The KDE desktop’s new login manager (PLM) in the upcoming Plasma 6.6 will mark the first time that KDE requires that the underlying OS uses systemd, if one wishes for the full KDE experience. This has especially the FreeBSD community upset, but will also affect Linux distros that do not use systemd. The focus of the KDE team is clear, as stated in the referenced Reddit thread, where a KDE developer replies that the goal is to rely on systemd for more tasks in the future. This means that PLM is just the first step.

In the eyes of KDE it seems that OSes that do not use systemd are ‘niche’ and not worth supporting, with said niche Linux distros that would be cut out including everything from Gentoo to Alpine Linux and Slackware. Regardless of your stance on systemd’s merits or lack thereof, it would seem to be quite drastic for one of the major desktop environments across Linux and BSD to suddenly make this decision.

It also raises the question of in how far this is related to the push towards a distroless and similarly more integrated, singular version of Linux as an operating system. Although there are still many other DEs that will happily run for the foreseeable future on your flavor of GNU/Linux or BSD – regardless of whether you’re more about about a System V or OpenRC init-style environment – this might be one of the most controversial divides since systemd was first introduced.

Top image: KDE Plasma 6.4.5. (Credit: Michio.kawaii, Wikimedia)

hackaday.com/2026/02/02/kde-bi…

[XYZAiden]’s concept for a flexible robotic gripper might be a few years old, but if anything it’s even more accessible now than when he first prototyped it. It uses only a single motor and requires no complex mechanical assembly, and nowadays 3D printing with flexible filament has only gotten easier and more reliable.

The four-armed gripper you see here prints as a single piece, and is cable-driven with a single metal-geared servo powering the assembly. Each arm has a nylon string threaded through it so when the servo turns, it pulls each string which in turn makes each arm curl inward, closing the grip. Because of the way the gripper is made, releasing only requires relaxing the cables; an arm’s natural state is to fall open.

The main downside is that the servo and cables are working at a mechanical disadvantage, so the grip won’t be particularly strong. But for lightweight, irregular objects, this could be a feature rather than a bug.

The biggest advantage is that it’s extremely low-cost, and simple to both build and use. If one has access to a 3D printer and can make a servo rotate, raiding a junk bin could probably yield everything else.

DIY robotic gripper designs come in all sorts of variations. For example, this “jamming” bean-bag style gripper does an amazing, high-strength job of latching onto irregular objects without squashing them in the process. And here’s one built around grippy measuring tape, capable of surprising dexterity.

youtube.com/embed/8F8gctNCGyE?…

hackaday.com/2026/02/02/print-…

Hackers have been building their own basic oscilloscopes out of inexpensive MCUs and cheap LCD screens for some years now, but microcontrollers have recently become fast enough to actually make such ‘scopes useful. [NJJ], for example, used a pair of Raspberry Pi Picos to build Picotronix, an extensible combined oscilloscope and logic analyzer.

This isn’t an open-source project, but it is quite well-documented, and the general design logic and workings of the device are freely available. The main board holds two Picos, one for data sampling and one to handle control, display, and external communication. The control unit is made out of stacked PCBs surrounded by a 3D-printed housing; the pinout diagrams printed on the back panel are a helpful touch. One interesting technique was to use a trimmed length of clear 3D printer filament as a light pipe for an indicator LED.

Even the protocol used to communicate between the Picos is documented; the datagrams are rather reminiscent of Ethernet frames, and can originate either from one of the Picos or from a host computer. This lets the control board operate as an automatic testing station reporting data over a wireless or USB-connected network. The display module is therefore optional hardware, and a variety of other boards (called picoPods) can be connected to the Picotronix control board. These include a faster ADC, adapters for various analog input spans, a differential analog input probe, a 12-bit logic state analyzer, and a DAC for signal generation.

If this project inspired you to make your own, we’ve also seen other Pico-based oscilloscopes before, including one that used a phone for the display.

hackaday.com/2026/02/02/a-high…

[Dave] over at Usagi Electric has a mystery on his hands in the form of a computer. He picked up a Motorola 68000 based machine at a local swap meet. A few boards, a backplane, and a power supply. The only information provided is the machines original purpose: gas station pump control.

The computer in question is an embedded system. It uses a VME backplane, and all the cards are of the 3u variaety. The 68k and associated support chips are on one card. Memory is on another. A third card contains four serial ports. The software lives across three different EPROM chips. Time for a bit of reverse engineering!

