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

81–90 of 400 posts

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

#81

Post by toast0 »

throwaway894345 wrote: post #72
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…

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…

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

This is an area where the BSDs are pretty good. There may not be a dependency system here exactly, but because XBSD base builds XBSD base, everything you need is in one checkout. Generally with just (BSD) Make driving the build.

Programs outside of base are genrerally built with Portfiles which specify dependencies such that (BSD) Make can satisfy them. But somebody has to write the Portfile, and it's often not the authors of the program.

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

#82

Post by nromiun »

> Adding such a toolchain would take make build time from 40 minutes to hours. I don't see how that would happen.

This should have been at the top of the email because this is the main issue (along with the i386 one). As other people have noted in this thread some people have already re-written basic utilities in Rust (and other languages).

Unless someone manage to make the Rust compiler much much faster then it is currently it won't get accepted into OpenBSD anytime soon.

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

#83

Post by geocar »

loup-vaillant wrote: post #42
skrebbel wrote: post #17

Earlier quoted context omitted.

You make valid point, but you can't fault Theo for predicting a different future in 2017.

https://github.com/uutils/coreutils/commit/d4e96b33e34373399... I read 2013, Theo de Raadt's email is from 2017, over 4 years later. I think we can fault him for being overconfident and not checking his facts.

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

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

#84

Post by naasking »

hvs wrote: post #69
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…

This is pretty much a judgment of Rust: Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Consider me a skeptic -- I think these compiler ecosystems face a grim bloaty future. I would think that OpenBSD developers/users would care about security, since that's pretty much the value-proposition of OpenBSD.

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.

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

#85

Post by sjakobi »

throwaway894345 wrote: post #72
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…

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…

Regarding build tools for C, you might find this one interesting:

https://github.com/vmchale/cpkg

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

#86

Post by ChristianBundy »

protomyth wrote: post #56
ChristianBundy wrote: post #35

Earlier quoted context omitted.

79 by my count, but I'd be happy to have someone correct me. https://github.com/uutils/coreutils/tree/ef4d09ee3c067c280ba... It looks to me like the only changes in that table since November 2017 are that `join` and `df` were moved from 'todo' to 'semi-done'.

Are they done, or did they move onto to something else?

I don't know.

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

#87

Post by steveklabnik »

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

> Is this really appropriate for a core system component to have this many dependencies? Absolutely not. The entire OpenBSD base system can be built without an internet connection.

You can also build Rust and its ecosystem without an internet connection. It works the same way; you need to get a copy of everything first, but the build itself does not require the internet.

(This has been a hard constraint for effectively forever, because both Firefox and Linux distributions have this requirement.)

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

#88

Post by BearOso »

I want to like the rust language. The syntax is nice and the features are interesting.

My problem is the ecosystem. The packaging and build system clearly isn’t designed to accommodate classic desktop applications. The FFI is really painful, and even Firefox has tons of wrapper code to just integrate with the libraries it needs to have a GUI.

In that respect I agree with Theo in that Rust developers are focusing on far too narrow of a use case, mostly web facing applications or data processing. Cargo being so similar to npm kind of confirms this. Rust isn’t intended for me.

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

#89

Post by ajross »

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…

> 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 made much progress in replacing exactly the software that it claims to be intended to replace!

Where are the pervasively used compression libraries in Rust? Video and audio codecs? Network stacks? Database engines? System management utilities? PKI and encryption stacks? All that stuff is still in C. After ten years of Rust success!

It's not like no one is using Rust. It's not like it doesn't have success stories (even in the categories above). But they're comparatively rare, still. 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.

And if there isn't after the first decade, what needs to change to make it happen in the second. I mean, is it maybe fair to say that the window is closing for rust to take over a significant fraction the systems programming world?

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

#90

Post by throwaway894345 »

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…

Most scripts don’t depend on the POSIX standards anyway, they depend on GNU or BSD programs. CPython’s configure script, for example, blows up if the system grep is BSD and not GNU. The whole C build ecosystem is duct tape anyway and things rarely build without tons of manual effort (figure out what versions of which dependencies need to be installed to which locations in the file tree and then maybe things will build, but none of it will be documented and good luck reverse engineering those Autotools/CMake scripts!), so citing concerns about breaking things seems really disingenuous.
Post reply on HN