Asterinas: a rust kernel with a linux ABI
Asterinas: a rust kernel with a linux ABI
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...
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©®™
-
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??
Eww... You're right. What a waste.
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?
-
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.
I feel you,same thing about redox os.Core and system applications have to under gpl no doubt.
Good, this is a great way to direct that energy and help Rust mature without breaking a working OS.
The website is state of the art for 2015 +- 15 years.
So it's old and futuristic?
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?