Didn’t expect Oxide to go with a home-grown Illumos-based OS. I can appreciate the desire to control the entire stack, but on the other hand, Oxide is now maintaining an OS all by themselves (I would be surprised if the Illumos community is very large/active, but I could be wrong). There is also the question of who will want to commit their servers to a niche OS that only one company can realistically do anything about (say, fix something like Spectre/Meltdown).
It’s less problematic than it probably sounds since:
They control the hardware and can probably ignore other hardware while following upstream.
They have some serious OS experience in the team already who are deeply familiar with Illumos.
Illumos is only the host OS. Their product is all about on-prem cloud. So their users will mostly not know that Illumos is under the hood. They’ll be launching VMs via API and running mostly Linux.
users will mostly not know that Illumos is under the hood. They’ll be launching VMs via API and running mostly Linux.
This is a key observation. Consider both AWS and VMware, where people may suspect details of the underlying proprietary implementation but are really only interacting with the explicitly exposed API surface area which doesn’t expose those details to the consumer.
There is something to be said for an operating system community that moves slowly. You don’t get to take advantage of a large community, but you also won’t get washed away by that large community. Keeping up with a firehose has its own overhead, and your priorities probably won’t match the community’s.
It’s a lesson I learned watching node.js go mainstream. The emphasis on observability and debuggability went right out the window, because the community at large cared far more about new features than dealing with hard problems in production.
I’m guessing Oxide went with illumos more out of familiarity, but the above reasoning doubtless played a non-trivial role too.
I agree, hitching yourself to the wrong community is a consideration. But in this case, I think the goals of Linux (kernel, qemu/KVM, etc) would be pretty well aligned with Oxide’s goals and I don’t see a reason why they would change going forward.
FWIW, we’ve made a similar decision about 5 years ago by creating BuildOS which was heavily inspired by SmartOS (a PXE-booted in-RAM OS that is essentially a VM runner) but was based on Linux. So far no complaints.
Seriously, The Solaris descended operating systems have an incredible rep with a good reason. For literally decades, Sun hardware and software were THE gold standard in enterprise grade stability, and even in our industry where sometimes it feels like we forget everything we’ve ever learned every few years, things like that don’t just evaporate.
I had the same thought. I shouldn’t be surprised given Bryan’s involvement but I still didn’t expect it—especially with the Rust project’s lack of interest in making anything but Linux, macOS, and Windows tier 1.
Mounting a motherboard on cardboard doesn’t bother me. But that little SBC board sitting on top of a metal CPU heatsink… that bothers me. Since the whole thing isn’t going to fit inside a PC case, I’d say just go with more cardboard, it will at least prevent short-circuits from happening.
“As I’ve already stated, I am not an enterprise, nor do I plan on becoming one unless Jean-Luc Picard starts taking estrogen and wants to be my captain” - made my day :D
Didn’t expect Oxide to go with a home-grown Illumos-based OS. I can appreciate the desire to control the entire stack, but on the other hand, Oxide is now maintaining an OS all by themselves (I would be surprised if the Illumos community is very large/active, but I could be wrong). There is also the question of who will want to commit their servers to a niche OS that only one company can realistically do anything about (say, fix something like Spectre/Meltdown).
It’s less problematic than it probably sounds since:
This is a key observation. Consider both AWS and VMware, where people may suspect details of the underlying proprietary implementation but are really only interacting with the explicitly exposed API surface area which doesn’t expose those details to the consumer.
Solaris is probably mothers’ milk to people like Cantrill, who know it deeply (enough to certainly maintain it) and have a low opinion of Linux.
There is something to be said for an operating system community that moves slowly. You don’t get to take advantage of a large community, but you also won’t get washed away by that large community. Keeping up with a firehose has its own overhead, and your priorities probably won’t match the community’s.
It’s a lesson I learned watching node.js go mainstream. The emphasis on observability and debuggability went right out the window, because the community at large cared far more about new features than dealing with hard problems in production.
I’m guessing Oxide went with illumos more out of familiarity, but the above reasoning doubtless played a non-trivial role too.
I agree, hitching yourself to the wrong community is a consideration. But in this case, I think the goals of Linux (kernel, qemu/KVM, etc) would be pretty well aligned with Oxide’s goals and I don’t see a reason why they would change going forward.
FWIW, we’ve made a similar decision about 5 years ago by creating BuildOS which was heavily inspired by SmartOS (a PXE-booted in-RAM OS that is essentially a VM runner) but was based on Linux. So far no complaints.
Nerd cred? :)
Seriously, The Solaris descended operating systems have an incredible rep with a good reason. For literally decades, Sun hardware and software were THE gold standard in enterprise grade stability, and even in our industry where sometimes it feels like we forget everything we’ve ever learned every few years, things like that don’t just evaporate.
Yes. They did a lot of things super right and it feels like we’re still playing catch up in some ways.
SMF vs SystemD
Dtrace vs eBPF
ZFS vs BTRFS
I had the same thought. I shouldn’t be surprised given Bryan’s involvement but I still didn’t expect it—especially with the Rust project’s lack of interest in making anything but Linux, macOS, and Windows tier 1.
Tier 1 doesn’t matter that much. The only difference from Tier 2 is that automated runtime testing is run continuously.
Mounting a motherboard on cardboard doesn’t bother me. But that little SBC board sitting on top of a metal CPU heatsink… that bothers me. Since the whole thing isn’t going to fit inside a PC case, I’d say just go with more cardboard, it will at least prevent short-circuits from happening.
“As I’ve already stated, I am not an enterprise, nor do I plan on becoming one unless Jean-Luc Picard starts taking estrogen and wants to be my captain” - made my day :D