5 ms·

Demoting i686-PC-windows-gnu to Tier 2

69 points by ingve 1y ago

kstrauser 1y ago
That seems reasonable. If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it. They’re just not going to slow down development for the platforms most people use to accommodate it anymore. For context, that platform had 76K downloads. x86_64-unknown-linux-gnu had 135M, or about 1800x more.
- DaiPlusPlus 1y ago
  > If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it There are other use-cases, though not exactly popular or mainstream, but supposing you need dozens, hundreds, maybe even over a thousand currently-supported Windows VMs running off a single VM host box: you'll achieve a higher VM density with an x86 build of an OS compared to the x64 build; right now the only option is some cut-down custom build of Windows 10 Embedded x86[1] ...though I'm sure no-one outside of a DEFCON or CCC meetup's drinking-game will ever find themselves doing this - just so long as I get to see it in a youtube video. [1] EDIT: Turns out they renamed the (non-CE) NT-based Windows Embedded to "Windows IoT" - which annoys me because it's perfectly allowed to make a Windows IoT build without any networking features enabled - so it'd be like calling Apple's iPod Touch as Apple's "iPod iPhone". ---- I'll admit I'm surprised that "x32" (i.e. AMD64 ISA, but with 32-bit pointers) was never supported on Windows, nor exactly popular on Linux, because (at least before Electon Apps existed) plenty of software really has no business using 64-bit pointers, so it makes sense to keep 32-bit pointers; another benefit-of-sorts is that if your program has a memory-leak then it'll crash once the leak hits 4GB - but with 64-bit pointers your process might end-up gobbling hundreds of gigs of RAM before the next malloc call fails. While we're at it, let's also bring back Intel's 21-bit NEAR/FAR pointers ("segmented memory") if only to keep Rust programmers (and their compiler team) on their toes.
  - alerighi 1y ago
    True, but, the advantage of using 32 bit pointers to save a couple of RAM is not that important, since applications typically don't use that much pointers, thus if you half the size of them you will save probably a couple of kb of RAM. Maintaining the support for a different architecture only for that doesn't make a lot of sense, probably the reason it was never supported. RAM is cheap these days so...
    - weinzierl 1y ago
      "probably a couple of kb" Pointers are everywhere. In real world applications we see an increase between a quarter to a third. For example in 2016 Mozilla reported 25% increase from 32-bit Firefox to 64-bit [1]. Google deemed it necessary to implement pointer compression in Chrome to counter the effect. Java also has pointer compression. [1] https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-bit-for-windows-can-take-advantage-of-more-memory/ https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-b...
      - alfiedotwtf 1y ago
        It’s not just a problem for size, don’t forget you also have to copy bits across busses and several layers of cache - and doing so is not instant! And that’s just thinking in terms of logical RAM. You then have translation tables which pointers need to index into - having them larger makes indexing even more slower, compounding the issue
    - karmakaze 1y ago
      It can be important, but also there are ways of using compressed pointers on 64-bit systems for similar savings. Search/prompt "What modern systems or programming/runtime environments use compressed pointers of some form?" for details.
  - kstrauser 1y ago
    So, the Rust team didn’t say they wouldn’t support it, but more that they couldn’t. They’re don’t have in-house experts today who are experienced enough with that platform to support it efficiently. I’d say that a person or company who needs to run thousands of VMs on a single machine would be exactly the right one to step up and adopt it as a maintainer.
- SoftTalker 1y ago
  Building on a variety of architectures often shakes out bugs that might not be evident otherwise. Seems they are deciding those will just be ignored, rather than addressed. Security researchers might focus on these for potential exploits.
  - comex 1y ago
    i686-pc-windows-msvc and i686-unknown-linux-gnu are still tier 1. Any bugs that show up in i686-pc-windows-gnu but neither of the other two are almost certainly MinGW-specific jank, rather than anything that could have security implications on other platforms.
flohofwoe 1y ago
This reads like it only affects the 32-bit target (which tbh is surprising to see supported at all, since afaik there are no more supported 32-bit Windows versions?)
- wtallis 1y ago
  Yes, only the 32-bit target, and only the gnu toolchain. Compiling on Windows using the Microsoft toolchain to target 32-bit Windows will still be on the Tier 1 list: https://doc.rust-lang.org/rustc/platform-support.html https://doc.rust-lang.org/rustc/platform-support.html Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.
  - hulitu 1y ago
    > Windows on ARM hasn't made it up to Tier 1 yet. Windows on ARM is irelevant. Surface is Microsoft's offering to keep execs away from Apple. And just like Apple, they are toys. All relevant Windows software is x86(-64).
    - malkia 1y ago
      Not true. Key point: "Cloud savings"
  - ChrisSD 1y ago
    To be clear, tier 2 targets are still expected to be well supported. It just doesn't require CI to pass after every PR (meaning PRs aren't blocked on fixing tier 2 specific issues). However, the target is officially distributed and target maintainers are still expected to fix any blocking issues before a release. If they can't then it's likely the target will be demoted to tier 3. Windows on ARM couldn't be tier 1 until recently as there weren't Windows ARM github runners. Now that there are I think it likely that it'll be promoted to tier 1.
    - wging 1y ago
      Does that end up meaning, in practice, that stable releases are never broken, but nightly might be, for a tier 2 target?
