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

161–170 of 184 posts

Re: Illumos to drop SPARC Support

#161

Post by bsder »

tptacek wrote: post #146
bcantrill wrote: post #123

Earlier quoted context omitted.

Yes, though I would like to believe that Ben's responsible disclosure coupled with our addressing those vulns (and auditing ourselves for similar) reflect exactly that seriousness around multitenant security. And for whatever it's worth, one of those vulnerabilities -- which was a bug in my code! -- very much informed by own thinking about the inherent unsafety of C, underscoring the appeal of Rust. So I am grateful…

If you have a kernel implemented in Rust, (1) you should shout that from the rooftops and (2) use whatever isolation mechanism you like on it.

They're starting with the bootloader and management engine. That's a tough enough ocean to boil.

Give them some time to get Rust above that.

Re: Illumos to drop SPARC Support

#162

Post by e12e »

arid_eden wrote: post #135
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.

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.

In principle I dislike the coupling of volume manager, raid and filesystem.

But I still think zfs gets most things right; I see the argument for a concistent system managing caching/logs, volumes, data integrity, discard support, compression, snapshots and encryption.

The fact that it's the first serious, open, cross platform solution (Linux, bsd, Mac, winnt) that provides encryption, integrity and filesystem is a nice bonus.

And the integration of snapshots and fs dumps via zfs send/receive is beautiful.

I think zfs makes sense like one fat layer - networking can go below (drdb, iscsi) or on top (iscsi, nfs, cifs).

Encryption need to be somewhat holistic - for making sane performance and data leaking tradeoffs.

Re: Illumos to drop SPARC Support

#163

Post by jclulow »

wicket wrote: post #133
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…

> 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, th…

> I just fear that by dropping SPARC, Illumos have put the final nail in their own coffin.

If that were true, most illumos users today would be SPARC users. There would be more than a couple of people working on SPARC support, and not merely as a part-time hobby. There would be software support for a SPARC machine that was sold some time after 2011.

Instead, something like 99% of the people running illumos are doing so on 64-bit x86 machines. Dropping SPARC support will allow us to move forward much more easily with enhancements to the dramatically more relevant x86 bits. If anything I expect it will allow us to do interesting things that would garner new interest, like using Rust to implement bits of the operating system.

Re: Illumos to drop SPARC Support

#164

Post by bsder »

rnd0 wrote: post #142
guardiangod wrote: post #105

Earlier quoted context omitted.

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

>Isn't that putting politic before technical excellence, something the Linux crowd is proud of? It's not unprecedented. The adoption of systemd was forced on distros through political pressure, and not for technical reasons. If you want a truly non-political OS community these days, I think you're basically stuck with OpenBSD. No CoC, no systemd, no political BS at all -just pure tech. (there's other problems with Op…

> It's not unprecedented. The adoption of systemd was forced on distros through political pressure, and not for technical reasons.

Sorry, I'm going to slag on this.

Anyone could have put in the work to make a better init experience. No one put in that work.

System Management Facility (SMF) existed on Solaris since 2005 (systemd didn't appear until 2011?). launchd on OS X dates to a similar time. Someone could have copied them--no one did.

Even once it became clear that systemd was going through, still nobody could muster the work to put together a viable alternative.

Where's the "meritocracy through code" Linux mantra in all of this?

You can say what you want about Poettering, but he put in the work to write the code. Nobody else did.

Perhaps the problem is that an init system is a metric boatload of finicky code that nobody had the guts or skills to drive to completion?

And for the old-init bigots, sorry, that wasn't working in spite of what you claim. The fact that Windows, OS X, Solaris, etc. (and then systemd) all converged on essentially the same design is because of common needs on modern computers.

Re: Illumos to drop SPARC Support

#165

Post by znpy »

bombcar wrote: post #109
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.

The Linux Community is working on BTRFS but if ZFS emerged with a GPLv2 compatible license tomorrow BTRFS would likely be moribund.

Yup. If openzfs was gpl-ed tomorrow morning, btrfs would be dead by tomorrow at lunch time.

Re: Illumos to drop SPARC Support

#166

Post by bsder »

spamizbad wrote: post #10
hulitu wrote: post #3

This is really sad. The world is heading to a duopoly x86 - arm. Alpha is dead, Mips is almost dead, PA-RISC is dead, POWER is too expensive and RISC-V is mostly nice to have.

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…

> Alpha’s loosey-goosey memory model makes multithreaded code on SMP systems more challenging.

I thought Alpha and ARM were the same with respect to that.

ARM had some fairly nasty to track down XFS file system corruption bugs for quite a while for exactly this reason.

The issue has always been that x86 goes out of its way to generally be more forgiving than the spec.

Re: Illumos to drop SPARC Support

#167

Post by salmo »

arid_eden wrote: post #135
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.

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.

Having run all these thing in prod (except BTRFS, it ate a mirror on my desktop), I’ll say that even the LVM + + is so much more hacky than geom on FreeBSD which feels much more ‘Unix’ with a designed composable interface.

Although, I do prefer the durability of XFS or ext4 (depending on workload) vs UFS, and the setup you described is totally maintainable.

Re: Illumos to drop SPARC Support

#168

Post by mappu »

laumars wrote: post #140
arid_eden wrote: post #130

Earlier quoted context omitted.

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…

I think "smoother experience on FreeBSD" is a myth -

The standard volume manager on FreeBSD is vinum/geom; ZFS ships its entire separate volume manager to the host OS, so you can't use mount/umount to control mounting a ZFS volume. Maybe it would be okay to move entirely over to ZFS's volume manager but it only supports ZFS's own filesystem, you can't use the ZFS volume manager with a normal FreeBSD UFS2 partition.

In both Linux and FreeBSD, ZFS's bolt-on ARC competes with the kernel's actual page cache for resources instead of properly integrating with it.

It's an out-of-tree filesystem for both OSes. Sure FreeBSD periodically imports it into master from OpenZFS (née ZoL), but all development happens elsewhere, and the SPL is still trying to emulate a Solaris interface on top of both OSes.

Is there any more concrete example of how ZFS is actually better integrated on FreeBSD compared to Linux, say Ubuntu? It takes ZFS snapshots automatically during apt upgrades, root-on-ZFS is a default installer option, etc.

Re: Illumos to drop SPARC Support

#169

Post by wmf »

tptacek wrote: post #150
wmf wrote: post #97

Earlier quoted context omitted.

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

How'd that turn out?

I haven't heard any stories of people being hacked via container escape, but the whole VPS industry was so low-stakes that maybe customers didn't expect good isolation anyway.

Re: Illumos to drop SPARC Support

#170

Post by Koshkin »

tptacek wrote: post #147
jchw wrote: post #89

Earlier quoted context omitted.

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

gVisor isn't a shared-kernel multitenant system; it's essentially kernel emulation. It's a much stronger design.

Similar to Xen?
Post reply on HN