5 ms·

Potentially capable; their support for non-x86 has always fallen short. If you look at e.g. Linux or BSD distributions, the entire world is rebuilt for every a

by rleigh 10y ago

Potentially capable; their support for non-x86 has always fallen short. If you look at e.g. Linux or BSD distributions, the entire world is rebuilt for every architecture. Running Linux on powerpc, arm, amd64, I get the exact same experience across the board as x86 bar platform-specific bits like openfirmware/efi tools. Microsoft has never done this. The vast majority of their stuff remains x86 only, making arm and even x64 second class citizens, with x64 only being viable as a result of the x86 compatibility. Until Microsoft start building and providing every binary as a native build, and providing the tooling for others to do the same, they will remain wedded to x86, and I'll be unable to take their support for other platforms seriously. If a bunch of volunteers can manage to provide over 20000 software packages for over 10 architectures, totalling over 500000 binary packages, it's entirely possible for Microsoft to support three. When I used to maintain the Debian build tools, it took 18 hours to rebuild around all 18000 packages; compilers, kernel, tools, applications, everything. It would be much faster on a current system. It's all possible from a technical point of view.

justin66 10y ago
> Running Linux on powerpc, arm, amd64, I get the exact same experience across the board as x86 bar platform-specific bits like openfirmware/efi tools. This is demonstrably not true, there are plenty of ports that end up being Intel-only, and plenty of architectures that involve some sacrifice in terms of software choice if you want to run them. (as a SPARC and Raspberry Pi user I could elaborate, but hopefully you get the idea) Not that there's anything wrong with that. > Until Microsoft start building and providing every binary as a native build, and providing the tooling for others to do the same, they will remain wedded to x86, and I'll be unable to take their support for other platforms seriously. What you take seriously is your business, but the standard you're holding Microsoft to is one Linux doesn't meet, let alone BSD, and it's completely arbitrary regardless. If their ARM platform does what it needs to do, it doesn't especially matter if it offers support for (for example) legacy Windows cruft.
- trome 10y ago
  > There are plenty of ports that end up being Intel-only .. as a SPARC and Raspberry Pi user Sure, but you can compile failed builds of software yourself and get that tool on ARM or SPARC. ARM works pretty well on Debian, so long as your not on Raspbian & using their ancient repos with broken software. Part of why I've avoided Raspberry Pis entirely.
  - justin66 10y ago
    A good point, but their repos are so eccentric because Debian refused to support the RPi's older ARM architecture and the RPi community had to roll their own. That speaks to the original point of this subthread, I believe. Not only does Linux not offer the "exact same experience across the board," it cannot even do it for the ARM architecture. For decent enough reasons, really, when you think about it.
    - trome 10y ago
      Only a select few boards were based on ARMv6, the Raspi 2 and above use a modern ARMv7 core. Running Raspbian vs Debian on a Raspi 2 or 3 shows off the massive performance gap between the two, IMO they should have used a single ARMv7 core from the get go. But the Raspberry Pi is a fundamentally flawed platform, with poor I/O, binary blobs required to make the hardware function, and a community that is toxic towards free software, with its own vaguely supported distro. An OrangePi Zero ($7) or OrangePi PC Plus ($22) will blow a Raspi out of the water any day, due to each USB port and the ethernet port being directly wired into the SOC, allowing 40MB/s per port. Plus, I can run kernel 4.10 and mainline Debian on it without any blobs, and the only things I'll miss out on are GPU support & WiFi. The VPU has been reverse engineered though, so H.264 & H.265 video works well.
      - pjc50 10y ago
        > community that is toxic towards free software I think that's a hostile mischaracterisation of the community!
    - AlphaSite 10y ago
RandomOpinion 10y ago
> Potentially capable; their support for non-x86 has always fallen short. "Microsoft will continue to provide mainstream support for Itanium-based systems until July 2013, and extended support until July 2018." -- http://www.computerworld.com/article/2516742/computer-hardware/microsoft-ending-support-for-itanium.html http://www.computerworld.com/article/2516742/computer-hardwa... Itanium came out in 2001 and the above article is from 2010, so that would be about 9 years of product releases and 17 years of support overall. And, frankly, there's no money to be made off of supporting all those miscellaneous architectures so Microsoft has no reason to bother.
- rleigh 10y ago
  I'm not referring to that type of support; this is merely support for the base platform. I'm referring to the entire ecosystem of Microsoft products, of which you'll find most are x86 only. When you say "there's no money to be made...so Micosoft has no reason to bother", this attitude is a major reason why ia64 failed, and why their previous arm attempt failed, and why their current arm attempt is also likely to fail. If the software isn't there, it's a poor proposition for most customers. When I run Linux on ia64 or arm, I have an entire distribution's worth of software at my fingertips, and for the most part I'm not losing out compared with more popular architectures. With Windows, no matter how technically good the base platform may be, the ecosystem is a wasteland and will remain so until Microsoft put the effort in to support them properly. Supporting multiple platforms is not expensive; it's simply a matter of having the build infrastructure in place. In Debian we had it build every package automatically built on 11 platforms. Microsoft could do the same for their applications. For example, see https://buildd.debian.org/status/package.php?p=okular&suite=sid https://buildd.debian.org/status/package.php?p=okular&suite=... -- one package built for 22 platforms. Building for three or four is not a lot to ask...
  - RandomOpinion 10y ago
    > I'm not referring to that type of support; this is merely support for the base platform. I'm referring to the entire ecosystem of Microsoft products, of which you'll find most are x86 only. Windows Server comes with IIS and other services that would normally have been provided in a Linux environment by the Linux ecosystem. Also, as the article notes, SQL Server and Visual Studio were supported on Itanium as well. As Itanium only succeeded as a server product, there's no business reason for Microsoft to have ported their desktop applications to it.
