Redox OS version 0.8 is both strange and very familiar If the words "experimental operating system" don't scare you off, Redox OS is an impressive demonstration of both homegrown OS development and the Rust language itself. Redox OS version 0.8.0 arrives some seven months after version 0.7.0 in April. That seems to indicate that the cadence of new releases is accelerating – it's …
Why are developers focused on making a "general purpose operating system" that competes with Windows or Mac OS X? Both these companies have had a 30-year head start and are almost impossible to catch up to in any meaningful timeframe. Why not focus on a specific market like ARM did with its processors: embedded or server.
A server OS with only command line could be made functional relatively quickly if you use a LibC compatible Rust implementation since you could use most GNU written software. That would leave you with merely implementing hardware support, which is plenty of work for most people's lifetime.
This post has been deleted by its author
Wouldn't it be nice if a home PC was as reliable as a vms system? A gui makes a system more crash prone, but in the case of vms, a gui crash would not bring down the system.
I have only seen BeOS crash rarely. Any futuristic system needs to be responsive to the user and a great system to program for, which is why Haiku is so exciting.
For a good overview of modern OS research, TUNES' wiki has a good page on this:
http://tunes.org/wiki/index.html
I've been following the CapROS project for a few years too. It followed up on EROS, the Extremely Reliable Operating System
[Author here]
I think there are several reasons.
One is that taking on vast and optimistic new projects is a young person's sort of game.
Two, youngsters don't remember the era of small dedicated OSes that did only one or two things, but did them well -- Novell Netware being my go-to example. All they've ever known are big sprawling general-purpose OSes.
Three, the era of wildly experimental small simple OSes, such as Taos/Intent/Elate, or Plan 9, or Inferno, or Sprite, Chorus, Amoeba, even Singularity, was long ago, and so again youngsters haven't seen them.
Novell Netware was amazing. I remember on several occasions a server (over a numbers of years) had crashed and I was told by Novell support to press these keys (Shift+Shift+ALT+ESC keys), do this, type that, and the server would put the process thread that was causing the crash to sleep and and continue to do everything else until an appropriate downtime window could be negotiated with the customers who were probably working on with a deadline to submit a tender to their customers. Fricking amazing stuff. I think that I might have seen one server out of hundreds actually crash crash and that was over several years (turns out it had 2 disks in a raid-5 array die, one disk failed and then the extra stress of the rebuild caused a second disk to die - tape time!).
You could make another server OS, but are more people going to use it as a desktop OS or a server OS? I contend that nobody will use an unsupported and mostly untested OS for a production server, but some would use it on a desktop if just to experiment with the chance that they like it and continue from there. People are more likely to experiment with an OS with both interfaces rather than one that only has a terminal option.
Embedded might work a bit better, but embedded OSes usually have pretty daunting hardware compatibility problems before they're useful, which is why a lot of embedded devices big enough to use a full kernel use projects like Yocto to build them from a lot of components which work with Linux because the manufacturers already thought of it. Meanwhile making it small enough to run for more restricted embedded systems would mean creating a completely different kind of program.
I see real benefit in a command-line server OS written in Rust because of its stability and security. Redox is a microkernel OS which in itself is much safer than the monolithic Windows NT and Linux kernels.
I'm pretty sure take-up will be much quicker than an incomplete graphical OS which can in no way compare to Windows or even Linux for another two decades.
"I see real benefit in a command-line server OS written in Rust because of its stability and security."
I see the potential as well. My point was not that nobody wants it, but nobody wants to test it on servers when it's still this experimental because it's not suitable for production and most people using a lot of servers need something that is.
"I'm pretty sure take-up will be much quicker than an incomplete graphical OS which can in no way compare to Windows or even Linux for another two decades."
It's incomplete as a command line one as well, which is why take-up is going to lag either way. Until they can enhance it a bit more, it's going to stay in the experimental box, and I think it's more likely to get new experimenters with a graphical layer than without it, since you can still use it as a CLI-only system if you like. Since those experimenters can turn into contributors to the OS itself or to software to run on it, that could make adoption and improvement faster. It's very possible that after some more of this, it becomes like Linux or BSD, where there's a graphical layer for those who want it but a lot of the systems don't have it installed or do but it's never in use.
@StrangerHereMyself
"and are almost impossible to catch up to".
I can hear your voice, but I don't want to catch up with any of that "Fisher Price" type stuff they have become.
And to be honest I don't really know what I am talking about or if you are.
Driving a car I admit, if forced with a shotgun, that it's not just about going from A to B.
But using a desktop, a general purpose operating system, am I not just writing this.
Then again I am much past 30 years, and nor Microsoft or Apple have chaugth up with me, quite yet.
Knowing that cargo and crates.io isn't working is actually quite reassuring. It means that the OS isn't just an NPM style mess of package dependencies!
This project is interesting. If we do ever plan to move away from C (for better or worse), the software stack at the operating system really needs to be changed to Rust. Otherwise you do just get a shedload of dependencies in the form of bindings against the underlying platform (ANSI C).
Redox actually implements a C library called relibc that is written in Rust. In other words, if you say strcpy() in C, you're calling Rust code. That said, as it is an interface to C it has to use a lot of unsafe code blocks.
As for crates, I think they are incredibly useful however there are obvious risks that all package management systems (also npm, maven, conan, pip, rubygems et al) share. The crates.io repo is very proactive about protecting crates and weeding out bad actors but nothing is 100% guaranteed.
I see. Well it is good to know that strcpy calls into Rust's equivalent rather than Rust calling into C.
However there is an issue that many developers attracted to that platform (I am talking possibly many years in the future) will just leverage the C shim and not too much will change. Hopefully time will tell.
Rust doesn't have an equivalent of strcpy(). But the code for that function is fairly straightforward, just copying bytes from one pointer offset to another until it hits a zero byte.
https://gitlab.redox-os.org/redox-os/relibc/-/blob/master/src/header/string/mod.rs#L156
It just happens to be written in Rust is all. Other more substantial functions do call out into safe code, minimizing the amount of unsafe stuff to just the entry point.
It looks like relibc is also being targeted for Linux so in theory it could underpin a C program on Linux much like code can already choose between various C libs - glibc, uclibc etc.
strcpy() is irredeemably broken and there is nothing anyone on Earth can do to fix it. Rewriting strcpy() in Rust is a waste of time and shows that the belief that rewriting algorithmically* broken code in Rust will magically make it safe is a cargo cult.
Rewriting strcpy() in Rust is an extreme example of this, but the same thing would apply to other less extreme examples - you just need to fix the actual design instead of writing the same broken design in another language.
* or logically, whatever you want to call it.
Nearly as bad as assuming that all users of Rust believe writing it in Rust magically makes everything safe... each to their own high horse an all.
Anyhow - would you rather have a non-Posix-C compliant OS (i.e. remove strcpy()) or call out to an existing implementation because no improvement can be made when writing it in the language the rest of the library is being written in.
You could always RTFM, relibc is being written as part of redox-os because newlib wasn't doing it for them and there are probably safety improvements which could be made in some places.
Anyhow - would you rather have a non-Posix-C compliant OS (i.e. remove strcpy()) or call out to an existing implementation because no improvement can be made when writing it in the language the rest of the library is being written in.
It would be of more practical use to have a compiler switch that throws an error when an unsafe libc function call is found in the code and forces you to change it to a safe version than just swapping in a Rust version of libc and thinking "job done".
By this time, most libcs are well tested and the rewrite using Rust itself would introduce bugs.
So The Reg counts 3 years between 0.5 and 0.8 and Redox is not quite there yet. If memory serves, Linus Torvalds started his "student project" in 1991. By 1994 Linux was my major platform in the academia. It was not just usable - it had the same UI as the most advanced Sun workstations of the time (and was vastly superior to Windows of the period that I tried and abandoned in disgust) and ran on cheaper hardware (no VMs on COTS HW at that time). You had your personal resource rather than an X Terminal to share a departmental Sun. You could compile the kernel and everything else on it, too - something Redox can't do yet, according to the article.
By 1995 it was difficult to find anything but Linux at 2 US universities I was then affiliated with. In 1996 - and ever since - it was ubiquitous in at least some industries.
Yes, I suppose the distance to cover was shorter then and the requirements today are different. E.g., Internet was simpler. But maybe the overall architecture of GUI on top on Open Look on top of X on top of kernel, with shells and tools thrown in, helped making it all usable fast? I am pretty sure that keeping those old system calls (I've given the "Why Redox?" page linked in the article a superficial glance) that allowed other stuff to run helped a lot. And therefore I am curious: does Redox have a version of libc (and maybe sockets and some other stuff) that sits atop its new syscalls? That has been done, too, e.g., for InfiniBand to bypass the kernel without re-writing applications. Would such a "distraction" help running "legacy" (FOSS) stuff for usability's sake without hindering the interesting OS R&D?
In any case, somehow (less than) 3 years from inception to being perfectly adequate for everything I needed for my thesis, later academic research, and still later industry work (none in computer science, though computer-heavy) seems to me a bit more impressive - in terms of pace of development only, mind you - than what this article presents about Redox.
You'd have trouble fitting a useful linux kernel image itself on a single floppy disk (even with a compression format) these days. You'd have to split the file on a floppy set, have another floppy set for your initramfs image (and you would need one, if expecting this kernel to work on varied systems), and another set for your rootfs. It wouldn't surprise me if you used 10 floppies just to boot to a shell prompt.
So I'd have my doubts too, that any new operating system is going to boot from floppy disk media :-)
> By 1994 Linux was my major platform in the academia. It was not just usable [...]
> and was vastly superior to Windows of the period that I tried and abandoned in disgust
OK. I am happy that you found it usable for your work then.
I first tried Linux in 1995, with a Lasermoon Linux-FT boot CD.
I also tried to install Linux on my own machine at home around then: a Sunrace 486 laptop, with a small on-board IDE disk (maybe 20MB) and built-in SCSI to which I attached a CD-ROM and a Bernoulli Box removable hard disk, which dual-booted DR-DOS and OS/2 2.0.
I failed; I could not work out the necessary incantation to the `aha152x` driver to tell it the I/O and IRQ settings of the SCSI chip -- a cheapo Adaptec controller only really meant for a SCSI scanner -- and so I could not get the kernel to "see" my CD or the external HDD.
As such, I strongly dispute your statement that it was "not just usable" but "vastly superior to Windows".
At work, I ran NT 3.51 on an Intel Pentium 66 made by Panrix with the Neptune chipset and an all-SCSI storage stack: several hard disks, a CDR, a multi-disk CD-ROM changer, a tape drive, a scanner and so on. It was the first time I ever filled up a SCSI bus, and I completely removed (not disabled, pulled out the PCI card) the machine's IDE controller.
For me, at that time, Linux was an amusing curiosity. I had already installed and maintained multiple machines running SCO Xenix and SCO Unix by then; I had been working with Unix professionally for approaching a decade at that point. Those machines supported multiple Wyse terminals and ran multiuser accounts such as TetraPlan and Tetra Chameleon; I also got MS Word for Xenix and WordPerfect for Xenix running on them.
Real production work, but no GUI, no networking, no C compiler, no email; isolated standalone systems, backing up to tape, driving text terminals and printers.
For me, in my mid-1990s day job as a journalist, kernel 1.x Linux was a toy. It was impressive but it was useless. It could not talk to MS Mail, the email system I had built, installed and administrated for the magazine. It could not access our NT server, which I also ran, or our labs Novell Netware 4 server. It could not talk to the in-house FirstClass email system, hosted on a Mac. (I reviewed that email server for MacUser magazine, out of interest.) There was no offline reader for the CIX system we used for dial-up email and conferencing.
NT 3.51 could do all of those things, with rock-solid reliability, and superb multiprotocol networking. It also ran MS Office 4.x for my day-to-day work. It had a good usable and fast GUI, which was nicely customisable. It was a lot more reliable than classic MacOS, or than Win95 which was just starting to appear on some machines. It was also more reliable than OS/2 2.0, contrary to what OS/2 fans liked to claim. I was an OS/2 fan; I paid money for it, because IBM wouldn't give us review copies until it was too late and Windows had won.
Early to mid 1990s Linux may have been useful to you. Good for you. I professionally evaluated it.
In 1998, I helped SUSE UK put together the first (heavily cut-down) distro that PC Pro put on a cover CD, and I wrote an accompanying "Linux Masterclass" that carefully instructed readers on how to build a LAN server for a small business network, with file and print sharing, desktop-to-desktop email and so on, and a dial-on-demand masqueraded IP network link to the Internet.
By that time, I also owned a Sun SPARCstation IPX, which ran what you term the "industry standard UI". It was pretty in its minimalist way, but it was appallingly clumsy and clunky compared to Windows 9x, and Windows 9x was pretty poor compared to MacOS 8.x or 9.x.
So, no. I disagree. I was there. I worked with this stuff. In my considered professional opinion, it was _not_ usable; it was horribly unfriendly; if you could get a GUI up and running it was ugly and clunky; and it was not ready for mainstream use in an office environment, either writing copy, editing it, or laying it out.
It can certainly do that _now_, nearly 30 years later, and I am typing this on Linux, and I will submit it to a Linux server in a second.
But in the mid-1990s, it wasn't even _close_.
If it was suitable for use in academic and research settings, great.
But it was not ready for prime time, in general office use by nontechnical users, and it would not be for roughly another decade and a half.
Nor is Redox OS yet, but given that it took 5 years to get to 0.5 but only 2 more to 0.8 and it's heading for 1.0, yes, I think its progress is respectable.
But they key question is not that; it's whether it can offer enough gains over existing FOSS OSes to beat them in the market, even if that market is one of free users of free OSes and apps.
Linux was not usable for nonspecialists before it got to 1.0 and in my personal experience it wasn't between 1.0 and 2.0 either.
But by kernel 2.2, when KDE 1 was available, it was getting there. I used Caldera OpenLinux as my main desktop OS for a while and I liked it.
I can't remember now what kernel Ubuntu 4.10 shipped with, but that was a pretty usable OS and far ahead of Debian or even Red Hat Linux.
Jeremy is also the lead engineer at System76 working on both Pop!_OS and open firmware, and is also the parent of two children. Given those constraints, Redox is already progressing rapidly compared to Linux. Software requirements are much more complex today than it was back then, and today there's already Linux so there's not much pressure to make something to replace it, so times are also different. But one thing that Redox has going for it is that it can leverage the bulk of the open source advancements made by the Rust community and Pop!_OS. iced, slint, and libcosmic are already cross-compiling to Redox, and COSMIC itself may find itself there too.
I'll probably never use this OS, but even as a proof of concept that Rust could be used to build a functioning OS makes it interesting.
What I wish the FOSS world would do more of, is this sort of thing. Instead of just carrying on where Unix left off, and chasing the taillights of Apple and Microsoft, I'd love to see them trying out all kinds of whacky shit to see what works. They aren't beholden to shareholders who demand fat profit margins, or corporate schedules, market research... FOSS developers can try out anything and everything. If it doesn't work, they can just move on to the next idea and leave the code out there. Maybe someone else will come along and figure out how to make it work, or they can retool parts of it for another idea.
There's a list of operating systems written in Rust and quoted below:
There are several open source operating systems written in Rust. Most of them are proofs of concepts. The only system that goes a step further is redox. It comes with a window manager as well as basic applications like an editor and a file manager. Theseus is approaching maturity with the ability to execute legacy components in a WASM sandboxed environment.
redox (repository / homepage)
Theseus OS (repository / homepage)
Tock (repository / homepage)
intermezzOS (repository / homepage)
reenix (repository)
rustboot (repository)
RustOS (repository)
QuiltOS (repository)
Tifflin (rust_os) (repository)
bkernel (repository)
Quasar (repository)
SOS (repository)
https://github.com/flosse/rust-os-comparison
Some are for embedded use or other research projects.
The point of this is to show that Rust can build show a solid, stable, secure system. The future of computers gets brighter all the time.
"striking a happy compromise between a familiar user experience, a modern underlying design, and cutting-edge development tools."
Haiku does this today. And it supports rust, but it will not be rewritten in Rust.
There's a list of all the os projects written in Rust here:
https://github.com/flosse/rust-os-comparison
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
