Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

Post reply on HN
Print view View original

261–270 of 338 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#262

Post by sick_of_slop »

collinfunk wrote: post #5

I really don't understand why Canonical rushes this. If 'rm' can't remove all possible directory entries, that is a big issue: $ podman run --rm -it ubuntu:26.10 $ apt update -y; apt upgrade -y $ rm --version rm (uutils coreutils) 0.10.0 $ gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n') $ rm -rf a Segmentation fault (core dumped) rm -rf a $ ls a a $ gnurm -rf a $ ls a ls: cannot access 'a': No such file o…

[dead]

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#263

Post by swiftcoder »

werdl wrote: post #152
t0duf0du wrote: post #124

I was bummed when I came across this: https://github.com/trifectatechfoundation/sudo-rs/issues/129...

I don't understand - I thought sudo-rs was supposed to be a drop-in replacement? If it implements a subset of features how can this be the case?

the uutils project bills themselves as a drop-in replacement for coreutils. sudo-rs does not bill itself as a drop-in replacement for sudo

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#264

Post by t0duf0du »

collinfunk wrote: post #171
werdl wrote: post #152

Earlier quoted context omitted.

I don't understand - I thought sudo-rs was supposed to be a drop-in replacement? If it implements a subset of features how can this be the case?

I don't think sudo-rs ever advertised itself as a drop in replacement. They seem pretty upfront that it isn't their goal. See this list: https://github.com/trifectatechfoundation/sudo-rs#difference...

Its not that if they have advertised themselves as a drop-in replacement or not. What made me bummed that cannonical used it as drop-in replacement and it did break some of my installation scripts.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#265

Post by Freaky »

Arcuru wrote: post #52

Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I looked at in detail had pretty bad performance or correctness issues. [1] https://jackson.dev/post/rust-coreutils-dd/

Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099...

Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751...

It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it:

     dd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec)

     target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s

     gdd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/s

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#266

Post by sick_of_slop »

mort96 wrote: post #207
teekert wrote: post #6

Earlier quoted context omitted.

Rush? This is an interim release (95% or so only tracks LTS's) that is not even out yet... Go file a bug reports if you have some time.

This is what made me move away from Ubuntu. Use LTS and encounter issues with outdated packages? "Well duh, you're supposed to upgrade to interim releases if you need remotely up to date software". Use interim releases and encounter bugs? "Well duh, it's an interim release. Of course it's a buggy mess, nobody uses those" Every Fedora release is intended to be solid and they come out twice a year.

[dead]

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#267

Post by aliceFish »

senfiaj wrote: post #198
erminpour wrote: post #128

Whether you like Rust or not, it's questionable as to why Canonical would push this so much and do it in such a cavalier way. Will this really make coreutils more secure? I doubt it, if anything there will be a river of new bugs. So, again, why are they pushing Rust so much? Having Microsoft make Rust a 'Tier-1' language also doesn't bode well.

>> Will this really make coreutils more secure? In the long run yes. Sure, many logic bugs happen in Rust programs as well, but memory safety bugs are another level of hell. At least many classes of exploits will mostly be impossible. Also, Rust program failures tend to be more predictable. For example, in C/C++, if you do out of bound writes in an array or writes in a freed memory block, the behavior is undefined. T…

new C++ STL standard makes it no more undefined.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#268

Post by c0balt »

chris_st wrote: post #257
linsomniac wrote: post #244

ProTip: You can switch back to Gnu coreutils on 26.04 with: apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential And pin it so an upgrade doesn't flip it back with: printf 'Package: coreutils-from-uutils\nPin: release a=*\nPin-Priority: -10\n' \ | sudo tee /etc/apt/preferences.d/uutils > /dev/null

Just curious, why the 'sudo tee {file} > /dev/null'?

it writes to the file with elevated priviledges and doesn't write it back to the terminal, effectively a 'sudo sh -c '{cmd} > {file}''.

sudo tee is a common way to work around priviledge restrictions in shell pipes (you can't easily 'sudo' a pipe), if /secure was 0600 and owned by root:

"sudo echo "test" > /secure" or "sudo printf '' > /secure", would not work because your user's shell process can't write to /secure. However, "echo 'test' | sudo tee /secure" works because the elevated 'sudo tee' can write to the file.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#269

Post by akdev1l »

dijit wrote: post #259
dale_glass wrote: post #256

Earlier quoted context omitted.

Why are we still using dd? Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.

I don’t know of a better tool that operates on raw blocks, maybe there is one. `dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.

    cp file.iso /dev/sda
Post reply on HN