7 ms·

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

by 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.
      - Paianni 9y ago
        Unfortunately those sorts of people tend to be less informed about I.T and that eventually leads to their NetBurst, Pentium M and Atom machines performing even slower than they would be if they were maintained probably. They probably waste more power waiting for the machines to accomplish their tasks in an under-maintained state.
  - Annatar 9y ago
    OpenBSD is an ultra-conservative, orthodox project, ...which is exactly the kind of a system one needs for production environments.
  - kps 9y ago
    “i386” is OpenBSD's label for the 32-bit Intel architecture (they don't actually support the 80386). Intel still sells these.
    - Paianni 9y ago
      They support 486's though, which is quite rare for 2017.
      - emidln 9y ago
        486s and 586s are still sold for usage as embedded systems. They are well understood and some of them managed to pass certification decades ago.
        cat199 9y ago
        not to mention, 386 or not, there's still other 'odd' 32bit platforms which still have huge use for embedded things where openbsd would work great (hello mips/arm32, for starters)
        kps 9y ago
        You can still buy 32-bit Xeons, even. Sometimes srs bsns requires stability, too. https://ark.intel.com/Search/FeatureFilter?productType=processors&FilterCurrentProducts=true&InstructionSet=32-bit&FamilyText=Intel%C2%AE%20Xeon%C2%AE%20Processors https://ark.intel.com/Search/FeatureFilter?productType=proce...
      - JdeBP 9y ago
        There's a 32-bit x86 processor in every PC with the Intel Management Engine version 11 or later.
- rtpg 9y ago
  So... my main point was that "I have to cross-compile the rust compiler from another arch" is not equivalent to "rustc is not usable in i386". And even if rustc wasn't usable in i386, the binary it produces would be. So you could have a scenario where the i386 binaries would have to be cross compiled from a 64-bit machine but the end result would work just fine on those machines. I wasn't aware that OpenBSD's objectives included having each arch be able to build itself. Totally reasonable goal. It's harder to do "dreamcast port"s in those scenarios, though.
- drb91 9y ago
  How do you even find an i386 processor these days?
  - 2trill2spill 9y ago
    In the OpenBSD world i386 == x86. And it's pretty easy to find an x86 processor now a days.
    - deathanatos 9y ago
      … such as? You're merely restating the claim, without providing any proof. Consumer machines, AFAICT, are all amd64 (or x86_64, if you prefer that name). I understood the original post to mean i386 == x86, and I agree — where do you even find an x86 today (for sale, in a non-niche use case, i.e., "pretty easy")?
      - kelnos 9y ago
        OpenBSD has as a goal to run on much more than just standard currently-sold consumer hardware. You can certainly disagree with that goal, but that doesn't make it go away.
        drb91 9y ago
        Oh I totally get this—but what is this hardware that people are still using OpenBSD with that they haven't upgraded in 30 years? Targeting i386 as opposed to, say, i486 or i686 seems like an exercise in idealistic masochism.
        kelnos 9y ago
        I think you're misunderstanding: "i386" is just shorthand for "32-bit Intel". They're not specifically talking about the 80386 chip. The same problem exists when you consider newer 32-bit chip families in that ISA.
      - zaarn 9y ago
dmm 9y ago
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 for a while and would kernel panic when you tried to play audio. The netbsd dreamcast port is not functional in the sense that openbsd would like to enforce, something which is not relevant to netbsd and in no way denigrates them, but merely serves as an example.
- rtpg 9y ago
  Thanks for the context, that wasn't clear to me.
phkahler 9y ago
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 not run the tools right on the target? If your controller is an RPi why not use it for development?
- norswap 9y ago
  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/Intel_80386
  - monochromatic 9y ago
    https://en.wikipedia.org/wiki/IA-32 https://en.wikipedia.org/wiki/IA-32 It includes 486, Pentium, etc.
  - imtringued 9y ago
    From the article you linked: > the 80386 instruction set, programming model, and binary encodings are still the common denominator for all 32-bit x86 processors, which is termed the i386-architecture, x86, or IA-32, depending on context.
empath75 9y ago
It’s not a trite point for BSD but if those are the kinds of objections holding back adoption by Linux and bsd, then I think the end result will just be a new Rust-first operating system.
- npsimons 9y ago
  > It’s not a trite point for BSD but if those are the kinds of objections holding back adoption by Linux and bsd, then I think the end result will just be a new Rust-first operating system. That would be great! Get back to me when it exists, instead of trying to dissuade an already established project from one of it's primary goals and handwaving said goals as "outdated" and "unimportant". Heck, it's open source, so if someone feels like it, they can just fork and go hog wild!

