Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Oxide Chose Illumos

rfd.shared.oxide.computer

Post reply on HN
Print view View original

141–150 of 177 posts

Re: Why Oxide Chose Illumos

#141

Post by dijit »

transpute wrote: post #10

> Xen: Large and complicated (by dom0) codebase, discarded for KVM by AMZN 1. Xen Type-1 hypervisor is smaller than KVM/QEMU. 2. Xen "dom0" = Linux/FreeBSD/OpenSolaris. KVM/bhyve also need host OS. 3. AMZN KVM-subset: x86 cpu/mem virt, blk/net via Arm Nitro hardware. 4. bhyve is Type-2. 5. Xen has Type-2 (uXen). 6. Xen dom0/host can be disaggregated (Hyperlaunch), unlike KVM. 7. pKVM (Arm/Android) is smaller than KVM…

Honestly, SMF is superior to SystemD and it’s ironic it came earlier (and, that shows based on the fact that it uses XML as its configuration language.. ick).

However, two things are an issue:

1) The CDDL license of SMF makes it difficult to use, or at least that’s what I was told when I asked someone why SMF wasn’t ported to Linux in 2009.

2) SystemD is it now. It’s too complicated to replace and software has become hopelessly dependent on its existence, which is what I mentioned was my largest worry with a monoculture and I was routinely dismissed.

So, to answer your question. The argument must be: IllumOS over Linux.

Re: Why Oxide Chose Illumos

#142

Post by sophacles »

akira2501 wrote: post #136
sophacles wrote: post #133

Earlier quoted context omitted.

> Cargo is widely recognized as low quality. Can you point me to both of: * why it's considered low quality * evidence of this "wide regard" Other than random weirdos who think allowing dependencies is a bad practice because you could hurt yourself, while extolling the virtues of undefined behavior - I've never heard much serious criticism of it.

> why it's considered low quality Other software providing the same features produce better results for those users. It's dependency management is fundamentally broken and causes builds to be much slower than they could otherwise be. Lack of namespaces which is a lesson well learned before the first line of Cargo was ever written. I could go on. > evidence of this "wide regard" We are on the internet. If you doubt me…

Im not attempting to insult you, i didn't know you held such a hypocritical position - sorry pointing out that it is weird for someone working a field that is so dependent on logic to hold such a self-contradictory position insults you. Maybe instead of weird i should use the words unusual and unexpected. My bad.

You're right, I'm being dismissive of weasely unbacked claims of "wide regard". It's very clear now that you can't back your claim and I can safely ignore your entire argument as unfounded. Thanks for confirming!

Re: Why Oxide Chose Illumos

#143

Post by transpute »

dijit wrote: post #141
transpute wrote: post #10

> Xen: Large and complicated (by dom0) codebase, discarded for KVM by AMZN 1. Xen Type-1 hypervisor is smaller than KVM/QEMU. 2. Xen "dom0" = Linux/FreeBSD/OpenSolaris. KVM/bhyve also need host OS. 3. AMZN KVM-subset: x86 cpu/mem virt, blk/net via Arm Nitro hardware. 4. bhyve is Type-2. 5. Xen has Type-2 (uXen). 6. Xen dom0/host can be disaggregated (Hyperlaunch), unlike KVM. 7. pKVM (Arm/Android) is smaller than KVM…

Honestly, SMF is superior to SystemD and it’s ironic it came earlier (and, that shows based on the fact that it uses XML as its configuration language.. ick). However, two things are an issue: 1) The CDDL license of SMF makes it difficult to use, or at least that’s what I was told when I asked someone why SMF wasn’t ported to Linux in 2009. 2) SystemD is it now. It’s too complicated to replace and software has become…

> software has become hopelessly dependent on its existence

With some effort, Devuan has managed to support multiple init systems, at least for the software packaged by Devuan/Debian.

> SMF is superior to SystemD ... [CDDL]

OSS workalike opportunity, as new Devuan init system?

> The argument must be: IllumOS over Linux.

Thanks :)

Re: Why Oxide Chose Illumos

#144

Post by JonChesterfield »

Illumos and ZFS sounds completely sensible for a company that runs on specific hardware. They mention the specific epyc cpu their systems are running on which suggests they're all ~ identical.

Linux has a massive advantage where it comes to hardware support for all kinds of esoteric devices. If you don't need that, and you've got engineers that are capable of patching the OS to support your hardware, yep, have at it. Good call.

Re: Why Oxide Chose Illumos

#145

Post by Rendello »

implr wrote: post #85
craftkiller wrote: post #77

I wonder if CockroachDB abandoning the open source license[0] will have an impact on their choice to use it. It looks like the RFD was posted 1 day before the license switch[1], and the RFD has a section on licenses stating they intended to stick to the OSS build: > To mitigate all this, we’re intending to stick with the OSS build, which includes no CCL code. [0] https://news.ycombinator.com/item?id=41256222 [1] http…

They already have another RFD for this: https://rfd.shared.oxide.computer/rfd/0508 and on HN: https://news.ycombinator.com/item?id=41268043

And a podcast episode: https://oxide.computer/podcasts/oxide-and-friends/2052742

Re: Why Oxide Chose Illumos

#146

Post by jclulow »

transpute wrote: post #143
dijit wrote: post #141

Earlier quoted context omitted.

Honestly, SMF is superior to SystemD and it’s ironic it came earlier (and, that shows based on the fact that it uses XML as its configuration language.. ick). However, two things are an issue: 1) The CDDL license of SMF makes it difficult to use, or at least that’s what I was told when I asked someone why SMF wasn’t ported to Linux in 2009. 2) SystemD is it now. It’s too complicated to replace and software has become…

