I personally find the "animals killed since you opened this page" number to be the most unsettling. YTD numbers are so large, I find them hard to process.
If you choose to eat meat, please be aware of the conditions most of these animals exist in and how they die. I'll spare you more numbers, because they don't do the cruel reality justice anyway. Instead, I'll leave you with some video material: https://animalequality.org/blog/factory-farming-facts/
The quantity of animals killed scales inversely with size. Most of the "animals killed since opening this page" are shrimp.
I am open to hearing evidence that shrimp have the capacity to care about the conditions in which they live and die but as of now I don't believe they do.
Gnome, for example. GDM now needs systemd's userdb.
It is indeed becoming harder and harder to avoid and I understand that this isn't great, but systemd tackles some genuinely hard problems that others don't. Which is to say I don't begrudge Gnome devs for this and personally prefer systemd over current alternatives.
I've looked at OpenRC, RUnit and S6. I haven't recently run any of them "in production", however.
Personally, I am a strong believer that declaring the desired state is a lot easier to get right than actually writing the code to get there. Beyond that, I'm not saying any of these are bad at being what they are, systemd just has more features, some of which I really like. Two examples I'm actively using currently are automount units and socket activation (S6 also has socket activation). I have some remote folders mounted via SSHFS automatically when I access them and this is incredibly useful for my workflow.
Could I find tools to slot into other init systems that do this for me? Probably. But systemd has this neatly packaged up, easy to configure and easy to introspect state.
It uses a folder with a subfolder for every service. Each subfolder contains a script called run. The system runs the run script. If it exits, it waits two seconds and runs it again. Repeatedly. It's very worse–is–better.
There are commands to control the services and check their status. For example, if a file called down exists next to the run script, it won't run it. This is how you disable a service.
It checks for service folders being created and deleted. New folders are started, and deleted ones are stopped cleanly. They can also be symlinks, so you don't need to worry about deleting a running service folder and you can remove a service from init without erasing the scripts you wrote.
The whole system is useful in many situations and not only as pid 1.
Maybe one day I'll invent a runit–based distribution.
You seem to be under the impression that you cannot reset your Secure Boot to setup mode. You can in the UEFI, doing so wipes any enrolled keys. This, of course assumes you trust the UEFI (and hardware) vendors. But if you don't, you have much bigger problems anyway.
Is it possible someone will eventually build a system that doesn't allow this? Yes. Is this influenced in any way by features of Linux software? No.
It is certainly influenced by the features of Linux software. If Linux does not support this then this preserves a platform as an escape route where this is not possible and this substantially reduces the incentive to provide certain content and services (!) only when this is enabled.
> What prevents Microsoft from mandating removal of enrollment permissions for user keychains and Secure Boot toggle
Theoretically, nothing. But it's worth pointing out that so far they have actually done the opposite. They currently mandate that hardware vendors must allow you to enroll your own keys. There was a somewhat questionable move recently where they introduced a 'more secure by default' branding in which the 3rd party CA (used e.g. go sign shim for Linux) is disabled by default, but again, they mandated there must be an easy toggle to enable it. I don't begrudge them to much for it, because there have been multiple instances of SB bypass via 3rd party signed binaries.
All of this is to say: this is not a scenario I'm worried about today. Of course this may change down the line.
> Maybe I could get a EU bank from another EU country but my employer will not accept an out of country account for salary deposits because it makes their tax life difficult and my mortgage provider doesn't trust foreign accounts either.
I do not doubt this is happening, but it is forbidden under SEPA. All IBANs, no matter from which member country, must be treated equally. Unfortunately, "IBAN discrimination" happens quite frequently still. The European commission recommends filing a complaint with your national governing body.
If you're working in a corporate environment, this may not be viable. LibreOffice is great software, but it's not 100% compatible. Things may look slightly different, get lost or otherwise cause problems. I've really tried, but at the end of the day I occasionally do need to use actual Microsoft Office.
Yep. And then there is Visio which gets used a lot where I work. LibreOffice Draw doesn't come anywhere near it. It saves a lot of grief just to give our Linux users a Windows VM with Office on it if they need to do any significant docs or drawings.
I used Word to write a reasonably complicated document that necessarily used tables. It was one of the most frustrating, bug inducing experiences of my life. I had to open the document and edit it in LibreOffice to get any sort of stability.
nix-darwin is essentially this. I have a small bootstrap script to install Xcode CLI and Nix, git clone my dotfiles and activate the config. That in turn sets up the system, also installs Homebrew, installs apps from the App store and sets up all my configs. The only thing I need to do after is sign into some accounts.
I also strongly dislike requiring remote attestation for any kind of software I want to run. But what I also dislike is cheaters in my online games and I genuinely do not have a better suggestion on what to do.
Personally, I run Windows purely for gaming and don't let it near any important data. For the latter, I boot into Linux with separately encrypted disks.
>But what I also dislike is cheaters in my online games and I genuinely do not have a better suggestion on what to do.
You can't suggest "run online games as close-knit social groups, with social exclusion punishments for cheaters", which is how most online games used to be run. How old are you?
Game vendors used to be happy letting us host and run our own multiplayer games, until they realised they could get more money out of us -- "battle passes", microtransactions, ability to forcibly turn off multiplayer of older game when newer remake comes out -- and now they've made themselves a mandatory part of your online experience. You have to use their matchmaking and their servers. So now it's down to them to solve the problem of cheaters, enabled by their centralised matchmaking... and their only solution is remote attestation of your machine and yet more data collection?
I'm doing the same but I worry about windows compromise messing with the bootloader so then encrypted linux drive won't save me. Probably too paranoid though?
If you use secure boot and don't let your keys near Windows, you should be fine even if your Windows install is compromised. Unless you don't trust Microsoft themselves, in which case you'd need to re-enroll keys whenever switching operating systems, which is possible, but very tedious.
The important part in the parent is "that don't need a user password". You just said you had to supply a (user) password.
With a TPM you can set it up that your disk is unlocked automatically, but only if no-one changed anything in the signed boot chain. This is the default with Bitlocker on Windows and is also possible on Linux, though somewhat more finicky.
But most people don't want to enter a password, and if you make people enter a password too much, they'll choose terrible passwords and put them on a sticky note. Windows Hello can only be done securely with a TPM. A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.
I want a TPM in my computer so I can have the security and convenience. Yes, it's another point of failure. But I need backups in case the hard drive fails anyway. And besides, the OS can be designed so I can enter a password if I need to use the drive without the TPM.
>Windows Hello can only be done securely with a TPM
I think in general biometrics are in the same ballpark as low-entropy passwords. IDK, I personally have no faith in trusted computing hardware because it can be broken with the right equipment. You're right that it can be used alongside ordinary security measures, but I just think it encourages putting your eggs into a cryptographicially-weak hardware-strong basket (which represents a downgrade because crypto is stronger than hw).
>A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.
Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.
> >A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.
> Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.
I'm not sure what you mean by prevent a MitM attack, unless you're worried about someone with probes MitM-ing your TPM-CPU connection in the DC.
You can bind a TPM to measurements on the host (let's say for argument's sake you want Secure Boot state, Option ROM state, and UEFI state), then configure the OS to ask the TPM for the (or rather, a) decryption key during boot.
The TPM will check that the state(s) you bound to is (are) the same as when you bound them, and if so it will give the OS the key. Your disk is encrypted, but the boot process is automatic/unattended, as well as completely contained within the server chassis.
There are ways to attack this hypothetical setup, buuuuut there are ways to attack remotely entering your disk password as well, and bear in mind that denial of service is a security vulnerability. Tradeoffs.
I agree that biometrics are in the same ballpark as low-entropy passwords, which means their security relies on avoiding offline attacks. My ATM card is protected by a 4-digit pin. That's perfectly secure, because the ATM network won't let you enter a wrong pin more than a single-digit number of times before locking the account.
Windows Hello allows you to log in with a 6-digit pin. That's perfectly secure, because the TPM lets them design a system where you can't do an offline attack on the pin. Too many wrong entries and you'll need to use your password.
I doubt there's more than two dozen bits of entropy provided by finger print readers or facial recognition authentication, but you can make an acceptably secure login experience with it because, again, the TPM lets you prevent offline attacks.
But without password, anybody can physically access the device and exfiltrate data. That is even easier than regular password protection, where the storage medium would have to be removed or a live OS would have to be booted.
The risk is data leakage. With a TPM and no password, there is no data leakage protection.
Passwordless boot with a TPM means the software can control what secrets it gives out. Yeah, if you boot to a desktop operating system and auto-login as an admin user, that doesn't leave things very secure, but that's not the only scenario.
Consider a server. It can have an encrypted hard drive, boot with the TPM without a password, and run its services. In order to steal data from it, you need to either convince software running on the server to give you that data, or you need to do some sort of advanced hardware attack, like trying to read the contents of DRAM while the computer is running.
There are other use cases too, like kiosks, booting to a guest login, corporate owned laptops issued to employees, allowing low-entropy (but rate limited) authentication after booting, to name a few.
If you choose to eat meat, please be aware of the conditions most of these animals exist in and how they die. I'll spare you more numbers, because they don't do the cruel reality justice anyway. Instead, I'll leave you with some video material: https://animalequality.org/blog/factory-farming-facts/
reply