Linux Fu: Fake Webcams Have Many Uses

Dealing with text streams is a fundamental skill for the Linux power user. You can sort, merge, and search text files easily from the command line. What if you could do the same thing with video? Well, you can. Maybe you want to add a logo to a webcam feed before sending it to a conference app. Maybe you want to blur, color-correct, or annotate video in real time. Or perhaps you want to inject prerecorded video into Zoom while pretending it is a live camera. Linux can do all of this, and the key ingredient is usually the same: a loopback video device.

The basic idea is simple. Instead of an application reading directly from /dev/video0, you create a fake camera device using the v4l2loopback kernel module. Your software pipeline writes processed video into the fake camera, and applications read from it as if it were a normal webcam. The result is surprisingly powerful.

Continue reading “Linux Fu: Fake Webcams Have Many Uses”

Linux Distributions And Who Is Responsible For The Software

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”

A phone running the XFCE desktop environment is placed on a desk, with a wireless keyboard in front of it.

Linux On Android Provides Inexpensive, Powerful Computing

In some parts of the world it’s common for cell service providers to sell new phones at a price significantly below market value, with the caveat that these phones are locked to that service provider alone. It’s questionable whether this practice is good for consumers, but as [Gabriel Broussard Korr] notes, it’s an opportunity for hackers: since it’s possible to run a Linux environment on these phones, they make an inexpensive source of quite powerful computing hardware.

In this case, [Gabriel] was using the Moto G Power 2024, which has 128 GB of storage, 12 GB of RAM, and costs less than $50 when carrier-locked. Rather than trying to install a mobile-oriented Linux distribution (such as postmarketOS), [Gabriel] installed Termux, a terminal emulator which provides a Linux environment within Android. Before doing this, he set up the phone and configured a number of settings for a better Linux experience. Since automatic updates can interfere with these settings, and since none of the provided settings effectively disable these, he used NetGuard to block Internet access from the updater app and from Google Play services.

The next step was to actually install Termux, as well as an X11 extension and an app which exposes an API for Termux. The desktop environment (XFCE in this case) was installed through Termux, and [Gabriel] wrote a shell script to go through the steps of starting it. XFCE worked well on mobile devices because of its full-desktop zoom capability. Even running Linux indirectly, the experience was smooth; [Gabriel] found that GIMP, Shotcut, and VS Code all performed well.

It’s not quite the same set of software, but we’ve previously featured a guide to setting up a similar Linux environment using Termux and AnLinux. Lindroid provides a similar containerized Linux environment; on the other hand, you can also use postmarketOS to make a server from an old phone.

Linux Fu: The Bluetooth Regression

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

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!]

How The Banana Pi BPI-R4 Pro Violates The First Rule Of OpenWRT Club

As fun as ARM and RISC-V single-board computers (SBCs) are, all too often getting the most out of the hardware requires the use of an unofficial firmware image. So too with the Banana Pi BPI-R4 Pro router SBC that has been out for a while, as OpenWRT support for it still very much unofficial. This is where [Interfacing Linux] goes on a bit of a rant while assembling one of these puppies into a sleek metal enclosure.

The first rule of OpenWRT Club is of course that you never run an unofficial image on any hardware that’s part of any network you care about. This is somewhat upsetting, as the testing shown in the video below reveals that performance is great when running it.

Currently OpenWRT support is painfully working its way through development, per the OpenWRT PR thread, so there’s hope that official support will appear at some point. As with all of such SBCs the question is always whether official support appears before the hardware has been rendered firmly obsolete. Until then the community Debian 13 image might actually be safer.

Continue reading “How The Banana Pi BPI-R4 Pro Violates The First Rule Of OpenWRT Club”

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

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.