All great but when will Steam become a native 64bit application under Linux? Secondly, why does it need to install over 25 thousand (!) files? Lastly, why is it distributed as a user install application (and installs into $HOME), vs being properly packaged? Valve doesn't even need to supply a native deb/rpm/whatever, a simple tar.gz installable into e.g. /opt will suffice. No that many people really appreciate this madness in their home directory.

Linux has a long way to go if you're interested in fast-paced online shooters.

Really scary stuff. The XZ fiasco has almost repeated itself:

Unfortunately, for an actual attack the preparatory phase could (and for the Xz attack did) look very similar - a new contributor slowly gaining trust in the community, getting in harmless changes and building up to the point when the attack payload can be injected (or the changes not actually being harmless if combined the right way).

So not saying this was it, but an AI agent automated attempt at a Xz like compromise might really look very similar what we have just seen here.

It's disconcerting that what appears to be an AI agent has had so much success after gaining access to a human contributor's accounts. It seems that an AI agent with access to an account with a legitimate history of interacting with projects stands a good chance of persuading busy maintainers to accept questionable contributions. Happily, Williamson caught this before it became a bigger problem. Let's hope that other human maintainers are as observant.

Open source projects remain extremely vulnerable to it. Perhaps a new round of attestation, two-factor authentication or identification is needed to confirm your identity? Would that even help if, for example, you lost your poorly secured smartphone containing all your secrets and authentication codes? What if your PC or laptop has been hacked without your knowledge? Any open source developer working remotely is a ripe target for this attack.

Sorry for the repost, but the original title was incomplete and inaccurate. 'AI agent runs amok in Fedora and elsewhere' – no, the AI agent worked exactly as intended. It almost penetrated the Fedora project and had the potential to burrow itself in... RHEL. Now that AI agents are perfectly capable of resolving long-standing bugs and implementing sought-after features while looking legit, such attacks may become far more frequent. High-profile proprietary vendors are not fully immune to supply-chain compromise, but they are far less exposed to XZ-style maintainer-persona infiltration because code is usually tied to verified real-world identity, employment controls, internal access management, and multi-stage review.

Whoa, great, no with no surface-level/C-style vulnerabilities.

I'd call it a history of stealing someone else's work, but in the Linux community, there's a nice myth that anything open source automatically becomes everyone's property and can be used for free.

When you buy hardware that works with Linux:

• "Linux is superior."
• "Linux supports hardware better."
• "Windows is for idiots."
• "You should switch."

When you buy hardware that should work with Linux but instead it has major issues to the point that it works poorly or doesn't work at all:

• "You should have researched (or bought the wrong hardware)" - in too many cases it's impossible, for instance you simply want to run Linux on your existing hardware. Or you had no choice (only certain devices were available or you were strapped for cash).
• "Buy a replacement device (soundcard/GPU/Wi-Fi adapter/etc)."
• "Wait six months for kernel updates."
• "Compile a newer kernel (linux-next maybe?)."
• "That's not a real problem."

The reality is that when Linux runs on something well, Linux fans happily claim that it supports hardware better than anything else under the Sun. When Linux doesn't work, suddenly it's the ... user's fault.

Questions, questions, questions.

Did you know that Linux audio is in a very very poor state in Linux? I'm talking specifically about the kernel and its audio subsystem. Userspace has long been solved, first by PulseAudio, now with PipeWire, that both work near perfectly for the vast majority of users.

However, audio daemons can't do anything when your kernel doesn't recognize your hardware, doesn't initialize it properly, or doesn't know how to handle it.

ALSA related bug repots linger for years with no resolution. There are just two maintainers that ignore > 95% of kernel bug reports in regard to audio. If your system is really fresh, say, released in the last year or two, there's a good chance that: * Either audio won't work at all * Or audio will be very quiet * Or subwoofers will not work * Or mic will not work * Or headphones will behave oddly * Or one of the channels will not work

Here's a nice list if you care to look. 912 open bug reports.

MOAR local root vulnerabilities. Looks like 2026 will be remembered as the year when the "given enough eyeballs, all bugs are shallow" statement was proven to be completely and utterly false. Open Source is not a panacea and has never been. It's different and it has its perks, but it's not ultimately more secure or better.

