Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

131–140 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#131

Earlier quoted context omitted.

If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.

Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.

So, you say Python is totally missing the point and is wrong? Even when encoding videos, performance matters.

Also, that optimizing compilation is important is no reason to not work on i386. This is a point Rust needs to fix. And not only i386 support, but also other architecture families, as host.

Re: Integrating “safe” languages into OpenBSD?

#132

Earlier quoted context omitted.

If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.

Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.

A fast edit-compile-run cycle makes development a lot more efficient in my experience.

Re: Integrating “safe” languages into OpenBSD?

#133

I remember I stopped frequenting /r/programming when it became this weird Haskell echo chamber. It was a bubble where a small but vocal faction inside the community seemed to over react to any criticism. They methodically and tirelessly responded to every comment with an endless litany of "facts" showing how Haskell could do anything from os kernels to game programming. They touted every industry mention of Haskell u…

It's become clear to me that a lot of the Rust fanatics don't actually know how C++ works and and Rust is their first low-level language. The ones I'm talking about know enough to make them sound like they know what they're talking about unless you actually know what they're trying and failing to accurately describe.

It sounds and seems like a language worthy of more investigation on my part, but I have to agree that the militant, presumptive attacks on any language besides their Chosen One has left a bad taste in my mouth.

Re: Integrating “safe” languages into OpenBSD?

#134

I remember I stopped frequenting /r/programming when it became this weird Haskell echo chamber. It was a bubble where a small but vocal faction inside the community seemed to over react to any criticism. They methodically and tirelessly responded to every comment with an endless litany of "facts" showing how Haskell could do anything from os kernels to game programming. They touted every industry mention of Haskell u…

I find most of the programming/lang/framework subreddits intolerable. I dip into those waters occasionally, but unsub pretty quick. Too many egos, trolls, asshats, and too much noise. There are notable exceptions, like /r/elixir. But I abandoned /r/python and /r/django months ago, and won't be back. I'm an adult, and prefer to discuss things those who will show at least a modicum of respect to others.

Re: Integrating “safe” languages into OpenBSD?

#135
post #12

Earlier quoted context omitted.

>Such ecosystems come with incredible costs. For instance, rust cannot >even compile itself on i386 at present time because it exhausts the >address space. Is cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, envir…

Okay, there's a lot of misunderstandings here. Theo is right about some things, and wrong about some things. And people are misunderstanding what things he's right about. The things he's wrong about are very minor. Rust absolutely works on 32-bit platforms, though we often use the i686 target rather than an i386 one. Platform support list is here: https://forge.rust-lang.org/platform-support.html Theo is talking abou…

If compilation of rustc runs out of memory it represent an upper limit on the complexity of actually viable Rust programs, and given how much software is larger than a compiler it is a discouraging performance level.

Re: Integrating “safe” languages into OpenBSD?

#136
post #126

I remember I stopped frequenting /r/programming when it became this weird Haskell echo chamber. It was a bubble where a small but vocal faction inside the community seemed to over react to any criticism. They methodically and tirelessly responded to every comment with an endless litany of "facts" showing how Haskell could do anything from os kernels to game programming. They touted every industry mention of Haskell u…

> I sometimes get the feeling people spend more time writing defences of these languages than they spend time writing programs in them. Programmers love language wars.

> Programmers love language wars

Programming Language Advocates love language wars

Most programmers just like to be aware of ALL the PROs and CONs of the languages and choose the right one for the task at hand.

Re: Integrating “safe” languages into OpenBSD?

#137
post #46

Earlier quoted context omitted.

> He has a point though… Does he? He "stat[es as] fact" that > There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. which as xwvvvvwx notes is categorically wrong, then points out that rustc can't compile itself on i386, which is relevant… how?

He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong. i386 is relevant because OpenBSD supports i386.

> He's talking specifically about OpenBSD base.

No, he is very explicitly saying that

> There has been no attempt […] provide replacements for base POSIX utilities.

Which once again is categorically false, a github repository purporting to do exactly that has been provided.

> i386 is relevant because OpenBSD supports i386.

i386 is supported, the issue is compiling the compiler on i386.

Re: Integrating “safe” languages into OpenBSD?

#138
post #66

Earlier quoted context omitted.

> On a project such as OpenBSD they cannot suddenly drop platforms and only support amd64 as portability They… don't need to? That rustc can't compile itself on i386 doesn't mean you can't ship a rustc for i386, it just means you have to cross-compile it.

I see it as part of portability that you do not need to use any external system for bootstrapping. Imagine as a developer who compiles base from source you had to find another system only to compile rustc and then transfer it to your machine. And you would not have to do this only once, but for every compiler bug fix coupled with the overall rapid evolution of Rust. I think many in the OpenBSD community would oppose…

> I see it as part of portability that you do not need to use any external system for bootstrapping.

You always need an external system for bootstrapping, you're not assembling the base C compiler with which you're compiling everything else. At one point you need to obtain a compiler from somewhere else.

Re: Integrating “safe” languages into OpenBSD?

#139
post #15

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 happen…

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 mus…

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

Re: Integrating “safe” languages into OpenBSD?

#140

Earlier quoted context omitted.

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 mus…

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.
Post reply on HN