So, after talking to @jackpot51 on a GitHub ticket, where he advised me to just run Redox in a VM after I told him it wouldn’t run on my hardware, I noticed the extreme speed there and flipped my s***.
So, I know a guy named Scott who’s an intern at NASA in the hardware and software engineering fields, and I had to show this QEMU setup to him. I knew I wasn’t insane when his reaction was the same “taken aback” reaction I had - if I had tried like, Ubuntu or Fedora in it, it would have taken a lot longer to start. No, start Redox, select a res, and BOOM! It’s there.
I know this project is relatively young, but as a freshman in the CS field, I have to wonder why this thing loads so fast. Would a similar implementation be as fast in C? I know at the end of the day, everything gets compiled down to assembly and whatnot regardless of if you use C or Rust, but I want to know if this speed can safely be attributed to the usage of Rust and its direct memory safety mechanisms (borrowck, etc), or if it’s just the design of the OS and it doesn’t matter if you do it in Rust or C.
Honestly, I want it to be the fact that it’s entirely Rust, but I can’t say that’s true because of my bias for Rust over everything else. I want to know if my judgement is just confirmation bias or not.
I’m not very versed in Redox in particular, but my experience suggests that the speed you are witnessing is due to it being young and slim. Established mainstream operating systems like Ubuntu or Windows simply have a lot of accumulated bad designs that slow things down to a crawl. It’s not really about Rust being faster. It’s about Rust being more efficient as a language – it makes correct code much easier to write. With C, everything is a huge chore, so when you finally get the system to a working order, after cramming in a hundred different kinds of bottlenecks, you just shrug and vow never to touch that perfectly reasonable working code again, for fear that you would break it and never be able to fix it again, or worse, never be able to notice the new bugs until something like heartbleed happens (more likely).
It’s doubtful that the “speed” you are seeing it primarily attributable to it being “Rust”. The vast majority of the “Speed” at this point is because it isn’t actually doing that much on start up. Very few background processes are loaded and running. Very little hardware is initialized. That being said, RedoxOS has the opportunity to avoid a lot the legacy of other operating systems and so hopefully, even when it is starting up similar processes and hardware it will be “fast(er)”. But, remember, the point of Rust is “Safety First, Speed Always”.
Next round of questions, I guess (@gbutler69 and @jzr and whoever else might wanna step in):
So, if we brought Redox up to feature-completion with Linux all in Rust, what would the benchmarks be like?
Would the system NEED the same amount of junk loaded on startup to function the same way?
Would the speed on startup still be noticeably faster?
Do you guys think Redox will become a large OS that is able to be used for daily tasks EVENTUALLY? I say this because I feel like the team behind it did more stuff faster than the GNU/Linux community did - sure, you can track components, but I feel like Redox did everything from the ground-up in just over two years without re-use of code for the most part.
It’s a microkernel, so I could easily see the ISOs downloaded only containing things specific to the target platform, whereas I hear Linux has EVERYTHING, just that most of it isn’t seen. That’s what people say slow it down. If this is a microkernel, maybe you could select the drivers you need during setup - they all run in userspace anyway!!
I guess it’s interesting to poll community members who are into the project…I like seeing the different opinions. Especially because this project, unlike others, is new territory. It’s not Linux, BSD, or any others. It’s one-of-a-kind. That’s why I like it so much.
With respect to your questions, I’d first say, that focusing on “Speed” or “Being faster than ? OS” is not really the point of Redox. Just as speed is not the primary focus of Rust.
The point of Rust is to provide memory safety and concurrency safety with as little run-time overhead as possible. That means that if the choice is between making it faster by breaking the safety guarantees, the slower path will be chosen. Redox being a Micro-Kernel OS written in Rust is focused on safety as well. It gets memory and concurrency safety from Rust and also other kinds of safety by virtue of being a micro-kernel.
Micro-Kernels are known to be not quite as efficient as monolithic kernels due to the necessity of 2 context switches, as opposed to 1, on every system call. There are many strategies that have been, and continue to be, explored for optimizing micro-kernels to make them as close as possible in performance to their monolithic brethren, but, to my knowledge there still is a performance gap due to the double-context switch. So, it is unlikely all-in-all for Redox to end up being the “fastest”, but, again that is not the point. The point is “Safety First. Performance Always.” That means that safety/security will trump speed when it comes to choosing how things are implemented, but that, the developers will always seek ways to make it faster/more efficient/perform better while maintaining the safety and security.
Now to answer your questions more directly:
Redox does not intend to necessarily have everything that Linux has. It does not intend to replace or supplant it (though who knows some day). Its purpose is to prove out building a more secure/safe OS on top of the safety and security guarantees of Rust and see where that leads.
Probably. Mostly. Maybe not. We’ll have to see!
Start-up speed has more to do with how much stuff is loading and how much of that loading happens in parallel versus in a serial fashion and how much processes that are starting up block other processes from completing their start-up. For example, if there are 30 processes that need to start up, and 25 them start in 50ms each, 4 of them start in 150ms each, and 1 has to wait on network resources or something on start-up for and indeterminate amount of time (capped at 60 seconds) and you start all the processes in a serial fashion, then, the entire startup time would be 25 * 50 + 4 * 150 + 60000 ms at a maximum (I’ll leave the arithmetic to you). However, if you can start processes in parallel and only a few processes block only a few other processes from loading, you could have something faster. Parallelizing the start-up of processes, and delaying start-up of background services until they are actually needed, is something that systemd under Linux attempts to solve. At some point, RedoxOS would likely have some mechanism that would be similar in nature, or at least purpose, to systemd.
Hopefully it will become a real player in the OS market. That remains to be seen. Like any project, you can’t know the future. I’m sure everyone working on it wants it to succeed. I’m not really certain how the development speed of RedoxOS compares to the early days of Linux development, but, remember, Redox has the benefit of a lot of sophisticated tooling around shared/distributed development and the communication between developers, that didn’t really exist at the same level in the early days of Linux.
I guess I’d have to say that you should probably study both Linux and Redox before jumping to any conclusions as you’ll likely get to the wrong conclusions if you don’t have full understanding of both.
BTW: I’ve only recently begun contributing (or attempting) to Redox recently so I would not consider my opinions on the matter to be anything close to the final word. In fact, they are just my opinions as I currently understand things.
It’s a microkernel, so I could easily see the ISOs downloaded only containing things specific to the target platform, whereas I hear Linux has EVERYTHING, just that most of it isn’t seen. That’s what people say slow it down. If this is a microkernel, maybe you could select the drivers you need during setup - they all run in userspace anyway!!
That’s a misconception. Linux is actually a modular kernel, and most of it is never loaded. Time spent by the kernel’s own initialization is probably dominated by detecting hardware and loading and initializing drivers. Redox won’t spend time on that because it doesn’t yet have those drivers to begin with. Of course, with linux, you can avoid that overhead by compiling the necessary modules into the kernel, and disabling everything you don’t need. Gentoo users in particular have an obscene interest in custom configuration of everything. It can be done, and it’s not even very difficult.
Do you guys think Redox will become a large OS
Maybe yes, maybe no. It’s too early to tell.
Would the system NEED the same amount of junk loaded on startup to function the same way?
In short, yes. The amount of unnecessary junk is almost always proportional to the complexity of the system, because reasons. On the other hand, making a new system that functions the same way as Linux would be madness.
So, if we brought Redox up to feature-completion with Linux all in Rust, what would the benchmarks be like?
That’s a heck of a question. Benchmarks of what exactly? Disk I/O? CPU-bound computation? IPC messaging? TCP/IP stack? There are a million little pieces, each of which can be a faster or slower than the Linux’s analog, and each of which affects real-life applications in a different way. Can Redox be “faster in general”? Sure. Any system can be, if written/configured right. Can Redox be “slow as hell”? Also sure. The question doesn’t really have any answer except “wait and see”.
I am a total nub but in my opinion it is very likely Redox can become significant. 2 large use cases would be security appliances and general purpose app/web servers. Rust has very good chance of becoming a popular web dev. platform and as soon as rust compiler gets ported to Redux and enough drivers to run on a modern x86 server are available it would become a very attractive os for above use cases. It would be also nice to be able to run PostgreSQL but for most deployments db servers are separate boxes/instances anyway.
On the other hand, making a new system that functions the same way as Linux would be madness.