There are two ways to run the Libvirt daemon, which are unprivileged and privileged aka system. You are using unprivileged mode, the parent is using system mode which is more powerful and provides better isolation but does hide stuff in /var.
For example, running QEMU as its own user and using PCI passthrough is only possible with the system daemon.
You also need the system daemon to set up bridged networking, though the unprivileged daemon can use it through a setuid helper.
Red Hat is still using and developing libvirt (though the user facing layer is Kubevirt instead of oVirt) and virt-install, and even though virt-manager is not growing new features libvirt takes backwards compatibility extremely seriously, so new libvirt works with relatively old virt-manager.
Maybe, or maybe there is no yacht and no 2 star restaurant. Since your profile doesn't have any personal info (which is certainly your right, mind) I have only one data point and it tilts towards the latter.
On POWER, LPARs and the first level of hypervisor do not use any LPAR-specific nesting support in the processor. It's all handled by the firmware, not the hardware.
If you're a cloud provider, it's all hands on deck.
For everyone else it's dangerous enough to look seriously at getting an updated kernel or apply mitigations, especially since those are easy (disable nested virtualization, only requires restarting guests). Note that this is true even if you're not running guests, having a user running untrusted code and with access to /dev/kvm is enough.
If you're not running anything untrusted, you probably won't be affected but probably should still look at getting an updated kernel or apply mitigations.
It's the worst class of vulnerabilities for KVM in many years (this is the third variant, after CVE-2026-23401 which is a bit different and not guest teiggerable, and 46113 which I have already mentioned and is basically the same bug as this one), on the other hand it also says something about KVM that nothing similar was found in so many years. It's interesting that while this one was found with AI the first two were found with old school (albeit very sophisticated) fuzzing.
The initial definition of the meter would have been such that g=pi^2. It was then adjusted but enough for it to remain an interesting (if not too good) approximation.
> If AI accelerates productive development like with software, move the objectives up the ladder in complexity, or expectations.
The problem is that the purpose of group projects is (besides practicing programming) to facilitate learning together, splitting tasks, discussing approaches, presenting the outcome. Doing these requires understanding what's going on, and if you just vibe code everything you don't have enough knowledge to experience the soft-skill parts of the work.
For what it's worth, my understanding is that fentanyl is pretty bad as a recreational drug, which is why it started as a scam for people looking for heroin. It's too strong as an anesthetic and the effect lasts very little.
Both things can be true at the same time. The article mention switching to shorter reports and oral discussion but other courses may not have the luxury, especially the introductory ones.
For example, running QEMU as its own user and using PCI passthrough is only possible with the system daemon.
You also need the system daemon to set up bridged networking, though the unprivileged daemon can use it through a setuid helper.