Live data from Hacker News

Rewriting essential Linux packages in Rust

lwn.net

51–60 of 175 posts

Re: Rewriting essential Linux packages in Rust

#51

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

Just using dependencies isn't bad IMO. Your code might be of much higher quality when you use libraries that are used by many other packages instead of coding your own stuff that is only used by your package and thus less reviewed / less improved upon.

That is much less true than you think. It's undeniably true for "complicated" stuff. If you as an app developer roll your own DEFLATE implementation vs. using zlib, you're being an idiot, etc... But the lines around those utilities have long since been drawn already, and traditional open source projects have already organized themselves around this. We don't need crates.io to put libz.so into a separate package, it's already there.

Instead, what's left over is a bunch of random junk that saves developers 20-30 minutes of typing and Stack Overflow research. "Here's a small package to automate the creation of a zip file with this format and add a manifest file to it", stuff like that.

And more, downstreams tend not to use the whole package anyway. So you end up importing a "small" 2000-line crate just to use 7% of it. The "code quality" calculus tends to invert very rapidly when you have that kind of ratio.

Re: Rewriting essential Linux packages in Rust

#52
post #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.

AGPL? I can understand. Pure GPL 2 or even GPL 3? Never heard of that.

Re: Rewriting essential Linux packages in Rust

#53

Earlier quoted context omitted.

No. What relevance does that have tho?

The relevance would be that Rust coreutils cannot be merged into Linux mainline. Obviously.

Coreutils are not part of the linux project in the first place, and uutils does not aim to be merged into GNU coreutils.

Re: Rewriting essential Linux packages in Rust

#54
A big reason the GNU utilities were game changing is not because of their existence, or their functionality, but because of their license... a license which, in no small part, is what not merely motivated but then allowed for their continued existence and functionality: a tit-for-tat, sharing is caring, we're all in this together, fighting for the users approach to software development, one which ensures that no one is going to embrace and extend your software for use in their platform to lock people out of participation (whether directly or indirectly) in control over the hardware they own.

