I was interested until the website proudly stated that the kernel is not under the GPL, but the weak copyleft MPL. Great, an alternative to the linux kernel for companies to steal, yay...
its five founding companies (AWS, Huawei, Google, Microsoft, and Mozilla).
aka ' the coalition of the shilling'
Our choice of the weak-copyleft MPL license reflects a strategic balance:
Commitment to open-source freedom: We believe that OS kernels are a communal asset that should benefit humanity. The MPL ensures that any alterations to MPL-covered files remain open source, aligning with our vision. Additionally, we do not require contributors to sign a Contributor License Agreement (CLA), preserving their rights and preventing the possibility of their contributions being made closed source.
Accommodating proprietary modules: Recognizing the evolving landscape where large corporations also contribute significantly to open-source, we accommodate the business need for proprietary kernel modules. Unlike GPL, the MPL permits the linking of MPL-covered files with proprietary code.
Wouldn't the LGPL also allow this?
All source code in Rust is statically-linked when compiled, which thereby renders the LGPL no different from the GPL in practice. For Rust, the MPL-2.0 is a better license because it does not have the linking restriction.
Interesting. Is that because the kernel can't load a a module as dylib (I don't know a lot about kernel development) or because dylibs are also somehow statically linked in Rust?
I think it would. Its still a bad idea to allow proprietary modules though. It also allows for EEE shenanigans. I hope they reconsider.
The Linux kernel already allows proprietary modules via DKMS, and a handful of vendors have been using this for decades, so this is no different. Case in point: NVIDIA driver, and Android vendor drivers.
Eww... You're right. What a waste.
I feel you,same thing about redox os.Core and system applications have to under gpl no doubt.
In practice, because Rust libraries are always statically-linked, the MPL-2.0 is equivalent to the LGPL in spirit. Meanwhile, because of the static linking restrictions in the LGPL, the LGPL is effectively no different from the GPL. Hence, you're going to find a lot of open source copyleft projects from the Rust ecosystem preferring either GPL or MPL-2.0, where MPL-2.0 is used in libraries where LGPL would have used previously in C projects. Dynamic linking is essentially going the way of the Dodo.
You could create an issue to address it. I'm not sure why they consider MPL to be a good license for the project. Of course somebody could contact the linux rust contributors and suggest they create another project with GPLv3 or even AGPL.
The website praises it as a superior license that they chose specifically because of the weak copyleft, I doubt I could change their mind
Wouldn't hurt to create the ticket, maybe even it share it here. People who support it can simply put a thumbs up.
Good, this is a great way to direct that energy and help Rust mature without breaking a working OS.
That's the spirit. I see some good arguments for and against Rust in Linux. It's just more complicated than »do it« or »don't do it«.
Well at least this time I'm not getting dogpiled by a bunch of Rust fanatics.
Edit: oh, here they are.
I'm pretty sure Lemmy isn't about having well-reasoned opinions... They need to be strong, and be blasted out there 🤗 I think it's a bit weird that specifically niche Linux topics like Rust, Flatpak and whatever I've discussed here, trigger some emotional responses in some people. I'm more emotional about licensing and freedom. Less so about specific technology stacks. They usually come with objective arguments, and use-cases that change the perspective.
What's ABI? API compatible with linux kernel? EDIT: Never mind, Application binary interface
And what's TCB?
I'm not an expert, but this is what I gather
What’s ABI? API compatible with linux kernel?
Application Binary Interface is the equivalent of an API but at binary level. An API defines for example the functions with their parameters, types, order, and output. An ABI defines how functions are called, how parameters are passed, how output is pass and retrieved, and so on but at a binary level.
An example of an ABI would be for example the Linux Standard Base which makes compiled binaries compatible with linux (how binaries are constructed, where to find data like constants, where to find instructions, and so on). The internal ABI is also important for example how drivers communicate with the kernel.
And what’s TCB?
That, I don't know, unfortunately :/ We need a tech glossary. If I had to guess, it's the Trusted Computing Base?
Linux unplugged (podcast) covered this news pretty well where you get to hear both sides of the case. It's pretty interesting, would defo give it a listen for full story.
The website is state of the art for 2015 +- 15 years.
So it's old and futuristic?
I must say, being able to create, build, and bootstrap your kernel and run it in a VM with 3 commands is pretty cool.
This should've been the linux kernel for years, but instead you have a maze of documentation that makes it very difficult to find how to even build the damn thing, let alone test it. Instead you need to go to other websites like linux.com that explain how to compile it and run it, but mention nothing about VMs.
I don't know how long it'll take for the mailing list and other archaic stuff to be dropped, but it's probably actively hindering contributions to the kernel.
this is very cool.
one of the main issues with a lot of alternate kernels is the driver support. even a really impressive project like Redox is kinda limited to the hardware the maintainers can get their hands on.
Would this support that?
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP