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.
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.
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
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"
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.
1. I can definitely see its future in drivers, filesystems, codecs (areas where both performance and correctness is required).
2.
+ 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.
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?
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.
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
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'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.
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.
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.
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.
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.)
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.
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.
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?
> 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?
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.