> " There are between 200 and 300 dependencies in the uutils project. He said that he understood there is always a supply-chain-attack risk, "but that's a risk we are willing to take". There is more and more tooling around to help mitigate the risk, he said. left-pad II, coming soon to a Linux distro near you
Rewriting essential Linux packages in Rust
21–30 of 175 posts
Re: Rewriting essential Linux packages in Rust
#22It's a fun pasttime. I'm rewriting mdadm in rust: https://github.com/DavidVentura/mdadm-rs Mostly, I am tired of tools requiring root access, or a block device, to function, even in read only mode. If you have a file on disk (eg: a VM's disk) mdadm will refuse to show metadata, requiring root to do so.
> If you have a file on disk (eg: a VM's disk) mdadm will refuse to show metadata, requiring root to do so. If that's an artificial limitation, surely it should be easy to fix?
Re: Rewriting essential Linux packages in Rust
#23Is Rust (llvm?) supported on all platforms Linux targets?
AFAIK, no. Linux chooses to support platforms from which we haven't seen new releases in decades, like DEC Alpha. Although in recent years, Linux has dumped support for many older platforms including IA-64.
But my guess is GNU coreutils also doesn't support all Linux targets. I mean this in two ways -- 1) AFAIK coreutils does not expressly support each and every Linux platform, and 2) whether something builds is not the measure of whether there is platform support.
That is -- Linux may support some weirdo MIPs variant and 68K (which has Tier 3 Rust support), but what's your guess that your GNU coreutils support, even busybox support, for these platforms is top tier? You may be guaranteed that your weirdo arch has a C compiler, but what's the likelihood all the GNU tests passed on this arch? That each and every utility even runs on this arch?
Re: Rewriting essential Linux packages in Rust
#24Re: Rewriting essential Linux packages in Rust
#25> " There are between 200 and 300 dependencies in the uutils project. He said that he understood there is always a supply-chain-attack risk, "but that's a risk we are willing to take". There is more and more tooling around to help mitigate the risk, he said. left-pad II, coming soon to a Linux distro near you
A left pad incident isn't possible on crates.io. Yanking a package from the registry doesn't remove the code if you have an existing lockfile.
Re: Rewriting essential Linux packages in Rust
#26Re: Rewriting essential Linux packages in Rust
#27Earlier quoted context omitted.
A left pad incident isn't possible on crates.io. Yanking a package from the registry doesn't remove the code if you have an existing lockfile.
left-pad is symbolic of dependency and supply chain issues generally. If all you took away from that incident is that there's risk only from someone unpublishing the module then you probably need to go back and think about it some more.
(An interesting thing to consider: the worst "supply-chain" type attack in recent memory is probably xz, which has a much more traditional maintenance, development, and distribution model than the median Rust package does. I don't think Rust's ecosystem is even remotely immune to the risk of malicious packages, but I imagine the kinds of dependencies that exist in the current coreutils are much more appealing to a high-sophistication attacker because of their relative lack of publicity/transparency.)
Re: Rewriting essential Linux packages in Rust
#28Re: Rewriting essential Linux packages in Rust
#29Re: Rewriting essential Linux packages in Rust
#30Ripgrep should be included in all distros by default.
fd is also great and I install it everywhere. https://github.com/sharkdp/fd
https://github.com/eza-community/eza (modern ls replacement)
https://github.com/BurntSushi/erd (modern tree replacement)
https://github.com/sharkdp/bat (modern cat(1) replacement)
my .zshrc for every system now uses these as drop in replacements