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

351–360 of 400 posts

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

#351

Post by folmar »

busterarm wrote: post #300
dmitrygr wrote: post #263

Earlier quoted context omitted.

> Disk is cheap Arguable, but I'll grant you this. But RAM ain't cheap.

Single Responsibility Principle except apply it to infrastructure. We're in a world where both virtualization and containerization are the norm and with either flavor this is easy. Each of your virtualized/containerized systems are going to have their own distinct instances of the shared libraries, so you're getting a fraction of the benefits of dynamic linking if you're doing your infrastructure properly today anywa…

> Each of your virtualized/containerized systems are going to have their own distinct instances of the shared libraries,

Certainly not mine, my memory deduplication is doing just fine.

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

#352

Post by busterarm »

saagarjha wrote: post #335
busterarm wrote: post #238

Earlier quoted context omitted.

Deployability really should be king. I hinted at this in my other post, but I don't think quite enough people think about this. Static linking makes your deployability worries go away. That's not to say that isn't at least possible with dynamic linking, but the complexity and gymnastics will sink you. Everyone gets bit by it eventually.

> Deployability really should be king. Not everyone values deployability as much as you (or employers, I suspect) do. On my personal computer I care about getting security patches and disk usage.

Lots of people don't measure risk very well and get hit by black swan events.

Over 65% of startups have less than 6 months of cash reserves right now and 74% have been laying off staff. It turns out the majority of people are poor long-term planners.

I personally don't care about how you manage your personal workstation, but you're not who most of us are building for. Most of us aren't building tools to support you. We're writing a big ecosystem for everyone to collaborate.

In a professional setting, problems with how people manage their computers aren't acceptable. Any decently-sized company will get rid of such a problem quickly. In smaller companies I've seen people get fired over poor management of their workstation's environment.

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

#353

Post by folmar »

saagarjha wrote: post #335
busterarm wrote: post #238

Earlier quoted context omitted.

Deployability really should be king. I hinted at this in my other post, but I don't think quite enough people think about this. Static linking makes your deployability worries go away. That's not to say that isn't at least possible with dynamic linking, but the complexity and gymnastics will sink you. Everyone gets bit by it eventually.

> Deployability really should be king. Not everyone values deployability as much as you (or employers, I suspect) do. On my personal computer I care about getting security patches and disk usage.

Deployability is the job of the package manager, not compiler. You can always link dynamically and ship with all libraries and set rpath accordingly.

Also: static linking is not deployability if the source code is not shipped to the target - you don't have _my_ version of a library which is patched to support my hardware.

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

#354

Post by folmar »

kinghajj wrote: post #258
busterarm wrote: post #238

Earlier quoted context omitted.

Deployability really should be king. I hinted at this in my other post, but I don't think quite enough people think about this. Static linking makes your deployability worries go away. That's not to say that isn't at least possible with dynamic linking, but the complexity and gymnastics will sink you. Everyone gets bit by it eventually.

Eh, even with Rust's static linking, that's not a guarantee that there will be no worries with deployment. Most SSL libraries in Rust, for instance, currently link to (Open/Libre)SSL dynamically. So you often can't take a Rust binary compiled on a distro with one version of the SSL library, to another distro with a different version.

Actually openssl is pretty compatible between versions, usually not an issue in the real world.

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

#355

Post by busterarm »

folmar wrote: post #351
busterarm wrote: post #300

Earlier quoted context omitted.

Single Responsibility Principle except apply it to infrastructure. We're in a world where both virtualization and containerization are the norm and with either flavor this is easy. Each of your virtualized/containerized systems are going to have their own distinct instances of the shared libraries, so you're getting a fraction of the benefits of dynamic linking if you're doing your infrastructure properly today anywa…

> Each of your virtualized/containerized systems are going to have their own distinct instances of the shared libraries, Certainly not mine, my memory deduplication is doing just fine.

We've had various mechanisms for this and some of them have even been deprecated. Transparent Page Sharing was deprecated in VMware as it turned out to not be super useful in large pages. We have Kernel Same-Page Merging but many folks are disabling this in a post-Meltdown/post-Spectre world as the potential vulnerabilities aren't worth it.

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

#356

Post by folmar »

