linux

693 Articles

Linux Distributions And Who Is Responsible For The Software

May 27, 2026 by 58 Comments

The topic of downstream and upstream is an important one in the Linux ecosystem, where from one base distribution you can go many layers of distros deep before even looking at all the other base distributions. Within that veritable jungle you get questions about who is responsible for packaging software, where to report bugs found with a specific application, as well as what ‘LTS’ truly means in a consumer context. These and other points are raised in a recent video by [Brodie Robertson], with many examples of things going tragically wrong.

There’s a good argument to be made that ultimately it is the distro that is responsible for the software that they provide via their repositories. As [Brodie] shows in the video, there are a few cases where an ‘LTS’ distro uses an old version of some software that contains a bug that has been fixed a while ago, so reporting it to the developer is rather pointless, while the distro maintainers should fix it with backporting of patches or updating the version.

From an end user experience this also makes the most sense, as in the end they just want to have the Windows experience of downloading a proverbial installer, clicking through whatever dialogs pop and have working software. If the software is provided via the distro, it is their responsibility, the same way that you contact the developer if you get a DEB or RPM from a GitHub project page and it doesn’t work.

This current Linux Chaos Vortex can be called a major issue when e.g. FreeBSD has no such upstream/downstream issues, with cross-platform installers being basically impossible on Linux ever since the Linux Standard Base effort died.

Perhaps Linux will get a distroless future, however, which may finally herald that Year of the Linux Desktop.

Continue reading “Linux Distributions And Who Is Responsible For The Software” →

Linux Fu: The Bluetooth Regression

May 26, 2026 by 23 Comments

There’s a line in a [Weird Al] (no relation) song that says, “I upgrade my system at least twice a day…” I know how that is. I primarily use a rolling distro, OpenSuse Tumbleweed, and if I’m having a problem that I’m too lazy to run down, it is extremely tempting to do an upgrade and see if it just happens to fix the problem.

Of course, the problem is often caused by a previous upgrade. Recently, I’ve been having a lot of trouble with the NVIDIA proprietary drivers, so I updated them yet again. After a huge amount of effort to sort out the video problems, I found that the latest kernel didn’t like my MediaTek Bluetooth adapter, which is built into the motherboard’s WiFi chipset.

This post isn’t about how to fix your Bluetooth problem. You probably don’t have the same setup I do, and even if you do, it will be sorted out in a week or two anyway. But how I temporarily fixed this issue is worth documenting. The details are going to apply to Tumbleweed and this particular adapter, but the general approach should work anywhere with any sort of kernel module problem.

My Own Fault

Part of my problem is my own fault, of course. I have a complex disk setup and do not use the recommended btrfs root file system. That means I can’t do the snapshot thing where I can just undo a bad upgrade. If I did, then sure, I should just roll back and wait for an upstream fix.

I do have “normal” backups, but they are not always totally up to date. Worse, I have found that for things like NVIDIA, the user stuff and the kernel module stuff have to match up. That makes it very hard to roll back a kernel with older modules. The modules themselves live with the kernel, but the user space stuff gets pushed out. Or, if you uninstall things, it uninstalls it for all kernels.

Truthfully, NVIDIA and others like that should keep all the user space stuff in a kernel-specific place, and then symlink it at boot to /usr/bin or wherever. But they don’t. In the end, I didn’t want to go through the trouble of rolling things back and decided to push ahead.

Continue reading “Linux Fu: The Bluetooth Regression” →

The Team Behind The Flipper One Needs Your Help

May 22, 2026 by 33 Comments

You’ve probably heard of the Flipper Zero, a pocket-sized device that packs in lots of great hacking potential. The team behind it has now turned their efforts towards developing the Flipper One, and they’re calling out for help from the broader community. 

The Flipper One is not intended to be a replacement or sequel for the Flipper Zero. Instead, it’s designed to exist as a entirely new device in its own segment. The team is hoping to build “the most open and best-documented ARM computer in the world,” as they attempt to create a Linux cyberdeck of grand capability. Where the Flipper Zero has found great use for interrogating and investigating low level communications, like IR and NFC, the Flipper One is intended to go to a higher level, working with protocols like Wi-Fi, 5G, and Ethernet in the networked world.

The new device will be based around a co-processor architecture, where a microcontroller is paired with a capable CPU for great flexibility. It will also feature all the high-speed interfaces you’d expect, like PCI Express, USB 3.0, SATA, and Gigabit Ethernet. It’s a proper, capital-C Computer in that regard. The intention of the team is also to redefine some of the typical Linux experience, by creating GUI wrappers around certain traditional CLI utilities. It should go a long way to giving the software the same cyberdeck feel that the current prototypes embody in their hardware design.

If you want to learn more and get involved, head over to the Flipper One Development Portal and dive in. Alternatively, you might like to get up to speed with some of our prior reporting on the Flipper Zero. Happy hacking!

