LaggyKar

No, they just include libarchive in Windows

I’ve only gotten that when I’ve mistyped the encryption password. They really should improve the handling of that.

Apparently so it does, and it says “HDMI Freesync” rather than “HDMI [2.1] VRR”. FreeSync HDMI is a completely different protocol and is supposed to work under Linux. Found a thread here, can you try cat /sys/kernel/debug/dri/0/HDMI-A-1/vrr_range and edid-decode < /sys/class/drm/card0-HDMI-A-1/edid? Though there is no solution there.

I thought that there was VRR support over HDMI even for versions below 2.1 spec.

Yes, there is FreeSync HDMI, which is supposed to be supported on Linux, and which is unrelated to HDMI 2.1 VRR. Don’t see anything about the monitor supporting that though (LG 24GS60F based on your previous post). Not anything about HDMI 2.1 VRR, it probably only supports VRR via DisplayPort Adaptive Sync.

It’s better in one way, in that updates are applied on reboot rather than pulling the rug put from under running applications. But I agree that it doesn’t go all the way, as it doesn’t provide a verifiable base system with clearly separated modifications. OSTree would be great.

Another possibility would be to distribute a base image as a btrfs send stream (possibly differential against previous versions) containing a compose-fs image and associated files. And then OS extensions could be installed with systemd-sysext.

I used to use it, but then I switched to MPV, as it works a lot better with hardware acceleration. MPV supports more methods for hardware decoding (e.g. nvdec), and also MPV will keep the frames in VRAM when doing hardware decoding, and do additional processing and presentation using the GPU, while VLC copies everything back to system RAM and processes the frame on the CPU.

At the time I switched hardware decoding with copy-back would actually result in twice the CPU usage compared to software decoding, but that was a long time ago. Also, I would get tearing in VLC and not in MPV.

You’re right, that might work

That requires root

Speaking of which, nowadays KDE hides files with these extensions for some reason

Maybe if you use a file system that supports compression, e.g. btrfs, bcachefs, F2FS, squashfs, or EROFS. Of course, you’d need to add a separate FAT32 EFI System Partition for the bootloader, not sure how to do that.

A310 is the cheapest.

I wonder how well it does for transcoding on older computers without ReBAR, since apparently gaming on it is straight out broken without ReBAR. As in, it would actually freeze for a second or so every now and then.

Could be that the graphics card is outputting an HDR signal (Rec. 2020 color space), but the monitor is in SDR mode. That would result in desaturated colors.

Already daily driving it on my laptop, which uses AMD graphics, and my work laptop, which uses Intel graphics. For Nvidia, there’s missing explicit sync (which should be fixed soon), and Steam completely freaking out (might get fixed by explicit sync). Kwin also seems a bit unstable on Nvidia, but I haven’t tested it for extended periods of time.

I also have a computer with display on an Nvidia card via reverse prime, which suffers performance issues on Wayland. Might be improved on Plasma 6, but that computer runs OpenSUSE Leap, so it won’t get that for some time.

There is also the issue of picture-in-picture, but that can be worked around with Kwin rules.

That though would make it break when the host system updates glibc, just like it does in snappy.

Another alternative then would be Restic. That’s what I’m using for backups

This is very outdated.

• Catalyst doesn’t exist anymore, it was replaced by AMDGPU-PRO years ago.
• The Radeon Mesa driver (radeonsi) is generally faster than AMDGPU-PRO OpenGL for gaming, and has been for years. On the Vulkan side, performance is usually fairly close between the Mesa driver (RADV), AMDVLK and AMDGPU-PRO.
• AMDGPU is just the kernel driver, which is used by both the Mesa drivers and AMDGPU-PRO, so why is it listed separately?
• For Intel, I think the hardware was holding it back more than the driver, especially since they’ve replaced the classic Mesa drivers with Gallium based ones. But now they’re doing the Arc stuff.
• I don’t know if I would say that Nvidia proprietary runs well