Illumos to drop SPARC Support • Hacker News Board

Re: Illumos to drop SPARC Support

#31

Post by monocasa » Fri, May 07, 2021, 2:22 PM UTC

tyingq wrote: post #5

hulitu wrote: post #3

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.

I know of at least one micro arch that'll fuse load and byte swap instructions into a reverse endian load. There's still probably a detectable overhead, but it's not the end of the world to hack on later.

Re: Illumos to drop SPARC Support

#32

Post by wicket » Fri, May 07, 2021, 2:23 PM UTC

With Linux having caught up with key Solaris features in recent years (DTrace -> eBPF, Zones -> Namespaces, ZFS -> ZFS on Linux), I always thought that the main reason to use Illumos would be first-class SPARC support. With that now dropped, I'm concerned that Illumos soon become irrelevant. Are there any compelling reasons left to use Illumos, other than being something for those who just want a free Solaris alternative?

Re: Illumos to drop SPARC Support

#33

Post by spijdar » Fri, May 07, 2021, 2:23 PM UTC

sgift wrote: post #19

cbmuser wrote: post #11

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…

How would upgrading GCC help with the problem that they don't have SPARC machines available for building Illumos?

It wouldn't, but they state that one of the benefits of dropping SPARC is being able to "[retire] the now-ancient GCC 4.4.4 shadow compiler that remains chiefly to support the SPARC platform"

I'm guessing the problem isn't that newer GCC lacks SPARC support, but that their (now very old and bitrotted) SPARC support relies on some kind of undefined behavior or nuance of GCC 4 that prevents newer versions from building the kernel.

Re: Illumos to drop SPARC Support

#34

Post by corty » Fri, May 07, 2021, 2:27 PM UTC

qwerty456127 wrote: post #21

Sound crazy. Like if Windows had dropped x86.

Yes, but Sparc was on life-support as soon as Oracle bought Sun, and dead soon after. Sparc was already hideously expensive and slow compared to x86 during the Sun days. There innovation in Sparc came to a halt soon after T1, which also dropped most of the really nice features like CPU and RAM hotswapping. So you just got something expensive, slow and incompatible for five to six times the price. Oracle then proceeded to cut research further, cut rebates, cut off customers from support trying to renegotiate higher rates. Which sent everyone running to x86 if they weren't already.

Solaris on Sparc was great until ca. 2006. After that it started dying.

Re: Illumos to drop SPARC Support

#35

Post by classichasclass » Fri, May 07, 2021, 2:28 PM UTC

tyingq wrote: post #5

hulitu wrote: post #3

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.

Power ISA systems are still bi-endian and many systems run big. In fact, the low level OPAL interfaces require you to be in big-endian mode, AIX and i are still BE, and both FreeBSD and OpenBSD have BE flavours for current PowerNV systems. Even a few Linux distros run big (Adelie comes to mind). They're definitely a minority but they're still around.

Re: Illumos to drop SPARC Support

#36

Post by klelatti » Fri, May 07, 2021, 2:28 PM UTC

mavhc wrote: post #26

alanfranz wrote: post #20

Earlier quoted context omitted.

“Switch” to what? Apple is one of the founders of ARM and still holds ARM shares IIRC

They sold their 40% stake in ARM when they were short of cash. Switch from Power PC to Intel, and then from Intel to ARM. I'm using Apple as a tipping point, to when the new architecture was so much better than the old it completely took over. Obviously with 90% of Apple devices being ARM already it was an easier choice for them this time. But as each Architecture gets more power as the market is many times bigger, i…

On the Apple specific case I think any move to RISC V would be because it would want more control than it has with Arm. It could then take the RISC V ISA in the direction it wants.

I'm guessing it already has a lot of influence over Arm though and there are other factors that strongly act in favour of staying with Arm.

If Nvidia takes over Arm though and starts making life difficult for the ecosystem then that could change ....

Re: Illumos to drop SPARC Support

#37

Post by Ericson2314 » Fri, May 07, 2021, 2:29 PM UTC

> Without ready access to build machines, one might consider cross compilation. Though we have some support for cross-architecture software generation in the tools, the operating system does not currently support being cross compiled in full.

SPARC or not SPARC, I would love to help with that!

Re: Illumos to drop SPARC Support

#38

Post by bombcar » Fri, May 07, 2021, 2:30 PM UTC

tyingq wrote: post #5

hulitu wrote: post #3

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.

There are various open-source and white-box network switches and routers - do any of them run big-endian? If not, it must be a solved problem (perhaps by fast-path dedicated ASICs).

Re: Illumos to drop SPARC Support

#39

Post by mastax » Fri, May 07, 2021, 2:32 PM UTC

macksd wrote: post #29

cbmuser wrote: post #12

Earlier quoted context omitted.

> It's mildly interesting to me that there's now really no notable big-endian systems left 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.

Though as we recently learned, it's considered sufficiently "fringe" by a big chunk of the development community that it's not that big a deal to drop support for it. (Not to imply IBM couldn't be sponsoring development for it more).

If you're talking about the python cryptography fiasco that was dropping support for S390 (31-bit architecture discontinued in 1999). S390X (64-bit architecture introduced in 2000) is supported by Rust, though not necessarily by Python Cryptography.

Incidentally Rust's continued support for S390X is driven primarily by cuviper who works for Red Hat (even before the IBM acquisition).

Re: Illumos to drop SPARC Support

#40

Post by 4ad » Fri, May 07, 2021, 2:32 PM UTC

rbanffy wrote: post #2

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.

Convince Oracle to donate a machine... for an Oracle Solaris competitor?! Oracle was the one that shut down OpenSolaris in the first place!