I have a uniquely soft spot for SPARC, having written and disassembled a bunch of SPARC early in my career. If this is its swan song, I'll take the moment to share some code the takes advantage of the odd (today) delay slot architecture to implement instruction picking:
The trick uses a branch in the delay slot of a jmp--a decidedly unusual construction. At the time I found this to be extremely clever and elegant... but apparently not so clever as to warrant a comment.
Can you explain how that works or what it does? I understand delay slots, but I didn't know it was legal to have a branch in a delay slot, so I don't really know what this means :)
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?
* Namespaces don't come close to FreeBSD jails or Solaris / Illumos Zones. There is a reason Docker hosters put their Docker tenants in different hardware VM's. Because the isolation is too weak.
* Due to CDDL and GPL problems ZFS on Linux will always be hard to use making every update cycle like playing Russian roulette.
And there are other benefits. Like SMF offers nice service management while not providing half an operating system like systemd.
Solaris SPARC is one of the few OSes in production taming C with hardware memory tagging (ADI).
With Linux that will eventually happen in ARM, but currently only Android is adopting it, who know when it will ever come to upstream enabled by default like on Android.
its been said in the thread already but this was always a non-starter. Torvalds even said so himself. CDDL was the last poison pill of a dying giant who couldnt pull its foot from the well.
What we, er, the linux community, chose instead, was BTRFS. It isnt ZFS, but its made incredible strides. for most use cases, it is a reasonable and working replacement for ZFS.
Not really. SmartOS was nice for a while but tbh you may as well go with openstack or proxmox these days.
I used it for hosting a lot of java over the years but these days everyone wants a k8s endpoint and really the kind of hypervisor you are running doesn’t really make a difference.
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 are in-order, why?)
POWER isn’t so bad though. It’s open enough where you could build your own lower-cost core if you wanted. There’s nothing intrinsic to the ISA that would mandate an expensive chip other than volume constraints.
PA-RISC put up some great numbers back in the day but between the Compaq acquisition (bringing with it Alpha) and Itanium it was chronically under-resourced. They had a great core in the early 90s and basically just incrementally tweaked it until its death.
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.
Yes, but where can I buy a SPARC CPU? How many of those who have/can have it are running Illumos and are putting money/time in it? And more importantly what's the outlook for SPARC?
One thing I've wondered (randomly) and I could be way off the mark here, but does Illumos have any kind of place at Oxide Computer? The author of the link and the CTO of Oxide both have strong links to Illumos in one way or another but on the other hand some of their team are Linux kernel developers, or is the work they are doing not at this level in the stack?
While the primary issue is likely developer time and hardware availability to test on, there are other OSs like OpenBSD which supports much newer SPARC64 hardware: https://www.openbsd.org/sparc64.html
OpenBSD is the only OS ever to run on my Tadpole laptops without any modification necessary. Even Solaris 8 and 10 needed special software to run on them. OpenBSD works right out of the box.
I can’t really tell if they’re just dropping older SPARC systems or the architecture altogther.
OpenBSD will eventually face the same issues with older systems, and I believe they already dropped platforms because hardware couldn’t be replaced.
For newer SPARC system you could “just” buy one. Oracle doesn’t need to donate them, it would be nice if they did, but the community around Illumos, Debian and OpenBSD could raise money to buy theses systems.
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.
Because it's not a stock gcc. It's specially modified to do things quite differently on SPARC. If it was a case of "just" upgrading we would have done it long ago.
As one of approximately 2 people who actually build illumos on SPARC, I can testify that the whole thing is enough of a maintenance burden that it's causing major problems.
(And I'll just fork a copy and use that; it's not as though the SPARC ecosystem is a moving target.)
I hope Debian manages to keep sparc64 in Debian Ports. Just last night, I was fixed an alignment portability issue for e2fsprogs which only showed up on sparc64. The "non-portable" code worked just fine on all of the officially supported Debian architectures, and the only one where one of the alignment problem showed up was sparc64[1]. (Two of the alignment problems did show up when running a 32-bit arm chroot on a 64-bit arm kernel, but one of them, a failure in the regression test j_recovery_fast_commit, only be reproduced on sparc64.)
Sparc64 support is rocky; yes, it has a modern gcc, but stack unwinding in gdb is totally broken. (Not sure if that's a gdb or a gcc problem, but just try building some trivial program where main() calls some trivial function, and then try setting a breakpoint inside that function, and then try getting a stack trace.) This made finding the root cause of the alignment bug-induced crash much harder, but at least sparc64 served as a canary in the coal mine. Supporting niche architectures is great from a software quality perspective.
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.
Much less crazy than when Mac dropped the 68K -- those had been joined at birth and separation was believed impossible by even the best surgeons.
Solaris was portable by design all along, in the later Unix fashion. Sun actually sold their first x86-based system running SunOS all the way back in the 1980s, as a low-end complement to their new high-end SPARC machines: https://en.wikipedia.org/wiki/Sun386i
There are plenty of people who would donate a virtual machine or remote work environment for this sort of thing, if anyone was (seriously) interested in porting. Realistically, I doubt anyone wants to put that kind of effort in. Getting FreeBSD and more recently OpenBSD working on PowerNV platforms has taken a very large effort by the community, and those OSes already had some support for POWER/PowerPC. Illumos only has the x86 and (very bitrotted) SPARC support AFAIK, I believe there have been some attempts at bringing up ARM but don't see anything substantial.
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...
> 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!
ahl|4 years ago
https://github.com/illumos/illumos-gate/blob/master/usr/src/...
The trick uses a branch in the delay slot of a jmp--a decidedly unusual construction. At the time I found this to be extremely clever and elegant... but apparently not so clever as to warrant a comment.
mattst88|4 years ago
wicket|4 years ago
jsiepkes|4 years ago
* Namespaces don't come close to FreeBSD jails or Solaris / Illumos Zones. There is a reason Docker hosters put their Docker tenants in different hardware VM's. Because the isolation is too weak.
* Due to CDDL and GPL problems ZFS on Linux will always be hard to use making every update cycle like playing Russian roulette.
And there are other benefits. Like SMF offers nice service management while not providing half an operating system like systemd.
pjmlp|4 years ago
With Linux that will eventually happen in ARM, but currently only Android is adopting it, who know when it will ever come to upstream enabled by default like on Android.
nimbius|4 years ago
its been said in the thread already but this was always a non-starter. Torvalds even said so himself. CDDL was the last poison pill of a dying giant who couldnt pull its foot from the well.
What we, er, the linux community, chose instead, was BTRFS. It isnt ZFS, but its made incredible strides. for most use cases, it is a reasonable and working replacement for ZFS.
cyberpunk|4 years ago
I used it for hosting a lot of java over the years but these days everyone wants a k8s endpoint and really the kind of hypervisor you are running doesn’t really make a difference.
Shame, it was nice tech.
shrubble|4 years ago
Lxc containers vs Solaris Zones... zones clearly wins.
SMF vs systemd (I know that you didn't include this, but it matters)... SMF is clearly superior as well.
hulitu|4 years ago
spamizbad|4 years ago
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 are in-order, why?)
POWER isn’t so bad though. It’s open enough where you could build your own lower-cost core if you wanted. There’s nothing intrinsic to the ISA that would mandate an expensive chip other than volume constraints.
PA-RISC put up some great numbers back in the day but between the Compaq acquisition (bringing with it Alpha) and Itanium it was chronically under-resourced. They had a great core in the early 90s and basically just incrementally tweaked it until its death.
jhbadger|4 years ago
tyingq|4 years ago
pabs3|4 years ago
https://raptorcs.com/
mavhc|4 years ago
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)
macspoofing|4 years ago
PedroBatista|4 years ago
Tepix|4 years ago
roryrjb|4 years ago
wmf|4 years ago
zdw|4 years ago
cptnapalm|4 years ago
mrweasel|4 years ago
OpenBSD will eventually face the same issues with older systems, and I believe they already dropped platforms because hardware couldn’t be replaced.
For newer SPARC system you could “just” buy one. Oracle doesn’t need to donate them, it would be nice if they did, but the community around Illumos, Debian and OpenBSD could raise money to buy theses systems.
cbmuser|4 years ago
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:
> https://cdimage.debian.org/cdimage/ports/current/
ptribble|4 years ago
As one of approximately 2 people who actually build illumos on SPARC, I can testify that the whole thing is enough of a maintenance burden that it's causing major problems.
(And I'll just fork a copy and use that; it's not as though the SPARC ecosystem is a moving target.)
tytso|4 years ago
Sparc64 support is rocky; yes, it has a modern gcc, but stack unwinding in gdb is totally broken. (Not sure if that's a gdb or a gcc problem, but just try building some trivial program where main() calls some trivial function, and then try setting a breakpoint inside that function, and then try getting a stack trace.) This made finding the root cause of the alignment bug-induced crash much harder, but at least sparc64 served as a canary in the coal mine. Supporting niche architectures is great from a software quality perspective.
[1] https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs&arc...
sgift|4 years ago
qwerty456127|4 years ago
corty|4 years ago
Solaris on Sparc was great until ca. 2006. After that it started dying.
retrac|4 years ago
Solaris was portable by design all along, in the later Unix fashion. Sun actually sold their first x86-based system running SunOS all the way back in the 1980s, as a low-end complement to their new high-end SPARC machines: https://en.wikipedia.org/wiki/Sun386i
rbanffy|4 years ago
That's a lot of work and I don't see IBM making a machine available.
spijdar|4 years ago
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...
cbmuser|4 years ago
We tried to convince Oracle to donate a SPARC machine for Debian but that unfortunately never happened for various reasons.
4ad|4 years ago
Ericson2314|4 years ago
SPARC or not SPARC, I would love to help with that!
unknown|4 years ago
[deleted]