
Redox: Unix-Like Operating System in Rust - bpierre
https://www.redox-os.org/
======
dang
If curious see also

2019
[https://news.ycombinator.com/item?id=19478720](https://news.ycombinator.com/item?id=19478720)

2018
[https://news.ycombinator.com/item?id=18442390](https://news.ycombinator.com/item?id=18442390)

2018
[https://news.ycombinator.com/item?id=16198342](https://news.ycombinator.com/item?id=16198342)

2017
[https://news.ycombinator.com/item?id=15290607](https://news.ycombinator.com/item?id=15290607)

2016
[https://news.ycombinator.com/item?id=11318004](https://news.ycombinator.com/item?id=11318004)

2016
[https://news.ycombinator.com/item?id=12844539](https://news.ycombinator.com/item?id=12844539)

2015
[https://news.ycombinator.com/item?id=10295187](https://news.ycombinator.com/item?id=10295187)

------
jackpot51
I'm Jeremy Soller, the creator of Redox OS. Let me know if you have questions!

~~~
heavyset_go
Has anyone looked into the viability of a Linux driver compatibility layer to
help solve the problem of the lack of drivers?

For example, something like NDISwrapper allows you to use Windows network
drivers on Linux.

~~~
yjftsjthsd-h
Other prior art is DDE on HURD, FreeBSD drivers on Haiku, and NetBSD rump
kernels.

~~~
loeg
FreeBSD has a pretty broad linuxkpi layer for Linux drivers on FreeBSD as
well. E.g., the Mellanox FreeBSD NIC drivers are really Linux drivers running
on this framework.

------
Galanwe
That may be a stupid question, but the comments here made me wonder:

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.

~~~
Shared404
The OS and in house projects are in Rust, and there is support for programs in
other languages as well.

------
ezluckyfree
I support them on patreon because I'm a terrible low level programmer but I
think OS diversity is a good thing!

~~~
cultofmetatron
Didn't know there was a patreon. Just signed up myself because I love the
project and I don't know enough systems dev to contribute code yet.

Hoping I'll be able to run redox-os as my daily driver in a few years.

------
brundolf
I wish they had more details up-front. Is this totally from scratch, or is it
a piecemeal-replacement of some other Unix-like OS? Does it lean on any non-
Rust components at all? If it's 100% bootstrapped from scratch and they
already have a GUI like in the screenshot, that's extremely impressive and
exciting.

Edit: There are more details in the Book [https://doc.redox-
os.org/book/ch01-02-what-is-redox.html](https://doc.redox-
os.org/book/ch01-02-what-is-redox.html)

~~~
tormeh
Yeah, Redox is a completely new, from scratch, OS written in Rust. Ironically,
even the libc is written in Rust. It (occasionally) runs on real hardware, and
I believe they're pretty close to bootstrapping, although lack of a browser is
a rather big obstacle

~~~
vbezhenar
It is ironic, that writing OS is easier than writing a browser.

~~~
monocasa
Tao of Programming 3.3

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.

~~~
farisjarrah
Are there actually more of these Tao of Programmings? I would be interested in
reading more of these.

~~~
Marcusn3
[http://www.mit.edu/~xela/tao.html](http://www.mit.edu/~xela/tao.html)

------
rcarmo
Bit curious that it doesn't seem to run on a Raspberry Pi. Would seem like an
obvious thing to do at this point. Looked around and found some forum threads,
but nothing installable.

------
darksaints
Can anybody here do a qualitative comparison of the redox kernel and L4
(particularly SeL4)? I'd love to see how well some of the modern microkernels
perform, but I think more importantly, how do they differ and what
capabilities should we care about?

As a side question, how does kernel bypass networking work with a microkernel?

~~~
jclulow
Bypass networking is generally more akin to how device drivers in microkernels
work: a core trusted set of functionality that needs to be in the kernel is
(e.g., programming the MMU or I/O MMU, scheduling) and all the device control
and network stack stuff is in some process or task outside.

------
Ericson2314
Nixpkgs supports Redox a bit! [https://www.redox-os.org/news/redox-plus-
nix-0/](https://www.redox-os.org/news/redox-plus-nix-0/)

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.

~~~
ori_b
> _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.

~~~
Ericson2314
Nothing you said Nix precludes.

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.

------
sntran
I have been curious about OS, particularly how a process for a command is
handled through it's life cycle, and also things like how redirection works
(for things like named pipes). Is there some resources on that topic?
Searching for how OS works is very vague or too details in other aspects.

~~~
halayli
You'll find all the answers in the book 'Advanced Programming in the UNIX
environment' by Richard Stevens. It's also referred to by the acronym APUE.

------
seisvelas
I apologize in advance for such a brazenly ignorant question: But why is it
that this small team is able to produce a working microkernel, yet GNU Herd
and (more recently) Google's Fuchsia have languished eternally as vaporware?

~~~
asveikau
You can use GNU HURD. I did so something like 20 years ago for kicks, then
went back to Linux.

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.

~~~
viraptor
You can even use gnu/hurd, the way gnu/Linux naming was trying to be specific
about.
[https://www.debian.org/ports/hurd/](https://www.debian.org/ports/hurd/)

------
snvzz
>microkernel design

>unix-like

You can't have your cake and eat it too.

"With POSIX compatibility" would have been a better description.

~~~
meddlepal
Wait what? Minix and macOS via Mach are both microkernel designs. Minix is
Unix-like but macOS is Unix.

Im not following your contention.

~~~
zokula
The XNU kernel in macOS is not a microkernel.

~~~
pjmlp
It follow a mikro kernel like design though.

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.

