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

131–140 of 184 posts

Re: Illumos to drop SPARC Support

#131

Post by simcop2387 »

ahl wrote: post #95
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.

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.

As far as Ive heard it's still pretty iffy. Since you were involved with the zfs side of things what are your thoughts on the upcoming zfs draid bits? I don't have specific need for them myself but they look really attractive for building a new pool to replace my aging drives.

Re: Illumos to drop SPARC Support

#132

Post by arid_eden »

nix23 wrote: post #82
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.

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

His comment was more on the wisdom (or otherwise) of running an out of tree filesystem. I think its hard to disagree with him. He went on to say you would never be able to merge the ZFS tree with Linux. Again he's the one who would know what code gets in Linux. His only actual comment against ZFS was that benchmarks didn't look great - which is unsurprising given all the extra work ZFS is doing wrt data integrity than other filesystems in production use.

https://www.realworldtech.com/forum/?threadid=189711&curpost...

Re: Illumos to drop SPARC Support

#133

Post by wicket »

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…

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

This is largely a myth, please provide an namespace-related CVE that has gone unpatched to support your argument. The reason they run as VMs is that hypervisors run on ring 0 and require higher privileges than the kernel, therefore they are naturally more secure. Like Namespaces, Zones and Jails are also managed by their respective kernels. If there were any major hosters running managed services for Zones and Jails, you can bet they would implement them in a similar way.

> Due to CDDL and GPL problems ZFS on Linux will always be hard to use making every update cycle like playing Russian roulette.

You're right in that the CDDL causes complication but I don't consider this to be a compelling reason to use Illumos. Many who want to use ZFS on Linux will use it and get it to work despite the licensing issues and complications.

> Like SMF offers nice service management while not providing half an operating system like systemd.

SMF is relatively nice (apart from the use of XML) and like you, I would not touch systemd barge pole. Despite systemd making a lot noise in major distros, there are plenty alternative distros for those of us who don't want to use it.

Don't get me wrong, I'm a Solaris guy, it made my career. I just fear that by dropping SPARC, Illumos have put the final nail in their own coffin.

Re: Illumos to drop SPARC Support

#134

Post by cestith »

mavhc wrote: post #26
alanfranz wrote: post #20

Earlier quoted context omitted.

“Switch” to what? Apple is one of the founders of ARM and still holds ARM shares IIRC

They sold their 40% stake in ARM when they were short of cash. Switch from Power PC to Intel, and then from Intel to ARM. I'm using Apple as a tipping point, to when the new architecture was so much better than the old it completely took over. Obviously with 90% of Apple devices being ARM already it was an easier choice for them this time. But as each Architecture gets more power as the market is many times bigger, i…

Apple switched from Motorola 68k to PowerPC, too, and Sun switched from 68k to SPARC. The Amiga, NeXT, early Palm devices, and the ST were also using members of the 68k family. That's an ISA born in 1979 and largely replacing (and inspired by) the 6800 (1974) which had a 16-bit address bus and 8-bit memory bus and its (binary incompatible but with the same assembly language) little brother the 6809 (1978). The Tandy Color Computer and the Dragon were notable 6809 systems.

That, of course, is just with the Mac since Apple previously used variants of the MOS 6502 (1975 and allegedly an illicit clone of the MC6800). Apple, Atari, Acorn, Commodore (the owner of MOS for several years), BBC, Oric, and Nintendo used it in multiple systems each. Apple, Acorn, and Nintendo built additional systems on its updated sibling the WDC65816 series (1983).

The the 6800/6809/Hitachi 6300/68k/Dragonball/Coldfire dynasty and the bastard MOS6502/WDC65816 families were collectively basically the ARM of their day in a way. Everyone targeting low priced or power-sipping was building platforms around them at one time or another. Acorn went from a customer to a major competitor and successor.

It should be noted that the PowerPC and the whole POWER ISA multi-platform family was largely inspired by Apple in the first place. They were talking to IBM about a new platform and invited Motorola to the talks as their long-time processor provider. They formed the "AIM Alliance" that eventually morphed into the POWER Foundation and OpenPOWER initiatives. I can't really speak to how much of POWER ISA is inspired by Motorola's own "RISC" processor, the 88000 series.

