Redox – A Unix-Like Operating System Written in Rust

Thanks for the heads up on the Ada book.

I also share nickpsecurity ideas on memory safe systems programming.

The last treasury I got, was getting an edition of "Systems Programming with Modula-3" in very good state.

What's the quality of that book in terms of instruction and examples for a modern audience? If it's good, I might try to get a copy even for a teaching or demonstration language in safe languages. Easier for people to learn than Ada or Rust.

re embedded vs digital design

Yeah, embedded was what I was talking about and trial&error was what I was worried about. What I've seen people write up is a lot more difficult than software in general. I remember one had severe application issues when it ran with instant on that were eventually resolved as the PLL's not synced up. They put a delay in to let them warm up. Program worked fine. Seen some stuff in immunity-aware programming talking of similar issues. A comprehensive, free collection of stuff like that with tips would be a boon to hobbyists and pro's alike.

re book recommendations

Thank you. I'm already on Ganssle's newsletter. Good stuff in it. I've been published in one or two. Ancient hardware factored into my recommendations for two:

http://www.ganssle.com/tem/tem277.html

http://www.ganssle.com/tem/tem262.html

Ganssle confirmed that one SOC was taking the approach where it had a badass ARM Cortex plus a M0 for interrupts and such. It's claims were like a watered down version of Channel I/O. Cheap, too. :)

Btw, here's your 1-bitter. The link saying datasheet and VHDL design has the PDF's and code. The manual might have tricks worth remembering on other architectures.

http://www.linurs.org/mc14500.html

re Bitsavers

I already have over 10,000 papers from CompSci on my computer, a subset I read instead of skimmed. I keep planning to go through BitSavers to find more interesting stuff but afraid of accumulating useless junk. I just keep putting it off. I was able to pull interesting data on some interesting systems. They even had detailed books on OpenVMS drivers and internals. Something I'd have had to pay for when trying to clone its legendary reliability. Similar stuff on Tandem's NonStop architecture, patents on which should be expired by now or close. I'm keeping an eye there.

My own work was research and occasional work in high-assurance systems. I focused on security as it was hardest and most important with safety or predictability next. I have all the key papers from the past with many of today's best. The lessons learned papers had the most wisdom showing me every step of the way how they tried, failed, and/or succeeded in specific ways. I applied those lessons to my own work. After a brain injury, I'm like INFOSEC's Jason Bourne where I don't remember shit but what's left kicks in to help on forums and such. My main role is evangelist of high-assurance and old wisdom to embed it into more projects. Successes are few but keep it worthwhile. Best, recent example is Tinfoil Chat: Ottela applied every bit of feedback we gave him on Schneier's blog to make one badass design that deserves a rewrite in systems language.

I'll send you my stuff later today. Some people find it useful. Especially since the advice pre-empted the Snowden leaks defeating around 90% of their attacks. Funny that security "pro's" still argue with the shit while pushing what got defeated. In high assurance, it's mandatory to learn from the past. In retrospect, I wish I did lots of embedded or digital design before my memory loss as hardware/software interface is where best results are at. The analog and RF levels, too. I've mostly completed a secure ASIC design methodology and RAD strategy, though, so that will come as quickly as CompSci decides on right HW architecture. :)

"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."

I agree that such techniques need to be infused throughout the language. I just don't know enough Rust to comment. I do love Ada's existential types. That's a very simple technique that can knock out all kinds of issues, esp numeric conversions, that other languages have to go out of their way to avoid. Quite a few things like that in the language.

" 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."

There was a myth among some users of Rust that it was the first to have safe concurrency. I bust that here an elsewhere citing Hansen's Concurrent Pascal, Eiffel's SCOOP, and Ada's Ravenscar in that order. SCOOP is most exciting given pedigree (Meyer et al) and CompSci research into it. I've seen people formally verify (read: fix) it, livelock/deadlock-free proofs, and eliminate performance penalties. Wild stuff. Rust is latest with safe concurrency but not first. Some CompSci person really needs to do a detailed comparison of these as that might be insightful.

"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 very, very early days on getting a OSS community around a language that's about three decades old. Whereas I've been fighting C's of a similar age, there was little resistance to Rust, and one spontaneously emerged around Julia. You see why I have little to no hope for Ada? The only place I see a ressurgence of it is business sector where professionals that Get Shit Done (TM) might use it for long-term, mission-critical apps. Aside from what we like, it also has advantage of being designed for readability, easy integrations, and future-proofing. It delivered all that for decades straight. Just say: "Look, you'll be stuck with this app for decades. You want it written in COBOL, Microsoft C++, or AdaCore Ada/SPARK?" Ok, let's be honest: Delphi Pascal was a contender and my recommendation given ease of learning for disposable IT staff. ;)

"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 feel you there. Good news is that the Rust team takes feedback so long as it's productive. They're quite active here on HN. You'd have to learn Rust more thoroughly so you could say exactly what Ada has and it lacks. Maybe suggest how they'd add that without breaking current code as the language is in stable mode. They might bring it up to parity there.

"Finally, I know nothing about how Rust handles concurrency, so that would be another great comparison to see."

http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.ht...

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

Good. Far as name, you can ditch it for one easier to quote or keep the gibberish. Four karma points aren't a big loss. ;)

If we're talking tech, then your post couldn't be more wrong given my BeOS and QNX examples. Performance was equal to or better than monoliths of the time. BeOS especially destroyed competition in concurrency performance due to its architecture. QNX runs at hardware speed basically with real-time properties and POSIX support. BeOS disappeared due to Microsoft monopoly with Haiku making a OSS clone. QNX was at $40 million a year in revenue when Blackberry bought it. Green Hills and VxWorks are doing OK, too, with VxWorks making more than QNX per quarter. Both have desktops virtualizing Windows, Linux, etc on microkernels w/ Gbps throughput.

I don't see why we keep getting these theoretical counters given the proven results of microkernel performance in the field. Tell me why microkernels are too slow when they can only do this on 90's era hardware:

https://youtu.be/BsVydyC8ZGQ?t=16m9s

Then, tell us why we should sacrifice isolation of malice and faults in favor of kernel-mode code with properties like this:

https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

Our side produced highly reliable and secure systems plus high-performance systems. It was always done with a small group with little time. The monoliths took a decade and thousands of man hours to do the same. It's up to you people to justify why those hours were well-spent.

"while for say an exokernel the opposite is mostly true."

An exokernel is a microkernel...