jmclnx 1y ago
Edit: Seems the article is only for Microsoft Windows, so what follows may be a waste of bandwidth :) Well I guess this will cause OpenBSD to drop more packages that depend upon rust for i386: https://marc.info/?l=openbsd-misc&m=174696055709421&w=2 https://marc.info/?l=openbsd-misc&m=174696055709421&w=2 FWIW, OpenBSD i386 seems to be on its way to tier 2 anyway: https://www.openbsd.org/i386.html https://www.openbsd.org/i386.html I wonder if this could cause NetBSD to start dropping packages that need rust on some ports. Right now, due to NetBSD's assume Cross-Compiling, I do not think rust is an issue for NetBSD (yet).
mmastrac 1y ago
This makes a lot of sense. Obscure Windows bugs make for unhappy developers. Unless you have a local windows setup, the platform is challenging to debug. I spent too much time while working at Deno on this sort of thing.
- layer8 1y ago
  They are only demoting one of two Windows targets. This isn’t about Windows, it’s about there being no maintainer for one of the two toolchains. Unfortunately, it’s the open-source toolchain that is being demoted.
  - josephcsible 1y ago
    It's not just one of two. There used to be four Tier 1 Windows targets, and there are still three: i686-pc-windows-msvc, x86_64-pc-windows-gnu, and x86_64-pc-windows-msvc.
dblohm7 1y ago
> If you rely on the *-windows-gnu targets and have expertise in this area, we would be very happy to have you as a target maintainer. Damn, I'd love to take that on, if only I had the time...
malkia 1y ago
There is `clang-cl` and `lld` that can link windows executables cross platform, targeting "MSVC" without Wine hacks.
- ftco 1y ago
  The bigger problem is legal concerns. Shipping MSVC headers might violate MS EULA.

69 points by ingve 1y ago

That seems reasonable. If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it. They’re just not going to slow down development for the platforms most people use to accommodate it anymore. For context, that platform had 76K downloads. x86_64-unknown-linux-gnu had 135M, or about 1800x more.

DaiPlusPlus 1y ago
> If you want to keep building software on by now ancient hardware, they’ll still give you the tools to do it There are other use-cases, though not exactly popular or mainstream, but supposing you need dozens, hundreds, maybe even over a thousand currently-supported Windows VMs running off a single VM host box: you'll achieve a higher VM density with an x86 build of an OS compared to the x64 build; right now the only option is some cut-down custom build of Windows 10 Embedded x86[1] ...though I'm sure no-one outside of a DEFCON or CCC meetup's drinking-game will ever find themselves doing this - just so long as I get to see it in a youtube video. [1] EDIT: Turns out they renamed the (non-CE) NT-based Windows Embedded to "Windows IoT" - which annoys me because it's perfectly allowed to make a Windows IoT build without any networking features enabled - so it'd be like calling Apple's iPod Touch as Apple's "iPod iPhone". ---- I'll admit I'm surprised that "x32" (i.e. AMD64 ISA, but with 32-bit pointers) was never supported on Windows, nor exactly popular on Linux, because (at least before Electon Apps existed) plenty of software really has no business using 64-bit pointers, so it makes sense to keep 32-bit pointers; another benefit-of-sorts is that if your program has a memory-leak then it'll crash once the leak hits 4GB - but with 64-bit pointers your process might end-up gobbling hundreds of gigs of RAM before the next malloc call fails. While we're at it, let's also bring back Intel's 21-bit NEAR/FAR pointers ("segmented memory") if only to keep Rust programmers (and their compiler team) on their toes.
- alerighi 1y ago
  True, but, the advantage of using 32 bit pointers to save a couple of RAM is not that important, since applications typically don't use that much pointers, thus if you half the size of them you will save probably a couple of kb of RAM. Maintaining the support for a different architecture only for that doesn't make a lot of sense, probably the reason it was never supported. RAM is cheap these days so...
  - weinzierl 1y ago
    "probably a couple of kb" Pointers are everywhere. In real world applications we see an increase between a quarter to a third. For example in 2016 Mozilla reported 25% increase from 32-bit Firefox to 64-bit [1]. Google deemed it necessary to implement pointer compression in Chrome to counter the effect. Java also has pointer compression. [1] https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-bit-for-windows-can-take-advantage-of-more-memory/ https://blog.mozilla.org/nnethercote/2016/07/22/firefox-64-b...
    - alfiedotwtf 1y ago
      It’s not just a problem for size, don’t forget you also have to copy bits across busses and several layers of cache - and doing so is not instant! And that’s just thinking in terms of logical RAM. You then have translation tables which pointers need to index into - having them larger makes indexing even more slower, compounding the issue
  - karmakaze 1y ago
    It can be important, but also there are ways of using compressed pointers on 64-bit systems for similar savings. Search/prompt "What modern systems or programming/runtime environments use compressed pointers of some form?" for details.
