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

131–140 of 177 posts

Re: Why Oxide Chose Illumos

#131

Post by 6c696e7578 »

anonfordays wrote: post #80
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…

>Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. QEMU typically uses KVM for the hypervisor, so the vulnerabilities will be KVM anyway. The big three all use KVM now. Oxide decided to go with bhyve instead of KVM.

Azure uses hyper-v, unless things have changed massively, the linux they run for infra and customers is in hyper-v.

Re: Why Oxide Chose Illumos

#132

Post by inftech »

netbsdusers wrote: post #73
bonzini wrote: post #12

Earlier quoted context omitted.

Talking about "technological and political issues" without mentioning any, or without mentioning which components would need to be revived, sounds a lot like FUD unfortunately. Mixing and matching traditional and systemd components is super common, for example Fedora and RHEL use chrony instead of timesyncd, and NetworkManager instead of networkd.

> Talking about "technological and political issues" without mentioning any I don't know why you think none were mentioned - to name one, they link a GitHub issue created against the systemd repository by a Googler complaining that systemd is inappropriately using Google's NTP servers, which at the time were not a public service, and kindly asking for systemd to stop using them. This request was refused and the issue…

And people forget that this behavior of systemd devs is present in lots of other core projects of the Linux ecosystem.

Unfortunately this makes modern Linux not reliable.

Re: Why Oxide Chose Illumos

#133

Post by sophacles »

akira2501 wrote: post #129
TimTheTinker wrote: post #113

Earlier quoted context omitted.

I believe TypeScript and Rust are both strong examples of languages that do this (for different reasons and in different ways). It's also possible for a language to raise the ceiling of software quality, and Zig is an excellent example. I'm thinking of "floors" and "ceilings" as the outer bounds of what happens in real, everyday life within particular software ecosystems in terms of software quality. By "quality" I m…

> possible for a language to raise the ceiling of software quality Cargo is widely recognized as low quality. The thesis fails within it's own standard packaging. It's possible for a language to be used by _more people_ and thus raise the quality _in aggregate_ of produced software but the language itself has no bearing on quality in any objective measure. > to benefit from a raised ceiling You're explicitly putting…

> 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.

Re: Why Oxide Chose Illumos

#134

Post by sophacles »

otabdeveloper4 wrote: post #74
bonzini wrote: post #51

Earlier quoted context omitted.

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…

[flagged]

Why is it the only people who say this at all are people saying it sarcastically or quoting fictional strawmen (and can never seem to provide evidence of it being said in earnest)?

Re: Why Oxide Chose Illumos

#135

Post by cmeacham98 »

anonfordays wrote: post #80
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…

>Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. QEMU typically uses KVM for the hypervisor, so the vulnerabilities will be KVM anyway. The big three all use KVM now. Oxide decided to go with bhyve instead of KVM.

> 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/).

Re: Why Oxide Chose Illumos

#136

Post by akira2501 »

sophacles wrote: post #133
akira2501 wrote: post #129

Earlier quoted context omitted.

> possible for a language to raise the ceiling of software quality Cargo is widely recognized as low quality. The thesis fails within it's own standard packaging. It's possible for a language to be used by _more people_ and thus raise the quality _in aggregate_ of produced software but the language itself has no bearing on quality in any objective measure. > to benefit from a raised ceiling You're explicitly putting…

> 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 you can easily falsify this yourself. Or you could discover something you've been ignorant of up until now. Try "rust cargo sucks" as a search motif.

> random weirdos

Which may or may not be true, but you believe it, and yet you use your time to comment to us. This is more of a criticism of yourself than of me; however, I do appreciate your attempt to be insulting and dismissive.

Re: Why Oxide Chose Illumos

#137

Post by suprjami »

netbsdusers wrote: post #73
bonzini wrote: post #12

Earlier quoted context omitted.

Talking about "technological and political issues" without mentioning any, or without mentioning which components would need to be revived, sounds a lot like FUD unfortunately. Mixing and matching traditional and systemd components is super common, for example Fedora and RHEL use chrony instead of timesyncd, and NetworkManager instead of networkd.

> Talking about "technological and political issues" without mentioning any I don't know why you think none were mentioned - to name one, they link a GitHub issue created against the systemd repository by a Googler complaining that systemd is inappropriately using Google's NTP servers, which at the time were not a public service, and kindly asking for systemd to stop using them. This request was refused and the issue…

systemd made time servers a compile-time option and a warn if distros are using the default time servers:

https://github.com/systemd/systemd/pull/554

What's your suggested alternative?

Using pool.ntp.org requires a vendor zone. systemd does not consider itself a vendor, it's the distros shipping systemd which are the vendor and should register and use their own vendor zone.

I don't care about systemd either way, but your own false representation of facts makes your last paragraph apply to your "argument".

Re: Why Oxide Chose Illumos

#138

Post by anonfordays »

cmeacham98 wrote: post #135
anonfordays wrote: post #80

Earlier quoted context omitted.

>Pretty much every cloud outside the big three (AWS, GCE, Azure) runs on QEMU. QEMU typically uses KVM for the hypervisor, so the vulnerabilities will be KVM anyway. The big three all use KVM now. Oxide decided to go with bhyve instead of KVM.

> 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.

Re: Why Oxide Chose Illumos

#139

Post by bigfatkitten »

suprjami wrote: post #137
netbsdusers wrote: post #73

Earlier quoted context omitted.

> Talking about "technological and political issues" without mentioning any I don't know why you think none were mentioned - to name one, they link a GitHub issue created against the systemd repository by a Googler complaining that systemd is inappropriately using Google's NTP servers, which at the time were not a public service, and kindly asking for systemd to stop using them. This request was refused and the issue…

systemd made time servers a compile-time option and a warn if distros are using the default time servers: https://github.com/systemd/systemd/pull/554 What's your suggested alternative? Using pool.ntp.org requires a vendor zone. systemd does not consider itself a vendor, it's the distros shipping systemd which are the vendor and should register and use their own vendor zone. I don't care about systemd either way, but…

> What's your suggested alternative?

That if they do not wish to ship a safe default, they do not ship a default at all.

Re: Why Oxide Chose Illumos

#140

Post by suprjami »

bigfatkitten wrote: post #139
suprjami wrote: post #137

Earlier quoted context omitted.

systemd made time servers a compile-time option and a warn if distros are using the default time servers: https://github.com/systemd/systemd/pull/554 What's your suggested alternative? Using pool.ntp.org requires a vendor zone. systemd does not consider itself a vendor, it's the distros shipping systemd which are the vendor and should register and use their own vendor zone. I don't care about systemd either way, but…

> What's your suggested alternative? That if they do not wish to ship a safe default, they do not ship a default at all.

That would have been my preference too.
Post reply on HN