Security is an insanely broad topic. As an average desktop user, keep your system up to date, and don’t run random programs from untrusted sources (most of the internet). This will cover almost everyones needs. For laptops, I’d recommend enabling drive encryption during installation, though note that data recovery is harder with it enabled.

“jellyfin isn’t immune to security incidents”

Well, no software is. The difference is that Plex just leaked data of all their users, where Jellyfin can’t, because they don’t have this data.

IRC does not have any federation, and XMPP does it in a completely different way from Matrix that has unique pros and cons.

IRC is designed for you to connect to a specific server, with an account on that server, to talk to other people on that server. There is no federation, you cannot talk to oftc from libera.chat. Alongside that, with mobile devices being so common, you’d need to get people to host their own bouncer, or host one for nearly everyone on your network.

XMPP federation conceptually has one major difference compared to Matrix: XMPP rooms are owned by the server that created them, whereas Matrix rooms are equally “owned” by everyone participating in it, with the only deciding factor being which users have administrator permissions.

This makes for better (and easier) scaling on XMPP, so rooms with 50k people isn’t that big of an issue for any users in that room. However, if the server owning the room goes down, the whole room is down, and nobody can chat. See Google Talk dropping XMPP federation after making a mess of most client and server implementations.

On Matrix, scaling is a much bigger issue, as everyone connects with everyone else. Your single-person homeserver has to talk with every other homeserver you interact with. If you join a lot of big rooms, this adds up, and takes a lot of resources. However, when a homeserver goes down, only the people on that homeserver are affected, not the rooms. Just recently, matrix.org had some trouble with their database going down. Although it was a bit quieter than usual, I only properly noticed when it was explicitly mentioned in chat by someone else. My service was not interrupted, as I host my own homeserver.

The Matrix method of federation definitely comes with some issues, some conceptually, and some from the implementation. However, a single entity cannot take down the federated Matrix network, even when taking down the most used homeservers. XMPP is effectively killed off by doing the same.

GNOME devs simply can’t “tolerate” SSD, and force CSD in every scenario for GTK4. My machines running Wayland only have CSD for fully custom apps (like Steam) and every GTK4 app.

To answer the question in the title: No, because these systems inherently have different architecture. Something like OpenBSD (the OS) is relatively self-contained. Linux distributions have system components that are externally developed, but a user might rely upon.

What exactly is the “problem” you have with Linux package managers? It’s specifically extra complexity to separate “system” and “packages”. This works well for *BSDs that often develop the entire OS themselves, but would pose extra challenges for Linux distributions, where the line between “OS” and “user installed package” is much more blurred.

Discord is one of the greedy AI companies training on your data

FOSS only, no proprietary spyware here. Daily driver on Android 15.

Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don’t support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.

Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can’t configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its “convenience” tools/setup).

Looking at this, I’d personally delete both EFI and boot partitions, then remake them with the EFI partition significantly smaller (it should not exceed >100MB used). I have no idea what issues this would cause on Debian, and what specific configuration needs to be changed/updated. I’d guess you need to change the fstab entries, remake the initrds, and reinstall/reconfigure the bootloader.

Any manual messing with partitions, especially rootfs/boot/efi, can easily lead to a broken system. The fix will not be a simple procedure.

As you’re considering messing with your rootfs, I’m going to assume you have a backup. It’ll be significantly easier for you to wipe everything, install fresh new Debian, and copy your personal files over to the new installation.

sudo systemctl status shows you what services are running, sudo systemctl list-units lists everything, including the services that failed. sudo systemctl status gdm.service shows you the status of one service in particular, and sudo journalctl -u gdm.service shows the output/logs of that service.

There’s a decent chance something is not starting due to misconfiguration. I’m guessing GDM based on previous comments. You can also check /var/log/pacman.log (make sure to save a copy, just in case), to see what packages changed/updated.

If you think it’s a pacman issue somehow, you can reinstall your entire system (excluding AUR or self-made PKGBUILDs). Note that this is almost never required to fix an issue. In a properly working system this “shouldn’t harm anything”, but nothing can be guaranteed on a broken system. The command for that is sudo pacman -S $(pacman -Qqn)

had to find and get the dependencies by myself

Luckily, Linux has evolved in the past 30 years. A package manager (one usually comes with your system, like apt, dnf, pacman) will handle almost all direct dependencies for you. When installing Steam, you may be asked which 32-bit Vulkan library you want to install, but aside from that it should get everything automatically. (Hint: vulkan-radeon on AMD, otherwise pick the one for your GPU brand)

Managing and “maintaining” (updating, sometimes cleaning) an Arch Linux installation is definitely more involved than what you are used to on Windows or the Steam Deck. Some people prefer this workflow, as it offers more control over their system. Others prefer an already set up and maintained environment.

Bazzite is a very SteamOS-like experience. You click update once in a while, and shouldn’t have to touch anything else internal to the system. You get Steam and Flatpaks out of the box.

