Redox OS 0.7.0 | Hacker News Reader

Redox OS 0.7.0

redox-os.org

234 pointsjackpot5188 comments

Personally, I am really excited by Relibc. While there is a certain irony in a C standard library that is not written in C, it seems like exactly the kind a place you want to have the advantages of Rust. I would love to see it find success beyond Redox as well.

Yes me too. I hope it can join forces with https://github.com/sunfishcode/mustang

I have never really paid attention to Redoxfs before. I see that it is also meant to work with Linux as well.

It would be great if it could get some traction on Linux as any level of success on Linux would bring a relatively large audience and substantial testing. A filesystem also seems like the kind of place that Rust features would be very welcome. The fact that Linux is moving towards allowing Rust usage gives me hope that Redoxfs could make it into the kernel at some point.

I am Jeremy Soller, the creator of Redox OS, please ask me anything!

Do you know anyone using Redox as their daily driver?

No, I do not. Redox OS is hard to install permanently (there is no easy installer yet). Most of us are running Redox OS in a VM, with occasional experiments on real hardware.

Super exciting, congrats on the new release, it's been so long since the last release!

One question I have is: Is there any plan or prioritisation to get Firefox running on Redox? Totally understand if that's way down the line of prerequisites of course :)

The next priorities will be to make the image installable, and to improve how rustc runs on Redox (for self-hosting). After that, it will be easier to develop on Redox OS and work on porting larger pieces of software like Firefox.

Why not Servo?

I'd love to port Servo, but the first thing people would ask after doing that, is probably when is Firefox going to be ported ;-)

I'll cast another vote for Servo. Serenity has their own native browser: https://github.com/SerenityOS/serenity/tree/master/Userland/...

Servo never made it to a place where it could consistently render most websites correctly. People underestimate the amount of work required to get something like that production ready by several orders of magnitude.

Dumb question. Why make another OS?

For fun and for knowledge, what else?

Well, sometimes people make OSes for commercial use, educational use, etc.

Yep, all those too :D

because 3 operating systems apple-linux-windows isn't enough! Just like the 3 web browsers webkit-mozilla-chromium isn't enough. Remove the derivatives, and there aren't really that many different freshly updated and fully functional desktop / phone operating systems available, but it's good to see some. Thank you https://www.redox-os.org/

https://serenityos.org/

https://www.openbsd.org/

https://wiki.osdev.org/Projects

Let's also add https://genode.org/ to the list :)

minix3

Don't forget about GNU Hurd. ;)

Because UNIX and its derivatives do suck. (huge TCB, drivers in the kernel, global namespaces, ambient security)

Therefore, it is sensible that other approaches are being considered.

> Because UNIX and its derivatives do suck. (huge TCB, drivers in the kernel, global namespaces, ambient security)

This is a unix-like, and none of those are inherit to unix/derivatives; there are small unixen, there are microkernel unixen, containers are popular, and whatever security model you want, someone has hacked it onto an existing unix-family OS.

> Because UNIX and its derivatives do suck. (huge TCB, drivers in the kernel, global namespaces, ambient security)

GNU Hurd on drivers, you can use the ones from GNU/Linux I think. On global namespaces, I'd say Plan9/9front it's Unix 2.0.

That is a good question

Why not?

Apologies if this is already documented somewhere, but what security model is Redox working towards?

(P.s. thanks for starting the gargantuan task of writing a modern OS in a memory safe language)

Primarily the model is capability based. Most things are managed through file descriptors. Services usually end up in a special namespace where they can no longer open new files at runtime, except from a highly restricted set of filesystems. This essentially disallows operating on anything beyond their current set of open file descriptors. This makes runtime inspection of the capabilities of each process fairly easy, and the build time declaration of those namespaces also pretty easy.

Wow, that sounds really exciting. How would this work for something like a service that runs for a long time, and periodically needs to make a web request (and therefore periodically opens a TCP socket)?

