Earlier quoted context omitted.
This should be the sort of red flag to take note of. There’s an LLVM fork for every esoteric architecture now and this sort of thinking will lead to never being able to run your own software on your own hardware again. A reversion to the dark ages of computing.
Seriously. To the author: kudos for the interesting project, but please strongly consider a copyleft license moving forward.
Moss: a Rust Linux-compatible kernel in 26,000 lines of code
101–110 of 163 posts
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#102Earlier quoted context omitted.
MIT licensed code is a gift. A gift indeed doesn't require the recipient to give back anything related to the gift. A "gift" requiring GPL-like conditions isn't really a gift in the common sense. It's more like a contractual agreement with something provided and specific, non-negotiable obligations. They're giving while also asserting control over others' lives, hoping for a specific outcome. That's not just a gift.…
MIT is throwing a free party where food and drinks are paid for, and copyleft is where food is paid for but you BYOB. Both are fine, so what's the problem?
Here, I'll make a substantive contribution. I hope this succeeds and causes a lowest-common denominator Linux ABI to exist that user-land can target, thus freeing us all from the Linux kernel as the only viable option. Solaris/Illumos, the BSDs, and even Windows have all gone through one or two phases of attempting Linux ABI compatibility, ultimately giving up because the Linux ABI is such a fast-moving and underdocumented target.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#103Earlier quoted context omitted.
Love the MIT license. If this were further along we could use this as the foundation of our business without having to "give back" device drivers and other things.
MIT licensed code is a gift. A gift indeed doesn't require the recipient to give back anything related to the gift. A "gift" requiring GPL-like conditions isn't really a gift in the common sense. It's more like a contractual agreement with something provided and specific, non-negotiable obligations. They're giving while also asserting control over others' lives, hoping for a specific outcome. That's not just a gift.…
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#104Earlier quoted context omitted.
What is a "pushover" license?
Permissive license + complaining when companies don't contribute back from their forks.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#105Very cool project! I do have to admit - looking far, far into the future - I am a bit scared of a Linux ABI-compatible kernel with an MIT license.
What's the threat? Solaris/Illumos, the BSDs, even Windows, have all tried -sometimes more than once- to be compatible with the Linux ABI, and in the end they've all given up because the Linux ABI evolves way too fast to keep up and is underdocumented. Someday someone -perhaps TFA- will succeed in building momentum for a well-defined and highly functional least common denominator subset of the Linux ABI, and that will be a very good thing (IMO) regardless of their choice of license.
I guess you imagine that everyone will switch to Moss and oh-noes!-everyone-will-be-free-to-not-contribute-back!! So what?
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#106Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#107Hello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has…
Love the MIT license. If this were further along we could use this as the foundation of our business without having to "give back" device drivers and other things.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#108Earlier quoted context omitted.
I’m aware; you’re not adding new information. I think you’re handwaving the difficulty of implementing work stealing in the kernel (interrupts and whatnot) + the mechanics of suspending/resuming the calling thread which isn’t as simple within the kernel as it is in userspace. eg you have to save all the register state at a minimum but it has to be integrated into the scheduler because the suspension has to pick a nex…
No. I am adding new information but I think you are stuck on your initial idea. There's no work stealing. Async-await is cooperative multitasking. There is no suspending or resuming a calling thread. There is no saving register state. There is not even a thread. I will re-reiterate: async-await is just a state machine and Futures are just async values you can poll. I'm sure moss has an actual preemptive scheduler for…
You’re arguing about the technical definition of async/await while completely ignoring what it means to write a kernel.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#109Hello! For the past 8 months, or so, I've been working on a project to create a Linux-compatible kernel in nothing but Rust and assembly. I finally feel as though I have enough written that I'd like to share it with the community! I'm currently targeting the ARM64 arch, as that's what I know best. It runs on qemu as well as various dev boards that I've got lying around (pi4, jetson nano, AMD Kria, imx8, etc). It has…
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#110The choice of MIT for a kernel feels like setting up the project to be cannibalized rather than contributed to. We've seen this movie before with the BSDs. Hardware vendors love permissive licenses because they can fork, add their proprietary HAL/drivers, and ship a closed binary blob without ever upstreaming a single fix. Linux won specifically because the GPL forced the "greedy" actors to collaborate. In the embedd…
Not sure why am getting in the middle of this but I need to point out that you are not even correct for Linux. Linux rather famously has avoided the GPL3 and is distributed under a modified GPL2. This license allows binary blob modules. We are all very familiar with this. As a result, the kernel that matches your description above that ships in the highest volume is Linux by a massive margin. Can you run a fully open…