Live data from Hacker News

Integrating “safe” languages into OpenBSD?

marc.info

31–40 of 344 posts

Re: Integrating “safe” languages into OpenBSD?

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

OpenBSD supports a wide variety of hardware platforms, including machines with Alpha, PA-RISC, and SPARC64 processors. On each of them, the base system is able to compile itself.

If rustc cannot even build itself on i386, what kind of support can we expect for other platforms with an even smaller user base?

On a project such as OpenBSD they cannot suddenly drop platforms and only support amd64 as portability is one of their main "selling" points. Furthermore, that would also mean to lose the developers that are interested in these alternative platforms and probably chose OpenBSD because of the platform support. Furthermore, such developers are usually not only contributing to platform-specific parts, but also to system utilities and ports.

For the full list of platforms, see https://www.openbsd.org/plat.html

Re: Integrating “safe” languages into OpenBSD?

#32

> So rather than bothering to begin, you wrote an email. This is where Theo appears to me to be quite different to eg Linus. He plays the man, not the ball, with personal attacks.

I believe that Linus's attacks are usually good intentioned, to get people in the Linux community to act better. I am not sure what Theo's intent is.

If you want to effect change, do some work, don't write emails.

Re: Integrating “safe” languages into OpenBSD?

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

Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.

The performance of the compiled code is great, and the performance of the compiler is something they have identified as a major issue to fix, and are working to solve it.

Re: Integrating “safe” languages into OpenBSD?

#35
post #12

Earlier quoted context omitted.

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

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…

I think you are referring to “Reflections on Trusting Trust” by Ken Thompson.

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

Re: Integrating “safe” languages into OpenBSD?

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

> 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. Trite point? OpenBSD supports 1386[1] if they pull a rust compiler into base and start rewriting things in rust, then they can't support 1386. Dropping a supported platform is not a "trite point". [1]: https://www.openbsd.org/plat.html

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 their own making.

Re: Integrating “safe” languages into OpenBSD?

#37
post #12

Earlier quoted context omitted.

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

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/

Re: Integrating “safe” languages into OpenBSD?

#38
post #12

Earlier quoted context omitted.

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

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…

You're looking for "Reflections on Trusting Trust" by Ken Thompson, one of the original co-authors of Unix:

https://dl.acm.org/citation.cfm?id=358210

Re: Integrating “safe” languages into OpenBSD?

#39
i also saw the same eurobsdcon youtube video. i agree it is somewhat hard to imagine replacing long-time unix tools with newer versions that only differ in being implemented in a new language. making sure nothing breaks takes so much time, with not enough reward.

but writing new tools in safer languages makes more sense to me.

yes, you would need the toolchain in base. not easy, but should be possible. i only know go. perhaps it's still too much of a moving target for openbsd.

you could write programs in new safe language and put them in openbsd ports. problem is that it then isn't a "part of openbsd". do openbsd developers really want to write their next daemon in c? for how long will they stick to c?

Re: Integrating “safe” languages into OpenBSD?

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

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?

Post reply on HN