Ubuntu explores replacing gnu utils with rust based uutils
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?
don't like this
Jumuta
in reply to Zenlix • • •like this
underrate170 likes this.
ParetoOptimalDev
in reply to Jumuta • • •I would love this news if it didn't move away from the GPL.
Mass move to MIT is just empowering enshittification by greedy companies.
like this
underrate170 and Nathan like this.
Zenlix
in reply to ParetoOptimalDev • • •thedeadwalking4242
in reply to Zenlix • • •SmoothLiquidation
in reply to thedeadwalking4242 • • •thedeadwalking4242
in reply to SmoothLiquidation • • •Competitive improvements the company makes make be kept secret, re packaged, and sold without making contributions to the src code.
Basically embrace, extend, extinguish
like this
Nathan likes this.
prime_number_314159
in reply to thedeadwalking4242 • • •don't like this
Nathan doesn't like this.
Nathan
in reply to prime_number_314159 • •Linux reshared this.
thedeadwalking4242
in reply to prime_number_314159 • • •Patents kill innovation. No one should be granted rights to a concept purely because they got to it first. It’s still really.
I didn’t even say anything about copyright or patent?
Mactan
in reply to SmoothLiquidation • • •SmoothLiquidation
in reply to Mactan • • •girsaysdoom
in reply to SmoothLiquidation • • •like this
Nathan likes this.
philluminati
in reply to SmoothLiquidation • • •To give you an example, if git was under the MIT license instead of GPL , then Microsoft can silently add incompatible features to GitHub without anyone knowing. The regular git client appears to work for a while. Then they start advertising msgit with some extra GitHub features and shortcuts. Once they get to 50% adoption they simply kill the open source version off.
If GitHub required a special client to be installed tomorrow… I would have to concede and use it. It’s GPL that stops that because everyone has to get every new feature.
When Slack was first rolling out the dev team in my office of 50 people we all hated it. Thankfully it had an IRC bridge so we could use Slack through IRC. It was seemingly the same experience as before except more business users were in the chat rooms. Once the Corp side of the business were onboard, they dropped IRC support, forcing us to use their clients.
Now it doesn’t matter that rules or laws or privacy invasion they do. They have captured the companies communications and can hold it hostage.
I’
... Show more...To give you an example, if git was under the MIT license instead of GPL , then Microsoft can silently add incompatible features to GitHub without anyone knowing. The regular git client appears to work for a while. Then they start advertising msgit with some extra GitHub features and shortcuts. Once they get to 50% adoption they simply kill the open source version off.
If GitHub required a special client to be installed tomorrow… I would have to concede and use it. It’s GPL that stops that because everyone has to get every new feature.
When Slack was first rolling out the dev team in my office of 50 people we all hated it. Thankfully it had an IRC bridge so we could use Slack through IRC. It was seemingly the same experience as before except more business users were in the chat rooms. Once the Corp side of the business were onboard, they dropped IRC support, forcing us to use their clients.
Now it doesn’t matter that rules or laws or privacy invasion they do. They have captured the companies communications and can hold it hostage.
I’ve seen it again and again. When is the last time you downloaded an MP3 file?
CarrotsHaveEars
in reply to SmoothLiquidation • • •Imagine a contributor of the project. He would have been fixing the bug for free and give the work to the public project. Right before he submits the code change, he sees an ad from a big tech bro: "Hiring. Whoever can fix this bug gets this job and a sweet bonus." He hesitated and worked for the company instead.
Now that he is the employee of the company. He can't submit the same bug fix to the open source project because it is now company property. The company's product is bug free, and the open source counterpart remains buggy.
Daniel Quinn
in reply to Zenlix • • •The best example I could point to would be BSD. Unlike Linux, the BSD kernel was BSD (essentially MIT) -licensed. This allowed Apple to take their code and build OSX and a multi-billion dollar company on top of it, giving sweet fuck all back the community they stole from.
That's the moral argument: it enables thievery.
The technical argument is one of practicality. MIT-licensed projects often lead to proprietary projects (see: Apple, Android, Chrome, etc) that use up all the oxygen in an ecosystem and allow one company to dominate where once we had the latitude to use better alternatives.
The GPL is the tool that got us here,
... Show more...The best example I could point to would be BSD. Unlike Linux, the BSD kernel was BSD (essentially MIT) -licensed. This allowed Apple to take their code and build OSX and a multi-billion dollar company on top of it, giving sweet fuck all back the community they stole from.
That's the moral argument: it enables thievery.
The technical argument is one of practicality. MIT-licensed projects often lead to proprietary projects (see: Apple, Android, Chrome, etc) that use up all the oxygen in an ecosystem and allow one company to dominate where once we had the latitude to use better alternatives.
The GPL is the tool that got us here, and it makes these exploitative techbros furious that they can't just steal our shit for their personal profit. We gain nothing by helping them, but stand to lose a great deal.
like this
Nathan likes this.
Zenlix
in reply to Daniel Quinn • • •priapus
in reply to ParetoOptimalDev • • •don't like this
Nathan doesn't like this.
0x0
in reply to Jumuta • • •like this
Nathan likes this.
alphadont
in reply to Jumuta • • •Jumuta
in reply to alphadont • • •pewpew
in reply to Zenlix • • •Rust/Linux
The Ramen Dutchman
in reply to pewpew • • •dukatos
in reply to The Ramen Dutchman • • •Zaemz
in reply to Zenlix • • •The Ramen Dutchman
in reply to Zaemz • • •Mainly memory safety;
split(which is also used for other programs likesort) 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.
0x0
in reply to The Ramen Dutchman • • •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.
ParetoOptimalDev
in reply to 0x0 • • •like this
Nathan likes this.
0x0
in reply to ParetoOptimalDev • • •FTFY
The Ramen Dutchman
in reply to 0x0 • • •To add to @ParetoOptimalDev@lemmy.today
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.
0x0
in reply to Zaemz • • •Communist
in reply to 0x0 • • •Nathan doesn't like this.
ferric_carcinization
in reply to Communist • • •Communist
in reply to ferric_carcinization • • •I don't understand, you'd still have to completely replace the linux kernel for a situation where this matters to occur, no?
and the linux kernel is where 99% of the work is, correct?
ferric_carcinization
in reply to Communist • • •practice of a hardware developer making only a specific version of free software runnable
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)Communist
in reply to ferric_carcinization • • •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
TMP_NKcYUEoM7kXg4qYe
in reply to Communist • • •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
... Show more...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
What is the goal of this project in terms of adoption? · uutils coreutils · Discussion #4358
GitHub0x0
in reply to Communist • • •I seem to recall some drama about rust in the kernel... what could that mean...
unique_hemp
in reply to 0x0 • • •Communist
in reply to 0x0 • • •priapus
in reply to 0x0 • • •ParetoOptimalDev
in reply to Zaemz • • •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.
cyberciti.biz/linux-news/cve-2…
At least this one in a Rust implementation of rsync would have very likely been avoided:
0x0
in reply to ParetoOptimalDev • • •So you prefer closed-source code to potentially unsafe open-source code?
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.
Kusimulkku
in reply to 0x0 • • •ParetoOptimalDev
in reply to 0x0 • • •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.
joel_feila
in reply to Zenlix • • •So i hear that removing all the gnu stuff opens linux to be redistributed with a bew liesinse like mit. Which means its a little more closed iff a little more monitized.
Not knowledge enough on my own to know for sure. If someone with more knowledge could explain.
atzanteol
in reply to joel_feila • • •This is one of the old-time original arguments in the OSS community.
The crux of the matter is that the GNU licenses require that modifications be released back to the community. Other "more permissible" licenses like MIT do not.
So if you want to make a commercial version of X, and X is under a GPL, then any changes you make need to be released under the GPL. The idea being "I shared this code with the community with the intent that you can use it for free and modify it as you like, but you need to share back what you do." Also called "Share and share alike".
This defends against "embrace, extend, extinguish" tactics that companies like Microsoft has loved to do. They can't take your code, modify it for their own purposes and re-sell it possibly making a more popular version that is now proprietary.
LeFantome
in reply to atzanteol • • •Somewhat ironic example.
X (Xorg) has been MT licensed for 40 years. So is Wayland. So is Mesa.
I think Xorg is a good example of the real world risks for something like core utils. If you did not know or care until now that X and Wayland were MIT licensed, you probably do not need to care too much about utils licensing either.
UnityDevice
in reply to LeFantome • • •Here's a better example: the use of GPL software (primarily Linux and busybox) by Linksys when they made their wrt54g router was used to compel them into releasing the source code of the firmware for that router. Subsequent GPL enforcement by the SFC made Cisco release full firmware sources for a whole series of Linksys routers. Thanks to those sources openwrt, ddwrt and several other open source router firmwares developed.
I can now run three openwrt routers in my home purely thanks to the GPL. If those projects had been MIT licensed, Linksys and Cisco could have just politely told everyone to go suck a lemon because they would have had no obligation to release anything.
priapus
in reply to joel_feila • • •Gork
in reply to Zenlix • • •azolus
in reply to Gork • • •DeuxChevaux
in reply to Zenlix • • •The Ramen Dutchman
in reply to DeuxChevaux • • •Also especially not if it turns out to be a bad idea; they explicitly build Mint without Snaps since their inclusion in the Ubuntu base.
Fatur_New
in reply to DeuxChevaux • • •suicidaleggroll
in reply to DeuxChevaux • • •Arehandoro
in reply to Zenlix • • •like this
Nathan likes this.
shirro
in reply to Arehandoro • • •nodiratime
in reply to shirro • • •Alternatively, upgrade your Ubuntu pro to pro-double-plus-good for 10$ p.m.
mystic-macaroni
in reply to Zenlix • • •merthyr1831
in reply to Zenlix • • •My scepticism is that this should've been done within the coreutils project, or at least very closely affiliated. This isn't an area of the linux technical stack that we should tolerate being made distro-specific, especially when the licensing is controlled by a single organisation that famously picks and chooses its interpretation of "FOSS" to suit its profit margins.
On a purely technical level, GNU coreutils should very seriously consider moving to rust if only to counter alternatives before it's too late. While these utilities work well in C (and usually stay secure thanks to the Unix philosophy limiting the project scope), FOSS projects are continuing to struggle with finding new contributors as younger devs are more likely to use modern systems languages like Go and Rust. Not to mention that any project using Rust as a marketing tool will appeal to anyone rightfully concerned about hardening their system.
markstos
in reply to merthyr1831 • • •Drito
in reply to Zenlix • • •ipkpjersi
in reply to Zenlix • • •solardirus
in reply to Zenlix • • •On the one hand, Toybox exists. So, the non-copyleft license bs isn't new. On the other hand, toybox afaik isnt aiming to treat "deviations with GNu as bugs". Almost feels hostile-takeover-ish though I know that almost certinly isn't the idea behindbit.
If this ends in proprietization bs I'm going to throw hands.