Not interested in an MIT-licensed coreutils. Thanks, but no thanks!
this post was submitted on 10 Apr 2026
50 points (96.3% liked)
Linux
64605 readers
630 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 6 years ago
MODERATORS
Yeah but people who want to sell support and their own unique coreutils are interested in that.
Also not interested in a rust rewrite of coreutils but the same ppl whose material interests are served by mit licensing get to replace senior devs with fresh off the bus/out of college juniors and ai when they target rust so that’s happening too.
I can understand MIT being an issue in some cases. For example, VSCode is a proprietary fork of the MIT open-source Code. If Microsoft wanted, they could stop publishing the MIT open source version. Of course that code would still exist as MIT, but development would slow down without Microsoft.
But I don't see uutils being MIT as an issue. It's primary goal is to be compatible with GNU coreutils. You can't really rug pull a project with a goal like that. And permissively licensed utils have been around thanks to BSD and it's never been an issue. You don't see companies like Apple using proprietary forked versions as benefit. The "value" they add is higher up the tech stack with their own truly proprietary stuff or open stuff that encourages lock-in to its ecosystem, like Swift.
And permissively licensed utils have been around thanks to BSD and it’s never been an issue.
The distinction is that BSD coreutils are not attempting to be a drop-in 1:1 compatible replacement of GNU coreutils. The Rust coreutils has already accomplished this with its inclusion into Ubuntu 26.04.
If I wanted a permissively licensed system, I'd use BSD. I don't, so I primarily use Linux. I think citing a proprietary OS like macOS as a reason why permissively licensed coreutils are OK is kind of funny. It's easy to forget that before before the GPL there were many incompatible UNIX systems developed by different companies, and IMO the GPL has kept MIT and BSD-licensed projects "Honest", so-to-speak. Without the GPL to keep things in check, we'd be back to how things were in the 80s.
So what's next on the docket for Ubuntu? A permissively licensed libc?
What are they going to call the rust reimplementation of Bash? Rash?
Snap as a technology is so interesting and more versatile than other formats. It's just unfortunate that Canonical is in charge of the project, they've made some baffling decisions and continue to shoot themselves in the foot.
no closed down walled garden will ever be interesting or versatile
That's part of what I mean. Snap could be so much more interesting and useful if not for Canonical doing stuff like only allowing one store and slacking on proper support for non-AppArmor distros.
One of the more bizarre experiences I've had is that a Canonical employee packaged a version of a Minecraft launcher. It was absolutely garbage, didn't even start. The first thing that comes to mind is that snap is just garbage. But for fun, I made my own package of it, and it just worked perfectly. Which just leaves me the question of why a Canonical employee who works on snap can't create a good snap package.
There's also the weird fact that Ubuntu dropped the ball with its core24 runtime. For some reason, Canonical's own snaps stuck to core22 up until this month. Like, why wouldn't they upgrade to their latest runtime? If there was an issue with it, why has it been broken for 2 years? Doesn't inspire trust.
Huh. Now you've got me thinking. Are snaps redeemable? Are they forkable?
If you have all the AppArmor patches and use a custom snap store, I believe so. There's some inefficiencies with flatpak that are currently ignored. For example, every flatpak app has its own bubblewrap processing running, though they are light on resource usage. However, inter process communication is really inefficient, there's a lot of context switching. You have the app talking to the dbus proxy and the proxy talks the real dbus (there might even be a step between the dbus proxy and real dbus).
Meanwhile, for snap, this security stuff is handled by AppArmor security profiles. There's no need for a dbus proxy.
Security is nice but I would like finished ipu6 hardware support
Are you waiting for a kernel patch, or is this support simply not available yet?
It’s supported but buggy as hell. If you have an ipu6 laptop with a MIPI camera, the camera won’t work. Some worked in 24.04 but neither 25.x release nor the 26.04 beta work yet. And for me at least I have a (not my choice of laptop) actually supported with Ubuntu Dell machine.
And even without that, it seems to suffer from random lag - I can’t seem to fathom what causes that at all.
I’ve been told I should have gotten an AMD machine, but this is for work and had to be supplied through an “approved vendor” so I was limited to what they had available.
Do they still lock security updates behind paywalls? 🤣