What problem does Oxide solve exactly?
The point of a startup is to disrupt the current market. And they are trying. Lets see how they do.
Does it matter? Oxide is building the whole stack - their own hardware with their own firmware to run their own OS with their own virtualization layer. They don't need support for arbitrary devices, because they control the hardware.
tl;dr: Smaller players are able to do things that larger players can't -- which isn't to minimize how challenging it currently is!
Moore's Law has been dead for a while. Getting "performance" now requires design and architecture again rather than just sitting back for 18 months and letting Moore's Law kill your competitor.
The big problem right now is that custom chip hardware is still too stupidly expensive because of EDA software. Fab runs are sub $50K, but EDA software is greater than 100K per seat and goes up rapidly from that.
Yes, actually, you do.
The "interesting" bits in chip design aren't the digital parts--the interesting bits are all analog.
A RISC core is an undergraduate exercise in digital design and synthesis in any HDL--even just straight Verilog or VHDL. It's a boring exercise for anyone with a bit of industry experience as we have infinite and cheap digital transistors. (This is part of the reason I regard RISC-V as a bit interesting but not that exciting. It's fine, but the "RISC" part isn't where we needed innovation and standardization--we needed that in the peripherals.)
However, the interfaces are where things break down. Most communication is now wireless (WiFi, BLE, NB-IoT) and that's all RF (radio frequency) analog. Interfacing generally requires analog to digital systems (ADCs and DACs) and those are, obviously, analog. Even high-speed serial stuff requires signal integrity and termination systems--all of that requires parasitic extraction for modeling--yet more analog. And MEMS are even worse as they require mechanical modeling inside your analog simulation.
If your system needs to run on a coin cell battery, that's genuinely low power and you are optimizing even the digital bits in the analog domain in order to cut your energy consumption. This means that nominally "digital" blocks like clocks and clock trees now become tradeoffs in the analog space. How does your debugging unit work when the chip is in sleep?--most vendors just punt and turn the chip completely on when debugging but that screws up your ability to take power measurements. And many of your purely digital blocks now have "power on/power off" behavior that you need to model when your chip switches from active to sleep to hibernate.
All this is why I roll my eyes every time some group implements "design initiatives" for "digital" VLSI design--"digital" VLSI is "mostly solved" and has been for years (what people behind these initiatives are really complaining about is that good VLSI designers are expensive--not that digital VLSI design is difficult). The key point is analog design (even and especially for high performance digital) with simulation modeling along with parasitic extraction being the blockers. Until one of these "design initiatives" attacks the analog parasitic extraction and modeling, they're just hot air. (Of course, you can turn that statement around and say that someone attacking analog parasitic extraction means they are VERY serious and VERY interesting.)
Having "infinite and cheap" transistors is what makes hardware design not boring. It means designs in the digital domain are now just as complex as the largest software systems we work with, while still being mission-critical for obvious reasons (if the floating point division unit you etched into your latest batch of chips is buggy and getting totally wrong results, you can't exactly ship a software bugfix to billions of chips in the field). This is exactly where we would expect shifting to higher-level languages to be quite worthwhile. Simple RISC cores are neither here nor there; practical multicore, superscalar, vector, DSP, AI etc. etc. is going to be a lot more complex than that.
Complicated analog stuff can hopefully be abstracted out as self-contained modules shipped as 'IP blocks', including the ADC and DAC components.
What would the hosting story look like now if 8(?) years ago 25% of servers had adopted SmartOS?
I never used it in production anywhere, admittedly. I also never got a chance to try out Triton. I'm on the fence about whether or not I keep my SmartOS hosts in my home network now that Illumos is a second-class citizen when it comes to OpenZFS.
The case with OpenZFS does worry me as well. I fear the developers start slowly introducing linuxisms thus sacrificing portability and stability for the great penguin.
I would love to hear more about the replacement of VMware experience and any other Triton details good/bad.
Generally there hasn't been anything game breaking and our biggest issues have been with running out of logging space for the core services (went with too low capacity disks in the beginning, doh) and one failed upgrade which didn't even take down the whole cluster during fixing. Our clients can now also provision their own VMs with the Triton API unlike with VMware which required admins to do it. Bhyve like KVM before has also been rock solid in everything we run from simple web servers to kubernetes clusters.
For issues we've found the Joyent/SmartOS IRC channels to be excellent and they have helped us tremendously in debugging and fixing things. It's the best support I've encountered for a FOSS product by far and one of the biggest reasons I'm such an illumos advocate now.
I'm also looking forward to further testing LinuxCN (https://github.com/joyent/linux-live/tree/linuxcn) on Triton in the near future!
Are you running Manta (https://github.com/joyent/manta) for anything? If so, is that meeting you needs for object storage?
Not sure about linuxCN either. I would rather run !linux on bare metal as much as possible, and having purged most of the penguins from infrastructure it would feel a bit weird to go immediately back ;)
In addition, we also have SPARC hardware running on OpenBSD due great hardware support, including ldoms! Of course would be nice to run illumos on them too, but alas...