Nah, if they were using can't and still are using VMware, is because they are terrified of any new product and wild be afraid of a salesman offering anything new.

Now any company entertaining *starting* to use VMware, now those are the folks you have a good chance of suckering coming in cold.

I'm not sure that I'd consider vCenter to look more sophisticated than vCenter, just different. I will say that at least once the WebUI got a VM into a state it didn't understand how to come back from, and had to log in and directly run a qemu command, which would probably be a deal breaker for a vmware shop, but it *looked* fine at least.

I'd say the distinction between 'dedicated ESXi hypervisors' versus 'full Debian' is actually a bit arbitrary, ESXi is a 'full OS', just VMWare wants to pretend very hard that it isn't. I consider it an asset to be flexible, but I could see how someone could see it as a bad thing because someone could get 'adventurous' and get in over their head by messing directly with the environment too much.

The API continues to be pretty direct about the parts of the solution, without any abstraction so you still must treat LXC *very* different from VMs, but on the other hand they are very different, and VMWare API doesn't even have a model for dealing with containers, so it's not a point of comparison. Based on my vmware api experience, should they add something like LXC containers for some reason, it would be abstracted like crazy, but also fail to be consistent with VM abstraction anyway.

So VirtualBox is akin to VMWare Workstation, which is about as free as VirtualBox, both with parent companies that I wouldn't personally trust to keep the bargain, though VMWare is a lot more in flux now than VirtualBox. Broadly speaking, no business cares about desktop virtualization except *maybe* as an on-ramp to infrastructure virtualization.

FreeBSD Jails are in the neighborhood of containerization. While VMWare has tried to pretend to be relevant, they really aren't to that. That isolation is of course much more lightweight and manageable compared to trying to do something similar with virtualization. However some contexts are served better by a full fledged virtualization.

KVM is a low level implementation detail, that is important but not really the level that folks would consider competing with 'VMware'. You have libvirt based management stacks (ovirt, which should be pretty much considered abandoned), openshift (which is first and foremost a container platform, but RedHat kind of sort of trumpets the fact you can run QEMU as a container in it, a bit 'weird' for a vmware user), or openstack (not personally a fan, a bit chaotic and ultimately not a solid experience). You also have things like just using virsh from command line, virt-manager from gui, or cockpit over web to manage virtual machines, which can capably compare with using ESXi as a standalone thing.

Probably the closest in nature to 'vCenter' I've seen is ProxMox VE. Simple and to the point to deploy (unlike most of the other multi-node virtualization stacks) and sidesteps libvirt (which in the fullness of time has kind of constrained stacks built on it as qemu has grown up).

Oracle entered the lead decades ago...

Or if it's pissing everyone off the fastest, they are near the bottom as people are already as pissed off as they could get, there is no pissing further off.

Well, *duh*, if you could have SSD for the same cost as magnetic drives then of course everyone would want them.

Joke can be on you though, you didn't say SSD, you said NVMe. So there is a concept of a spinning disc with an NVMe interface, since it's increasingly weird to bother with SAS/SATA when PCIe interfaces are more and more prolific, including switch chips taking the role of things like SAS expanders. So it may well be that you can get slow disks that are, technically, NVMe drives.

Yarrr

Maybe you mis typed or omitted something and didn't realize it? He quoted you directly: "Also it's not been very successful so it makes sense to roll it into the Android project." His reading of your comment was pretty straightforward.. My best guess is you meant it wasn't successful at being any more minimalist than Android, since it had Android runtime, you might have had to sweat local storage, and you had ability to run full on debian in container. They got the 'drawbacks' of Android while still being awkwardly 'almost Android'. But that's making a leap because there wasn't an explicit link between the thoughts.

Note that he describes only 5% of submissions as legitimate security issues and only 20% as AI slop, leaving still 75% of the submissions human slop.

Curl has long been one of the projects unafraid to highlight the mess of the "security research" ecosystem. Very good and solid work is drowned out by people fishing for vulnerabilities to pad their resume. A lot of bogus stuff gets CVEs, and even if by some chance MITRE is surprisingly stingy with giving a CVE, there are third party companies that will issue "advisories" that some organizations treat the same as CVEs.

So the AI slop certainly exacerbates the problem, but the broader security industry does have some deep issues with spewing so much stuff that it's very difficult to know whether to take a "finding" seriously or not.

Think that's likely pretty much the plan. They have added desktop mode and blessed ways of running Linux containers to Android, and with that they've pretty much caught up with the things ChromeOS could do that you typically didn't see happen in Android.

ChromeOS was already "barely enough Linux to run a web browser" with just the most crappy minimalist window management and a concession to let you run Linux applications in a container.

So compared to the typical android experience, you have a lack of Window management (but Android does have a desktop mode with ChromeOS level window management, which isn't much) and container execution (which Google has added to Android in the AVF thing they have been spouting.

This actually makes a ton of sense the only thing that didn't make sense was how long they tried to keep ChromeOS and Android separate.

I've seen it a lot in games that aspire to look 2D-ish. They seem to think it looks quaint and human.

You see it in pre-rendered 3D animation content a lot too, which isn't trying to hide bad performance, since the rendering isn't real time either. The spider man movie being a prime example of this "some choppy animation as an artistic choice" sensibility.

It's a common style nowadays, like some sort of counter reaction to the change from hand drawn animation to 3D animation, where the software could fill in between keyframes and be effortlessly smooth.

I've seen a fair argument that smooth is not necessarily better, that human choice in the animation allows the animator to decide which frames linger a bit and which frames move on. For example in a fast paced action sequence letting some frames linger to give the viewer a chance to see what happens.

However the response seems to be to just animate at a lower rate all the time, which I personally don't think is better but it is stylistically consistent with a fair amount of modern games and animation.

You have to get a feel for when it's utterly useless and when it's got a good chance of success. You also have to have a different vigilance as the LLM will make mistakes unlike what humans will do. My experience is it can be a modest time save but only because I've learned to ignore it for most of my work. Occasionally neat completion, very very rarely generating useful snippets from prompts, and ability to generate doc strings that no one will probably read anyway. Utterly asinine at trying to write comments, documenting the self evident tediously and skipping commenting anything that actually could use it. One example is if I write a little command line utility using variables that make sense to me it's decent at seeing the uninitialized variables and generating a chunk of argument parsing code including decent staff help text based on the observed variables

When all is said and done, if AI convinces management I don't need the diploma mill outsourced code slinger from the lowest bidder, I come out ahead even if I never even use the AI at all.

An example where the business case is at odds with the best situation for the user.

The ideal would be a local hub that can easily provide local area "app" connectivity, with ability to work with a DNS provider, Let's encrypt, and the relevant firewalls to let it have it's own port. Regrettably every member of the industry has steered explicitly away from making this interoperable. Upnp was designed to faciltate asking for real ports, but generally considered insecure and disabled with no standardized authenticated way to do the same. We basically didn't create an ecosystem capable, because it being anti-revenue.

The money is on the side of client being a dumb slave to vendor curated internet services that happen to also let them hold your device hostage for a subscription fee.

Home Assistant Green is the closest to enable it, but you get to own having to see if the devices are willing to work with it but without cloud and you get to own the task of getting it a port going to it from the internet, it's a piece in an ecosystem that's barely willing to accommodate the use case.

Just dealt with some nest thermostats. Hate their design.

Much prefer the "Sensi" thermostats, but the ones that still have HomeKit since those can be onboarded onto a LAN without internet (and even without an Apple Device). However they seem to have decided to discontinue HomeKit in their newer models, so I won't touch them either.