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

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

#231

Post by jacquesm » Sun, May 03, 2020, 6:27 PM UTC

ashtonkem wrote: post #63

Datenstrom wrote: post #7

A rewrite of core utils[1] was started in 2013. commit d4e96b33e343733992fad55ac840c9649cd72ede Author: Jordi Boggiano Date: Fri Aug 2 09:22:57 2013 -0700 Initial commit Although I hope that Redox[2] takes off more so than rust makes it into existing systems. I dream of one day ordering a System76 with Redox already installed. [1]: https://github.com/uutils/coreutils.git [2]: https://www.redox-os.org/

I was going to say, all this discussion of whether you can make OS utilities in rust seems to be ignoring the entire OS that’s actually being written in rust!

How long until it will have the same kind of reputation that OpenBSD has?

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

#232

Post by throwaway894345 » Sun, May 03, 2020, 6:27 PM UTC

busterarm wrote: post #214

staticassertion wrote: post #167

Earlier quoted context omitted.

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

Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead... I hate to say this but Bazel is probably the first time we have a tool that's better than make. It took over 40 years to get here. And it's still a pain in the ass.

> Considering the staggering number of languages out there that have implemented their own worse-version of make, or even those that haven't and the language-agnostic tooling systems that are implementing make instead...

The language-specific build tools tend to be good, at least for mainstream languages introduced in the last 20 years. Certainly better than make.

Bazel and especially Nix are really interesting and directionally correct, but like you mention, they are pains in the ass. Fortunately, their issues aren’t fundamental to the category of general purpose reproducible build tools. They’re just issues of execution. And arguably Nix isn’t even trying to be a build tool as much as a packaging tool (subtle but manifestly important difference), which is a damn shame.

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

#233

Post by GrayShade » Sun, May 03, 2020, 6:28 PM UTC

steveklabnik wrote: post #149

zozbot234 wrote: post #139

Earlier quoted context omitted.

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.

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.

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

#234

Post by hu3 » Sun, May 03, 2020, 6:29 PM UTC

protomyth wrote: post #31

Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space. Is this true anymore or just a history note?

> For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

Last I checked Rust needed more than 4GB of RAM to compile itself.

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

#235

Post by steveklabnik » Sun, May 03, 2020, 6:29 PM UTC

zerpelin68 wrote: post #208

steveklabnik wrote: post #198

Earlier quoted context omitted.

The only issue memory leaks can cause is being a DDoS vector. Memory unsafety can cause a host of other issues, and much more serious ones. It is also very difficult to come up with a definition of "memory leak" that doesn't include programmer intention, and so it's not clear that you can come up with static analysis to preclude it.

Agreed there is not much you can do about a programmer using memory in an unsafe way...so what is the point?

You can, in general. Just not for memory leaks.

The point is defense in depth.

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

#236

Post by Ensorceled » Sun, May 03, 2020, 6:31 PM UTC

gdy wrote: post #118

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 The words 'gatekeeping' and 'toxic' are toxic.

Agreed, and it's even more toxic to use "gatekeeping" in this fashion for somebody who is LITERALLY a gatekeeper for the project under discussion.

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

#237

Post by jacquesm » Sun, May 03, 2020, 6:34 PM UTC

quotemstr wrote: post #161

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…

What a load of bullshit. Theo has had more staying power than the Rust community collectively to date as a maintainer of a mission critical OS. That's a lot of responsibility and I personally very much value his defense of what matters a lot to me: backwards compatibility. Not breaking stuff is the prime directive at that level. Suggesting that your rewritten, non compliant, non-drop in replacements and associated toolchain should be part of the default is hubris at a level that does not befit nor benefit the Rust community.

If you want to reach that level then you need to commit for real, and solve those issues that Theo rightfully marks. Even though this was written in 2017 it is just as applicable today: either you replacement is as good on all fronts as the thing it replaces and has some additional benefits replacement of something battle tested makes no sense.

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

#238

Post by busterarm » Sun, May 03, 2020, 6:34 PM UTC

eximius wrote: post #173

bsdubernerd wrote: post #103

It also doesn't help that Rust keeps on pushing on the idea that "static linking is the only way to go". This is another cargo-cult which I wish didn't end up being engrained so deep in the toolchain because while it has some merits, it also has significant drawbacks of a typical unix distribution. Static linking might be good for folks distributing a single server binary over a fleet of machines (pretty much like Go…

I don't think the position of the language teams is that static linking is better than dynamic linking. I think that static linking is a significantly easier target for a relatively new language whose _novel_ features make it difficult to define a stable ABI. Under the very specific constraints that Rust is operating in, static linking is currently the best option. That said, I wouldn't mind seeing some kind of ABI g…

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.

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

#239

Post by afiori » Sun, May 03, 2020, 6:35 PM UTC

ddevault wrote: post #210

afiori wrote: post #195

Earlier quoted context omitted.

> bundling an entire Chromium build with their app is a good idea. Does Chromium offer any other type of linking? I mean, is the problem in the developer including it when another option is possible or the fact that no other option is possible?

The problem is reaching for Chromium to solve any problem in the first place.

But chromium offers a lot of relevant functionality. If I remember correctly one of the alleged reasons Microsoft moved to a chromium browser was to actually sort of include it in the OS and have electron apps link to it dynamically.

But before that time the chromium bloat is 100% independent from the static linking bloat.

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

#240

Post by jacquesm » Sun, May 03, 2020, 6:36 PM UTC

Mordak wrote: post #64

dochtman wrote: post #15

Perhaps relevant: Ted Unangst recently wrote some Rust code: https://flak.tedunangst.com/post/reliverator

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.