Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Re: Integrating "safe" languages into OpenBSD? (2017)

marc.info

Post reply on HN
Print view View original

121–130 of 400 posts

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#121

Post by euler_angles »

random_savv wrote: post #114
bsdubernerd wrote: post #103

It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…

Cargo cult - what a great pun!

You can find many articles on the origin of the term. I like this one from 1959:

https://www.scientificamerican.com/article/1959-cargo-cults-...

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#122

Post by fluffything »

ben_bai wrote: post #109
naasking wrote: post #84

Earlier quoted context omitted.

Bizarre that he thinks a language or compiler is doomed unless it can compile itself on each platform it supports. Microcontrollers and cross-compilation wouldn't exist if that were the case.

Well OpenBSD has this "dumb" rule that snapshots/releases are never cross compiled and be done on real hardware. So it's pretty much a rule that every hardware platform has to be self hosting. Microcontrollers are the exception, but then they don't run a full blown OpenBSD stack anyways.

This rule is not just dumb, it is retarded.

I maintain a quite popular open source project, and OpenBSD maintains a fork. They try to submit patches every now and then, but every time it happens, I ask them to please also submit a test that makes CI fail without the patch, and pass with it.

They can't, so OpenBSD remains unsupported.

The problem is that there isn't a supported cross-compilation toolchain from any major platform to OpenBSD (due to this dumb rule), so if they want to compile and run the test, they need to compile a big project under qemu-system and then run the test, which is super slow.

Other targets just cross-compile natively in seconds, and just run the test under qemu-user, which is super fast.

So we break OpenBSD a lot, and they need to put in a lot of effort into maintaining their own fork, which takes them resources away from doing other more useful things. Adding OpenBSD code is pointless, because we can't even test that it compiles, much less works.

This rule of not supporting cross-compilation hurts them more than it helps them, but it's their own fault.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#123

Post by steveklabnik »

gmueckl wrote: post #120
bsdubernerd wrote: post #103

It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…

The rationale is that rust can only give any guarantees at all if the resulting binary is self-contained. A shared library swap can break everything that the compiler guaranteed during compilation. This fits nicely with the generally restrictive mindset of the rust designers.

This is not "the rationale" whatsoever.

Stable ABIs are hard, and we have a lot of other work that's a higher priority for our users. There is no ideological opposition to dynamic linking, only practical blockers.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#124

Post by jerf »

jcranmer wrote: post #34
protomyth wrote: post #21

Earlier quoted context omitted.

The post was written in 2017. How far along was the project in 2017. Also, I am a bit confused about the gatekeeping implied here (it's not a serious language because it's not used to build an operating system) is really toxic. ? Which line in the e-mail stated that?

The gatekeeping is strongly implied by this statement: > As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts. Which I read in the tone of "go play with your toy language somewhere else, and let the real programmers program with real languages. Additionally, there's the allusions to the fact that…

There is gatekeeping here... but it's not implied, it active and out in front. The entire conversation here is whether Rust code is going to be permitted through the gate of the OpenBSD base system. You don't have to parse through implications to find the gatekeeping, it's the topic of the conversation.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#125

Post by loup-vaillant »

geocar wrote: post #83
loup-vaillant wrote: post #42

Earlier quoted context omitted.

https://github.com/uutils/coreutils/commit/d4e96b33e34373399... I read 2013, Theo de Raadt's email is from 2017, over 4 years later. I think we can fault him for being overconfident and not checking his facts.

That commit doesn't have any files in it. The first release of "uutils coreutils" appears to be this: https://github.com/uutils/coreutils/commit/511f138e3856e2d69... which is only twenty days young, and a 0.0.1 release to boot (whatever that means).

> There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities.

There was an attempt, that started over 4 years earlier, and if I understand correctly that attempt was pretty far along when this email was written. We can argue over definition, but I'm pretty sure he wouldn't have written this if he was aware of this project.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#126

Post by jerf »

jcranmer wrote: post #22
zdw wrote: post #14

Earlier quoted context omitted.

Linked mailing list message is from 2017, which is may be after when the linked project was started/viable.

uutils was started in 2013, and was decently complete well before 2017.

Your definition of "decently complete" and Theo's are likely to be waaaaay different... and within your respective contexts, you are both correct.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#127

Post by hedora »

staticassertion wrote: post #61

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 1…

> Developers in particular don't generally care about security, so selling Rust as a "secure" language is not going to be enough.

You do realize that OpenBSD is, by far, the most secure general purpose operating system specifically due to decades of thankless work by people like Theo de Raadt, right?

I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#128

Post by Arch-TK »

throwaway894345 wrote: post #72
staticassertion wrote: post #61

This is less "On Rust" and more "On accepting a rewrite of any tool into OpenBSD, on the merits of memory safety alone". There isn't really much of a statement or judgment on Rust. At most there's an interesting point on it's value proposition: > However there is a rampant fiction that if you supply a new safer method everyone will use it. For gods sake, the simplest of concepts like the stack protector took nearly 1…

Yeah. Not sure about BSD, but I was wading into building the GNU coreutils and other GNU packages just yesterday. Fresh hell, they all seem to be build dependencies of each other. ‘sed’ is its own build dependency. The whole C ecosystem is a joke with respect to builds—all dependencies are implicit; you’re just expected to have the exact dependencies installed on your system at the exact versions and in the exact loc…

Python's build ecosystem IS sane and well-designed. It's the pinnacle of package handling so far. A separate package manager which works together with a separate build system which still works when a distribution wants to package a python package.

What build systems like cargo seem to think is awesome is probably the most backwards idea of build systems I've ever seen. Static linking and automatic downloading of dependencies. Even the ability to directly pull from a github repo. No wonder almost nothing written in rust ever gets packaged.

Dependencies are hard, following a spec like semver seems to have confused people. Developers are lazy and don't want to think about settling down their API. Solution? Just give up and encourage bad behaviour. Thanks guys. Great solution. I think I'll stick with the previous one.

Re: Re: Integrating "safe" languages into OpenBSD? (2017)

#130

Post by roblabla »

bsdubernerd wrote: post #103

It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…

> I wish didn't end up being engrained so deep in the toolchain

For what it's worth, rustc does support dynamic linking, both for system dependencies and crates. You can compile a crate with the type `dylib` to produce a dynamic rust library, that can then be linked against when producing a final binary by passing ` -C prefer-dynamic`.

I don't think it's possible to make this work with cargo currently, but there are a couple open issues about it (albeit without much activity).

And of course, rust not having a stable ABI means the exact same rust compiler (and LLVM version, I suppose) would need to be used when compiling the dynamic libraries and final binary.

Post reply on HN