It just really really sucks that people are thereby allocating a ton of effort into reimplementing these tools--putting good effort behind a project that even has a good reason to exist (memory safety), even if (as I'll poke at later in this comment) that apparently is explicitly not the reason they are working on this (which shocked me)--with the goal of being "bug for bug compatible" with the upstream copies from the GNU Foundation while carefully ignoring the #1 most important integration (as this affects how the software fits into the whole) test: "is this software 'free' as in freedom?".

Of course, they claim that this is some kind of unproductive waste of time "debate", as if the license is the least important part of the software and doesn't matter, and I think some people want to take this narrative. Regardless, whether or not we agree with this--a position that feels a lot like "politics don't matter and are a waste of time, so stop voicing your concerns"--that's not what's going on here: if you look a bit deeper, this project actually cares deeply about its license, and is going out of its way to choose the license it is using, ignore complaints, and avoid ending up GPL.

https://www.youtube.com/watch?v=5qTyyMyU2hQ

In an interview with FOSS Weekly, Sylvestre Ledru (the main developer, who curiously has a background working on Debian and Firefox, before ending up getting seduced by the clang/LLVM ecosystem), firmly states "it is not about security", focusing only on an interest in learning himself how the full stack of tools function and preparing for a future where new developers don't actually know enough C to contribute; this might seem to fit into the earlier narrative that the license doesn't really matter, which he later restates himself "I don't care that much, as long as it is OSI compliant".

This topic comes up multiple times later in the interview, and Steven sticks to his framing that he doesn't care about the license, that this debate is a waste of time, and that he tries to avoid discussing it as it is "more philosophical than technical". Of course, this isn't preventing him from discussing it ;P... this is clearly a big issue that people have with this project, it is one that comes up in most discussions of the project, and--if it really didn't matter, and it really weren't a big deal--you would thereby expect that he'd just change it, to avoid having to discuss it again...

...only, in this interview--in no small part from the interviewer slowly leaking part of their pre-interview discussion to cause the topic to keep coming back up--we learn just how much this developer does seem to care about the license, as, to keep it all as MIT, he's having to avoid looking at the original implementation, in an attempt to avoid accidentally letting his code get infected by GPL, to support some users of the project who actively choose to use this reimplementation to avoid GPL compliance (the example we are given--by the interviewer outing it, not him--is "car manufacturers").

As someone who works in security but finds it demoralizing how often security is used as an excuse for what ends up being an effort to lock users out of a platform due to what is merely some supposedly-accidental property of the effort--including one time I was in a hearing with the US Copyright Office, sitting next to a rep from General Motors who was there to argue that we shouldn't be allowed to jailbreak a "portable all-purpose mobile computing device" because that might include a car (lol)--I found this back/forth in the comments forum on the website for this interview worth reading:

https://hackaday.com/2024/07/17/floss-weekly-episode-792-rus...

the goal is to “rewrite it in x” is to move everything to permissive liscenses. then lock future changes away. just like every thing else “security” is used as pretext.

We chatted a bit about exactly that. They make no claim that this effort is for security, and freely admitted that some of their users are doing so precisely because it’s MIT and not GPL. So… Yes, but actually no.

That sounds like yes, but actually, yes. No?

Re: Rewriting essential Linux packages in Rust

#55

Earlier quoted context omitted.

The relevance would be that Rust coreutils cannot be merged into Linux mainline. Obviously.

Coreutils are not part of the linux project in the first place, and uutils does not aim to be merged into GNU coreutils.

>> The relevance would be that Rust coreutils cannot be merged into Linux mainline. Obviously.

> Coreutils are not part of the linux project in the first place, and uutils does not aim to be merged into GNU coreutils.

I think he having fun with you bro.

Re: Rewriting essential Linux packages in Rust

#56
I wonder what lessons were learned that could benefit others who want to port command line tools from C to Rust, e.g. particular idioms or re-usable functions (error handling, logging, defaults/dot-file management, command line option parsing).

There was a book called "Dr. Dobb's C-tools", which had the commented source code of a C compiler, assembler, linker and std library, and it greatly benefitted me to go beyond K&R's book towards understand the idioms of C programing.

Re: Rewriting essential Linux packages in Rust

#57
post #12

Is Rust (llvm?) supported on all platforms Linux targets?

> Is 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 e…

I can't find an official list of supported targets, but

https://github.com/coreutils/coreutils/blob/master/README-in...

contains notes on compiling for IRIX, HPUX, AIX, and OSF/1. So no, I would bet that it very much does run anywhere Linux runs, and a lot of places it doesn't.

Re: Rewriting essential Linux packages in Rust

#58
post #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?

As a person who shares OPs concerns, (A)GPL is acceptable, in v2 or v3 form. Anything permissive is not, because allows a closed fork, which everybody wants to do to rob free software ecosystem to undo what has been done over these years.

Because "monies".

Re: Rewriting essential Linux packages in Rust

#59
post #40

Seems this project is MIT-licensed. That is fine, but I cannot help this is a way to get Corporations from following the GPL. I wonder if Linux is re-written i rust will it too remove GPL as a factor ? Again due to the license choice I tend to believe this can be seen as a way to move Linux to a Microsoft Type Windows System.

There's no specific reason for Rust code not to be GPL licensed. For whatever reason, many Rust devs choose not to use copyleft licences in their projects, but that doesn't preclude GPL projects from using Rust.

I would've preferred projects like these to be GPL licensed too, but as the author writes in the comments (https://lwn.net/Articles/1009647/): what's the real-world impact of this specific project being MIT?

Commercial UNIX systems are pretty much dead, and I doubt the ones that still want to ship customised versions of these tools will respect the GPLv3 licence. I believe copyleft is essential for things like kernels, but for userspace tooling where plenty of alternatives exist, I don't think it's as important.

Re: Rewriting essential Linux packages in Rust

#60
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.

Perhaps, but MIT licensed code is Free like Air and Sunshine.

...and can be closed anytime, if the author wants to.

Which will happen with these tools, anyway.

Post reply on HN