Kill? no, definitively not. But 1) not adding a lot of extra and 2) applying the Pareto principle here are a huge difference. I.e. making the essential parts approachable enough to get one started while not being blocked too much by upfront (steep) learning curve, while not blocking one later by limiting one to just the predefined path.
> Anything touching SDN or clustered storage, in any ecosystem, will need dedicated in-house experts that know networking, storage, Linux and how Proxmox (or Kubernetes) approaches those domains.
There are widely different level of expertise needed though, and the setups that often are managed by admins with not in-depth expertise in clustering or SDN can still get things done with Proxmox VE, and if they are out of idea we got our enterprise support and naturally also the very active and friendly community forum to help.
> Unless you are just using Proxmox for small VM labs, in which case it ought to be compared with libvirt and standalone QEMU.
Yeah, I really do not get that point, you basically invalidate 95% of Proxmox VE's feature set because it might not be fully leveraged by a specific user group and because there are some different solutions that also allow one to do similar things. That would also invalidate Kubernetes, it's not completely unpopular in small labs either after all.
To be honest, to me, it feels a bit to me like a justification attempt for the initial post in this chain here that brushed off Proxmox VE as just some small UI/UX wrapper around QEMU/KVM and all the Real Work™ being done by others, possibly because you never actually used it, but I might read it the wrong way, and I'm certainly not offended in any way, just find it a bit odd.
My OP is more about promoting understanding of underlying VM technologies. Proxmox adds value, but also complexity of its own abstractions. QEMU and libvirt don't have salespeople trolling the internet to promote their use, so there is less awareness of what these core technologies are capable of.
Note that I'm neither a "sales people", nor is the one that made the original post, as that is Olaf from the Perl foundation, who reached out to me after I made a contribution to one of his Perl projects, if you must know. Tbh. I didn't even know that he would post this on some channels like here or reddit before getting pinged by a colleague that we were mentioned on the front page of HN.
And for a fact, I actually know (and enjoy!) several people from the QEMU and libvirt developer community actively posting on other sites comment sections, or is that now a bad thing too?
And FWIW, I tried several times to point out that QEMU itself is only a small part of what we provide–even if not, just providing a good API abstraction around that is significant work, especially if it should allow two decades (and counting!) of stable upgrade paths and _without_ libvirt. And we nowhere hide the underlying technologies, we're proudly building upon–and trying to give back–to all projects we use, be it Debian, QEMU/KVM, LXC (which we co-maintain), Linux kernel, FRR, rust, or–like here–Perl...
But as you're rather dismissive and now even start to call people trolling I hardly see any need to take your writings as serious discussion, they do not seem to be done in good faith, and IMO doing it this way certainly won't help to promote FLOSS, that should be possible without being dismissive to others work.
> Anything touching SDN or clustered storage, in any ecosystem, will need dedicated in-house experts that know networking, storage, Linux and how Proxmox (or Kubernetes) approaches those domains.
There are widely different level of expertise needed though, and the setups that often are managed by admins with not in-depth expertise in clustering or SDN can still get things done with Proxmox VE, and if they are out of idea we got our enterprise support and naturally also the very active and friendly community forum to help.
> Unless you are just using Proxmox for small VM labs, in which case it ought to be compared with libvirt and standalone QEMU.
Yeah, I really do not get that point, you basically invalidate 95% of Proxmox VE's feature set because it might not be fully leveraged by a specific user group and because there are some different solutions that also allow one to do similar things. That would also invalidate Kubernetes, it's not completely unpopular in small labs either after all.
To be honest, to me, it feels a bit to me like a justification attempt for the initial post in this chain here that brushed off Proxmox VE as just some small UI/UX wrapper around QEMU/KVM and all the Real Work™ being done by others, possibly because you never actually used it, but I might read it the wrong way, and I'm certainly not offended in any way, just find it a bit odd.