Illumos to drop SPARC Support • Hacker News Board

Re: Illumos to drop SPARC Support

#91

Post by guenthert » Fri, May 07, 2021, 5:18 PM UTC

nimbius wrote: post #71

wicket wrote: post #32

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

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

BTRFS is the only fs I recall having lost data to (rather it corrupts data, i.e. data of one file is found in another) as late as 2018.

Re: Illumos to drop SPARC Support

#92

Post by bcantrill » Fri, May 07, 2021, 5:18 PM UTC

tptacek wrote: post #86

jsiepkes wrote: post #60

Earlier quoted context omitted.

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

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!

Re: Illumos to drop SPARC Support

#93

Post by pjmlp » Fri, May 07, 2021, 5:19 PM UTC

wicket wrote: post #32

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

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.

Re: Illumos to drop SPARC Support

#94

Post by ptribble » Fri, May 07, 2021, 5:22 PM UTC

cbmuser wrote: post #46

PedroBatista wrote: post #25

Earlier quoted context omitted.

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?

> Yes, but where can I buy a SPARC CPU? You can buy them used or new in various kind of servers. > How many of those who have/can have it are running Illumos and are putting money/time in it? Dunno, I'm not really a Solaris guy. I use Solaris as a hypervisor for Linux and BSD LDOMs. > And more importantly what's the outlook for SPARC? Well, you could make the very same argument about Illumos. The Python developers wa…

For illumos, the sweet spot is the 10-15 year old Sun gear you can pick up on eBay. Works well, supported, not overly expensive.

Newer SPARC systems are really quite good. And pretty cost-effective too. The problem is that the starting price is out of reach, and almost nobody is offering a cloud service based on SPARC, so you can't hire it either.

I'm running illumos on SPARC. I have some old hardware (desktop and server) that I like to make use of. Time, yes, but I'm not putting money into it.

And while OpenJDK upstream has dropped support for SPARC and Solaris, that was really all about problems with the Studio compiler. I' maintaining an illumos OpenJDK port with the gcc toolchain on x86 - it's not excessively hard, and realistically if you're using a common toolchain and common CPU most standards-compliant code is portable at the OS layer.

Re: Illumos to drop SPARC Support

#95

Post by ahl » Fri, May 07, 2021, 5:25 PM UTC

nimbius wrote: post #71

wicket wrote: post #32

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

>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 is the latest on RAID-5/6 support for BTRFS. RAID-Z has its issues (saying this as the triple- and double-parity author), but it's been stable.

Re: Illumos to drop SPARC Support

#96

Post by jjav » Fri, May 07, 2021, 5:26 PM UTC

nimbius wrote: post #71

wicket wrote: post #32

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

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

When filesystem integrity matters, the filesystem matters more than the OS.

While I mostly use Linux these days, for file servers it must be ZFS, which means whichever OS has first-class support for ZFS. I'm still on Illumos but perhaps will move to FreeBSD at some point.

Re: Illumos to drop SPARC Support

#97

Post by wmf » Fri, May 07, 2021, 5:26 PM UTC

bcantrill wrote: post #92

tptacek wrote: 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!

There were also tons of providers who trusted Linux containers for VPS hosting.

Re: Illumos to drop SPARC Support

#98

Post by wmf » Fri, May 07, 2021, 5:27 PM UTC

roryrjb wrote: post #74

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?

https://github.com/oxidecomputer/propolis

Re: Illumos to drop SPARC Support

#99

Post by ptribble » Fri, May 07, 2021, 5:28 PM UTC

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…

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

Re: Illumos to drop SPARC Support

#100

Post by kens » Fri, May 07, 2021, 5:28 PM UTC

pabs3 wrote: post #6

tyingq wrote: post #5

Earlier quoted context omitted.

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.

IBM mainframes are big endian, all the Linux distros support them too.

IBM 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.)