Live data from Hacker News

Rewriting essential Linux packages in Rust

lwn.net

41–50 of 175 posts

Re: Rewriting essential Linux packages in Rust

#41
post #35
post #29

Rewriting GPL software under the MIT license is a terrible thing to do. The GPL is meant to protect and preserve what should be basic human rights. So-called "permissive" licenses are meant to provide big tech with free labour.

Yup, and one doesn't need to look further than FreeBSD to see what the end result is. I wonder, to what extent is the Linux Rust effort "generously subsidized" by corporations? > He is thinking about ""what we are going to leave to the next generation"". Developers starting out don't want to use COBOL, Fortran, or C, he said. They want to work with fancy stuff like Rust, Swift, Go, or Kotlin. Oh, think about the chil…

I did not see these posts before I posted similar. I fully believe this is a direction Corporations are pushing.

Almost wonder when spyware will be added and restrictive DRM.

Re: Rewriting essential Linux packages in Rust

#44

I wonder how linux devs feel about the rewrite in Rust. I mean surly loads of them have decades of experience in C, and Rust seems like such a different beast. Can any C developers provide insight, how is this transition?

I don't see an transition happening at all. There are some rust projects, but they are more like an addition to, not an replacement of the current ecosystem.

Re: Rewriting essential Linux packages in Rust

#45
post #13

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 manag…

I like some of the directions you're heading with that. One thing I've thought is it might be useful to have tools that create filesystem objects (like "new" or "mov foo bar/") be able to take permissions. "mov --umask 027 --owner alice:bob foo bar/" and "new --mode a=rx foo/" for example.

install(1) does that: https://www.man7.org/linux/man-pages/man1/install.1.html

Re: Rewriting essential Linux packages in Rust

#46

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

I was a little horrified to see that quote, and really hope there's some context that makes it less of a disaster. That is not an appropriate answer or attitude. Also... what "tooling" is he talking about?!

The simple truth is that in "modern" package systems optimized around Reuse-Uber-Alles principles, the ability of J. Random Attacker to "get code into" a downstream app is much, much higher than it was in the days of coarse-grained projects. We need to start dealing with that as a problem to be solved and not excused away.

Re: Rewriting essential Linux packages in Rust

#47
post #29

Rewriting GPL software under the MIT license is a terrible thing to do. The GPL is meant to protect and preserve what should be basic human rights. So-called "permissive" licenses are meant to provide big tech with free labour.

Thanks for sharing this thought, it hadn't occured to me that this could be an issue. Would the choice of AGPL or MPL for a licence have satisfied your concerns?

Re: Rewriting essential Linux packages in Rust

#48
post #29

Rewriting GPL software under the MIT license is a terrible thing to do. The GPL is meant to protect and preserve what should be basic human rights. So-called "permissive" licenses are meant to provide big tech with free labour.

It would depend on what the end goal of the rewritten project is. If they pursue widespread adoption GPL licenses can definitely hinder it in many cases.

Re: Rewriting essential Linux packages in Rust

#49

Earlier 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.

Why would I take anything away beyond the specific scope of the vulnerability to supply chain issues that NPM had? Cargo offers a variety of tools for auditing and managing dependencies that specifically mitigate supply chain issues. If your only suggestion is to not use dependencies at all, that's an extreme opinion.

Re: Rewriting essential Linux packages in Rust

#50

Earlier quoted context omitted.

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

Did the previous developers put it there for fun? Probably not.

The previous developers might have written it at the time when VM disk RAID images were not a consideration. (Apparently it was Linux 3.0, 2011.)
Post reply on HN