Live data from Hacker News

Illumos to drop SPARC Support

github.com

111–120 of 184 posts

Re: Illumos to drop SPARC Support

#111

Earlier quoted context omitted.

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.

SPARC 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

>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

Re: Illumos to drop SPARC Support

#112
post #88

Earlier quoted context omitted.

I wouldn't be completely surprised if there is a box running a build of Mac OS for RISC V somewhere in Cupertino! Seriously though, I suspect that the ISA isn't that important for Apple but on the other hand I think they're probably quite happy with the direction of the Arm ISA (probably had a big say in parts of it) and it would take quite a lot to push them away. I think that the odds on the Nvidia takeover are qui…

Apple's aggressive removal of legacy stuff means the apps they do have are mostly kept up to date, so they have that going for them. On the desktop the major Mac OS only apps are now a) owned by Apple and b) rewritten from scratch so are easy to port to ARM, and therefore most likely, anything else. Will RISC V do what ARM did to x86? Start at the low end, be more open, and slowly take over.

I think that's unlikely - Arm gradually replaced a number of in-house ISA's and designs because the economics didn't support each firm doing their own thing. I'd be surprised if in many cases - except for eg Western Digital - the economics of going RISC-V make sense.

Re: Illumos to drop SPARC Support

#113

Earlier quoted context omitted.

At Joyent, we deployed public-facing multitenant workloads based on zones (and before that, jails) for many years. We seriously trusted it -- and had serious customers who seriously depended on it. So, now you know someone!

Security requirements (and awareness) have increased over the years, have they not?

They definitely have! And we had a (zones-based) public cloud through it all. On that note, Alex Wilson's description of working with Robert Mustacchi on mitigating Meltdown by adding KPTI to illumos[0] definitely merits a read!

[0] https://blog.cooperi.net/a-long-two-months

Re: Illumos to drop SPARC Support

#114
post #110

Earlier quoted context omitted.

> Still leaves Apple open to potential Nvidia's changes to the ISA's direction (and the ISA won't stand still). I assume a full fork of the ISA isn't on the cards even for Apple.

> I assume a full fork of the ISA isn't on the cards even for Apple. Why do you assume this?

If you've seen their license then happy to be corrected but typically an architecture license wouldn't permit them to do precisely what they want with the ISA with no restrictions whatsoever.

Re: Illumos to drop SPARC Support

#115
post #34

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 proceede…

The 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.

Re: Illumos to drop SPARC Support

#116
post #110

Earlier quoted context omitted.

> I assume a full fork of the ISA isn't on the cards even for Apple. Why do you assume this?

If you've seen their license then happy to be corrected but typically an architecture license wouldn't permit them to do precisely what they want with the ISA with no restrictions whatsoever.

I haven’t seen their license but they founded ARM and even though they don’t retain any ownership of the business I have heard that they retain a license that allows them to do pretty much whatever they like with the architecture in their own products.

Re: Illumos to drop SPARC Support

#117

Earlier quoted context omitted.

At Joyent, we deployed public-facing multitenant workloads based on zones (and before that, jails) for many years. We seriously trusted it -- and had serious customers who seriously depended on it. So, now you know someone!

And needless to say it became a billion dollar business, with a great product.

They were acquired for $170m.

Re: Illumos to drop SPARC Support

#118
post #86

Earlier quoted context omitted.

The 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.

At Joyent, we deployed public-facing multitenant workloads based on zones (and before that, jails) for many years. We seriously trusted it -- and had serious customers who seriously depended on it. So, now you know someone!

To be fair, y'all had some serious vulnerabilities, including zone escapes and arbitrary kernel memory reads, discovered by @benmmurphy.

Re: Illumos to drop SPARC Support

#120
post #71

Earlier quoted context omitted.

>ZFS on Linux 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.

>What we, er, the linux community, chose instead, was BTRFS. Isn't that putting politic before technical excellence, something the Linux crowd is proud of? Other than in place volume expansion, there is no technical reason to choose BTRFS over ZFS (for now.) I don't really see a killer feature from BTRFS that would persuade me to take a chance with it.

It's being pragmatic. Linux has typically placed freedom ahead of pretty much everything else.[1] All else being equal, sure you want the best technical solution. But if it doesn't fit the definition of freedom that Linux requires, how otherwise good a solution is doesn't matter. So the main 'killer' feature of BTRFS is that it fits the licensing requirements for integration into Linux. Linux has a great many problems, but being sticklers for a particular type of license isn't one of them IMO.

[1] This isn't just idealism. See Oracle v. Google for an example of what happens if you play fast and loose with licenses and a malicious actor. Google eventually won, but how many millions of dollars did that victory cost them? Oracle would love Linux developers to blunder their way into the receiving end of a lawsuit.

Post reply on HN