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

161–170 of 400 posts

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

#161

Post by quotemstr »

013a wrote: post #95

> Yes, now I am implying something: you won't bother to rewrite the utilities. > So we cannot replace any base utility, unless the toolchain to build it is in the base. Adding such a toolchain would take make build time from 40 minutes to hours. I don't see how that would happen. So, to summarize: "We're not going to include the capability to write core utils in Rust, and also, no one is bothering to do it." Its rath…

I got the same vibe from the email. It reads just like bigcorp turf defense.

When a smart but curmudgeonly component owner just doesn't want to accept some outsider's change, there's no end to the technical objections that component owner can raise against the outsider's change --- but these objections are just a smokescreen, and addressing them is futile, because the real problem is that the component owner has done a thing certain way for a long time and some attempt by an outsider to shake things up triggers all the owner's ancient territorial defense instincts. The actual merit of the outsider's proposal doesn't matter: the problem is social, not technical.

In a situation like this, when the intrepid outsider does manage to exhaust the maintainer's objections, the maintainer will switch to just spewing unfalsifiable FUD, to inventing further ridiculous objections, or just simply ignoring the outsider's change entirely. There's no technical fix for a curmudgeonly maintainer who really doesn't want to entertain new ideas.

In the corporate world, to resolve this problem, you usually have to go up the management chain and explain to leadership that certain people are making important work impossible. (You should try every possible alternative means of persuasion first, of course.) In the FOSS world, you just have to fork as a last resort.

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

#162

Post by AgentME »

gmueckl wrote: post #136
DougBTX wrote: post #98

Earlier quoted context omitted.

> Or is there something I'm missing here? There may be some platform-specific dependencies, but at least when building on Windows, I saw 67 dependencies downloaded. One thing that may be skewing the count is that internally coreutils is packaged with one crate per command. There are about 100 commands, so you'll have seen at least that many separate crates building. They're listed here: https://github.com/uutils/core…

Urgh, that's just a verification nightmare waiting to happen. Who is going to wade through all that mess, review every package, pin its version etc...? You need reproducability before you can get safety and security.

Cargo uses lockfiles by default to pin all dependencies of an application, so reproducibility shouldn't be much of an issue.

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

#163

Post by roblabla »

Arch-TK wrote: post #128
throwaway894345 wrote: post #72

Earlier quoted context omitted.

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

> Python's build ecosystem IS sane and well-designed. It's the pinnacle of package handling so far.

Big oof. Python packaging has a lot of problems, and defaulting to a single shared location when installing, that might conflict with your default package manager, is very high on the "What the fuck are you even doing" list of issues. You also very easily get into version hell. Unless you start using virtualenv, at which point you're basically doing the same thing cargo is.

> automatic downloading of dependencies

How is that a problem? Cargo has a lockfile to ensure the dependency downloaded is the exact same, various flags to prevent cargo from updating the lockfile (--frozen and --locked), and even the ability to vendor dependencies with cargo vendor[0]. It defaults to the most convenient things for developers because packages will be worked on many more times than they are packaged.

> Even the ability to directly pull from a github repo.

So does python/pip. And most package managers I've worked with. Crates.io will refuse packages that have github dependencies though, so this only comes up when packaging something that isn't really ready to be packaged.

As for linking, there are several rust-specific problems to dynamic linking:

1. Rust currently has no stable ABI (apart from the C ABI). This means updating rustc (and maybe even updating llvm) may cause the ABI to change, and libraries to become incompatible. There is currently no plan to fix this on Rust's part, and in fact some opposition, since it would prevent some optimizations from happening (such as niche-filling optimizations).

2. Generic functions and impls would not be part of this, as monomorphised variants would have to end up in the final binary. I believe C++ has the same problem with templates. A lot of Rust APIs are generic. This could theoretically be fixed (at least partially) through automatic promotion to dynamic dispatch, or other similar schemes.

[0]: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

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

#164

Post by [deleted] »

hedora wrote: post #127
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.

[deleted]

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

#165

Post by sgt »

Theo is being conservative here. It may just save OpenBSD some 10 years from now when Rust is no longer in the wind due to Hooch. At that point, someone will propose rewriting coreutils in Hooch, yet it may be much more sensible to stick with C, or rather C29.

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

#166

Post by ajross »

jerf wrote: post #140
ajross wrote: post #89

Earlier quoted context omitted.

> the gatekeeping implied here [...] is really toxic It's Theo de Raadt, toxic rhetoric is sort of his brand. But... he has a real point here. It's not about grep or cat or whatever really, those are just the use cases for which OpenBSD would care. It's that as Rust is reaching the second decade of its history, and despite some outrageous wins in press, evangelism, and general developer mindshare... Rust just hasn't…

" There's nothing in Rust that rises to the category of "stuff everyone just uses because it's what everyone uses" (c.f. zlib, libjpeg, readline...) yet." IMHO, that's basically not possible, so it isn't a fair ask. If the Rust community produced a drop-in replacement that is every bit as good as readline in literally every way... still nobody would switch, because why would they? What's the benefit? You spend all th…

> IMHO, that's basically not possible, so it isn't a fair ask

Is it not? There is software in that category written in the last ten years (not as much as in the preceding decade, obviously). How about Docker? V8/node? Most of the wasm ecosystem dates from that period. Actually there was a huge window with TLS implementations once the community collectively decided to move away from openssl, too.

Rust didn't hit any of those sweet spots. And I think we should maybe be spending more time asking why.

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

#167

Post by staticassertion »

adev_ wrote: post #158
throwaway894345 wrote: post #72

Earlier quoted context omitted.

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…

> So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. I will be mean, I am sorry but this kind of attitude piss me off. If you are not able to run a ./configure / make / make install & 3 apt-get properly. Then you should just stay far from keyboard and not try to build anything. W…

"If you are not able to run a ./configure / make / make install & 3 apt-get properly."

Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience.

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

#168

Post by wang_li »

tpush wrote: post #20
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.

No need to speculate, if you follow the GitHub link you'll see that the project is older than 2017.

You’ll also see that cp, ls, expr, test, and others are still only considered semi-done.

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

#169

Post by adev_ »

staticassertion wrote: post #167
adev_ wrote: post #158

Earlier quoted context omitted.

> So no, “security” isn’t the most compelling use case (for me, anyway), it’s moving past these dumpster fire build systems as quickly as possible so mere mortals can build their own software. I will be mean, I am sorry but this kind of attitude piss me off. If you are not able to run a ./configure / make / make install & 3 apt-get properly. Then you should just stay far from keyboard and not try to build anything. W…

"If you are not able to run a ./configure / make / make install & 3 apt-get properly." Nearly choked on my water reading this. Incredible how many developers are stockholme syndrome'd by their godawful tooling experience.

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

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

#170

Post by jen20 »

notaplumber wrote: post #36
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…

BSD does not use GNU coreutils. Is it really unexpected that the developer of a BSD project might have been unaware at the time of a project attempting to replace it, or simply found it incompatible with the stated requirements-- POSIX compliant base utilities. OpenBSD does not care about compatibility with GNU, for example longopts do not work for many utilities, with exceptions to permissive replacements to histori…

The use of cargo implies this no more than the use of make. One can fetch all dependencies and then build in a completely offline manner.
Post reply on HN