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

51–60 of 177 posts

Re: Why Oxide Chose Illumos

#51

Post by bonzini »

TimTheTinker wrote: post #48
bonzini wrote: post #5

> QEMU is often the subject of bugs affecting its reliability and security. {{citation needed}}? When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. Here's a talk I gave about it that includes that analysis: slides - https://kvm-forum.qemu.org/2019/kvm…

> When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. So there existed known guest-exploitable vulnerabilities as recently as 8 years ago. Maybe that, combined with the fact that QEMU is not written in Rust, is what is causing Oxide to decide against QEMU. I think it's fair to say that any sufficiently large codebase originally…

That would be a damn good record though, isn't it? (I am fairly sure that more were found since, but the point is that these are pretty rare). Firecracker, which is written in Rust, had one in 2019: https://www.cve.org/CVERecord?id=CVE-2019-18960

Also QEMU's fuzzing is very sophisticated. Most recent vulnerabilities were found that way rather than by security researchers, which I don't think it's the case for "competitors".

Re: Why Oxide Chose Illumos

#52

Post by InvaderFizz »

bonzini wrote: post #43
jclulow wrote: post #37

Earlier quoted context omitted.

FWIW, founder mode didn't exist five years ago when we were getting started! More seriously, though, this document (which I helped write) is an attempt specifically to avoid classic FUD tropes. It's not perfect, but it reflects certainly aspects of my lived experience in trying to get pieces of the Linux ecosystem to work in production settings. While it's true that I'm a dyed in the wool illumos person, being in the…

Founder mode existed, it just didn't have a catchy name. And I absolutely believe that it was the right choice for your team, exactly for "founder mode" reasons. In other words, I don't think that the social or technological reasons in the document were that strong, and that's fine . Rather, my external armchair impression is simply that OS and hypervisor were not something where you were willing to spend precious "r…

I would agree with that. Given the history of the Oxide team, they chose what they viewed was the best technology for THEM, as maintainers. The rest is mostly justification of that.

That's just fine, as long as they're not choosing a clearly inferior long term option. The technically superior solution is not always the right solution for your organization given the priorities and capabilities of your team, and that's just fine! (I have no opinion on KVM vs bhyve, I don't know either deep enough to form one. I'm talking in general.)

Re: Why Oxide Chose Illumos

#53

Post by kayo_20211030 »

Is the date on this piece correct?

The section about Rust as a first class citizen seems to contain references to its potential use in Linux that are a few years out of date; with nothing more current than 2021.

> As of March 2021, work on a prototype for writing Linux drivers in Rust is happening in the linux-next tree.

Re: Why Oxide Chose Illumos

#54

Post by kayo_20211030 »

kayo_20211030 wrote: post #53

Is the date on this piece correct? The section about Rust as a first class citizen seems to contain references to its potential use in Linux that are a few years out of date; with nothing more current than 2021. > As of March 2021, work on a prototype for writing Linux drivers in Rust is happening in the linux-next tree.

nm, I read the postscript. The RFD was from 2021. I wonder how correct it was, and whether decisions made, based on it, were good ones or bad ones.

Re: Why Oxide Chose Illumos

#55

Post by specialist »

panick21_ wrote: post #21
ReleaseCandidat wrote: post #16

Instead of stating more or less irrelevant reasons, I'd prefer to read something like "I am (have been?) one of the core maintainers and know Illumos and Bhyve, so even if there would be 'objectively' better choices, our familiarity with the OS and hypervisor trump that". A "I like $A, always use $A and have experience using $A" is almost always a better argument than "$A is better than $B because $BLA", because that…

But Bryan also ported KVM to Illumos. And Joyand used KVM and they supported KVM there for years, I assume Bryan knows more about KVM then Bhyve as he seemed very hands on in the implementation (there is nice talk on youtube). So the idea that he isn't familiar with KVM isn't the case. So based on that KVM or Bhyve on Illumos, KVM would suggest itself. In the long term if $A is actually better then $B, then it makes…

> Trying to be objective about this... And writing it down also seems smart.

Mosdef.

IIRC, these RFDs are part of Oxide's commitment to FOSS and radical openness.

Whatever decision is ultimately made, for better or worse, having that written record allows the future team(s) to pick up the discussion where it previously left off.

Working on a team that didn't have sacred cows, an inscrutible backstory ("hmmm, I dunno why, that's just how it is. if it ain't broke, don't fix it."), and gatekeepers would be so great.

Re: Why Oxide Chose Illumos

#56

Post by TimTheTinker »

bonzini wrote: post #51
TimTheTinker wrote: post #48

Earlier quoted context omitted.

> When I ran the numbers in 2019, there hadn't been guest exploitable vulnerabilities that affected devices normally used for IaaS for 3 years. So there existed known guest-exploitable vulnerabilities as recently as 8 years ago. Maybe that, combined with the fact that QEMU is not written in Rust, is what is causing Oxide to decide against QEMU. I think it's fair to say that any sufficiently large codebase originally…

That would be a damn good record though, isn't it? (I am fairly sure that more were found since, but the point is that these are pretty rare). Firecracker, which is written in Rust, had one in 2019: https://www.cve.org/CVERecord?id=CVE-2019-18960 Also QEMU's fuzzing is very sophisticated. Most recent vulnerabilities were found that way rather than by security researchers, which I don't think it's the case for "compet…

You're not wrong, and that is very impressive. There's nothing like well-applied fuzzing to improve security.

But I still don't think that makes Oxide's decision or my comment necessarily invalid, if only because of an a priori decision to stick with Rust system-wide -- it raises the floor on software quality.

Re: Why Oxide Chose Illumos

#58

Post by Aissen »

Point 1.1 about QEMU seems even less relevant today, with QEMU adding support for the microvm machines, hence greatly reducing the amount of exposed code. And as bonzini said in the thread, the recent vulnerability track record is not so bad.

Re: Why Oxide Chose Illumos

#59

Post by gyre007 »

sausagefeet wrote: post #8
gyre007 wrote: post #6

Earlier quoted context omitted.

Yeah I came here to say that Bryan worked at Sun so why do they even need to write this post (yes, I appreciate the techinical reasons, just wanted to highlight the fact via a subtle dig :-))

This isn't a blog post from an Oxide, it's a link to their internal RFD which they use to make decisions.

I never said it was a post by Oxide.

Re: Why Oxide Chose Illumos

#60

Post by dcre »

crb wrote: post #19
saagarjha wrote: post #14

Unrelated, but is this a homegrown publishing platform?

Yes; it's referred to in Oxide's RFD about RFDs [1] https://rfd.shared.oxide.computer/rfd/0001 but the referenced URL is 404 unless you're an Oxide employee. [1] https://rfd.shared.oxide.computer/rfd/0001#_shared_rfd_rende... [2] https://github.com/oxidecomputer/rfd/blob/master/src

That link is out of date. The site and backend are now open source. Only the repo containing the RFD contents is private.

https://github.com/oxidecomputer/rfd-site

https://github.com/oxidecomputer/rfd-api

Post reply on HN