andreiw 10y ago
Not true. When multiarch mattered (NT 3 and 4), Microsoft was the only vendor that delivered the exact same OS, device support and development environment across x86, Alpha, MIPS and PowerPC, and pushed the industry towards standardization. Microsoft has always taken arch and platform independence seriously, and this was evident even in 2010 when I worked on NT. You could rebuild the whole system for any supported arch (x86, x64, ia64 when that mattered), now arm and arm64 It's funny, but Microsoft was spot on correct to continue supporting 32-bit x86 on par with x64. Now they can just support BTing 32 x86 on ARM64 instead of being forced to support 64-on-64, which would simply involve more overhead.
- milcron 10y ago
  BTing?
  - kijiki 10y ago
    Binary Translating. Basically a JIT that recompiles (for example) 32bit x86 instructions to ARM64, so that you can run old apps on new CPUs. DEC had FX!32 to run x86 Windows NT programs on Alpha Windows NT. Apple licensed Transitive's QuickTransit to run PPC OSX apps on x86 Macs, though in typical Apple style they renamed it "Rosetta".
    - trapperkeeper79 10y ago
      Is this the same as code morphing mentioned here? https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver Article seems to say NVidia couldn't get a license from Intel.
    - foobiekr 10y ago
      I worked with those guys on a project - also PPC to x86. It was pretty amazing and they were solid. Sad that so much of it ended up at IBM. Apple's marketing around it was amazing; you'd think Apple built the technology in house.
  - andreiw 10y ago
foobiekr 10y ago
As long as the non-x86 architecture is both 64 bit and little endian, I think this is true. However, in the absence of those two properties not at all. There are many mainstream linux code bases which are either inconsistently endian-clean (meaning they are for some operations but not all) or are straight up broken. This becomes really visible debugging bizarre, impossible bugs on BE architectures.

by rleigh 10y ago

justin66 10y ago

> Running Linux on powerpc, arm, amd64, I get the exact same experience across the board as x86 bar platform-specific bits like openfirmware/efi tools. This is demonstrably not true, there are plenty of ports that end up being Intel-only, and plenty of architectures that involve some sacrifice in terms of software choice if you want to run them. (as a SPARC and Raspberry Pi user I could elaborate, but hopefully you get the idea) Not that there's anything wrong with that. > Until Microsoft start building and providing every binary as a native build, and providing the tooling for others to do the same, they will remain wedded to x86, and I'll be unable to take their support for other platforms seriously. What you take seriously is your business, but the standard you're holding Microsoft to is one Linux doesn't meet, let alone BSD, and it's completely arbitrary regardless. If their ARM platform does what it needs to do, it doesn't especially matter if it offers support for (for example) legacy Windows cruft.

trome 10y ago
> There are plenty of ports that end up being Intel-only .. as a SPARC and Raspberry Pi user Sure, but you can compile failed builds of software yourself and get that tool on ARM or SPARC. ARM works pretty well on Debian, so long as your not on Raspbian & using their ancient repos with broken software. Part of why I've avoided Raspberry Pis entirely.
- justin66 10y ago
  A good point, but their repos are so eccentric because Debian refused to support the RPi's older ARM architecture and the RPi community had to roll their own. That speaks to the original point of this subthread, I believe. Not only does Linux not offer the "exact same experience across the board," it cannot even do it for the ARM architecture. For decent enough reasons, really, when you think about it.
  - trome 10y ago
    Only a select few boards were based on ARMv6, the Raspi 2 and above use a modern ARMv7 core. Running Raspbian vs Debian on a Raspi 2 or 3 shows off the massive performance gap between the two, IMO they should have used a single ARMv7 core from the get go. But the Raspberry Pi is a fundamentally flawed platform, with poor I/O, binary blobs required to make the hardware function, and a community that is toxic towards free software, with its own vaguely supported distro. An OrangePi Zero ($7) or OrangePi PC Plus ($22) will blow a Raspi out of the water any day, due to each USB port and the ethernet port being directly wired into the SOC, allowing 40MB/s per port. Plus, I can run kernel 4.10 and mainline Debian on it without any blobs, and the only things I'll miss out on are GPU support & WiFi. The VPU has been reverse engineered though, so H.264 & H.265 video works well.
    - pjc50 10y ago
      > community that is toxic towards free software I think that's a hostile mischaracterisation of the community!
  - AlphaSite 10y ago

