Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

71–80 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

#71
post #57

Earlier quoted context omitted.

Linux and BSD ran for a long time on 32bit systems. 4GB of memory is an ocean in my mind. Those systems should be able to compile their own programs and tools. On a related note, we will eventually be running development tools on microcontrollers. Not that little 16bit parts will run the tools, but that 16bit parts are going away. In price sensitive areas this will not happen, but for things with a larger budget why…

They don't mean "x86" (the 32bit instruction set), but i386 aka Intel 80386, a processor introduced in 1985: https://en.wikipedia.org/wiki/Intel_80386

https://en.wikipedia.org/wiki/IA-32

It includes 486, Pentium, etc.

Re: Integrating “safe” languages into OpenBSD?

#72
post #5
post #3

Earlier quoted context omitted.

That is sort of addressed by Theo: >Such ecosystems come with incredible costs. For instance, rust cannot even compile itself on i386 at present time because it exhausts the address space.

People are still using i386? I'd assume even if they are, it's such a tiny minority that it shouldn't be an excuse to hold everyone else back.

There's significant infrastructure in place that uses i386. It used to be fairly popular, I'm sure you can google it.

Re: Integrating “safe” languages into OpenBSD?

#73

Earlier quoted context omitted.

Considering the complete lack of viable competition in the space, that day is a long way off.

Why is Redox not viable competition?

Redox is an unproven toy OS compared to some of the more mature and battletested alternatives. And don't think battletested is a metaphore, some of these have been used to operate battlegear.

Re: Integrating “safe” languages into OpenBSD?

#74
post #44

A bit incendiary: I fail to see what advantage rewriting existing and proven tools with a new language would bring. Shouldn't the main value new tools bring to be enable writing of new things? Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value?

> I fail to see what advantage rewriting existing and proven tools with a new language would bring.

This is not the first rewrite, and won't be the last one. Earlier environments were very memory-constrained, which led to optimizing for memory usage; a rewrite with less memory constraints can focus on speed (as mentioned in the GNU coding standards: "For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. [...]").

The current challenge is the "end of Moore's law" leading to an increasing use of multiple cores, instead of faster cores. Developers will have to focus on parallelism instead of raw speed, and new languages can help.

> Shouldn't the main value new tools bring to be enable writing of new things?

Or writing old things in a new way.

> Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value?

These tools are the base over which your system is built (their GNU version isn't named "coreutils" for nothing). Focusing more effort on them makes sense.

Re: Integrating “safe” languages into OpenBSD?

#75

Earlier quoted context omitted.

He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether its a good thing or a bad thing. Also in terms of systems languages I believe only rust has some potential to truly replace C. Although, a large part of C usage still takes place in the embedded world where rust has yet to be ported to many embedded processors.…

> He has a point though… Does he? He "stat[es as] fact" that > There has been no attempt to move the smallest parts of the ecosystem, to provide replacements for base POSIX utilities. which as xwvvvvwx notes is categorically wrong, then points out that rustc can't compile itself on i386, which is relevant… how?

> then points out that rustc can't compile itself on i386, which is relevant… how?

Remember he is speaking as the leader of an operating system project. As in, a basic part of the project functioning normally is compiling the whole thing from scratch. If something needs cross-compilation to even get started it won't end up in OpenBSD base.

I seem to recall when it supported more architectures they made a public show about how they weren't going to cross compile even for targeting wimpy/sluggish machines, because recompiling the OS was a good stress test for the kernel itself.

Re: Integrating “safe” languages into OpenBSD?

#76
post #12
post #2

Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils

>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 cargo supported on i386 platforms? Also Rust complies itself, afaik there is no way to compile Rust/Cargo but to use previous version of it. If one of the past builds of Rust is backdoored, any version between then and now is backdoored, language is safe, envir…

Okay, there's a lot of misunderstandings here. Theo is right about some things, and wrong about some things. And people are misunderstanding what things he's right about. The things he's wrong about are very minor.

Rust absolutely works on 32-bit platforms, though we often use the i686 target rather than an i386 one. Platform support list is here: https://forge.rust-lang.org/platform-support.html

Theo is talking about building rustc, not compiling most Rust programs. That's the first distinction that it seems like many people are missing.

However, apparently the compilation process OOMs when building on a i386 box. I don't use those platforms, but I'd believe it. The Rust compiler is large. However, I thought (and looking at our CI, this seems to be true https://travis-ci.org/rust-lang/rust/jobs/311223817) we do compile with an i686-unknown-linux-gnu host (for this build), so I dunno. Maybe it was a fluke, maybe I'm misunderstanding, I'm not sure.

We often provide artifacts via cross-compiling, but this is unacceptable to OpenBSD. That's totally okay. They have good reasons for doing this.

Re: Integrating “safe” languages into OpenBSD?

#77

Earlier quoted context omitted.

I'm pretty sure that attack you describe is mentioned in literature as essentially undefeatable. I really wish I could remember exactly what the name of it was; the gist is, there has to be a first compiler somewhere. If at any point in the chain, the compiler is infected with a self-propagating virus that hides itself in the byte code of the binary, it can ensure that the exploit is in every future version of the co…

There is a possible defense: https://www.dwheeler.com/trusting-trust/

... and the hope is that https://github.com/thepowersgang/mrustc will let us do this for Rust.

Re: Integrating “safe” languages into OpenBSD?

#78
post #6
post #2

Maybe I'm misunderstanding but there is a pretty serious effort to rewrite all the gnu coreutils in Rust: https://github.com/uutils/coreutils

And Go: https://github.com/ericlagergren/go-coreutils Does he really not know this or is he ignoring them to make a point?

go-coreutils is abandoned, and not POSIX compliant. It was meant to be a proof-of-concept, and it kind of was, in a negative way.

Re: Integrating “safe” languages into OpenBSD?

#79
post #21
post #10

Earlier quoted context omitted.

This seems like a bit of a trite point unless many rust developers are actually working inside i386. Though the compiler itself might not work very well in i386. Not many people are whining about our C compiler toolchains not fitting into our microcontrollers.

Every port being self-hosting is a fundamental project value in OpenBSD. The reason being that they believe every port should be useful and functional, not just a novelty. And requiring that every port be self-hosting is a way to enforce this. For example, the NetBSD project has a dreamcast port, but like most of their ports, it is crosscompiled. The last time I tried the port it would crash when put under high load…

Thanks for the context, that wasn't clear to me.

Re: Integrating “safe” languages into OpenBSD?

#80
post #58

Earlier quoted context omitted.

At this point i386 is legacy for most of the world. OpenBSD is an ultra-conservative, orthodox project, therefore they will probably support i386 for years into the future - I mean, they supported VAX until 2016. That is a choice they are entitled to make, the trade-off being it would appear to make most modern technologies a poor fit for adoption in OpenBSD - that's the price they have to pay. It is a problem of the…

If OBSD feels it can make use of older arches then so be it, many users will find less intensive jobs for the respective hardware and it saves it from going to waste/recycling.

Not to mention plenty of people in the "developed" world (let alone "developing") can't afford to buy a new computer, and thus are going to use 32-bit "legacy" desktops and laptops for a very long time.
Post reply on HN