Fuck Ubuntu fuck MIT fuck everything
this post was submitted on 15 Mar 2025
50 points (70.5% liked)
Linux
51822 readers
678 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
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
While shifting to Rust might be a good idea for improving safety and performance, adopting the MIT license represents a fundamental change that will enable large tech companies to develop and distribute proprietary software based on the new MIT-licensed Core Utilities. This shift moves away from the original vision of the project which was to ensure that the software remains free and open as enshrined in the GPL's copyleft principles. The permissive nature of the MIT license also will increase fragmentation, as it allows proprietary forks that diverge from the main project. This could weaken the community-driven development model and potentially lead to incompatible versions of the software.
Do large tech companies contribute a lot to the GPL coreutils?
If this happened, would Ubuntu based operating systems be impacted as well? I might start to learn Debian or LMDE if so.
MIT license is still open source, so Ubuntu based operating systems can still be open source. The problem is that this makes it less needed that they have to be. However most current projects will probably stay proper open source projects and likely continue to use a better license.
Can't wait for proprietary apps to not work on distros that still use gnu core utilities.
genuinely my only problem with it is the license. I really hate how much stuff is mit or apache now. I've seen some really nice projects get taken over and privatized in the last few years and nobody has learned
sadly, i think that's exactly the reason why so many gnu coreutils/libc/compiler competitors keep croping up: people want to get rid of the gpl as much as possible. if they could replace the linux kernel with a non gpl variant they would
not that the people creating the projects necessarily have this intention, but the projects are certainly being picked up and sponsored mainly for that reason
Clickbait. The VP Engineering for Ubuntu made a post that he was looking into using the Rust utils for Ubuntu and has been daily driving them and encouraged others to try
It’s by no means certain this will be done.
Clickbait
With mental outlaw, it's usually that or ragebait, to rile up his audience.
Clickbait. The VP Engineering for Ubuntu made a post that he was looking into using the Rust utils for Ubuntu and has been daily driving them and encouraged others to try
It’s by no means certain this will be done.
Here is that post. It isn't certain to happen, but he doesn't only say that he is daily driving them. He says his goal is to make them the default in 25.10:
My immediate goal is to make uutils’ coreutils implementation the default in Ubuntu 25.10, and subsequently in our next Long Term Support (LTS) release, Ubuntu 26.04 LTS, if the conditions are right.
His goal.
A VP could have the goal to increase profits by 500% over the next 6 months but that doesn't mean it's gonna happen.
It might happen, but just because someone says it's their goal is no confirmation that it will happen.
Yeah this particular guy also loves doing insane things to his machine. He's absolutely mental in a wonderful way.
My personal take on anything Jon does based on my experience with his delightful antics is that the only thing we can say for sure is if it doesn't work for him it's just not going to happen. His blog is pretty great to follow.
Huh, he mains NixOS. Always a bit funny to see someone daily driving a distro different than what they professionally work on.
I thought I recognized that blog, I remember reading his blog TPM+FDE for NixOS back when I was trying NixOS.
One of the main developers presented this project at FOSDEM.
(He is a Mozilla employee but made a point to tell it was not affiliated with Mozilla and was working on it on his spare time)
Hopefully it’s drop in compatible with GNU coreutils else a lot of scripts are gonna break
That’s the project’s goal and they have 100% comparability across quite a few of the tools. Definitely still a ways to go before they can fully replace all of coreutils, but Ubuntu’s goal is to replace the tools peace meal with the once that are ready.
Waiting for the Rust haters to get unjustifiedly mad again...
I love rust and projects rewritten in Rust, but I've felt pretty mixed about this particular project. The strong copyleft on GNU coreutils is part of what keeps many Linux distros truly free. There's stuff like BusyBox or BSD coreutils if you need something you can make non-free, but GNU coreutils are just so nice. I wish this reimplementation in rust had been licensed with GPL or a similar copyleft license. At least there's no CLA with copyright transfer.
Yeah the licensing is a bit worrying, but it's not a language issue.
It actually is a language issue.
Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.
But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you're program doesn't have to be GPL. It's partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn't be able to extend proprietary code off of it — not that I care about that, but the library makers often do.
https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries — it's complicated.
EDIT: Nvm I'm wrong. Rust does allow dynamic linking
Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.
EDIT2: Upon further research it seems that Rust's dynamic linking implementation lacks a "stable ABI" as compared to other languages such as Swift or C. So I guess we are back to "it is a language issue". Well thankfully this seems easier to fix than "Yeah Rust doesn't support dynamic linking at all.".
As long as two binaries are compiled with the same version of the Rust compiler, they are ABI compatible. Even if the compiler version differs, I've found that changes to the ABI are fairly uncommon. Furthermore, anything exposed through the C ABI is stable, so the problem can be circumvented if needed. It's not the most ergonomic solution, admittedly, but with some compromises dynamic linking is perfectly feasible.
The lack of ABI stability in Rust means they don't have to commit to language changes that may prove to be unpopular or poorly designed later.
Swift went through the same growing pains and, IMO, has suffered for it a bit with even quite basic code often needing lots of availability checks. This may seem counter intuitive but Swift is in the unique(-ish) position of having to serve both a huge corporation demanding significant evolution on a regular basis and a cross platform community that don't want to write an encyclopedia every time a major version of the language is rolled out.
Rust doesn't have this issue and I think it's right for them to allow themselves the freedom to correct language design errors until it gains more traction as a systems language - and it's quite exciting that we're seeing that traction happen now in realtime!
If I found the correct repo it seems like it's MIT licenced which is very permissive, as well.
No that's the issue: it's too permissive. It allows corporations or individuals to redistribute and modify the code as closed source, which isn't desirable for this kind of project.
I interpreted your message wrong, now I get it, thanks!
Here's the giant run-on sentence youtube transcript:
spoiler
earlier this week Ubuntu announced plans to integrate rust based implementations of essential system utilities starting with the upcoming Ubuntu 2510 release the plan is to use programs from yuud which has got to be the biggest rewrite in Russ project ever in terms of how prolific it could become if experiments like this one that Ubuntu will be conducting are successful the corles like LS and CP are used on every Unix like operating system out there so servers firewalls embedded devices Mac Linux Android and every smart whatever is using these programs under the hood so replacing these essential tools that the world has depended on for decades with rust rewrites is both interesting and really terrifying so the goals that usually drive a rust rewrite or just choosing to write something in Rust to begin with versus another language is for it to be blazingly fast and memory safe now to gnu's credit their implementation of the corles actually has a really amazing track record with security and hasn't had that many major vulnerabilities discovered in it over the last 20 years but there have been memory bugs in Coral like split as recently as last year and if it had been written in Rust there wouldn't have been a heap-based buffer overflow bug in it and sure enough if we read the disclosure on ubuntu.com that goes into the reasoning the enhanced resilience and safety that is more easily achieved with rust ports are what's most attractive about it now while the article didn't list performance as the primary driver for rustifer doeses bring up an interesting point about performance and also reliability by saying if found foundational software fails so does all the other layers built on top if foundational packages have performance bottlenecks that becomes a floor on the performance achievable by the layers above if these core utilities can get faster then everything else can get faster and the speed is one of the primary focuses of the U utils project now in a lot of cases the core utilities probably won't get much faster because of writing them in Rust because one of the big speed advantages that you actually get over C or C++ is that in Rust multi-threading is typically much easier to implement especially in a safe manner but a lot of the tools in the core utilities don't actually benefit from being multi-threaded or parallelized in any way for example MV CP and RM are all file system tools and since disio is fundamentally serialized there's not much point in them being parallelized but there are huge opportunities for the few core utils that can be run in parallel and that's why when the lead developer of U utils did a talk at fem this year he did a live Benchmark of the uu's implementation of the sort command against the G new implementation because sort is one of those programs that actually benefits from more threads and the U's implementation was six times faster than gano's so you can imagine the gains that something as basic as faster sorting is going to bring to basically every other program that's running on higher levels on the operating system now Ubuntu isn't just going to all of a sudden pull the familiar core utilities from under their user's feet instead they release this oxidizer tool which let's use users and developers seamlessly rustifer ify their core utilities on their Ubuntu system so that they can get used to how that's going to work before rust actually becomes the default and you can download this right now to your Ubuntu system from GitHub or you can install it with cargo but you should still be careful with running this because it could break your system I mean it's making a very fundamental change to how things are working so make sure that you have a backup but by default if you run this with the basic enable command it's going to replace coril and Pudu enabling all experiments is going to replace coril Pudu find utils and diff utils and make them the default on your Linux system so far I haven't broken my Ubuntu VM with oxidizer but again be careful if you have important data on your system now of course the Linux kernel itself has been progressively integrating rust into it with initial support merged in version 6.1 and ongoing developments to include rust written drivers lus traval has also shown support for rust especially by his usual metrics and so there's a lot of support for this language in the Linux world and one of the biggest upsets here I think is really to ganu because if Ubuntu succeeds with yuud and other distributions start to follow suit then G new Linux won't really be a thing anymore more and it would really be a shame if ganu got dropped from Linux before they're even able to finish their own Kel because without a konel you can't really call yourself an operating system and while most people besides gnu developers are probably welcoming this rustifer Utilities in Linux there are some people that absolutely hate this change and it's not just people that prefer C and C++ who who hate the syntax of rust so much that reading it makes their eyes bleed and hearing rust evangelism sounds like nails on a chalkboard to them these people are always going to be around whenever you mention rust but I think the real big concern here with uud is its software license so this rust implementation of the cor udol as an MIT license while the gnu one of course has a GPL license and by the way I might as well mention that G's implementation of Cory udil isn't the only one in existence okay BSD has their own busy box is another Apple has another Unix had another but G new GPL license on their code is where the real big deal is here especially for low-level programs like this so the general public license or GPL is copy left so you can think of it as doing the inverse of what a copyri does which restricts the ownership and control over some intellectual property to an individual party GPL makes things free as in freedom forever so if you took ganu and you built upon it you'd have to open source your improvements if you wanted to distribute them you could technically use GPL code and make proprietary modifications and then just use it on your own system but if you want to distribute it has to be open and this prevents proprietary software in the form of binary Aries or encrypted or heavily ausc code from being added to a GPL code base but an MIT license does not prevent this it's perfectly legal to take MIT license code which would be open source and then make fantastic improvements to it or integrate it into a small part as a much larger code base and none of the changes or additions that you made in these cases would have to be open source even if you wanted to distribute them and it could be the case that your changes are so popular that they basically end up replacing the original open source program in popularity and since proprietary software is a kind of evil in itself because the end users don't have any control over it you could argue that MIT and similar licenses allow for good open-source software to be more easily turned into something that is going to abuse end users and this has already happened with Minix so this was another Unix like operating system that was developed by Andrew tannin bomb and it actually predates Linux by a few years and Minix was initially proprietary software that was conditionally Source available I think maybe you could get the source code if you were in University because initially Minix was created to be a teaching tool but anyway in the year year 2000 almost 13 years after Minx first came out it was officially open- sourced under a BSD license and the reason for this was commercial viability so as you can imagine a lot of companies don't actually want to open source their code or they don't want to open source whatever changes they made because they don't want their competitors to get it because they think it gives them a Competitive Edge and yada yada and so they're wary about using anything that is GPL and this pretty much sums up Tannon bomb's reasoning too for using the BSD license for menx but this openness allowed Intel to integrate Minix code into their Intel management engine which is basically a mini operating system that runs on every Intel chip alongside your real OS and because of this it's technically one of the most used operating systems in the world and if you read Tannon bombs open letter to Intel he obviously is not super happy about the way that Intel went about this mentioning that they should have at least given him a heads up about his OS becoming the most prolific one ever but again that is not a requirement of a BSD or an MIT license you don't even have to say thanks to the person who originally developed that code so this could lead to more excellent operating systems being poached for diabolical reason reasons in the future by major corporations but what do you think are the fears about the MIT license overblown is rust in the core utilities a good thing for Linux let me know in the comments below like and share this video to hack the algorithm and check out my online store based. win where you can buy my awesome merch or accessories for your phone or laptop 10% store away discount when you pay him Monero XMR at checkout have a great rest of your day
Oh, how I wish spoilers worked in my Lemmy app...
Works well in thunder
Works on Voyager and Mlem.
Still not on Boost, unfortunately.
Boost was abandoned
Do you have any statements from the dev? Would be curious to know if there's anything that corroborates it being abandoned or on hiatus.
But it sure does seem that way. I remember Boost for Reddit getting updates all the time, and this one had a few in the beginning, then it just kinda stopped with bugs unresolved.
It's a shame, because there's a lot to like about Boost.
Worked for me on the voyager app