The system being secure is a secondary benefit to it being comprehendible and coherent to an individual. It's not enough for the output of a magic box to be a better widget, even if the widget is better in every measurable way. The box itself must not be magic.

This isn't "right" or "wrong". It's simply a stance that values an individual's ability to understand their computing device from top to bottom.

Rust is an amazing and wonderful piece of technology, produced by a great investment of energy by brilliant minds. I'm incredibly grateful it exists and look forward to it's continued development and adoption.

But I'm not brilliant, and I don't have a lot of energy, and so I'm also grateful there exists an operating system I can understand, and other people who continue to work to make that operating system useful.

Much open source technology is created by people with a financial incentive for others to use it. That's fine. OpenBSD is written by people who want to use it. It's usefulness to others is coincidental. That's fine too.

I'm glad there is so much money funding the development of open and free computing innovations. The world is a much better place for it.

But there isn't a lot of money funding the rest of the unix philosophy besides the "open" part, like the parts about composability and anti-monolithic design. Because those things are not valuable in financial terms, and are potentially even destructive towards the purpose of capturing value at all.

I am grateful there is a small radical free operating system defending our freedom from monoculture.

And I'm similarly glad for their defacto antagonism towards proselytizing of all kinds, even if that proselytizing is done with good intention, and even if that proselytizing turns out to be right.

That's why you need to show them the code. When you show the code, it means you understand. Until you understand, you're not free.

At least, this is my interpretation. I'm not affiliated with the project in any way. Just a fan.

Writing correct, efficient C takes more years to master than people take to learn Rust that I've seen. Also, the C compiler and many other parts of OpenBSD are black boxes to their developers. Your worries apply equally to their situation unless you've read and understood all their dependencies. On top of it, the OpenBSD people are always rewriting stuff for claimed benefits in maintainability or security. It's just when we talk a safe, systems language that can be as simple as a Wirth language or complex as Rust they suddenly can't justify the effort of even piecemeal replacement.

Then, next week, they'll put piles of effort into a mitigation across their toolchain whose benefits are so probabilistic even they can't tell you what attacks will fail or succeed. It's worth it, though, to improve their security standpoint. Unlike the pain of recoding even one utility in something like Rust. That's where this email draws the line.

Of course, I encourage people to do exactly what he asks every time another BS argument is raised. He's worried about drawbacks of a non-C language? Make something like Cyclone or get a Wirth language better at selectively turning off safety compiling to C w/ great C FFI. He's worried about compile times? Fix the compiler. He says utilities aren't rewritten in the better language? Rewrite them showing its advantages esp against the bug reports in OpenBSD's tracker. Just keep pounding away at the problems until he runs out of excuses to import stuff or is extra clear they simply don't like language/method X for arbitrary reasons. Regardless, you get a pile of safe utilities/modules for OpenBSD to do useful things on top of fast, safe tooling. Win, win. :)

Alternatively, contribute those ports to OS's that want to bring in best-of-breed tooling for boosting safety and security. They're usually smaller, less mature, and need all the help they can get.

I wouldn't be too worried about Rust, it will have a niche at least as big as Ruby's is and IMO it will be way more entrenched since its target domain moves way slower and the barriers to entry are way higher than for scripting languages and web frameworks, IMO.

If it were that simple, the compiler wouldn't be slow in the first place. Rustc and ghc have both been too slow to be usable their entire lives. There doesn't seem to be any reason to believe they can be made fast enough to consider using.

This is a really interesting and compelling philosophy to me, but it’s the first time I’ve heard OpenBSD described this way! Why is this not mentioned on the project’s homepage?

2) Nothing wrong with kernel and base. It provides the kernel, clang, X.org, documentation and BSD-games, among the rest of Unix tools.

3 The drivers are in base and NOT in a module form, as the GNU/Linux crap with incompatible vendor releases and binary blobs tied to a version.

I acknowledge the strong pull to go and re-implement existing standards like POSIX in a new language like Rust.

But, having had to again deal with all the corner cases of signal handling and threads for a Linux application, I encourage any prospective Rust OS developers to pick a different path.

Please, please, let's move beyond POSIX. Give me a sane set of operating system API calls that work in a reasonable way together. And that can compose easily.

So that future developers don't have to deal with file read calls that may (or may not) be interrupted by a signal, and all that.

I do understand OBSD's objections to using a new implementation language for their core utilities. And I understand their philosophy for what they're doing and how they're doing it in the general case.

But the fact remains that POSIX, as it has evolved (or not, in some cases) makes writing correct programs harder than necessary. Especially modern multi-threaded programs.

I'd like to see something better and simpler. And maybe written in something other than C.

ChromeOS, the OS APIs are the web platform.

iOS, almost everything that matters is done via Cocoa

Android, Java reigns. There is very little UNIX exposed to userspace, less so since Google started clamping down NDK since version 7.

In general I think the "why don't you rewrite your project in $languageoftheday" remarks should be dismissed and ignored. Theo is entirely right when he says that if people think it's a good idea then they should spend less time bothering the devs about it and more time actually coding it.

You think Curl or Emacs should be written in Rust? Then do it. Don't bother the devs about it. If it's really better then people will make the switch.

If I decided to start practicing Formula One next week that won't automatically make me competition for Lewis Hamilton. Redox has some way to go before people can seriously consider using it over OpenBSD for real world applications.

I'm sure it will be good enough for that some day, but that day is not now.