Illumos to drop SPARC Support(github.com) |
Illumos to drop SPARC Support(github.com) |
https://github.com/illumos/illumos-gate/blob/master/usr/src/...
The trick uses a branch in the delay slot of a jmp--a decidedly unusual construction. At the time I found this to be extremely clever and elegant... but apparently not so clever as to warrant a comment.
SPARC has two attributes (I hesitate to call them features) that this code interacts with: register windows and a delay slot. Register windows are a neat idea that leads to some challenging pathologies, but in short: the CPU has a bunch of registers, say 64, only 24 of which are visible at any moment. There are three classes of windowed registers: %iN (inputs), %lN (local), %oN (output). When you SAVE in a function preamble, the register windows rotate such that the callers %os become your %is and you get a new set of %ls and %os. There are also 8 %gN (global) registers. Problems? There's a fixed number of registers so a bunch of them effectively go to waste; also spilling and filling windows can lead to odd pathologies. The other attribute is the delay slot which simply means that in addition to a %pc you have an %npc (next program counter) and the instruction after a control flow instruction (e.g. branch, jmp, call) is also executed (usually, although branches may "annul" the slot).
This code is in DTrace where we want to know the value of parameters from elsewhere in the stack, but don't want to incur the penalty of a register window flush (i.e. writing all the registers to memory). This code reaches into the register windows to pluck out a particular value. It turns out that for very similar use cases, Bryan Cantrill and I devised the same mechanism completely independently in two unrelated areas of DTrace.
How's it work?
We rotate to the correct register window (note that this instruction is in the delay slot just for swag): https://github.com/illumos/illumos-gate/blob/master/usr/src/...
Then we jmp to %g3 which is an index into the table of instructions below (depending on the register we wanted to snag): https://github.com/illumos/illumos-gate/blob/master/usr/src/...
The subsequent instruction is a branch always (ba) to the next instruction. So:
%pc is the jmp and %npc is the ba. The jmp sets %npc to an instruction in dtrace_getreg_win_table and %pc is the old %npc thus points to the ba. The ba sets %npc to be the label 3f (the wrpr) and %pc is set to the old %npc, the instruction in the table. Finally the particular mov instruction from the table is executed and %pc is set to the old %npc at label 3f.
Why do it this way? Mostly because it was neat. This isn't particularly performance critical code; a big switch statement would probably have worked fine. In the Solaris kernel group I remember talking about interesting constructions like this a bit around the lunch table which is probably why Bryan and I both thought this would be a cool solution.
I'm not aware of another instance of instruction picking in the illumos code base (although the DTrace user-mode tracing does make use of the %pc/%npc split in some cases).
OpenBSD will eventually face the same issues with older systems, and I believe they already dropped platforms because hardware couldn’t be replaced.
For newer SPARC system you could “just” buy one. Oracle doesn’t need to donate them, it would be nice if they did, but the community around Illumos, Debian and OpenBSD could raise money to buy theses systems.
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 Debian Ports:
That's a lot of work and I don't see IBM making a machine available.
More on topic, as someone sentimental for SPARC hardware and to an extent solaris, this is sad to see, but it feels like just a formality. I don't think illumos has worked properly on SPARC hardware since ... Ever? There were a few illumos distributions with SPARC builds but I always had trouble getting them to run on even a T2, seems there was little work done post rebranding from OpenSolaris for SPARC. Linux and OpenBSD have been much, much better on SPARC than Illumos, tinged with bitter irony...
We tried to convince Oracle to donate a SPARC machine for Debian but that unfortunately never happened for various reasons.
But IBM wouldn’t help someone to build an AIX-killer OS.
SPARC or not SPARC, I would love to help with that!
* 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 management while not providing half an operating system like systemd.
I completely agree. I love Linux and it’s easily my preferred desktop OS but when it comes to stuff like ZFS, containerisation and other enterprise features, FreeBSD and Solaris are just more unified and consistent. A lot of it has to do with Linux being a hodgepodge of different contributors resulting in every feature effectively being a 3rd party feature. Which I think is the problem Pottering was trying to solve. And in many ways that’s quite a strength too. But ultimately it boils down to the old Perl mantra of “There's more than one way to do it” and how it’s fun for hackers but FreeBSD et al add the “but sometimes consistency is not a bad thing either” part of the mantra doesn’t too.
https://en.m.wikipedia.org/wiki/There%27s_more_than_one_way_...
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.
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.
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.
That is a huuuuge overstatement for the current state of Btrfs. In some specific domains it is a working replacement. But for most domains it still falls far behind ZFS in terms of stability, resiliency or even ease of use.
By all means if you want to use btrfs then go for it. But the favourable comparisons people make when comparing btrfs to ZFS is a combination of wishful thinking and not having really bullied their fs into those extreme edge cases where the cracks begin to show. And frankly I’d rather depend on something that has had those assurances for 10+yrs already than have the hassle of explaining downtime to restore data on production systems.
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.
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.
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.
Torvald's comment about ZFS was as uninformed as it gets...and he calls himself an FS-Guy ;(
I used it for hosting a lot of java over the years but these days everyone wants a k8s endpoint and really the kind of hypervisor you are running doesn’t really make a difference.
Shame, it was nice tech.
Lxc containers vs Solaris Zones... zones clearly wins.
SMF vs systemd (I know that you didn't include this, but it matters)... SMF is clearly superior as well.
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 are in-order, why?)
POWER isn’t so bad though. It’s open enough where you could build your own lower-cost core if you wanted. There’s nothing intrinsic to the ISA that would mandate an expensive chip other than volume constraints.
PA-RISC put up some great numbers back in the day but between the Compaq acquisition (bringing with it Alpha) and Itanium it was chronically under-resourced. They had a great core in the early 90s and basically just incrementally tweaked it until its death.
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 competitive, though, and was happy to bail out for Itanium when it was viable. My big C8000 is a power hungry titan, makes the Quad G5 seem thrifty.
If you look at ARM, particularly the 64-bit version, you'll notice it attempts to squeeze multiple operations into a single 32-bit "instruction". It's still called RISC, but not really "reduced" anymore.
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.
Is that still true in the present tense? Anybody doing this in 2021? Seems like alpha has been dead for a long time.
That's not correct. s390x is big-endian and well supported in all enterprise distributions such as SLE, RHEL as well as Debian and Ubuntu.
Serialization formats like JSON/YAML/protobuf/etc. would be much more costly by comparison.
ARM: 1985 ARM64: 2011
RISC V: 2010
It took x86 about 10 years (1988) to become the most popular, and until 2005 to cause Apple to switch (another 17 years)
It took ARM about 25 years (2010) to become the most popular, and until 2020 to cause Apple to switch (another 10 years)
The Newton, then the iPod, then the iPhone, and now the M1.
The iPhone is a more important device for Apple than the Mac from a revenue point of view, and they've sold more devices with ARM chips in them than they have 68k, PowerPC, or x86. They've sold 2.2 billion iPhones. I can't find an easy number on how many Macintoshes they've sold totally, but I can't imagine it's close to that.
In fact, they used ARM in the Newton (1993) before they used PowerPC in the Power Mac (1994).
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 wanted to drop support for Solaris already and OpenJDK upstream did actually drop it.
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.)
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?
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...
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 the kernel.
Solaris on Sparc was great until ca. 2006. After that it started dying.
For anyone that got to use a T3, T4+, etc. performance was obviously and substantially improved.
You're also ignoring significant innovations such as ADI.
Regardless, it doesn't matter anymore.
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
But as a believer in open source, I really would love it if the choices we had were so much superior to the proprietary stuff that was out there that it made using an open source OS a no brainer.
The last PPC64 release of Ubuntu was 16.04 which is now out of support by about a month. Even on that, the two major web browsers didn't support building on the platform for a long time.
Yes, it can be done if you want enough to do it.
https://catfox.life/2018/11/03/clearing-confusion-regarding-... for more info
(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.)
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.
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.
What I mean is that if you use LXC namespace's as a container it is going to be an insecure container. Simply because LXC namespace's are not containers and are not going to provide a fully isolated environment. Namespace's are low-level building blocks which, together with other technologies (for example a virtualized network stack), you can use to make fully isolated containers. And that's why most hosters just took a shortcut and put the whole thing in a hardware VM to ensure tenants are fully isolated. Which I think is a shame since you also get all the overhead of a hardware VM.
So sure, you can _make_ something like jails or zones on Linux if you combine a bunch of things and provide the glue. But there is no concept of a container like jails or zones in Linux. Which leads to other problems such as there not being any tooling to mange the (non-existant) container.
> 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.
I don't know if I fully understand what your saying here but I think you mean that with a type 2 hypervisor the hypervisors kernel runs in a more privileged mode on the CPU then the virtualized kernels it manages and that provides additional security?
I don't really see how a type 2 hypervisor would conceptually give additional security in regards to a type 1 hypervisor (where a single kernel can provide multiple OS instances such a FreeBSD with Jails or Solaris / Illumos with Zones). Everything that is not the "main" kernel always executes in a less privileged mode then the kernel executing them on the CPU. For example no user process executes on Ring 0 on a "normal" (ie. non-hypervisor) OS. With containers this is no different. Hardware virtualization doesn't give a big conceptual advantage in that regard as far as I know.
https://www.realworldtech.com/forum/?threadid=189711&curpost...
>[ZFS] was always more of a buzzword than anything else, I feel,
This is deeply ignorant. I feel that Linux has been handicapped by the fact that many developers have never done any serious enterprise administration and thus not having clear understanding of the needs of a set of their users.
>His only actual comment against ZFS was that benchmarks didn't look great
What benchmark? Mines are looking pretty good, with a preheated Arc and with L2 especially...actually much better than any HW-Raid. Compared to Linus, there are Institutes with a bit more than a single 3GB git repository, and the crazy stuff...they need verified backups.
https://computing.llnl.gov/projects/zfs-lustre
If he ever has to improve a Lustre Filesystem of 55 petabyte with ZFS, he can come back, otherwise Linus...shut-up* and be happy with your ext4 (nothing against that one).
* A homage to the old linus-style of having a discussion.
Incidentally Rust's continued support for S390X is driven primarily by cuviper who works for Red Hat (even before the IBM acquisition).
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.
Although, I do prefer the durability of XFS or ext4 (depending on workload) vs UFS, and the setup you described is totally maintainable.
[1] This isn't just idealism. See Oracle v. Google for an example of what happens if you play fast and loose with licenses and a malicious actor. Google eventually won, but how many millions of dollars did that victory cost them? Oracle would love Linux developers to blunder their way into the receiving end of a lawsuit.
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 OpenBSD -performance, mostly; that's why I use windows and Ubuntu instead. But the way they run things is admirable IMO. Blatant BS isn't tolerated.)
The thing is that systemd did something quite clever -- it sold itself to the people actually building distributions, which are the people that actually matter the most in regards what system software gets used. It made their jobs easier and less annoying in many ways.
As somebody who's done a lot of packaging and writing of SysV scripts, I can tell you that it's a tiresome and annoying task even for a small amount of software, let alone a whole distro. At that point the unix philosophy loses its luster quite a bit.
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.
https://bugs.launchpad.net/upstart/+bug/406397/comments/21 https://bugs.launchpad.net/upstart/+bug/447654/comments/6
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 :)
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.
Correct. The data plane of all 'real' networking is done in ASICs and/or NPUs.
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.
To be fair [to you], my original claim is a bit of a tautology as I don't really consider software/CPU based CPE gear to be 'real' networking.
I should be more specific. High radix switches/routers are, unequivocally, not built out of CPUs and software, period. To the point of the original discussion, these concentration points are the only place that byte order overhead would be significant. Others in this thread claim it's not significant even in CPU implementations due to optimized instructions, but I personally can't opine on that.
(The stroke of genius of the C++11 memory model, compared to the older Java memory model, was that reordering could be treated the same way no matter if performed by processors or compilers).
(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.)
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, it may be more difficult for the new entrant.
That's why RISC V's win (if it occurs) will be because it's Open Source. Linux won in 30 years against everyone else due to that.
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 change ....
It would be interesting to know how important the ARM instruction set is to Apple.
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.
(side tangent FWIW, NetBSD has no qualms with using GPLv3 GCC, only Free/Open do)
(Edit for another historical tangent: Sun helped create System V release 4, which specifically combined element of older SysV with BSD. Additionally, Solaris/"SunOS 5"'s predecessor SunOS 4 was a straight-up BSD. So Solaris is a pretty BSD-y UNIX, in a way...)
This branch in particular addresses your points: https://news.ycombinator.com/item?id=27062069
Has the latest version of Ubuntu finally made mirrored ZFS root pools painless? Because that was anything but a native out of the box experience (compared to setting up the same on FreeBSD) and that has bit me several times.
I've use ZFS on both FreeBSD and Linux for years and while Ubuntu is closing the gap, ZFS has been the default recommended file system on FreeBSD for close on 10 years already. So it's bound to feel more like a native experience on FreeBSD.
> In a review in DistroWatch, Jesse Smith detailed a number of problems found in testing this release, including boot issues, the decision to have Ubuntu Software only offer Snaps, which are few in number, slow, use a lot of memory and do not integrate well. He also criticized the ZFS file system for not working right and the lack of Flatpak support. He concluded, "these issues, along with the slow boot times and spotty wireless network access, gave me a very poor impression of Ubuntu 20.04. This was especially disappointing since just six months ago I had a positive experience with Xubuntu 19.10, which was also running on ZFS. My experience this week was frustrating - slow, buggy, and multiple components felt incomplete. This is, in my subjective opinion, a poor showing and a surprisingly unpolished one considering Canonical plans to support this release for the next five years."
This was Ubuntu's latest LTS release, which is less than a year old. Granted not all of the criticism levelled against it are ZFS related and granted that's just another persons anecdotal report but it mirror the same experiences everyone else, aside from yourself it seems, raises when switching between Linux and FreeBSD for ZFS storage.
I don't post this as a hater though. I, like others, do still run Ubuntu Server + ZFS for some systems (particularly where I wanted ZFS + Docker) and those systems do run well. But I can't deny that everything requires just a little more effort to get right on Linux because there isn't the assumption you're running ZFS where as on FreeBSD it more or less pre-configured to use ZFS right out of the box because that's the expectation. eg FreeBSD containers tooling is already written to support ZFS where as Linux container tooling isn't.
This is why people talk about a smoother experience on FreeBSD. The file system itself is the same code base and performs largely the same. But it's all the stuff around the edge that is built with the assumption of ZFS on FreeBSD that makes things feel a little less hacked together with duct tape.
My point is unlike the other BSDs they haven't made a point of deprecating/removing GCC from the source tree, or even using LLVM by default where they can. For third parties worried about GPLv3, you can easily delete all GPLv3 code with a rm -rf src/external/gpl3 :)
You can look at the recent history of Linux kernel LPEs --- there has been sort of a renaissance because of mobile devices --- and count all the ways any shared-kernel multitenant system would have broken down. At the end of the day, it's not so much about predicting whether your system can get owned up (it can), so much as: "what do I need to do when there is a kernel LPE announced on my platform". If you're doing shared-kernel isolation, the right answer to that question is usually "fire drill". It's not a noodley thought-leadership kind of question; it's a simple, practical concern.
Also, now, extremely subtle and hard-to-mitigate timing attacks between tenants.
Give them some time to get Rust above that.
Very big ocean indeed.
That said, I could just be completely wrong, and there could be similar things that can be done using jails and zones. But when I looked around for similar art with FreeBSD jails, either with regards to Docker's style of packaging and distribution, or with regards to additional layers like gVisor, it didn't seem like a thing well-suited to that kind of composition. In comparison, jails, at least, seem kind of like more powerful chroots. To me this is a pretty big difference versus Linux "containers".
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 quite small by now so don't think a move likely at all.
Will RISC V do what ARM did to x86? Start at the low end, be more open, and slowly take over.
Agree with the point 100% but Apple also has a history of long and sustained investments in key parts of the stack where it sees long term value - including compilers and silicon - and long relationships with suppliers. I suspect their relationship with Arm is in that category and so in the absence of something that is demonstrably better, then that will continue.
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.
Why do you assume this?
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
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.