You’re somewhat right in the sense that the point of disk encryption is not to protect from remote attackers. However, physical access is a bigger problem in some cases (mostly laptops). I don’t do it on my desktop because I neither want to reinstall nor do I think someone who randomly breaks in is going to put in the effort to lug it away to their vehicle.

Clevis pretty much does TPM encryption and is in most distros’ repos. I use it on my Thinkpad. It would be nice if it had a GUI to set it up; more distros should have this as a default option.

You do have to have an unencrypted boot partition, but the issues with this can at least in be mitigated with PCR registers, which I need to set up.

It’s a smidge more difficult on Debian if you want to use a non-ext4 filesystem - granted for most people, ext4’s probably still fine. I use it on my desktop, which doesn’t have encryption.

Yes, fellow OpenTTD player.

I’m using LVM. The BIOS solution would be a bad idea because it would be more difficult to access the drive on other systems if you had to; LVM allows you to enter your password on other systems to decrypt.

Do your servers have TPM? Clevis might be the way to go; I use it on my Thinkpad and it makes my life easy. If the servers don’t have TPM, Clevis also supports this weird thing called Tang, which from what I can tell basically assures that the servers can only be automatically decrypted on your local network. If Clevis fails, you can have it fall back to letting you enter the LVM password.

Well, it was worth a shot.

I don’t do it for my desktop because 1) I highly doubt my desktop would get stolen. 2) I installed Linux before I was aware of encryption, and don’t have any desire to do a reinstall on my desktop at this time.

For my laptop, yes, I do (with exception of the boot partition), since it would be trivial to steal and this is a more recent install. I use clevis to auto-unlock the drive by getting keys from the TPM. I need to better protect myself against evil maids, though - luckily according to the Arch Wiki Clevis supports PCR registers.

I wouldn’t necessarily say that - Debian and FreeBSD releases have roughly the same support lifespan, meaning if installed on release day, you’d get a few (~5 years) years of support without major upgrades.

I’d say both systems have a high chance of success at upgrading to the immediate next version, so that becomes maybe 7 or 8 years when adding the years of support left on the now older immediate next version.

For a second immediate next upgrade, you might be right that a BSD has a better chance of surviving.

I wouldn’t know about Open SD, though, as they operate on point releases and I don’t know to what extent they prevent breaking changes.

I think you might win.

I feel like I had a problem very much like this with Debian Testing on my Surface Go 1 (and I think my desktop too) a couple years back, and it turned out there was issues with /etc/nsswitch.conf. I can’t remember exactly what I did, but this is the current contents of that file:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files mdns4_minimal [NOTFOUND=RETURN] dns myhostname
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Compare yours - maybe even post it so I can try to reproduce the issue on my machine. Anyhow, hope it helps, and good luck.

It depends. Sometimes I shut it down every night. Occasionally, I’ll leave it in sleep mode for a few days.

I think the longest uptime I’ve had on anything I’ve owned is probably a month or so on a Raspberry Pi 4 server I used to have running with a personal Mediawiki instance (I still have the Pi, but if I ran a server in my dorm, I have the feeling someone might come to bite off my hand).

Have you tried SSH-ing into the system when it’s in the bad state to see if you can diagnose the problem? You might be able to see if any displays are being detected at all in the problematic state. Part of me wonders, though is not certain, if the switch is somehow providing an inconsistent display name that confuses the system, though this is just a hunch - I have no idea what I’m talking about, to be frank.

Also, try switching TTYs and seeing if those show up.

Do attempts without Windows as the first step count e.g running Windows in QEMU on Wine on Linux?

Also, depending on which version of WSL you used, you might be breaking your own rule with WSL on VMs since WSL2 uses Hyper-V. You might also be breaking it again with QEMU.

What actually counts as “VM software”? Are you defining it as a hypervisor, or does, for instance, emulating Linux on ARM in an emulator of a RISC V system in an emulator of a PowerPC system break the rule. In addition, do you mean consecutive VM software steps, or could I for instance emulate an ARM CPU that supports hypervisors and run a VM software in there?

Honestly, play around with Xscreensaver - that’s a fun collection. I’ve currently settled on the Apple II screensaver and have a custom Python script pip Star Trek scripts to it.

The Nakagin capsule tower one is awesome, too.

It depends on several things. Debian 13 is only a few months away, so 12 will already be a version behind. However, 12 will still receive security updates until mid-2028, so if it’s just a stopgap, it shouldn’t be too much trouble to install those security updates - they’re specifically designed and tested not to break anything.

If you upgrade to a newer version, it will definitely be more than 300 packages, but they also try to be careful (no guarantees, though) to make sure an update from the immediately previous version doesn’t bork everything. Thus, updates should still be pretty easy for a few years afterwards.

I could be completely out of my element here, but I almost wonder if an immutable distro would be a better idea in this case. If I’m getting this right, updating the base image under the root overlay a few years later shouldn’t mess up too much. I could be completely wrong, as I don’t use immutable distros; this is just my impression of how they work.

On my desktop, I wrote a Python script that pulls a random Star Trek: The Next Generation or Deep Space Nine script from a folder and prints it in STDOUT. I use this in the XScreenSaver Text Manipulation > Program option to turn Star Trek into a screen saver.

Currently, I use it with the Apple II screensaver, but in its original incarnation, I used the Star Wars intro screensaver. 😈

Sometimes, I Miles Edward O’Brien my VM GPU passthrough.

I’d like to interject for a moment. What you’re referring to as card games, is in fact, GNU/card games, or as I’ve recently taken to calling it, GNU plus card games. 😉