Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Illumos to drop SPARC Support

github.com

Post reply on HN
Print view View original

81–90 of 184 posts

Re: Illumos to drop SPARC Support

#81

Post by monocasa »

classichasclass wrote: post #30
spamizbad wrote: post #10

Earlier quoted context omitted.

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…

You could even build your own Power ISA system with Microwatt, which is fully synthesizeable and growing by leaps and bounds. https://github.com/antonblanchard/microwatt (Disclaimer: minor contributor) I really liked PA-RISC. I thought it was a clean ISA with good performance at the time and avoided many of the pitfalls of other implementations. I think HP didn't want to pour lots of money into it to keep it competit…

IDK, I never really liked PA-RISC, but to be fair I was always able to look at it from a hindsight perspective. Looking back it seems to have most of the RISC issues that complicate modern ISA design. Like branch delay slots, having a multiply instruction wasn't RISCy enough for it to bother with, etc.

Re: Illumos to drop SPARC Support

#82

Post by nix23 »

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.

>Torvalds even said so himself.

Torvald's comment about ZFS was as uninformed as it gets...and he calls himself an FS-Guy ;(

Re: Illumos to drop SPARC Support

#83

Post by josteink »

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 we, er, the linux community, chose instead, was BTRFS. It isnt ZFS

Speak for yourself. As a part of “the Linux community” I gave btrfs a fair chance, but stopped using it because it constantly failed on me in ways no other fs had done before and didn’t protect my data.

ZFS is rock solid and I’ve never had any of the issues I had with btrfs.

So as a member of “the Linux community” you claim to unilaterally represent I put such petty license-politics aside and choose the file system which serves my needs best, and that is ZFS.

Re: Illumos to drop SPARC Support

#84

Post by nix23 »

_hyn3 wrote: post #75
nimbius wrote: 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.

I lost data and had to restore from 12 hour old backups one too many times with BTRFS. XFS + Ext4 for me from here on out, but that's one of the great things about Linux: lots of choices.

XFS all the way down...or ZFS (on FreeBSD)

Re: Illumos to drop SPARC Support

#86

Post by tptacek »

jsiepkes wrote: post #60
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…

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.

Re: Illumos to drop SPARC Support

#87

Post by tytso »

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…

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.

[1] https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs&arc...

Re: Illumos to drop SPARC Support

#88

Post by mavhc »

klelatti wrote: post #66
mrweasel wrote: post #61

Earlier quoted context omitted.

Apple is really interesting, with chip design being moved inhouse and the ease of which they seem to switch architecture they could move away from ARM if the Nvidia purchase happens. I think they’d want to avoid it, at least for the next 10 years. It would be interesting to know how important the ARM instruction set is to Apple.

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.

Re: Illumos to drop SPARC Support

#89

Post by jchw »

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.

Also, tools for improving Docker for multi-tenant workloads exists, like gVisor. I don’t think equivalents exist for jails/zones really.

Re: Illumos to drop SPARC Support

#90

Post by bonzini »

asveikau wrote: post #27
spamizbad wrote: post #10

Earlier quoted context omitted.

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…

> Linux utilizes its Alpha port as a worst-case testbed for data race conditions in its kernel. Is that still true in the present tense? Anybody doing this in 2021? Seems like alpha has been dead for a long time.

Not Linux but the Linux formal memory model. The idea is that the compiler optimizations can be as nasty as the Alpha out of order execution engine and cache. The Linux code has to cater for these optimizations even though it will not result in an actual assembly instruction on anything except the Alpha. Problem is, on Alpha there's indeed an actual price to pay in performance for that nastiness.
Post reply on HN