Letting licensing alone, I think they have a couple of killer reasons to choose Illumos: It's a fine operating system, and it's much easier for them to land the fixes/features they need on the Illumos kernel than if they've built on Linux.
Why Oxide Chose Illumos
161–170 of 177 posts
Re: Why Oxide Chose Illumos
#162Earlier 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…
> The more reasonable assertion is that it takes good people to get good results regardless of the quality of the tool.
> Acolytes are uncomfortable saying this because it also destroys the negative case, which is, it would be impossible to write quality software in a previous generation language.
Not impossible, just a lot harder. It's as if you're thinking in equations that are true/false, while I'm thinking in statistical distributions.
Have you used Macintosh System 5? How about Windows 3.1? Those were considered quality systems at the time, but standards are up, way up since then.
Why are modern systems better? Is it because we have better developers today? -- I don't think so. It took a "real" programmer to write quality apps in Pascal for early Macintosh systems, or apps in C for Windows 3.1.
I think the difference is in the tooling that is available to us -- and modern programming languages (and libraries) are surely a very large part of that tooling.
If you disagree, I challenge you to find a seasoned modern desktop app developer who can write a high-quality app for MacOS or Windows that looks and functions great by modern standards and doesn't use any modern languages or directly invoke any non-vendor libraries built after the year 2000. It's possible[0]. They may be able to do it, but you must certainly concede that doing a great job requires a much better developer than the average modern desktop app developer to be able to work well under those kinds of constraints.
That's what I mean by "raising the floor" -- all software gets better when languages, libraries, and tooling improve.
[0] https://stackoverflow.com/questions/30269329/creating-a-wind...
Re: Why Oxide Chose Illumos
#163Because CTO Bryan Cantrill, who was a core contributor to illumos
[deleted]
Re: Why Oxide Chose Illumos
#164Earlier quoted context omitted.
Those are not the only options. You can have KVM on Illumos, or Bhye on FreeBSD. And finding people to heir that know Linux/KVM wouldn't be a problem for them. This evaluation was done years ago and they added like 50 people since then. Saying 'We have a great KVM Team but our CEO was once an Illumos developer' is perfectly reasonable. And as I point out in my other comment, the former Joyant people like know more ab…
> "Buy our KVM Solution, we have KVM experts" Of course, but that is less of unique selling point. > But they evaluated that Bhyve was better then KVM despite that. If you are selling Bhyve you better say that whether it's true or not. So why should I, as a reader or employee or customer, trust them?
> Of course, but that is less of unique selling point.
Who cares about uniqueness? That's not a goal.
> If you are selling Bhyve you better say that whether it's true or not. So why should I, as a reader or employee or customer, trust them?
They are not selling Bhyve. This is an internal document. Their costumers don't care about the implementation details. And if they do, then they will do their own evaluation based on their own evaluation.
As an employee you trust it because you know how the company heirs and who wrote these RFDs.
As a reader, its literally like any other thing on the internet.
Re: Why Oxide Chose Illumos
#165Earlier quoted context omitted.
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.
1. Oxide made an unproven statement ("QEMU is often the subject of bugs affecting its reliability and security.") 2. OP (bonzini) has given specific and valid arguments that that statement is wrong. 3. You're not answering to that specific arguments, but defending Rust and bashing C++ generally without giving any prove. 4. bonzini again provides specific arguments that your generalization is not correct in that conte…
You're right on (1) and (2) - Oxide used weasel words when explaining the decision. My point is that their poor explanation doesn't necessarily mean it was the wrong decision. A bad defense attorney doesn't imply the defendant committed the crime.
I'm not bashing C++ beyond saying "any sufficiently large codebase originally written in C or C++ has memory safety bugs". I did not say those bugs are exploitable, just that they're present.
I'm also not insisting Rust is superior, except to say that it raises the floor of software quality, because it nearly eliminates a class of memory safety bugs.
Do you disagree? Neither of those statements implies C++ sucks or that Rust is awesome. Just 2 important data points (among many others) to consider in whatever context you're writing code in.
Re: Why Oxide Chose Illumos
#166Re: Why Oxide Chose Illumos
#167Earlier quoted context omitted.
Oracle is a $53 billion company, and never had a mass exodus, just less greenfield deployments. Broadcom also isn't all that dumb, VMware was fat and lazy and customers were coddled for a very long time. They've made a bet that it's sticky. The competition isn't as weak as they thought, that's true, but it will take 5+ years to catch up, not 2 years, in general. Broadcom was betting on it taking 10 years: plenty of t…
I don’t disagree much. Still, there’s a sudden weakening of the main incumbent in the on-prem virtualization market… and that is _all_ Oxide does. It will be interesting to see whether Oxide can convert some VMWare customers.
Oxide is a moonshot, it requires companies to fire a lot more suppliers than VMware. Which is easier said than done. A lot will depend on if Oxide can find their early niches: they're a long play (years) before they crack the mainstream or are truly competitive with, say, VCF on VxRail, for the average talent ops team. Long run it's clearly going to be better, but short run they have to pick their battles.
Re: Why Oxide Chose Illumos
#168Earlier 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…
> The more reasonable assertion is that it takes good people to get good results regardless of the quality of the tool.
That's totally true, and I never contradicted that.
By "ceiling" I mean the limit of what is possible. A great team can do a lot more when they have great tools.
Re: Why Oxide Chose Illumos
#169Earlier 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.
[flagged]
Re: Why Oxide Chose Illumos
#170Earlier 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.
>Can you point me to both of:
>* why it's considered low quality
>* evidence of this "wide regard"