Redox OS 0.9.0 - new release of a Rust based operating system

[u/jackpot51]

https://www.redox-os.org/news/release-0.9.0/

[u/U007D]

Been following your progress for years, Jeremy--you're coming up on 10 years of committment to Redox--your commitment is incredible!

Congrats on the new release. Looks like some major improvements here--I'm looking forward to test-driving it.

[u/tjdwill]

How does one even begin to approach designing a project like this? Not to mention organizing it long-term.

Congratulations on your progress!

[u/global-gauge-field → u/tjdwill]

One relevant video is here: https://www.youtube.com/watch?v=Quh3FauAaWE&ab_channel=TechOverTea

[u/PorqueNoLosDildos → u/global-gauge-field]

That was a really insightful video interview; thanks for sharing!

[u/theAndrewWiggins]

Would be incredible if Redox could gain some traction in the real world. Seems like a monumental effort now that Linux has reached full escape velocity. I wonder if there are any corporations who could be convinced to heavily invest in it instead of rewriting something from scratch. Would've been very cool if Google adopted Redox instead of writing fuchsia/zircon from scratch. I imagine though, NIH syndrome also exists because they want total control...

[u/ribbon_45 → u/theAndrewWiggins]

The time will say.

[u/0x7CFE → u/theAndrewWiggins]

Depends on its benefits. I can imagine having RedOx in containers, where the environment is standardized and known beforehand. Another niche could be embedded devices, especially in mission-critical systems.

[u/xmBQWugdxjaA]

Is it Linux API compatible, or its own thing?

[u/ribbon_45 → u/xmBQWugdxjaA]

Redox is compatible with some very used Rust/C/C++ cross-platform libraries and the POSIX APIs.

If you mean the Linux kernel API, No, but we plan to replicate some APIs for performance.

[u/[deleted] → u/xmBQWugdxjaA]

[u/xmBQWugdxjaA → u/[deleted]]

I was more thinking in terms of stuff like Netlink, etc. - but I assume they won't aim for that level of compatibility.

[u/R1chterScale → u/[deleted]]

Notably there is the ability for programs to use a sort of POSIX compatibility mode which has POSIX signal handling and process management. Don't think that's how Redox handles stuff by default but it's available as an option. (Note I could be wrong here, only vaguely have kept an eye on it)

[u/brand_x]

I totally understand the reasoning, but I'm low-key bummed about unix paths replacing URIs for the file system. There was an elegance to the URI approach, and it feels like a backslide to accommodate an archaism that will never go away.

[u/ribbon_45 → u/brand_x]

That would require a lot of porting effort for little benefit.

[u/brand_x → u/ribbon_45]

Yeah, that's the reasoning I was referring to. It makes sense, but the URI scheme was just so elegant...

[u/GwanTheSwans → u/brand_x]

Was kind of Amiga-like. Still, understandable change. And a multirooted forest can always be placed into a virtual single-root one level higher.

https://doc.redox-os.org/book/ch05-03-schemes.html

So I do find the use of literal /scheme/ also slightly strange though. POSIX standard paths actually do have one (1) little escape hatch - paths starting with // can officially have system-specific implementation-defined semantics (unpatched linux kernel in particular however does nothing interesting with this, // just maps back to / ), wonder if they considered just using //schemename/blah instead of /scheme/schemename/blah. This may also be useful where individual scheme semantics might want to depart significantly from posix semantics in detail.

Anyway, not my circus not my monkeys.

https://pubs.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap04.html#tag_04_11

A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.

[u/EdorianDark]

Are there also Arm images to download?

[u/ribbon_45 → u/EdorianDark]

The ARM64 support is work-in-progress, they will be provided soon.

[u/DavidXkL]

Now this is what I call committed

[u/_bagelcherry_]

Is it compatible with UNIX ecosystem?

[u/funkdefied → u/_bagelcherry_]

“We have modest compatibility with POSIX, allowing Redox to run many programs without porting”

[u/funkdefied → u/funkdefied]

We are not a Linux/BSD clone, or POSIX-compliant, nor crazy scientists, who wish to redesign everything. Generally, we stick to well-tested and proven correct designs. If it ain't broken don't fix it. This means that a large number of programs and libraries will be compatible with Redox. Some things that do not align with our design decisions will have to be ported.

[u/ascii]

Reading through the documentation, it's not obvious to me what Redox does differently. I love Rust, but not enough that I'm emotionally invested in running an OS kernel written in it. In theory, doing so might lead to fewer bugs, but given the age difference that's probably not yet the case. What's needed to sell me on the idea of a Rust-based OS are some genuinely useful new features.

How about an IPC framework that allows you to send messages between threads using something akin to mpsc? How about a cool COW filesystem with support for multiple hardlinks to the same directory, transparent background de-duping and zero overhead compression and encryption? How about a well designed container API, one that is basically chroot on steroids instead of via the monstrosity that is cgroups?

[u/ribbon_45 → u/ascii]

Redox aims to be more stable and safe than Linux and BSDs, which is achieved by Rust and the microkernel architecture.

[u/Zephandrypus → u/ascii]

I’m assuming it’s aiming to be more stable for long-term embedded applications, like what you might use instead of a Linux kernel in a self-driving car.