4 ms·

This reminded me of Theo de Raadt's reply to 'Integrating "safe" languages into OpenBSD?': https://marc.info/?l=openbsd-misc&m=151233345723889&w=2 https://marc

This reminded me of Theo de Raadt's reply to 'Integrating "safe" languages into OpenBSD?': https://marc.info/?l=openbsd-misc&m=151233345723889&w=2 https://marc.info/?l=openbsd-misc&m=151233345723889&w=2

unixhero 6y ago
Interesting response. Pretty backwards of Theo to snub Rust-lang like that. It's pretty much attempting to achieve the same ideals as some of OpenBSD's.
- smabie 6y ago
  Eh, not really. OpenBSD is about simplicity more than anything else. It's no surprise that they don't want Rust, which is very complicated, into the OS. Also rustc is super complicated, and very slow. For example, for a time OpenBSD was trying to switch to pcc, a super simple C compiler so they could get off gcc. They eventually went with clang instead, which is not simple, but presumably the cost of using an alternative to gcc or clang was too high.
- secondcoming 6y ago
  It's not a snub of the language, it's a complaint about the compiler using all your memory. That's not an unreasonable complaint. It was also written 3 or so years ago, so hopefully rust has improved.
  - asveikau 6y ago
    I agree with your comment, but how often does a high memory program get better at memory usage over time? My intuition is that use of resources goes almost exclusively in one direction. Layers get added, less often removed. On the other hand the typical RAM amounts in common hardware gets higher too.
    - sanxiyn 6y ago
      Firefox did, while they did MemShrink project: https://wiki.mozilla.org/Performance/MemShrink https://wiki.mozilla.org/Performance/MemShrink. I note that Rust is in part developed by the same organization that brought a successful MemShrink project, so you should be more hopeful.
      - asveikau 6y ago
        Nice. On the other hand, I feel like people will tolerate high memory usage in a compiler much more than they will in a browser. Memory usage in general is very different between the two - in a compiler it will perform many allocations and discard quickly, whereas the pain in a browser is more likely sustained memory usage from long-running instances.
- pnako 6y ago
  Note that he did not snub the language but its toolchain. I think they already have enough trouble with Rust in the ports tree that they don't want the same thing in base.
  - deleted 6y ago
    [deleted]
- MintelIE 6y ago
  OpenBSD has to be able to build itself on fairly lean hardware, it's a design goal for the project. Rust has been in ports and packages forever if you want to install it.