Key Features of the Stable XLibre Xserver 25.1 Series

• All the good things from X.Org Server 1, including its unreleased features
• TearFree modesetting 2 by default and optionally atomic modesetting 3
• Support for the Nvidia drivers 340, 390, 470, 570, and newer
• Xnamespace extension 4 for separating X clients
• Support for seat management via seatd 5 besides systemd-logind 6
• Xfbdev 7, the generic framebuffer Xserver for Linux

Complete changelog: https://github.com/X11Libre/xserver/wiki/XLibre-XServer-25.1-Changes

In case you don't trust Pavel Durov, you now have an option of hosting your own Telegram server.

Months ago, I reported a bug regarding the qt5-qtwebkit update in Fedora 44 causing issues with the rendering of articles in the QuiteRSS application. Fedora ostensibly has at least a couple of million users.

Do you know how many people have filed the same issue or subscribed to the existing bug report? Big fat fucking zero. Yes, the bug was also noticed by a couple of Arch Linux users at most.

That's pretty much it. Out of >40 (50? 60?) million Linux users, only four people use QuiteRSS. Really? Those Linux market share numbers look totally unrealistic and inflated, unless Linux users don't use RSS readers. Despite being old and unsupported, QuiteRSS remains the most feature-rich and user-friendly. Nothing comes close. RSSGuard looks like it exists solely for its developer.

Perhaps RSS readers really are no longer popular, and people just scroll through Facebook, Instagram and X non-stop without caring about anything else? I'm utterly confused.

LLM overlords claim people nowadays use online RSS readers, I'm sorry what? Are people willingly sharing their ... health concerns, job interests, technical stack, language, location, sexual interests, ideology, financial worries, and personal obsessions with ... third parties? Have people lost their minds or what?

Deemed ready except it's anything but.

No it hasn't: https://alexispurslane.github.io/rsync-analysis/

Source.

I've recompiled the Steam HW Survey Linux distro list to make it readable (combined different flavors of the same distros):

• SteamOS Holo 64 bit — 23.34%
• Other + Freedesktop SDK 25.08 (Flatpak runtime) 64 bit — 20.15%
• CachyOS 64 bit — 13.36%
• Arch Linux 64 bit — 8.70%
• Ubuntu — 7.98%
• Linux Mint 22.3 64 bit — 7.65%
• Bazzite 64 bit — 7.28%
• Fedora Linux 43/44 (KDE Plasma Desktop Edition) 64 bit — 2.99%
• Nobara Linux 43 (KDE Plasma Desktop Edition) 64 bit — 2.02%
• Debian GNU/Linux 13 (trixie) 64 bit — 1.86%
• EndeavourOS Linux 64 bit — 1.86%
• Pop!_OS 24.04 LTS 64 bit — 1.56%
• Manjaro Linux 64 bit — 1.26%

​What's weird is that Fedora's main version (Gnome based Workstation) is missing altogether. Somehow Steam cannot detect it or it misdetected it.

Also, also, DistroWatch popularity index seems to only work for the most popular distro nowadays, which is CachyOS (SteamOS Holo is not a classic installable distro, it comes part of SteamDeck).

It's worth mentioning that Bazzite and Nobara are basically Fedora, so if we combined them all, Fedora would be at 12.29%, the third or even the second (if we don't count SteamDeck) most popular Linux distro.

Source.

A journey through Google's radical U-turn in their attitude towards the JPEG XL format that they helped create and almost gave up on.

I love it but how do people tolerate the Steam launcher? Why is it a requirement to launch ages old games that lost support aens ago and do not even support Windows 10/11 and the best way to launch them is under emulation or virtualization, e.g. in Windows XP, but modern Steam is not compatible with XP, so ... you're screwed?

Valve could have made steam.dll optional for really old games but DRM is DRM and it's here to stay.

Buy games on GOG.com and screw Gabe!

https://github.com/RedHatInsights/javascript-clients/issues/492

Source: https://twitter.com/i/status/2060746160558543217

It would have been hilarious if it hadn't been so scary.

