hunger

One more reason to run the steam flatpak: At least I can sandbox away things steam does not need to concern itself with.

The point of using the TPM is that it does not unlock the drive unless it has a certain set of software is loaded in a certain sequence on the machine with that specific TPM chip.

So if somebody breaks grub and makes it load a shell, then that results in different software loaded (or at least loaded in a different sequence) and will prevent the TPM to unlock the system. The same is true if somebody boots from a rescue disk (different software loaded) or when you try to unlock the disk in an unexpected phase of the boot process (same software but different sequence of things loaded, e.g. after boot up to send the key to some server on thr network. The key is locked to one TPM, so removing the drive and booting it in a different machine also does not work.

The TPM-locked disk is pretty secure, even more so than that USB idea of yours -- if the system you boot into is secure. It basically stops any attacker from bringing extra tools to help them in their attack. All they have available is what your system has installed. Do not use auto-login or run some root shell in some console somewhere...

But if the key is fully wrench-safe inside the TPM. You do not know it, you can not get convinced to give it up -- even after repeated wrench use.

Of course the recovery key that typically goes with it and you logging password is not wrench safe, so that does not protect the system fully, while getting you a matching set of broken kneecaps.

The idea behind TPM-locked boot is that you can boot into your system unattended, but it stops booting into any other system. Typically no password is needed, but you can also assign an additional (non-user) password if you want.

This is nice if you trust your system to be basically secure. Nothing else can access its filesystems, so no external tool can be used to break into it. Rescue disks can not access any data without knowing a special rescue key -- so make sure to set one up! A nice side effiect is that the key is only available while setting up disks in the initrd and totally inaccessible at any other time. That makes it very hard to extract the password once the system is running.

You can encrypt the home directories of users using other services like systemd-homed. That will prevent anyone from accessing any data in the user's directory while that user is logged out. Homed will basically use your password to unlock your disk and if that works, then the password is accepted. So you do not need that user to be listed in the traditional /etc/passwd file, which is useful as you can just copy the users homedir image file onto another system to move a user account over.

Add a /var partition, boot from some live system, copy over the data, delete it in the root partition after making sure it was copied ok and add the new filesystem to fstab. /var is the only place we that will grow significantly(especially when younuse flatpaks).

Last time I tried it was an apt install followed by a reboot. If your distribution claims to support several inits and it is harder than that: Your distribution did a poor job.

Where are those "many of us"?

It is what the CI uses for testing. If several layers of people decide to not do their job and you have no hardware in your network that announces the DNS servers to use like basically everybody has, then those CI settings might leak through to the occassional user. Even then, at least there is network: Somebody that can't be arsed to configure their network or pick any semi-private distribution will probably prefer that.

Absolutely no issue here, nothing to see.

Why? Slab sysv-init (or openrc or s6) and the gnu tools the onto it and you will hardly be able to tell the difference :-)

That is actually the thing I like about systemd: They expose a lot of linux-only features to admins and users, making the kernel shine.

Why would he? It never was an issue.

might want to look at the more "advanced" distributions that let you choose the init system.

Yeah, sure... integrating a init system is a huge task (if you want to do it properly). Let's do that several times!

Systemd-networkd (not systemd the init system) defaulted to the google DNS servers when:

• the admin did not change the configuration
• the user did not configure anything
• the network did not announce anything
• the packagers had not changed it as they were asked to do
• the distribution actually decided to switch to networkd. Few have done somtomthis day.

That is indeed a serious issue worth bringing up decades later.

You are not done one the config is written: A configuration requires maintenance effort: New plugins get released, others stop getting developed, APIs change. You constantly need to adapt your configuration.

That is why I recommend using a distribution like astonvim. A distribution takes care of keeping the basics going and gives a well msintained base and thus gives you more time to fiddle with the interesting bits of the configuration.

Astronvim in particular is "just" a lazy nvim config and very easy to customize, filtering the standard override process defined by the lazy plugin manager.

I actually got rid of most custom config I had on top of astronvim by using its community repository: It contains easy to add config snippets that fully integrate other plugins with all the plugins in the astronvim config (lsp setup, treesitter, snippets, completion, ...). This ranges from adding one plugin to entire language packs with all the recommended bells and whistles to work with some programming language.