Rust-Written Redox OS Enjoys Significant Performance Improvements

[Developer12]

LOL!

An Ice Lake lap top is "bleeping edge"?

Ice Lake processors where released in August 2019, nearly 5 years ago.

They also have a bunch of screenshots showing it running on a bunch of laptops:

https://www.redox-os.org/screens/

Compared to a 486? yes, yes they are. Post-skylake CPUs bring a hell of a lot of baggage that isn't well documented for people building their own OSs over on https://wiki.osdev.org/Expanded_Main_Page

Try again with something that's more conventional, with a normal USB keyboard and mouse. After all, the main complaint was that the keyboard etc don't work, and you're sure as hell not going to see support for the weird peripheral BS that intel dreamed up in a hobby OS.

[Veto]

What the hell are you even talking about with memory safety? Yes, most RTOSs don't make use of virtual memory, and many run on systems where it isn't available.

If you bothered to read the comment I was replying to, they were implying that memory safety was something that rust would uniquely bring to RTOSs, but it isn't something they typically worry about. It's nice to have code that works, but that isn't the distinguishing feature of an RTOS. Predictable timing is.

If you bothered to read the comment you were replying to yourself, you would see, that I was the one who wrote it And I did only write: a safety oriented language. You were the one to conflate it with memory safety. It seems you should perhaps be a bit more keen on using your own eyes and ears before cursing and accusing others of being sloppy.