[Thanks to Andrew for the tip!]

This Week In Security: AI Generated Reports, More AI Generated Reports, GitHub Chaos, And More Linux Vulnerabilities

May 22, 2026 by 11 Comments

Google’s Project Zero demonstrates a new zero-click exploit for the Pixel 10 phones, showing a full escalation from remote to kernel without user interaction. During the investigation Project Zero found unprotected memory access from userspace in the Tensor G5 video processing chip driver, which allows direct write access to kernel memory.

Using previously discovered flaws in media decoding components — in this case CVE-2025-54957 in the Dolby digital audio decoder — Project Zero modified a Pixel 9 attack to work on the Pixel 10, despite newer protections built into the hardware to harden the system against memory corruption.

The author’s takeaway is mixed. Once the bug on Pixel 9 was reported, one could hope that the Android team would look into similar bugs in their newer systems. On the positive side, though, Project Zero reported the vulnerabilities to the Android team in November 2025 and they were patched in February of 2026, 71 days later. That’s 19 days short of the 90-day timeline.

Continue reading “This Week In Security: AI Generated Reports, More AI Generated Reports, GitHub Chaos, And More Linux Vulnerabilities” →

Wayland Comes To Minecraft

May 21, 2026 by 5 Comments

The overall adoption and implementation of Wayland — intended as a replacement for the decades-old X11 windowing system — in the Linux world has been full of fits and starts. But perhaps the most surprising adopter we’ve seen yet is this Minecraft patch which brings a full Wayland compositor into the game.

This software project, called Waylandcraft, is the brainchild of a developer known as [EVVIE] who spent a considerable amount of time and effort getting this to work. According to a post on GamingOnLinux it was also done the old fashioned way, with no AI involved.

Users wanting to run this compositor need a Linux system to run Minecraft, as well as the Fabric mod loader and a few other tools. For those wishing to show off to their friends, though, they’ll need to do so in-person as streaming the Wayland windows to other users in the server is not possible.

With everything running, you’ll be able to launch arbitrary programs and have the windows placed within the Minecraft world as if they were in-game. Users can place the windows in any orientation and can interact with them like any other desktop environment. [EVVIE] has released all of the code under the GPL for anyone wanting to try it out or build on the project itself.

If you haven’t spun up a Minecraft server at all yet, all you really need is something like an ESP32 to get started.

Continue reading “Wayland Comes To Minecraft“ →

Hackaday Links Column Banner

Hackaday Links: May 17, 2026

May 17, 2026 by 3 Comments

To start things off, we’d like to extend a special thanks to everyone who joined us for Hackaday Europe this weekend in Lecco, Italy. It was 48 hours of fascinating talks, incredible badge hacks, and some of the greatest company you could hope for. For those who couldn’t make it in person, we didn’t forget you — expect to hear more about what went down once we get a chance to catch our collective breath.

That’s not the only thing to keep an eye out for in the coming days. This is your reminder that Amazon will be officially ending support for older Kindles in a few days. After May 20th, any of the megacorp’s e-readers that were introduced before 2012 will be persona non grata, so you should plan accordingly.

The biggest change is that these older devices won’t be able to buy digital books from Amazon, but you can still use them offline, and the fantastic Calibre makes it a breeze to load up content from other sources. To be perfectly honest, we’d advise any Kindle user to decouple their device from the Amazon mothership by using Calibre or even jailbreaking it and installing KOReader, so the end of official support is fine by us. In fact, if a surge of unsupported Kindles brings more attention and users to those projects, that suits us just fine.

Continue reading “Hackaday Links: May 17, 2026” →

After Stumbling From CVE To CVE Will Linux Get A Kill Switch?

May 16, 2026 by 24 Comments

For the few people who have spent the past weeks living under a security rock, the Linux kernel has found itself the subject of multiple severe bugs in the form of Copy Fail and Dirty Frag, both of which allow for privilege escalation. They’ve made many people very upset, and also potentially put many thousands of systems at risk of exploitation. Worse is that system managers are generally left to twiddle their thumbs while waiting for patches to be rolled out. This is where NVIDIA engineer [Sasha Levin] has proposed a ‘kill switch’ for affected kernel functions.

The basic concept seems rather simple, with this feature merely intercepting a call to the affected function and instead returning a predefined return value. This makes it less extreme than hitting a general SCRAM button on the entire kernel, and could theoretically allow the affected systems to keep running until the patched kernel becomes available.

A disadvantage of this is that it obviously modifies the kernel, patching it in-memory so that you need to reboot the system to clear it. Another potential disadvantage is that it opens a potentially massive attack vector, with people in the Cybersecurity sub-Reddit roundly rejecting the idea. Amidst all the other anxious conversions there is also the concern that this particular patch was at least partially generated by an LLM (Claude Opus 4.7) , so one may hope that if it does gets merged into mainline it’ll at least be properly vetted by multiple pairs of well-caffeinated human eyes.