The OP didn’t mention Proxmox in their post. I’ve been speaking generally, not about any specific OS. For example, Nvidia’s enterprise offerings include a license to use their “GRID” vGPU tech (and the enabled feature flag in the driver).

Why? Product segmentation I suppose. Last I looked, the Virtio project’s efforts were still work-in-progress. The Arch wiki article corroborates that today. Inconsistent behavior across brands and product lines.

I’ve also wanted to do this for a while, but there were always a few too many barriers to actually spin up the project. Here’s just a brain dump of things I’ve seen recently.

vGPUs continue to be behind a license. But there is now vgpu_unlock.

L1T just showed off PCIe “fabric” from Liqid that can switch physical devices between machines.

Turning VMs on and off isn’t as slick as either of the above, but that is doable today. You’ll just have to build all the switching automation yourself. That could just be a shell script running QEMU/libvirt commands, at a minimum.

Thanks for asking. Not sure how I toggled that on…

You can put the game into its own time namespace.

https://www.man7.org/linux/man-pages/man7/time_namespaces.7.html

I’m not sure I understand your question.

Eat has its own major mode which is used when you open a standalone buffer via the eat function.

When it’s embedded in Eshell it mostly just does the right thing whenever you invoke a command that uses terminal control codes (e.g. htop) – and many of those can be closed with q, yes.

I assume Eat is activated for any program listed in the eshell-visual-commands variable (but I’ll admit I don’t really understand how that works). The notable new minor modes present when I run htop in eshell are Eat--Eshell-Local and Eat--Eshell-Process-Running.

niggle (plural niggles)

A minor complaint or problem.

https://en.wiktionary.org/wiki/niggle

I haven’t fully moved my terminal needs to Emacs (though I’d like to) for the same little niggles you mentioned. Just wanted to recommend another option amongst the good ones already suggested here.

https://codeberg.org/akib/emacs-eat/

I’d ask why they don’t make it optional (I’m not a Brave user) but it seems it was.

Another issue is that Strict mode is used by roughly 0.5% of Brave’s users, with the rest using the default setting, which is the Standard mode.

This low percentage actually makes these users more vulnerable to fingerprinting despite them using the more aggressive blocker, because they constitute a discernible subset of users standing out from the rest.

Given that, I’m inclined to agree with the decision to remove it. Pick your battles and live to fight another day.

There’s some history there, if you didn’t know. Jellyfin is a fork of Emby.

They have said they want to keep a fairly long-term performance target for game devs optimizing for the device. Consoles do the same thing. Another part of that is improving margins over time.

KDE is working on it for Plasma 6.

From your link:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Mozilla stated that a while back.

How do I capitalize Firefox? How do I abbreviate it?

Only the first letter is capitalized (so it’s Firefox, not FireFox.) The preferred abbreviation is “Fx” or “fx”.

#8 in the FAQ

You’re right, it doesn’t. That does give me an idea though.

You could use overlayfs with an opaque upper directory to hide the files littering your $HOME and still access them by bind-mounting them into the appropriate xdg dirs.

Way more effort than it’s worth, of course.

Not the parent poster, but I am similarly concerned about tag spam. I find big tag blocks can ruin the reading experience on platforms that display them in-line with the body text.

Another comment suggested that tags be put in a field separate from the body of the post (and they shouldn’t be parsed from the body, either). I think that’s the best way to facilitate Lemmy clients to (optionally) hide big tag blocks.

They ask a bit of trust on that, but their FAQ also has an appeal to reason:

I have privacy concerns over linking my search queries with my credit card. Why should I trust you?

We do not log search queries. Queries you type are never associated with your account. The simple reason is we don’t have any reason to do so, as it would only be a liability for us. We are in the business of selling search results, not user data.

(For the record, I use Kagi)