https://asterinas.github.io/
Linux maintainers are unwilling to get rust into the kernel, so some rust folks decided to start writing a new kernel with same ABI. This allows them to make new architectural decisions. An example being their "frame kernel" (something between a monolithic kernel and a microkernel).
If I may say, it's more legible and the tooling is way better, right off the bat.
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...
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.
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.
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.
I feel you,same thing about redox os.Core and system applications have to under gpl no doubt.
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.
I'd love to live in a solarpunk world where intellectual property was abolished. In the meantime, compromises are met and it's no horror at all.
I feel you, but maybe GPL is just an unpopular option (linux kernel never upgraded to v3, only a few oss web apps use affero, etc.)
As much as I love libre software, I have to say that Linux had bad support for drivers because of it, and its mainstream adoption for desktops was hindered for decades because of it. Only today, we celebrate a 5% user share.
An alternative permissive license doesn't immediately mean companies will do the worst. We live under capitalism, perhaps we can't just change that with a license. Their decision might future-proof the project to higher heights that are hardly seen today.
Look at Android, yeah it's a hell of a locked down system when you buy a new phone. But it works quite well, and their user share is at the very top (or second to Apple? Maybe, if you're American). However, Android allows us to have LineageOS and Graphene (which is MIT license, but that's beyond my point, iiuc it could very well be GPL for all of its customizations), and no matter which license these forks(?) use, privacy is preserved and taken to new levels. Meanwhile, Android or any of these alternatives support ARM architecture with great integrated video acceleration that is low power. These are not simply "nice features" but a requirement (e.g. saves energy, improved user experience, competitive to other platforms, etc.) and privacy is not really compromised.
P.s. I'm suprising myself with this comment, nearly 10 years ago I was obsessed with libre software. Today I find it more of a niche hobby, or intellectual challenge. Valuable nonetheless, sure. And hell yeah I'd like to have a linux phone which fully supports all software and hardware... But then, reality.
ok, just a few points from me, typed very quickly because im in a hurry so forgive me if its not very coherent:
the gpl is very popular, its the apgl that has less popularity. The gpl is used by thousands of software projects, and the linux kernel is one of the few projects that did not upgrade to v3, many did, but still, they use the gpl! Thats not an argument against it! Using gplv2 is still fine!
if the linux kernel was more permissive we would absolutely not have better drivers. The linux kernel supports a crazy amount of hardware, a lot more than any other OS! How can you say that support is poor? Bad Drivers are mostly nvidia, broadcom, and chinese vendors that ignore the gpl, and yes, these drivers are bad because they dont want to open source anything(or, my guess, its because of low market share). But imagine that the kernel was MIT. Suddenly, wow, nvidia and broadcom might release more drivers, amazing my laptop wifi card works now! Exept 5 years later the driver breaks in creative ways and broadcom isnt interested in fixing it because its out of support. Proprietary drivers arent the solution to bad drivers, they are bad drivers by their design. its the reson why nvidia drivers are hated, because they are mostly closed binaries so nobody can fix them, and they develop them their way so wayland etc is still buggy. If it was MIT nothing would change in this situation, exept they have more legal possibilities of making badly integrated drivers.
you gave andoid as an example, but that uses the linux kernel? The "good" driver support is kernel modules for the andoid kernel, aka gpl compatible? And support for ARM is good, yes, that is by the way also true for regular linux. And when it is not, its because they didnt mainline their drivers, which is a lot of work and doesnt benefit them apart from goodwill, not because of licensing. What is your argument here?
Do you think that android would have been open source if the gpl didnt force them to?
a permissive license doesnt mean it immediately gets abused. But it does mean that abuse is possible, and it does happen. I dont want to live in a world where the best linux is microsoft© linux™ which has ads and their own packages, which are for some reason, incompatible with free linuxes because of extra features in microlinux©®™
I'm absolutely with you on point 5. As for the rest, I will have to admit that I may have said some things plain wrong. I'm just trying to drive the point that it's not inmoral and people should be happy anyway. Perhaps in 10 years this is the OS we are all using on our desktops, phones, and wearables. It would be a pity that's not GPL and it has ads, sure (like maybe Android on x-brand flagship mew phone). But we could then have the LineageOS version of this. And I'd be happy. My poiny being, if that happens (it turns out to be the biggest OS), it will be thanks to its license, allowing it to be a thing for both people, and companies.
Oh.. I just saw your point. I'm comparing to Android (LineageOS) when it should be to iOS... void
Well, then this news are just sad.
Eh? I daily drive only FOSS software with basically no problems, the only exception I make is for firmware and JS, firmware because it's realistically not a choice and JS because it's extremely sandboxed and I use librewolf with container tabs to isolate cookies etc cross sites, even drivers are not exempt from this rule. FOSS specifically being programs under a GNU approved free software license or software found in the Debian main repos and therefore complying with the DFSG. It's, surprisingly easy. In fact when I made the decision to do this it was primarily because I needed so little proprietary software that it just wasn't even much of a challenge?? I guess my main point in saying this is I don't get where you're coming from, I'd love a Linux phone but it's not realistic there, but on the desktop? It's extremely realistic??
Linux made huge strides in the last years. But if we go back 10 years, or 15 things were quite bleak. And there are many reasons to that. It's license is one. That's my point. Correct or not, okay.
And Linux never embraced GPLv3 for reasons that are in common probably as to why this project chose a permissive license. So, I think we should all support them in that regard.
The decision not to support GPLv3 makes sense and I understand Linus' perspective on that. GPLv3 branched out into something beyond traditional copy left by ensuring that users can run the modified code by restricting hardware design. That's a separate thing. I disagree with the decision to go with a permissive license in most cases including this one. Permissive licensing leads to the problems the BSDs have with companies like Sony taking the code and running with it without giving back and it's why I prefer strong copy left licenses like GPLv2 or v3.
One other thing, yes it was rough in the past but now due to the massive market penetration Linux has we have a large swath of GPLv2 drivers making it far less of a relevant issue.
We can't really know if BSD "lost" a sell to Sony. Right? I ask sincerely, maybe there's more to the case you cited.
From my naïve view, this new project can win new associated companies and get some income to pay new devs when some maturity is achieved on this framework since it's quite innovative and those companies can really participate whereas with a GPL they would just be left out.
I only mean to say that we might be discussing if the glass is half empty or half full. That's why I'm trying to put into this new perspective (like considering GrapheneOS as an example. In the long run, the license might not be that much of a hurdle. At least let's hope that's the case since they probably won't change to GPL.
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.
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?