11 ms·

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

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

mrweasel 9y ago
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.
- jrs95 9y ago
  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.
  - zaarn 9y ago
    Linux supported i386 until 2012, I think in this context it is more likely to refer to pre-Pentium 86 CPUs though (I'm not certain on that) I've seen i386 multiple times to also refer to any x86 Arch.
    - dmm 9y ago
      i386 in this context refers to 32bit intel x86 cpu architecture in general and generic pc compatibles specifically. OpenBSD currently runs on 486s and better: > All CPUs compatible with the Intel 80486 or better,[0] [0]https://www.openbsd.org/i386.html https://www.openbsd.org/i386.html
  - tsmarsh 9y ago
    One of OpenBSDs sweet spots is turning old hardware into useful, secure, reliable, network infrastructure. i386 might not be as popular as it was on 'normal' OS, but I wouldn't be surprised if OpenBSD had a lot of people still using it.
  - raimue 9y ago
    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 https://www.openbsd.org/plat.html
    - masklinn 9y ago
      > On a project such as OpenBSD they cannot suddenly drop platforms and only support amd64 as portability They… don't need to? That rustc can't compile itself on i386 doesn't mean you can't ship a rustc for i386, it just means you have to cross-compile it.
      - _jal 9y ago
        Addressed in the article. > In OpenBSD there is a strict requirement that base builds base.
      - raimue 9y ago
        I see it as part of portability that you do not need to use any external system for bootstrapping. Imagine as a developer who compiles base from source you had to find another system only to compile rustc and then transfer it to your machine. And you would not have to do this only once, but for every compiler bug fix coupled with the overall rapid evolution of Rust. I think many in the OpenBSD community would oppose such an approach, even without further considering other aspects such as security implications.
        clort 9y ago
        This is the case IIRC with Android - even though I want to build it for a 32-bit ARM architecture, I can't build it on anything but 64-bit. I guess the vast majority of Android systems cannot even compile Android! https://source.android.com/setup/requirements https://source.android.com/setup/requirements
  - DCKing 9y ago
    OpenBSD is a perfectly servicable operating system on an old Atom board I have (nice router!), and on i386 only Core Duo iMacs/Macbooks long abandoned by Apple. These will be perfectly good machines to use for a long time, and it's really great you can get up to date support on these systems from this great project. Obsolete means different things to different people. I'm a big fan of what Rust promises, but the solution is not that OpenBSD changes its policies or that OpenBSD drops i386. Rust should become self hosting on i386.
  - mfukar 9y ago
    There's significant infrastructure in place that uses i386. It used to be fairly popular, I'm sure you can google it.
  - rubyfan 9y ago
    Theo would say, if you think so then get to writing code instead of commenting about it. These aren’t just philosophical comments, the implications for him and OBSD devs is to spend massive time developing these things. Dropping a supported platform and taking on a huge investment of effort needs serious justification.
  - jlgaddis 9y ago
    Yep: $ uname -a OpenBSD hostname 5.9 GENERIC.MP#6 i386
- sillysaurus3 9y ago
  Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.
  - oblio 9y ago
    It depends what kind of performance. The only performance they are "lacking" seems to be compilation speed (an annoyance, but they're working on it) and compilation memory usage (rarely a problem, considering we also have C++, Java and C# around :) ).
  - ionforce 9y ago
    Are you implying that Rust isn't performant?
    - yellowapple 9y ago
      If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.
      - mikepurvis 9y ago
        Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.
        madez 9y ago
        So, you say Python is totally missing the point and is wrong? Even when encoding videos, performance matters. Also, that optimizing compilation is important is no reason to not work on i386. This is a point Rust needs to fix. And not only i386 support, but also other architecture families, as host.
        9y ago
- rtpg 9y ago
  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.
  - 2trill2spill 9y ago
    > 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 https://www.openbsd.org/plat.html
    - JetSetWilly 9y ago
      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.
      - Paianni 9y ago
        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.
        yellowapple 9y ago
        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.
- accurrent 9y ago
  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. Go's GC makes it a show stopper for use in many places as for haskell I would be very interested to see more low level embedded programming going on in it.
  - masklinn 9y ago
    > 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?
    - _jal 9y ago
      He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong. i386 is relevant because OpenBSD supports i386.
      - HelloNurse 9y ago
        And if the end user is unable to compile everything, i386 would be only half-supported (or maybe, for the austere OpenBSD maintainers, not supported at all).
      - masklinn 9y ago
        > He's talking specifically about OpenBSD base. No, he is very explicitly saying that > There has been no attempt […] provide replacements for base POSIX utilities. Which once again is categorically false, a github repository purporting to do exactly that has been provided. > i386 is relevant because OpenBSD supports i386. i386 is supported, the issue is compiling the compiler on i386.
IshKebab 9y ago
And Go: https://github.com/ericlagergren/go-coreutils https://github.com/ericlagergren/go-coreutils Does he really not know this or is he ignoring them to make a point?
- tankenmate 9y ago
  Some would consider Go to not be as safe as Rust for example. But his argument still holds for POSIX compliance, it is a loveless task so it it gets done at snail's pace.
- deleted 9y ago
  [deleted]
- akerro 9y ago
  It uses remote dependencies. First compilation in a single-run environment will be very slow, there won't be second compilation. Go compiler is fast when you add the `-i` flag, without it it takes a couple of seconds to compile a few hundred lines, a few more minutes when you have to `go get` packages. Now, github goes down, your build is broken for that time.
  - gjem97 9y ago
    Not sure what the "it" is in your first sentence, but allow me to address the rest of your points. "First compilation ... will be very slow": the go compiler is in fact quite fast, orders of magnitude faster than C++ or rust compilers. The fact that there's a noticeable pause when you want to compile thousands of files does not mean that its slow. "There won't be a second compilation": not for each top level tool, but there certainly could be shared packages that don't need to be recompiled. "Go compiler is fast when you add the `-i` flag", ok, do that then. "Now, github goes down, your build is broken": you only need to depend on external github references if you want always to build against the latest version of your referenced code. I can't imagine anyone interested in stability wants this. There are lots of options for vendoring your dependencies in tree.
    - akerro 9y ago
akerro 9y ago
>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, environment... as safe as it was never compromised. OpenBSD compiles everywhere where C code works, Rust/Cargo works where it's supported and it will takes decades to catch-up on some architectures.
- hood_syntax 9y ago
  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 compiler. I may be remembering the details a bit wrong, but it was a good read.
  - traverseda 9y ago
    You want the "trusting trust" keyword.
  - skj 9y ago
    A talk by Ken Thompson, "trusting trust".
    - mcguire 9y ago
      Technically, his Turing award lecture.
  - edwincheese 9y ago
    I think you are referring to “Reflections on Trusting Trust” by Ken Thompson. https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

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

mrweasel 9y ago

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.

jrs95 9y ago
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.
- zaarn 9y ago
  Linux supported i386 until 2012, I think in this context it is more likely to refer to pre-Pentium 86 CPUs though (I'm not certain on that) I've seen i386 multiple times to also refer to any x86 Arch.
  - dmm 9y ago
    i386 in this context refers to 32bit intel x86 cpu architecture in general and generic pc compatibles specifically. OpenBSD currently runs on 486s and better: > All CPUs compatible with the Intel 80486 or better,[0] [0]https://www.openbsd.org/i386.html https://www.openbsd.org/i386.html
- tsmarsh 9y ago
  One of OpenBSDs sweet spots is turning old hardware into useful, secure, reliable, network infrastructure. i386 might not be as popular as it was on 'normal' OS, but I wouldn't be surprised if OpenBSD had a lot of people still using it.
- raimue 9y ago
  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 https://www.openbsd.org/plat.html
  - masklinn 9y ago
    > On a project such as OpenBSD they cannot suddenly drop platforms and only support amd64 as portability They… don't need to? That rustc can't compile itself on i386 doesn't mean you can't ship a rustc for i386, it just means you have to cross-compile it.
    - _jal 9y ago
      Addressed in the article. > In OpenBSD there is a strict requirement that base builds base.
    - raimue 9y ago
      I see it as part of portability that you do not need to use any external system for bootstrapping. Imagine as a developer who compiles base from source you had to find another system only to compile rustc and then transfer it to your machine. And you would not have to do this only once, but for every compiler bug fix coupled with the overall rapid evolution of Rust. I think many in the OpenBSD community would oppose such an approach, even without further considering other aspects such as security implications.
      - clort 9y ago
        This is the case IIRC with Android - even though I want to build it for a 32-bit ARM architecture, I can't build it on anything but 64-bit. I guess the vast majority of Android systems cannot even compile Android! https://source.android.com/setup/requirements https://source.android.com/setup/requirements
- DCKing 9y ago
  OpenBSD is a perfectly servicable operating system on an old Atom board I have (nice router!), and on i386 only Core Duo iMacs/Macbooks long abandoned by Apple. These will be perfectly good machines to use for a long time, and it's really great you can get up to date support on these systems from this great project. Obsolete means different things to different people. I'm a big fan of what Rust promises, but the solution is not that OpenBSD changes its policies or that OpenBSD drops i386. Rust should become self hosting on i386.
- mfukar 9y ago
  There's significant infrastructure in place that uses i386. It used to be fairly popular, I'm sure you can google it.
- rubyfan 9y ago
  Theo would say, if you think so then get to writing code instead of commenting about it. These aren’t just philosophical comments, the implications for him and OBSD devs is to spend massive time developing these things. Dropping a supported platform and taking on a huge investment of effort needs serious justification.
- jlgaddis 9y ago
  Yep: $ uname -a OpenBSD hostname 5.9 GENERIC.MP#6 i386
sillysaurus3 9y ago
Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.
- oblio 9y ago
  It depends what kind of performance. The only performance they are "lacking" seems to be compilation speed (an annoyance, but they're working on it) and compilation memory usage (rarely a problem, considering we also have C++, Java and C# around :) ).
- ionforce 9y ago
  Are you implying that Rust isn't performant?
  - yellowapple 9y ago
    If compilation exhausts the IA32 address space, then I'd say it's not adequately performant as a whole, regardless of how "efficient" the resulting binaries might be.
    - mikepurvis 9y ago
      Hard disagree. Compilation is like encoding a video— it's a price you pay once, and if you know the resulting binary will be run millions of times, it's totally worthwhile spending a lot of compute and memory upfront to get that binary as fast as possible.
      - madez 9y ago
        So, you say Python is totally missing the point and is wrong? Even when encoding videos, performance matters. Also, that optimizing compilation is important is no reason to not work on i386. This is a point Rust needs to fix. And not only i386 support, but also other architecture families, as host.
        9y ago
rtpg 9y ago
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.
- 2trill2spill 9y ago
  > 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 https://www.openbsd.org/plat.html
  - JetSetWilly 9y ago
    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.
    - Paianni 9y ago
      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.
      - yellowapple 9y ago
        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.
accurrent 9y ago
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. Go's GC makes it a show stopper for use in many places as for haskell I would be very interested to see more low level embedded programming going on in it.
- masklinn 9y ago
  > 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?
  - _jal 9y ago
    He's talking specifically about OpenBSD base. Unless you can point to a rust binary in OpenBSD that Theo forgot about, he's not wrong. i386 is relevant because OpenBSD supports i386.
    - HelloNurse 9y ago
      And if the end user is unable to compile everything, i386 would be only half-supported (or maybe, for the austere OpenBSD maintainers, not supported at all).
    - masklinn 9y ago
      > He's talking specifically about OpenBSD base. No, he is very explicitly saying that > There has been no attempt […] provide replacements for base POSIX utilities. Which once again is categorically false, a github repository purporting to do exactly that has been provided. > i386 is relevant because OpenBSD supports i386. i386 is supported, the issue is compiling the compiler on i386.

IshKebab 9y ago

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

tankenmate 9y ago
Some would consider Go to not be as safe as Rust for example. But his argument still holds for POSIX compliance, it is a loveless task so it it gets done at snail's pace.
deleted 9y ago
[deleted]
akerro 9y ago
It uses remote dependencies. First compilation in a single-run environment will be very slow, there won't be second compilation. Go compiler is fast when you add the `-i` flag, without it it takes a couple of seconds to compile a few hundred lines, a few more minutes when you have to `go get` packages. Now, github goes down, your build is broken for that time.
- gjem97 9y ago
  Not sure what the "it" is in your first sentence, but allow me to address the rest of your points. "First compilation ... will be very slow": the go compiler is in fact quite fast, orders of magnitude faster than C++ or rust compilers. The fact that there's a noticeable pause when you want to compile thousands of files does not mean that its slow. "There won't be a second compilation": not for each top level tool, but there certainly could be shared packages that don't need to be recompiled. "Go compiler is fast when you add the `-i` flag", ok, do that then. "Now, github goes down, your build is broken": you only need to depend on external github references if you want always to build against the latest version of your referenced code. I can't imagine anyone interested in stability wants this. There are lots of options for vendoring your dependencies in tree.
  - akerro 9y ago

akerro 9y ago

>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, environment... as safe as it was never compromised. OpenBSD compiles everywhere where C code works, Rust/Cargo works where it's supported and it will takes decades to catch-up on some architectures.

hood_syntax 9y ago
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 compiler. I may be remembering the details a bit wrong, but it was a good read.
- traverseda 9y ago
  You want the "trusting trust" keyword.
- skj 9y ago
  A talk by Ken Thompson, "trusting trust".
  - mcguire 9y ago
    Technically, his Turing award lecture.
- edwincheese 9y ago
  I think you are referring to “Reflections on Trusting Trust” by Ken Thompson. https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...