Oh? I just tried to get one with the instructions on their github page, and it said the box type was vbox. Are the vmware versions kept elsewhere?

Where can I find the page which guarantees me that any given version of any given package will be fully supported by a defined security team for security fixes for at least 2 years from release, preferably 3+?

That is my argument against using Gentoo. I have absolutely no idea how long any given piece of it will be supported. If you can point me to a resource which explains that, I might take another look.

I also have no interest in picking and choosing packages out of a bucket - I want a stable, well-defined OS that I can build on, and preferably one which is as close to what everyone else is using as possible so I can ask for help from people who understand my OS.

Yes, it might work out if you're running at scale, have specialised needs, and can dedicate resources to what essentially amounts to development of a forked distro. It doesn't work out for me, as I need to know that the system I'm building isn't going to be unsupported in a couple of months, and I need to know I can talk to someone who is running similar versions of everything I'm running if everything goes wrong.

There are certainly environments where enterprisey vendor testing and certification makes sense; mostly small or heterogeneous environments. But at large scale it's cheaper to do stuff yourself.

Also, CoreOS has more of a read-only stateless philosophy, so I think it'd still be interesting even if it ends up having to duplicate a lot of effort from mainstream distros.

That would have been a problem with every new distribution, including RHEL and Debian when they were brand new. In reality, your SAN should be able to accommodate a generic Linux kernel with any userland you can containerize.

I'm not sure how else to respond to "let's reinvent a complete Linux distribution because we've written a 20 line auto-updater".

This would have made sense to me a decade ago, but back then I just wouldn't have understood the amount of work involved. You simply cannot produce a fully generalized container OS without producing a fully generalized OS.

That aside, I actually like the central idea of a better approach to managing/updating a large group of host machines. I just don't think it warrants yet another bikeshedded support/security/certifiability nightmare (and lets face it, this is bikeshedding, there's absolutely no value in the core claim of "it's just Linux", but it gives unfettered license to reinvent the same old wheels all over yet again).

Just wanted to add something to this thread, which has not been mentioned yet. Sure, most (if not all) SANs are supported vie generic linux kernel drivers for HBAs, something like a QLogic card, or an exported iSCSI LUN. The issue is that you spent tons of money on the SAN and a truck load of money on hardware and software to hook up to that SAN. So you want to have a vender supported OS to go along with these items. If you have performance issues or stability issues, the first things a vender will ask is, what OS are you running, so they can direct you to the correct support group. The support group will want to debug the issue, so you have to generally run something like RHEL or Windows to get support. This might only be a mega corp issue though, since most startups don't have Oracle/Sybase, fiber channel SANs, etc. To sum this up, in the mega corp world, if you are not running a vender supported OS, you likely cannot get support for your device.