No. Both CUPS and Netflix work perfectly fine for me on Arch.

You’re probably confusing it with Alpine.

Despite the memes, Arch isn’t that hard to install nowadays. The Wiki is stellar and archinstall is a thing (as well as EndeavourOS).

But Debian testing is a fine choice as well, of course.

In my experience, once you’ve got Arch set up, it less work to maintain than Manjaro. On Arch, you have noticeably more frequent, but smaller, package updates. On Manjaro, compatibility issues with the AUR may occur, which happened a few times for me, while that won’t happen on Arch.

$ fuck

Comes in handy quite frequently.

Keepass allows you to use a passphrase in combination with a randomly generated keyfile. You only need to copy the keyfiles to your devices once (not via cloud services, obviously). Your actual database can then be synchronized via any cloud provider of your choice (hell, you could even upload it publicly for everyone to see) and it would still be secure.

Of course, one doesn’t have to install Arch manually; archiso and Endeavour are great conveniences and exist for a reason.

That doesn’t change the fact that people who rely on those tools not because they want to save some time/effort but because they’re unable to follow wiki instructions are likely better off with something other than Arch.

And if one is not able to install Arch using archinstall, then they should question themselves if Arch is even the right distro for them.

Without wanting to be elitist, I’d go further than that. While archinstall is a nice convenience, even the “manual” installation is really just diligently reading and following the wiki guide.

If that’s too much for you, you’re likely going to struggle when stuff needs manual intervention and you’re probably better off with a different distro.

Is “I use zsh, btw.” a thing yet?

Doesn’t prevent the initial crash, of course, but there won’t be one on the next boot.

What distros are there that have drive encryption but don’t require decrypting the drive while booting? Isn’t LUKS pretty much the standard disk encryption for all Linux distributions?

Relevant xkxd

I’ve seen some organisations move from CentOS to Rocky Linux.

Can’t have jury nullification if you don’t have juries.

Yes, it’s usually still available, but systemd timers are the more “modern” way, which is why distros like Arch use them by default:

There are many cron implementations, but none of them are installed by default as the base system uses systemd/Timers instead

https://wiki.archlinux.org/title/Cron

And lastly the fact that Signal is the only CA means that they can use a machine- in-the-middle attack on their own users and there is no way to protect against it.

As I mentioned in my comment, it doesn’t - if the users verify each other’s “security number”.

I have to say that some of the points on that site are outright ridiculous.

First off, they quote the privacy officer of the German protestant church, who has no technical background according to his own bio:

"… when using Signal, data protection concerns remain, especially because this service processes personal data of its users outside the scope of the GDPR. The use of this messenger service can therefore not be recommended.”

Not sure what that’s supposed to mean, because the GDPR applies based on user location and not company location. Although I’m going to grant that having servers in US jurisdictions may be a concern.

And he goes on to say that Threema (for profit, proprietary server code and (at the time) client code) and SIMSme (for profit, fully proprietary) are preferable over Signal because of the jurisdictions they’re in. Not sure about anyone else, but I’m going to trust the open source software more, regardless of what jurisdiction the servers are in.

I do have to give him credit for recognising a “self-hosted messenger service based on established and freely available protocols on federated servers” as the best option, though.

negative: actual server software used does not have to match the version published on GitHub

Fair, but how many other messaging services publish server code at all?

negative: terms of use (external) as well as privacy policy in English only

I suspect there’s very little overlap in the Venn diagram of people who use (or even know of) Signal and people who don’t speak English.

negative: weaknesses in authentication for encryption

This boils down to users trusting Signal as a certificate authority and not verifying their contacts “security number”. Fair point, but a user can still choose to use Signal in a way that removes those weaknesses.

Of course, since we’re on a federated service, I expect people to jump on the chance to recommend Matrix/XMPP instead, but realistically, I’ve had much more success getting people to use Signal. And apart from federated messengers, I’m not aware of anything better than Signal.