Live data from Hacker News

Moss: a Rust Linux-compatible kernel in 26,000 lines of code

github.com

101–110 of 163 posts

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#101
post #39
post #37

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.

Seriously: stop it. It's none of your business what the author's license choice is. You don't know what the author is trying to accomplish by their choice of license. It could be a mindless choice, or it could be an informed choice. Perhaps the author wants to build interest and later plans to switch licenses (it's not like others are likely to fork _and_ do an excellent job of evolving and maintaining the fork). Perhaps the author is looking to get hired. Perhaps the author believes that BSD/MIT licensing is more free than the GPL. You really don't need to be shaming the author for not making the choice you made.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#102

Earlier 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?

That's my question. Why is this thread full of license choice flamewar? Do we have nothing of substance to contribute?

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

#103

Earlier 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.…

I agree, and even if a company doesn't give back, they further the popularity and sustainability of the project. Isn't Python an MIT-like license (PSFL)? As well as React and Godot? And Tensorflow is also permissive with Apache 2.0, corrrect?

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#104

Earlier quoted context omitted.

What is a "pushover" license?

Permissive license + complaining when companies don't contribute back from their forks.

I've worked on plenty of BSD and MIT licensed code. I've never complained about lack of contribution. You're projecting. Please stop.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#105

Very 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.

> 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

#107

Hello! 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.

You just described android.

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#108
post #19

Earlier 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…

Embassy is a single threaded RTOS. Moss implements support for Linux ABI which presumes the existence of threads. The fact that async/await doesn’t itself imply anything about threads doesn’t negate that using it within the context of a kernel implementation of the Linux kernel ABI does require thread suspension by definition - the CPU needs to stop running the current thread (or process) and start executing the next thread if there’s any blocking that’s required. Clue: there’s a scheduler within the implementation which means there’s more than 1 thread on the system.

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

#109

Hello! 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…

How does android compatibility look? Can this be compiled to WebAssembly and run in browser?

Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code

#110
post #65

The 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…

A real life case where someone try to force a vendor to release the kernel source code: https://sfconservancy.org/copyleft-compliance/vizio.html
Post reply on HN