Tbh for email I'd say don't bother with privacy as it wasn't meant to be private, as Dessalines said. If you care about data sovereignty (which is different to privacy, though often hand-in-hand), you can self-host email—it's not as hard as it's reputed to be. I've self-hosted my main email address for a couple years now and not had major hiccups. For the most part, after initial setup, it just runs. And if you're daunted by configuring it, there are out-of-the-box solutions like Mailcow you can use. I'd only really recommend it if you already have a VPS/home lab/etc where you already self-host things.
communism
He gets away with it because he makes a high quality OS that people want to use. I don't see it as much worse than e.g. using Linux when Torvalds is kind of an asshole.
Entirely believable. If you're experiencing genocide, what are you going to do? Just let you and everyone you love be killed? No, you're gonna fight back. Of course Al Qassam recruitment has been doing well.
saying that anything AI generated in the kernel is a problem in itself is bullshit.
I never said that.
Same with human generated code. AI bug are not magically more creative than human bugs. If the code is not readable/doesn’t follow conventions you reject it regardless of what generated it.
You may think that, but preliminary controlled studies do show that more security vulns appear in code written by a programmer who used an AI assistant: https://dl.acm.org/doi/10.1145/3576915.3623157
More research is needed of course, but I imagine that because humans are capable of more sophisticated reasoning than LLMs, the process of a human writing the code and deriving an implementation from a human mind is what leads to producing, on average, more robust code.
I'm not categorically opposed to use of LLMs in the kernel but it is obviously an area where caution needs to be exercised, given that it's for a kernel that millions of people use.
I wonder if a "deposit" system for huge projects that get a lot of patch submissions might be worthwhile to deter vibe coders from submitting slop patches. You pay a trivial amount of money (adjusted for region/local currency strength) to submit a first patch and get it back if it's accepted. People who have already had patches accepted in the past are exempted.
The issue is that it's easy for AI generated code to be subtly wrong in ways that are not immediately obvious to a human. The Linux kernel is written in C, a language that lets you do nearly anything, and is also inherently a privileged piece of software, making Linux bugs more serious to begin with.
The other problem is, of course, you can block someone submitting AI slop but there's a lot of people in the world. If there's a barrage of AI slop patches from lots of different people it's going to be a real problem for the maintainers.
And from there you can anonymously publish the newsletter archives for everyone. I agree there should be some kind of tracker for newsletter piracy though.
I see, that's interesting. Well glad that it's not hard to switch away from systemd on Debian for those who want it—although I still think if you don't want systemd you should just pick another distro, given that the Debian installer doesn't let you pick another init.
Probably boomers who aren't used to more idiomatic ways of typing on casual social media?
On Debian you can use both sysvinit and openrc
Huh really? Then why does Devuan exist? (I don't use Debian for context)
I use Alpine for servers because I like its simplicity. Not in terms of computational power requirements, just in terms of user experience.
Alpine is an interesting choice for hosting
I'd say servers are one of the main uses of Alpine, second to containers. It would be a much more unusual choice for a desktop OS.
I self-host on a VPS, so my off-site copy is the VPS, and my on-site copy is the emails downloaded to my email clients.
Define "safer". If you are receiving unencrypted emails (which is the case in the vast majority of cases), there is nothing stopping Proton or Tuta from reading them. Fundamentally, if something arrives at a server unencrypted, the server can read it—nothing can be done about that.
If you're exchanging e2ee emails, then it doesn't matter if you use Google, because the body of the email can't be read by Google. A lot of metadata is required to be unencrypted though (this is the case for Proton and Tuta too).
I don't really see the benefit to using an email service like Proton or Tuta from a perspective of meaningful data privacy. If it were between e.g. Proton and Google I'd probably pick Proton to avoid my emails being used to serve me ads from Google, but I wouldn't have any illusions about Proton being able to read unencrypted incoming mail.