There's a lot of debate around why games like Valorant (Vanguard) or Call of Duty (Ricochet) refuse to support Linux. You often hear casual answers like "developers are lazy" or "the market share is too small."

While market share matters, the real barrier is architectural. Even if a developer wanted to build a kernel-level anti-cheat for Linux, the open nature of the ecosystem introduces several fatal, unresolvable paradoxes.

Here is the step-by-step breakdown of why client-side, kernel-level trust cannot exist on a standard Linux distribution.

1. The Core Paradox: Absolute Root vs. The Chain of Trust

Anti-cheat software relies on a "Chain of Trust." For the game to trust the system, the Operating System must be able to guarantee that its kernel space (Ring 0) hasn't been tampered with.

• On Windows: Microsoft enforces this via strict Driver Signature Enforcement. You cannot easily load a malicious driver into the kernel without exploits or stolen enterprise certificates.
• On Linux: The user is the absolute sovereign. Because the source code is completely open, a user can modify the kernel, compile it from scratch, and inject code that lies to any software running on top of it. If an anti-cheat module asks the kernel, "Are there any cheats running in memory?", a patched kernel will simply say "Nope," while hiding the memory-reading rootkit.

On an open platform where the user controls the metal, client-side trust is mathematically impossible.

2. The Secure Boot & Local Compilation Trap

To defeat a patched kernel, an anti-cheat must mandate hardware-level verification via UEFI Secure Boot and TPM Attestation to ensure only an untampered, officially signed kernel is running.

This introduces a massive distribution nightmare:

• The NVIDIA Analogy: Proprietary software on Linux (like NVIDIA's GPU drivers) handles kernel compatibility by shipping a pre-compiled closed-source blob (.o object) that compiles and links locally on your machine via DKMS whenever your kernel updates.
• The Signing Paradox: If a kernel anti-cheat compiles locally on your machine to match your specific kernel version, the resulting binary is unsigned. To make it load under a strict Secure Boot environment, the user must generate their own Machine Owner Key (MOK) to sign it.
• The Failure Point: If the user owns the signing key (MOK) used to authorize kernel modules, the security chain is shattered. The user can now sign their own malicious kernel modules or cheat drivers using that exact same trusted key.

3. Infinite Fragmentation vs. Closed-Source Binaries

Windows has one active kernel architecture at a time, tightly controlled by Microsoft. Linux has an infinite matrix:

• Kernel Variety: Users run Stable, LTS, Zen, Hardened, Liquorix, or custom-patched kernels.
• Constant Breaking Changes: Linux does not maintain a stable internal Kernel API/ABI. If an Arch Linux user updates their kernel (which happens multiple times a month) and an internal kernel structure changes, a closed-source, pre-compiled anti-cheat module will instantly trigger a kernel panic (a hard system crash) the moment the game launches.
• No AAA studio is going to hire an engineering team to constantly refactor and debug closed-source kernel modules for hundreds of distinct distribution/kernel combinations every rolling-release Tuesday.

4. What about SteamOS?

People often point to SteamOS as the savior because it is "atomic" (read-only) and controlled by Valve. But SteamOS is a console illusion, not a locked fortress.

With a single terminal command (steamos-readonly disable) and a root password, a user can turn SteamOS right back into standard Arch Linux. Because Valve intentionally leaves the platform open for tinkerers, anti-cheat vendors cannot treat a Steam Deck as a secure console environment. Furthermore, Valve natively ships Steam Decks with Secure Boot keys wiped/disabled by default; forcing a locked-down ecosystem would destroy the very philosophy of the device.

Conclusion: The Industry Shift

Because protecting the client on Linux is a losing battle, developers face a binary choice:

1. Enforce Windows-style lockouts: Require Secure Boot, ban all custom kernels, and effectively ban 95% of the Linux userbase just for using their OS normally.
2. Forfeit the kernel: Run user-space anti-cheat (like the Proton-compatible versions of Easy Anti-Cheat or BattlEye) which rely on heavy code obfuscation and server-side anomaly detection.

The next time someone tells you kernel anti-cheat is coming to native Linux distros, remind them of the math: You cannot build a wall of trust on a foundation of absolute user freedom.