Re: Integrating "safe" languages into OpenBSD? (2017) • Hacker News Board

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

#291

Post by acdha » Sun, May 03, 2020, 7:56 PM UTC

dmitrygr wrote: post #263

busterarm wrote: post #230

Earlier quoted context omitted.

I'm not much for Rust, but I'm essentially a deploy/tooling engineer and supporting a build system for hundreds of engineers and tens-thousands of servers. I've worked in a few dozen languages at this point and have seen 20 years of the problems in this field. I'm going to tell you that static linking is the only way to go. The idea that needs to die is the personal workstation. It's just another deploy target. Ideal…

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

It’s a lot cheaper than it’s been in the past, especially for what we’re talking about: people are using more data these days but the kinds of system shared libraries where common page mapping helps has seemed like diminishing returns for years, both as a fraction of private data size and because applications don’t sync their dependencies so you end up with multiple versions of each library cutting into the savings.

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

#292

Post by acdha » Sun, May 03, 2020, 7:59 PM UTC

aidenn0 wrote: post #94

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.

I think it was more the implication that requiring more than 2GB of RAM to compile itself was an indication of its profligate resource usage.

That doesn’t seem like an especially strong argument since computing is full of time/space trade-offs and 2GB of RAM hasn’t been a significant amount for over a decade at this point (X86-64 only goes back to 2003 but it was a latecomer following Intel’s epic failure to deliver Itanium). Things like whole program optimization seem like a reasonable trade off for <$20 worth of RAM.

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

#293

Post by rurban » Sun, May 03, 2020, 8:02 PM UTC

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…

A lot is missing also.

First he doesn't know about ripgrep, which is far better than GNU or BSD grep.

Second,none of the known grep's can find unicode strings. Redhat carried along the uni patches for a while, but when people complained about performance on the new utf8 locales, they dropped it. coreutils is still missing unicode support, so we don't find equivalent strings with different bytes. No normalization, no fold casing. Rust based coreutils could solve that, because they have the proper libs which are better than in C land and could survive the perf critics.

Third, rust is not secure. Just more secure than C. Memory safety, thread safety and type safety are lies. People buy it, but Theo should know.

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

#294

Post by qppo » Sun, May 03, 2020, 8:11 PM UTC

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 reading your comment and reacting to it, I'm tempted to estimate how much money dynamic linking will cost my business this year and how much money we'd save by reworking our build tree to compile our dependencies from source and maintain static libs on the targets we care about.

>And rebuilding isn't cheap in storage requirements either: a typical cargo package will require a few hundred megabytes of storage, likely for _each_ rebuild.

shrug I don't care about build storage requirements until we start talking tens to low hundreds of GB and disk I/O becomes the time bottleneck or caching costs real money in CI.

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

#295

Post by numbsafari » Sun, May 03, 2020, 8:13 PM UTC

anthk wrote: post #255

numbsafari wrote: post #209

Earlier quoted context omitted.

“cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy: https://www.cvedetails.com/cve/CVE-2014-9471/

That's not BSD cat, that's GNU cat. And I am using AWK and KSH + dcgi in my Gopher server with a chrooted root gopher hole, it works fine.

In fact, it’s neither, it’s coreutils (gnu, yes) `date`. My point is that seemingly innocuous system utilities do make for exploit targets, because folks shell to them.

Yes, you can lock things down with jails/containers, but it’s a valid target. Defense in depth, and all that jazz.

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

#296

Post by DagAgren » Sun, May 03, 2020, 8:13 PM UTC

adev_ wrote: post #215

staticassertion wrote: post #185

Earlier quoted context omitted.

> I am curious of your notion of "gatekeeping" Repeatedly telling people that they're bad developers, should walk away from a computer, that they are "script kiddies", because they do not know or enjoy some arcane technical artifact. I call this gatekeeping.

> enjoy some arcane technical artifacts Except that I do not think that you can call executing "make" and using your native package manager an "arcane", I am sorry. These are basic actions that are documented even from tutorials from the 90's. They are basic actions that are generally part of any first year study in computer sciences. That is not 'gatekeeping', there is no gate to keep here. I name more that fight la…

Speaking as a C developer of twenty or thirty years or so who's used make for all that time:

Make is absolute, utter arcane bullshit. It is mad. It is complete nonsense.

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

#297

Post by thesuperbigfrog » Sun, May 03, 2020, 8:14 PM UTC

pot8n wrote: post #266

SergeAx wrote: post #264

> For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Wow, that one was really cruel.

Seriously who cares about i386 in 2020?

- Older computers still in use throughout the world.

- Embedded systems and "Internet of Things" (IoT) devices

Many operating systems and toolchains continue to support i386: https://itsfoss.com/32-bit-os-list/

Just because you do not use it does not mean other people do not.

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

#298

Post by numbsafari » Sun, May 03, 2020, 8:15 PM UTC

staticassertion wrote: post #223

numbsafari wrote: post #209

Earlier quoted context omitted.

“cat” and related tools make perfectly interesting exploit targets on Unix systems that follow the Unix philosophy: https://www.cvedetails.com/cve/CVE-2014-9471/

There is a big difference between being having vulnerabilities and being valuable attack surface. Again, I am not saying that cat and others do not provide attack surface, or even valuable attack surface, only that step 1 is not "rewrite cat". Generally "cat" is not exposed to the internet, and if you're running a service and you said "I'm concerned about local attackers using cat" it's probably a lot easier to just…

> step 1 is not "rewrite cat"

Totally agree on this point. In fact, I think it’s brash for the rust armada to think that the borrow checker alone is going to help replace 20+ years of maintenance on these kinds of tools, which often crufty, and gnarled by the sands and whims of generations that preceded us.

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

#299

Post by busterarm » Sun, May 03, 2020, 8:16 PM UTC

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.

So you're saying that static linking isn't a guarantee, because the build was polluted with dynamic linking.

Isn't that furthering my point?

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

#300

Post by busterarm » Sun, May 03, 2020, 8:17 PM UTC

dmitrygr wrote: post #263

busterarm wrote: post #230

Earlier quoted context omitted.

I'm not much for Rust, but I'm essentially a deploy/tooling engineer and supporting a build system for hundreds of engineers and tens-thousands of servers. I've worked in a few dozen languages at this point and have seen 20 years of the problems in this field. I'm going to tell you that static linking is the only way to go. The idea that needs to die is the personal workstation. It's just another deploy target. Ideal…

> 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 anyway. Stop keeping pets.

How many of these big binaries are you running on your servers at once?