Since Linux gives everyone the freedom to do things the way they want, there will always be people shitting on a specific way to do things. There are definitely good reasons to dislike certain software, but generally you should be just fine. Just because someone thinks their way of doing things is better doesn’t mean you should immediately switch to that.

That being said, the main downside of Steam in a flatpak is the sandboxing possibly getting in the way of modding your games, or games that use unique hardware (like steering wheels or so). steam (pacman package) does not have those specific issues, but it lacks sandboxing (aside from Steam’s pressure vessel for games).

You can continue with Arch if you want, and there’s certainly good resources to learn (like the wiki) or get help (like the IRC or Matrix rooms). It will require you to learn about how to actually set up and configure your Linux installation the way you prefer. Other distros (usually marketed as “user friendly”), like Fedora, Bazzite, Mint, will automatically perform or set up some of the maintenance you’d have to do manually on Arch.

There is no justification. The “Ends” in E2EE mean the initial sender, and intended recipient. The “transport” should have zero insight into the content. Encrypting a message to the servers is standard even for “non-private” messaging services, it’s usually done with SSL (part of HTTPS).

Lets compare it to traditional mail. If you send something, the postal company can always just open your mail and read it. With computers, we have black magic (E2EE) that physically prevents the postal company from doing that. In this hypothetical, Facebook (owner of WhatsApp) is the company that provides you with the pen and paper (the app), and is a postal company (their servers). They promise that the black magic on the paper prevents them from reading what you wrote, but then they clearly read the content of your letter to send you a summary of the conversation.

Mid-message quick edit: They could’ve also done something to the pen (other parts of the app) to have it tell them what you wrote. This would mean the black magic (E2EE) is applied, but is completely useless. (End of edit)

If the process for making the pen and paper (the app) was publicly known (open source), you could make your own, and be sure the black magic (E2EE) is applied properly. That way you can be certain the postal company (servers) can’t read your letter, only the recipient can.

If the postal company gives you the pen and paper without telling you how to make it, it’s nearly impossible to tell if the black magic was applied properly.

The concept of “End to End Encryption” (E2EE) is that one end encrypts the data, it passes through transport, and the only person who can read the decrypted data is the intended receiver.

In the case of WhatsApp, this should mean:

• Your phone (WhatsApp app) encrypts a message
• Your phone sends the encrypted (“unreadable”) message to Facebook
• Facebook sends the message to the intended receiver
• The receiver decrypts the message

The whole “Meta AI summaries” thing has to run on their servers. Large language models small enough to fit on a phone don’t produce sensible output yet, and your phones battery would drain very quickly. Since each message is (supposed to be) encrypted with different keys, no human nor computer can make sense of the encrypted data without the keys to decrypt it. For their servers to provide a “summary of your chats”, they have to be able to read the content of the messages. Thus proving that the whole “end to end encryption” in WhatsApp is either false, or made entirely useless with them sending all messages to themselves without E2EE.

The only proof that would invalidate this is evidence of the LLM running locally on device. Even then, the way some of WhatsApp’s services work (like notifications, WhatsApp Web) creates some serious doubt on the “E2EE” claim.

It is absolutely essential that any communications platform claiming “E2EE” proves this by making the client-side code (the stuff running on your device) fully open source. A proprietary app, like WhatsApp, by definition makes it harder to fully understand its inner workings, and thus fully verify the E2EE claim.

It’s actually not within their rights (I am NOT a lawyer)

GPL code is still owned by the person who wrote it, that includes contributors who have made a PR. Unless they all signed CLAs (Contributor License Agreements) to hand over their copyright to the repository owner, the repository owner does not hold copyright for this code, and as such can’t legally change the license. They can use and distribute it as specified in the license terms of the GPL, but that excludes changing the license.

Surely there wasn’t an exploit on the half a year out of date kernel (Article screenshots from April 2025, uname kernel release from a CBL-Mariner released September 3rd 2024).

Yeah but that’s not limited to physical DVD size constraints.

Filmmaker

transmitting over 125,000 gigabytes of data per second over 1,120 miles (1,802 kilometers).

Please include usable metrics in the title

XMPP is significantly less decentralized, allowing them to “”“cut corners”“” compared to Matrix protocol implementation, and scale significantly better. (In heavy quotes, as XMPP isn’t really cutting corners, but true decentralization requires more work to achieve seemingly “the same result”)

An XMPP or IRC channel with a few thousand users is no problem, wheras Matrix can have problems with that. On the other hand, any one Matrix homeserver going down does not impact users that aren’t specifically on that homeserver, whereas XMPP is centralized enough that it can take down a whole channel.

Meanwhile IRC is a 90s protocol that doesn’t make any sense in the modern world of mainly mobile devices.

XMPP also doesn’t change much, the last proper addition to the protocol (from what I can tell, on the website) was 2024-08-30 https://xmpp.org/extensions/xep-0004.html