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

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

#181

Post by jupp0r » Sun, May 03, 2020, 5:38 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…

I can see your point, but to give you a little more perspective on the breadth of the problem domain:

I wish they went as far as Go with their ability to produce fully static binaries and allow for cross compilation. Go's ability to have one CI pipeline running on Linux that then produces binaries that run on every conceivable version of Linux, Mac and Windows is a huge productivity boost.

For most of my use cases, they don't go far enough with static linking!

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

#182

Post by adev_ » Sun, May 03, 2020, 5:39 PM UTC

staticassertion wrote: post #171

adev_ wrote: post #169

Earlier quoted context omitted.

> Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience. I tend to name a "magic bulshit bloat tool" that will makes me download 350MB of crap to compile an 'hello world' a "godawful tooling experience". We are all free to have our own definition.

You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. But keep calling people "script kiddies" that's cool.

> commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me.

I am curious of your notion of "gatekeeping", because you are the one being funny here.

People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No)

If "today", with the unprecedent level of documentation you have on the Web, it is a problem for you to do so, then yes: you are indeed a bad developper.

I am a strong believer of "the show me the code" approach. It is easy to call all the actual tooling a "dumpfire", then show me a better one, or at least document in details what "a better" one would be.

Critics are easy and in this precise context, without arguments, they are just FUD or religious beliefs.

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

#183

Post by kzrdude » Sun, May 03, 2020, 5:41 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…

I don't think static linking is a cargo cult at all. It's just a simple and good enough solution, and there hasn't been enough interest into supporting anything else well. If it would show up as an articulated obstacle, you'd see movement to resolve it.

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

#184

Post by zozbot234 » Sun, May 03, 2020, 5:43 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…

Dynamic linking is just not very useful for rust due to lacking a stable ABI. So yes, you can build shared libraries and link to them but you'll be using the C ABI at the interaction boundary, which some devs might find unintuitive. (Or else you have to make sure that everything you link to is compiled by the same version of rustc and llvm, which is not very realistic.) Static linking sidesteps this potential issue.

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

#185

Post by staticassertion » Sun, May 03, 2020, 5:43 PM UTC

adev_ wrote: post #182

staticassertion wrote: post #171

Earlier quoted context omitted.

You can tell me that other build tools have problems, but the "You must know how to run some os/project-specific commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. But keep calling people "script kiddies" that's cool.

> commands to write a program or you're a bad developer" is the funniest kind of gatekeeping to me. I am curious of your notion of "gatekeeping", because you are the one being funny here. People have been able to understand Make, use it and compile C for 20 damn years: Are people being more stupid today ? ( Spoiler: No) If "today", with the unprecedent level of documentation you have on the Web, it is a problem for y…

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

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

#186

Post by kzrdude » Sun, May 03, 2020, 5:43 PM UTC

adrianN wrote: post #138

aidenn0 wrote: post #106

Earlier quoted context omitted.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.

Interesting point.

Does anyone know how much memory is needed to compile llvm+clang? GCC?

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

#187

Post by cosmojg » Sun, May 03, 2020, 5:48 PM UTC

staticassertion wrote: post #150

hedora wrote: post #127

Earlier quoted context omitted.

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

> 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? Yes, I think it is fair to say that I am very familiar with all of this information. I work in information security, and was quite into Linux kernel security for a while. I disagree with your assertion about it being the most secure general purpo…

> I disagree with your assertion about it being the most secure general purpose OS but I'm not gonna go there :)

Could you please go there? I'm very curious what the contenders for "most secure general purpose OS" might be.

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

#188

Post by utborin » Sun, May 03, 2020, 5:48 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…

In a thread about OpenBSD,

> Developers in particular don't generally care about security

Thanks, now I have to clean a mouthful of coffee off my screen!

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

#189

Post by est31 » Sun, May 03, 2020, 5:48 PM UTC

jupp0r wrote: post #181

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 can see your point, but to give you a little more perspective on the breadth of the problem domain: I wish they went as far as Go with their ability to produce fully static binaries and allow for cross compilation. Go's ability to have one CI pipeline running on Linux that then produces binaries that run on every conceivable version of Linux, Mac and Windows is a huge productivity boost. For most of my use cases, t…

Note that Go implements most of its toolchain itself while Rust uses parts of the C/C++ toolchain (llvm, C++ linker instead of go's own linker, etc). Go even has its own library loader. Once you have that it's not hard to make it compile to any target you want.

Also Rust is still evolving. They still have to add major new features to the compiler instead of being able to implement features like raw dylibs which would remove the need to include .lib files.

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

#190

Post by numbsafari » Sun, May 03, 2020, 5:49 PM UTC

adrianN wrote: post #138

aidenn0 wrote: post #106

Earlier quoted context omitted.

Until there is a rustc in production that doesn't use llvm to emit code in the backend, the point is moot, no?

No, I don't think so. If LLVM is at fault then the issue is definitely not inherent to Rust the language or Rust the development culture.

Your code is what it depends on. If you are picking dependencies with no concern for the overhead they introduce, well, it says everything it needs to say: you value that dependency over the associated overhead it introduces.

Asking an OS to adopt those same preferences, without any appreciation for their needs or preferences is pretty rude and arrogant.

A better solution would be to ask “what would it take, because I’d like to understand your needs”. Maybe then Theo could help you understand their constraints. Trying to argue with him that he needs something he clearly doesn’t isn’t very nice and won’t get a nice response if you push it too far.