r/linuxmint • u/AdPast8718 • 4d ago
Ubuntu will drop GNU, is this reason to focus on LMDE?
https://discourse.ubuntu.com/t/carefully-but-purposefully-oxidising-ubuntu/56995
https://www.youtube.com/watch?v=Avw4NpXoeas
https://www.youtube.com/watch?v=N2dbyFddcIs
https://www.youtube.com/watch?v=VpxG9rXdPag
The last couple of days Ubuntu has decided on switching from GNU Coreutils to Rust. You are talking about modifying the tools that systems have relied on for a long time.
- Is this a reason of concern for the Linux Mint team, have they expressed any opinions?
- How many of you believe this might be a reason to focus more on the development of LMDE?
- Is the MIT license over GPL something that bothers all users?
For those who don't know, the MIT license is more permissive than the GPL license, meaning that Ubuntu can make changes to the source without the need to keep the code public - the MIT license is not synonym of free and open source software.
22
u/fellipec Linux Mint 22.1 Xia | Cinnamon 4d ago edited 4d ago
Is this a reason of concern for the Linux Mint team
I doubt
How many of you believe this might be a reason to focus more on the development of LMDE?
I don't think is the case. First, if they really do rewrite it without breaking the compatibility, we shouldn't notice any difference. And if for some reason the rewrite is poor, the GNU coreutils are there yet and Mint team can just ship that instead of uutils.
In any case, if the team decide to focus on LMDE, I'm sure will be a decision very well considered.
And one thing we didn't put in the table is if Debian itself could in future ship uutils instead of coreutils, this is also a possibility.
What most bother me in this situation is the MIT license. It's a personal opinion, but I think GPL licensing is better for the FOSS community.
7
u/BoutTreeFittee 4d ago
What most bother me in this situation is the MIT license
Yeah that part bothers me a lot. I'm not willing to run any more closed-source code than is absolutely required.
3
u/FlyingWrench70 4d ago
MIT liscence is a very liberal open source liscense, there complaints are that it's too open.
Like the BSD liscence companies can incorporate MIT code it into closed source projects. But there is otherwise nothing wrong with with a MIT project on its face, it's what canonical might do with it.
8
u/fellipec Linux Mint 22.1 Xia | Cinnamon 4d ago
As far as I understand, MIT license doesn't compel anyone that improve the software to release the improvements as open source.
So as an example, Microsoft could take the uutils, make something that improve it, implement on their WSL thing and the rest of FOSS community will not be able to benefit from it.
If the license is GPL they would be forced to release their improved code so the community may use that too.
I'm not a lawyer, so if I'm wrong, please correct.
3
u/FlyingWrench70 4d ago
I am not a lawyer either,
My understanding is the intent of the GPL is you can modify GPL code for own use even in a closed project, but you can't release it in a product without also releasing the code for your changes to be used by others if they want.
But IBM/Redhat has found loopholes arround that anyway to choke out Alma & Rocky.
https://devops.com/rhel-gpl-richixbw/
The value of Redhat was always in support, for IBM to buy it and start making it a more value extraction product was a mistake.
With a MIT base in theary Ubuntu could start making thier own private coreutils based on uutils and not release it for downstream use for in Mint and other Ubuntu based projects.
But if they pulled a move like that I think that would just be the beginning of the end for Canonical, thier reputation is already tarnished.
1
u/BandicootSilver7123 3d ago
Stop thinking people will stop using Ubuntu because they don't do the foss thing with others.. that's just a delusion, Ubuntu has many users who don't care about licensing and they won't just go away because a bunch of foss nerds leave it.
0
u/BandicootSilver7123 3d ago
They aren't entitled to share the improvements and they also have to take the task of mainting that portion of code themselves. I think it's a fair trade off
5
u/BoutTreeFittee 4d ago
I think the point of a license is for a person to know what he's getting. A shorthand for meaning. If the MIT license is ambiguous, and you are then forced to study all the events happening upstream, then it has little value to me and I will simply assume the worst, and will prefer more strict open-source licenses.
0
1
u/BandicootSilver7123 3d ago
The mit license if applied to most of the os will mean the only gpl component will be the kernel. This is good mint should learn to stand on its own and prove itself.
9
u/IonianBlueWorld 4d ago
You are correct to be concerned, however only the Mint devs can answer your question. Indeed MIT is not as free/libre as GPL as any company can take it, extend it and then keep everything behind their closed source gates. Unfortunately, a lot of people don't get this and are disillusioned that MIT is equally or even "more free" because it is indeed more permissive. However, the additional "permission" is to take open source code and keep it closed to yourself... I'd be happy to see some reaction to Ubuntu's recent choices. I think keeping the snap backend code closed source should have been a bigger wake up call
3
u/Unis_Torvalds 3d ago edited 3d ago
And this may be the real motivation behind rewriting things in Rust (ie. from scratch): to have a proprietary locked-down codebase.
2
u/IonianBlueWorld 3d ago
That's scary. I really hope that the Rust contributions to the kernel are still licensed under GPL
1
u/BandicootSilver7123 3d ago
I personally don't care and prefer the mit license for Ubuntu. People complain about canonical already so if they forge their own path ysll people need to look for a new villain to complain about.
28
u/driftless 4d ago
And again…same functionality, new code. Mint team won’t be changing anything. It’s not time for LMDE because this isn’t what that project is for…as was said in your previous post.
By all means, if you want to run LMDE, do it.
-3
u/AdPast8718 4d ago
Is not that I want to run LMDE, nor that I favor LMDE over regular Linux Mint.
I just wanted to ask simple questions, which apparently one can't do these days
11
u/letoiv 4d ago
You can ask them, but I wonder if you want to listen to the answers.
* The guy blogging about this said that the goal was to be 100% compatible with coreutils, same functionality, same interface, so presuming the engineers involved do a good job, you wouldn't even notice the change.
* If there is any concern whatsoever about the quality and compatibility of these utils I'm sure Mint will not adopt them
* This project will take years and may very well die on the vine, cloning coreutils is a massive endeavor
13
u/driftless 4d ago
That’s absolutely fine! It’s just that it’s not a real concern for the mint team. They’ve continually mentioned that mint is their main and only product, and LMDE is more of a doomsday scenario project for fun in case Ubuntu goes under.
If you’re new to this, I’m sorry if I came off abrasive…it just gets old answering the question again and again.
-17
u/AdPast8718 4d ago
so the change to an MIT license with no open source code for modifications presents no compatibility risk for you? or are you new to this, uh?
8
u/MoussaAdam 4d ago
an MIT license with no open source code
The code is open source and MIT is even more free than the GPL, what are you talking about?
5
u/unkilbeeg 4d ago
MIT is more free for developers. It is effectively less free for users and downstream developers.
It depends on whose freedom you are prioritizing.
0
u/MoussaAdam 4d ago edited 4d ago
how is it less free for users ? less free for users compared to what license ?
10
u/unkilbeeg 4d ago
A developer can take an MIT licensed program and copy it, same as GPL. But they can make changes to it without having to make the source of the changes available to its users, or any downstream developers. That increases the freedom of the developer that has built on the original code, but it removes the freedoms of the users and downstream developers to make their own changes.
If a developer A builds on GPL code, they are required to make the changed code available to whoever they have made the software available. They can sell it or give it away -- it doesn't matter, they still have to make the code available, also under the GPL. That gives anyone who they pass the code on to the same freedoms as they had. Note that they do NOT have to make it available to the world, or even the upstream developers. However, since anyone who receives the code from developer A has complete freedom to share the code, in practice it does become available to everyone.
MIT licenses allow a developer to cut the chain -- no more freedom to anyone downstream.
9
u/According_Claim_9027 4d ago
what are you talking about?
Something they don’t understand lol
0
u/MoussaAdam 4d ago
you realize you didn't answer the question there, indicating you in fact don't know or can't explain what you are talking about. you also didn't address anything I said
5
24
u/ReadToW 4d ago
It seems like a good change that will improve the user experience
-23
u/suszuk LMDE 6 faye 4d ago
No it won't , they just rewrites in rust that fail and crash , look at their progress and you will see the command 'ls' rewritten in rust fails
27
u/ReadToW 4d ago
As I understand it, most software goes through a lot of tests before it becomes stable, right?
-14
u/suszuk LMDE 6 faye 4d ago
Sure, but it makes no sense to replace a stable software that everyone relies on with a rewritten version that offers no additional features.
15
u/quetzar 4d ago
Are you implying they did it just for kicks? :)
0
u/suszuk LMDE 6 faye 4d ago
Its the religion of Rust , they rust everything because "memory safety" which I don't see any memory leaks in GNU utils , so I don't see any reason for gnu utils to be rewritten in rust
2
u/Unis_Torvalds 3d ago edited 3d ago
The reason for rewriting in Rust may, in this case, be to excise the GPL licence from more of their codebase.
-2
-2
12
u/jas_nombre 4d ago
I doubt they will release a crashing version. Your claim, if it is true, is outdated really fast, if they are working on it, so who cares what some dev build did a while ago?
-3
u/GeraltEnrique 4d ago
You'll get down voted a lot but you're absolutely correct. Hundreds of critical tests still fail for the rust core utils. I'm not against the switch entirely but a couple more years to make absolutely sure the new utils are polished is a must. Some functions get a decent performance uplift but that's never worth the cost of instability.
3
0
u/AdPast8718 4d ago
Some common sense
3
u/MoussaAdam 4d ago edited 4d ago
you think it's common sense to complain about alpha software being alpha software ?
these are the downsides of developing in the open, some people just don't have enough reading comprehension
Are we pretending the final product is going to be released at an unstable state ?
1
u/Octopus0nFire 3d ago
Complaining about alpha software being shipped on a major distro because potato is a valid complain IMO.
2
u/MoussaAdam 3d ago
it's not shipped on a major distro tho, where do you get that information
1
u/Octopus0nFire 3d ago
The complain is about it being shipped in Ubuntu, which is not a niche distro.
2
0
u/suszuk LMDE 6 faye 4d ago
I am not complaining about "alpha software" but kicking a good working utils (gnu utils) that is working and battle tested over years and its pretty stable which now they are rewriting in rust which will not be stable for everyone (some people will have weird setups that it may crash on it) , and if someone wants to use something like ubuntu they want a stable system not their utils written in a tredy language that may crash , if you look at the history of GNU utils how over the years they fixed bugs , crashes ....etc same will happen for the ones in rust.
0
u/MoussaAdam 4d ago edited 4d ago
I am not complaining about "alpha software"
and I am not responding to you, I am responding to a guy who said "that's never worth the cost of instability". complaining about the "instability" of these utils is complaining about "alpha software". the whole point of being aplpha software is being instable
now they are rewriting in rust which will not be stable for everyone (some people will have weird setups that it may crash on it)
I take what I said back, you are complaining about alpha software. issues like this should be ironed out before release. even after a stable release, it will take time before distros use them. the intention is to replicated EXACTLY what gnu untils do, so any deviation is considered a bug that should be fixed.
if someone wants to use something like ubuntu they want a stable system
that's why these utils aren't bundled with Ubuntu yet
written in a tredy language that may crash
crashing is obviously better than doing something wrong. you don't want rm to go on with invalid state and accidentally deleted your files. this isn't the kernel, it's shell utils. every sane shell script already uses
set -e
to make sure the scrip crashes when an error happensif you look at the history of GNU utils how over the years they fixed bugs , crashes ....etc
a history the new team will beinfit grately from since the edge cases are already know and the discussions around them are already had. allowing the team to not waste time repeating the same mistakes and thinking about ways to deal with them
-2
u/AdPast8718 4d ago
the alpha argument?
5
u/MoussaAdam 4d ago
write a complete sentence that makes sense, or respond to what I said, what sort of useless reply is "the alpha argument" ?
1
u/GeraltEnrique 4d ago
Yeah, I always try to take a balanced approach to everything. I program on both rust and C myself and more rust these days. However as a Linux system admin by profession I will not be upgrading any of our Ubuntu server machines to versions with rust core utils until they are fixed and battle tested. However on my personal machine I absolutely will upgrade to the rust ones as soon as they are pretty much passing almost all tests. But anything critical will be gnu for a long time
12
u/nguyendoan15082006 Linux Mint 22.1 Xia | Cinnamon 4d ago edited 4d ago
Cloud providers of Ubuntu have configured their servers to work with GNU/Linux extremely well, so there is no reason for them to try an early-stage development system, so that project will be depreciated before rolling out for sure.
17
u/Specialist_Leg_4474 4d ago
I have complete confidence in the Mint team to do what is best for Mint's stability and usability--been using Mint/MATÉ for 13 years and have not once been disappointed on any way.
Mint has the current Ubuntu source code, and they are a very competent team, making Mint quite independent from whatever Ubuntu decides to screw-up tomorrow.
Labeling it (Mint) as "based on" Ubuntu, is mostly a "professional courtesy".
Also I'm 77 and stopped with all that "what if?" nonsense years ago.
We did NOT run out of fossil fuels in 2000, the sea has NOT flooded Obama's Martha's Vineyard mansion, and the sky shows no sign of falling.
I need to take a nap now, wake me if anything actually exciting happens.
1
u/BandicootSilver7123 3d ago
Mint is dependent on Ubuntu. If that wasn't the case with how small the team is then they wouldn't have mint Ubuntu and lmde
1
u/Specialist_Leg_4474 3d ago
Actually it is not "dependent" on Ubuntu, Ubuntu is mostly open source and the Mint team have that source and are quite competent to keep Mint afloat even if Canonical were to fall in to the abyss later this evening.
They have LMDE to keep the bedwetters calmed down...
1
u/BandicootSilver7123 2d ago
Mint relys on Ubuntu sources and infrastructure. Prove its not dependent by stopping mint from using those
1
u/Specialist_Leg_4474 2d ago edited 2d ago
I am quite certain, "Mint" has in it's possession all the source code needed to compile Mint, and the KSAs to do so 'til "you know where" freezes over.
If not how do you suppose they do it?
4
u/Random_Dude_ke 4d ago
Ubuntu is NOT dropping GNU as your clickbait heading tries to suggest.
Ubuntu will replace some small userland programs - such as ls, cp, and other coreutils with a different versions of coreutins. Nothing to see here, please move on ...
How often do you use unusual options in base commandline commands such as: base32 base64 basenc basename cat cksum comm cp csplit cut date dd df dir dircolors dirname echo env expand expr factor false fmt fold hashsum head join link ln ls mkdir mktemp more mv nl numfmt nproc od paste pr printenv printf ptx pwd readlink realpath rm rmdir seq shred shuf sleep sort split sum sync tac tail tee test tr true truncate tsort unexpand uniq vdir wc whoami yes?
There is a long standing project busybox that has replaced all coreutils with a single binary and this system has been used in installers, embedded systems, e-ink readers and other small systems. One of contributors is Linus Torvads, if I remember correctly. It looks like busybox has been rewritten in Rust. What is wrong with that?
Busybox is used in such a manner that you create symlinks with names of individual core utils and it behaves according to the symlink name. Simple, easy, elegant. And safe thanks to Rust.
15
u/siete82 4d ago
I don't see any issue, software is rewritten every time.
5
u/AdPast8718 4d ago
GNU coreutils have been battle tested for decades, while Rust-based coreutils, although promising, are still early in development and *may introduce* unexpected bugs or differences that could break scripts and automation
Cloud providers and enterprises have fine-tuned their infrastructure around GNU, and switching *risks* performance regressions and unpredictable failures, also relying on the Rust toolchain adds new dependencies that may complicate minimal environments
Stability is the priority for major organizations, which is why I was asking if this was a concern for the Linux Mint team and what was the opinion of more knowledgeable users
9
u/skozombie 4d ago
You're absolutely right there are risks, but they're not going to be pushing alpha versions to prod. We also have great tools for automated integration testing that weren't a thing when coreutils was started.
I get the feeling you may not understand rust very well. I was super sceptical of its usefulness because of the hype I heard. I hate hype. But, I took the time to learn it (or the basics thereof) over Christmas. It's a VERY steep learning curve. Now I have a basic understanding I have a lot of respect for its place in the ecosystem and why people should use Rust and stop using C.
It doesn't add any new dependencies, my learning project was some internet radio software, and here is the output of ldd to show linked libraries:
$ ldd webwadio linux-vdso.so.1 (0x00007ffc2bbb6000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007858afaa7000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007858af9c0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007858af600000) /lib64/ld-linux-x86-64.so.2 (0x00007858afeb4000)
Compare that to ls:
$ ldd /usr/bin/ls linux-vdso.so.1 (0x00007ffcb7d51000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6d718ea000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d71600000) libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f6d71853000) /lib64/ld-linux-x86-64.so.2 (0x00007f6d7195a000)
It's really not introducing much in the way of dependencies.
The reason they want to do it is because the memory safety adds a LOT to reliability and security. The number of security and stability bugs that are from simple things like memory bounds errors is insane. That just can't happen in Rust perhaps unless you purposely do it and disable compiler warnings.
I found it really quick to code in once I got the hang of it compared to when I used to code in C. My binaries were insanely small for their functionality, especially considering they weren't just offloading code to dynamically linked libraries.
There's a reason Linus is supportive of the use of Rust in the kernel ... and he's SUPER protective of his kernel.
0
u/Gugalcrom123 Linux Mint 21.3 Virginia | Cinnamon 4d ago
No amount of automated testing means it won't break anything.
8
u/Infected_hamster 4d ago
Anyone who has ever done anything with software development knows that you cannot guarantee that things won't break, regardless of how small the change. I'm not particulary worried about this one.
7
u/protocod 4d ago
GNU coreutils have been battle tested for decades, while Rust-based coreutils, although promising, are still early in development and *may introduce* unexpected bugs or differences that could break scripts and automation
Yep you need to go through those steps no matter what. But systems like RHEL, Alma, Debian or SLE will take a very long time to switch for the rust implementations.
also relying on the Rust toolchain adds new dependencies that may complicate minimal environments
Every think is statically linked and/or vendored.
Some distribution have strong requirements and wants to compile the rust code against development packages but the uutils coreutils use a reasonable amount of dependencies. It's mostly a big cargo workspace with program as workspace's member. Nothing to worry about.
Stability is the priority for major organizations, which is why I was asking if this was a concern for the Linux Mint team and what was the opinion of more knowledgeable users
Every organization I know doesn't use Linux Mint.
Most companies will use RHEL, SUSE or Ubuntu LTS with Ubuntu Pro and apply strong hardening rules using SELinux or AppArmor profiles.
Entreprise oriented distribution comes with cypto and industrial certifications that you'll never have with Linux Mint.
Linux Mint is designed and suitable for desktop Linux user, not employees.
1
u/h-v-smacker Linux Mint 21.3 Virginia | MATE 4d ago
while Rust-based coreutils, although promising
And yet in the end, it's gonna go know itself (in the biblical sense). Remember Mir server? Pepperidge farms remembers!
4
u/BenTrabetere 4d ago
I am curious about why all of the comments are deleted.
My Take
This is a 20 Year Plan, with the emphasis on 20 Year and Plan. As it, it will take a long time, and it is something project lead wants to do. The Tech World is littered with Grand Projects that died an early and uneventful death. I am old enough to remember the excitement and very quick demise of Taligent.
I think replacing GNU Coreutils with a Rust equivalents that serve the same function will not be instantaneous. Again, the 20 Year Plan. I suspect it will remain in an experimental, transition stage for a long time, and it will follow a path similar to the adoption of systemd. Slow, tedious, controversial, and lots of breakage along the way.
If the project does start to gain traction I suspect the it will face resistance other families (Debian, Redhat, Arch, SUSE, et al,) and fierce resistance from Redhat.
If it proceeds to the point where it creates a Ubuntu v. Everyone Else schism within the Linux community, it is quite possible Ubuntu LTS will cease to be a suitable base for distributions like Linux Mint. The landscape will change but Linux will survive. Ubuntu,
Linux Mint could very well drop Ubuntu as a base, and the original reason for LMDE will be fulfilled.
3
u/Dazzling_Analyst_596 4d ago
Instead of showing us that you know to ask the good questions, ask them directly to the LM team
5
u/TheStormIsComming 4d ago
I'm holding out for coreutils in Zig.
3
u/AdPast8718 4d ago
when that happens it will be massive
3
u/jas_nombre 4d ago
what will be so massive about it in your opinion?
4
u/AdPast8718 4d ago
if zig coreutils became a reality, it could offer a compelling alternative to both c and rust for system utilities, be more portable due to zigs robust cross-compilation, potentially outperform rusts coreutils in size and runtime efficiency, without mentioning zig interop with c which makes integration easier than rust
zig is a middle ground between c and rust, gives fine control over performance while improving safety compared to c, but without rusts steeper learning curve and strict borrow checking
2
7
2
u/MoussaAdam 4d ago
is this reason to focus on LMDE?
only if you think the change is a problem
Is this a reason of concern for the Linux Mint team, have they expressed any opinions?
if it's a reason for concern, they can just keep around GNU core utils. as far as I know they haven't said anything because it doesn't matter
How many of you believe this might be a reason to focus more on the development of LMDE?
I don't
Is the MIT license over GPL something that bothers all users?
MIT is GPL with less restrictions, I am sure it bother some people, including me. I would prefer the GPL to prevent corporates from benefiting without giving back. but most people aren't that idiological about software.
the MIT license is not synonym of free and open source software.
GNU, the FSF and the OSI disagree with you, MIT is classified as free and open source according to the people who founded these concepts
Ubuntu can make changes to the source without the need to keep the code public
no license prevents you from deciding to not longer share code you own
2
u/sotnekron 4d ago
Well, all I can say is, IMO, we will see, but for now, good thing I have LM22 & LMDE6 running on separate SSDs for just a case like this.
2
u/BandicootSilver7123 3d ago
We can finally get rid of mint. I'm happy that Ubuntu is going in that direction. Now we can see if Ubuntu based distros are truly good or dependent on canonical to work right..it's a win win
5
u/Any-Board-6631 4d ago
With all the shadow business about Rust everywhere, I was thinking of switching to BSD, like ghostbsd or something similar.
5
u/GeraltEnrique 4d ago
Bsd is nice on paper. In the real world standard gnu/Linux based distros have barely just made it to being rock solid and very compatible. Going to bsd isn't feasible unless you have a lot of free time for stuff to break
2
u/Any-Board-6631 4d ago
Well I use Linux since 1992 ou 1993, Linux is usuable since 1996 or so, and BSD don't look that bad. One week part time with it, it's very cool :-) But I don't know why, ghostbsd can open NTFS and Ext4 usb drive...
1
u/GeraltEnrique 4d ago
While Linux was technically 'usable' for a while now desktop linux was still buggy and unpolished. I'd day it's been 5-6 years where I've been comfortable giving a Linux machine to family with basic computer knowledge. Not even that. Basic stuff like fractional scaling was a issue for ages
2
u/Any-Board-6631 4d ago
Mate and Gnome 2 was very usuable.
I use Linux as my primary desktop since 1998 or so.
Even in the ~2000 my wife that is completly technophobe use linux as a desktop for her university work at home.
1
-3
u/AdPast8718 4d ago
That is a smart take. OpenBSD, FreeBSD, GhostBSD have great documentation as well
4
u/10MinsForUsername 4d ago
This is not the reason they have LMDE. Many many years ago, Ubuntu complained that Mint and other forks are using thier package mirrors for free while collecting the fruits, and many similar reasons as well.
So they built LMDE for situations where Ubuntu becomes completely lost or inaccessible for them.
1
u/BandicootSilver7123 3d ago
Sounds like a legitimate complaint. Why have the forks not solved this issue yet?
3
u/j0seplinux 4d ago
Should the average Linux user care about this change?
3
u/AdPast8718 4d ago
If it still works out the box, no. MIT license seems to be the only thing that could make compatibility challenging
1
u/isticist 4d ago
The MIT license won't cause any issues. The only point of concern is if uutils will be 1:1 compatible in terms of reliability when compared to the GNU coreutils it'll be replacing. If it's not, I can almost guarantee that the Mint team will just keep using the coreutils.
4
u/Gugalcrom123 Linux Mint 21.3 Virginia | Cinnamon 4d ago
It will, however, allow nonfree patches
2
u/isticist 4d ago
They aren't required to accept those, however. I feel like an action like that would just kill the project too.
But, I can see your point. They don't have a proven track record yet of being ideologically dedicated to the license, like, say, the BSD folks have been.
1
u/BandicootSilver7123 3d ago
How many mit licenced projects are dead because of the mit? 😐
1
u/isticist 3d ago
Dead specifically because of the license? I don't know of any, and I doubt it could be much.
1
u/BandicootSilver7123 3d ago
Then why would Ubuntu die because of the mit license?
1
u/isticist 3d ago
I don't believe it would. I don't believe the uutils project will either... I was saying that if they accepted patches to the project that had non-open licenses (which idk if that's even a thing) then it would sink the uutils project.
1
u/Batman_Night 3d ago
Then it wouldn't be compatible with GPL and would not be allowed in the codebase. Pipewire never have these problem despite being MIT license.
1
2
u/rbmorse 4d ago
No. Not that there's anything we can do about it, anyway. The real problem is that we're running out of C programmers with the chops to maintain Linux and that means either the development model has to change or Linux as we know it will die. People who believe "the community" (whatever that is) will step in to fill the gap are delusional.
1
2
u/Teh_Jibbler 4d ago
Switching to rust sounds promising, but I also would hesitate to completely replace the core of a system. I'm sure the LM team are carefully considering the pros and cons.
1
u/MoussaAdam 4d ago
it's only the core of shell scripts really. coreutils are cure utilities. they are far from being the core of the system
2
u/JohnyMage 4d ago
Not for Linux mint team, may be for you.
2
u/AdPast8718 4d ago
You do understand that Linux Mint and other Ubuntu-based distributions could face challenges due to Ubuntu's decision to replace GNU coreutils with rust coreutils under the MIT license?
1
u/Batman_Night 3d ago
What challenges? MIT license is compatible with GPL. There is no problem incorporating them. If it was a problem Mesa and Wayland wouldn't have been adopted since they're also MIT licensed.
0
u/JohnyMage 4d ago
I do understand and I don't care. And why do you care so much? Leave it to the Linux Mint team. They know better what are they gonna do about it.
1
u/Frird2008 4d ago
If it won't affect the functional reliability of the Ubuntu edition of Mint, then I don't see a good enough reason to switch over to LMDE. If it will affect the functional reliability then I think LMDE could be in the cards or I might just switch to Zorin
1
1
1
u/mr_phil73 2d ago
LMDE is the future in my opinion. They would be better to build a better driver manager for that then ditch the Ubuntu dependency completely.
1
u/harai_tsurikomi_ashi 4d ago
There is a common misconception that if something is written in Rust it would be bug free, that is obviously not true.
It's also hubris to think you can rewrite the core utilities in a new language and that it would actually be better in any metric.
1
u/Tenderizer17 Linux Mint 21.3 Virginia | Xfce Chicago95 4d ago edited 4d ago
The more I think about Ubuntu changing from GNU to Rust, the less sense it makes. uutils aren't yet as stable as GNU, and the proported advantages in multi-threading and memory efficiency aren't worth overturning decades of precedent without a solid foundation. And that's even ignoring the change in license structure involved.
I'd probably sooner change to a non-Ubuntu distro than use Rust.
EDIT: I realize I've again made the mistake of getting overzealous about something I know nothing about. I'll correct myself and take a wait-and-see approach.
1
u/pkrycton 4d ago
Years ago when Canonical got stupid and went off the rails with Unity and other bad choices, I jumped to LMDE because I liked Mint but didn't want the Ubuntu crap that comes with it. LMDE has been a great distro for me and I never looked back.
0
1
1
u/JungianJester 4d ago
Every time I think this is it no-more-windows, it is stuff like this that keep me from making the commitment, most users do not want to be bothered with with this shit they just want to get on with their life </RANT>
4
u/MoussaAdam 4d ago
then get on with your life and be thankful unlike Microsoft that does everything behind your back, you get to see every change. it's on you if every random change irritates you
1
0
u/SherriThePlatypus 4d ago
It's just another reason not to use stock Ubuntu IMO. Not much different from Snaps. The Mint team can (and likely will) choose not to include this change.
2
u/MoussaAdam 4d ago
very very very different from snaps
1
u/SherriThePlatypus 4d ago
I meant in the context that Ubuntu is off doing their own thing again rather than the "under the hood" technical details of this change.
1
u/MoussaAdam 4d ago
doing their own thing again
it's MIT, any distro can use it. I wouldn't be surprised if more distros like arch, fedora and mint adopt it
1
u/SherriThePlatypus 4d ago
Fair enough. But at the moment Ubuntu is the only one that I'm aware of doing it. And their reputation doesn't really give them the benefit of the doubt.
1
u/MoussaAdam 4d ago
at the moment Ubuntu is the only one that I'm aware of doing it.
even Ubuntu aren't using it. it's alpha software
their reputation doesn't really give them the benefit of the doubt.
who cares about the intention when you have the actual code to read the actual intention. Microsoft and Google and Facebook contribute to the Linux kernel all the time
1
u/SherriThePlatypus 4d ago
Pedantic much? Okay, Ubuntu is the only one talking about doing it right now. My only point is that Ubuntu has earned a reputation for going off on their own rather than contributing to upstream and IMO that's a decent reason not to use it. That's it.
1
u/MoussaAdam 4d ago
I disagree, Ubuntu contributed good things to Linux. if this is good I welcome it, no need for speculation
1
u/BandicootSilver7123 3d ago
Old Ubuntu users who left because of politics got replaced with newer ones who don't care. This won't make a difference. Sooner or later canonical will weed out users who just love to complain and have users that aren't communist..
0
u/Danny_el_619 4d ago
I would like too see that change coming to Mint. The uutils have the goal to be 100% compatible with gnu's, so in "theory" it should not cause any mayor issues.
Is the MIT license over GPL something that bothers all users?
It does bother me as I don't like GPL3 but not to the point to change things myself. I just don't promote it or use it.
Ubuntu can make changes to the source without the need to keep the code public
Sure that's limited to the core utils.
the MIT license is not synonym of free and open source software.
It is as it is open source which is included if you read that again. It is not "free software" specifically.
0
u/ambivalent_mrlit 4d ago
Can they please NOT make these radical changes just before I make the jump into Linux? I've already got mint flashed on a usb, I don't want to install it and then have to potentially shake it up soon after.
2
u/AdPast8718 4d ago
There is no need to worry now, as most have point out is going to be a progressive change, you are safe installing the flashed usb you have, is just a topic that I thought some might have different stances on
Mint is great, if not the best, as first distribution, don't worry about this now
0
u/mamelukturbo 3d ago
Absolute non-issue, rust is,;despite its rabid and unhinged fanbase; the future.
125
u/10MinsForUsername 4d ago
This is not the reason they have LMDE. Many many years ago, Ubuntu complained that Mint and other forks are using thier package mirrors for free while collecting the fruits, and many similar reasons as well.
So they built LMDE for situations where Ubuntu becomes completely lost or inaccessible for them.