Redox: Unix-Like Operating System in Rust
redox-os.org
redox-os.org
2019 https://news.ycombinator.com/item?id=19478720
2018 https://news.ycombinator.com/item?id=18442390
2018 https://news.ycombinator.com/item?id=16198342
2017 https://news.ycombinator.com/item?id=15290607
2016 https://news.ycombinator.com/item?id=11318004
Also, in what way's does the project need help?
Edit: FWIW, I think this or something similar to it is the future of OS development.
I'll look forward to it.
> Right now writing drivers, porting software, and improving documentation are areas to help.
I'll take a look and see what I can help with.
Disagree. It is mostly a Unix clone in rust with few novel concepts. Not that it is not important, and no offense meant to developers.
Edit: removed italics tag.
That being said, I don't know much about OS/kernel development.
Redox is still Unix like, it moderately changes the file paradigm. Microkernel Unix clones are not new. They mention Minix as inspiration while there is no mention of L4 which did lot of work in microkernel performance.
A couple of weekends ago I was playing with seL4 on RISC-V and Rust under qemu, and it felt much better balanced overall than my recollections of LK.
https://fuchsia.googlesource.com/fuchsia/+/master/zircon/ker...
There used to exist a document about porting everything to C++, which I cannot find anymore.
Modern CPUs have a rough time switching tasks. There are all those mitigations for meltdown and spectre. Even before that though, the situation with the TLB was ugly.
Limiting your data structures to ones that are friendly to message passing will really hurt you. Hacks to minimize the performance loss add complexity.
Fundamentally, glue isn't free. The parts may be simple, but the interactions are not.
Hardly forgotten.
We have ported bash and dash, so far. I think porting nushell wouldn't take much work
I prefer doing bare metal development in Rust if possible
That way Redox could offer a considerably improved API and app development environment without worrying about backward compatibility, while being useful as a daily driver in the meantime.
For example, something like NDISwrapper allows you to use Windows network drivers on Linux.
NetBSD's rump kernel drivers might be portable to userspace
From https://news.ycombinator.com/item?id=21839514 re: awesome-safety-critical https://awesome-safety-critical.readthedocs.io/en/latest/ :
> > Does Rust have a chance in mission-critical software? (currently Ada and proven C niches) https://www.reddit.com/r/rust/comments/5iv5j7/does_rust_have...
FWIU, Sealed Rust is in progress.
And there's also RustPython for the userspace.
Is the objective to have an OS written in Rust, which can support programs running in any language.
Or is the objective to have an OS written in Rust AND all the ecosystem in Rust too.
Im wondering because the former seems easier and reachable, but from the comments mentioning the port of numerous programs, I have the impression that it is the latter.
Hoping I'll be able to run redox-os as my daily driver in a few years.
Edit: There are more details in the Book https://doc.redox-os.org/book/ch01-02-what-is-redox.html
Will they refuse to ship any userland code that isn't written in Rust (a browser, for example)? Writing a whole new browser from scratch in Rust would be almost as big a task as the OS itself. Practically speaking, it could make more sense to port an existing one over to their (already POSIX-compatible) environment.
The analogy with operating systems is not silly, actually. Operating systems have indeed benefited/suffered from the network effect caused by "content" (programs). OSs were indeed becoming also feature-rich bahemoats that are hard to recreate faithfully enough in order to run that legacy stuff.
However when people refer to Windows or macOS as OS, they also include the whole collection of standard software as part of the OS. Control panels, browsers, GUI frameworks, etc. At that point it probably includes a browser
I'd add hardware drivers to that list too. Many are of course written by 3rd parties, but to the average consumer they are "part of the OS".
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: "Which is easier to design: an accounting package or an operating system?"
"An operating system," replied the programmer.
The warlord uttered an exclamation of disbelief. "Surely an accounting package is trivial next to the complexity of an operating system," he said.
"Not so," said the programmer, "When designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design."
The warlord of Wu nodded and smiled. "That is all good and well, but which is easier to debug?"
The programmer made no reply.
I think a lot of people actually as much or more applications in their browser these days than normal applications. A lot of times they don't realize they are running an application though until it freezes the browser or pops up a window begging for money. But it's amazing how much code is downloaded for seemingly trivial applications sometimes.
But anyway if you take Chrome as an example, they are literally adding just about every OS feature including accessing USB devices.
This is cool, are there any downsides to calling Rust code from C? I guess it's basically a black box that behaves like a regular C library from the outside?
There's no runtime wrapped around your code like with Go etc. You just need to add an attribute to tell the compiler not to mangle your names, similar to what's needed for C++ / C interop.
https://www.theregister.com/2019/11/29/after_four_years_rust...
https://linux.slashdot.org/story/19/11/30/2011231/rust-based...
https://doc.redox-os.org/book/ch01-06-how-redox-compares.htm... says they support the 31 most common syscalls (however that's defined).
As a side question, how does kernel bypass networking work with a microkernel?
I'm excited about Redox in particular, because of the lack of C.
But more broadly, I hope Nixpkgs (and eventually NixOS) can be a good way to promote kernel diversity. Every kernel having it's own distro is a huge waste, and I think the Nix in particular supports really good integration so the whole BSD "we're tighter-knit than a distro, don't call us that" argument shouldn't justify the duplicated effort.
That's an inaccurate representation: The difference is that BSD evolves the whole system in lockstep, userspace and kernel at the same time. When userspace wants new capabilities like pledge(2), then the kernel is updated to expose it. When the kernel adds new features like routing domains, then userspace is updated to use it.
There's no coordination across a bunch of different projects: The same commit just changes things, across all the bits at once.
Nix doesn't offer that.
If I were to make a Nixified BSD, there's no requirement that I have to split things into multiple repos. I can continue to use a monorepo for the core userland and kernel.
If I want to add a feature to a widely used package, I can still vendor the package like BSD, or I can bump the kernel and package srcs in one commit, adding the feature in both, like Nixpkgs today. In no way am I now at the mercy of coordinating upstream devs---Nix allows any user to integrate anything they want, unilaterally, whether a monorepo is used ot not.
The benefit of Nixpkgs is not to replace the core of BSD, but to replace ports. Nobody, least of all the BSDs, has the time to bespoke integrate every single package. There is always a long tail of stuff that is budgeted minimally----this isn't Linux distro ideology, put simple economics. Nixpkgs allows multiple disparate groups to better cooperate on that long tail.
fork(), execve(), waitpid() and friends
> also things like how redirection works
dup() ing file descriptors. dup2 is atomic alternative to separately closing a file descriptor and dup'ing to it.
xv6 book is freely available on MIT website - it teaches implementation of toy Unix like operating system.. as another commenter mentioned APUE is pretty popular too.
>the project has been going since 2015
True, but Fuchsia started only a year later
>Fuchsia is a lot more than a microkernel, right?
Indeed, but that is also true of Redox!
jackpot51 describes himself in his bio as a "BDFL of Redox OS" which means he's likely personally passionate and just does what he thinks is best. This will likely not lead to a better outcome than Herd and Fuchsia would lead to but it will lead to an outcome within our lifetimes.
In many cases, however, "working" is better than "planned"
The reason stuff doesn't take off is that it never takes off. Implementing an OS is actually not hard. You can get pretty far as a 1-person project provided you have the time. Real world use and other people adopting your stuff is harder.
I can’t imagine how difficult it would have been to get support in 94, but 2020?!
If so, besides the hurd (and all the debian packages that build and run for it), there's Minix 3, HelenOS and Genode (specifically Sculpt) to look into.
>unix-like
You can't have your cake and eat it too.
"With POSIX compatibility" would have been a better description.
Im not following your contention.
And when Apple is finished with moving all kernel extensions to userspace, it might as well be considered as such.
By the way the extensions that were deprecated in Catalina, are now removed in Big Sur, as promised by 2019 roadmap.
So eventually, all extensions will be gone from the kernel.
https://en.wikipedia.org/wiki/Hybrid_kernel#:~:text=The%20Wi...