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

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

#141

Post by steveklabnik » Sun, May 03, 2020, 5:05 PM UTC

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…

> No wonder almost nothing written in rust ever gets packaged.

rustc is also built with cargo, and it is packaged on most distros. A lot of distros are including packages of other tools too.

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

#142

Post by Arch-TK » Sun, May 03, 2020, 5:05 PM UTC

Uehreka wrote: post #104

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…

Agreed on a hundred thousand. I used to feel sheepish defending npm and the whole node package ecosystem against its critics, but once I started trying to run deep learning applications or WebRTC media servers I quickly realized that some of the critics are probably coming from a much worse package management system that they’ve merely grown familiar with. Want to have two pieces of software on one computer that rely…

"two different versions of libwebsockets"

If your programs depend on different MAJOR versions of libwebsockets and libwebsockets' build system doesn't easily allow that to happen then complain to the developer of libwebsockets about it. If the developer of libwebsockets is not interested in solving this problem then complain to the developers of the programs which depend on libwebsockets that they should find a better library which doesn't suck. If they don't listen, rewrite the tools you depend on to not suck.

If, on the other hand, the programs depend on different minor versions of libwebsockets and libwebsockets broke API in such a way that just using the highest common version doesn't work then complain to the developer of libwebsockets that they should stop doing terrible things like breaking API and then complain to the developers of those applications that they shouldn't let this kind of breakage slide and should move to a different library.

If you think this is unrealistic then I think your push towards insane let's-pull-all-the-dependencies-into-one-binary/package build systems is unrealistic.

You want a sane build system? The change starts when you stop tolerating idiots who cause things not to work.

We don't tolerate engineers who build crappy bridges which break and kill people. You shouldn't be tolerating programmers who build crappy libraries which break API or don't allow two major-versions to be easily simultaneously installed and linked against.

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

#143

Post by enz » Sun, May 03, 2020, 5:05 PM UTC

This is not "de Raadt on Rust". There isn’t any de Raadt’s opinion on Rust.

This is Theo de Raadt on integrating Rust utilities in OpenBSD.

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

#144

Post by geocar » Sun, May 03, 2020, 5:06 PM UTC

gmanley wrote: post #115

geocar wrote: post #83

Earlier quoted context omitted.

That commit doesn't have any files in it. The first release of "uutils coreutils" appears to be this: https://github.com/uutils/coreutils/commit/511f138e3856e2d69... which is only twenty days young, and a 0.0.1 release to boot (whatever that means).

The first four utils were added 7+ years ago: https://github.com/uutils/coreutils/commit/9653ed81a2fbf393f... This has been developed for a while. You're looking at the official GitHub releases which doesn't mean much. It just means they just started providing official compiled releases. Not all projects even do that at all. I know a lot of people getting into Rust, including myself, started reading through this repo…

> You're looking at the official GitHub releases which doesn't mean much.

Fermat would like rust then.

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

#145

Post by appleflaxen » Sun, May 03, 2020, 5:08 PM UTC

>> As a response to this, Theo asked rhetorically "Where's ls, where's cat, where's grep, and where's sort?"

> I wasn't implying. I was stating a fact.

It doesn't affect his point, per se, but this is a confusing way to engage the topic.

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

#146

Post by hedora » Sun, May 03, 2020, 5:08 PM UTC

DougBTX wrote: post #98

cycloptic wrote: post #59

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…

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

If you care about security, api stability and legal compliance, you should minimize the number of developers and packages you trust. My rule of thumb is that, for a team of ~10 developers, each package dependency adds a week or two of developer maintenance time each year or so.

Having a dozen packages where one will do, and having them do the same thing recursively means you need to spend 144 times longer dealing with such things.

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

#147

Post by zamalek » Sun, May 03, 2020, 5:08 PM UTC

cycloptic wrote: post #59

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…

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…

His statement was that there was "no attempt" to write POSIX tools. As a "statement of fact." Irrespective of how much work there is still to do for coreutils in terms of compliance, they are an attempt. They may be be completely unsuitable as a drop-in replacement right now, but that was not the "fact" that he asserted.

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

#148

Post by LukeShu » Sun, May 03, 2020, 5:09 PM UTC

euler_angles wrote: post #121

random_savv wrote: post #114

Earlier quoted context omitted.

Cargo cult - what a great pun!

You can find many articles on the origin of the term. I like this one from 1959: https://www.scientificamerican.com/article/1959-cargo-cults-...

You're being downvoted--it's because you missed the pun. Everyone knows the term "cargo cult". The pun is combining that with that the Rust package manager is named "Cargo".

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

#149

Post by steveklabnik » Sun, May 03, 2020, 5:09 PM UTC

zozbot234 wrote: post #139

throwaway894345 wrote: post #111

Earlier quoted context omitted.

Comparing coreutils to a self-hosting compiler is a strained analogy. Bootstrapping a compiler is about as hard as it gets; there’s no reason coreutils needs to depend on itself.

There's "no reason" why the rustc build should depend on cargo, but apparently it does. And this makes it way harder than it should be to keep rustc support up-to-date in any distro, which in turn impacts stuff like Firefox updates.

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

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

#150

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

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.

> 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 purpose OS but I'm not gonna go there :)

> I don’t think healthy skepticism of Rust is strong enough evidence to conclude that they don’t care about security.

Cool, that was not my conclusion either. I'm saying that Rust's value proposition in general includes memory safety and I think that it's not compelling for most developers, especially with regards to rewrites of low-value attack surface.