by rtpg 9y ago

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.
    - Paianni 9y ago
      Unfortunately those sorts of people tend to be less informed about I.T and that eventually leads to their NetBurst, Pentium M and Atom machines performing even slower than they would be if they were maintained probably. They probably waste more power waiting for the machines to accomplish their tasks in an under-maintained state.
- Annatar 9y ago
  OpenBSD is an ultra-conservative, orthodox project, ...which is exactly the kind of a system one needs for production environments.
- kps 9y ago
  “i386” is OpenBSD's label for the 32-bit Intel architecture (they don't actually support the 80386). Intel still sells these.
  - Paianni 9y ago
    They support 486's though, which is quite rare for 2017.
    - emidln 9y ago
      486s and 586s are still sold for usage as embedded systems. They are well understood and some of them managed to pass certification decades ago.
      - cat199 9y ago
        not to mention, 386 or not, there's still other 'odd' 32bit platforms which still have huge use for embedded things where openbsd would work great (hello mips/arm32, for starters)
      - kps 9y ago
        You can still buy 32-bit Xeons, even. Sometimes srs bsns requires stability, too. https://ark.intel.com/Search/FeatureFilter?productType=processors&FilterCurrentProducts=true&InstructionSet=32-bit&FamilyText=Intel%C2%AE%20Xeon%C2%AE%20Processors https://ark.intel.com/Search/FeatureFilter?productType=proce...
    - JdeBP 9y ago
      There's a 32-bit x86 processor in every PC with the Intel Management Engine version 11 or later.
rtpg 9y ago
So... my main point was that "I have to cross-compile the rust compiler from another arch" is not equivalent to "rustc is not usable in i386". And even if rustc wasn't usable in i386, the binary it produces would be. So you could have a scenario where the i386 binaries would have to be cross compiled from a 64-bit machine but the end result would work just fine on those machines. I wasn't aware that OpenBSD's objectives included having each arch be able to build itself. Totally reasonable goal. It's harder to do "dreamcast port"s in those scenarios, though.
drb91 9y ago
How do you even find an i386 processor these days?
- 2trill2spill 9y ago
  In the OpenBSD world i386 == x86. And it's pretty easy to find an x86 processor now a days.
  - deathanatos 9y ago
    … such as? You're merely restating the claim, without providing any proof. Consumer machines, AFAICT, are all amd64 (or x86_64, if you prefer that name). I understood the original post to mean i386 == x86, and I agree — where do you even find an x86 today (for sale, in a non-niche use case, i.e., "pretty easy")?
    - kelnos 9y ago
      OpenBSD has as a goal to run on much more than just standard currently-sold consumer hardware. You can certainly disagree with that goal, but that doesn't make it go away.
      - drb91 9y ago
        Oh I totally get this—but what is this hardware that people are still using OpenBSD with that they haven't upgraded in 30 years? Targeting i386 as opposed to, say, i486 or i686 seems like an exercise in idealistic masochism.
        kelnos 9y ago
        I think you're misunderstanding: "i386" is just shorthand for "32-bit Intel". They're not specifically talking about the 80386 chip. The same problem exists when you consider newer 32-bit chip families in that ISA.
    - zaarn 9y ago

dmm 9y ago

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 for a while and would kernel panic when you tried to play audio. The netbsd dreamcast port is not functional in the sense that openbsd would like to enforce, something which is not relevant to netbsd and in no way denigrates them, but merely serves as an example.

rtpg 9y ago
Thanks for the context, that wasn't clear to me.

phkahler 9y ago

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 not run the tools right on the target? If your controller is an RPi why not use it for development?

norswap 9y ago
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/Intel_80386
- monochromatic 9y ago
  https://en.wikipedia.org/wiki/IA-32 https://en.wikipedia.org/wiki/IA-32 It includes 486, Pentium, etc.
- imtringued 9y ago
  From the article you linked: > the 80386 instruction set, programming model, and binary encodings are still the common denominator for all 32-bit x86 processors, which is termed the i386-architecture, x86, or IA-32, depending on context.

empath75 9y ago

It’s not a trite point for BSD but if those are the kinds of objections holding back adoption by Linux and bsd, then I think the end result will just be a new Rust-first operating system.

npsimons 9y ago
> It’s not a trite point for BSD but if those are the kinds of objections holding back adoption by Linux and bsd, then I think the end result will just be a new Rust-first operating system. That would be great! Get back to me when it exists, instead of trying to dissuade an already established project from one of it's primary goals and handwaving said goals as "outdated" and "unimportant". Heck, it's open source, so if someone feels like it, they can just fork and go hog wild!