Live data from Hacker News

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

marc.info

281–290 of 400 posts

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

#281

Earlier quoted context omitted.

There is no gatekeeping. To actually achieve POSIX-compliance is not an easy task and requires lots of testing. If you don't do it then your replacement will break everyone's scripts. A distro maintainer will also want to retain compatibility with their supported GNU/BSD extensions so that's more work to add on. I would still agree with his statement at least as far as BSD is concerned. Outside of Redox I haven't see…

Somewhat academic as I have no dog in the fight, but ... > To actually achieve POSIX-compliance is not an easy task and requires lots of testing. Why are the existing tests not enough for a new implementation?

Sweet summer child, imagining OpenBSD has comprehensive tests? This is UNIX, old-school. If it seems to work, it works.

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

#282
post #216

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?

To me the question is moot if the problem is llvm. I don't know if that's the case or not. Modern tools require modern hardware. If the problem is that the target constraints don't allow modern tools to be used, the problem is the constraints and not the tools. But maybe I just don't understand their stance here.

Depending on what you are working on / with, you may not be able to choose your constraints.

Constraints that you cannot change can certainly dictate what tools you have to choose from.

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

#283

Earlier quoted context omitted.

> There's "no reason" why the rustc build should depend on cargo, rustc is a Rust project. Cargo is a build system for Rust projects. > this makes it way harder than it should be to keep rustc support up-to-date in any distro I am not aware of distro maintainers complaining about this, or at least, not any time in the last few years. Do you have some context to share? We want distros to have a good experience.

Debian unstable (IIRC) updated Firefox a couple weeks late because cargo got a couple of new dependencies and nobody added them to the Debian repos. This is because they forbid static linking, so there are hundreds of packages of popular Rust crates compiled as shared libraries. Even worse, some of them have multiple variants, for various combinations of features.

That’s a Debian issue. They’re trying to foist a dependency management strategy intended for C on a different language with a different strategy

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

#284
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…

That really wasn't the vibe I was getting.

There probably are legitimate technical issues with integrating Rust. That's fine; it happens. Maybe Rust will be better in the future (this was written in 2017, so maybe it already is). Or, maybe Rust will never be a good candidate for BSD. Any of these outcomes are possible.

I take issue with his tone, which is strongly reminiscent of Linus' management of Linux. He's welcome to be mean, but I would think long and hard about joining a community with a leader with such a disposition (I don't know Theo's history, so I can't say whether this is a pattern).

Being kind when running a project, especially of the scope of an operating system/kernel, is very difficult. Not everyone has the disposition to do it. You'll get Rust-fiends and Go-phers and all sorts of people who haven't contributed a single line come in and make wild suggestions that don't make sense, every day. You'll get HackerNews armchair commentators like me who think their opinion matters. In the face of this, its understandable to respond with scorn. But; enviable leaders instead form measured responses. You never make it personal. You never shut the door on suggestions.

Open Source, especially at BSD's scale, is not a one man army. Thousands of people have helped with that project, and its creator no longer has the blank check to be a dictator.

An excerpt from Bezos' 2010 Princeton commencement address [1]:

> I decided to do the math for my grandmother. I estimated the number of cigarettes per days, estimated the number of puffs per cigarette and so on. When I was satisfied that I’d come up with a reasonable number, I poked my head into the front of the car, tapped my grandmother on the shoulder and proudly proclaimed, “At two minutes per puff, you’ve taken nine years off your life!”

> I have a vivid memory of what happened next and it was not what I expected. I expected to be applauded for my cleverness and arithmetic skills. “Jeff, you’re so smart. You had to have made some tricky estimates, figure out the number of minutes in a year and do some division.” That’s not what happened. Instead, my grandmother burst into tears. I sat in the backseat and did not know what to do. While my grandmother sat crying, my grandfather, who had been driving in silence, pulled over onto the shoulder of the highway. He got out of the car and came around and opened my door and waited for me to follow. Was I in trouble? My grandfather was a highly intelligent, quiet man. He had never said a harsh word to me, and maybe this was to be the first time? Or maybe he would ask that I get back in the car and apologize to my grandmother. I had no experience in this realm with my grandparents and no way to gauge what the consequences might be. We stopped beside the trailer. My grandfather looked at me and after a bit of silence, he gently and calmly said, “Jeff, one day you’ll understand that it’s harder to be kind than clever.”

[1] https://www.theladders.com/career-advice/jeff-bezos-to-princ...

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

#286

> 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 10 years for adoption, let people should switch languages? DELUSION. Yeah, I agree: if the sole value proposition were 'security' it would be a really slow roll. cargo is the killer app IMO. Anyone who's walked a big dependency tree - download, b…

Why is rust easier than C? Is it because it makes what is simple in C hard?

Because it makes what’s hard in C easy: dependency management, cross-compilation, memory safety, etc.

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

#287

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…

With CMake you can build statically in a very reproducible cross platform way if you use Hunter and toolchain files.

the tools are all there - just they're not popular and aren't widely used

I wrote a bit of an old intro to the workflow: https://geokon-gh.github.io/hunterintro.html

This is an example of a project that's well setup using this pattern: https://github.com/elucideye/drishti

And having things work dynamically ... well that's what package maintainers due. It seems inherently very fragile. Developers only build test and develop against whatever dependency versions they have locally. you can't test against every version under the sun

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

#288

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.

Much of the ecosystem seems to be trending towards using rustls though, where this is of no concern.

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

#289
post #85

Earlier quoted context omitted.

Regarding build tools for C, you might find this one interesting: https://github.com/vmchale/cpkg

Yeah, there are lots of good build systems for C (didn’t know about this one; will have a look; thanks for sharing), but the problem is that they have tiny adoption, especially among “core” ecosystem packages, like coreutils and friends. The problem isn’t technical, it’s political and cultural. This ecosystem is hostile toward its users for no discernible reason. If anyone knows of a distribution that aims to use onl…

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.

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

#290
post #64

Earlier quoted context omitted.

There are actually several of the OpenBSD devs that have been writing Rust lately. Some are doing it for work, some from personal interest. Opinions vary on how much people like it. Rust and OpenBSD share a lot of technical values though so maybe this isn't surprising. Rust values safety and correctness. OpenBSD values safety and correctness. Rust values 'Just Works' with all the nice things cargo does and the whole…

Nothing wrong with the OpenBSD people writing in Rust, that's a step away from tossing out say 'grep' or 'ls' and replacing it with something that isn't 100% compatible. That will cause a lot of stuff to break in hard to predict ways. It's like kicking out a random foundation stone from a building and expecting no consequences.

Sorry if you interpreted my comment as advocating for tossing out grep or ls - that certainly wasn't what I was getting at. As one of the OpenBSD people that happens to quite like Rust, I'm aware of some of the other devs who have been using it, and we've talked a bit about Rust in general on occasion. The things that people appreciate about Rust tend to align with the things they like about OpenBSD, because the two projects have similar values. That's all I meant.
Post reply on HN