[Dave] quickly dumped the ROMs and looked for strings. Since the 68k is a big endian machine, some byte swapping was required to get things human readable. Once byte swapped, huge tables of human readable strings revealed themselves, including an OS version. The computer runs pSOS, an older 68k based real time operating system – exactly what one would expect a machine from the 80’s to run.

The next step was to give it some power and see if the gas station computer would pump once again. The LEDs lit up, and a repeating signal showed up from one of the serial ports. The serial connections on this machine are RS-485. Not common for home computers, but used quite a bit in industrial embedded systems. Unfortunately, the machine wouldn’t respond to commands sent from a terminal. The communication protocol remained a mystery.

Since this video has gone up though, several people have provided a wealth of information at the vintage-micros channel over on [Dave’s] Usagi Electric Discord.

Gas pumps are a bit of a departure from [Dave’s] usual minicomputer work. We’re no strangers to embedded systems here though.

youtube.com/embed/i0Qw8GrOcp0?…

hackaday.com/2026/02/02/usagis…

Does vibe coding risk destroying the Open Source ecosystem? According to a pre-print paper by a number of high-profile researchers, this might indeed be the case based on observed patterns and some modelling. Their warnings mostly center around the way that user interaction is pulled away from OSS projects, while also making starting a new OSS project significantly harder.

“Vibe coding” here is defined as software development that is assisted by an LLM-backed chatbot, where the developer asks the chatbot to effectively write the code for them. Arguably this turns the developer into more of a customer/client of the chatbot, with no requirement for the former to understand what the latter’s code does, just that what is generated does the thing that the chatbot was asked to create.

This also removes the typical more organic selection process of libraries and tooling, replacing it with whatever was most prevalent in the LLM’s training data. Even for popular projects visits to their website decrease as downloads and documentation are replaced by LLM chatbot interactions, reducing the possibility of promoting commercial plans, sponsorships, and community forums. Much of this is also reflected in the plummet in usage of community forums like Stack Overflow.

(Credit: Koren et al., 2026)
If we consider this effect of ‘AI-assisted’ software development to be effectively the delegating of the actual engineering and development to the statistical model of an LLM, then it’s easy to see the problems here. The LLM will not interact with the developers of a library or tool, nor submit usable bug reports, or be aware of any potential issues no matter how well-documented.

Although the authors of this paper are still proponents of ‘AI technology’, their worries seem well-warranted, even if it’s unclear at this point how big the impact is going to be. Software ecosystems like those involving JavaScript, Python, and web technologies are likely to suffer the impact from vibe coding first, as their audiences appear to be more into such vibes, and the training sets were largest.

It’s also a topic that is highly controversial, ever since Microsoft launched GitHub Copilot in 2021. Since then we saw reports in 2024 that ‘vibe coding’ using Copilot and similar chatbots offered no real benefits unless adding 41% more bugs is a measure of success.

By the time we hit 2025, we can observe an even more negative mood, with LLM chatbots in general being accused of degrading the cognitive skills of those using them, vibe coding chatbots reducing productivity by 19%, and experienced developers who gave them a whirl subsequently burning them to the ground in scathing reviews.

All of which reinforces the notion that perhaps this ‘AI revolution’ is more of a stress test for human intelligence than an actual boost to productivity or code quality. Despite the authors pitching the idea that OpenAI or Google could toss a few cents the way of OSS projects when their code is being used, the comparison with Spotify is painfully apt, since about 80% of artists on Spotify rarely have their tracks played and thus receive basically no money for their efforts.

With an LLM statistical model we know with extremely high likelihood that only the dependencies that are most prevalent in the training data set will realistically be used for the output, and we expect that we’ll see something similar happen with this vibe coding compensation scheme.

Even today we can already observe many negative effects from ‘AI slop’ in software development. Whether it’ll be something that’ll choke the life out of the entire OSS ecosystem remains to be seen, but it is hard to envision a bright vibe coding future.

hackaday.com/2026/02/02/how-vi…

There are a few possible ways to do a teardown of new electronics like the Apple AirTag 2 tracker, with [electronupdate] opting to go down to the silicon level, with die shots of the major ICs in a recent teardown video. Some high-resolution photos are also found on the separate blog page.

First we get to see the outside of the device, followed by the individual layers of the sandwiched rings of the device, starting with the small speaker, which is surrounded by the antenna for the ultrawide band (UWB) feature.