qppo wrote: post #294
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…

It starts being cool way more quickly on typical /* nix systems as a developer Due to subtle binary incompatibilities in shared libraries, a CD pipeline I maintain costs twice as much money to run in order to target MacOS and Debian systems. It's not "worth it" to me. Static linking is a cornerstone of what I'd call "deterministic deployment." The cost savings of deterministic deployment are so immense that after rea…

Suppose a closed-source program you use has a critical vulnerability in rustls and the company that wrote it is out of business. How much effort do you need to hot-patch the binary in a safe manner? I routinely use 15-years old software which is only usable with replacing libraries with their recent counterparts and changing the names to masquerade for the old ones. And I do prefer to have access to old files.

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

#357

Post by eximius »

busterarm wrote: post #238
eximius wrote: post #173

Earlier quoted context omitted.

I don't think the position of the language teams is that static linking is better than dynamic linking. I think that static linking is a significantly easier target for a relatively new language whose _novel_ features make it difficult to define a stable ABI. Under the very specific constraints that Rust is operating in, static linking is currently the best option. That said, I wouldn't mind seeing some kind of ABI g…

Deployability really should be king. I hinted at this in my other post, but I don't think quite enough people think about this. Static linking makes your deployability worries go away. That's not to say that isn't at least possible with dynamic linking, but the complexity and gymnastics will sink you. Everyone gets bit by it eventually.

Static linking is more ergonomic for developers.

Dynamic linking is a better use of user resources, which is sort of ergonomics.

To say one metric should be king without context is missing the point.

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

#358

Post by cycloptic »

throwaway894345 wrote: post #315
yawaramin wrote: post #289

Earlier quoted context omitted.

Nix is becoming more of a name in dependency management systems: https://blog.galowicz.de/2019/04/17/tutorial_nix_cpp_setup/ Its claims to fame are support for multiple languages, reproducible builds, and system-wide package caching.

Yeah, Nix is really neat. It's the right direction for sure, but it's mostly used as a wrapper around autotools and cmake projects by third parties and not so much as a first-class build tool by the maintainers of C/C++ libs (this isn't going to change because Nix prefers to be "innovative" and unfamiliar in just about every design decision--its core approach to reproducible builds is right on, but the execution leav…

Nix is a package manager, not a build tool. It's never been in-scope for it to figure out how to invoke a particular compiler or linker. All it can do is make it easier for you to invoke another build tool, of which there are quite a few.

I would not recommend the use of autotools in new projects, but in my experience CMake with Ninja is fine for distro maintainers to deal with — All other modern build tools I've seen are roughly the equivalent of it. If you find that it's hard to get over the hump with that, then I hate to say it but I don't think solutions will come easily elsewhere on any OS or platform. The state of things on free software operating systems is constantly improving but for now it's something you have to get used to. There are no silver bullets here.

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

#359

Post by zozbot234 »

dang wrote: post #277
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…

Yes, we've changed the title from "Theo de Raadt on Rust", which broke the site guidelines: " Please use the original title, unless it is misleading or linkbait; don't editorialize. " https://news.ycombinator.com/newsguidelines.html

(2017)

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

#360

Post by yellowapple »

asveikau wrote: post #45
jcranmer wrote: post #8

> I wasn't implying. I was stating a fact. There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. This is in fact incorrect--there is a project aiming to build all of the coreutils in Rust ( https://github.com/uutils/coreutils ). More to the point: while I do concur in the conclusion that Rust shouldn't be a part of the OpenBSD base system, the gatekee…

Some substantive comments I read from the mail: * It takes a long time for a rewrite to be fully compatible and a good implementation. This project says it uses the busybox tests and that seems like a good start. Is it good enough though? Busybox itself is quite good for certain embedded niches but it would be absurd to replace a good chunk of OpenBSD userland with that, the usability would suffer a lot. * OpenBSD ne…

> Busybox itself is quite good for certain embedded niches but it would be absurd to replace a good chunk of OpenBSD userland with that, the usability would suffer a lot.

Not to mention that Busybox (last I checked) uses a license unsuitable for inclusion in OpenBSD (which is trying to reduce the amount of GPL-licensed software in the base install).

Post reply on HN