this post was submitted on 24 Mar 2025
106 points (92.7% liked)

Linux

52637 readers
815 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

At first I was sceptical, but after a few thought, I came to the solution that, if uutils can do the same stuff, is/stays actively maintained and more secure/safe (like memory bugs), this is a good change.

What are your thoughts abouth this?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 1 week ago (3 children)

I personally don't see the point.

[–] [email protected] 28 points 1 week ago (1 children)

See other comments: all these rewrites are not using the GPL but rather permissive licenses like MIT. Bye-bye FOSS (in those ecosystems).

[–] [email protected] 14 points 1 week ago (2 children)

I don't like them moving away from gpl but there were already plenty of non-gpl coreutils clones, so, i'm not sure how much it really matters as long as the linux kernel is still gpl.

[–] [email protected] 11 points 1 week ago* (last edited 1 week ago) (1 children)

Unlike the other alternative coreutils, uutils focuses on GNU compatibility. If you depend on GNUisms, uutils allow you to unGNU & unGPLv3+ your system.

[–] [email protected] 6 points 6 days ago* (last edited 6 days ago) (1 children)

I don't understand, you'd still have to completely replace the linux kernel for a situation where this matters to occur, no?

[–] [email protected] 8 points 6 days ago (1 children)

The Linux kernel is licensed under GPLv2, not v3. The third version of the license forbids tivoization (vendoring unmodifiable copyleft software). Also, the GNU coreutils aren't limited to Linux.

[–] [email protected] 3 points 6 days ago (1 children)

I know they aren't limited to linux, but can you give me an example of a situation where this matters?

All of the situations I can think of are remedied by the fact that linux is still GPL'd

[–] [email protected] 1 points 6 days ago* (last edited 6 days ago)

I will give you one. You want to embed the coreutils in some other projects ie. a browser. But at that point it's cheaper for you to submit your modification upstream because you are making money selling the browser not by selling modified coreutils. Maintaining your own fork is not worth it once you make meaningful changes.

~~I think this is the reason why uutils are being funded by Big Tech and why they chose this license. (to get funded)~~ correction: I only found that they are funded by the Sovereign Tech Fund and apparently the author is open to changing the license, they don't care (see video/presentation).

But yes, I agree this whole comment section is deranged. The reason why Ubuntu chose uutils is because of Rust's safety and because of speed. In some workloads (I think it's sorting) they totally smash the GNU counterparts.

For Ubuntu it does not make any sense to make a proprietary fork. You don't choose your OS based on its coreutils. If they added a new convenience flag for their proprietary grep, it would just make them look bad. Also skilled users would hate it because now their scripts would not be portable. Or if it were really that big of a gamechanger, the feature would get added to the other coreutils and Ubuntu would end up with nothing but bad reputation. Unless they made change to the underlying code for performance. Then it would be harder to implement in the other coreutils but as I said before, nobody would care. Faster and safer coreutils are a nice to have, not something people base their OS choice on.

Edit: added source to author's stance on license

[–] [email protected] 9 points 1 week ago (1 children)

I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.

Take the recent rsync vulnerabilities for example.

https://www.cyberciti.biz/linux-news/cve-2024-12084-rsyn-security-urgent-update-needed-on-unix-bsd-systems/#more-2215

At least this one in a Rust implementation of rsync would have very likely been avoided:

CVE-2024-12085 – A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time. Info Leak via uninitialized Stack contents defeats ASLR.

[–] [email protected] -1 points 1 week ago (3 children)

I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.

So you prefer closed-source code to potentially unsafe open-source code?

Take the recent rsync vulnerabilities for example.

Already fixed, in software that's existed for years and is used by millions. But Oh no, memory issues, let's rewrite that in ! will surely result in a better outcome.

[–] [email protected] 7 points 6 days ago

Already fixed, in software that's existed for years and is used by millions. But Oh no, memory issues, let's rewrite that in ! will surely result in a better outcome.

Rsync is great software, but the C language fates it to keep having memory issues in spite of its skilled developers.

Preventing a bug from being possible > fixing a bug.

[–] [email protected] 0 points 6 days ago* (last edited 6 days ago)

Rust isn't language of the month unless you've been asleep for a decade, old man

What about the rust version is closed source?

This whole post is very disingenuous.

Edit: oh you're a troll

[–] [email protected] 4 points 1 week ago

They're MIT licensed.

[–] [email protected] 7 points 1 week ago (1 children)

Mainly memory safety; split (which is also used for other programs like sort) had a memory heap overflow issue last year to name one. The GNU Coreutils are well tested and very well written, the entire suite of programs has a CVE only once every few years from what I can see, but they do exist and most of those would be solved with a memory and type safe language.

That said, Rust also handles parallelism and concurrency much better than C ever could, though most of these programs don't really benefit from that or not much since they already handled this quite well, especially for C programs.

[–] [email protected] -1 points 1 week ago (2 children)

but they do exist and most of those would be solved with a memory and type safe language.

Maybe.

Still, there are other sources of bugs beyond memory management.

And i'd rather have GPL-ed potentially unsafe C code to... closed-source Rust code.

[–] [email protected] 9 points 6 days ago (1 children)

The Rust code isn't closed source, but I'd strongly prefer a coreutils replacement to use GPL over MIT as well.

[–] [email protected] 1 points 6 days ago (1 children)

The Rust code isn’t closed source yet
FTFY

[–] [email protected] 0 points 6 days ago

What the fuck is wrong with your brain?

[–] [email protected] 2 points 6 days ago* (last edited 6 days ago)

To add to @[email protected]

The uutils are MIT licensed, simply put it means “do whatever you want with it, as long as you credit us”.
The coreutils are GPL, simply put “do whatever you want with it but only in other GPL works, also credit us”.

The coreutils make sure forks will also be open source.
While the uutils aren't closed source, they do allow you to make closed source forks.

The uutils' license is too permissive.