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

71–80 of 184 posts

Re: Illumos to drop SPARC Support

#71

Post by nimbius »

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.

Re: Illumos to drop SPARC Support

#72

Post by 1_person »

insaneirish wrote: post #58
bombcar wrote: post #38

Earlier quoted context omitted.

There are various open-source and white-box network switches and routers - do any of them run big-endian? If not, it must be a solved problem (perhaps by fast-path dedicated ASICs).

> If not, it must be a solved problem (perhaps by fast-path dedicated ASICs). Correct. The data plane of all 'real' networking is done in ASICs and/or NPUs.

Surprisingly less true these days.

Increasingly things seem to be moving towards ASICs for switching and general purpose CPUs (usually with a lot of support from the NIC offload capabilities) for routing, even in 'real' networking hardware.

The vast majority of fabric ASICs would never actually utilize additional TCAM necessary to support full tables at line rate in hardware because top of rack switches do not have that many addressable targets, so it's a wasted cost.

And with DPDK optimized software implementations are achieving zero drop line rate for even 100G+ interfaces for much, much lower cost than full table routing ASICs married to fabric ASICs in a chassis switch.

It's not something a lot of users are aware of -- they often think they've bought an ASIC-based router! -- but essentially all of the big vendors entry and mid-level devices are software routers, and they're even trying to figure out how to sell their NOS experience on whitebox hardware without undercutting their branded hardware.

Re: Illumos to drop SPARC Support

#73

Post by kps »

insaneirish wrote: post #58
bombcar wrote: post #38

Earlier quoted context omitted.

There are various open-source and white-box network switches and routers - do any of them run big-endian? If not, it must be a solved problem (perhaps by fast-path dedicated ASICs).

> If not, it must be a solved problem (perhaps by fast-path dedicated ASICs). Correct. The data plane of all 'real' networking is done in ASICs and/or NPUs.

Last NPU I worked with (admittedly 10+ years ago) was little endian! It used load/store-swapped instructions. (Why? I can only guess that they licensed a little-endian CPU core for other reasons.)

Re: Illumos to drop SPARC Support

#74

Post by roryrjb »

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?

Re: Illumos to drop SPARC Support

#75

Post by _hyn3 »

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.

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.

Re: Illumos to drop SPARC Support

#76

Post by lizknope »

klelatti wrote: post #70
classichasclass wrote: post #69

Earlier quoted context omitted.

Pretty sure Apple has a permanent ARM license. They'll watch what happens with Nvidia, but it doesn't really affect them because, as you say, all the secret sauce is in-house.

Does that give them control over the direction of the ISA - suspect not. Don't think it's really the case then that they're unaffected by the Nvidia takeover.

Most companies buy the ARM CPU RTL or an existing hardened core for their chip.

Large companies like Apple have an architectural license and implement the entire instruction set on their own.

I worked for a couple of companies with ARM architectural licenses and there was a large ARM compliance suite of tests that had to be run and pass before you could claim that you made an ARM instruction set compatible CPU.

I have heard that Apple does not claim ARM compatibility and doesn't run the compliance suite which allows them a few shortcuts and other optimizations. Apple only cares about running Mac OS and iOS on their hardware so if they were incompatible with Linux/ARM or Windows/ARM they wouldn't really care.

I haven't been able to verify this. Linux/ARM seems to be running okay so far on the new Apple M1 chips.

I don't know if Apple would be affected much if Nvidia buys ARM. Their architecture license to implement from scracth is probably forever but maybe not

Re: Illumos to drop SPARC Support

#77

Post by zepto »

mrweasel wrote: post #61
klelatti wrote: post #36

Earlier quoted context omitted.

On the Apple specific case I think any move to RISC V would be because it would want more control than it has with Arm. It could then take the RISC V ISA in the direction it wants. I'm guessing it already has a lot of influence over Arm though and there are other factors that strongly act in favour of staying with Arm. If Nvidia takes over Arm though and starts making life difficult for the ecosystem then that could…

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.

> they could move away from ARM if the Nvidia purchase happens.

The Nvidia purchase is irrelevant to Apple. They have a license that won’t be impacted.

The only thing that would make them move away would be a performance bottleneck in the architecture that necessitates a shift.

Re: Illumos to drop SPARC Support

#78

Post by ch_123 »

spijdar wrote: post #33
sgift wrote: post #19

Earlier quoted context omitted.

How would upgrading GCC help with the problem that they don't have SPARC machines available for building Illumos?

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

While I don't follow Illumos closely, I know that there was a project to remove the dependency on the Sun Studio compiler suite, so it's possible that the reliance on the old gcc version has something to do with that.

Re: Illumos to drop SPARC Support

#79

Post by klelatti »

lizknope wrote: post #76
klelatti wrote: post #70

Earlier quoted context omitted.

Does that give them control over the direction of the ISA - suspect not. Don't think it's really the case then that they're unaffected by the Nvidia takeover.

Most companies buy the ARM CPU RTL or an existing hardened core for their chip. Large companies like Apple have an architectural license and implement the entire instruction set on their own. I worked for a couple of companies with ARM architectural licenses and there was a large ARM compliance suite of tests that had to be run and pass before you could claim that you made an ARM instruction set compatible CPU. I hav…

Interesting - especially that Apple gets some latitude on compliance.

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.

Re: Illumos to drop SPARC Support

#80

Post by klelatti »

zepto wrote: post #77
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.

> they could move away from ARM if the Nvidia purchase happens. The Nvidia purchase is irrelevant to Apple. They have a license that won’t be impacted. The only thing that would make them move away would be a performance bottleneck in the architecture that necessitates a shift.

> 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.
Post reply on HN