Next is the PCB layer, with a brief analysis of the main ICs, before they get lifted off and decapped for an intimate look at their insides. These include the Nordic Semiconductor nRF52840 Bluetooth chip, which also runs the firmware of the device.

The big corroded-looking grey rectangle on the PCB is the UWB chip assembly, with the die shot visible in the heading image. It provides the localization feature of the AirTag that allows you to tell where the tag is precisely. In the die analysis we get a basic explanation of what the structures visible are for. Basically it uses an array of antennae that allows the determination of time-of-flight and with it the direction of the requesting device relative to it.

In addition to die shots of the BT and UWB chips we also get the die shot of the Bosch-made accelerometer chip, as well as an SPI memory device, likely an EEPROM of some description.

As for disabling the speaker in these AirTag 2 devices, it’s nestled deep inside, well away from the battery. This is said to make disabling it much harder without a destructive disassembly, yet as iFixit demonstrated, it’s actually fairly easy to do it non-destructively.

youtube.com/embed/UjUIXqiAIgA?…

hackaday.com/2026/02/02/teardo…

Although generally described as a document format, PDFs have ballooned from a Postscript-lite format into a mutant featuring XML and JavaScript support, basically turning what once was a fairly simple format into an interactive page. Naturally, this has to be used for good, and that is why we have the Doom PDF project, as well as [Game of Tobi] using that project as the inspiration for a Super Mario 64 port based on the decompiled source code.

The nice thing about the Super Mario 64 version is that it’s stand-alone, running from a 23.5 MB PDF, unlike the Doom PDF which runs the game in DOSBox. The compromise is that Super Mario 64 PDF runs at just a few FPS, with the output in glorious ASCII.

What enables this feat is to open the PDF in a viewer that supports JavaScript, with the PDF.js that comes with most browsers generally allowing for integrated JS in the PDF to be executed. Unfortunately [Game of Tobi] hasn’t released source code for this project, but we hope that this is forthcoming.

While one can argue about the practicality of this whole demonstration from a gaming perspective, it definitely shows that PDF as a format has gotten way out of hand now that it’s even overrun with hellspawn and Italian plumbers.

youtube.com/embed/a0F08py5Z4M?…

hackaday.com/2026/02/02/runnin…

We’re used to handheld Linux devices of varying usefulness appearing on a regular basis, but there’s something about the one in a video from [Rootkit Labs] which sets it aside from the herd. It’s a fork of a conference badge.

The WHY2025 badge had pretty capable hardware, with an ESP32-P4, a really nice screen, and the lovely SolderParty keyboard. Here it’s been forked, to become a carrier board for their previous project, the Flipper Blackhat. This is a Linux add-on for the Flipepr Zero, and it seems that plenty of people wanted it in a more useful context. The result is something that looks a lot like a WHY badge, but running Linux.

It’s a great shame when badges end up lying unused after the event, and ones like the WHY 2025 badge are a serious effort to make something that endures. Here, the badge endures in spirit by being forked and re-engineered, and we like it a lot. The full video is below the break.

youtube.com/embed/QxqeU8ZfaYg?…

hackaday.com/2026/02/02/an-eve…

Horoscopes are a great way to pass a boring lunchbreak, and an excellent excuse for ending a ill-considered relationship. They’re also a hilarious way to handle CPU scheduling under Linux, thanks to the work of [Lucas Zampieri].

The project is called scx_horoscope, and it’s a sched_Ext scheduler that makes its CPU scheduling choices based on what the heavens are doing in real time. Different tasks are handled based on different astronomical objects. For example, the Sun represents life force, and thus grants boons to key system processes. The Moon, an emotive influence, rules over interactive processes like shells and terminals. Mercury, as the god of communication, handles network and IO tasks, and so it goes from there. It’s not just a surface level thing, either—[Lucas] has implemented the influences of the elements of fire, air, earth, and water, and there are negative timeslice penalties on associated tasks when a given planet lands in retrograde.

You can argue whether or not the broader motions of the heavens have any impact on our lives based on the time and circumstances of our birth. But you can’t argue that scx_horoscope really will influence how your computer runs based on the dance of the planets in the sky. Mostly, though, we concern ourselves with astronomy rather than astrology around these parts!

[Thanks to Benjamin for the tip!]

hackaday.com/2026/02/01/cpu-sc…