- kstrauser 1y ago
  So, the Rust team didn’t say they wouldn’t support it, but more that they couldn’t. They’re don’t have in-house experts today who are experienced enough with that platform to support it efficiently. I’d say that a person or company who needs to run thousands of VMs on a single machine would be exactly the right one to step up and adopt it as a maintainer.
SoftTalker 1y ago
Building on a variety of architectures often shakes out bugs that might not be evident otherwise. Seems they are deciding those will just be ignored, rather than addressed. Security researchers might focus on these for potential exploits.
- comex 1y ago
  i686-pc-windows-msvc and i686-unknown-linux-gnu are still tier 1. Any bugs that show up in i686-pc-windows-gnu but neither of the other two are almost certainly MinGW-specific jank, rather than anything that could have security implications on other platforms.

flohofwoe 1y ago

This reads like it only affects the 32-bit target (which tbh is surprising to see supported at all, since afaik there are no more supported 32-bit Windows versions?)

wtallis 1y ago
Yes, only the 32-bit target, and only the gnu toolchain. Compiling on Windows using the Microsoft toolchain to target 32-bit Windows will still be on the Tier 1 list: https://doc.rust-lang.org/rustc/platform-support.html https://doc.rust-lang.org/rustc/platform-support.html Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.
- hulitu 1y ago
  > Windows on ARM hasn't made it up to Tier 1 yet. Windows on ARM is irelevant. Surface is Microsoft's offering to keep execs away from Apple. And just like Apple, they are toys. All relevant Windows software is x86(-64).
  - malkia 1y ago
    Not true. Key point: "Cloud savings"
- ChrisSD 1y ago
  To be clear, tier 2 targets are still expected to be well supported. It just doesn't require CI to pass after every PR (meaning PRs aren't blocked on fixing tier 2 specific issues). However, the target is officially distributed and target maintainers are still expected to fix any blocking issues before a release. If they can't then it's likely the target will be demoted to tier 3. Windows on ARM couldn't be tier 1 until recently as there weren't Windows ARM github runners. Now that there are I think it likely that it'll be promoted to tier 1.
  - wging 1y ago
    Does that end up meaning, in practice, that stable releases are never broken, but nightly might be, for a tier 2 target?

jmclnx 1y ago

Edit: Seems the article is only for Microsoft Windows, so what follows may be a waste of bandwidth :) Well I guess this will cause OpenBSD to drop more packages that depend upon rust for i386: https://marc.info/?l=openbsd-misc&m=174696055709421&w=2 https://marc.info/?l=openbsd-misc&m=174696055709421&w=2 FWIW, OpenBSD i386 seems to be on its way to tier 2 anyway: https://www.openbsd.org/i386.html https://www.openbsd.org/i386.html I wonder if this could cause NetBSD to start dropping packages that need rust on some ports. Right now, due to NetBSD's assume Cross-Compiling, I do not think rust is an issue for NetBSD (yet).

mmastrac 1y ago

This makes a lot of sense. Obscure Windows bugs make for unhappy developers. Unless you have a local windows setup, the platform is challenging to debug. I spent too much time while working at Deno on this sort of thing.

layer8 1y ago
They are only demoting one of two Windows targets. This isn’t about Windows, it’s about there being no maintainer for one of the two toolchains. Unfortunately, it’s the open-source toolchain that is being demoted.
- josephcsible 1y ago
  It's not just one of two. There used to be four Tier 1 Windows targets, and there are still three: i686-pc-windows-msvc, x86_64-pc-windows-gnu, and x86_64-pc-windows-msvc.

dblohm7 1y ago

> If you rely on the *-windows-gnu targets and have expertise in this area, we would be very happy to have you as a target maintainer. Damn, I'd love to take that on, if only I had the time...

malkia 1y ago

There is `clang-cl` and `lld` that can link windows executables cross platform, targeting "MSVC" without Wine hacks.

ftco 1y ago
The bigger problem is legal concerns. Shipping MSVC headers might violate MS EULA.