“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.

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).

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).

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

Why the downvotes? Apple silicon ARM is not the same ISA as any existing ARM. There’s extra undocumented instructions and features. Unless you want to reverse engineer all that, and make your own ARM CPU, you cannot run (all of) macOS on an off the shelf ARM chip. Making it effectively “impossible”.

You don’t get control of the incoming port that way. For LetsEncrypt to issue a certificate primarily intended for HTTPS, they will check that the HTTP server on that IP is owned by the requesting party. That has to live on port 80, which you can’t forward on CGNAT.

Great, the touchpads are amazing for mouse-related stuff while handheld. I can comfortably use mouse heavy menus with them. Obviously, a lot closer to a laptop touchpad than an actual mouse, but still a lot better than a joystick as mouse.

A Steam Deck is a PC. If you dock it, you can hook up a mouse+KB and a monitor, and use “desktop mode” (KDE plasma) to use it exactly like any other Linux desktop. Docked “gaming mode” makes it feel more like a home console for PC games (and emulators). It is even possible (though not recommended) to install Windows.

Reminder that the license was changed to a “custom” non-free license.

I own a OnePlus 6 with postmarketOS. My daily driver is a Pixel 7 with CalyxOS and microg turned off.

Despite having effectively only FOSS apps on my Android daily driver, I can’t daily drive postmarketOS. It’s making great progress, but isn’t nearly stable enough as a modern smartphone, and several other issues hold it back;

• Sleep states. Currently you get to choose between your phone going to sleep (~ a day battery life) but without notifications, incoming calls, alarms, etc. Or your phone “staying awake”, where you’ll have those features but only ~4 hours battery.
• Hardware video decoding, which “can work” but only in select apps, and they’re not great for mobile.
• Audio issues, such as no audio from the earpiece, microphone not working, or no audio at all.

If you rely on non-foss Android apps, there is Waydroid, but it’s not a perfect solution and might have issues.

It’s not a “waste of money” if you want a device to experiment or tinker with, or if you want to follow progress of Linux mobile, but it is extremely unlikely to replace your daily driver.

Keyguard, which works on Bitwarden-compatible servers like Vaultwarden

Mint under the hood is still Linux, but for basic tasks like webbrowsing, it’s very similar to or easier than Windows.

deleted by creator

I have used Waydroid, mainly with FOSS apps, and although it has some rough edges, it does often work for just having one or two Android apps functionality.

Linux on mobile as a whole isn’t daily driver ready yet in my opinion. I’ve only tried pmOS on a OP6, but that seems to be a leading project on a well-supported phone (compared to the rest).

deleted by creator