RandomOpinion 10y ago

> Potentially capable; their support for non-x86 has always fallen short. "Microsoft will continue to provide mainstream support for Itanium-based systems until July 2013, and extended support until July 2018." -- http://www.computerworld.com/article/2516742/computer-hardware/microsoft-ending-support-for-itanium.html http://www.computerworld.com/article/2516742/computer-hardwa... Itanium came out in 2001 and the above article is from 2010, so that would be about 9 years of product releases and 17 years of support overall. And, frankly, there's no money to be made off of supporting all those miscellaneous architectures so Microsoft has no reason to bother.

rleigh 10y ago
I'm not referring to that type of support; this is merely support for the base platform. I'm referring to the entire ecosystem of Microsoft products, of which you'll find most are x86 only. When you say "there's no money to be made...so Micosoft has no reason to bother", this attitude is a major reason why ia64 failed, and why their previous arm attempt failed, and why their current arm attempt is also likely to fail. If the software isn't there, it's a poor proposition for most customers. When I run Linux on ia64 or arm, I have an entire distribution's worth of software at my fingertips, and for the most part I'm not losing out compared with more popular architectures. With Windows, no matter how technically good the base platform may be, the ecosystem is a wasteland and will remain so until Microsoft put the effort in to support them properly. Supporting multiple platforms is not expensive; it's simply a matter of having the build infrastructure in place. In Debian we had it build every package automatically built on 11 platforms. Microsoft could do the same for their applications. For example, see https://buildd.debian.org/status/package.php?p=okular&suite=sid https://buildd.debian.org/status/package.php?p=okular&suite=... -- one package built for 22 platforms. Building for three or four is not a lot to ask...
- RandomOpinion 10y ago
  > I'm not referring to that type of support; this is merely support for the base platform. I'm referring to the entire ecosystem of Microsoft products, of which you'll find most are x86 only. Windows Server comes with IIS and other services that would normally have been provided in a Linux environment by the Linux ecosystem. Also, as the article notes, SQL Server and Visual Studio were supported on Itanium as well. As Itanium only succeeded as a server product, there's no business reason for Microsoft to have ported their desktop applications to it.

andreiw 10y ago

Not true. When multiarch mattered (NT 3 and 4), Microsoft was the only vendor that delivered the exact same OS, device support and development environment across x86, Alpha, MIPS and PowerPC, and pushed the industry towards standardization. Microsoft has always taken arch and platform independence seriously, and this was evident even in 2010 when I worked on NT. You could rebuild the whole system for any supported arch (x86, x64, ia64 when that mattered), now arm and arm64 It's funny, but Microsoft was spot on correct to continue supporting 32-bit x86 on par with x64. Now they can just support BTing 32 x86 on ARM64 instead of being forced to support 64-on-64, which would simply involve more overhead.

milcron 10y ago
BTing?
- kijiki 10y ago
  Binary Translating. Basically a JIT that recompiles (for example) 32bit x86 instructions to ARM64, so that you can run old apps on new CPUs. DEC had FX!32 to run x86 Windows NT programs on Alpha Windows NT. Apple licensed Transitive's QuickTransit to run PPC OSX apps on x86 Macs, though in typical Apple style they renamed it "Rosetta".
  - trapperkeeper79 10y ago
    Is this the same as code morphing mentioned here? https://en.wikipedia.org/wiki/Project_Denver https://en.wikipedia.org/wiki/Project_Denver Article seems to say NVidia couldn't get a license from Intel.
  - foobiekr 10y ago
    I worked with those guys on a project - also PPC to x86. It was pretty amazing and they were solid. Sad that so much of it ended up at IBM. Apple's marketing around it was amazing; you'd think Apple built the technology in house.
- andreiw 10y ago

foobiekr 10y ago

As long as the non-x86 architecture is both 64 bit and little endian, I think this is true. However, in the absence of those two properties not at all. There are many mainstream linux code bases which are either inconsistently endian-clean (meaning they are for some operations but not all) or are straight up broken. This becomes really visible debugging bizarre, impossible bugs on BE architectures.