Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 163 posts

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

#111

Post by josefx »

kev009 wrote: post #97
leo_e wrote: 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…

I think GCC is the real shining example of a GPL success, it broke through a rut of high cost developer tooling in the 1990s and became the de facto compiler for UNIX and embedded BSPs (Board Support Packages) while training corporations on how to deal with all this. But then LLVM showed up and showed it is no longer imperative to have a viral license to sustain corporate OSS. That might've not been possible without…

> But then LLVM showed up and showed it is no longer imperative to have a viral license

I am not sure I remember everything right, but as far as I remember Apple originally maintained a fork of gcc for its objective-c language and didn't provide clean patches upstream, instead it threw its weight behind LLVM the moment it became even remotely viable so it could avoid the issue entirely.

Also gcc didn't provide APIs for IDE integration early on, causing significant issues with attempts to implement features like refactoring support on top of it. People had the choice of either using llvm, half ass it with ctags or stick with plain text search and replace like RMS intended.

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

#112

Post by netbsdusers »

leo_e wrote: 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…

> Linux won specifically because the GPL forced the "greedy" actors to collaborate.

How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms that (at least when they began) committed themselves to respect those principles.

I realise the memory of Linux's roots in hacker culture is fading away fast but I really do think this might have been the key factor in Linux's growth. It reached a critical mass that way.

I'm quite certain of the fact that this was more important anyway than the fact that, for instance, Linksys had to (eventually! they didn't at first) release the source code to their modifications to the Linux kernel to run on the WRT54G. I don't think things like that played much of a role at all.

Linksys were certainly kind enough to permit people to flash their own firmware to that router, and that helped grow Linux in that area. They even released a special WRT54GL edition to facilitate custom firmware. But they could just as easily have Tivoised it (something that the Linux licence does not forbid) and that would've been the end of the story.

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

#113

Post by netbsdusers »

kaoD wrote: post #5
Rochus wrote: post #4

Earlier quoted context omitted.

Cool project, congrats. I like the idea with libkernel which makes debugging easier before going to "hardware". It's like the advantages of a microkernel achievable in a monolithic kernel, without the huge size of LKL, UML or rump kernels. Isn't Rust async/awat depending on runtime and OS features? Using it in the kernel sounds like an complex bootstrap challenge.

Rust's async-await is executor-agnostic and runs entirely in userspace. It is just syntax-sugar for Futures as state machines, where "await points" are your states. An executor (I think this is what you meant by runtime) is nothing special and doesn't need to be tied to OS features at all. You can poll and run futures in a single thread. It's just something that holds and runs futures to completion. Not very differen…

I find it interesting that this fulfills some of Dennis Ritchie's goals for what became the STREAMS framework for byte-oriented I/O:

> I decided, with regret, that each processing module could not act as an independent process with its own call record. The numbers seemed against it: on large systems it is necessary to allow for as many as 1000 queues, and I saw no good way to run this many processes without consuming inordinate amounts of storage. As a result, stream server procedures are not allowed to block awaiting data, but instead must return after saving necessary status information explicitly. The contortions required in the code are seldom serious in practice, but the beauty of the scheme would increase if servers could be written as a simple read-write loop in the true coroutine style.

The power of that framework was exactly that it didn't need independent processes. It avoided considerable overhead that way. The cost was that you had to write coroutines by hand, and at a certain point that becomes very difficult to code. With a language that facilitates stackless coroutines, you can get much of the strengths of an architecture like STREAMS while not having to write contorted code.

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

#114

Post by wmf »

netbsdusers wrote: post #112
leo_e wrote: 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…

> Linux won specifically because the GPL forced the "greedy" actors to collaborate. How do we know that? It seems to me that a greater factor in the success of Linux was the idealism and community. It was about freedom. Linux was the "Revolution OS" and the hacker community couldn't but fall in love with Linux and its community that embodied their ideals. They contributed to it and they founded new kinds of firms tha…

We can't really prove it but I noticed a lot of people worked on BSD for a few years, got poached by Sun/NeXT/BSDI/NetApp, then mostly stopped contributing to open source. Meanwhile early Linux devs continued contributing to Linux for decades.

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

#115

Post by drob518 »

rendx wrote: post #96
LeFantome wrote: post #80

Earlier quoted context omitted.

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…

> In fact, the GPL often discourages collaboration Not true. Yes, companies choose not to contribute, so they discourage themselves. It's not inherent to the GPL.

?!?!?

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

#116

Post by phendrenad2 »

leo_e wrote: 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…

Kinda sad that the top comment on this really interesting project is complaining about the license, reiterating the trite conventional wisdom on this topic,which is based on basically two data points (Linux and BSD) (probably because any time someone tries something new, they get beaten down by people who complain that BSD and Linux already exist, but that's another topic).

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

#117

Post by [deleted] »

vlovich123 wrote: post #108
kaoD wrote: post #19

Earlier quoted context omitted.

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…

[deleted]

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

#118

Post by tensor »

marty-oehme wrote: post #10

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.

FreeBSD already has Linux ABI compatibility and has for a long time.

I have to say the GPL trolling in this post is some of the worst I've ever seen on HN. Literally 99% of the comments GPL trolls coming in and thread shitting everywhere. It's genuinely disgusting.

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

#119

Post by Blikkentrekker »

surajrmal wrote: post #48
533474 wrote: post #45

Earlier quoted context omitted.

Great, an MIT license to accelerate planned obsolescence and hardware junk. Truly a brilliant move

Linux magically solves this problem how? GPL isn't magic. It doesn't compel contributing upstream. And half of modern driver stacks live in userspace anyways.

There are also so many G.P.L. violations and nothing is done about it.

I think a big issue is also that it's hard to show actual damages with this kind of copyright violation. It's obviously copyright violation but what damages are there really? Also, there are so many dubious cases where it's not clear whether it is a violation or not.

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

#120

Post by Blikkentrekker »

F3nd0 wrote: post #29
hexagonal-sun wrote: post #2

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…

Congratulations on the progress. If I may ask, I'm curious what considerations have motivated your choice of licence (especially since pushover licences seem extremely popular with all kinds of different Rust projects, as opposed to copyleft).

Copyleft doesn't work well with Rust's ecosystem of many small crates and heavy reliance on libraries alongside static linking.

If one library be GPLv2 and the other GPLv3 they couldn't be used together in one project. LGPL solves nothing because it's all statically linked anyway. And yes, one could licence under both under the user's choice but then GPLv4 comes out and the process repeats itself, and yes one could use GPLv2+ but people aren't exactly willing to licence under a licence that doesn't yet exist and put blind faith into whoever writes it.

Using anything but a permissive licence is a good way to ensure no one will lose your library and someone will just re-implement it under a permissive licence.

C is a completely different landscape. Libraries are larger and the wheel is re-invented more often and most of all dynamic linking is used a lot so the LGPL solves a lot.

Post reply on HN