Hacker News new | comments | ask | show | jobs | submit login
Show HN: Redox Rust OS – v0.3.3 release (github.com)
232 points by jackpot51 on Sept 20, 2017 | hide | past | web | favorite | 76 comments

I've been seeing Redox develop for a while now, and I've got to say—it's really amazing what such a small group of people can accomplish. They have innovative tools in all sorts of areas of computer science. Including coreutils, binutils, a shell (along with a custom shell scripting language), common GUI applications, a hash function, a file system, etc.

One of the coolest aspects of all of these tools are that they aren't exclusive to Redox. In fact, they are rather portable. For example, the new file system (tfs) can run on operating systems other than Redox. One of the team members wrote an "atomic hash table" for it, and it was open sourced as well. It even uses an open source hash function by the same author.

Congrats to the team. Writing an operating system is incredibly hard, and it's great to see something like this written in Rust. I'm a big fan of all of the core contributors, and can't wait to see where Redox goes.

I’ve always found it weird that things like file systems in the Linux kernel are so tightly coupled. Why isn’t, say, Ext4 written like a library? (Or is it? I don’t think it is?)

Stub out the interface that the kernel needs, and provide an interface for the bits (reading disk blocks and so on) that the file system needs from the kernel. This way, you can decouple it completely from the kernel, test it independently, port it without forking the code, and then it can easily be used in userland, too.

This is the recurring argument about "monolithic kernels" vs "microkernels". In the latter different user-space processes can be used to implement filesystems, networking, etc.

There are a lot of small operating systems that take the decoupled route - but you'll almost certainly never see them because they're either research-based, or suffer from the problem of most hobbyist operating systems which is "lack of hardware support". Doesn't matter how modern/sexy an O/S is if you cant run it upon your hardware. (Relatedly once you can run it you need software on it too..)

That said there are some compromises available, even with Linux. If you use something like FUSE you can write your own filesystem in 100% user-space - something I've done for a couple of niche applications.

Notably, NetBSD has recently undergone a successful effort to implement such a decoupling of subsystems, while still remaining a monolithic kernel. Lo and behold, it immediately boosted the ecosystem of hobbyist FOSS OSes, by letting them easily reuse chosen subsystems (see e.g. Haiku, GenodeOS). It also certainly helped that NetBSD is BSD-licensed. If you want to learn more about the effort, search about "rump kernel".

It's also not just about monolithic Vs microkernel: Linux could decouple filesystem drivers without becoming a unikernel e.g. by specifying a fixed driver API - you could just load FSs as kernel modules. The reason for tight coupling is just that devs don't want to commit to a stable API. If you are only talking about a single kernel version, FS drivers actually _are_ decoupled this way (can be loaded as modules) and distributors do this.

This is fine until optimisations are needed. Most meaningful performance work requires changing data structures which impacts the shape of the interface.

One reason is that it helps keep Linux free by making it harder to pull code out of the tree or maintain out-of-tree drivers, which encourages people to contribute their changes upstream.

Doesn't the GPL ensure this?

You can write kernel drivers that are not GPL, which is difficult with the continuously changing internal kernel API.

Decoupling is not the strongest suit for Linux developers however as somebody pointed out there is already other projects to enable user land FS.

I feel this statement is a bit unfair. Much of the tight coupling has been a design decission. There has been a lot of public discussion about it.

This already done. FUSE

I agree -- I've been somewhat negative about Rust, but it looks like Redox is one of the projects doing "real work" with it. It's an impressive vote of confidence for the language.

Also, I'll pat myself on the back and say the Ion shell looks nice, because it borrowed some ideas from the Oil shell [1] :) In particular, we talked a fair bit about the array syntax and semantics, and lack of word splitting.

[1] http://www.oilshell.org/

Curious, what makes you think Rust isn't be used for "real work"? So far there's a high performance browser (servo + servo components in FF), kernel (Redox), parallelism library (Rayon), grep replacement (ripgrep), all written in Rust, that are somewhere near best-in-class (Redox is debatable but that's mostly due to the fact that the success of an OS requires many non-technical factors).

All this in a language that's ~2 years old is pretty impressive.

Webrender, the next gen rendering/compositing engine for Servo, will become the default renderer for Firefox Nightly at the end of this year and several components like CSS and URL parsing have been in Firefox stable for a while now. That alone puts Rust in the multi-million end user club for some complicated software

Beautiful project- and home page!

What does "word splitting" mean in this context?

Word splitting is the difference between

    $ var='my program.py'
    $ python $var

    $ python "$var"
You need double quotes to protect against word splitting. Almost all shell tutorials guides hammer this point home repeatedly, because if you omit double quotes, it works most of the time, and then blows up with incomprehensible error messages when you have spaces.

If you have a filename with spaces, like "my program.py", then python would be invoked with TWO arguments in the first case ["my", "program.py"].

But it will be invoked with single argument in the second case ["my program.py"], which is the correct thing.

I talk about how word splitting is really a hack around the historical lack of arrays in bash here:

"Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays"


I am the creator of Redox OS. It is a microkernel based operating system mostly written in Rust.

Please ask any questions or make any comments you have about Redox!

EDIT: I am going to sleep soon. I will be up in 8 hours, 7 A.M. Mountain Time.

Your works are very amazing! I have three questions :)

