> 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…
Re: Integrating "safe" languages into OpenBSD? (2017)
91–100 of 400 posts
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#92Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#93> 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…
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#94Earlier quoted context omitted.
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)
#95> 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 rather startling to me how tail-wagging-the-dog, or maybe chicken-and-egg, this situation is. Did anyone stop to consider that the reason why some of these utilities aren't being rewritten is because the unix old guard doesn't want to support it in the toolchain? If this guy is the wall that you'll eventually have to crash your car into, I'm not going to get behind the wheel in the first place. Why waste my time?
Look; the compile limitations are real. I'm not saying that it should be supported. But, attitudes like the one are not productive. What is it about operating system devs and these aggressive, mean, anti-social, self-important personalities? A response worded like this should not be tolerated by the community. It would have been just as easy and clear to say "We don't have toolchain support for Rust, and we're really not interested in supporting it due to its compile time and architecture support issues. . . We can revisit this discussion in the future if/when these improve."
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#96This 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…
Except that people have run into the exact same issue with stuff like rustc and cargo. Bootstrapping an entirely new platform is just hard, no way around it.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#97Earlier quoted context omitted.
I think Theo's reply was a bit excessive in some regards but I can also understand him being frustrated when you've been working on a very complex project for decades and somebody comes around and say "uh, why don't you rewrite it in ?". It's seldom a very interesting or constructive discussion. If you think Rust has something to bring to some project then you should at least take the time to write a decent proof of…
I think he was very polite.
>As a general trend the only things being written in these new languages are new web-facing applications, quite often proprietory or customized to narrow roles. Not Unix parts.
This doesn't really match what I saw of the Rust ecosystem and, even if it did, being able to write proprietary web-facing apps doesn't preclude one from writing "Unix parts". It's as if I said that C++ couldn't be used to write Unix utilities because it's used to write proprietary videogames. It's not a very good argument IMO.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#98> 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…
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/coreutils/blob/6e8c901204934029c88...
My impression is that ecosystems where tracking dependencies is hard tend to discourage them, while ecosystems where tracking dependencies is easy encourage them. The coreutils crate depends on separate md5, sha1, sha2, and sha3 crates, if managing external dependencies was hard I imagine those would be bundled together. But it is easy, so it makes sense to organise the crates so that each just provides one specific piece of functionality. Think single responsibility principle applied to packaging.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#99Earlier 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…
Regarding build tools for C, you might find this one interesting: https://github.com/vmchale/cpkg
If anyone knows of a distribution that aims to use only software with sane build systems, let me know, I would be very curious.
Re: Re: Integrating "safe" languages into OpenBSD? (2017)
#100> 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…
Sort of. It's only been five years since it was actually stable enough for production use. (with a few exceptions of folks who were really invested)