11–20 of 184 posts
So, while I don't really have a problem with removing SPARC support from Illumos which I wouldn't be using on SPARC systems anyway, the reasons mentioned in the document aren't convincing me at all.
FWIW, we still support sparc64 in Debian Ports:
This is really sad. The world is heading to a duopoly x86 - arm. Alpha is dead, Mips is almost dead, PA-RISC is dead, POWER is too expensive and RISC-V is mostly nice to have.
It's mildly interesting to me that there's now really no notable big-endian systems left, yet that's still the network byte order. I wonder what the math is for the amount of global wasted CPU cycles on byte-swapping for things that would do a fair amount of that...DNS for example.
That's not correct. s390x is big-endian and well supported in all enterprise distributions such as SLE, RHEL as well as Debian and Ubuntu.
A fun way to make Oracle donate a machine would be to make an official POWER port. That's a lot of work and I don't see IBM making a machine available.
We tried to convince Oracle to donate a SPARC machine for Debian but that unfortunately never happened for various reasons.
This is really sad. The world is heading to a duopoly x86 - arm. Alpha is dead, Mips is almost dead, PA-RISC is dead, POWER is too expensive and RISC-V is mostly nice to have.
It's mildly interesting to me that there's now really no notable big-endian systems left, yet that's still the network byte order. I wonder what the math is for the amount of global wasted CPU cycles on byte-swapping for things that would do a fair amount of that...DNS for example.
Serialization formats like JSON/YAML/protobuf/etc. would be much more costly by comparison.
This is really sad. The world is heading to a duopoly x86 - arm. Alpha is dead, Mips is almost dead, PA-RISC is dead, POWER is too expensive and RISC-V is mostly nice to have.
A lot of these architecture have some drawbacks in modern times. Alpha’s loosey-goosey memory model makes multithreaded code on SMP systems more challenging. Linux utilizes its Alpha port as a worst-case testbed for data race conditions in its kernel. SPARC’s register windows are anachronistic and complicate the implementation of CPUs, and I’d guess also make it more difficult to build OoOE cores (so many SPARC chips…
If you look at ARM, particularly the 64-bit version, you'll notice it attempts to squeeze multiple operations into a single 32-bit "instruction". It's still called RISC, but not really "reduced" anymore.
A fun way to make Oracle donate a machine would be to make an official POWER port. That's a lot of work and I don't see IBM making a machine available.
More on topic, as someone sentimental for SPARC hardware and to an extent solaris, this is sad to see, but it feels like just a formality. I don't think illumos has worked properly on SPARC hardware since ... Ever? There were a few illumos distributions with SPARC builds but I always had trouble getting them to run on even a T2, seems there was little work done post rebranding from OpenSolaris for SPARC. Linux and OpenBSD have been much, much better on SPARC than Illumos, tinged with bitter irony...
Why don't they just upgrade GCC to a more recent version. GCC still actively supports SPARC to this date and Rust support is also present and while not perfect, it definitely works. So, while I don't really have a problem with removing SPARC support from Illumos which I wouldn't be using on SPARC systems anyway, the reasons mentioned in the document aren't convincing me at all. FWIW, we still support sparc64 in Debia…
This is really sad. The world is heading to a duopoly x86 - arm. Alpha is dead, Mips is almost dead, PA-RISC is dead, POWER is too expensive and RISC-V is mostly nice to have.
x86: 8086 1978 x64: 1999 ARM: 1985 ARM64: 2011 RISC V: 2010 It took x86 about 10 years (1988) to become the most popular, and until 2005 to cause Apple to switch (another 17 years) It took ARM about 25 years (2010) to become the most popular, and until 2020 to cause Apple to switch (another 10 years)