Just a hobby, won’t be big and professional like Linux?
I see what you did there, fair human.
Moss: a Rust Linux-compatible kernel in 26,000 lines of code
61–70 of 163 posts
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#62Earlier quoted context omitted.
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…
Yeah, for example embassy-rs is an RTOS that uses rust async on tiny microcontrollers. You can hook task execution up to a main loop and interrupts pretty easily. (And RTIC is another, more radically simple version which also uses async but just runs everything in interrupt handlers and uses the interrupt priority and nesting capability of most micros to do the scheduling)
Sorry for nit but embassy is not a RTOS (or any OS), its a framework
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#63Earlier quoted context omitted.
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.
> And half of modern driver stacks live in userspace anyways ??? I haven't touched hardware whose driver lives in userspace since 2017 and it was a DMX512 controller of a shitty brand
They seem to be primarily targeting arm. A lot of drivers live in userspace for arm socs, especially on the higher end.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#64Earlier quoted context omitted.
Do you think soup kitchens and food banks should only serve food to those who volunteer? MIT is a perfectly fine FOSS license.
No, but if someone takes the free food and builds a business by selling it to others, without giving anything back to the original places, it harms everyone other than the person doing that. F/LOSS is not a charity or a gift, so your analogy is not appropriate. It is a social movement and philosophy with the goal of sharing knowledge and building software for the benefit of everyone . It invites collaboration, and fo…
This feels eerily close to having someone try to convince me to be join their religion. You don't need to force your opinions into others. Let them choose. If folks agree then the license will hold them back in terms of building a community. There are plenty of great open source kernels that don't use GPL, including freebsd. I think most embedded os kernels are not gpl (zephyr, freertos, etc). I would argue that Linux does well in spite of its license not because of it.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#65The 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 embedded space, an MIT kernel is just free R&D for a vendor who will lock the bootloader anyway.
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#66Earlier 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.
Do you think soup kitchens and food banks should only serve food to those who volunteer? MIT is a perfectly fine FOSS license.
yes
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#67Really neat. Do you have any specific long term goals for it? Eg, provide an OS distro (using Linux drivers?) to provide memory safety for security-critical contexts? Also, are there any opportunities to make this kernel significantly faster than Linux’s?
Eventually, It'd be amazing to use Moss as my daily driver OS. That means targeting the specific hardware that I have, but in doing so, I hope to build up enough of the abstractions to allow easier porting of hardware. A more concrete mid-term goal is for it to be 'self-hosting'. By that I mean you could edit the code, download dependencies and compile the kernel from within Moss.
Are you interested in beating Linux performance-wise? Eg:
- Moving away from the too-small 4kb default page size (while having a good strategy for dealing with fragmentation)?
- Make it easy to minimize/track interrupts on a core, for low-latency contexts
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#68Hello! 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…
Impressive work! Do you have any goals, other than learning and having fun? Also how does it's design compare with Redox and Asterinas?
Are the collaborations possible/foreseeable?
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#69Earlier quoted context omitted.
because otherwise big tech companies will take it and modify and release hardware with it without releasing patches etc? Basically being selfish and greedy?
Does this happen to freebsd? I know plenty of closed source Linux drivers.
Isn't that basically every router out there?
Re: Moss: a Rust Linux-compatible kernel in 26,000 lines of code
#70The 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 meaning to single you out specifically, but this entire discussion — all of this license gatekeeping is ridiculous. This is a very cool project, but if the license ruins it for you, there are zillions of open source GPL3 kernels.
I mean, this is not different from bitching about someone writing their custom kernel in C++ instead of Rust, or Zig. It’s not your project! Let people do their own thing! MIT is a perfectly fine license; maybe the lack of zealotry associated with it would even be a positive thing for whatever community might be built around this eventually, if the author is even interested in having other contributions.