Hacker News Reader

Comment by SCHiM | Hacker News Reader

The points made against switching to newer languages are valid. It will cost time, it will cost effort, it will take many years of work to convince stubborn maintainers to switch.

But it will not stop _everyone_ from adopting better languages, and their efforts will eventually surpass the older, less secure systems.

When there's feature parity, each and every new exploit will be called out: "this wouldn't have happened in our system'. And that is a good thing. There _are_ better alternatives to C.

As for the point about how nobody is working on replacements, that's wrong. There's (partial) replacements for most coreutils written in rust, and a whole kernel has been under active development for years now.

View on HN

I think this misunderstands the OpenBSD philosophy. The more likely it is "everyone else" disagrees, the more likely it is Theo is choosing the right course for the project.

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.

As regards understandability and minimising "magic boxes", this means it's pretty much just core OpenBSD (kernel & base system). The moment you add the usual desktop environments or a huge monolith like Firefox, you've lost these benefits. Same with drivers. More drivers you have, more the system becomes byzantine. Keeping things minimal and well designed yet useful must be a continuing challenge for OpenBSD!

Hah. Going by the "anything you compile with a magic box becomes itself a magic box" argument, even the OpenBSD base is a magic box as soon as you run it on an x86 machine.

1) I Think Firefox is already pledged. Firefox 57 is in current, built with Rust.

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.

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

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.

My impression is that the Rust developers and community are firmly in the practical camp. They will keep plowing at Rust and its ecosystem. They will improve and optimize every nook and cranny they can find.

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.

>He's worried about compile times? Fix the compiler.

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.

> The system being secure is a secondary benefit to it being comprehendible and coherent to an individual.

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?

https://www.openbsd.org/goals.html

Nothing in that list says anything about being "comprehendible and coherent to an individual". I'd agree those are useful and good things, but security is indeed mentioned and emphasized there, and not as being secondary to aesthetic concerns.

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.

Were there any successful attempts to design a brand new and complete OS API in the last decade?

UWP, slow and steady, will eventually get there.

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.

Not really, but POSIX itself is almost 30 years old (and primarily standardized interfaces that were considerably older), and a lot of interesting stuff happened ca. 1995-2005. See e.g. BeOS or Inferno.

I find your post quite funny in the context of the topic..

I totally respect (and have donated to) the OpenBSD project, and ran it for years for my firewall machines. Though these days I'm running containerized Linux firewalls for ease of upgrades. Anyway...

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.

Yep, I look forward to the day OpenBSD is obsolete. How Theo can be so anal about features like ASLR but then completely disregard the potential of compiler enforced memory safety is beyond my cognitive power.

Considering the complete lack of viable competition in the space, that day is a long way off.

Why is Redox not viable competition?

Are you joking? Are you running large, mission-critical systems in production on Redox already?

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

Because of GNU/Linux.

Come on, I really like Rust but these types of comments are why people like Theo de Raadt don't take the evangelists seriously. You can't take a project like OpenBSD that has existed for more than 20 years, is being used right now to power all kinds of applications around the world on all kinds of architectures and say that Redox, an experimental x86-64 OS, is viable competition. What with the seven applications written for it listed on Wikipedia, including "A simple web browser with basic image support" and "A simple editor that is similar to notepad". I don't know what the driver situation is like but I don't expect to see a lot of support for anything beyond the most basic devices.

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.

I love this. I think both of you are right, but your perspectives are for different time frames, with one side having an ideal view about a future time frame, while the other thinking about the now. This is the kind of situation that leads to innovation and how projects like Linux or neovim started. It's a natural way to progress. I hope jackpot51 gets pissed off and takes redox to the point where it proves the naysayers wrong, which will take time and effort, and doesn't serve the now.

I really hope that redox will eventually become a competitor to OpenBSD and other flagship OSs, I'd love to work on a Rust OS. That being said I still don't think it makes sense to label it a competitor at this stage though.

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.

That is precisely what I am going to do

Redox is an unproven toy OS compared to some of the more mature and battletested alternatives. And don't think battletested is a metaphore, some of these have been used to operate battlegear.

I feel like you should add a disclosure about being the creator of Redox.

Ouch, that's not a good look at all.

Reply on news.ycombinator.com