Check whether your BIOS settings show the system clock UTC or adjusted to your timezone.

Windows stores hardware clock time in your local timezone. Other operating systems usually store it in UTC. If you’re dual booting, this could cause issues.

It’s also possible that saving the current time to the hardware clock in silverblue/secureblue is misonfigured in some way.

Is the video player application itself muted in pipewire? What’s the output device set to?

You can check these things with an application like pavucontrol. Pipewire (and pulse) have a default audio device, but individual applications can set a different audio device if they want to.

Another great category of utilities for pipewire is virtual patchbays. If you’re looking for something simple, helvum or qpwgraph are geat. For all the technical details in a GUI, coppwr provides a good experience.

The exact numbers for when it messes something up, but keeps running, are unknown and highly ubpredictable.

According to above post, about 10% of firefox crashes (more numbers found in the post) are caused by this stuff. It’s not unreasonable to say those crashes could’ve had the bitflip happen on content instead, changing maybe a character on the page or something.

Note that it’s not 10% of users, as that’s reslly hard to figure out. Someone with bad RAM will likely crash more often.

Simple stuff like a calculator can be just as broken by a bitflip as more complex things. You wouldn’t want your calculator to say 1 + 1 = 2049.

If you want to rely on your computer, ECC RAM is required.

Arch isn’t exactly intended for beginners, and the “windows is more bloated than Linux” thing applies for pretty much every Linux distro.

If you’re willing to spend a significant amount of time learning and tinkering, a distro like Arch could provide what you need. However, if you’re just starting out, you might want to start with something easier. Distros like Linux Mint or Fedora are plenty lightweight compared to Windows, and they require much less learning to get started actually using your computer.

As for “which distro allows you to use the cheapest PC”, this mainly comes down to how much effort you’re willing to put in, not necessarily the distro you use. At a certain point, a desktop computer will “just work” for basic desktop tasks, the distro doesn’t change much there.

If I had to pick one, Arch. I already use it a lot, so it’s familiar. I know my way around the package manager and how to create packages, so even when things aren’t available for Arch out of the box, I can make it work.

It’d be kind of a hassle trying to keep anywhere close to 100% server uptime, but for my own personal stuff that shouldn’t be that big of an issue, as I can fix it when I have the time.

For desktop, I basically can’t do stable release. I frequently mess with new projects requiring the latest versions of everything, which is a near impossible task on stable-release distros.

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.

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.

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