1. Could you say your opinion about future of Rust. Will it become mainstream?

2. Pros/cons between Rust and C for system programming?

3. I heard many times that implementation of standart data structures like RBTree, Graphs without recursion traversal in Rust it's very difficult and painful tasks with unsafe hack code. So if i am Rust beginner i should avoid learn this language through implementations my own data structures(BST, AVL, LL, ...)?

*sorry for my English. It is not my native language.

Not OP, but maybe can help:

1. I can definitely see its future in drivers, filesystems, codecs (areas where both performance and correctness is required).


+ Rust has fantastic error handling. No null pointers. Mandatory error checking, but with very light syntax.

+ Dependencies and modularization in Rust are soooo much easier than in C.

+ You never have to write `free()` again.

+ Thread-safety can be guaranteed at compile time.

- Significant learning curve. You need to "get" Rust's ownership approach before you even manage to compile a non-trivial program.

- It's still "new", so it may be hard to convince people to use it. C is 45 years old, so it seems like a safe bet (it has flaws, but the flaws are well-known).

3. What Rust calls "unsafe" is what all of C is, so it's never worse than C. The idea is that you carefully implement these structures using raw ("unsafe") pointers, and wrap them in a safe Rust API. This way you need get it right once, and rest of the code doesn't have to worry about breaking things.

> You need to "get" Rust's ownership approach before you even manage to compile a non-trivial program.

I'm not entirely certain that's true. I wrote a useful (to me) cli script and only have the vaguest understanding of how the ownership model works. I think for text processing sorts of tasks, it's not too difficult to use.

As someone learning rust and currently going through this, I would consider that a trivial program. You will know once you get there because you hit kind of a wall where you have to learn and understand what is basically a language inside of a language. And the language is kind of this mapping for logic that only used to be inside of your head (ownership logic), and so translating that fluently into this brand new language is a real roadblock.

The ownership model isn't too bad for strings, but those are easily the most simple way to start using the ownership model. At least for me, getting into the more advanced ownership stuff is a whole different beast entirely.

Beginners frequently trip over `&str` vs `String`, but other than that I agree w/ you

Is Orbital the desktop for Redox, or are there plans for a modular DE/WM system where other desktops can be slotted in and selected from the login screen, or wherever? If it is going to be modular, are there any plans for compatibility with Linux DEs?

Yes, there are plans for others. Orbital is not tied to the lower level framebuffer driver, so it would be possible to write or port other GUI stacks.

Could you write default username/password on a release page? :)

I have added it. The username is `user` with an empty password, or `root` with a password of `password`.

The only way to change this at the moment is to edit `/etc/passwd`, where they are stored after being encrypted using argon2.

>after being encrypted using argon2.

Nitpick: s/encrypted/hashed/


What is your background? Like how many OSs have you written not in Rust?

I wrote a toy OS in 32-bit assembler when I was younger. It was terrible. Unikernel, basically, with no memory protection.

I then rewrote it in 64-bit assembler, for fun.

After learning about Rust, I immediately went to work on Redox. The bootloader and framebuffer initialization code were lifted from the old toy OS's.

How much unsafe code is in redox and the core utils and what are you doing to ensure that you don't end up with the same bugs in your unsafe code that you find in C codebases?

i watched an interview you did on a podcast some time ago. i found it to be very interesting! in that interview you said that redox was not going to become a viable desktop operating system for a long time. you seemed to even dismiss the sentiment. is that still so?

I personally will use Redox once it is self-hosting as a desktop. However, there is a long, long way to go - wireless, graphics, and audio drivers must be improved.