Are you counting the ability itself to open sockets as a "file descriptor"? Is it straightforward to implement a "namespace" (not sure if I'm using that correctly) that limits network access to certain IP addresses? Certain domains?

Super stoked to see the note on rustc!

Would you mind sharing any details of your dev setup (HW/SW)?

Spoiler alert: I am also the maintainer of Pop!_OS and the Principal Engineer at System76 so it will be easy to guess.

I have loads of computers (which helps when doing OS work!) but my main one is my desktop. I have a System76 Thelio Mira with AMD Ryzen 9 5950X CPU, AMD Radeon RX 6900 XT GPU, 128 GB DDR4-3200 ECC RAM, a couple PCIe Gen 4 drives, and a couple larger PCIe Gen 3 drives. The most important parts of my setup, though, are my System76 Launch keyboard and 3x LG 27GL850 monitors. There's also probably a mouse somewhere.

This computer runs primarily Pop!_OS 22.04 LTS, but on those extra drives I often have some other OS's installed for testing. I also use loads of VM's, as you can probably imagine.

For apps, I mostly use Alacritty for my terminal, Firefox for my browser, and Vim for my editor.

Do you have any system of subaccounts or workspaces for permissions?

I basically wish more OSs would allow me to easily isolate the different "topics" of my life like gaming, studying, banking, etc.

Also, are most syscalls async?

Namespaces on redox are probably what you are looking for. They are incredibly powerful, but difficult to describe. Processes can offer isolated filesystems called "schemes". These are usually at the default namespace (1). Processes can move to the null namespace (0) which disallows them from opening file descriptors from most schemes. Moving to a new namespace allows a process to control the view of the system for all its children. This can be used, for example, to implement chroot.

Syscalls are mostly sync, but with some syscalls for doing blocking operations asynchronously, like on Linux.

Is there any good reason releases don't have the ISA they target in the filename or path?

Going by the screenshot, I am guessing it'll require x86_64, and that I should built it myself for some other architecture (which ones are supported? This is not easy to find either, yet it belongs to the bulletpoint list in the front page).

I'll add that, I would definitely have had that if something other than x86_64 was supported

Good work. There's not anywhere near enough people working on non-bankrupt OS designs.

Too much bad design (UNIX-like, drivers in the kernel, global namespaces, ambient security) out there.

What is your long term strategy for hardware support? Do you want to target a few devices, or aim for broad support? Will you support some sort of virtualized/embedded Linux process to leverage all of the Linux drivers that have already been written?

Working at System76, I have mostly been developing with those devices in mind.

First of all, thank you for this release.

It is fascinating to see the emphasis on working with a broad range of hardware and low level features like the file system. Contrast this with something like SerenityOS where they spend so much time on things like the web browser and where many contributors are working on things like fonts and dialog boxes.

This leads me to ask, “what are your goals and ambitions for Redox?”. How should I be thinking about it? Who should be using it today and tomorrow?

Some people have asked what is unique about Redox as if being an OS in Rust is not enough. That is not really what I am asking.

If I am allowed to ask another question, “what’s next?”.

I would love to next work on the install process. Currently, there is only a very simple installer that I haven't mentioned much because it is really only good for replicating the VM image inside a VM.

Improving this so it can be used to have permanent installs of Redox OS, and then improving rustc so those installs can build software for Redox OS (self-hosted), would accelerate development so we can take on bigger, higher level projects.

This looks fun. did you look into Fuchsia? It has similar concepts of microkernel with userland drivers.

I have looked into Fuchsia, mostly into the Zircon kernel and its system calls.

Could you lay out some of the differences between Zircon and Redox? I know that both are vaguely Plan 9-inspired, but some of the finer details are unclear.

(This would be a great thing to flesh out in the official docs, currently there are a lot of TODOs in those sections)

Been contributing each month for the last year or so. Every release confirms to me that this is money well spent. currently learning rust so that I can contribute myself. eventually. thankyou for all the hard work!

Thanks!

Does Copy-on-Write mean that Redoxfs is meant to be a competitor to the likes of ZFS and Btrfs at some point?

Is it really Redirect-on-Write?

Yes, it is redirect on write.

Why a new filesystem - not zfs, nilfs or hammer for example?

Are you the creator of Redox OS?

Is there something like DTrace? Or are you considering having something like EBPF?

Nice to see you're still going at it, good luck going forward, we need alternative OS designs and Redox looks quite cool.

Hi Jeremy and first of all, thank you very much for your efforts in trying to bring some new fresh air in the OS world. We see nowadays OSes and applications running short in resources with, let's say, 2GB RAM and 2 2GHz cores, typical resources for old-school 32-bit systems. Do you have in mind to keep the resource hunger of your OS as low as possible so they could fit (and be actually effective and useful) also on such "limited" hardware?

I ask this because I use what I would call "a rather capable" 64-bit laptop that normally does nothing but yet can easily struggle with some web-based multimedia service running in a browser.

Redox has pretty low resource requirements.

How much performance overhead does the microkernel design impose? Or is it actually the opposite these days (there's got to be a reason people keep moving network stacks into userspace for performance...)?

People are moving network stacks into userspace to be closer to the application, which improves the performance. Similarly, you could move application code to the kernel, which is what unikernels achieve. :)

Which distribution model do you have in mind? Something like Linux or something more with much more centralized control?

Hi, Redox OS looks very interesting and I'd love to help contribute. Using rust for an OS seems like a big win for safety and stability down the road. I've emailed info@redox-os.org a while ago to try and get account approved so I can join the chat and begin to contribute - However I have had no response. Is there another way of me being able to get onto the chat?

Glad to see v0.7!

I tried v0.6 a couple of weeks ago, shortly after TheRegister.co.uk had an article on it.

v6's major lack was self hosting and from the release notes it seemed far away, but with v7 it's now mentioned as one of the main user visible new features...

only I can't find 'rustc' or 'cargo', so I'm afraid that capability isn't quite there yet, correct?

Like your hardware btw. mine's rather similar only home-grown with same CPU and RAM, but an RTX2080ti GPU, 10Gbit Ethernet, dual NVMe but also dual tray-less 2.5" SATA SSD hot-swap enclosure, pretty much like 1.44" floppy disks at SSD speed and Terabyte capacity, so I can swap operating systems like floppies.

I'd love to have the same for NVMe, but those solutions are rare, pricey and most likely troublesome, unless you have retimers in place.

It looks cool, when I was young and Linux was just few years around it was very limited and people considered it a toy, but it being limited in supporting stuff was the reason I loved it, as it would force me to go around and explore and experiment, and I guess it developed my passion for informatics. Now Linux is a bit of low maintenance system. But I hope your system may become the reason why kids of today explore and read and experiment and which light their passion for this world in them. Good luck! I say it because every now and then I think about my history and am afraid that kids of today between all the ready to use and black boxes stuff have little to experiment

The most exciting sentence is that you want to release more often. Also very cool that Rust itself is close to working.

It has been a lot of work getting to this point. Finally, the foundation is laid for more regular updates.

Silly absurd question, is it possible to get something like Wine working so we can keep using debian packages ?

I strongly doubt that within scope for a single developer, but I would absolutely love to be able to run Linux software on something that's not Linux.

FreeBSD has this today - https://wiki.freebsd.org/Linuxulator

VMs with some level of integration along the lines of what Microsoft did with WSL2 is a safer approach.

How hard is this for a new OS to implement ?

I imagine the biggest barrier to adoption is always application support. If I can run chrome on an OS you made last week, I'll be set

Hardware support is always a big issue with a new OS designed to be run directly, it is much easier for a new OS to start the other way as a VM run by a more mature OS. Getting qemu working is also quite a bit of work, although Xen Dom0 support would be easier. There are security implications of the hosting implemention as well. However, long term a general purpose OS will almost certainly want to support VMs so the extra work to do a WSL2-style integration is less than trying to keep up with the large number of complex Linux system calls for direct binary compatability and there are also major security implications to doing things that way.

Would it be possible to implement a VM host in C or something that can compile for a different platforms?

I've never designed an OS so I might be off base here.

This is what most of the existing open source operating systems are and it is much easier to contribute to those or fork one that does most of what you want. If you are aiming at a POSIX system then there is a fair amount of work but you at least then get a huge amount of already written software that you can run (IIUC Redox is aiming for this but written in Rust). A structure like Qubes OS would make it easier to do something less like POSIX while still running some existing software.

If you are interested in OS design, I suggest taking a look at NetBSD. It is a full OS supporting a bunch of different platforms all in one source tree and not quite as complex as Linux while still supporting most software the works on Linux. It has a nice crosscompile system and "rump kernels" that allow large parts of the kernel to be run in userland for testing (I think GNU Hurd also uses this for some device support). I think it has had at least a couple hundred active volunteer developers at any particular time for about three decades now (vs 7 years with mostly one developer it looks like for Redox). It is really quite a lot of work. src/sys is the kernel and src/sys/arch has the platform specific code, such as:

https://nxr.netbsd.org/xref/src/sys/arch/amd64/

https://nxr.netbsd.org/xref/src/sys/arch/x86/

x86 has the generic x86 support shared between 32-bit and 64-bit systems while amd64 has the 64-bit specific stuff. The rest of the tree is relatively easy to understand as well (e.g. most devices are under src/sys/dev), although a few things are in less than optimal place due to NetBSD still using CVS (there are git and hg mirrors so no need to learn CVS). The tech-* mailing lists can have interesting discussions.

https://mail-index.netbsd.org/

https://netbsd.org/

For Linux, LWN is a great resource for learning about OS stuff with in depth summaries of disscusions on many topics as they come up:

https://lwn.net/

It looks like Redox has a web forum, subreddit, and gitlab issues:

https://redox-os.org/community/

Thank you !

If never been good at C, but I'm enjoying reading though this

Is there a chance / goal for ralloc to become the default allocator for Rust itself?

Rust uses the platform-default allocator by default for good reasons.

What are those? For instance jemalloc is generally better than glibc malloc, so platform default isn't necessarily the best choice.

Rust has stopped using jemalloc by default, because often it wasn't noticeably faster, but users did mind additional size it added to executables.

https://blog.rust-lang.org/2019/01/17/Rust-1.32.0.html#jemal...

I don't know anything about building a POSIX OS from scratch. I don't know much about Rust as well. That said, Redox code base is clean and very approachable. Kudos!

I do see a lot of unsafe keyword, are they inevitable?

Why does this reset hardware registers on Chromebooks with legacy boot?

Can you explain in more detail?

Very exciting.

As soon as there's a working compiler it might be fun to implement something like gentoo's ports system, would be quite fun to run something like that as an excercise in how far pure rust can get you. :D

I look forward to the first "distro" of Redox!

I hope that this distro's package management system follows the best practices of The Update Framework[0] or just reimplements a well-engineered existing architecture for distro updates.

Actually the Rust ecosystem is doing some exciting work on supply chain security[1], but it would be good to have something like pacman-bintrans[2] supported from day one of any new distro.

[0] https://theupdateframework.io/

[1] https://docs.rs/cargo_crev_reviews/2022.122.1621/cargo_crev_...

[2] https://lib.rs/crates/pacman-bintrans

pkgsrc has been ported to various OSs, is the default in at least two and supports both binary and source packages. If I were to choose a package system for a new OS, it'd probably be my choice.

As Kerla, this is an excellent project, that they will could be a replace of Linux (as kernel) but not, because they lost the opportunity in the start.

And what is Redox? The website doesn't really say!

An Operating System mostly written in the Rust programming language.

> Redox is a Unix-like Operating System written in Rust, aiming to bring the innovations of Rust to a modern microkernel and full set of applications.

Did you not navigate to the main page?

The installer seems to be broken.

There is no functional installer yet.

redox_installer_tui?

Reply on news.ycombinator.com