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

Rewriting essential Linux packages in Rust

lwn.net

Post reply on HN
Print view View original

11–20 of 175 posts

Re: Rewriting essential Linux packages in Rust

#13

Post by xixixao »

I've been using the rewritten coreutils as a reference in implementing human-utils[0].

The amount of complexity, even with pretty high-level Rust std, is still super high. So rewriting them in Rust is no small feat.

For the file-system management ones: I appreciate the value of everyone knowing these tools, but they do have some terrible defaults, and I wish there was an alternative between using a GUI/TUI file manager and carefully not stabbing myself in the foot. That's why I started building human-utils (alas it's very much unfinished).

https://github.com/xixixao/human-utils

Re: Rewriting essential Linux packages in Rust

#14

Post by deivid »

It'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.

Re: Rewriting essential Linux packages in Rust

#17

Post by brian-armstrong »

> " 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

Re: Rewriting essential Linux packages in Rust

#18

Post by estebank »

janice1999 wrote: post #10
dylan604 wrote: post #5

Earlier quoted context omitted.

If the original thing is improved by being written in Rust as everyone proclaims, then this would be a good thing. However, I have doubts that the years upon years of updates fixing odd behavior, and then forgotten about the whys&hows of those updates that the same issues will not be introduced in the Rust version.

> and then forgotten about the whys&hows of those updates that the same issues will not be introduced in the Rust version. Ideally that's what test suites are for, although I'm sure some deviations/gaps will be caught by users. For uutils they are preserving all the edge cases, replicating the original behaviour. There are benefits to rewrites (far less often in my experience), like doas replacing sudo in BSD distros…

And in the face of gaps of the test suite there's no assurance that consistent output will be preserved across releases of the same application. This is somewhat mitigated by the slow release schedule that these kind of projects usually have, couples with a feeling of "being done" meaning that releases shouldn't have much green field feature development work. But still fixing one bug could cause a regression elsewhere.

Re: Rewriting essential Linux packages in Rust

#19

Post by johnny22 »

brian-armstrong wrote: post #17

> " 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

pretty sure you'd have to call it something else. I don't think the crates setup allows what exactly happened with left-pad to happen. It's much more likely to involve malicious code.

Re: Rewriting essential Linux packages in Rust

#20

Post by yjftsjthsd-h »

deivid wrote: post #14

It'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?

Post reply on HN