bonzini

That's not supposed to happen. I would like to have more info.

Wikipedia does have a rule allowing "routine calculations"

https://en.wikipedia.org/wiki/Wikipedia:No_original_research...

Of course given the magnitude of the statement a bit of care is warranted, but the rules do allow it.

What is the manufacturing tooling that you mention?

True, but adding the hollow tube to the bottom side greatly improved how much the bricks stuck together, compared to Kiddicraft. It's not a small change.

Lego also tried other designs like crosses on the bottom but then kept the tube (and later the filled small tube that you can see on 1xN bricks and plates).

It doesn't have a carry flag either. Multiprecision integer operations absolutely suck in RISC-V, you need three operations (SLT and two adds, with an awful dependency chain too) to do an add with carry, and op fusion can only do so much. At least add an instruction that computes the carry out, like "Rd = Cout(Rs1 + Rs2)" and the similar one for overflow...

https://gmplib.org/list-archives/gmp-devel/2021-September/00...

Indeed, it's hard to find a balance between what's too verbose and what's too hard. For relatively complex models it's also almost impossible to do "quality control" without actually building it.

However, I agree with the other poster that you can get good at it. And you really have to do it anyway, since creating instructions will find bugs in anything but the simplest models and you want to solve those before paying for the pieces.

AI is good at coding if there's an oracle. If the system is ancient, unreadable, untestable, that's exactly the opposite. It won't get the exact set of corner cases.

It depends on how much the code has changed, how easy it is to test old releases, how far back you need to merge the fix... "Cherry picking from the top of tree" is the most common workflow but git itself uses "merge the same topic branch in all trees".

I interpreted "I squashed them" as "I used git rebase -i to squash the oopses and fixes". If that's not what the user does, and rather squashes the PRs, then indeed I would be disagreeing with him.

The why for a commit belongs in the message or code comments not in the history.

Nope. Perfectly curating history is indeed the opposite of squashing—you squash because you couldn't be bothered to curate your commits. Squashing is a workaround not an alternative solution.

So you're "spending effort in perfectly curating git history" and agreeing with your parent comment.

You can develop with failing tests and reorder them after the code change before publishing your branch.

That's not possible, because files don't have ancestors in git. Each commit's tree is tracked independently and copy/move is just something that's detected via heuristics.

I am not sure how lockdowns (millions of people not able to work) could be driven by profits.

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.

Much less if you consider buy vs build+maintain.

Point taken, I didn't go as far as scrolling comments and only checked the user page. Apologies to dataviz1000.

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.

It's spelled osso buco though.

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.

That's exactly the same as x86. Nested virtualization support is almost entirely in the hypervisor.

No, even s390 needs shadow paging.

Intel and AMD both have some small amount of acceleration of nested virtualization, respectively with shadow VMCS and virtualized VMLOAD/VMSAVE.

KVM maintainer here, yes it is.

Yes you can disable it via kernel module parameters kvm_intel.nested=0 or kvm_amd.nested=0.

In that case you'd have to combine this vulnerability with a local privilege escalation to reach guest kernel mode.

Also the vulnerability requires enabling nested virtualization on the VM.

KVM maintainer here.

For what it's worth, this is a variant of a vulnerability discovered via fuzzing last April, CVE-2026-46113.

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.