Re: Illumos to drop SPARC Support

#135

Post by arid_eden »

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.

My main issue with ZFS is the integrated nature - like systemd for filesystems. My 'alternative' for ZFS isn't BTRFS (awful performance characteristics for my workloads) but LVM coupled with ext4 and mdraid. I get snapshots, reliability, performance and a 'real UNIX' composable toolchain. I miss out on data checksums.

Re: Illumos to drop SPARC Support

#136

Post by retrac »

qwerty456127 wrote: post #21

Sound crazy. Like if Windows had dropped x86.

Much less crazy than when Mac dropped the 68K -- those had been joined at birth and separation was believed impossible by even the best surgeons.

Solaris was portable by design all along, in the later Unix fashion. Sun actually sold their first x86-based system running SunOS all the way back in the 1980s, as a low-end complement to their new high-end SPARC machines: https://en.wikipedia.org/wiki/Sun386i

Re: Illumos to drop SPARC Support

#137

Post by cestith »

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…

I suspect Apple's rights might be spelled out more in the sales contract to SoftBank than in a separate license agreement. Acorn created the ARM processor, but Apple is a cofounder of ARM Holdings (Acorn, Apple, and VLSI Technogology).

Re: Illumos to drop SPARC Support

#138

Post by ptribble »

yjftsjthsd-h wrote: post #126
ptribble wrote: post #99

Earlier quoted context omitted.

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…

> (And I'll just fork a copy and use that; it's not as though the SPARC ecosystem is a moving target.) This was actually one of my first questions on seeing the announcement - is Tribblix SPARC going to continue, or will this upstream change eventually EOL that as well?

Tribblix SPARC will continue. While you lose any new features that go into illumos upstream, at least you don't keep getting broken by changes going into illumos upstream.

(This isn't a commitment for all time, naturally. At some point the SPARC hardware I have will stop working. But it turns out to be solidly built and impressively reliable.)

Re: Illumos to drop SPARC Support

#139

Post by yjftsjthsd-h »

ptribble wrote: post #138
yjftsjthsd-h wrote: post #126

Earlier quoted context omitted.

> (And I'll just fork a copy and use that; it's not as though the SPARC ecosystem is a moving target.) This was actually one of my first questions on seeing the announcement - is Tribblix SPARC going to continue, or will this upstream change eventually EOL that as well?

Tribblix SPARC will continue. While you lose any new features that go into illumos upstream, at least you don't keep getting broken by changes going into illumos upstream. (This isn't a commitment for all time, naturally. At some point the SPARC hardware I have will stop working. But it turns out to be solidly built and impressively reliable.)

So for the foreseeable future you intend to just freeze SPARC Tribblix on the last Illumos to support SPARC? I suppose it should stay ABI compatible with other components ~forever, so that shouldn't even hold back other pieces of the system.

Re: Illumos to drop SPARC Support

#140

Post by laumars »

arid_eden wrote: post #130
jjav wrote: post #96

Earlier quoted context omitted.

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.

This is why FreeBSD rebasing its ZFS fork on ZFS-on-Linux made me so scared for the future of FreeBSD. Their one major advantage over Linux and they didn't have the developers to maintain their fork themselves.

ZFS will always be a smoother experience on FreeBSD as opposed to Linux because FreeBSD endorses it. Thus the user land and documentation is written assuming you’re running ZFS. As opposed to Linux where some distros might ship pre-compiled binaries but everything is written assuming you’re not running ZFS. Thus everything takes that extra couple of steps to set up, fix, and maintain.

For example, if you want to use ZFS as a storage for containers on Linux, you have to spend hours hunting around for some poorly maintained 3rd party shell scripts or build some tooling yourself. Whereas on FreeBSD all the tooling around Jails is built with ZFS in mind.

This is why platforms like FreeBSD feel more harmonious than Linux. Not because Linux can’t do the job but because there are so many different contributors with their own unique preferences that Linux is essentially loose Lego pieces with no instructions. Whereas FreeBSD has the same org who manage the kernel, user land and who also push ZFS.

And I say this as someone who loves Linux. There’s room for both Linux and FreeBSD in this world :)

Post reply on HN