141–150 of 184 posts
While the primary issue is likely developer time and hardware availability to test on, there are other OSs like OpenBSD which supports much newer SPARC64 hardware: https://www.openbsd.org/sparc64.html
OpenBSD is the only OS ever to run on my Tadpole laptops without any modification necessary. Even Solaris 8 and 10 needed special software to run on them. OpenBSD works right out of the box.
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 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.
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.)
Earlier quoted context omitted.
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.
> The dealbreaker problem remains a shared kernel attack surface between tenants. Also, now, extremely subtle and hard-to-mitigate timing attacks between tenants.
Earlier quoted context omitted.
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.
At Joyent, we deployed public-facing multitenant workloads based on zones (and before that, jails) for many years. We seriously trusted it -- and had serious customers who seriously depended on it. So, now you know someone!
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.
I have a uniquely soft spot for SPARC, having written and disassembled a bunch of SPARC early in my career. If this is its swan song, I'll take the moment to share some code the takes advantage of the odd (today) delay slot architecture to implement instruction picking: 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.…
Earlier quoted context omitted.
To be fair, y'all had some serious vulnerabilities, including zone escapes and arbitrary kernel memory reads, discovered by @benmmurphy.
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…
Earlier quoted context omitted.
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.
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.
x86: 8086 1978 x64: 1999 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).
Earlier quoted context omitted.
At Joyent, we deployed public-facing multitenant workloads based on zones (and before that, jails) for many years. We seriously trusted it -- and had serious customers who seriously depended on it. So, now you know someone!
There were also tons of providers who trusted Linux containers for VPS hosting.