15 ms·
Illumos to drop SPARC Support
- rbanffy 5y agoA 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.
- cbmuser 5y ago> A fun way to make Oracle donate a machine would be to make an official POWER port. We tried to convince Oracle to donate a SPARC machine for Debian but that unfortunately never happened for various reasons.
- spijdar 5y agoThere 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...
- 4ad 5y agoConvince Oracle to donate a machine... for an Oracle Solaris competitor?! Oracle was the one that shut down OpenSolaris in the first place!
- rbanffy 5y agoThe only way they’d do it is if someone made a Solaris-killer that ran on a SPARC-killer that could run an Oracle-killer database. But IBM wouldn’t help someone to build an AIX-killer OS.
- hulitu 5y agoThis 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.
- jhbadger 5y agoOn the plus side, at least it looks like it will be a duopoly. For a long time it looked like x86 would eat all other architectures.
- tyingq 5y agoIt'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.
- pabs3 5y agoIBM mainframes are big endian, all the Linux distros support them too.
- kens 5y agoIBM mainframes are big endian essentially because punch cards are big endian. (Punch cards are big endian because the number 123 is punched as "123". So that's the order a decimal number will be stored in memory. The System/360 mainframes (1964) had a lot of support for decimal numbers and it would be kind of bizarre to store decimal numbers big-endian and binary numbers little-endian so everything was big endian. IBM's current mainframes are compatible with S/360. On the other hand, in a serial computer, you operate on one bit at a time, so you need to start with the smallest bit for arithmetic. The Intel 8008 was a copy of a serial TTL computer, the Datapoint 2200, so it was little-endian. x86 is based on the 8008, so it kept the little-endian architecture.)
- pabs3 5y agoIIRC ARM devices can also be big-endian and GCC can even generate big endian 64-bit ARM code: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
- cbmuser 5y agoWhy 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 Debian Ports: > https://cdimage.debian.org/cdimage/ports/current/ https://cdimage.debian.org/cdimage/ports/current/
- sgift 5y agoHow would upgrading GCC help with the problem that they don't have SPARC machines available for building Illumos?
- spijdar 5y agoIt 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.
- 1over137 5y agoIllumos is a BSD, so perhaps, like other BSDs, they don't want to rely on GPLv3 projects like (current) gcc.
- spijdar 5y agoIllumos is a fork of Solaris, itself a UNIX System V derived OS, very much not a BSD, though taking some code from BSD. I'm not sure what license they make new additions under, but the core is CDDL licensed and not BSD licensed, anyway. (side tangent FWIW, NetBSD has no qualms with using GPLv3 GCC, only Free/Open do) (Edit for another historical tangent: Sun helped create System V release 4, which specifically combined element of older SysV with BSD. Additionally, Solaris/"SunOS 5"'s predecessor SunOS 4 was a straight-up BSD. So Solaris is a pretty BSD-y UNIX, in a way...)
- zdw 5y agoWhile 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 https://www.openbsd.org/sparc64.html
- cptnapalm 5y agoOpenBSD 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.
- cyberpunk 5y agoSPARC was where Theo cut his teeth in the netbsd years, anecdotal but I think it’s his favourite pet so you’d imagine it’ll be well supported on his os
- nix23 5y ago>The other architectures that OpenBSD supports have benefited because some kinds of bugs are exposed more often by the 64-bit big endian nature of UltraSPARC. https://www.openbsd.org/sparc64.html https://www.openbsd.org/sparc64.html
- deleted 5y ago[deleted]
- mrweasel 5y agoI 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.
- deleted 5y ago[deleted]
- qwerty456127 5y agoSound crazy. Like if Windows had dropped x86.
- corty 5y agoYes, 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.
- binarycrusader 5y agoThe notes about SPARC hardware performance are not accurate; there were significant performance improvements to SPARC in progress before the Oracle acquisition and some after. Oracle made significant investments for a time after the acquisition. I don't know at what point that direction changed, but it must have been somewhere between 2014-2017. For anyone that got to use a T3, T4+, etc. performance was obviously and substantially improved. You're also ignoring significant innovations such as ADI. Regardless, it doesn't matter anymore.
- pjmlp 5y agoThe SPARC innovations for hardware memory tagging, making Solaris one of the few OSes taming C in production were done after Oracle bought Sun.
- reg_windows 5y agoThis is so very far from the truth. The 2000's were a poor decade for Sun's management of SPARC. They wasted hundreds of millions on the Rock chip which is a story waiting to be written someday (Marc Tremblay, the Rock architect, was being portrayed with god-like praise by Sun executives, always citing the mountains of patents he had but as we know, patents aren't a leading indicator of technical or business success). Then they foolishly latched the SPARC program to a Stanford professor's idea of Chip Multi Threading which had some good ideas but was not performant at the very time when X64 clock rates were rocketing, due to Intel and AMD's fab processes. I'm not an Oracle apologist by any means but Oracle revived SPARC R&D and made the chip competitive again. Larry even funded a lower cost S7 SPARC chip intended for high volume cloud deployments. And as has been mentioned, Oracle also supported (again, with millions of dollars) the SPARC software-in-silicon program, which provided hardware support for encryption, bad pointer detection, and tabular memory compression/searching (DAX). They tried but it was too late for SPARC. But it should never be said that Oracle didn't pump a lot money into SPARC after the Sun aquisition.
- wicket 5y agoWith 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?
- cyberpunk 5y agoNot 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. Shame, it was nice tech.
- pjmlp 5y agoSolaris 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.
- jsiepkes 5y agoIn my opinion Linux hasn't caught up. * 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.
- tptacek 5y agoThe problem with this jails/zones stuff is that I don't know anyone who seriously trusts jails and zones for real multitenant workloads anyways. The dealbreaker problem remains a shared kernel attack surface between tenants. It's one thing to propose that Zones are better than namespaces (they probably are), but another thing to cross the threshold where the distinction is meaningful in practice.
- Ericson2314 5y ago> 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 5y agoI 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: https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/sparc/dtrace/dtrace_asm.s#L430 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 5y agoCan 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 :)
- ahl 5y agoYou mean the total lack of comments didn't help? ;-) SPARC has two attributes (I hesitate to call them features) that this code interacts with: register windows and a delay slot. Register windows are a neat idea that leads to some challenging pathologies, but in short: the CPU has a bunch of registers, say 64, only 24 of which are visible at any moment. There are three classes of windowed registers: %iN (inputs), %lN (local), %oN (output). When you SAVE in a function preamble, the register windows rotate such that the callers %os become your %is and you get a new set of %ls and %os. There are also 8 %gN (global) registers. Problems? There's a fixed number of registers so a bunch of them effectively go to waste; also spilling and filling windows can lead to odd pathologies. The other attribute is the delay slot which simply means that in addition to a %pc you have an %npc (next program counter) and the instruction after a control flow instruction (e.g. branch, jmp, call) is also executed (usually, although branches may "annul" the slot). This code is in DTrace where we want to know the value of parameters from elsewhere in the stack, but don't want to incur the penalty of a register window flush (i.e. writing all the registers to memory). This code reaches into the register windows to pluck out a particular value. It turns out that for very similar use cases, Bryan Cantrill and I devised the same mechanism completely independently in two unrelated areas of DTrace. How's it work? We rotate to the correct register window (note that this instruction is in the delay slot just for swag): https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/sparc/dtrace/dtrace_asm.s#L451 https://github.com/illumos/illumos-gate/blob/master/usr/src/... Then we jmp to %g3 which is an index into the table of instructions below (depending on the register we wanted to snag): https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/sparc/dtrace/dtrace_asm.s#L459 https://github.com/illumos/illumos-gate/blob/master/usr/src/... The subsequent instruction is a branch always (ba) to the next instruction. So: %pc is the jmp and %npc is the ba. The jmp sets %npc to an instruction in dtrace_getreg_win_table and %pc is the old %npc thus points to the ba. The ba sets %npc to be the label 3f (the wrpr) and %pc is set to the old %npc, the instruction in the table. Finally the particular mov instruction from the table is executed and %pc is set to the old %npc at label 3f. Why do it this way? Mostly because it was neat. This isn't particularly performance critical code; a big switch statement would probably have worked fine. In the Solaris kernel group I remember talking about interesting constructions like this a bit around the lunch table which is probably why Bryan and I both thought this would be a cool solution. I'm not aware of another instance of instruction picking in the illumos code base (although the DTrace user-mode tracing does make use of the %pc/%npc split in some cases).
- roryrjb 5y agoOne 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?