Not necessarily without concern. Some containers have startup scripts that chown or chmod all files in some locations. It can mess up access for other containers if shared.

First will be shared files between the container in a single named volume. The others will create 2 named volumes pointing at different files with example1 from the 3rd not being on NFS.

If filesystem UUIDs are IP equivalents. Then device paths are MAC addresses. FS labels are DNS. Device mapper entries are service discovery.

“Invalid” or “unparseable” are more understandable descriptors in normal language. I don’t think I ever heard of garbage/junk being used for that in language theory but it may be domain specific usage.

It can still have issues with potential attacks that would redirect your client to a system outside of the VPN. It would prevent MitM but not complete replacement.

Likely you needed to include the intermediate cert chain. Let’s encrypt sets that up automatically so it’s quite a bit easier to get right.

Your experience may depend on which distro you use and how you install things. If you use a distro with a stable upgrade path such as Debian and stick to system packages there should be almost no issues with upgrades. If you use external installers or install from source you may experience issues depending on how the installer works.

For anything complex these days I’d recommend going with containers that way the application and the OS can be upgraded independently. It also makes producing a working copy of your production system for testing a trivial task.

I’n Windows it is not stored in a keyring but instead in the registry. This has basically the same security threat model as a local key file.

The ssh-agent on Linux will do what you want with effectively the same security. The biggest difference being that it doesn’t run as a system service but instead runs in userspace which can make it easier to dump memory. There are some other agent services out there with additional security options but they don’t change the threat model much.

Initrd contains the systemd binary and enough libraries, services, and kernel modules to get booted this far. The system failed at switch root which is where the real root disk is mounted. Initrd can contain as much or as little as needed to get a working system which can be a lot of you are using a network filesystem as a root for instance.

My memory of the cp command is that attributes such as file times were transferred at the last step. I think this would make rsync safe in most situations where a system crash wasn’t involved.

I think I remember running into that as well but for whatever reason I couldn’t get accelerated-x working with the opengl libraries I was using for school. Likely the issue was just a lack of understanding on my part as I don’t think I had a good grasp of the Linux library loader until well after I graduated.

I’ve had a system in the late 90s with a 3dfx voodoo card. Also had a laptop with a SIS card from the early 2000 era.

The voodoo card was THE card to have it it’s day (mine was an older second hand system though). The SIS card… for some reason they decided that standard VESA mode probing wasn’t a thing they supported and would hardware crash when that API was used. I eventually got it working in Linux after patching xfree86 to not attempt probing when loading the VESA driver.

QEMU supports either spice, vnc or sdl graphics output. If you want to copy/paste you need to use spice and install the spice agent on the VM.

My steam deck also unlinks family libraries with almost every os update. It might be an issue of overzealous hardware validation but it could also just be a bug.

It’s very likely that your disk is failing.

dd if=/path/to/file.mkv of=/new/file/path.mkv conv=noerror,sync bs=4k

Should give you a file with just the damaged bits missing.

PTSD from the days long ago when X11 error log would fill up the disk when certain applications were used.

Are they on a local disk? Thunar doesn’t render any thumbnails for remote storage by default.

When rsync copying the active root I like to bind mount / to /mnt/root_fs first. This avoids the issue with needing to exclude folders with sub-mounts and will expose files to copy that might be hidden by the mounts.