| |
| ▲ | stonogo 5 hours ago | parent [-] | | After reading that document twice, I'm still not sure why they based it on Illumos. I strongly suspect it's just down to the personal preference of the founders, which is a perfectly valid reason. This document very much reads like "here are the pieces we will use, let's work our way back to why" | | |
| ▲ | ironhaven 2 hours ago | parent [-] | | The reasoning can be simplified to two things.
1. Linux does not have the bhyve hypervisor ported
2. Maintaining a Linux distribution will require more effort and have more churn than illumos. Because Linux is just a kernel and users have to provide all of their own user space and system services there is a lot of opportunity for churn. Illumos is a traditional operating system that goes from the kernel to the systemd layer. Illumos is also very stable at this point so most of the churn is managed up front The choice is between porting a handful of apps to illumos or jumping on to the Debian treadmill while pioneering a new to Linux hypervisor. Would Linux have enabled a faster development cycle or just a easier MVP? | | |
| ▲ | stonogo an hour ago | parent [-] | | There's no churn in a graveyard, either. Debian's not much of a treadmill on stable; it's famous for it. The justifications for bhyve over kvm are similarly inscrutable; you can simply not build the code you don't want. Nobody's forcing you to use shadow paging. Comments like "reportedly iffy on AMD" are bizarre. What does "iffy" mean? This wasn't worth testing? Why should I, a potential customer, believe that these people are better at this than the established companies who have been producing nearly-identical products for twenty years? At the domain of development they're discussing why bother using an x86_64 processor from a manufacturer who does not bother to push code into the kernel you've chosen? Again, it's their company, and if they (as I suspect) chose these tools because they're familiar, that's a totally supportable position. I just can't understand why we get handwaving and assurances instead of any meat. | | |
| ▲ | bcantrill 29 minutes ago | parent [-] | | You may disagree with our rationale, but it is absolutely absurd to complain that that RFD 26[0] does not have "any meat." This is in fact dense technical content (10,000+ words!), for which I would expect a thorough read to take on the order of an hour. Not that I think you read it thoroughly: you skimmed to parts, perhaps -- but certainly glossed over aspects that are assuredly not your domain of expertise (or, to be fair, of interest to you): postmortem debuggability, service management, fault management, etc. These things don't matter to you, but they matter to us quite a bit -- and they are absolutely meaty topics. Now, in your defense, an update on RFD 26 is likely merited: the document itself is five years old, and in the interim we built the whole thing, shipped to customers, are supporting it, etc. In short, we have learned a lot and it merits elucidating it. Of course, given the non-attention you gave to the document, it's unlikely you would read any update either, so let me give you the tl;dr: in addition to the motivation outlined in RFD 26, there are quite a few reasons -- meaty ones! -- that we didn't anticipate that give us even greater resolve in the decision that we made. [0] https://rfd.shared.oxide.computer/rfd/0026 |
|
|
|
|