> software has become hopelessly dependent on its existence With some effort, Devuan has managed to support multiple init systems, at least for the software packaged by Devuan/Debian. > SMF is superior to SystemD ... [CDDL] OSS workalike opportunity, as new Devuan init system? > The argument must be: IllumOS over Linux. Thanks :)

SMF is OSS. The CDDL is an OSI approved licence. I'm not aware of any reason one couldn't readily ship user mode CDDL software in a Linux distribution; you don't even have the usual (often specious) arguments about linking and derivative works and so on in that case.

Re: Why Oxide Chose Illumos

#147

Post by transpute »

evandrofisico wrote: post #127
transpute wrote: post #10

> Xen: Large and complicated (by dom0) codebase, discarded for KVM by AMZN 1. Xen Type-1 hypervisor is smaller than KVM/QEMU. 2. Xen "dom0" = Linux/FreeBSD/OpenSolaris. KVM/bhyve also need host OS. 3. AMZN KVM-subset: x86 cpu/mem virt, blk/net via Arm Nitro hardware. 4. bhyve is Type-2. 5. Xen has Type-2 (uXen). 6. Xen dom0/host can be disaggregated (Hyperlaunch), unlike KVM. 7. pKVM (Arm/Android) is smaller than KVM…

I've been using xen in production for at least 18 years, and although there is been some development, it is extremely hard to get actual documentation on how to do things with it. There is no place documenting how to integrate the Dom0less/Hyperlaunch in a distribution or how to build infrastructure with it, at best you will find a github repo, with the last commit dated 4 years ago, with little to no information on…

> github repo, with the last commit dated 4 years ago

Some preparatory work shipped in Xen 4.19.

Aug 2024 v4 patch series [1] + Feb 2024 repo [2] has recent dev work.

> hard to get actual documentation

Hyperlaunch: this [3] repo looks promising, but it's probably easier to ask for help on xen-devel and/or trenchboot-devel [4]. Upstream acceptance is delayed by competing boot requirements for Arm, x86, RISC-V and Power.

dom0less: ELC2022 slides [5] and video [6].

[1] https://lists.xenproject.org/archives/html/xen-devel/2024-08... [2] https://github.com/FidelisPlatform/xen

[3] https://github.com/apertussolutions/initrd-builder [4] https://groups.google.com/g/trenchboot-devel

[5] https://www.slideshare.net/StefanoStabellini/static-partitio... [6] https://www.youtube.com/watch?v=CiELAJCuHJg

Re: Why Oxide Chose Illumos

#148

Post by anonfordays »

dijit wrote: post #141
transpute wrote: post #10

> Xen: Large and complicated (by dom0) codebase, discarded for KVM by AMZN 1. Xen Type-1 hypervisor is smaller than KVM/QEMU. 2. Xen "dom0" = Linux/FreeBSD/OpenSolaris. KVM/bhyve also need host OS. 3. AMZN KVM-subset: x86 cpu/mem virt, blk/net via Arm Nitro hardware. 4. bhyve is Type-2. 5. Xen has Type-2 (uXen). 6. Xen dom0/host can be disaggregated (Hyperlaunch), unlike KVM. 7. pKVM (Arm/Android) is smaller than KVM…

Honestly, SMF is superior to SystemD and it’s ironic it came earlier (and, that shows based on the fact that it uses XML as its configuration language.. ick). However, two things are an issue: 1) The CDDL license of SMF makes it difficult to use, or at least that’s what I was told when I asked someone why SMF wasn’t ported to Linux in 2009. 2) SystemD is it now. It’s too complicated to replace and software has become…

>Honestly, SMF is superior to SystemD

Maybe 15 years ago, not by a mile now. systemd surpassed SMF years ago and it's not even close now. No one in their right mind would pick SMF over systemd in 2024.

Re: Why Oxide Chose Illumos

#149

Post by cthalupa »

anonfordays wrote: post #138
cmeacham98 wrote: post #135

Earlier quoted context omitted.

> The big three all use KVM now. This isn't true - Azure uses Hyper-V ( https://learn.microsoft.com/en-us/azure/security/fundamental... ), and AWS uses an in-house hypervisor called Nitro ( https://aws.amazon.com/ec2/nitro/ ).

>This isn't true - Azure uses Hyper-V I thought Azure was moving/moved to KVM for Linux, but I was wrong. >AWS uses an in-house hypervisor called Nitro Nitro uses KVM under the hood.

Nitro does not use QEMU or many other parts traditionally used with KVM, however.

https://www.brendangregg.com/blog/2017-11-29/aws-ec2-virtual...

Re: Why Oxide Chose Illumos

#150

Post by cthalupa »

transpute wrote: post #10

> Xen: Large and complicated (by dom0) codebase, discarded for KVM by AMZN 1. Xen Type-1 hypervisor is smaller than KVM/QEMU. 2. Xen "dom0" = Linux/FreeBSD/OpenSolaris. KVM/bhyve also need host OS. 3. AMZN KVM-subset: x86 cpu/mem virt, blk/net via Arm Nitro hardware. 4. bhyve is Type-2. 5. Xen has Type-2 (uXen). 6. Xen dom0/host can be disaggregated (Hyperlaunch), unlike KVM. 7. pKVM (Arm/Android) is smaller than KVM…

> Is this an argument for Illumos over Linux, or for translating SMF to Linux?

I'd certainly like that! I had spent some time working with Solaris a lifetime ago, and ran a good amount of SmartOS infrastructure slightly more recently. I really enjoyed working with SMF. I really do not enjoy working with the systemd sprawl.

I will note the distinction between type-1/type-2 hypervisors never really made sense, and makes even less sense today. http://blog.codemonkey.ws/2007/10/myth-of-type-i-and-type-ii...

Post reply on HN