Yes, predictable timing is the defining feature of an RTOS - by name. However, this obviously implies predictable behavior - especially if missing a deadline is truly catastrophic. (It doesn't really make sense to meet the deadline with code that does not work )

[andyprough]

Still not a valid criticism.

The problem is that you criticize the content, not the OS itself.
You base your review on _nothing_ that is bound to the OS design, the intrinsic, the code quality... It's a pure non-technical Walmart end-user point of view. Who cares at this point that there are not many preinstalled softwares bundled with it, it's not the point... The point is to develop a new type of OS with the best concepts, structure, and implementation possible. Things that you sadly didn't even consider while they are 9000x more important.

And you compare it to Temple OS....Seriously?
It's like comparing an electric racecar with a carbon frame to a 40 years old camping-bus and saying the camping-bus is a much better vehicle because there is a mattress and an ashtray....

I spent a couple of weeks exploring TempleOS, but with Redox there's nothing obvious to explore, as it has no obvious tools for the job. To be fair though, I have not taken the time to read TFM yet, it may be that when I do take a few hours to read TFM I will understand the structure better and how to start configuring it and changing it and testing it.

But to give you an example, yesterday evening I spent several hours exploring the Debian 12 Hurd edition, making lots of changes to the configs, adding a lot of software, finding lots of dependency errors. I had a very enjoyable time, I'll probably install it more permanently and learn more about it. I was hoping Redox would be easy to study and play with, but as I said it just presents itself as a demo of someone's masterful graphical artistry, but outside of that it's not clear that it will attain its goals of being a general unix replacement anytime in the near future.

Anyway, since you have such a high degree of interest I will look forward to your notes after you have tested it.

[WileEPyote]

Still not a valid criticism.

The problem is that you criticize the content, not the OS itself.
You base your review on _nothing_ that is bound to the OS design, the intrinsic, the code quality... It's a pure non-technical Walmart end-user point of view. Who cares at this point that there are not many preinstalled softwares bundled with it, it's not the point... The point is to develop a new type of OS with the best concepts, structure, and implementation possible. Things that you sadly didn't even consider while they are 9000x more important.

And you compare it to Temple OS....Seriously?
It's like comparing an electric racecar with a carbon frame to a 40 years old camping-bus and saying the camping-bus is a much better vehicle because there is a mattress and an ashtray....

His criticisms are valid from an average user standpoint though.

To an end user, what you can do with it, and having it meet your needs, is infinitely more important than how it works under the hood. He gave respect for the work put into it, and it is an impressive amount of work, but unless you know programming and can rewrite or recompile programs to actually use on it, it's not very useful yet. That's just a fact. It wasn't stated with ill intent. He's basically saying that it's making good progress, but it isn't ready for prime time, which the devs themselves are basically saying as well.

That is a 100% fair assessment.

I am also looking forward to seeing where this goes, and will likely give it a go myself, but until it can run all the apps I need, or at least an equivalent, it's nothing more than a proof of concept and demo, just like he said. You seem to take that as a bad thing, but it's not. It's a sign of progress.

[Viki Ai]

an OS targeting systems all the way back to the 486 doesn't work with fancy new peripherals on a bleeding-edge intel laptop? say it ain't so! /s

maybe try it again on a desktop system that's a few years older and has a normal USB mouse and keyboard.

I'm pretty sure they don't have a USB stack yet (they support some very specific USB devices, but not in a general way). Unless that changed quite recently. So any system, laptop or desktop, that relies on USB peripherals is likely to not work (which is why I am left only able to drool over it for now).

[mangeek]

I think that while the desktop approach to redox is admirable, it would be far more likely to see it modified and implemented in a high reliability context.

I agree, though it would be way less fun, and it's not my decision to make. IMO it would be a winning strategy to target two or three headless server use cases where a memory-safe OS and server stack would be very high value (LAMP-type server, libvirt/kvm-compatible hypervisor, and K8s node). You could optimize for running as a cloud guest first. I think that would create a lot of interest that could end up making the mission they're currently on easier to get to.

Again, I am not involved, this isn't my place to say. I just see the desktop as a REALLY hard place to target a new OS. You need so much just to be truly viable, like accelerated graphics and tons of device drivers.

[skierpage]

IMO it would be a winning strategy to target two or three headless server use cases where a memory-safe OS and server stack would be very high value (LAMP-type server, libvirt/kvm-compatible hypervisor, and K8s node)..

Good that the March "This Month in Redox" update says "The Apache HTTP server was ported by Chocimier to the point where it can host pages using localhost. There is still work to be done, but this is an exciting first step for the Redox Server edition!"

I assume it's waiting on RustUtils to get completed before it'll support all the ls/cat/grep etc commands.

From the start Redox had a port of the BSD coreutils rewritten in Rust. It's still there but many commands have been removed in favor of the uutils Rust reimplementation of GNU coreutils.

As the team explains in Porting Strategy, Redox includes Relibc, an implementation of the C standard library in Rust; so in many cases, CLI, TUI, and libraries only need to be compiled with relibc. "This is how programs such as Git and Python can run on Redox. relibc has some Poxix compatibility." So I imagine many of the Linux command-line utilities could simply be recompiled ("You are in a maze of xxutils, all alike."), but there are Rust and/or Redox-specific versions of the common ones that Redox favors by default.

Using a Redox port of libc seems a little limiting, but so is Rust's general adoption of libc as a low-level lingua franca even for pure Rust programs. There are fascinating projects like cap-std and rustix that bypass a crufty insecure C library interface as a foundation and go directly in Rust from library functions to system calls, using better error handling, I/O safety,, support for richer types including Rust string types, "references, slices, and return values instead of raw pointers", sandboxed-by-default file access, etc. These should all just work on Redox (eventually).

[byteabit]

Redox includes Relibc, an implementation of the C standard library in Rust;

Uh, that's nice! Hopefully this library can be used to replace glibc entirely, meaning as a drop-in replacement that has the exact same functionality and API. I just saw the section and reading it:

It is intended to work on both Linux and Redox.

We can already do that with musl implementation of libc, that can be used to statically link the libc library instead dynamically linking glibc. But an implantation purely in Rust would be the next level.

So, Relibc implements Linux or POSIX compatible variants of Redox platform services. Compiling against Relibc allows many Linux programs to run on Redox without modification.

Ok, I'm actually satisfied.