> (just a hobby, won't be big and professional like gnu)

How long until emacs ? or I should say remacs (rust ported emacs by Wilfred Hughes :)

Not sure. We just got termios support, and pthreads is WIP, so many programs like emacs should be portable.

I'm done with other oses

What are the most common classes of bugs you observe?

I would say the most common are logic errors.

Seems to be the state all programers wish they were in, but only rustaceans practically find themselves in, assuming "logic" equates to "human rationale" regarding an arbitrary topic

any plans to port it to mobile phones? If anyone worked on porting a touch-based input drivers I could contribute!

Mobile phones are extremely diverse. Attempting to target any more than one model would be very difficult, and that one model would need to be owned by all contributors.

I wish to have an OS able to run DirectX same on window :D

I've been watching Redox on and off since its inception, and I must say I'm really impressed at what it has achieved till now. It is a fully functional OS with binutils, terminal, calculator etc, and this is a win for the whole FOSS culture.

What are the potential areas where Redox could be beneficial ? I would love to run on Raspberry pi, older Androids or Routers etc. Is it doable?

I'm also curious about the benefits that redox offers vis-a-vis bare metal Linux (Alpine/Void etc)?

> I'm also curious about the benefits that redox offers vis-a-vis bare metal Linux (Alpine/Void etc)?

Security (Redox' stems form the language, Linux' stems from being widely used). Hackability (smaller, more modern, more hackable language). Simplicity.

> What are the potential areas where Redox could be beneficial ?

To put apps on VMs with a very tight and secure OS underneath.

> To put apps on VMs with a very tight and secure OS underneath

Hmm. Have you bounced off ideas with the Qubes OS team yet? It could be an option for the core OS/microkernel of Qubes OS.

And/or, maybe even better, with the GenodeOS team?

What is the security model of Redox? We’ve heard a bunch recently about the capabilities security model in Fuschia/Zircon, which is the other new operating system that excites me. Can you compare the two?

Somewhat capability based. If you do `cat sys:iostat`, you can see part of what I mean. Most operations happen on a file handle which has the properties of a capability.

We still need to do more work on it though.

I expect this sort of work doesn't get enough praise because it's just the start of what a full OS would look like, but I think having OS kernels written with more memory safety is awesome and necessary.

I believe it is only just beginning. There are only about a dozen regular contributors, which would be very small if comparing with Linux distributions.

Yes, specially since we already lost many of them since the early 70's, mostly due to politics and bad management decisions.

I wonder why Redox has so high requirements, 1GB of RAM looks like a lot for pretty much toy OS. I'm using server running on 256 MB RAM and it's enough for quite a lot of services.

Redox can run in 256 MB if it is installed to disk, and is not running the GUI.

What is the breakdown of the ISO size? It's now 430MB - what are all those bits? (I ask because, as a new OS, I'd expect it to be really tiny since it's so new.)

- 64 MB - Preallocated kernel buffers

- 256 MB - Live filesystem

- The rest - Running applications

Hey there, thanks for the response. Just DL'd the ISO and it's only 38MB. I think there is some ambiguity when you say "Lower Memory Usage" and then talk about "ISO size". I was expecting the download to be 430MB!

Also, I ran the ISO in Virtual Box and it's far more than I thought it would be. It's not just a barebones kernel and shell, you actually included a simple window manager and some GUI applications! It booted nice and fast, too.

Great work.

How realistic is it to run processes of this OS (like the netstack processes) on top of existing microkernels like minix/QNX/etc. ?

Will it work with virt-manager, or it requires manual Qemu/KVM setup?

Pretty much all standard functionality in QEMU is supported by virt-manager, only for weirder things you need to escape to manual command line use.

Great. I'll give Redox a spin.

Very impressive, but I'm still disappointed they are mostly copying Unix, rather than trying to improve it. E.g. based on the names, the coreutils are identical.

While I completely agree that there are Unix idioms that could go by the wayside, the team is already taking on an enormous project. Reinventing standard practices at the same time (and the ridiculous bike shedding that would ensue) seems like an even more impossible task.

Good point, but opportunities to fix fundamental things like 'dd' existing, or unstructured piping are rare. Shame to waste them.

Ok, I have to ask. What's wrong with dd?

Strongly agreed.

Especially since multiple successors to Unix already exist -- notably, Plan 9 and Inferno.

If you have ideas, then you should pitch them on the corresponding GitHub projects.

Any null pointer deference, overflow so far and how if so?

There have been overflow bugs, usually logic errors during subtraction.

I encourage the use of checked subtraction and addition to prevent these from becoming issues.

Hey Ive built it on Voidlinux and ran it with Virtualbox but my touchpad dont work yet with qemu no problems with touchpad. Superb efforts! Great work devs and contribs! Such an enormous task and I hope joy is a result :)

I have a question. In the fuchsia/zircon thread some people (committers?) were saying that Rust was not suited and would be difficult. Redox is also a microkernel. So are there any limitations or not?

Limitations of Rust or of microkernels?

Rust has not impacted development in any negative way. On the contrary, it has been incredibly helpful and has boosted development.

> In the fuchsia/zircon thread some people (committers?) were saying that Rust was not suited and would be difficult.

The only thread that I saw was someone decrying that Zircon was written in C++ rather than C, which later turned into a discussion on Rust. I haven't seen any Zircon committers comment on Rust; can you find the link you're thinking of?

I may have been mis-remembering. I was hoping to see more Rust in it since it was new.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact