The one escape out of FreeBSD jails that I'm aware of (CVE-2005-2218) involved not a bug in the jails code, but by burrowing out via devfs.
So it seems that OS-level virtualization/security has a better track record.
The story of the BSDs and illumos is really a tragedy about the complete and total disconnect between technical quality+value and technology adoption. People utilize technology products as fashion statements first and foremost, and the Linux fashion was easily the most desirable -- indeed, aside from PC v. Mac, it's the only one generally known by average technophiles.
As a technical entrepreneur, I've discovered the sad reality that it's really only the most superficial 10% of any functionality that drives virtually all adoption. Everything else is marketing, even in supposedly heavily-technical endeavors like running an open-source kernel. The more you invest in engineering beyond that initial superficial component, the less you have to invest in brand promotion.
One can choose to gratify their own sense of righteousness and ignore this, and that is certainly a valid option to take, but then they shouldn't be surprised to see their lunch eaten by someone who took the other side of the bargain.
Linux have 18 millions lines of code in drivers. It can run on almost any chip/architecture. Distributions are fully featured and most of the things you can imagine have first class support.
I do not care how beautiful is architecture of BSD kernel if I cannot run my code on it.
It's true that tech has a popularity-breeds-popularity effect, but I don't think it's mainly fashion (at least, for industrial use of tech like PLs used commercially), but network effects around available knowledge and skilled users.
Abstract technical superiority often isn't a commercial win without reliable availability of people able to use it effectively at costs that make it efficient. There's situations where buying the limited knowledge pool, or paying to grow on house skill, is worthwhile, but often the “worse” solution that is well-known is better practically
That was true at one point in time (i.e., no known breakouts). I don't know if that is still true, and if it is not, when that breakout CVE was published.
There is still a great deal of administrative/technical value in using anything-but-Docker if you can tolerate the social stigma, but who can? The CxOs need that Docker/Kubernetes feather in their cap so they can look cool at conferences.
Suggesting SmartOS/illumos gets you sideways looks at the very bare minimum. When I stated that I was thinking about using it here over a year ago, my inbox was immediately flooded with accusations that I was part of a Joyent-bankrolled cabal, because clearly no sane ordinary person would consider such a dead platform. In the interim, OmniTI has gone belly-up and OpenZFS has deemed ZFS on Linux the rightful heir to the ZFS throne, and now the Joyent Public Cloud is shuttering. If the impression that you had to be part of a conspiracy to use SmartOS for a greenfield project was reasonable then, it's only more reasonable now.
The sun may yet rise again on illumos some day, but it's time to accept that it's well into the night now.
There are also some really subtle Linux compatibility problems. For instance: IIRC a SmartOS malloc will not fail. Ever. But it might not return either. There's a really complicated mark/sweep type virtual memory thing and the documentation is good, for the nasty node stuff, and kinda terrible otherwise.
Finally, and with no lack of irony, you just can't run SmartOS on the cloud. For a start it needs to do its first boot off a CD and subsequent boots off a USB drive-type-arrangement. The hard part is that most cloud providers run a butchered Linux kernel and not a fully generalised VM - and on vultr at least, while they run a proper VM, for some reason the processors don't "come up".
I've not looked at all this stuff for at least a year so it may have changed. Either which way I believe the majority of the community is now on OmniOS - which I always got on better with anyway.
Actually I'd say the Triton install is not only trivial, but should be a model for other similar systems. During my testing with Intel NUCs, I had a usable system deploying containers in under 20 minutes. Most managed Kubernetes systems cannot even provision in that time frame.
> you just can't run SmartOS on the cloud.
The installer may lead you to the USB and install path, but it is not necessary. I built Vagrant boxes that had SmartOS on a regular disk, and I believe that more recently SmartOS has been running well in GCP. There is no reason it could not run in AWS or Azure, either.
when was the last time you used k8s?! I mean as of now there is even the expirmental k3os which boots a fully fledged k8s in seconds. you can even built a cluster with it. sadly HA backplane is still not available since k3s is still early in its development.
How many systems did you need to install Triton?
How much memory did(do) the individual systems running Triton have?
Which documentation did you follow to install Triton?
No it does not. I boot my SmartOS instances with PXE, DHCP and TFTP from the network. Served by a Solaris 10 intel server, no less. No CD's or USB images anywhere in sight.
In fact, I came up with a trifecta scheme where three SmartOS servers will all run TFTP and DHCP servers, thus being able to boot each other and all the other SmartOS servers over the network. In the event where all three would lose power simultaneously, THEN I reach for a USB stick with the emergency boot image. And I'll have two of those. But barring such catastrophic loss of power simultaneously, there won't be any CD's or USB sticks needed.
The network is the computer.
When you compared the utility of JCP "tiny" instance (1 CPU worth of shares, 256MB of RAM) to a t2.micro or similar instance in AWS, the difference was astounding. Part of this is the CPU credit mechanism on T2 instances, but I'd wager that a good part of it was being in OS-level virtualisation.
The main selling point is/was being closer to the hardware and thus getting better utilization. Virtualizing at the machine level was a lot slower (especially before Intel VT-x and AMD-V came along) and so one wouldn't lose (say) 30% right off the top:
* https://en.wikipedia.org/wiki/OS-level_virtualisation