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!
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.
- [deleted]
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.
> 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.
Original author of smoltcp here! I couldn't have imagined how much of a cornerstone of the Rust ecosystem it would become. Very excited to see it get used like this, and yeah, #![no_std] use cases were the original and primary motivation to build the stack in the first place.
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.
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.
Software Freedom Conservancy have been doing GPL compliance actions for a long time, especially if you consider their staff's previous lawsuit that resulted in OpenWRT existing. Also the more recent Vizio lawsuit is kinda interesting, it aims to enable any recipient of GPLed binaries to sue for GPL compliance.
https://sfconservancy.org/copyleft-compliance/ https://sfconservancy.org/copyleft-compliance/vizio.html
> 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’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.
Thanks for the example! Your opinion here aligns with mine: GCC's GPL status has manifestly not been an issue for vendors in the past. I think the reason for vendors selecting LLVM has much more to do with the fact that LLVM is easier to develop on than GCC.
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.
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.
> 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.
If you intend to spend 1000 hours extending a gpl project someone put 30 minutes into, and you wouldn't have wanted to use GPL, perhaps don't use that project as a base? Spend 1000.5 hours and pick whatever license you like
The point of copyleft is that the author wants the code to remain available to the public, not to give it as a gift to whoever wants to build their own closed source system
>> That's not someone giving me a gift.
You're right. GPL code is not a gift to you its a gift to the public.
Dont try to build your house or business in a national park.
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.
Someone implied that people were evil if they gave away software with nothing asked in return. I didn't think the author deserved that. I'm also starting to think such people are at war with both private property and generosity for political reasons leaning toward socialism or communism. That segment also tries to pressure others to adopt their ideas.
So, I defended the author and the concept of generosity. I also tried to help FOSS people reframe what their doing as collective property or work so everyone understands the tradeoffs better. They confuse people by advocating for "free" or "freedom" with licenses that take away freedoms from authors. It's like they're redefining words to have non-standard meanings but get angry when people act on standard morals or word usages.
I'm also starting to think the confusion was intentional because many of their arguments look like socialism or communism disguised as software advice. We also see the same failure modes across most projects and products. Like communist nations (eg Shenzhen), we see the GPL projects succeed best when they relied on capitalists instead of communist principles for code contributions. So, I'll eventually look to see if people like Stallman were communist and if this was sneaky, ideological warfare or subversion. Like we see with critical theory ("woke") proponents constantly repacking their ideas (eg DEI, Codes of Conduct) to snesk them in where they'd be rejected after peer review. I feel like so much fighting online started with people doing something evil built on a conflict-oriented philosophy (Marxism/Communism) that causes the same destructive effects everywhere people promoted it.
There is a huge distinction between socialism/communism and Free Software.
1) the marginal cost of software is zero.
2) some software is becoming more like infrastructure that everyone uses.
In the physical world, some infrastructure is privatized, some is regulated, and some is provided by the government. But going back to point 1 we see that privatization makes even less sense (to society) with software.
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?
Godot is meant to be used for commercial games, so it should have an MIT, BSD, or LGPL license.
I'm done with proprietary operating systems and IMHO everyone should be. There's no reason to support that.
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.
> They can't remove it. They gave it to you. They just don't have to keep giving you more stuff.
Who is "they" in this context?
A permissive license allows anyone to take someone else's work, profit from it, and never contribute back to the original project. For someone advocating for fairness, it's remarkable how you ignore this very real and common scenario.
> Many people think they're owed more software, including fixes to software, without compensating the laborer. That worldview is the real problem.
Compensation is orthogonal to F/LOSS. Authors are free to choose whatever income streams they like, and many successful businesses have been built around F/LOSS. Whoever is expecting people to work without compensation is being unreasonable, of course.
But F/LOSS as a social movement goes beyond a mere financial transaction. It works on the basis of mutual trust, where if I share something you find valuable, then the acceptable "payment" for that work is for you to do the same. This collaborative effort is how the highest quality products are produced.
The irony of your point is that a permissive license allows precisely the scenario you're arguing against. We've seen corporations profit from the work of others without compensating them for it. So much so, that OSS projects are forced to roll back their permissive licenses, often going too far in the other direction, to where they can no longer be labeled as "Open Source". E.g. Elastic: Apache -> SSPL -> AGPL; Redis: BSD -> SSPL; HashiCorp: MPL -> BSL; etc.
That is the actual problem which copyleft licenses prevent.
Re fairness
Not giving anything back is fair because the author's license specifically allows them to do that. A gift has no expectation of anything in return. God blesses such generosity because it's a a truly, selfless act.
re compensation
Compensation is not orthogonal to FLOSS. Copyright was mainly designed to ensure work couldn't be shared without paying the author. Anything given for free dramatically decreases the chance of getting paid. OSS and FLOSS almost guarantee no money is made on standalone software but GPL with CLA's allows dual licensing to recover some.
If anyone uses permissive licenses, it's a gift where they're not (in legal terms) expecting money. Some try to sell it or ask for donations, too, which is incompatible with the license. The free license usually undermines that. It works for some people to some degree, though.
Re roll backs
I didn't argue against any scenario. The original person I replied to appeared to be arguing that it was evil to give software away with no obligations. I had to explain what a gift is and why it's morally good to give. I believe the reason is years of people promoting FOSS politics which I now see are rooted in ideas similar to socialism or communism. It wouldn't surprise me if Stallman was a closet communist and just repackaged those ideas into software licensing.
(Note: I feel like I'm going to have to think more on that political angle given I've been influenced by such people for years on these sites. I'll do a fresh take at some point.)
On companies being unsustainable, I've already explained what happened. Their goal included selfish gain (money/contributions) from selfish entities who normally take but don't give. Their goal was also to build, individually or collectively, a shared work. They used a license that said it's a one-time gift with no obligations. So, entities took the gift and felt no obligations to return anything. Surprise!
Now, they've changed to licenses that suit their commercial and/or property goals. That may or may not work for them. Whereas, the companies successfully marketing proprietary software are able to build it up to their hearts' content. Some companies give out the source or dual license under GPL/AGPL. They should probably do Parity License to close remaining gaps and see if FOSS people are really about the free commons.
License Zero and Polyform have new licenses to help. I conceptualized some in the past that allow modifications, forks, etc so long as the customer keeps paying. Then, redistribution among paying customers. I'd like to see more models for people aiming for sustainability with software freedoms baked in.
>> Many people think they're owed more software, including fixes to software, without compensating the laborer. That worldview is the real problem.
Many people (corporations) think they're owed more money beyond the labor. This is why SaaS is a major business model these days. The marginal cost of software is zero, and yet people expect to keep getting paid for it over and over.
Thay "holier than thou" attitude from BSD/MIT proponents seems like some kind of ego talking. Freedom to deny others the freedom you had is not noble.
GPL is a gift that keeps giving.
Using the legal system to force other people to do what you want and perpetually isn't freedom: it's controlling others by force to make them live the way you want them to. You're taking away their personal freedoms, like sharing or not sharing their work, to promote or force compliance with a goal of yours. Again, that's control, not freedom.
Would you want people controling your property based on their current and future desires? And dictating what you do with your property enhancements? Would you call that giving you more freedom? Or denying you freedom to force you to support their goals for your property?
It's stupid to discuss this in the abstract because what you want to do with your property is very relevant. If you want to paint your fence a weird color and that's what's being prohibited by law is different is totally different from if you want to build a heavy polluting chemical processing factory or a poorly run slaughter house with animals squealing at all hours of the day.
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.
- [deleted]
yes
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?
>> 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?
Thank you for reading it correctly. I originally had a </sarcasm> to make sure nobody thought I liked the license choice. What's it to me? Well someone posted it to HN here so we could comment on it, so I did.
I think the MIT license has its place, but IMHO it does not belong on an OS like that. Reason is indicated in my original comment.
Glad the author disagrees with you. So do I.
You just described android.
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.
Correct me if I'm wrong, but I think all of these are solved problems.
LGPL should only pose a problem if you explicitly want your program to be used with non-free software. And then only if said non-free software doesn't give you a way to rebuild it yourself, should you want to modify the LGPL program. (So not a problem for open-core or public-source projects, either.)
If, for some reason, you insist on allowing static linking for all the projects, I think the MPL allows this. (People often seem to think of the LGPL, but it's not the only weak-copyleft licence around.)
Otherwise, when releasing your project under GPLv3+, you don't have to put blind faith into the FSF; you can designate a proxy which will decide whether the new version should be allowed for your project or not. This proxy can be yourself, or it can be a different organisation you choose to trust. Plus, I'm pretty sure the GPL allows you to make linking exceptions of your liking.
> LGPL should only pose a problem if you explicitly want your program to be used with non-free software. And then only if said non-free software doesn't give you a way to rebuild it yourself, should you want to modify the LGPL program. (So not a problem for open-core or public-source projects, either.)
No, just if you want it to be used with anything that isn't that exact same GPL licence.
> Otherwise, when releasing your project under GPLv3+, you don't have to put blind faith into the FSF; you can designate a proxy which will decide whether the new version should be allowed for your project or not. This proxy can be yourself, or it can be a different organisation you choose to trust. Plus, I'm pretty sure the GPL allows you to make linking exceptions of your liking.
That's the same as just licencing under the GPLv3 and later retroactively deciding to also give the GPLv4 option when liking that licence. The issue is, what if you don't? Then your code can't be combined with any GPLv4 library.
The simple reality is that crates that have incompatible licences, and GPLv2 and GPLv3 are incompatible, cannot be used together in one distributed project without committing copyright infringement. The thing with MIT is that it's compatible with about every single licence out there.
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?
A derogatory term for copyfree licenses
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?
Not in particular, but it's pretty common for permissively licensed projects to complain about companies complying with their license instead of what they imagine the license to be, then relicensing to a proprietary or copyleft license (e.g. Elasticsearch for a high-profile case but there are many others). This lead to some people disliking permissive licenses.
Personally I dislike them because they don't preserve end-user freedom, I prefer the MPL. But if someone wants to donate their work to for-profit companies that's their choice.
I've worked on plenty of BSD and MIT licensed code. I've never complained about lack of contribution. You're projecting. Please stop.
I'm not the person who used the term "pushover license". I just explained why some people use the term.
It’s a play on “permissive” license.
'Pushover licence' is a licence which may grant freedom, but doesn't care to protect it. One may modify software under a pushover licence and release their modifications as non-free software. Another, more common name is 'permissive licence'.
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
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).
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.
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?
Ah, nice. I wish this was licensed GPL instead of MIT. I'll avoid contribution, sorry!
How does android compatibility look? Can this be compiled to WebAssembly and run in browser?
shouldn't this be a ShowHN?