tialaramex 6y ago
de Raadt is a remnant of the "real men" programming era. The upside of "real men" is that they write code, but then of course some Rust proponents write code too, and their code is in fact safer because to err is human. There's an ACME (e.g. for Let's Encrypt) client included in OpenBSD which is exactly what you'd expect a real man ACME client to look like. It uses OpenBSD-only pledge() and similar features to do privilege separation, it has guards and checks throughout and so long as there aren't any missing (but there's no way to verify...) it's probably safe to use it - but it's written in C rather than a safer language. There are some obvious security considerations you'd put in an ACME client, and somebody who thought OpenBSD was about security would probably expect them. But they are absent because it's not about security it's about being a real man. Examples: Using CSRs is safer as now the ACME client doesn't know your private keys, but acme-client doesn't provide any way to do that. Using the dns-01 challenge rather than http-01 or tls-alpn-01 allows you to do issuance from a system that isn't accessible from the outside world rather than having to open ports but acme-client only supports http-01 challenges.
- anjbe 6y ago
  I’m an OpenBSD developer (mostly a packager). IMO you’ve mischaracterized both Theo’s response and OpenBSD’s culture. If OpenBSD has a culture, it’s not “real men,” but “show me the code.” That’s plain from the mail linked in the post you responded to: mailing lists are full of people making suggestions (like “rewrite OpenBSD in Rust”), but few people doing the necessary work (like implementing or testing a reasonably POSIX‐compatible userland, handling the 8+ architectures that would immediately have to be dropped, measuring the performance impacts on the project build clusters…). Contrast the above response with the WireGuard implementation this whole discussion is about. A non‐OpenBSD contributor sent a draft patchset, which received suggestions and was iterated upon several times, and despite some complaints about the concept from one quarter (https://marc.info/?l=openbsd-cvs&m=159273877612032&w=2 https://marc.info/?l=openbsd-cvs&m=159273877612032&w=2), it was committed by the very person who had those complaints! In the end Jason and Matt of WireGuard described the process as “extremely pleasant” (https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588.html https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588...). This is feedback I see often from external contributors. You describe safety guards like privilege separation and pledge/unveil as “real men programming”, but they’re the complete opposite: they exist precisely to mitigate the damage that results from human error. acme-client’s design does keep private keys inaccessible this way (see https://kristaps.bsd.lv/acme-client/ https://kristaps.bsd.lv/acme-client/). Privilege separation is a proven technique. OpenBSD is not a project that says it’s okay to live dangerously as long as you code with the right macho attitude. There are plenty of valid things in OpenBSD to complain about—it might even be valid to argue that our resistance to Rust disproportionately values architectural concerns over memory safety!—but don’t blame “real men programming.” That’s just false. I am baffled as to why you attribute OpenBSD’s ACME client lacking DNS challenges to this same “real man” attitude rather than the simple reality that in a relatively small, completely volunteer project nobody has yet done the work to integrate that feature. If someone sent a patch to add dns-01 support—certainly something very useful that plenty of our users and developers want—I bet it would be committed within weeks.

unixhero 6y ago

Interesting response. Pretty backwards of Theo to snub Rust-lang like that. It's pretty much attempting to achieve the same ideals as some of OpenBSD's.

smabie 6y ago
Eh, not really. OpenBSD is about simplicity more than anything else. It's no surprise that they don't want Rust, which is very complicated, into the OS. Also rustc is super complicated, and very slow. For example, for a time OpenBSD was trying to switch to pcc, a super simple C compiler so they could get off gcc. They eventually went with clang instead, which is not simple, but presumably the cost of using an alternative to gcc or clang was too high.
secondcoming 6y ago
It's not a snub of the language, it's a complaint about the compiler using all your memory. That's not an unreasonable complaint. It was also written 3 or so years ago, so hopefully rust has improved.
- asveikau 6y ago
  I agree with your comment, but how often does a high memory program get better at memory usage over time? My intuition is that use of resources goes almost exclusively in one direction. Layers get added, less often removed. On the other hand the typical RAM amounts in common hardware gets higher too.
  - sanxiyn 6y ago
    Firefox did, while they did MemShrink project: https://wiki.mozilla.org/Performance/MemShrink https://wiki.mozilla.org/Performance/MemShrink. I note that Rust is in part developed by the same organization that brought a successful MemShrink project, so you should be more hopeful.
    - asveikau 6y ago
      Nice. On the other hand, I feel like people will tolerate high memory usage in a compiler much more than they will in a browser. Memory usage in general is very different between the two - in a compiler it will perform many allocations and discard quickly, whereas the pain in a browser is more likely sustained memory usage from long-running instances.
pnako 6y ago
Note that he did not snub the language but its toolchain. I think they already have enough trouble with Rust in the ports tree that they don't want the same thing in base.
- deleted 6y ago
  [deleted]
MintelIE 6y ago
OpenBSD has to be able to build itself on fairly lean hardware, it's a design goal for the project. Rust has been in ports and packages forever if you want to install it.

tialaramex 6y ago

de Raadt is a remnant of the "real men" programming era. The upside of "real men" is that they write code, but then of course some Rust proponents write code too, and their code is in fact safer because to err is human. There's an ACME (e.g. for Let's Encrypt) client included in OpenBSD which is exactly what you'd expect a real man ACME client to look like. It uses OpenBSD-only pledge() and similar features to do privilege separation, it has guards and checks throughout and so long as there aren't any missing (but there's no way to verify...) it's probably safe to use it - but it's written in C rather than a safer language. There are some obvious security considerations you'd put in an ACME client, and somebody who thought OpenBSD was about security would probably expect them. But they are absent because it's not about security it's about being a real man. Examples: Using CSRs is safer as now the ACME client doesn't know your private keys, but acme-client doesn't provide any way to do that. Using the dns-01 challenge rather than http-01 or tls-alpn-01 allows you to do issuance from a system that isn't accessible from the outside world rather than having to open ports but acme-client only supports http-01 challenges.

anjbe 6y ago
I’m an OpenBSD developer (mostly a packager). IMO you’ve mischaracterized both Theo’s response and OpenBSD’s culture. If OpenBSD has a culture, it’s not “real men,” but “show me the code.” That’s plain from the mail linked in the post you responded to: mailing lists are full of people making suggestions (like “rewrite OpenBSD in Rust”), but few people doing the necessary work (like implementing or testing a reasonably POSIX‐compatible userland, handling the 8+ architectures that would immediately have to be dropped, measuring the performance impacts on the project build clusters…). Contrast the above response with the WireGuard implementation this whole discussion is about. A non‐OpenBSD contributor sent a draft patchset, which received suggestions and was iterated upon several times, and despite some complaints about the concept from one quarter (https://marc.info/?l=openbsd-cvs&m=159273877612032&w=2 https://marc.info/?l=openbsd-cvs&m=159273877612032&w=2), it was committed by the very person who had those complaints! In the end Jason and Matt of WireGuard described the process as “extremely pleasant” (https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588.html https://lists.zx2c4.com/pipermail/wireguard/2020-June/005588...). This is feedback I see often from external contributors. You describe safety guards like privilege separation and pledge/unveil as “real men programming”, but they’re the complete opposite: they exist precisely to mitigate the damage that results from human error. acme-client’s design does keep private keys inaccessible this way (see https://kristaps.bsd.lv/acme-client/ https://kristaps.bsd.lv/acme-client/). Privilege separation is a proven technique. OpenBSD is not a project that says it’s okay to live dangerously as long as you code with the right macho attitude. There are plenty of valid things in OpenBSD to complain about—it might even be valid to argue that our resistance to Rust disproportionately values architectural concerns over memory safety!—but don’t blame “real men programming.” That’s just false. I am baffled as to why you attribute OpenBSD’s ACME client lacking DNS challenges to this same “real man” attitude rather than the simple reality that in a relatively small, completely volunteer project nobody has yet done the work to integrate that feature. If someone sent a patch to add dns-01 support—certainly something very useful that plenty of our users and developers want—I bet it would be committed within weeks.