Redox – A Unix-Like Operating System Written in Rust

"No, those do not perform well. They are just less horrible than GNU HURD. When you apply similar optimization and implement similar functionality, monolithic kernels always win. It cannot be otherwise; think about it."

I do. It doesn't have to be better. It simply has to perform well enough that users accept it. Older systems did that slowly. BeOS was a great example where it was running on 90's hardware several movies, graphic animations, a song, and productivity apps all simultaneously with no slowdown. Blackberry Playbook outperformed iPad in tests I saw in responsiveness with one demo running a 3D game with other intensive apps simultaneously. It's at the point where Linus et al's argument about performance being too limited is ridiculous. Only users maxing out performance with little care of reliability will need a monolithic kernel on COTS hardware.

"Self-healing is generally a security problem. It gives the attacker a second chance. It's also generally a failure."

What are you talking about? There's a bit of extra attack surface due to more code and interactions. The first one, though, was implemented in KeyKOS kernel whose total size was around 20Kloc. MINIX 3's Reincarnation Server is straight-forward, too, given how components it restarts are designed. It's actually easier to get this right than reliability and security of monolithic systems since it's simpler and smaller than them. I mean, starting with UNIX Hater's Handbook and such, it took monolithic UNIX (and Windows too) decades to get where they are in reliability and security. The stuff I push got most of that done in first few years with a handful of people plus acceptable performance. So are you arguing against microkernels getting it done or in favor of throwing 8+ digits worth of labor at monoliths to achieve similar results? Neither look good in face of evidence.

"Tanenbaum is biased. It's time to move on"

Tannenbaum's is most immature system on my list. I could drop everything he's ever said and done while still having others as exemplars for mainframe, embedded, and desktop use that had acceptable or great performance with better security and/or reliability. You must have a beef with Tannenbaum or something. I respect his work & like the one presentation I watched but don't need it to back my claims.

"Hardware may be in a strange state, needing a power cycle to restart. Other things start failing once one driver is down. Most systems are unable to keep DMA from scribbling all over everything in RAM, and probably all are unable to keep it from scribbling all over a filesystem."

That's all interesting except these kinds of systems, esp proprietary ones, have been in the field for years in systems where failure and unpredictability had to be minimalized. They worked as advertised. Security-focused ones also passed pentests and analysis by people who knew what they were doing. These kinds of things are where monoliths, esp UNIXen and Windows, often failed or took crazy amounts of labor. Even the immature MINIX 3 is more reliable than you describe with all kinds of failures at the component level for a system that stays up. Your DMA example shows you're really grasping at straws to fight microkernels with an example that (a) represents a tiny set of failures in complex HW/SW systems and (b) still applies to monoliths with the exact solutions available for both styles.

Btw, the first IOMMU I found was in a system called SCOMP: a microkernel-like system that was first to be certified to high-security after IIRC 5 years of analysis and pentesting. Name one monolithic OS that pulled anything like that off. Don't worry, I'll wait.

Interesting article on Minix by Tanenbaum which featured on HN recently: http://cacm.acm.org/magazines/2016/3/198874-lessons-learned-...

"I liked the juxtaposition of that haha. It kind of negates anything about Rust in your counterpoint."

I almost removed that at the end. I wasn't trying to say much about Rust except that it wasn't predicated on this idea of quickly spinning up new, conceptual types with specific constraints like Ada/SPARK. That sort of thing is really either infused throughout a language, or it isn't used. It doesn't take a great deal of familiarity to see that much.

Actually, just for this response I went and looked into it a little more. Rust has a tiny bit of syntax sugar for creating structs with positional members. So, you can at least wrap things in a struct a little bit easier than in C++, as you don't need to name the internal value. That's really not enough.

Really I mostly wanted to show that Ada also has some means of helping with memory safety - while also being focused on safety/correctness in general. I suppose on that front (and while I'm pushing Ada anyway) I should also mention Ada has a built-in concurrency model, although I suspect you may already be aware of this.

"Ada FOSS community is barely there with biggest deliverables coming from AdaCore."

Yeah, this is the biggest bugbear when it comes to Ada. For what it's worth, there has been some new life on that front and people are working on improving things. So far it's still very, very early days though. The biggest news so far is Gnoga, a web-socket based, uh, web framework that's usable with Gtk WebViews. It will take awhile, but hopefully this trend will continue and the Ada FOSS community will be able to rouse itself.

If you can't tell, I'm not quite ready to count Ada as a lost cause. If it is, and we are looking at running with a new, safe language, at a minimum we shouldn't be forced to take some serious steps back. I'd have loved to see Rust focus on general safety and correctness rather than just memory safety, but it didn't. Losing all that is a rather bitter pill to swallow.

"Ironsides..."

Totally reasonable, and I think it would be very interesting to see.

"Far as Ada vs Rust..."

I've been really hoping to find a good comparison for some time now. I know Rust is able to make stronger guarantees about memory than Ada/SPARK can, but it isn't able to handle every case. I'm really curious to see how well Ada/SPARK is able to handle both what Rust can prove, and what it can't. I also don't know if Rust offers any more imprecise safety nets for the cases it can't prove. Finally, I know nothing about how Rust handles concurrency, so that would be another great comparison to see.

"Note: You should get a real account if you're a programmer AND know Ada/SPARK. Seriously under-represented here."

I might. The plan was for this to be a rather temporary account, but it seems to have stuck.

> Good work. Not quite an OS like what they're trying to build, though.

Absolutely, that's why we managed to get something that worked, despite being at least six times as few people who also had to work on other projects :-). Redox is an order of magnitude more complex, because it's trying to solve problems that are an order of magnitude more complex. I just want to dispel some of the "black magic" air around these things.

> Side note. I'm peripherally gaining information on doing 8- or 16-bit software for microcontrollers. Hell, I even have some docs (and maybe HDL source) on a 1-bitter although with 8-bit ALU. Do you have any resources I can give to new people showing the tricks people use to reliably do complex or fast stuff with them? SymbOS would probably be high-end of that but I intend to use them in peripheral controllers, monitoring, and such.

You mean re. digital design, or microcontroller software?

If it's the latter, I'm not sure what to recommend... most of what I know is stuff that every programmer knows + experience you get out of working on embedded devices (and, of course, failing a lot). Fundamentally, programming these devices is no different than programming other computing devices (save, perhaps, for the Harvard architecture, but that's fairly inconsequential), you just work based on other assumptions regarding what's acceptable in terms of failure, performance degradation and so on.

I guess related resources that might help a lot would be:

* Jean Labrosse has a series on his uC/OS kernels. I think the latest is uC/OS-III. I haven't read it, but Labrosse's work in general is extraordinary, so this book may be what you're looking for.

* If you don't mind Ada, Building Parallel, Embedded, and Real-Time Applications with Ada is a pretty good book on the subject, too. I've skimmed it and at least the aspects related to reliability are well-treated.

* If you haven't already read it, van der Linden's "Expert C Programming" is still a very good read. I don't doubt that languages such as Rust and Go are the future for programming higher-end systems, but I don't see C going away on the lower-end in the next 10-15 years, and frankly, I don't think Rust solves too many of the problems I encounter on these systems.

* For dealing with resource-constrained systems in general, Bitsavers.org has exceptional stuff, but it requires some digging and extrapolation. Old computers are a semi-serious hobby of mine -- it's fun, but I also learned a lot of interesting things from studying old systems.

Good recommendations may come from Ganssle's (www.ganssle.com) Embedded Muse, too.

Oh, speaking of which...

> I have text files and PDF's I send to people that ask.

...can I ask :-)?

If they are a dead end, why do they rule the embedded and real time OSes?