Moss: a Rust Linux-compatible kernel in 26,000 lines of code
github.com391 points by hexagonal-sun 7 days ago
391 points by hexagonal-sun 7 days ago
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 enough implemented to run most BusyBox commands on the console.
Major things that are missing at the moment: decent FS driver (only fat32 RO at the moment), and no networking support.
More info is on the github readme.
https://github.com/hexagonal-sun/moss
Comments & contributions welcome!
Very impressive and I like how accessible the codebase is. Plus safe Rust makes it very hard to shoot yourself on the foot, which is good for outside contributions. Great work!
After you got the busybox shell running, how long did it take to add vim support? What challenges did you face? Did you cross-compile it?
BUt it's not "safe" because it's mixed with assembly
There are no programs written in 100% safe Rust—the std library is written with unsafe as needed. But typically the majority of lines in the program—sometimes even all outside std or some well-audited foundational creates—are safe. Those lines can not directly cause any unsoundness, which has tremendous value.
This has been discussed ad nauseam and this adds nothing new. There's value in the memory safety for the majority of the code even if there are some escape valves ("unsafe" keyword, assembly).
> no networking support
Would something like Smoltcp be of help here? https://github.com/smoltcp-rs/smoltcp
Great project either way!
How do you decide which sys calls to work on? Is is based on what the user space binaries demand?
Yip, I panic whenever I encounter a syscall that I can't handle and that prompts me to implement it.
Yeah, I was thinking of integrating that at some point. They've done a really nice job of keeping it no_std-friendly.
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 different from an OS scheduler, except it is cooperative instead of preemptive. It's a drop in the ocean of kernel complexities.
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)
Interesting references, thanks. Moss seems to be doing the same thing as Embassy.
Sorry for nit but embassy is not a RTOS (or any OS), its a framework
The difference becomes a bit murky at this level. For example embassy comes with a lot more things I would consider OS-related than FreeRTOS does.
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.
Ok, I see. I spent a lot of time with .Net VMs, where you cannot simply separate await from the heavy machinery that runs it. I now understand that in a kernel context, you don't need a complex runtime like Tokio. But you still need a way to wake the executor up when hardware does something (like a disk interrupt); but this indeed is not a runtime dependency.
EDIT: just found this source which explains in detail how it works: https://os.phil-opp.com/async-await/
There’s got to be some complexity within the executor implementation though I imagine as I believe you have to suspend and resume execution of the calling thread which can be non-trivial.
You can implement an executor with threading to achieve parallelism, but it's not a fundamental characteristic of Future executors.
To reiterate: an executor is just something that runs Futures to completion, and Futures are just things that you can poll for a value.
See sibling comments for additional details.
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 next task to execute and resume the register state for. On top of that you’ve got the added difficulty of doing this with work stealing (if you want good performance) and coordinating other CPUs/migrating threads between CPUs. Now you can use non interruptible sections but you really want to minimize those if you care about performance if I recall correctly.
Anyway - as I said. Implementing even a basic executor within the kernel (at least for something more involved than a single CPU machine) is more involved, especially if you care about getting good performance (and threading 100% comes up here as an OS concept so claiming it doesn’t belies a certain amount of unawareness of how kernels work internally and how they handle syscalls).
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 processes, but it's completely unrelated to its internal usage of async-await.
See embassy in sibling comments.
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.
This has been a real help! The ability to easily verify the behavior of certain pieces of code (especially mem management code) must have saved me hours of debugging.
Regarding the async code, sibling posts have addressed this. However, if you want to get a taste of how this is implemented in Moss look at src/sched/waker.rs, src/sched/mod.rs, src/sched/uspc_ret.rs. These files cover the majority of the executor implementation.
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.
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.
> There’s an LLVM fork for every esoteric architecture now
Can you provide examples of these? I'm aware of temporary forks for things like Xtensa, but these typically get merged back upstream.
Infineon tricore compiler from hightec. Compilers are actually, IMO, one of the things that are the most easy to have GPL because you can use it internally however you want without releasing the source outside. You could build whatever you want and you don't have to ship it on the final HW. A kernel does not afford you such a thing, you MUST ship it with your product.
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.
> 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.
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.
Seriously.
To the author: kudos for the interesting project, but please strongly consider a copyleft license moving forward.
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 fosters a community of like-minded people. Trust is an implicit requirement for this to succeed, and individuals and corporations who abuse it by taking the work of others and not giving anything back are harmful to these goals. Copyleft licenses exist precisely to prevent this from happening.
MIT is a fine license for many projects, but not for an operating system kernel.
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.
Just as people who strongly prefer permissive licenses deny copyleft licenses, this is the same in reverse. If you don't want to touch GPL projects, then don't.
Im not trying to suggest non gpl licenses are superior and folks writing kernels with gpl are making a mistake. On the contrary I'm advocating that both are fine options and you shouldn't make people feel bad for choosing to not use gpl. There is a difference here and it matters greatly. Most people will not care for the differences between the two and the ones that do will choose the one that aligns with their values. If I'm even a hint of anti gpl, it's due to zealotry of it's supporters.
I think a lot of the backlash for the GPL is unreasonable, and not really better than a lot of the backlash for permissive licenses, and furthermore I believe there are reasonable ideological opinions to prefer one or the other (though ideology isn't an excuse to be mean). But I concede that the person you responded to set a poor standard of discussion.
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.
People doing MIT license are often generous enough where the code is a gift to everyone. They don't try to control their lives or societal outcomes with extra obligations. They're just giving. So, I'm grateful to them for both OSS and business adaptations of their gifts.
While the FSF's vision for the GPL is clear, the GPL itself is not so powerful that it is more than a "gift" that has some terms if you want to do certain things you are not obligated to do. It is like a grant that enforces some reasonable conditions so the money isn't just misappropriated. I wouldn't give that to a friend for their birthday, but I think it's reasonable that powerful organizations should not be free to do whatever they want. Not that the GPL is perfect for that use, but it's good.
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?
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.
> It's more like a contractual agreement with something provided and specific, non-negotiable obligations.
The obligation is not to the author of the code, it is to the public. MIT-style licenses are gifts to people and companies who produce code and software, copyleft licenses are gifts to the public.
I don't give a shit about the happiness of programmers any more than the happiness of garbage collectors, sorry. I don't care more that you have access to the library you want to use at your job writing software for phones than I care that somebody has access to the code on their own phone. You're free to care about what you want, but the pretense at moral superiority is incoherent.
It is non-negotiable. GPL is basically proprietary software. It's owned by the public, and all of the work that you do using it belongs to the public. If you steal it, you should be sued into the ground.
I get what your saying but I think it’s not the best way to describe it - “GPL is property”? Hardly - it’s a societal common good that can be used by anyone interested in helping that common good.
Are parks “proprietary”? I can’t run my car dealership from one, so it’s …proprietary? No. So using the terminology of “proprietary” doesn’t do justice to what it actually is.
The phrasing is a little awkward but I like the sentiment: gpl software is owned by the public/humanity/the commons/etc in the same way something like the grand canyon should be.
Public property is different from private property, which is different from personal property.
A gift is when you do something without expecting anything in return, esp compensation.
If I use GPL'd code, I have to keep releasing my modifications for free because it's mandated. I have to do that even if I do 1000 hours of labor but they gave me 30 min of it. So, it's also near-infinite work required in return for finite work they did. And I have to bind others to this with my own work.
That's not someone giving me a gift. I'm not sure what to call that except a collective work with permanent obligations for all parties. It's more like a job or corporate charter or something. I like another person's claim that it's creating property with requirements for those using it (which copyright certainly does).
> If I use GPL'd code, I have to keep releasing my modifications for free because it's mandated.
Pedantically, only recipients of your updated binary are owed updated source, so if you're not distributing that binary to the whole world, you're not required to release updated source to the whole world. Kind of a nitpick, but maybe not.
A gift where the recipient can remove the freedoms that they've been enjoying themselves is a bad deal for ensuring those freedoms are available to everyone. A permissive license is a terrible idea for a F/LOSS kernel.
This is the paradox of tolerance, essentially.
Also, seeing F/LOSS as a "gift" is an awful way of looking at it.
They can't remove it. They gave it to you. They just don't have to keep giving you more stuff. Many people think they're owed more software, including fixes to software, without compensating the laborer. That worldview is the real problem.
So, we have a variety of licensing styles that meet various goals. People can pick what suits their needs and wants. That's a good thing.
I take this as an oblique critique of TFA's choice of license. What's it to you? Why must we all use the GPL always in order to satisfy busybodies?
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).
I’ve pretty much only seen MIT and to a lesser extent GPL on most open source projects. Would you expect a different license?
What is a "pushover" license?
Permissive license + complaining when companies don't contribute back from their forks.
Do rust projects have a reputation for complaining about corporate forks not contributing back code?
I've worked on plenty of BSD and MIT licensed code. I've never complained about lack of contribution. You're projecting. Please stop.
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.
Impressive work! Do you have any goals, other than learning and having fun?
Also how does it's design compare with Redox and Asterinas?
How does android compatibility look? Can this be compiled to WebAssembly and run in browser?
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 embedded space, an MIT kernel is just free R&D for a vendor who will lock the bootloader anyway.
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 source Linux kernel on your Android phone? Probably not. You do not have the drivers. You may not pass the security checks.
Do companies like Broadcomm “collaborate” on Linux even in the PC or Mac space? Not really.
On the other side, companies that use FreeBSD do actually contribute a lot of code. This includes Netflix most famously but even Sony gives back.
The vast majority of vendors that use Linux embedded never contribute a single line of code (like 80% or more at least - maybe 98%). Very few of them even make the kernel code they use available. I worked in video surveillance where every video recorder and camera in the entire industry is Linux based at this point. Almost none of them distribute source code.
But even the story behind the GPL or not is wrong in the real world.
You get great industry players like Valve that contribute a lot of code. And guess what, a lot of that code is licensed permissively. And a lot of other companies continue to Mesa, Wayland, Xorg, pipewire, and other parts of the stack that are permissively licensed. The level of contribution has nothing to do with the GPL.
How about other important projects? There are more big companies contributing to LLVM/Clang (permissive) than there are to GCC (GPL).
In fact, the GPL often discourages collaboration. Apple is a great example of a company that will not contribute to even the GPL projects that they rely on. But they do contribute a fair bit of Open Source code permisssively. And they are not even one of the “good guys” in Open Source.
This comment is pure ideological mythology.
>Probably not.
Probably not, but possibly yes. Which is more than the cuck license guarantees. See postmarketOS and such, which would be impossible in a BSD world.
>The vast majority of vendors that use Linux embedded never contribute a single line of code
It doesn't matter. The point is just that they can be legally compelled to if needed. That is better than nothing.
>The level of contribution has nothing to do with the GPL.
None of this would be feasible if linux wasn't a platform where the drivers work. They wouldn't have worked on the linux userspace in the first place if it didn't have driver support: it wouldn't be a viable competitor to windows and the whole PC platform would probably be locked down anyways without a decent competitor. Permissive software is parasitic in this sense that it benefits from inter-operating in a copyleft environment but cooperates with attempts to lock down the market.
LLVM was made after GCC and is designed with a different architecture. It is apples and oranges.
Apple is a great example of a company that is flooding the world with locked-down devices. Everything they do is an obstacle to general purpose computing. What do they meaningfully commit to the public domain? Swift? Webkit? It is part of a strategy to improve their lock-in and ultimately make collaboration impossible.
A real life case where someone try to force a vendor to release the kernel source code: https://sfconservancy.org/copyleft-compliance/vizio.html
> 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.
This comment is a tangential distraction, but it's not even correct. Linus Torvalds has specifically claimed that he wouldn't have created Linux at all if 386BSD was available at the time. But BSD was tied up in a lawsuit with USL, discouraging companies and individuals from use.
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 the land clearing GCC accomplished, but times are different now and corporations have a better understanding and relationship with OSS.
The GPL has enough area to opt out of contributing (i.e. services businesses or just stacking on immense complexity in a BSP so as to ensure vendor lockin) that it isn't a defining concern for most users.
Therefore I don't think Linux' success has much to do with GPL. It has been effective in the BSP space, but the main parts most people care about and associate with Linux could easily be MIT with no significant consequence on velocity and participation. In fact, a lot of the DRM code (graphics drivers) are dual-licensed thusly.
> 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.
> 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.
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.
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).
This comment does not contribute to discussion of TFA: it's just license flamewar bait.
The authors almost certainly gave a bit of thought to their choice of license. The choice of license is a "business choice" that has to do with the author(s)' goals, and it is a choice best seen as intending to achieve those goals. Those goals can be very different from your own goals, and that's fine! There is no need to shame TFA for their choice of license, or implicitly for their goals as opposed to yours.
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.
Why is a proven effect "ridiculous" to discuss? It's a valid concern and the discussion could make the authors rethink their choice.
That's 1980s-90s thinking. Nobody is making proprietary BSD forks any more and new kernels probably have no chance of reaching production anyway so worrying about proprietary forks is irrelevant.
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 agree, I know a lot of people aren't huge fans of it but in the long run Linux being GPL2 was a huge factor in its success.
Somewhere there is a dark timeline where the BSDs won, there are 50 commercial and open source variants all with their own kernel and userland. The only promise of interoperability is in extremely ossified layers like POSIX. There is, however, something terrible gathering its strength. A colossus. The great Shade that will eat the net. In boardroom meetings across the land, CTOs whisper its name and tremble... "OS/2."
> 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?
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.
Why?
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?
Routers are all running ddwrt which we only have access to because of a GPL lawsuit against Linksys. The GPL works.
It is neither selfish nor greedy to accept and use a gift freely given to you.
Receiving a gift does not confer obligations on the recipient.
Gifts definitely confer obligations on the recipient. You can experience this firsthand: take the next gift a loved one gives you, and then sell it, and let them know. Please report back on how you selling their gift impacts your relationship with that person.
People can license their code however they please, but comparing open source software to a gift is not an argument for permissive licenses.
True, but you would probably still be pissed if somebody took your gift and hit you over the head with it.
It does. There is an implied expectation that the recipient will will not be selfish. They can pay it back, pay it forward, possibly later when they can afford it, etc., but they are expected not to be selfish and also give someone something eventually.
Because unlike most other functionality, you generally need hw specs or cooperation to write drivers (see Nvidia GSP).
Anyone can write Photoshop (provided reasonable resources). The problem is going to be proprietary file format and compatibility with the ecosystem. It's same with hardware, except several orders of magnitude worse.
It will be compatible for ~5 minutes:
https://www.kernel.org/doc/html/v4.10/process/stable-api-non...
> [Moss has] binary compatibility with Linux userspace applications (currently capable of running most BusyBox commands).
Per your link
> Note: Please realize that this article describes the in kernel interfaces, not the kernel to userspace interfaces.
Really 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
How does this compare to https://github.com/nuta/kerla ?
Just a hobby, won’t be big and professional like Linux?
I don't know much about Linux internals - how difficult would it be to reimplement KVM? I'm guessing a big undertaking.
In what extent is this compatible with Linux?
Could I swap Ubuntu's or Android's kernel with this, while keeping those OSes bootable?
While it's very legitimate question, the answer is between the lines in the README, and it mostly means that there is a user space binary compatibility for everything that is implemented.
It might seem obscure, but syscalls to get access to kernel requires a tight integration on compilation and linking. So this is their approach and this is where the compatibility really means something : since you can cross compile on another machine, they don't need the full toolchain right away. Just compile your code on a linux machine, and run it there. You're at the mercy of all missing kernel API implementations, but it looks like a very good strategy if you aim is to code a kernel, as you only have to focus on actual syscalls implementation without getting distracted by toolchain.
At this stage you'd need to contribute to it, not treat it as a finished product.
This plus using Fil-C for the BusyBox commands is a nice combination (once Fil-C supports ARM64).
Or... rewrite BusyBox in Rust. (And most certainly such a project already exists.)
[flagged]
I understand that you've only been on HN for 7 days, but please don't do this. It's gross.
Just about everything of worth in operating systems (and in software in general) was already invented in those decades.
Just shows how little we have achieved since then. In both hardware architecture and software based on that hardware.
Wait until they get to the networking layer; you're going to hate what Vint Cerf did in the 70s :)
[dead]
> MIT license
What have you done?!