Rewriting essential Linux packages in Rust

The problem with your argument is that the GPL has not only provided the corporate world with free labor, but with a licensing model that big corporations now like for their own stuff, because it lets them license the code to other parties while retaining important advantages over those parties.

GNU and Linux are the engine that powers practically every form of online harm.

The best licenses are BSD and MIT and others of that sort; they have no naive pretense of not helping corporations: everyone can do almost whatever they want, be they a large business or an individual. These licenses also don't encourage unlevel playing fields where the copyright proprietor enjoys dominance in the ecosystem.

For instance, if you are licensee under the BSD2, the only thing you cannot do, in comparison with the copyright holder, is remove copyright notices from the documentation or other materials accompanying the compiled code. This is really a minor thing which only stands in the way of those who want to be outright plagiarists.

With the GPL, it's extremely important to be the copyright holder, so that you can litigate. That's why the Free Software Foundation and GNU Project require copyright assignment for all non-trivial contributions to every project. If your program is a patchwork of files, each copyright someone else, you can't litigate infringement cases easily.

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 children! The wolf in sheep's clothing.

I would have said this in the past, but at this point I don't think it matters that much anymore.

1. Code copyright has devalued a lot in general, as you can code significantly faster with LLMs and use them to launder GPL'd code into whatever you want.

2. Big tech seems to be getting away with most other forms of abuses these days, GPL wouldn't really stop them from doing anything important.

To the extent that code is being devalued, I would say that these LLMs are a benefit to open source overall, as devaluing of code also reduces the opportunity cost of open sourcing software. They also somewhat level the playing field between single-contributor open source projects and companies with teams of developers, because an individual is almost always limited by the rate at which he/she can write or architecture code, whereas teams have significant non-code overheads (meetings, reviews, bureaucracy).

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?

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

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.

+1 also, it is much less interesting if this is not sent upstream (even if upstream is not interested at this point)

[dead]

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.

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.

crates.io does not allow a dependency of another crate to be arbitrarily deleted as per their usage policy section 'package ownership' paragraph 4.

> There is more and more tooling around to help mitigate the risk, he said.

Could anyone expand on this? I could imagine tools... better static analysis, maybe? being able to help. But I'd really want to see details. Both to see if it really helps, and because if there is tooling to help then I want to know so I can adopt it!

But Rust is so secure, what could ever happen? ;)

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.

... when rewriting Linux system software, I'd only use Rust dependencies from a distro (probably something LTS, like Debian stable, or such).

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.

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

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.

> I wonder if Linux is re-written i(n) (sic) rust will it too remove GPL as a factor ?

No reason it must? AFAIK all Rust for Linux code is GPL2. For example see: https://github.com/torvalds/linux/blob/master/rust/kernel/al...

If some was or were to be licensed as MIT code, there is also plenty of dual licensed code in the Linux kernel.

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.

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

No.

What relevance does that have tho?

Not yet, afaik the rust4linux devs thus want to create a rust frontend for GCC (gccrs)

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.

There is no really transistion. Much developers just are ignoring Rust as they ignored D, E, Go, Ruby on Rails(the PHP developers) and some other fashion programming languages. It's a overhyped trend and in some years Rust will find his place beside all the other Languages, but will never be a widespread replacement of C/C++.

We tried it in a commercially project because some hyperiders in the team wanted to do so. The truth is, a thing that would be developed in C++ in 1.5 month wasn't done in 6 months caused by things like 'All our developers are newbies in the language, no one really can do meaningful reviews, tons of dependencies(often one dependency in different versions), no good way to integrate cargo in our existing build flow and the lack of fun during programming.'

When you don't start a complete new project with bloody newbies, Rust is not a good choice.

We just should ignore the evangelists that just reimplement something existing in rust again. Maybe this language will die or find his way in the corner where someone is doing soemthing useful with it.

fd is also great and I install it everywhere.

https://github.com/sharkdp/fd

And https://github.com/ast-grep/ast-grep maybe

It’s a great tool, but it’s not a posix compliant grep.