Roastidio.us Tagged with linux

Homebrew Release: Warnel Chawpiovs v1.8.0: adds "Agents of S.H.I.E.L.D." expansion and GUI Improvements - Wololo.net

Sun, 25 Oct 2026 17:48:32 +0000

You can now try this game in your browser at https://wololo.net/wc.

Heads up: we now have a discord server to discuss Warnel Chawpiovs! Feel free to join at https://discord.gg/suP7m7uafT

I’m happy to release version 1.8.0 of “Warnel Chawpiovs”, a homebrew game for PC (Windows, Linux, MacOS versions are now available), Nintendo Switch, and Android.

Since earlier this month, the game can now be played in your browser, and you can try it right now without installing anything, at https://wololo.net/wc.

I still encourage people to actually download the binaries. If you download the game on your device, and after all assets have been downloaded, you technically don’t need any internet connection to play the game with the native versions. And you don’t depend on my server being online to play.

Version 1.8.0 brings some significant changes to the hero/scenario selection menu (see below). With now more than 50 heroes and more than 40 scenarios, the selection screen was getting crowded, we’ve split it into two parts.

This version also brings The Agents of SHIELD expansion, as well as more hero packs. That’s 5 more heroes (Maria Hill, Nick Fury, Nova, X-23, and Storm) and 5 new scenarios (Black Widow, Batroc, MODOK, Citizen V, and Baron Zemo).

(By the way, if you’re using and enjoying Warnel Chawpiovs, please do me a favor and spread the word, to friends or on social networks. Having a growing number of users helps me staying motivated to add more cards and features!)

Overall, Warnel Chawpiovs now supports 51 heroes and 43 scenarios, which I estimate represents roughly 60% of all the cards in the original game (excluding campaigns)

This is a fan-created work and is not affiliated with, endorsed by, or sponsored by Fantasy Flight Games. All characters, settings, and related elements are the property of their respective owners.

What is Warnel Chawpiovs ?

Warnel Chawpiovs, aka WC, is a homebrew game for multiple platforms (included, but not limited to, Nintendo Switch, Android and Windows), based on the popular cooperative board game Marvel Champions. WC lets you play the popular card game with full rules enforcement. The game does the heavy lifting of handling all the rules, so you only have to focus on your strategy.

It also includes a full fledged deck editor (which, among other things, can import/export decks from popular fansite marvelcdb.com).

You can play on your own with one or multiple heroes, and there’s also a multiplayer mode, (mutiplayer mode should be considered to be in beta)

Warnel Chawpiovs – What’s new in 1.8.0

Adds support for “Agents of SHIELD” expansion, and 3 additional hero packs:
- New heroes : Nick Fury, Maria Hill, Storm, X-23, and Nova
- New scenarios: Black Widow, Batroc, MODOK, Citizen V, and Baron Zemo

Some GUI updates including a refactored Team/scenario selection menu and a cool animation (well, I think it’s cool) for characters with Aerial
Multiple bug fixes, as always (thanks to BL-Stark and MyGloo in particular for the numerous bug reports!)

1.8.0 Development notes

Agents of SHIELD was so far the most painful expansion to develop with my engine. In terms of the total file size of script definitions, it sits on top with the other “recent” expansions Age of Apocalypse, Mutant Genesis, and Next Evolution. And that’s *after* introducing new concepts to reduce the amount of JSON I had to type. Hopefully the gameplay of these new characters and scenarios is working reasonably well.

There are still lots of bugs in the cards, rules that are not properly taken into account in the engine, but overall I think we’re going in the right direction, with more and more cards behaving the way they should, even in corner cases.

How to install – Windows/Linux

Download the binaries below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

extract anywhere on your computer, then run the binary file (Windows: WC.exe, Linux:WC.x86_64)

How to install – Android

Download the apk below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

Copy the apk to your phone then install it with your phone’s file manager. You will need to enable “unknown sources” in your phone settings in order to install the APK.

Once you start the game it will need to download resources so it is recommended that your first launch is not on an expensive data plan 🙂

How to install – Nintendo Switch

You will need a hacked Nintendo Switch to run this game.

Download the binaries below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

extract the WC folder inside your switch folder on your SD card.

Launch the homebrew Menu in “full speed” mode (not in applet mode). This is done by pressing the Right Should button (R) while launching a cartridge game.

From there, you can run the game

How to install – Mac OS

Download the binaries below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

The Mac OS app isn’t officially signed, so in order to run it you can ctrl + click and select “open”

Running your First Game

The game will attempt to download any missing picture for new cards, as soon as you run it. This happens in the background and you can play while this happens. Again, that step is not needed if you have the appropriate “*.zip” resource files.

Once you’re in the game select “Sivgle Player”, then choose one hero and one villain, then click on launch.

Note: On your very first run, the game will only let you select one hero and one villain. This is intentional, as the game’s “adventure mode” requires you to win games in order to unlock more heroes and scenarios. If you don’t like this you can deactivate it in the options/gameplay menu, this will unlock all content.

Check the Videos below for examples of gameplay

Status of the Switch port

The Switch port is… slow. You might want to overclock your console when you play the game. I know it’s not ideal, but it makes the gameplay much more comfortable.

I would not recommend playing with more than one hero at the moment on Nintendo Switch, if only for performance reasons

Troubleshooting, bug reports, etc…

If you have any feedback or questions you can join us on discord at https://discord.gg/suP7m7uafT . Alternatively, you can use the itch.io community board here: https://frwololo.itch.io/warnel-chawpiovs/community.

Last but not least, you can open issues on the github project, or contact me by email (wagic.the.homebrew at gmail).

Known issues

Multiplayer should be considered early beta
Switch port is slow. You might want to overclock your console
The Mac port should be considered unsupported. I do not own any Apple products, which makes it impossible for me to verify (let alone debug) anything on that version.
There are still lots of issues with specific cards, but feel free to report issues you find on the github
- In particular multiple cards behave incorrectly when playing with more than one hero (e.g. effect targeting the wrong hero, etc…). This isn’t intentional so feel free to report those

Want more details?

check the Readme on github

What’s next:

There is still lots of work to do with this game. I am currently focusing on adding more cards to enjoy with a solo hero.

If by any miracle you are looking at my code and can help, in particular with multiplayer issues, please submit a PR on github

Download

Download page

Or on the project’s github page

OVHcloud CLI: cómo detectar los binarios manipulados y qué falló

Wed, 21 Oct 2026 20:10:03 +0000

El ataque a la herramienta de línea de comandos de OVHcloud, que el 19/10/2026 sirvió durante algo más de hora y media binarios diseñados para robar secretos, no explotó ninguna vulnerabilidad del código: bastó una cuenta de GitHub comprometida y un ajuste de seguridad desactivado. El atacante sustituyó los archivos de descarga de cinco versiones ya publicadas de OVHcloud CLI, de la v0.11.0 a la v0.15.0, y además manipuló el fichero de sumas de comprobación para que todo pareciera legítimo.

Las claves del ataque a OVHcloud CLI en 30 segundos

El atacante usó la cuenta de un colaborador con permisos de escritura y resubió los binarios de cinco versiones existentes.
También alteró checksums.txt, así que comprobar el hash contra ese archivo no servía de nada.
Los binarios estuvieron disponibles entre las 12:47 y las 14:21 UTC; lo detectó el pipeline de un cliente con el hash fijado.
Homebrew, Docker y las compilaciones desde el código fuente no se vieron afectados, según The Hacker News.
Quien ejecutara un binario afectado debe dar por expuestos todos los secretos de esa máquina.

Los hechos básicos los contamos en Revista Cloud, en el artículo sobre las cinco versiones manipuladas del CLI de OVHcloud. Aquí nos centramos en lo que interesa a un equipo de seguridad: cómo saber si un binario es uno de los comprometidos, qué falló en la cadena de publicación y qué controles habrían evitado o reducido el impacto.

Cómo comprobar si un binario es uno de los manipulados

OVHcloud no ha publicado todavía indicadores de compromiso completos, pero la reconstrucción de The Hacker News aporta varios para la versión v0.15.0. El más directo es el hash del paquete para Linux ARM64:

Paquete manipulado (v0.15.0, Linux arm64):
SHA-256 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb

Paquete original (v0.15.0, Linux arm64):
SHA-256 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0

Como la herramienta está escrita en Go, el propio binario guarda información de cómo se compiló. Se puede consultar con go version -m indicando la ruta del ejecutable:

go version -m /ruta/al/binario/de/ovhcloud-cli

En el binario manipulado aparece una pseudoversión del tipo v0.15.1-0.20261013083505-5ead8ef9b43d+dirty, que remite al commit 5ead8ef, cuando la etiqueta v0.15.0 apunta al 760fd72. También muestra una línea -ldflags="-s -w" que no tienen las versiones auténticas. Ojo con la marca +dirty: por sí sola no prueba nada, porque la versión limpia v0.16.0 también la muestra.

Para los paquetes de la v0.11.0 a la v0.14.0 no hay hashes públicos del contenido malicioso. Si alguien no puede determinar qué versión descargó ni cuándo, lo prudente es tratar la máquina como comprometida. La incidencia #300 del repositorio ovh/ovhcloud-cli recoge la información que se ha ido compartiendo.

Qué falló en la cadena de publicación

El fallo no está en el código, que sigue intacto, sino en cómo se publicaban las versiones. GitHub permite borrar y volver a subir los archivos adjuntos a una versión ya publicada con el mismo nombre, de modo que la URL de descarga no cambia. El ajuste de inmutabilidad de versiones lo impide, pero solo protege las versiones creadas después de activarlo, y en el repositorio de OVHcloud no estaba activado. Octave Klaba, fundador de la compañía, lo ha reconocido públicamente.

El atacante tampoco necesitó tocar la integración continua: compiló los binarios por su cuenta, a partir de un commit posterior, y los subió a mano. El dato más relevante para cualquier equipo es otro. Al reemplazar también checksums.txt, el atacante neutralizó la comprobación que muchos usuarios hacen al descargar. Un hash que se descarga del mismo sitio que el binario no protege frente a quien controla ese sitio. Lo que sí funcionó fue un hash fijado de antemano en el pipeline de un cliente: la descarga no coincidía, el trabajo falló y el cliente abrió una incidencia pública.

Sobre el origen, los investigadores de OpenSourceMalware sostienen que la cuenta usada llevaba meses comprometida y la relacionan con la campaña GlassWorm. Se basan en un cargador que obtiene su siguiente fase del campo memo de una cartera de Solana, una técnica asociada a esa campaña. Ellos mismos lo presentan como una inferencia, y nada del binario de octubre se ha vinculado todavía a GlassWorm.

Controles que conviene revisar

Si el equipo publica software en GitHub o depende de binarios descargados de versiones de GitHub, estos son los puntos que el caso deja sobre la mesa:

Activar la inmutabilidad de versiones en los repositorios propios, sabiendo que no cubre las versiones anteriores a su activación.
Publicar atestaciones de los artefactos y verificarlas al descargar, por ejemplo con gh release verify-asset, en lugar de confiar en un checksums.txt del mismo origen.
Fijar hashes o versiones exactas en scripts, imágenes base y pipelines, para que un cambio silencioso rompa el proceso en vez de colarse.
Reducir los permisos de escritura a las cuentas que realmente publican y exigir autenticación fuerte, porque una cuenta de colaborador basta para reemplazar binarios.
Rotar secretos desde otra máquina si se ejecutó un binario sospechoso: claves de la API de OVHcloud en ~/.ovh.conf y variables de entorno, claves SSH, tokens de nube y credenciales de Git.

OVHcloud ya ha activado la inmutabilidad, ha publicado la v0.16.0 como versión inmutable y ha prometido un informe posterior con más detalles sobre el binario, incluidos los ficheros que intenta leer y adónde envía la información.

Preguntas frecuentes

¿Cómo sé si tengo un binario manipulado de OVHcloud CLI?

Compara su hash con el publicado para la v0.15.0 de Linux ARM64 y revisa la salida de go version -m: los binarios manipulados apuntan al commit 5ead8ef y muestran un ldflags que no tienen los originales.

¿Por qué no sirvió comprobar el hash con checksums.txt?

Porque el atacante también reemplazó checksums.txt para que coincidiera con los binarios maliciosos. Solo detecta el cambio un hash fijado de antemano o una atestación verificable.

¿Qué es la inmutabilidad de versiones de GitHub?

Es un ajuste que impide modificar los archivos de una versión una vez publicada. Solo protege las versiones creadas después de activarlo.

¿Está confirmado que detrás está GlassWorm?

No. OpenSourceMalware relaciona la cuenta usada con esa campaña, pero lo presenta como una inferencia y no hay vínculo confirmado con el binario.

Fuentes:

YAFFplayer 0.13.0 (FFmpeg-based Audio / Video Player) released

Wed, 21 Oct 2026 09:40:08 +0000

YAFFplayer 0.13 (FFmpeg-based Audio / Video Player)

2026/10/07 JeGX Comment

1 – Download

YAFFplayer win64
(7zip, no-installer)
YAFFplayer linux x86_64
(7zip, no-installer)
YAFFplayer linux arm64
(7zip, no-installer)

Feedback and support:
– Forum thread
– Discord

A new update of YAFFplayer is ready for Windows 64-bit and Linux 64-bit (x86_64 and arm64).

YAFFplayer is a simple audio and video player made with GeeXLab and using the powerful FFmpeg library to read nearly every kind of video and audio files. It’s a standalone and native application for Windows and Linux. And thanks to yt-dlp, YAFFplayer can easily download video files from many youtube-like websites and even videos from Twitter or sounds from Soundcloud.

YAFFplayer 0.13.0 is built with GeeXLab 0.67 and the FFmpeg plugin has been updated with latest FFmpeg 9.0.2.

2 – Changelog

Version 0.13.0.0 - 2026.10.03
- (Windows) change in video download: if video format is not specified 
  (Best MP4 format or custom download format), FFmpeg.exe is 
  no longer used to merge audio and video streams. 
  That allows yt-dlp to download videos with defaut format.
- updated with yt-dlp v2026.09.27.
- updated FFmpeg plugin with FFmpeg 9.0.2.
- updated with GeeXLab 0.67.0.

Related posts:

Fake Kernel Threads Are Hiding Backdoors on Linux Servers and Appliances

Wed, 21 Oct 2026 05:40:11 +0000

Attackers keep disguising malware as Linux kernel worker processes, but careful checks will expose the disguise

On September 5, 2026, Sansec, a security firm that investigates attacks on online stores, reported that attackers were exploiting a zero-day in Magento and Adobe Commerce to install a backdoor written in Rust. The vulnerability is tracked as CVE-2026-75650 and is rated Critical, with a CVSS score of 10.0. Early versions of the backdoor ran under the name [kworker/u:8:0], which is meant to look like one of the Linux kernel’s own worker threads.

Two days later, researchers reported Tengu, a bot modeled on the Mirai botnet malware, which overwrites its process name with a random kworker/%d:%d value. In July, an incident responder found a Go command-and-control (C2) agent running as [kworker/7:2] on a breached OpenCart store, next to a script that dumped the store’s customer order table.

The disguise works because a Linux system runs dozens of real kernel threads with numbered names, and an administrator reading a process list has no reason to notice if there’s an extra. The disguise only goes as deep as the name, because a program running in user space cannot reproduce the properties of a real kernel thread without a kernel rootkit, so defenders can check for those properties instead of chasing each new malware name or hash.

Who should act: detection engineering should add the checks below to Linux servers and to any appliance that exposes a process list, and report back which systems the check cannot run on. Incident response teams should take over if this yields any hits. Network and appliance administrators should find out which of their devices give them a full process listing at all. A device without a process list makes an implant like this harder to find.

Why a fake kernel thread blends in

The Linux kernel does a lot of background work in threads that live entirely inside kernel memory. The kworker threads process queued work for drivers and subsystems, and others such as ksoftirqd, kswapd, migration, and the rcu_ family handle deferred interrupt work, memory reclaim, moving tasks between processors, and synchronization. Because these threads have no command line, ps displays their names in square brackets, for example [kworker/0:1].

Malware can emulate that appearance in two ways. It can overwrite its own argv[0], which changes what ps aux and /proc/PID/cmdline show, or it can call prctl(PR_SET_NAME), which changes the short process name stored in /proc/PID/comm. Some families do both. MITRE ATT&CK, the public catalog of attacker techniques maintained by MITRE, tracks this under Masquerading as T1036.004, Masquerade Task or Service.

None of this is new, but the continued recurrence of this established technique makes it worth another look. Especially given the rising number of exploitation attempts targeting Linux-based infrastructure devices. The United Kingdom’s National Cyber Security Centre (NCSC) documented in its February 2022 analysis of Cyclops Blink, a malware family attributed to the Sandworm group, that the implant “renames its running process to masquerade as a Linux kernel thread.” In June 2024, Trend Micro reported that the Linux version of the Noodle remote access trojan (RAT) spoofs its process name by overwriting argv, using code that matches the older Rekoobe backdoor.

Where this masquerading technique has showed up in 2026

Malware or campaign	What it hit	Name it used	Reported by
StyleSmuggler backdoor	Magento and Adobe Commerce stores, through CVE-2026-75650	`[kworker/u:8:0]`in early samples; `fc-cache` and `chronyd` in later ones	Sansec, September 5, 2026
Tengu bot	Linux servers, routers, and embedded devices	A random `kworker/%d:%d`value	Reverser.Space, as reported by GBHackers, September 7, 2026
Go C2 agent (`watchdogd`)	An OpenCart online store	`[kworker/7:2]`	K.K. Bourdakos, July 3, 2026
Linux Noodle RAT	Linux servers, typically after a web shell	Spoofed process names (specific names not published)	GBHackers, September 16, 2026, citing Trend Micro

According to Cyberpress’s summary of the Sansec findings, StyleSmuggler malware samples observed on September 6 had already switched from the kworker name to fc-cache, one day after Sansec’s report. A detection that keys on the name [kworker/u:8:0] stopped matching new infections within a day. The second detail is that kworker/u:8:0 is not a name the kernel would ever produce. Kernel workers that are not tied to a single processor are named kworker/u followed by a pool number, a colon, and a worker number, as in kworker/u8:2. The attacker’s version has no number after the u and an extra colon, so a simple check on the name format flags it.

Cyclops Blink also came back this year. On September 9, 2026, Cisco Talos, Cisco’s threat intelligence group, reported that a cluster it tracks as UAT-11823, which overlaps in tooling with Sandworm, deployed a Cyclops Blink variant on Cisco Secure Firewall Management Center (FMC), the appliance that manages fleets of Cisco firewalls. The actors gained access via CVE-2026-20079, a Critical authentication bypass (CVSS 10.0) that grants root access to the appliance’s underlying operating system. Talos does not say whether this variant still renames itself as a kernel thread. The 2022 version did, so if you run FMC, the checks below are relevant to you, with the caveat that this is an inference based on the malware’s history, not something Talos reported.

What an impostor kernel thread can’t fake

A real kernel thread has properties that a user-space program can’t reproduce without loading code into the kernel. Every malware sample in the table above runs in user space, so each of these properties gives you a way to catch it regardless of what it calls itself.

Property	Real kernel thread	User-space impostor
Parent process	`kthreadd`, process identifier (PID) 2	Anything else, often PID 1 or a shell
`/proc/PID/exe`	Does not resolve	Resolves to the binary on disk, or shows (`deleted`) if the file was removed
Memory (`VSZ` and `RSS` columns in `ps`)	Both 0	Non-zero
`/proc/PID/cmdline`	Empty	Usually populated
Kernel-thread flag (`PF_KTHREAD`)	Set	Clear
Network sockets	Never owns one	Often owns one
Owner	root	Whichever account launched it

Two name checks also work on a plain-text process listing where none of the metadata is available. The first is the name format problem described above. The second is that a real /proc/PID/comm value never contains a literal [ character. The brackets come from ps when it displays a process with an empty command line, so a process whose own name includes a bracket put it there itself.

The OpenCart case shows how these properties look in practice. Bourdakos noticed that [kworker/7:2] was running as the hosting account rather than root, reported about 724 megabytes of virtual memory and 12 megabytes resident when a real kernel thread reports zero, showed a process state of Sl (consistent with a multi-threaded Go program) instead of the I state of an idle kernel worker, and had started at 04:07, the same time the attacker dropped the web shell. Searching the process list for the real binary name, watchdogd, returned nothing.

An example of the masquerading technique discussed in this post, as detected by Eclypsium: the platform flagged the ENDLESSDOORS backdoor, an implant that hides as a kworker process, because the process posing as a kworker was not a real kernel thread.

Hunting for fake kernel threads on Linux systems

Detection engineering can run these checks today on any Linux host where they have a root shell. The first is a quick visual pass:

ps -eo pid,ppid,user,stat,vsz,rss,comm,args | grep -E '\[(kworker|ksoftirqd|kswapd|migration|rcu_)'

Real kernel threads show a parent of 2, a user of root, and zeros in the VSZ and RSS columns. Anything else in this output deserves a closer look. Compare the comm and args columns as well. A process that only overwrote argv[0] still shows its real name in comm while args shows the disguise, and that mismatch alone is enough to flag it.

The second check is a script that tests the strongest single property, whether the process has an executable file behind it:

#!/bin/bash
# Run as root. Flags processes that present a kernel-thread name
# but are backed by an executable file.
pattern='^\[?(kworker|ksoftirqd|kswapd|migration|rcu_)'
for d in /proc/[0-9]*; do
  pid=${d#/proc/}
  comm=$(cat "$d/comm" 2>/dev/null)
  args=$(tr '\0' ' ' < "$d/cmdline" 2>/dev/null)
  if [[ $comm =~ $pattern || $args =~ $pattern ]]; then
    exe=$(readlink "$d/exe" 2>/dev/null)
    if [[ -n $exe ]]; then
      ppid=$(awk '/^PPid:/{print $2}' "$d/status")
      echo "SUSPECT pid=$pid ppid=$ppid comm='$comm' args='$args' exe=$exe"
    fi
  fi
done

The script checks both comm and the command line, so it catches either renaming method. Run it as root. Without root, readlink fails on other users’ processes and the script silently misses them. A SUSPECT line means a process is claiming a kernel-thread name while running from a file on disk, which a real kernel thread never does. Hand that PID to incident response before anyone kills it.

A few cautions if you extend this logic into a production rule:

Keep the name list to names only the kernel uses. Ordinary daemons such as chronyd and fc-cache rename themselves for legitimate reasons, so StyleSmuggler’s later names will not fit this check and need hash or behavior-based detection instead.
If you add a parent-process test, exclude PID 2 itself. kthreadd‘s own parent is PID 0, so a naive “parent must be 2” rule fires on every healthy host.
Do not test whether /proc/PID/cmdline or /proc/PID/maps is empty by checking the file size. The proc filesystem reports a size of 0 for both files whether they hold data or not. Read the contents instead.
Keep in mind that an attacker who has deployed a kernel-level rootkit can do a much better job at hiding processes and will evade these detections.

Network appliances are where this check gets hard

Firewalls, firewall managers, remote-access gateways, and similar appliances often run Linux underneath, but most do not give the administrator a root shell or a full process listing. Also, in most cases, you cannot install an EDR agent on them. The Cyclops Blink deployment on FMC is a Linux implant, delivered as an Executable and Linkable Format (ELF) binary according to Talos, on exactly this kind of device.

Network and appliance administrators should ask each vendor whether there is a supported way to pull a process listing that includes the PID, parent PID, memory use, and executable path. The useful result is a list of which appliances support it and which do not. On devices that do, detection engineering can apply the same checks. On devices that do not, you will not see this technique through process data and need other evidence, such as file integrity and outbound connections, to find it.

What to do if you find one

Incident response should own any confirmed hit. Before killing the process, preserve what is only available while it runs:

mkdir -p /root/ir
cp /proc/PID/exe /root/ir/PID.bin            # works even if the file was deleted
ls -l /proc/PID/cwd                          # working directory
tr '\0' '\n' < /proc/PID/environ             # environment variables
ss -tunap | grep "pid=PID,"                  # network connections

Then look for the persistence these families used. StyleSmuggler relied on a cron job that restarts the implant twice an hour. The OpenCart attacker added an @reboot cron entry and a second cron job that restarted the binary every 5 minutes. Tengu installs a systemd service described as “System Helper Service,” along with SysV init scripts, OpenWrt procd entries, cron @rebootjobs, and /etc/rc.local. Talos lists /etc/init.d/ scripts as a Cyclops Blink persistence capability. Removing the process without removing the persistence brings it back.

Close the entry point too. For StyleSmuggler, that means Adobe’s hotfix in Adobe security bulletin APSB26-146. Patching stops new infections through that vulnerability and does not remove an implant that is already installed, so do both. In the e-commerce cases, also assume customer data on the host was exposed until you can show otherwise. The OpenCart attacker deployed an endpoint that exported the entire order table, including customer names, addresses, and payment details.

Frequently Asked Questions

No. A typical Linux host runs dozens of real kernel threads. They become suspicious when they have a parent other than PID 2, non-zero memory, or an executable file behind them.

It can, if the agent runs on the host and the vendor ships a rule for it, as Elastic does. EDR agents generally cannot run on closed network appliances, which is where the visibility gap is largest.

A kernel rootkit can alter what the proc filesystem reports. The examples in this post all run in user space, which is why the property checks work against them.

No. Patching stops new infections through that vulnerability. An implant that is already installed keeps running and keeps its persistence until someone removes it.

Every Linux system runs many kworker threads with numbered names that change between boots, so one more entry does not stand out in a long process list.

Sources

The post Fake Kernel Threads Are Hiding Backdoors on Linux Servers and Appliances appeared first on Eclypsium.

My First Year on Linux – AnubiBlog

Wed, 21 Oct 2026 00:57:46 +0000

My First Year on Linux

08 Dec, 2025

It's kinda wild to look back on it, but yeah, this month marks my first year using Linux!! So I thought it'd be fun to look back on everything that happened before, between and now.

First things first though, I was always scared of using Linux as I felt it was too complicated from what I saw everywhere, and even when I did attempt to give it a try back in 2020 with Ubuntu, the very next day the PC didn't want to boot up at all, which made me feel this kind of operative system was too "tech-savvy oriented", so I stuck with Windows 10 for the next few years.

As its End of Life approached closer and closer, I had to update my PC, so I wanted to try updating to Windows 11 and... It did not work, because my motherboard lacks that dreaded TPM 2.0 chip. At the time I just finished upgrading my PC from a potato in the literal sense to one that did everything I use it for (gaming, art, browsing, etc.) good enough, and I did not want to upgrade my hardware yet again because everything worked pretty well, even though Microsoft seems to think its outdated, but I decided I would wait till October 2025 to see my options.

The thing is, between that time I tried to update to Windows 11 to the next few months, my experience with Windows kept worsening more and more.

May it be the system lagging more often, using more and more resources out of nowhere, how bloated it started to feel, how things like the search bar gave me web results instead of files in my system??

But what pushed me to switch from Windows now was something very insignificant in the grand scheme of things, but something that still pissed me off due to everything prior. When I finished updating my PC one time, when I checked again I had the Copilot shortcut added to my taskbar.

I do not want your AI, I did not agree to having this in along with your browser that you keep shoving in every damn web feature, I did not want to have ads for Candy Crush in my start menu, I do not want this treatment you kept giving me for using the system.

That's when I snapped with Windows, and decided to switch off it now.

That's when Linux came into the picture, and I was hesitant at first because of both what I heard of it and my personal experience with Ubuntu, but a friend insisted for me to give it a shot again, so after figuring out if I wanted to do it or not, I went with it.

One call figuring out how to install it on my system later, I ended up having Linux Mint in my PC along with Windows 10, as a dual boot to test it out. We could not figure out how to make GRUB work (the boot loader that usually comes with Linux Distros) but from what I tried Linux Mint, I just liked it!

It was faster and felt way smoother than Windows, it didn't take an absurd amount of storage just from the system files, I could actually have a functioning search function, no AI anywhere, and even more importantly for me, I could customize it however I wanted to. Back when I was on Windows I tried different third party apps to achieve that, but here it was all built in, and I could do even more things, like add a second taskbar (panel on Linux).

I liked it so much in fact, that a week or 2 after installing that partition, I decided to nuke the windows partition and have Linux Mint as my main system. This time I installed it by myself and everything, it all felt so nice.

It felt weird for me how I didn't see any of the complains I heard online on Mint, like how you need to use the terminal at all times (everything in Mint can be done via GUI), how you can break everything at any time (Mint never broke in all my time using it), or how unhelpful and elitist/loud the community is (every time I needed help for something, everyone was very kind).

Also, Proton exists, which helped me to play most games on my Steam library from Linux just fine thanks to it being a compatibility layer for translating Windows stuff to Linux. at first I checked every game status on ProtonDB (an user contributed tracking of how well games work with Proton) but nowadays unless that game has an Anti-cheat, I just don't check it and it works fine every time, just hitting play they already work out of the box.

Over time, I wanted to try out different things from Linux, Mint was nice and all yeah, but there was things like KDE, GNOME and the at-the-time upcoming COSMIC desktop, along with Fedora and Arch that looked interesting enough, so I ended up giving them a shot each and every one.

Fedora KDE worked perfectly for me post install, though I needed to mess with the terminal every time to finish the set up as its lacking a few non-free dependencies I need. Every time a week or so passed though, something kept breaking in one way or another, and it took me weeks to find answers to those.

Fedora GNOME had the same post-install shenanigans as the one above, but it was far more stable, akin to Mint, even if I tried it for a tiny bit everything felt nice.

I tried COSMIC through Fedora, and it worked... well enough, though it was a bit laggy in some parts and buggy in others, though that's to be expected as it's in beta at the time of writing this. I'd definitely come back to it if the opportunity arises.

I also tried installing Arch and it did not work. I tried going through Archinstall but I kept getting one error after another, and the normal installation process was too complex for me, so I ended giving up on that idea.

Since then I started trying out more alternatives for apps, like Pixelorama for Pixel Art, Heroic for Epic Games Store/GOG/Amazon games, Akegrator for RSS Feeds, it all worked nicely!!

I stuck with Fedora KDE for most of that time until recently, where I decided to switch to Kubuntu.

And yeah I know, Ubuntu is bad and so are Snaps plus my last experience with Ubuntu was terrible, but I wanted to use KDE Plasma in a more stable way, Fedora KDE was nice and all, but it kept breaking the more time I used it and, as someone who works on arts and the like, I cannot really allow myself to risk losing those files, so Kubuntu seemed like the best option for me and hey, it is! I'd even dare to say it feels more stable than Mint, while still keeping things like KDE Plasma and Wayland which I use often.

If there's something I would say to the past me in 2020 is to try giving Linux a time again, because it's damn good. Thank you NullDott for helping me with this transition from one OS to the other.

Anyways, I'm off to remove the french language from my Linux Distro, bye!

Anubi "Xenia" Arts

#appreciation #linux #timeline #windows

Manejar subvolúmenes Btrfs en Fedora · El blog de Lázaro

Tue, 20 Oct 2026 01:57:53 +0000

Fedora utiliza Btrfs como sistema de archivos por defecto en Workstation lo que nos aporta flexibilidad para gestionar el espacio, compresión transparente y también nos va a permitir trabajar con snapshots.

La parte menos buena es que hay que aprender conceptos nuevos. Vengo de ext4 y XFS, y ahora aparecen términos como subvolúmenes, subvolid=5 y snapshots, al principio me ha supuesto cierto tiempo de investigación y dedicación hasta entenderlo.

En este artículo voy a repasar lo básico: qué es Btrfs, qué aporta, qué inconvenientes tiene y cómo consultar el layout por defecto. También explicaré cómo crear y borrar subvolúmenes y qué estructura me parece la más lógica para mantener el sistema ordenado.

Qué es Btrfs

Btrfs es un sistema de archivos moderno para Linux que incorpora características avanzadas como checksums, snapshots, compresión y subvolúmenes, todo dentro del propio filesystem.

Hay que entender que en Btrfs, los subvolúmenes no son particiones independientes. Aunque pueden montarse como si fueran sistemas de archivos separados, comparten el mismo espacio disponible del filesystem, salvo que apliques límites con qgroups. Esto evita el típico problema de quedarte sin espacio en / mientras te sobra mucho en /home, por ejemplo.

Btrfs en Fedora

Btrfs integra funciones como checksums, snapshots, compresión y subvolúmenes dentro del propio filesystem. Tiene una forma distinta de organizar y administrar el almacenamiento.

La idea es que un subvolumen no es una partición independiente. Puede montarse como si lo fuera, pero comparte el espacio libre del mismo filesystem con el resto de subvolúmenes, salvo que apliques límites con cuotas.

Una de las ventajas de utilizar Btrfs son los snapshots. Puedes interpretarlos como hacer una fotografía a un subvolumen en un momento en concreto, muy útil antes de hacer cambios, actualizaciones o pruebas. Además, los snapshots de Btrfs no son recursivos, así que puedes dejar fuera ciertas rutas si las separas en otros subvolúmenes.

Otra ventaja es la compresión transparente lo que nos permite ahorrar espacio y puede mejorar la lectura y escritura, especialmente en discos SSD.

Inconvenientes

La principal pega es la complejidad. Btrfs no es difícil de usar pero entender la estructura interna lleva algo de tiempo, más que con un sistema de archivos clásico.

En mi caso, lo que más me costó fue entender ideas como subvolid=5, los subvolúmenes anidados, los snapshots no recursivos o por qué df -h no muestra la información igual que en ext4.

Conviene dejar clara una idea: un subvolumen no tiene un tamaño propio por defecto. Todos los subvolúmenes pueden crecer mientras haya espacio libre en el filesystem. Hay que distinguir entre espacio usado, espacio asignado internamente y espacio libre total.

Fedora usa Btrfs por defecto, pero no instala una estrategia completa de snapshots automáticos como sí hace openSUSE en su instalación; tendrás que organizarla tú.

[!TIP] A diferencia de las particiones tradicionales, los subvolúmenes comparten el espacio libre de todo el disco, por lo que no tienes que preocuparte por asignarles un tamaño fijo.

El layout por defecto de Fedora

En una instalación estándar de Fedora, el instalador crea una partición EFI, una partición /boot en ext4 y un filesystem Btrfs para el resto. Dentro de ese Btrfs crea dos subvolúmenes: root y home, que luego monta como / y /home.

En el archivo /etc/fstab, Fedora monta / con subvol=root y /home con subvol=home, no usa el esquema @ y @home que usan Ubuntu y Timeshift.

Cómo listar subvolúmenes

Para ver los subvolúmenes de tu instalación:

sudo btrfs subvolume list /

En una instalación normal verás algo parecido a esto:

ID 256 gen 913 top level 5 path root
ID 257 gen 913 top level 5 path home

Muestra el ID, la generación, el top level y la ruta de cada subvolumen. Para ver todos los del pool, incluidos los no montados, usa -a:

carlos@d14:~$ sudo btrfs subvolume list -a /
[sudo] contraseña para carlos:
ID 256 gen 384 top level 5 path root
ID 257 gen 384 top level 5 path home

Y si quieres ver también sus UUID:

carlos@d14:~$ sudo btrfs subvolume list -u /
ID 256 gen 402 top level 5 path root uuid 3a7d8e2b-4c1f-4a9e-8b2d-6f5a1c9e3b7d
ID 257 gen 402 top level 5 path home uuid 9c2e6a4d-1b8f-4e3c-a7d2-5f8b0c4e6a1d

Para ver qué subvolúmenes están montados:

carlos@d14:~$ mount | grep btrfs
/dev/nvme0n1p6 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/root)
/dev/nvme0n1p6 on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=257,subvol=/home)

Cómo comprobar estado y espacio

btrfs filesystem usage / nos ofrece datos como tamaño del dispositivo, espacio asignado, espacio sin asignar, usado real y estimación de espacio libre.

carlos@d14:~$ sudo btrfs filesystem usage /
Overall:
    Device size:		 304.73GiB
    Device allocated:		  27.02GiB
    Device unallocated:		 277.71GiB
    Device missing:		     0.00B
    Device slack:		     0.00B
    Used:			  22.97GiB
    Free (estimated):		 280.24GiB	(min: 141.38GiB)
    Free (statfs, df):		 280.23GiB
    Data ratio:			      1.00
    Metadata ratio:		      2.00
    Global reserve:		  39.23MiB	(used: 0.00B)
    Multiple profiles:		        no

Data,single: Size:25.01GiB, Used:22.48GiB (89.90%)
   /dev/nvme0n1p6	  25.01GiB

Metadata,DUP: Size:1.00GiB, Used:248.09MiB (24.23%)
   /dev/nvme0n1p6	   2.00GiB

System,DUP: Size:8.00MiB, Used:16.00KiB (0.20%)
   /dev/nvme0n1p6	  16.00MiB

Unallocated:
   /dev/nvme0n1p6	 277.71GiB

Cómo crear un nuevo subvolumen

Si quieres añadir un subvolumen nuevo, lo más limpio es crearlo en el top level 5 y luego montarlo donde quieras con fstab. Así mantienes una estructura plana y no mezclas la jerarquía real de Btrfs con el sistema ya montado

Primero localiza tu partición Btrfs:

carlos@d14:~$ findmnt -vno SOURCE /
/dev/nvme0n1p6

Luego monta el top level:

sudo mkdir -p /mnt/btrfs-top
sudo mount -o subvolid=5 /dev/nvme0n1p6 /mnt/btrfs-top

Si ahora listas el contenido, verás los subvolúmenes creados, root y home

carlos@d14:~$ ls -la /mnt/btrfs-top
total 16
drwxr-xr-x  1 root root  16 mar 26 07:27 .
drwxr-xr-x. 1 root root  18 mar 26 08:58 ..
drwxr-xr-x. 1 root root  12 mar 26 07:44 home
dr-xr-xr-x. 1 root root 170 oct 23 06:11 root

carlos@d14:~$ sudo btrfs subvolume list /mnt/btrfs-top
ID 256 gen 246 top level 5 path root
ID 257 gen 246 top level 5 path home

Para crear un subvolumen llamado prueba:

sudo btrfs subvolume create /mnt/btrfs-top/prueba
Create subvolume '/mnt/btrfs-top/prueba'

Y para montarlo manualmente, por ejemplo en tu home:

sudo mkdir -p /home/carlos/prueba
sudo mount -o subvol=prueba,compress=zstd:1 /dev/nvme0n1p6 /home/carlos/prueba

carlos@d14:~$ sudo btrfs subvolume list /
ID 256 gen 248 top level 5 path root
ID 257 gen 248 top level 5 path home
ID 259 gen 248 top level 5 path prueba

Vemos que prueba cuelga de top level 5, el path es simplemente prueba y puedes comprobar que está montado:

carlos@d14:~$ mount | grep prueba
/dev/nvme0n1p6 on /home/carlos/prueba type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=259,subvol=/prueba)

Cuando termines, puedes desmontar el top level temporal:

sudo umount /mnt/btrfs-top

Eso no borra el subvolumen ni afecta a / o /home; solo deja de mostrarte el árbol de Btrfs en ese punto de montaje.

Puedes verificar que todo está bien:

carlos@d14:~$ mount | grep btrfs
/dev/nvme0n1p6 on / type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=256,subvol=/root)
/dev/nvme0n1p6 on /home type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=257,subvol=/home)
/dev/nvme0n1p6 on /mnt/btrfs-top type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/nvme0n1p6 on /home/carlos/prueba type btrfs (rw,relatime,seclabel,compress=zstd:1,ssd,space_cache=v2,subvolid=259,subvol=/prueba)

carlos@d14:~$ sudo btrfs subvolume list /
ID 256 gen 263 top level 5 path root
ID 257 gen 263 top level 5 path home
ID 259 gen 248 top level 5 path prueba

Cómo hacerlo permanente (fstab)

Si quieres que ese subvolumen se monte al arrancar, hay que añadirlo a /etc/fstab. Primero saca el UUID:

carlos@d14:~$ findmnt -no UUID /
5fb25f96-b91a-4871-b765-1a4d7cd8b0d6

Y añade una línea al fichero fstab:

#
# /etc/fstab
# Created by anaconda on Thu Mar 26 06:31:46 2026
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=5fb25f96-b91a-4871-b765-1a4d7cd8b0d6 / btrfs subvol=root,compress=zstd:1 0 0
UUID=89f45207-a218-4ed5-a659-3764d98447de /boot ext4 defaults 1 2
UUID=2621-F308 /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=5fb25f96-b91a-4871-b765-1a4d7cd8b0d6 /home btrfs subvol=home,compress=zstd:1 0 0
UUID=5fb25f96-b91a-4871-b765-1a4d7cd8b0d6 /home/carlos/prueba btrfs subvol=prueba,compress=zstd:1 0 0

Después valida antes de reiniciar:

sudo mount -a

Si mount -a no devuelve errores, el fstab está bien y los puntos de montaje son válidos.

Cómo eliminar un subvolumen

Si el subvolumen cuelga del top level 5, la forma más segura es montar ese top level temporalmente y borrarlo desde ahí.

No puedes borrar un subvolumen si está montado, hay que desmontarlos primero:

carlos@d14:~$ sudo umount /home/carlos/prueba

Como lo creaste en el nivel superior (subvolid=5), debes borrarlo desde ahí:

carlos@d14:~$ sudo mkdir -p /mnt/btrfs-top

carlos@d14:~$ sudo mount -o subvolid=5 /dev/nvme0n1p6 /mnt/btrfs-top

carlos@d14:~$ sudo btrfs subvolume delete /mnt/btrfs-top/prueba
Delete subvolume 259 (no-commit): '/mnt/btrfs-top/prueba'

carlos@d14:~$ sudo umount /mnt/btrfs-top

Si el subvolumen está anidado dentro de otro subvolumen montado, también puedes borrarlo desde esa ruta o usando su ID.

No olvides eliminar la entrada UUID=5fb25f96-b91a-4871-b765-1a4d7cd8b0d6 /home/carlos/prueba btrfs subvol=prueba,compress=zstd:1 0 0 del archivo fstab

Por ejemplo, para borrar prueba (ID 259) sin montar el top level puedes usar su ID directamente, apuntando a cualquier punto del mismo filesystem:

sudo btrfs subvolume delete --subvolid 259 /

[!WARNING] No debes intentar borrar un subvolumen que siga montado. Primero desmonta, luego elimina.

Cuando lo borras, la limpieza real del espacio puede seguir en segundo plano. Si quieres esperar a que termine:

sudo btrfs subvolume sync /

¿Top level o dentro de / o /home?

Se pueden crear subvolúmenes anidados dentro de otros subvolúmenes, pero la forma que mejor encaja con el layout de Fedora es crear los nuevos subvolúmenes bajo el root del filesystem y montarlos después donde corresponda.

Yo prefiero el top level 5. Me resulta más limpio, el fstab queda más claro y evito mezclar la organización lógica del sistema con la jerarquía interna de Btrfs

Es mucho más ordenado crear en el top level y montar luego /var/log, /var/cache, /var/tmp o /.snapshots.

Chuleta

# Ver subvolúmenes
sudo btrfs subvolume list /
sudo btrfs subvolume list -a /

# Ver montajes Btrfs
findmnt -t btrfs
mount | grep btrfs

# Ver espacio y uso
sudo btrfs filesystem show
sudo btrfs filesystem df /
sudo btrfs filesystem usage /
df -h /

# Montar top level 5
sudo mount -o subvolid=5 /dev/nvme0n1pX /mnt/btrfs-top

# Crear subvolúmenes
sudo btrfs subvolume create /mnt/btrfs-top/snapshots
sudo btrfs subvolume create /mnt/btrfs-top/var_log
sudo btrfs subvolume create /mnt/btrfs-top/var_cache
sudo btrfs subvolume create /mnt/btrfs-top/var_tmp

# Montar manualmente un subvolumen
sudo mount -o subvol=snapshots,compress=zstd:1 /dev/nvme0n1pX /.snapshots

# Validar fstab
sudo mount -a

# Eliminar un subvolumen
sudo btrfs subvolume delete /mnt/btrfs-top/var_tmp
sudo btrfs subvolume sync /

Mi estructura

Intento mantener el estilo nativo de Fedora y no mezclarlo con layouts tipo @.

root → /
home → /home
snapshots → /.snapshots
var_log → /var/log
var_cache → /var/cache
var_tmp → /var/tmp

Esta estructura mantiene el layout original de Fedora y deja fuera de los snapshots del sistema rutas como logs, cachés y temporales, que no me interesa tener en un rollback.

En el siguiente artículo explico cómo migrar desde el layout por defecto de Fedora a esta estructura, usando un Live USB, preservando los logs y dejando fstab preparado para arrancar ya con los nuevos subvolúmenes.

Espero que te haya gustado, pasa un buen día. 🐧

Linux 7.3 released

Tue, 20 Oct 2026 00:04:01 +0000

Significant changes in this release include some significant binfmt_misc extensions, some group-scheduling work aimed at improving performance on large systems, the new failfs filesystem that fails all operations, the fchroot() system call, global per-CPU data for BPF programs, the completion of the sched_ext subscheduler feature, working-set tracking for virtual machines, alternative data-stream support in the ntfs3 filesystem, a long list of SMB server improvements, and much more.
↫ “corbet” at LWN.net

It’ll make it way to your distribution of choice soon enough.

putting linux on my rtx spark laptop because i don't have a microsoft account - josie.lol

Mon, 19 Oct 2026 22:42:57 +0000

tl;dr - boo hoo microsoft bad. Arch Linux works, keeps up with Windows in 7-Zip, and reports the same 116.0 GiB memory pool to the OS and CUDA. My initial bootable setup and patches are here. This is for the ASUS ProArt P16 H7607BA-SE033W: the 128 GB RAM configuration with 6,144 CUDA cores and a 2 TB SSD.

When rumours started circulating about a laptop with over 100 GiB of RAM the GPU could access, I started thinking about all the things I could build on it and all the optimisations I could spend far too long playing with. I'm very pro open-weight models. Being able to run things locally and mess around with RL, quantisation and fine-tuning on a laptop would be sick. I already publish my own GGUF quants on Hugging Face, with over 160,000 downloads in the past month.

So I was less pleased to find out about the Windows-only official support. There are plenty of reasons to hate Windows. Mine include the privacy concessions during setup, the years spent waiting for Microsoft to let people put the taskbar on the side of the screen again, and the advertising. That last link is a collage of real Windows promotions, courtesy of Pureinfotech. You get it. I can go on forever, so let me stay on topic.

Arch is my preferred distribution, and I'm on the Arch staff as a package maintainer. I already put it on IBM mainframes (my FOSDEM slides), so it was always going to be my starting point here. This build uses Arch Linux ARM, the separate project that ports Arch packages to ARM, with the hardware support added on top.

NVIDIA has been doing kernel work for Ubuntu, which gave me a starting point. I incorporated that, fixed the ACPI override allocation and framebuffer mapping needed to get a console, and worked out the ACPI overrides from the laptop's own tables (thanks astra <3). The NVIDIA driver and ASUS speaker firmware came from official places on the internet (pls don't sue me computer companies). Keyboard support needed a patched hid-asus, and audio needed its own machine driver.

I put this together into a bootable USB and extended upstream Archinstall 4.5 to install the hardware support. The repo has the build scripts and patches, including the steps to dump your own ACPI tables and extract the speaker firmware from ASUS's driver package locally. Mine runs firmware H7607BA.300.

The build inputs are hash pinned. The hardware packages I put together over the weekend are signed with my Arch Linux Package Maintainer key, and the ACPI overrides come from the laptop itself.

The display runs at 3840 × 2400 and 120 Hz, and I use NetworkManager, PipeWire, and rootless Podman with NVIDIA CDI. The installer holds the kernel, NVIDIA, power-management and firmware packages with IgnorePkg, while ordinary packages keep updating from Arch Linux ARM.

CPU performance

I ran the suite on October 19 on native Arch Linux ARM, with kernel 7.0.0-1022-nvidia and NVIDIA driver 615.78.08. The laptop was plugged in with the performance profile selected. For the CPU comparison, I used published Windows results.

The CPU test is native ARM64 7-Zip 26.04 with a fixed 32 MiB dictionary. I ran one warmup and three measured passes at each thread count, then took the medians:

StorageReview tested a 128 GB HP OmniBook Ultra 16 with the same 20-core N1X, running native Windows ARM64 binaries. They report 7-Zip ratings in GIPS, so I divided the MIPS ratings in my raw logs by 1,000 to match. Higher is better.

Single-thread is basically a tie. With all 20 threads, my Linux setup is about 5% ahead on compression and 3% ahead on decompression. The HP review doesn't specify its 7-Zip version or dictionary size, so these percentages compare the two laptop setups.

ComputerBase also tested a ProArt P16 with the 20-core N1X. Converted to GIPS, its Windows 7-Zip score was 155.774; the median total from my three runs was 157.084. Their result sits inside my three-run range of 155.759 to 157.193 GIPS. Their machine was the 64 GB configuration and ran 7-Zip 26.00, and the chart doesn't give the dictionary size.

The memory split

The memory is a bigger flex. My Linux run reports 116.0 GiB as both system RAM and CUDA's total, from the same physical pool. Windows divides the RAM into dedicated GPU, shared, and CPU-only regions. CPU workloads can't use the dedicated GPU region, and GPU allocations can't use the CPU-only region.

The Windows NVIDIA app lets you change the dedicated reservation and reboot; Frandroid's 128 GB ProArt P16 reached 96 GiB. CUDA can go beyond that by allocating from shared RAM, subject to Windows' memory budget.

With a 91 GiB dedicated reservation, Frandroid's Windows setup reported a CUDA total of 109.7 GiB, including shared memory. My Linux setup reported 116.0 GiB, about 6.3 GiB more. What I care about is having the large pool available for CPU work too, without moving the reservation slider and rebooting between workloads.

Running Qwen locally

I ran NVIDIA's Qwen3.8-Flash-Next-FP4-Local checkpoint through vLLM with B12X CUDA kernels in a native ARM64 container, using mixed quantization and FP8 KV cache. I turned off thinking for this run.

Before loading the model, Linux reported 110.9 GiB of available RAM. vLLM logged 68.2 GiB for model loading and allocated another 21.1 GiB to the KV cache. That's nearly 90 GiB allocated to the model and KV cache on a laptop.

Model loading and compilation took about 16 minutes before the first request. The timings below start after warmup. PLE embedding tables are backed by disk and benefit from a warm page cache; other components use CPU offload. CUDA handles inference, with some of the model outside GPU memory.

I gave Qwen two buggy Python helpers to review, a long incident log with one failed operation to find, and a payment note to turn into JSON. Each task ran three times after warmup, with known answers to check against. I wanted to know how long I'd wait and whether it returned the right fields.

The incident task read nearly 10,000 tokens and returned the correct request, cause, and next action in under 6 s. Its answer was only 39 tokens long, which comes to 6.8 tokens/s over the whole request. Most of the wait went into processing the prompt, so for this task the response time tells me more than the tokens/s figure.

For code review, I estimated generation speed as (output tokens − 1) / (response time − time to first token), with both times in seconds. This includes stream overhead. Frandroid ran Qwen3.8-Flash-Next coding tasks on its Windows ProArt:

Both ProArt setups are around 30 tokens/s. For inference, Frandroid used an 85 GiB dedicated reservation and a context limit of 262,144 tokens; my context limit was 32,768 tokens. The prompts, quants, runtimes, and timing methods differ. This compares two working configurations; it doesn't isolate the effect of the OS.

I also sent four code reviews at once. The median batch finished in 5.314 s, producing 86.6 output tokens/s across all four requests combined. That rate includes prompt processing and response overhead. All 12 answers passed over three batches.

Then I left it cycling through the three tasks, one request at a time, for ten minutes. It finished 150 requests, 50 of each, and every answer passed the checks. Median response times were 4.036 s for code review, 5.921 s for the log, and 2.046 s for extraction. Comparing the first ten and last ten repetitions of each task, median response times grew by less than 1.6%.

All 171 measured responses passed the checks. That's three prompts repeated with deterministic decoding; the code-review check verifies the regression outputs. I kept every answer and raw event stream and checked them against the summaries.

Finding a home amidst the wreckage - Eskild Hustvedt

Mon, 19 Oct 2026 22:42:37 +0000

Finding a home amidst the wreckage

Published 2026-10-18 19:55

Like many others in the free software community, I've been been growing apathetic with the whole thing, lately. One project after the other - and one Linux distro after the other - embrace the proprietary world destroying plagiarism machine. I've been questioning the point of it all. Why make the effort of writing software, and publishing it, only for huge corporations to gobble it up, while blatantly ignoring the license?

I felt Debian's embrace of it the worst. To me it has been a community-focused constant. Until it wasn't. That isn't to say I feel Debian owes me anything. They don't. But it still made me sad.

But I still like computers. Coding and tinkering is fun. Unix-like systems are where I feel comfortable. But, if possible, I'd like to use something that aligns more with my values than my previous go-to, Debian, does.

Discovering Chimera Linux

I've been looking into community-focused distros that have firm LLM policies. While doing this I came over the post «Creating distro build tooling for a small community» on the Chimera Linux website. I was intrigued. They also reject LLM contributions completely.

It's not just their firm focus on community that makes Chimera interesting, though. They've also got a tech stack that deviates from mainstream Linux. Chimera uses musl, not glibc, it uses a FreeBSD-derived userspace, not GNU coreutils, and it uses dinit, not systemd.

The latter, not using systemd, required a bit of research. Not because it's a bad choice, but because some of the discourse among non-systemd-users is frankly bizarre. But Chimera has my back here too. Chimera «is explicitly not a part of this community».

I was sold, and quickly installed Chimera. Suddenly I was back to when I discovered Linux in the early 2000's, poking around something new and fresh. This time I knew my way around, but a new init and service manager, the FreeBSD-based userspace and new-to-me apk-package manager meant I had to learn some new tricks. It's loads of fun.

Making it easy to contribute

One thing that stood out in the blog post I was «[…]Every user can be a maintainer. It shouldn't be unnecessarily intimidating. We don't gatekeep here when possible. You should also be having fun using the system and being here.».

The barrier to entry for contributing to many Linux distributions these days is pretty high. Chimera makes it an explicit goal to make contributing easy - and I'd say they've succeeded. The packaging tools, and the format you write packages in, are both easy to learn and easy to use. As of writing, I've got one new package and one update accepted into «cports», Chimera's package repository.

More importantly, I made mistakes when contributing, and I was met with advice and suggestions on how to improve, not with hostility or rejection. What I first tried to submit wasn't good enough, but I was given a chance to improve - and I did.

This welcoming, friendly atmosphere, in my experience, extends to the rest of the community. I've been talking and asking questions in the #chimera-linux IRC channel on OFTC. People were more than happy to lend me a hand, give me hints and even just chat.

But, Eskild, you're still running LLM-generated code

I am. There's LLM code in projects upstream from Chimera, perhaps most notably the Linux kernel. It's impossible to avoid it at this point, and still be left with a usable system. I still think there's value in a project taking a stand, as much as it can, and I think there's also value in non-LLM forks like vim-classic and opentmux. I'm happy to be in a community of builders that take a stand.

There are others

If you think this sounds interesting, I urge you to try out Chimera Linux. That said, it's not alone, even though many of the largest Linux distributions, and *BSDs, are embracing LLMs. Elementary OS, Gentoo Linux, Asahi Linux and Nura on the Linux side, and NetBSD on the BSD side, are also options.

#UnplugBigTech: Raus aus der Windows-Abhängigkeit – Teil 10

Mon, 19 Oct 2026 21:41:00 +0000

1. Einleitung

In Teil 9 der Serie #UnplugBigTech haben wir uns das Smartphone vorgenommen: Android und iOS, Tracking-Einstellungen, App-Berechtigungen und – für alle, die weitergehen wollen – alternative Android-Systeme wie GrapheneOS.

Als Nächstes ist der klassische Rechner dran. Dort läuft in den meisten Fällen Windows 11 – oft schlicht deshalb, weil es beim Kauf schon vorinstalliert war. Dazu kommen ein Browser sowie zahlreiche Cloud-, Office- und KI-Angebote, die Microsoft direkt in Windows integriert oder dort bewirbt.

Windows lässt sich an vielen zwar Stellen datensparsamer einstellen, aber ein Problem bleibt: Microsoft entwickelt das System laufend weiter, ergänzt neue Funktionen und verändert Voreinstellungen. Wer Windows möglichst datensparsam nutzen möchte, muss deshalb immer wieder prüfen, was sich geändert hat.

Ziel dieses Teils: Zunächst verbessern wir den Datenschutz unter Windows 11 mit einigen gezielten Einstellungen. Danach schauen wir uns mit Linux Mint eine Alternative an, die du ausprobieren kannst, ohne Windows sofort zu löschen.

Dieser Beitrag ist Teil einer Artikelserie

2. Aufbau der Anleitung

Diese Reihe ist für Einsteiger. Deshalb halten wir es bewusst simpel: Keine Fachbegriffs-Parade, keine endlosen Spezialfälle. Wer es eilig hat, findet gleich am Anfang jedes Kapitels unter »Für ganz Eilige« eine kurze Checkliste mit allen Schritten. Danach kommt der Erklärungsteil: Kurz genug, um nicht zu erschlagen – aber so, dass du verstehst, was du da einstellst.

Damit du dich direkt orientieren kannst, steht am Anfang jedes Kapitels außerdem kurz dabei, für welche Geräte die Schritte gedacht sind. In diesem Teil geht es zunächst um Windows 11 und anschließend um Linux Mint auf einem Desktop-PC oder Notebook.

3. Problemanalyse

Windows ist längst mehr als ein Betriebssystem, das Programme startet und Dateien verwaltet. Rund um Windows hat Microsoft ein eigenes Ökosystem aufgebaut: Microsoft-Konto, OneDrive, Edge, Microsoft 365, Bing, Copilot und weitere Dienste greifen ineinander und werden an vielen Stellen direkt im System angeboten.

Zur engen Verzahnung mit Microsoft-Diensten kommt die Telemetrie, also die Übermittlung von Diagnose- und Nutzungsdaten. Diese lässt sich nur teilweise abschalten: Optionale Diagnosedaten kannst du deaktivieren, die von Microsoft als erforderlich eingestuften Daten werden dagegen weiterhin übertragen. Du kannst Windows also an vielen Stellen datensparsamer einstellen, aber nur innerhalb des Rahmens, den Microsoft vorgibt.

Für Einsteiger wäre es trotzdem unsinnig, Windows deshalb sofort zu löschen. Wir machen es wie in den anderen Teilen dieser Serie: Erst verbessern wir das vorhandene System. Danach schauen wir uns eine Alternative an.

4. Windows 11 datensparsamer einstellen

Für ganz Eilige

Windows 11

Optionale Diagnosedaten deaktivieren
Werbe-ID deaktivieren
Personalisierte Empfehlungen und Angebote deaktivieren
Aktivitätsverlauf deaktivieren und vorhandenen Verlauf löschen
App-Berechtigungen für Standort, Kamera, Mikrofon und weitere sensible Bereiche prüfen
Recall deaktivieren bzw. entfernen, wenn die Funktion vorhanden ist und nicht genutzt wird
Firefox aus Teil 3 als Standardbrowser nutzen

Bevor wir uns Linux anschauen, prüfen wir zunächst, was sich unter Windows 11 mit wenigen Einstellungen verbessern lässt. Wir gehen dabei bewusst nicht jeden einzelnen Datenschutzschalter durch. Windows verändert sich zu häufig, um daraus eine Anleitung mit dutzenden Menüpunkten zu machen, die nach dem nächsten größeren Update schon wieder anders aussehen kann.

Die folgenden Punkte sind deshalb die wichtigsten Stellschrauben. Die genauen Bezeichnungen können sich je nach Windows-Version unterscheiden.

4.1 Diagnosedaten, Werbung und Empfehlungen einschränken [Windows 11]

Öffne:

Einstellungen -> Datenschutz und Sicherheit

Dort solltest du zunächst die verschiedenen Datenschutzoptionen prüfen. Besonders relevant sind:

Optionale Diagnosedaten deaktivieren
Werbe-ID deaktivieren
Personalisierte Empfehlungen und Angebote deaktivieren
Online-Spracherkennung deaktivieren, wenn sie nicht benötigt wird

Microsoft unterscheidet zwischen erforderlichen und optionalen Diagnosedaten. Die optionalen Diagnosedaten können unter anderem Informationen über Gerätenutzung, App-Aktivitäten, besuchte Websites und Absturzspeicher enthalten. Sie können deaktiviert werden. Erforderliche Diagnosedaten werden weiterhin an Microsoft übermittelt. Weitere Informationen dazu bietet Microsoft unter »Diagnose, Feedback und Datenschutz in Windows«.

Wenn ein Menüpunkt nicht exakt so heißt wie hier beschrieben, hilft meist die Suche innerhalb der Windows-Einstellungen.

4.2 Aktivitätsverlauf und Berechtigungen prüfen [Windows 11]

Neben Diagnose- und Werbeeinstellungen speichert Windows auch Informationen darüber, wie du das System nutzt. Der Aktivitätsverlauf kann unter anderem erfassen, welche Apps und Dienste du verwendet, welche Dateien du geöffnet und welche Websites du besucht hast. Diese Daten werden lokal auf dem Gerät gespeichert. Weitere Informationen dazu findest du bei Microsoft unter »Windows-Aktivitätsverlauf und Datenschutz«.

Du findest die Einstellung unter:

Einstellungen -> Datenschutz & Sicherheit -> Aktivitätsverlauf

Dort kannst du »Aktivitätsverlauf auf diesem Gerät speichern« deaktivieren und einen bereits vorhandenen Verlauf über »Verlauf löschen« entfernen.

Danach lohnt sich ein Blick auf die App-Berechtigungen. Unter:

Einstellungen -> Datenschutz & Sicherheit

findest du weiter unten den Bereich für App-Berechtigungen. Dort kannst du unter anderem festlegen, welche Apps auf folgende Bereiche zugreifen dürfen:

Standort
Kamera
Mikrofon
Kontakte
Dateisystem

Wählst du beispielsweise »Kamera« oder »Mikrofon« aus, kannst du den Zugriff grundsätzlich einschränken und bei unterstützten Apps auch einzeln festlegen, welche Anwendung darauf zugreifen darf. Microsoft erklärt die entsprechenden Einstellungen unter anderem unter »Windows-Datenschutzeinstellungen, die von Apps verwendet werden«.

Unter Einstellungen -> Datenschutz & Sicherheit -> App-Diagnose kannst du zusätzlich verhindern, dass Apps Diagnoseinformationen über andere laufende Apps abrufen. Wenn du diese Funktion nicht brauchst, kannst du sie deaktivieren.

Die Grundregel aus Teil 9 gilt auch hier: Eine App sollte nur die Berechtigungen erhalten, die sie tatsächlich benötigt. Schau dir deshalb vor allem sensible Zugriffe genauer an und prüfe, ob sie bei der jeweiligen App wirklich nachvollziehbar sind.

Hinweis

Bei klassischen Desktop-Programmen greifen die Windows-Berechtigungen nicht immer so fein wie bei Apps aus dem Microsoft Store. Manche Desktop-Anwendungen lassen sich deshalb nicht einzeln über diese Schalter steuern.

4.3 Recall deaktivieren oder entfernen [Windows 11 / Copilot+-PC]

Auf sogenannten Copilot+-PCs gehört Recall zu den KI-Funktionen von Windows 11. Die Funktion kann in regelmäßigen Abständen Momentaufnahmen des Bildschirms speichern, sodass sich später nach Inhalten suchen lässt, die zuvor in Apps, auf Webseiten, in Bildern oder Dokumenten zu sehen waren. Die Momentaufnahmen werden laut Microsoft lokal auf dem Gerät gespeichert und verarbeitet. Das Speichern ist nicht standardmäßig aktiviert, sondern muss vom Nutzer eingeschaltet werden. Wer Recall nicht nutzen möchte, kann die Funktion ausgeschaltet lassen oder vollständig aus Windows entfernen.

Zum Prüfen bzw. Deaktivieren öffnest du:

Einstellungen -> Datenschutz & Sicherheit -> Recall & Momentaufnahmen

Dort sollte »Momentaufnahmen speichern« deaktiviert sein.

Wer Recall gar nicht auf dem System haben möchte, kann die Funktion vollständig entfernen:

Windows-Suche -> Windows-Features aktivieren oder deaktivieren -> Recall

Entferne dort den Haken bei »Recall« und starte Windows anschließend neu. Bereits gespeicherte Momentaufnahmen werden beim Entfernen ebenfalls gelöscht.

Hinweis

Recall ist nur auf unterstützten Copilot+-PCs verfügbar. Wenn du den Punkt unter Windows nicht findest, ist die Funktion auf deinem Gerät nicht vorhanden.

4.4 Firefox als Standardbrowser verwenden [Windows 11]

Auch beim Browser setzt Windows standardmäßig auf Microsoft Edge. Besonders unschön: Der standardmäßig aktive SmartScreen-Schutz kann aufgerufene URLs zur Prüfung an Microsoft übermitteln – aus Datenschutzsicht ein klarer Fehlgriff. Wenn du bereits Firefox aus Teil 3 der Serie nutzt, solltest du ihn auch als Standardbrowser festlegen.

Unter Windows 11 findest du die Einstellung unter:

Einstellungen -> Apps -> Standard-Apps -> Firefox

Dort kannst du Firefox als Standardbrowser festlegen. Anschließend werden normale Weblinks aus anderen Programmen standardmäßig mit Firefox geöffnet. Die eigentliche Einrichtung von Firefox wiederholen wir hier nicht. Welche Einstellungen sinnvoll sind und warum wir Firefox in dieser Serie empfehlen, haben wir bereits in Teil 3 behandelt.

5. Das Problem: Das Katz-und-Maus-Spiel mit Microsoft

Mit diesen Einstellungen ist Windows schon deutlich datensparsamer eingerichtet. Ganz erledigt ist das Thema damit allerdings nicht. Microsoft entwickelt Windows laufend weiter. Neue Funktionen kommen hinzu, bestehende werden verändert und Einstellungen umbenannt oder an andere Stellen verschoben. Nach größeren Windows-Updates lohnt sich deshalb ein erneuter Blick in die Datenschutzoptionen.

Wer Windows möglichst datensparsam nutzen will, bleibt deshalb in einem Katz-und-Maus-Spiel gefangen: Nach Updates prüfen, neue Funktionen einordnen und gegebenenfalls wieder nachjustieren. Wenn dich dieses ständige Nachjustieren irgendwann nervt, kannst du dir anschauen, wie sich ein Rechner ohne Windows anfühlt. Dafür musst du dein bestehendes System nicht direkt aufgeben.

6. Linux Mint ausprobieren

Für ganz Eilige

Erst anschauen

Linux Mint bei Interesse zunächst unverbindlich ansehen
Optional über DistroSea direkt im Browser ausprobieren

Richtig testen

Linux Mint herunterladen
Bootfähigen USB-Stick erstellen
Rechner vom USB-Stick starten
Linux Mint im Live-Modus ausprobieren
WLAN, Bluetooth, Sound, Drucker, Scanner und andere wichtige Hardware testen
Prüfen, ob Programme und Dienste funktionieren, die du im Alltag brauchst

Wenn alles passt

Backup der wichtigen Dateien anlegen
Linux Mint parallel zu Windows installieren
Beim Start des Rechners zunächst zwischen Windows und Linux Mint wählen

Es gibt zahlreiche empfehlenswerte GNU/Linux-Distributionen. Wenn du jemanden kennst, der bereits Linux nutzt und dir beim Einstieg helfen kann, orientiere dich ruhig an dessen Empfehlung. Für alle anderen machen wir die Auswahl bewusst einfach: Wir empfehlen Linux Mint. Die Oberfläche ist Windows vergleichsweise ähnlich und eignet sich deshalb gut für den Einstieg. Wer später tiefer einsteigen möchte, kann sich immer noch andere Distributionen anschauen.

6.1 Optional: Linux Mint erstmal nur anschauen

Wer Linux Mint zunächst nur kennenlernen möchte, kann es über einen Dienst wie DistroSea im Browser ausprobieren.

Das reicht für einen ersten Eindruck von Oberfläche und Bedienung. Ob Linux Mint auf deinem eigenen Rechner gut läuft, lässt sich damit aber nicht beurteilen. WLAN, Bluetooth, Drucker, Scanner oder andere Hardware werden dabei schließlich nicht auf deinem Gerät getestet. Für einen echten Test brauchen wir deshalb einen USB-Stick.

7. Linux Mint vom USB-Stick testen

Bevor du Linux Mint installierst, kannst du es direkt von einem USB-Stick starten und auf deinem eigenen Rechner ausprobieren. Solange du Linux Mint nur startest und nicht installierst oder gezielt Dateien auf der Windows-Partition veränderst, bleibt deine Windows-Installation unangetastet. Du kannst also in Ruhe testen, ob Linux Mint mit deiner Hardware funktioniert und ob du dich mit dem System zurechtfindest.

Dafür brauchst du:

einen USB-Stick mit 8 GB oder mehr Speicherplatz
das Linux-Mint-Abbild im ISO-Format
ein Programm, das dieses ISO-Abbild bootfähig auf den USB-Stick schreibt

Hinweis

Beim Erstellen des Linux-Mint-Sticks wird der USB-Stick vollständig überschrieben. Sichere deshalb vorher alle Dateien, die darauf noch liegen.

7.1 Linux Mint herunterladen

Linux Mint gibt es in verschiedenen Ausgaben. Für diesen Beitrag verwenden wir die Cinnamon Edition. Die aktuelle Version kannst du direkt beim Projekt herunterladen.

Wähle dort: Cinnamon Edition -> Download

Anschließend landest du auf einer Liste mit sogenannten Download-Mirrors. Das sind verschiedene Server, die dieselbe Datei anbieten. Du kannst grundsätzlich einen beliebigen Server auswählen – am besten einen Server in deiner Nähe. Heruntergeladen wird eine Datei mit der Endung: .iso bspw.: linuxmint-22.3-cinnamon-64bit.iso

Dieses ISO-Abbild enthält das vollständige Linux-Mint-System.

Hinweis

Linux Mint weist auf der Download-Seite darauf hin, dass sich die heruntergeladene ISO-Datei auf Echtheit und Integrität prüfen lässt. Für Einsteiger ist das ein zusätzlicher Schritt, aber durchaus sinnvoll. Eine Anleitung dazu findest du direkt bei Linux Mint unter »Verify your ISO image«.

7.2 Bootfähigen USB-Stick erstellen

Die ISO-Datei einfach auf den USB-Stick zu kopieren reicht nicht. Der Stick muss so vorbereitet werden, dass dein Rechner davon starten kann. Unter Windows eignet sich dafür balenaEtcher. Das Programm funktioniert nach einem einfachen Prinzip: ISO-Datei auswählen, USB-Stick auswählen und schreiben lassen.

Installiere bzw. starte Etcher und gehe dann so vor:

Klicke auf »Flash from file« und wähle die heruntergeladene Linux-Mint-ISO-Datei aus.
Klicke auf »Select target« und wähle deinen USB-Stick aus.
Prüfe noch einmal sorgfältig, ob wirklich der richtige USB-Stick ausgewählt ist.
Starte den Vorgang mit »Flash«.

Etcher schreibt das Linux-Mint-Abbild anschließend auf den Stick und prüft das Ergebnis.

7.3 Rechner vom USB-Stick starten

Wenn der Stick fertig ist, lässt du ihn eingesteckt und startest den Rechner neu. Normalerweise startet jetzt trotzdem wieder Windows. Du musst dem Rechner deshalb einmal sagen, dass er stattdessen vom USB-Stick starten soll. Dafür gibt es bei den meisten PCs ein sogenanntes Boot-Menü. Welche Taste du dafür drücken musst, hängt vom Hersteller ab. Häufig sind es:

Die Taste musst du direkt nach dem Einschalten mehrfach drücken – also noch bevor Windows startet. Im Boot-Menü wählst du anschließend den USB-Stick aus. Der Eintrag enthält häufig den Namen oder Hersteller des Sticks und teilweise zusätzlich den Begriff »UEFI«.

Hinweis

Wenn du das Boot-Menü nicht erreichst, suche im Handbuch deines Rechners oder auf der Herstellerseite nach »Boot Menu« zusammen mit der genauen Modellbezeichnung. Die dafür vorgesehene Taste unterscheidet sich je nach Gerät.

7.4 Linux Mint starten – noch nicht installieren

Wenn der Rechner erfolgreich vom USB-Stick startet, erscheint das Startmenü von Linux Mint. Wähle dort den normalen Start von Linux Mint. Nach kurzer Zeit erscheint der Desktop. Das ist das sogenannte Live-System. Linux Mint läuft jetzt direkt vom USB-Stick. Auf der internen SSD oder Festplatte wird dabei noch nichts installiert und deine vorhandene Windows-Installation bleibt unverändert.

Du kannst dich also erstmal umsehen, Firefox öffnen, ins WLAN gehen oder deine Hardware ausprobieren. Auf dem Desktop findest du zwar bereits das Symbol »Install Linux Mint«. Das ignorieren wir vorerst. An dieser Stelle geht es ausschließlich darum, das System zu testen.

7.5 Jetzt den eigenen Alltag testen

Das Live-System läuft vom USB-Stick und kann deshalb etwas langsamer reagieren als eine richtige Installation. Für unseren Test spielt das keine große Rolle. Wichtiger als ein kurzer Blick auf die Oberfläche ist, ob dein eigener Rechner vernünftig funktioniert. Prüfe deshalb die Dinge, die du später tatsächlich brauchst:

Funktioniert WLAN?
Funktioniert Bluetooth?
Kommt Ton aus Lautsprechern und Kopfhörern?
Wird dein Drucker erkannt?
Funktioniert dein Scanner?
Werden weitere USB-Sticks und externe Festplatten erkannt?
Funktioniert die Webcam?
Funktionieren Touchpad, Maus und Sondertasten?
Kannst du deine vorhandenen Dateien öffnen?
Funktionieren die Websites und Webanwendungen, die du regelmäßig nutzt?
Gibt es für deine wichtigen Programme eine Linux-Version oder eine brauchbare Alternative?

Gerade bei Druckern, Scannern und spezieller Hardware helfen allgemeine Aussagen wenig. Entscheidend ist, ob genau deine Geräte funktionieren. Wenn Linux Mint auf einem sehr neuen Rechner nicht startet oder wichtige Hardware nicht erkennt, gibt es zusätzlich sogenannte HWE-Abbilder mit einem neueren Linux-Kernel. Probier zunächst trotzdem die normale Cinnamon-Version. Erst wenn es damit Probleme gibt, ist HWE einen Versuch wert.

Wenn etwas Wichtiges fehlt, ist der Versuch damit nicht automatisch gescheitert. Vielleicht gibt es eine Lösung oder Alternative. Wenn nicht, bleibt Windows zunächst erhalten.

7.6 Zurück zu Windows

Wenn du genug ausprobiert hast, fährst du Linux Mint über das Startmenü herunter und ziehst anschließend den USB-Stick ab. Beim nächsten Einschalten startet dein Rechner wieder ganz normal mit Windows.

Damit hast du Linux Mint auf deiner eigenen Hardware ausprobiert, ohne Windows zu verändern. Wenn dabei alles Wichtige funktioniert und du das System weiter nutzen möchtest, installieren wir Linux Mint im nächsten Schritt parallel zu Windows.

8. Welche Programme funktionieren unter Linux Mint?

Für viele typische Aufgaben musst du unter Linux Mint nicht komplett neu anfangen. Einige Programme aus den bisherigen Teilen der Serie gibt es auch für GNU/Linux und funktionieren dort weitgehend genauso wie unter Windows. Dazu gehören beispielsweise:

Firefox zum Surfen
Thunderbird für E-Mail
viele weitere freie Programme für Fotos, Videos, PDFs oder die alltägliche Dateiverwaltung

Wenn du Firefox oder Thunderbird bereits unter Windows nutzt, kannst du sie unter Linux Mint einfach weiterverwenden. Die Umstellung fällt dadurch deutlich kleiner aus, weil sich nicht gleichzeitig Betriebssystem und sämtliche Programme ändern.

Genauer hinschauen solltest du bei Software, die ausschließlich für Windows entwickelt wurde. Das betrifft beispielsweise bestimmte berufliche Anwendungen, Steuer- oder Verwaltungsprogramme, manche Spiele oder Programme für spezielle Hardware. Prüfe deshalb vor dem Umstieg, welche Anwendungen du regelmäßig verwendest und ob es davon eine Linux-Version oder eine passende Alternative gibt. Genau dafür ist auch der Test mit dem Live-System hilfreich.

Wenn du auf ein bestimmtes Windows-Programm angewiesen bist und keine brauchbare Alternative findest, ist das kein Grund, Linux Mint gleich abzuschreiben. In diesem Fall behältst du Windows parallel und nutzt es weiterhin für genau diese Aufgaben.

9. LibreOffice statt Microsoft Office

Ein wichtiger Punkt beim Wechsel von Windows ist Microsoft Office. Für Texte, Tabellen und Präsentationen steht unter Linux mit LibreOffice eine freie Office-Suite zur Verfügung. LibreOffice bringt mit Writer eine Textverarbeitung, mit Calc eine Tabellenkalkulation und mit Impress ein Präsentationsprogramm mit. Für typische Briefe, Tabellen, Rechnungen oder Präsentationen reicht LibreOffice im Alltag meist gut aus.

Auch vorhandene Microsoft-Office-Dateien sind nicht verloren. LibreOffice kann Formate wie DOCX, XLSX oder PPTX grundsätzlich öffnen und bearbeiten. Bei komplexen Dokumenten, Makros, speziellen Schriftarten oder aufwendigen Layouts kann es allerdings zu Abweichungen kommen. Wenn du regelmäßig solche Dateien verwendest, solltest du auch das bereits im Live-System ausprobieren: Öffne einige deiner typischen Word-, Excel- oder PowerPoint-Dateien und schau, ob sie so dargestellt und bearbeitet werden, wie du es brauchst.

10. Linux Mint parallel zu Windows installieren

Wenn das Live-System funktioniert und du Linux Mint weiter nutzen möchtest, kannst du es neben Windows installieren. Beim Start des Rechners wählst du anschließend aus, welches Betriebssystem geladen werden soll.

Wichtig: Bei dieser Installation wird die bestehende Festplatte neu aufgeteilt. Genau hier liegt das größte Risiko. Wenn du versehentlich die falsche Option auswählst oder die Partitionierung schiefgeht, können Windows oder persönliche Daten beschädigt werden.

Vorher unbedingt sichern

Bevor du Linux Mint parallel zu Windows installierst, solltest du ein aktuelles Backup deiner wichtigen Dateien auf einem externen Datenträger anlegen und kurz prüfen, ob sich die Sicherung auch tatsächlich öffnen lässt. Falls unter Windows BitLocker bzw. die Geräteverschlüsselung aktiv ist, sichere zusätzlich den Wiederherstellungsschlüssel.

Bei der Installation selbst ist wichtig, dass du ausdrücklich die Option wählst, Linux Mint neben Windows zu installieren. Varianten wie »Festplatte löschen« oder eine manuelle Partitionierung sind für diesen Einstieg nicht gedacht und können dazu führen, dass Windows oder vorhandene Daten verloren gehen.

Achte außerdem darauf, wie die Verschlüsselung gehandhabt wird. Gerade bei Notebooks sollte der interne Datenträger verschlüsselt sein. Viele Windows-11-Geräte nutzen dafür bereits BitLocker bzw. die Geräteverschlüsselung. Diesen Schutz solltest du beim Wechsel zu Linux Mint nicht versehentlich verlieren.

Bei einer parallelen Installation neben Windows ist eine vollständige Verschlüsselung von Linux Mint allerdings nicht immer so einfach umzusetzen wie bei einer reinen Linux-Installation. Wird dir keine eindeutige Option angeboten, Linux Mint neben Windows zu installieren, brich an dieser Stelle ab und hole dir Hilfe.

Nach der Installation sollte beim Start des Rechners ein Auswahlmenü für Windows oder Linux Mint erscheinen. So kannst du beide Systeme parallel nutzen und Windows jederzeit weiter starten.

11. Typische Stolperfallen

Linux ist doch nur etwas für Nerds.

Das Bild hält sich hartnäckig. Einen Browser öffnen, Dateien verwalten, E-Mails schreiben oder mit LibreOffice arbeiten funktioniert unter Linux Mint aber ganz normal über eine grafische Oberfläche. Für typische Alltagsaufgaben musst du nicht ständig Befehle in ein Terminal tippen.

Wenn ich Linux installiere, ist Windows weg.

Nicht, wenn du Linux Mint parallel installierst. Danach entscheidest du beim Start des Rechners, welches System du verwenden möchtest.

Ich muss mich doch erst für die perfekte Linux-Distribution entscheiden.

Am einfachsten ist es oft, mit der Linux-Distribution zu starten, die dir jemand aus deinem Umfeld empfiehlt und bei der dir diese Person auch helfen kann. Kennst du niemanden mit Linux-Erfahrung, empfehlen wir Linux Mint. Die Bedienung ist für Windows-Umsteiger vergleichsweise vertraut und der Einstieg gelingt meist ohne größere Umgewöhnung. Wenn du später tiefer einsteigen möchtest, kannst du dir immer noch andere Distributionen anschauen.

Meine Word- und Excel-Dateien funktionieren unter Linux nicht mehr.

Die Dateien verschwinden natürlich nicht. LibreOffice kann die verbreiteten Microsoft-Office-Formate öffnen und bearbeiten. Bei komplizierten Dokumenten, Makros oder speziellen Formatierungen kann es aber Abweichungen geben. Solche Dateien solltest du deshalb vorher testen.

Mein Drucker oder Scanner funktioniert bestimmt nicht.

Das lässt sich nicht pauschal sagen. Genau deshalb gibt es den Test mit dem Live-System. Dort merkst du schnell, ob dein konkretes Gerät erkannt wird.

Ich brauche ein bestimmtes Windows-Programm.

Dann behältst du Windows einfach. Wenn eine wichtige Anwendung nur dort läuft, kannst du für diese Aufgabe weiterhin Windows starten. Für Fortgeschrittene gibt es noch eine weitere Möglichkeit: Windows lässt sich beispielsweise mit VirtualBox in einer virtuellen Maschine unter Linux betreiben. Dabei läuft Windows innerhalb eines Fensters auf dem Linux-Desktop. Das ist praktisch für einzelne Programme, aber deutlich aufwendiger einzurichten und deshalb nichts, womit Einsteiger anfangen müssen.

Dann lösche ich Windows direkt. Wenn schon, denn schon.

Das erzeugt für Einsteiger vor allem unnötigen Druck. Wenn später doch ein wichtiges Programm oder Gerät fehlt, ist der Frust groß. Windows löschen kannst du immer noch, wenn du sicher bist, dass du es nicht mehr brauchst.

12. Bei Fragen Hilfe erhalten

Du musst das übrigens nicht allein machen. Zu jedem Thema gibt es im Forum die Möglichkeit, Fragen zu stellen, Erfahrungen zu teilen und konkrete Hilfe zu bekommen – egal ob du beim Erstellen des USB-Sticks hängenbleibst, dein Drucker unter Linux Mint nicht auftaucht oder du wissen möchtest, welche Alternative es für ein bestimmtes Windows-Programm gibt.

Gerade beim Wechsel des Betriebssystems hilft es, konkrete Probleme einzeln zu lösen, statt beim ersten Stolperstein das ganze Vorhaben abzuschreiben.

13. Für Fortgeschrittene

Wer sich mit Linux Mint eingelebt hat oder von Anfang an mehr ausprobieren möchte, findet eine große Auswahl weiterer GNU/Linux-Distributionen. Eine Orientierung bietet beispielsweise der DistroChooser. Verschiedene Distributionen lassen sich außerdem über DistroSea direkt im Browser anschauen.

Später können auch Themen wie manuelle Partitionierung, virtuelle Maschinen, Wine oder eine vollständige Linux-Installation ohne Windows interessant werden. Wer tiefer einsteigen möchte, kann sich außerdem mit einer individuell eingerichteten Festplattenverschlüsselung beschäftigen – etwa wenn die automatische Installationsroutine nicht zu den eigenen Anforderungen passt.

Die Verschlüsselung selbst ist dabei kein reines Fortgeschrittenen-Thema, sondern gerade bei mobilen Geräten ein wichtiger Basisschutz. Fortgeschritten wird es erst dann, wenn du sie manuell einrichten oder an eine besondere Partitionierung anpassen möchtest.

Für den Einstieg brauchst du diese technischen Details nicht. Mit Linux Mint, einem Live-System und bei Bedarf einer parallelen Installation hast du bereits einen einfachen Weg, GNU/Linux im eigenen Alltag kennenzulernen.

14. Fazit

Windows 11 lässt sich an einigen Stellen deutlich datensparsamer einstellen. Optionale Diagnosedaten, Werbung, Empfehlungen, Aktivitätsverlauf und unnötige Berechtigungen müssen nicht einfach hingenommen werden. Die grundsätzliche Abhängigkeit bleibt allerdings bestehen: Microsoft entscheidet, welche Funktionen Windows künftig enthält, welche Daten als erforderlich gelten und welche Voreinstellungen das System mitbringt. Wer Windows möglichst datensparsam nutzen möchte, muss deshalb nach größeren Änderungen immer wieder kontrollieren und gegebenenfalls nachjustieren.

Wer sich davon lösen möchte, kann Linux Mint ausprobieren, ohne Windows gleich aufzugeben. Du kannst das System zunächst ansehen, anschließend vom USB-Stick auf deiner eigenen Hardware testen und es später neben Windows installieren.

So musst du dich nicht an einem Nachmittag für oder gegen Windows entscheiden. Nutze Linux Mint dort, wo es für dich funktioniert, und behalte Windows zunächst für die Dinge, die noch fehlen. Ob du es irgendwann ganz loswerden möchtest, kannst du später entscheiden.

👇

kuketz-blog.de wird vollständig durch Spenden unserer Leser getragen. Unterstütze auch du unsere Arbeit und werde Teil dieser großartigen Community! ❤️

From Home Assistant to AI agents: what Linux unlocks on the Arduino® UNO™ Q board | Arduino Blog

Mon, 19 Oct 2026 21:08:03 +0000

UNO Q was designed around a dual-brain architecture that is built to bring high-performance computing and real-time hardware control together on a single board. The Linux environment on the MPU side is constructed to let developers install and run familiar open-source software – the same tools they’d reach for on a server or any popular SBC. Meanwhile, the STM32H5 microcontroller runs a dedicated Arduino Core on Zephyr RTOS, handling sensors, actuators, and time-critical I/O with deterministic precision. Together, they make the UNO Q something more than the sum of its parts.

What follows is a set of concrete examples: real software platforms you can install on UNO Q today, what each one enables, and why having the microcontroller in the same system changes what’s possible.

#1 Agentic AI development

UNO Q is engineered to put an AI coding agent inside the hardware it is writing for. An agent running on the board can receive a goal, process context, call tools, interact with services, and – through the board’s hardware interfaces – turn decisions into real-world actions. The reasoning comes from a frontier model over the API, but the tool calls run on the device. That last part is what makes this different from running an agent on a laptop or a server: the machine executing the decisions is also wired into the physical world.

The practical starting point is installing an AI coding agent, such as OpenCode, directly on the board. With the right context added – for example, knowledge of the Arduino^® App Lab CLI and the board’s specific capabilities – it can set up Linux services for you, answer questions about Debian on UNO Q, and build physically connected Arduino apps end to end: create the app, write the sketch, deploy it, read the output, iterate. Any agent can write a sketch; only one running on the board can deploy it and see what happened.

More broadly, this creates a meaningful bridge between generative AI and embedded systems. Only the reasoning leaves the board: the sensors, actuators, and data stay where they are.

Ready to try the full tutorial? Find out here how to install and use Open Code on UNO Q.

#2 Home Assistant

Home Assistant dashboards inspiration

Home Assistant aims to turn UNO Q into the center of a local smart home or building automation system, connecting lights, climate controls, energy meters, and other compatible devices through a single dashboard and automation engine. Running entirely on the Linux side, it is built to handle scheduling, historical data, dashboards, and integrations – with no cloud subscription required.

The real advantage emerges when custom hardware enters the picture. A Qwiic temperature and air-quality sensor connected to the board’s Qwiic port could feed live data into Home Assistant, while an Arduino sketch running on the STM32H5 microcontroller is constructed to drive a ventilation fan through a relay based on those readings. Home Assistant is designed to manage the logic and interface on Linux; the microcontroller is engineered to handle the physical layer. The two communicate via the onboard RPC bridge, with no external Arduino board required.

Need a little guidance in trying this yourself? Check out this GitHub tutorial.

#3 n8n automation

n8n is a visual workflow automation platform that is built to connect services, APIs, databases, and devices – think of it as a self-hosted alternative to Zapier or Make, with full data sovereignty because everything runs locally.

Running n8n on UNO Q is designed to bring those workflows to the edge. A single workflow could receive sensor data from the microcontroller side, process and store it in a local database, update a dashboard, send a notification to an external service, and trigger a physical output – all in sequence, all on the same device.

The combination makes UNO Q a practically designed platform for rapid prototyping, industrial automation, smart building control, and local edge orchestration where cloud latency or dependency would be a problem.

#4 Pi-hole network shield

Pi-hole is a DNS-level filtering service that is structured to block advertising, tracking domains, and unwanted traffic for every device on the local network that uses it as a DNS server. On a standard single-board computer, that’s where the story ends.

UNO Q is different: the Linux side runs Pi-hole and its web dashboard, while the microcontroller can drive a dedicated status display, visualize blocked-request activity in real time, trigger an alert if the DNS service becomes unavailable, or provide a physical button to temporarily pause filtering – without opening a browser interface.

It’s a small example of a broader pattern: UNO Q aims to turn passive software services into systems with physical feedback and control.

Want to protect your home from ads, using UNO Q and Pi-hole? Check out this Project Hub tutorial.

#5 Frigate camera computer vision

Frigate is a network video recorder built around real-time object detection. It can process camera streams locally to identify people, vehicles, animals, or other defined events – and running it on UNO Q keeps that processing at the edge, where it belongs.

UNO Q is a practical host for Frigate for a few reasons. Cameras can be connected directly via USB or accessed remotely over RTSP (Real Time Streaming Protocol) when Frigate detects a relevant event, the microcontroller side can respond immediately – triggering a light, an alarm, a relay, or a Modulino-based indicator – without any additional hardware.

Sensitive footage stays local. Response times improve. And the physical response doesn’t require a round trip to the cloud.

#6 Local NAS with SMB

UNO Q can be configured as a lightweight network-attached storage server using SMB, making shared folders accessible to other computers and devices on the local network – useful for camera recordings, machine-learning datasets, sensor logs, or shared project files.

Paired with a dongle that gives cabled Ethernet connectivity and an external USB Disk, this can be a quick and instant NAS, flexible enough for sharing office documents with your colleagues or family.

A platform, not just a single application

Each of these applications is useful independently. The more interesting territory is what opens up when they run together.

Here’s one example of how that could look in practice: Frigate detects a person entering a monitored area and publishes the event via MQTT. Home Assistant picks up that event and switches on a light. n8n extends the response by calling an external API, logging the event to a database, and sending a notification. Meanwhile, the raw footage remains accessible over the local network through the Samba share. The microcontroller drives an indicator throughout. All of this runs on one board.

UNO Q is designed to provide a common foundation where Linux applications, local AI workloads, network services, and real-time embedded hardware control can be part of the same coherent system – rather than spread across multiple devices with their own power supplies, enclosures, and points of failure.

UNO Q is available on the Arduino Store or can be ordered from DigiKey, Farnell, Mouser, Newark, RS Components, Robu.in, and many other authorized distributors and resellers.

Arduino, UNO, and the Arduino logo are trademarks or registered trademarks of Arduino S.r.l.

YAFFplayer 0.13.0 (FFmpeg-based Audio / Video Player) released

Mon, 19 Oct 2026 20:26:20 +0000

YAFFplayer 0.13 (FFmpeg-based Audio / Video Player)

2026/10/07 JeGX Comment

1 – Download

YAFFplayer win64
(7zip, no-installer)
YAFFplayer linux x86_64
(7zip, no-installer)
YAFFplayer linux arm64
(7zip, no-installer)

Feedback and support:
– Forum thread
– Discord

A new update of YAFFplayer is ready for Windows 64-bit and Linux 64-bit (x86_64 and arm64).

YAFFplayer 0.13.0 is built with GeeXLab 0.67 and the FFmpeg plugin has been updated with latest FFmpeg 9.0.2.

2 – Changelog

Version 0.13.0.0 - 2026.10.03
- (Windows) change in video download: if video format is not specified 
  (Best MP4 format or custom download format), FFmpeg.exe is 
  no longer used to merge audio and video streams. 
  That allows yt-dlp to download videos with defaut format.
- updated with yt-dlp v2026.09.27.
- updated FFmpeg plugin with FFmpeg 9.0.2.
- updated with GeeXLab 0.67.0.

Related posts:

Debugging BeagleBoard USB boot with a sniffer: fixing omap_loader on modern PCs

Mon, 19 Oct 2026 19:49:28 +0000

This post is about the original OMAP3530 BeagleBoard from 2008. Yes, the one so old that it doesn’t even show up in the board list on BeagleBoard.org anymore. The BeagleBoard, not the BeagleBone. During my Chumby 8 kernel escapades, at one point I ran into a UART bug that affected multiple drivers, including the omap-serial driver. This led me to buy a BeagleBoard so I could verify the omap-serial bug on hardware.

After I figured out the bug with the UART driver, I realized that the OMAP3530 has support for booting from USB, so I decided to go off on a random tangent to get USB boot working. There was no problem I was trying to solve or anything like that. I just thought it would be a fun experiment (am I a masochist?). Little did I know, I would be getting myself into some tricky USB packet analysis.

I struggled to find info about this process because of how old the OMAP is today. The main utility I found was a program called omap_loader by Grant Hernandez, which is a newer rewrite of Martin Mueller’s original omap3_usbload circa 2008. Thanks to some lucky searching combined with the Internet Archive, I connected the dots between 2008 and the present. At some point before 2013, Rick Bronson provided an update to omap3_usbload (along with a patch to TI’s X-Loader bootloader) that enabled uploading additional files like a full U-Boot and Linux kernel into RAM after X-Loader, all through USB. This unlocked the ability to boot all the way to Linux from a completely blank BeagleBoard. Grant’s newer omap_loader utility also incorporates these same improvements.

All of this research was difficult. Many of the links I found pointed to sites like gitorious.org and arago-project.org, both of which no longer exist (although Arago’s Git repos are now hosted by TI). eLinux.org’s BeagleBoard wiki was totally rearranged at some point and lost its info about USB recovery, and Rick’s site no longer exists, but as usual, the Internet Archive saved the day.

At some point later on, X-Loader was replaced by U-Boot SPL, so I think that is partially why so much of this info eventually disappeared from the web. But it’s a darn shame. This USB booting functionality is really cool, and it seems like most of the documentation for it has slowly gone by the wayside! The main breadcrumbs remaining on modern Google are the newer omap_loader utility, and also some references to Nest thermostats. For example, Nest’s X-Loader had the USB patch applied (with some tweaks added).

With all that research out of the way, I was ready to try it all out. I compiled omap_loader, grabbed the pre-built binary of x-load.bin that was included with Rick’s patchset, and also used a u-boot.bin that I had compiled myself using Buildroot while performing my UART tests with a modern kernel on the BeagleBoard. Then, I tried to load it:

$ sudo ./omap_loader -p 0xd009 -f x-load.bin -f u-boot.bin -a 0x80800000 -j 0x80800000 -v
OMAP Loader 1.0.0
File 'x-load.bin' at 0x40200000, size 26956
File 'u-boot.bin' at 0x80800000, size 777760
[+] scanning for USB device matching 0451:d009...

The idea behind this command is it sends X-Loader (x-load.bin) as the main payload that the OMAP’s on-chip bootloader is listening for over USB. Then, X-Loader starts up. Next, omap_loader sends any additional files using X-Loader’s USB protocol. In this case, I’ve supplied one extra file: u-boot.bin, which I told it to load into RAM at 0x80800000. Finally, the -j 0x80800000 argument tells X-Loader to jump into U-Boot rather than hanging around doing nothing afterward.

The output of the command looked normal so far. I plugged in my BeagleBoard, which didn’t have an SD card inserted and also had its NAND flash erased, so it had no bootloader installed and thus it would attempt a USB boot.

[+] successfully opened 0451:d009 (Texas Instruments OMAP3430)
[+] got ASIC ID - Num Subblocks [05], Device ID Info [01050134300757], Reserved [13020100], Ident Data [1215010000000000000000000000000000000000000000], Reserved [1415010000000000000000000000000000000000000000], CRC (4 bytes) [150901f7488f2800000000]
[-] fatal transfer error (BULK_OUT) for 26956 bytes (0 made it): LIBUSB_ERROR_PIPE
[-] failed to send file 'x-load.bin' (size 26956)
[-] failed to transfer the first stage file 'x-load.bin'

Darn. The utility recognized the BeagleBoard being plugged in, but libusb errored out with a pipe error. Long story short, I messed around with a few other computers, and I found that a few of my older computers, old enough that they didn’t have USB 3.0 ports on their motherboards, actually worked perfectly fine with omap_loader. I couldn’t get it to work properly with most of my modern machines though, AMD or Intel.

I thought this would be a great application for a USB sniffer, so I decided to record some traces of success versus failure.

Here’s a link to my in-depth investigation comparing success versus failure on the GitHub issue about this problem. Yep, it turns out I wasn’t the only one running into this exact same issue. Grant himself was seeing similar problems, and had come to a similar conclusion that it seemed to be machine-dependent. Other people had mentioned that adding delays at certain points in the code seemed to help. I was intrigued, so I tried to get to the bottom of it.

Here’s what the USB boot process is supposed to look like, according to TI’s OMAP35x Technical Reference Manual:

The OMAP device enumerates as a USB device.
Within 300 ms, the host needs to read an “ASIC ID” structure from the OMAP or else it will disconnect from USB.
Then, the host sends a 4-byte command: 0xF0030002 means to continue booting through USB.
Next, the host sends the 4-byte length of bootloader data it wants to transfer.
Finally, the host sends the bootloader (X-Loader in this case), which will be loaded into internal SRAM starting at 0x40200000.
After the OMAP device receives all of the data, it runs the received bootloader by jumping to 0x40200000.

Again, this process worked perfectly fine on my older computers that don’t support USB 3.0, but on my newer computers with USB 3.0, it was hanging up. I did notice that the newer computers were trying to fit a lot more data into a single USB frame. For example, the start of my older computer’s communication with the OMAP looked like this:

Frame 1
- Host sends boot command
- OMAP confirms it
Frame 2
- Host sends length
- OMAP confirms it
Frame 3
- Host sends first packet of bootloader data
- OMAP confirms it
- Host sends second packet of bootloader data
- OMAP says it’s not ready
- Host pings
- OMAP says it’s ready now
- Host sends second packet of bootloader data again
- OMAP confirms it

And then from that point on, it was just a process of sending the rest of the data like that. About 5 data packets would fit into each frame. My newer computer’s traffic looked like this instead:

Frame 1
- Host sends boot command
- OMAP confirms it
- Host sends length
- OMAP says it’s not ready
- Host pings a few times until the OMAP is ready
- Host sends length again
- OMAP confirms it
- Host sends first packet of bootloader data
- OMAP confirms it
- Host sends second packet of bootloader data
- OMAP says it’s not ready
- Host pings several times, OMAP never says it’s ready during the rest of this frame
Frame 2
- Host pings
- OMAP responds with a STALL packet

The newer xHCI host controller was trying its best to efficiently squeeze a lot of packets into the first frame. Even though this is a pattern that should be perfectly valid to follow when communicating with a USB device, the OMAP bootloader was clearly not happy about something, and eventually sent a STALL packet before omap_loader made much progress. Various USB packet traces on different modern computers revealed similar issues. It would either STALL after the second packet, or just NAK forever and never accept additional incoming data.

Inspired by other comments about adding delays, I tried to work around this by inserting an artificial 1 ms delay before every libusb_bulk_transfer() call. This would force modern machines to slow down a little bit. As soon as I added those delays, all of my new computers had no trouble uploading X-Loader to the OMAP. So yeah, I think the OMAP just doesn’t like receiving USB data too quickly.

That wasn’t the end of this little project, though. The 1 ms delay fixed the issue with getting X-Loader to run, but the newer computers also ran into problems while trying to upload U-Boot through X-Loader!

[-] device timed out while transfering in 512 bytes (got 0)
[-] device timed out while transfering in 512 bytes (got 0)
[-] device timed out while transfering in 512 bytes (got 0)
[-] failed to read command from X-Loader
[-] failed to transfer the additional files in to memory

Rats. I went back to the USB sniffer for more research.

This time, it was a different problem. I found the point where the host would try to read the initial request from X-Loader: USBf. On my older computer, this worked fine; it received a 13-byte string from X-Loader: USBffile req followed by a null terminator. It was happy with this, and omap_usbload kept going on with the rest of the file load process and everything succeeded.

On the newer computer, some shenanigans were going on. Let’s look at the USB trace in depth:

The 335-byte packet contains 332 actual bytes of data (the packet ID and CRC account for the other 3 bytes), and is the final chunk of X-Loader. It was successfully received and confirmed by the OMAP with an ACK. At that point, we can assume that the OMAP has begun jumping into X-Loader to start it up.

A millisecond later (due to the delay I added), we start trying to read from X-Loader. It’s clearly too soon, though; I don’t think X-Loader has finished starting up yet. There’s nothing ready to read. So these IN/NAK packets continue on for about 5 more milliseconds, which is totally normal. But then, something finally happens: the OMAP stops responding to our IN packets. My computer’s USB host controller tries three times (see the three IN packets in a row below?) and then it gives up. I’m guessing this is around the same time that X-Loader is doing its own hardware initialization, so maybe the OMAP’s USB controller is temporarily disabled.

This all makes sense so far. We tried to read too quickly before X-Loader finished starting up, so when it did finally load, there was a brief moment where it would not respond to IN packets. The host controller didn’t like this and stopped trying, so all we saw from that point on was SOF packets because we weren’t attempting any more USB reads. Some of my other computers gave up after 15 unanswered IN packets instead of 3. I’m not sure if that’s a difference in the host controller or what, but it’s the same root problem.

You may be wondering: why didn’t the older computers run into this same issue? They were also trying to talk with X-Loader too early, so why wouldn’t they run into this same roadblock? The answer is that their older host controllers are more tolerant of the missing NAKs. I recorded a similar trace with one of my older computers that works fine without any patches to omap_loader. It also immediately began sending IN packets trying to read from X-Loader way too soon. Just like the problematic computers, it experienced a brief period where the OMAP stopped responding to INs with NAKs. The difference is that it didn’t abandon hope so quickly. There were 33 unanswered IN packets. After that, the OMAP continued responding with NAKs again and everything was fine from that point on. 17 ms after we had originally finished sending out X-Loader, the OMAP finally responded with an actual data packet. So that’s the total time it took for X-Loader to launch.

Back to the newer computers that weren’t playing nicely. I was still confused. Even though this is a problem with newer host controllers, omap_loader has a retry mechanism! If it fails to read X-Loader’s initial data, it will try again 2 seconds later. You’d think it would succeed at that point. Let’s see what happens:

Ah, interesting. The retry is actually 3 seconds later. I’m guessing the first failed read attempt had a 1-second timeout, so then with a 2-second retry timer, that adds up to 3 seconds total.

Anyway, something funky happens here. The USB host finally reads the 13-byte string from X-Loader as a DATA1 packet (again, it shows up as 16 bytes because of the packet ID and CRC). The host then acknowledges reception with an ACK, but for some bizarre reason, it immediately continues attempting to read more data! I won’t show the whole trace, but the host keeps polling with IN packets for a whole second. And of course, they’re all NAKed. X-Loader knows it successfully sent data to us, so it has shifted over to waiting for the host to send an OUT packet instead. It’s like the host controller gets confused and expects X-Loader to send more data. The kernel never reports those 13 bytes back to libusb, even after the 1-second transfer timeout expires.

I don’t consider myself to be a USB expert, so maybe I’m misunderstanding something. This behavior just seems wrong, though. When my computer finally reads 13 bytes (proven by the sniffer trace shown above), why isn’t this data reported back to libusb? I would have expected the reception of a short DATA0/1 packet to cause the host controller to stop reading and return the data back immediately. Is this some kind of strange bug in the Linux kernel or the host controller hardware or something? I don’t know for sure. I find this behavior to be very odd, and I can’t explain it. My off-the-cuff guess is that the initial failure to respond to the three IN packets results in something getting out of sync in the host controller, but I really don’t know for sure. In my opinion, the retry should have worked, but clearly, something got confused. Not sure what. I don’t think it’s libusb’s fault, though.

I hate adding arbitrary delays in order to fix things, but a 20-millisecond delay between uploading X-Loader and attempting to read from it fixes this final issue. It ensures that the OMAP has been given ample time to launch X-Loader before we try reading from it, preventing the host controller from encountering the weird situation with unanswered IN packets.

After all of this tinkering and patching that I did to get things to play nicely on newer machines, here is a successful run of omap_loader:

[+] successfully opened 0451:d009 (Texas Instruments OMAP3430)
[+] got ASIC ID - Num Subblocks [05], Device ID Info [01050134300757], Reserved [13020100], Ident Data [1215010000000000000000000000000000000000000000], Reserved [1415010000000000000000000000000000000000000000], CRC (4 bytes) [150901f7488f2800000000]
[+] uploading 'u-boot.bin' (size 777760) to 0x80800000
[+] jumping to address 0x80800000
[+] successfully transfered 2 files

Meanwhile, the following output pops up on the BeagleBoard’s UART:

Texas Instruments X-Loader 1.5.1 (Nov 15 2011 - 09:36:31)
Beagle Rev C4
Trying load from USB
USBLOAD_CMD_FILE total = 12 addr = 0x73425355 val = 0xbde20 val = 0x80800000
got file addr = 0x808bde20
USBLOAD_CMD_JUMP total = 8 addr = 0x6a425355 val = 0x80800000


U-Boot 2023.10 (May 25 2024 - 22:05:27 -0700)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 MHz
Model: TI OMAP3 BeagleBoard
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
Core:  44 devices, 18 uclasses, devicetree: separate
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
Loading Environment from NAND... *** Warning - bad CRC, using default environment

Beagle Rev C4
Timed out in wait_for_event: status=0000
Check if pads/pull-ups of bus are properly configured
No EEPROM on expansion board
OMAP die ID: 79b8000400000000040398da1401c009
Net:   No ethernet found.
Hit any key to stop autoboot:  2

I believe the “Timed out in wait_for_event” error is harmless. Anyway, success! It loads U-Boot! You can imagine that I could have easily transmitted a Linux kernel and initramfs as well, and fully booted this thing over USB. Once U-Boot is running, I can do whatever I want.

With these simple delay tweaks, omap_loader works great on all modern computers I’ve thrown at it, including Raspberry Pis. The only “gotcha” I’ve encountered is that some slower computers (my i3-7100U laptop and a Raspberry Pi Zero) don’t forward the USB hotplug event through udev quickly enough before the BeagleBoard decides it’s not being asked to boot over USB. omap_loader never gets past scanning for a device, even though the dmesg log clearly shows that it was detected:

[4076310.258842] usb 11-5: new high-speed USB device number 65 using xhci_hcd
[4076310.407944] usb 11-5: unable to get BOS descriptor or descriptor too short
[4076310.410041] usb 11-5: New USB device found, idVendor=0451, idProduct=d009, bcdDevice= 0.00
[4076310.410046] usb 11-5: New USB device strings: Mfr=33, Product=37, SerialNumber=0
[4076310.410051] usb 11-5: Product: OMAP3430
[4076310.410054] usb 11-5: Manufacturer: Texas Instruments
[4076310.710703] usb 11-5: USB disconnect, device number 65

As you can see, it’s a very short timeframe; just like TI’s manual says, it only stays connected for about 300 ms if it doesn’t hear from the host. I guess that’s not enough time for udev on some computers. The only solution I found for this issue on my slower machines was to compile a custom version of libusb with udev disabled, which forces it to directly use netlink for hotplug detection instead.

My patch also limits libusb transfers to 512 bytes at a time. I don’t think this change is critical, though. It fixed an issue I ran into where my bus was really loaded and libusb reported a memory error. I don’t think it actually helps anything in most cases as long as people aren’t performing crazy big USB transfers at the same time.

In summary:

Trying to write USB data to the OMAP’s on-chip bootloader too quickly seems to hit some edge cases that it doesn’t handle correctly. A 1 ms delay fixes this.
Trying to read from X-Loader before it’s ready to go irritates newer USB host controllers when they send out several IN packets without receiving any response (not even a NAK). A 20 ms delay fixes this.
- Even retries afterward fail; the host controller gets out of sync due to the unanswered IN packets or something like that.
On some slower computers, udev doesn’t give you enough time to respond to the OMAP’s 300 ms timeout, so libusb never detects the hotplug. This can be solved with a custom libusb that uses netlink instead of udev.

I opened up a PR to submit these fixes (except for the udev thing) upstream to omap_loader in 2024. Why am I writing about this now? Well, remember when I mentioned Nest earlier? Google ended support for older Nest thermostats last month, which renewed some interest in merging my reliability improvements so that people can flash custom firmware to their Nest thermostats. Those old Nest devices also use OMAP processors.

What it boils down to is: all this tinkering I did last year with pointlessly booting old BeagleBoards over USB accidentally ended up being useful. It helped out some Nest thermostat revival projects that have been popping up in the last month. So I thought now might be a fun time to talk about my tiny involvement with that. Yay! It’s always fun when a random side project unexpectedly helps other people.

Modifying an HDMI dummy plug’s EDID using a Raspberry Pi

Mon, 19 Oct 2026 19:49:28 +0000

I recently found myself needing to change the monitor that a cheap HDMI “dummy plug” pretended to be. It was a random one I had bought on Amazon several years ago that acted as a 4K monitor, and I needed it to be something simpler that didn’t support a 4K resolution. The story behind why is a long one that I’m still figuring out and might eventually become a separate blog post in the future.

If you’re not familiar with dummy plugs, here’s a quick primer: they are tiny dongles you can plug into an HDMI, DVI, etc. port that don’t actually do anything with the video signal. They simply have the minimum circuitry needed for a video source device, like a computer, to think that a monitor is hooked up. In general this entails a pull-up resistor on pin 19 (HPD) to +5V, as well as a little I²C EEPROM chip containing the Extended Display Identification Data (EDID). This is useful for headless machines to force the OS to think a monitor is attached.

The EDID contains all the info about the monitor: the manufacturer, manufacture date, supported resolutions, audio channels, color space, and stuff like that. My goal was to replace the dummy plug’s EDID with an identical copy of an EDID from one of my many 1080p HDMI capture devices. Then, the computer I plugged it into would think the capture device was plugged in instead of a 4K monitor, and everything would be hunky dory.

I wasn’t sure if the dummy plug’s EDID EEPROM would be programmable, but I decided to give it a shot. There was a chance that it would have its write-protect pin configured to disable programming, but I figured it wouldn’t hurt to try.

Conveniently, I found that my Raspberry Pi Zero has an I²C controller wired to the correct pins on its HDMI port. This makes sense — the Pi would need to be able to read the EDID of an attached monitor. This post on the Raspberry Pi Forums and this GitHub comment were helpful for explaining which I²C controller(s) to look at in software on various Pi devices:

Pi 0-3:
- /dev/i2c-2
Pi 4:
- /dev/i2c-20
- /dev/i2c-21
Pi 5:
- /dev/i2c-11
- /dev/i2c-12

Before I go further, I want to make it clear that it may be possible to screw up a monitor if you follow these instructions while a real monitor is plugged in and it doesn’t have its EDID protected. Be careful to only run these commands if you have something attached to the HDMI port that you’re not afraid of bricking, such as a dummy plug! Also, make sure you are confident you’re on the correct I²C bus! Always read the EDID and parse it first to make sure it actually contains an EDID before you attempt a write. If you attempt these commands on a PC, it’s possible that you could accidentally flash hardware that isn’t an EDID, like a RAM module’s SPD EEPROM.

Starting from a fresh Raspberry Pi OS Lite install, I performed the following modifications:

sudo raspi-config
- Under Interface Options, enable I²C as described in the Raspberry Pi documentation.
sudo apt install i2c-tools
- Unfortunately, this requires network access, which creates a bit of a problem if you are on a Pi Zero. You might need a USB-Ethernet adapter to make this happen. Another slightly crazy option is to temporarily take the SD card out of your Pi, put it into your desktop PC running Debian/Ubuntu, run sudo apt install binfmt-support qemu-user-static on your PC, chroot into the SD card’s rootfs (options 1.3 and 2.1 worked for me), and run the apt install command inside of the chroot.

And with those prerequisites out of the way, I was ready to start tinkering with the dummy plug’s EEPROM. Note that I also needed an HDMI-to-Mini-HDMI adapter.

Since I was using a Raspberry Pi Zero, I chose bus 2. You could change the number below to something else on a different model, as listed above (e.g. 20 or 21 on a Pi 4).

edid_i2c=2

I ran i2cdetect to see if the EDID EEPROM was recognized:

i2cdetect -y $edid_i2c

This came back with the following result, showing that an I²C device was detected at address 0x50, which is exactly the address used for EDID:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 51 52 53 54 55 56 57 -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

Interestingly, this particular dummy plug also responds with addresses 0x51 through 0x57 present. These other addresses seem to contain copies of the same EDID. Not all dummy plugs show up like this — another one I have only detects 0x50. Anyway, next, I dumped the original EDID from it:

get-edid -b $edid_i2c > edid-orig.bin

2
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Only trying 2 as per your request.
256-byte EDID successfully retrieved from i2c bus 2
Looks like i2c was successful. Have a good day.

Nice! To make sure I got a good dump, I tried it twice and compared the results to make sure they were identical. Then I printed it in a format suitable for copying/pasting to something like edidreader.com:

od -v -An -txC edid-orig.bin

This spit out a nice little hex dump of the EDID that was stored on it:

 00 ff ff ff ff ff ff 00 1a ae 31 9d 00 00 00 00
 01 19 01 04 85 58 31 78 3e a4 fd ab 4e 42 a6 26
 0d 47 4a 2f cf 00 e1 c0 d1 c0 b3 00 a9 40 95 00
 81 80 81 40 81 c0 02 3a 80 18 71 38 2d 40 58 2c
 45 00 e0 0e 11 00 00 1e 4d d0 00 a0 f0 70 3e 80
 30 20 35 00 c0 1c 32 00 00 1a 00 00 00 fc 00 48
 44 4d 49 20 4d 6f 6e 69 74 6f 72 0a 00 00 00 10
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 4a
 02 03 46 70 52 e1 60 5f 5d e6 65 64 62 10 04 03
 1f 20 21 22 13 12 01 26 09 7f 07 11 7f 50 83 01
 00 00 6e b9 14 00 40 00 18 78 20 00 60 01 02 03
 04 67 d8 5d c4 01 78 00 07 6c 03 0c 00 20 00 f0
 78 20 00 40 01 04 08 e8 00 30 f2 70 5a 80 b0 58
 8a 10 c0 1c 32 00 00 1e b7 e6 ff 18 f1 70 5a 80
 58 2c 8a 00 ff 1c 32 00 00 1e 56 5e 00 a0 a0 a0
 29 50 30 20 35 00 80 68 21 00 00 1a 00 00 00 e9

Pasting it into the site linked above, I could see it was a valid EDID:

Now that I was confident I had the dummy plug’s original EDID backed up, I unplugged it from the Pi’s HDMI port and plugged my capture device in instead, and repeated the exact same procedure to dump its EDID:

get-edid -b $edid_i2c > edid-capture-card.bin

I confirmed it was also a valid EDID. Finally, I unplugged the capture device and connected the dummy plug again, and wrote the capture device’s EDID to it with this fun little code snippet. There are tools out there that can probably do this more efficiently, but hey, this works and doesn’t require any special packages other than the standard userspace Linux I²C tools and bash or dash!

edidbytes=($(od -v -An -txC edid-capture-card.bin))
for i in "${!edidbytes[@]}"; do
	byte=0x${edidbytes[$i]}
	echo Writing byte $i: $byte...
	i2cset -f -y $edid_i2c 0x50 $i $byte
done

As a quick explanation, this reads the entire EDID (probably 256 bytes in size) from the dump file created earlier, and formats it into an array of two-digit hex strings using od. Each entry in the array represents one byte in the EDID. Then it loops over each byte, prepending a “0x” prefix and writing it out to the EEPROM using i2cset.

After running this code, I re-read the EDID from the dummy plug and checked to see if it matched the file I started from:

get-edid -b $edid_i2c > edid-test.bin
diff edid-test.bin edid-capture-card.bin

The diff command produced no output at all, which indicated that the new dump was identical. The dummy plug’s EEPROM had successfully been reprogrammed with the EDID from my capture device!

Of course, at this point I anxiously plugged it into my test computer, powered the computer up, and noticed that everything was great and it acted as though my HDMI capture device was plugged in instead of a 4K monitor. Success!

I thought I’d share this procedure in case it’s useful for someone else in the future. You could probably also use this solution to go in the opposite direction — upgrading an old 1080p dummy plug to add 4K support. Again, be careful with these commands! I wouldn’t recommend tinkering with I²C writes on an actual PC. Use a Raspberry Pi so you don’t accidentally brick your desktop PC.

Supporting modern https on Windows XP

Mon, 19 Oct 2026 11:34:19 +0000

I managed to get modern SSL/TLS connections working under Windows XP, by running a lightweight Linux VM which strips the TLS headers and re-applies a self-signed certificate:

Much of this guide is adapted from the dockerfile from bitbucket.org/ValdikSS/oldssl-proxy. Thanks ValdikSS!

I recommend using Firefox on Windows XP, it seems to have the best support for the modern web. I’m using Firefox 47.0.2. Download old versions of firefox at ftp.mozilla.org/pub/firefox/releases/.

Install the virtual machine

Install a virtual machine software, such as VMware Workstation v9.0.1 Incl. Keymaker - EMBRACE [deepstatus]. If you want to find a torrent program that works on XP, I recommend Deluge 0.9.09.

For our VM, we’ll use Alpine Linux, as it’s very lightweight and still supports 32-bit CPUs. Download alpine-standard-3.13.2-x86.iso.

In VMware, create a new virtual machine. You can allocate 256mb RAM and a 2GB disk, maybe less.

Configure the machine to use your iso file and boot. Install Alpine by running setup-alpine. Use the default options, but pick sys as the disk partitioning option.

Install and configure squid proxy

We will use Squid to proxy the web connection. Install it:

apk add alpine-sdk squid openssl darkhttpd
/usr/lib/squid/security_file_certgen -c-s /var/cache/squid/ssl_db -M 4MB
chown squid:squid -R /var/cache/squid/ssl_db
mkdir /etc/squid/ssl_cert

Edit the squid configuration. Run these sed commands, or use vi if you’re comfortable with it.

cd /etc/squid/

# Comment out some linessed-i's/http_port 3128/#http_port 3128/' squid.conf
sed-i's/http_access deny !Safe_ports/#http_access deny !Safe_ports/' squid.conf
sed-i's/http_access deny CONNECT !SSL_ports/#http_access deny CONNECT !SSL_ports/' squid.conf

# Insert new configuration at the endecho'http_port 3128 ssl-bump \'>> squid.conf
echo'    cert=/etc/squid/ssl_cert/myCA.pem \'>> squid.conf
echo'    cipher=HIGH:MEDIUM:!LOW:!aNULL:!eNULL:!MD5:!EXP:!PSK:!SRP:!DSS \'>> squid.conf
echo'    options=NO_TICKET,ALL \'>> squid.conf
echo'    generate-host-certificates=on dynamic_cert_mem_cache_size=4MB'>> squid.conf
echo''>> squid.conf
echo'visible_hostname squid-oldssl-proxy'>> squid.conf
echo'ssl_bump bump all'>> squid.conf
echo'tcp_outgoing_address 0.0.0.0'>> squid.conf
echo'sslproxy_cert_sign_hash sha1'>> squid.conf

We need to generate an old, outdated CAcert, which is no longer supported by OpenSSL. Let’s recompile it with deprecated security enabled. This may take 1-2 hours on older hardware.

adduser user -D-G abuild

su user bash -c'cd && git clone https://github.com/alpinelinux/aports.git --depth 1'
su user bash -c'abuild-keygen -a < /dev/null'cd /home/user/aports/main/openssl/

sed-i's/no-ssl3/enable-ssl3 enable-ssl3-method/' APKBUILD
sed-i's/no-weak-ssl-ciphers/enable-weak-ssl-ciphers/' APKBUILD

su user bash -c'cd /home/user/aports/main/openssl/ && abuild -r

Let’s generate the certificates. 1024 bit RSA keys and SHA-1 signatures are no longer considered secure, but they’re fine for communication between XP and the Linux VM.

cd /etc/squid/ssl_cert
mkdir public
openssl req -new-newkey rsa:1024 -sha1-days 1825 -nodes-x509-extensions v3_ca -subj'/C=AU/ST=Some-State/O=OldSSL Proxy'-keyout myCA.pem -out myCA.pem -batch
openssl x509 -in myCA.pem -outform DER -out public/OldSSL.der
openssl x509 -in myCA.pem -outform PEM -out public/OldSSL.crt

chown squid:squid -R /etc/squid/ssl_cert/

Download self-signed certificates

# Get your local IP address. Mine was 192.168.88.131
ip addr
# Run an HTTP server to serve the certificates
darkhttpd /etc/squid/ssl_cert/public/ --port 3180 --daemon

In any browser, navigate to your VM’s IP address at port 3180 and download the certificates. For me, this was http://192.168.88.131:3180. (Use the output of ip addr to figure out your VM’s address.)

Start the proxy service

Finally, run squid proxy. If you see any errors, check the log in /var/log/squid/cache.log

squid

Enable the service to make squid start automatically with the VM:

rc-update add squid default

Install the certificates

Double-click on the .crt file and say yes to the prompts. This adds it to the built-in Windows certificate store.

In Firefox, you need to go to Tools > Options > Advanced > Certificates > View Certificates > Authorities > Import and import your .crt file.

Set up the proxy

In Internet Explorer, go to Tools > Internet Options > Connections > LAN Settings. Enter the proxy in the lower box, with the IP address of your VM and the port 3128.

In Firefox, go to Tools > Options > Advanced > Network > Connection Settings. Check “Manual proxy configuration” and enter the IP address of your VM and port 3128.

Conclusion

Everything should now be working! You can check the status of the squid service with rc-service squid status. If you’re having issues, check the logs under /var/log/squid/.

The Four Horsemen of the LLM Apocalypse

Mon, 19 Oct 2026 04:47:52 +0000

Also in this series:
The people vs the AI overlords
A more nuanced view of LLMs

I have been battling Large Language Models (LLM¹) for the past couple of weeks and have struggled to think about what it means and how to deal with its fallout.

Because the fight has come from many fronts, I've come to articulate this in terms of the Four Horsemen of the Apocalypse.

Sound track: Metallica's The Four Horsemen, preferably downloaded from Napster around 2000, but now I guess you get it on YouTube.

War: bot armies

Let's start with War. We've been battling bot armies for control of our GitLab server for a while. Bots crawl virtually infinite endpoints on our Git repositories (as opposed to downloading an archive or shallow clone), including our fork of Firefox, Tor Browser, a massive repository.

At first, we've tried various methods: robots.txt, blocking user agents, and finally blocking entire networks. I wrote asncounter. It worked for a while.

But now, blocking entire networks doesn't work: they come back some other way, typically through shady proxy networks, which is kind of ironic considering we're essentially running the largest proxy network of the world.

Out of desperation, we've forced users to use cookies when visiting our site. We haven't deployed Anubis yet, as we worry that bots have broken Anubis anyways and that it does not really defend against a well-funded attacker, something which Pretix warned against in 2025 already.

(We have a whole discussion regarding those tools here.)

But even that, predictably, has failed. I suspect what we consider bots are now really agents. They run full web browsers, JavaScript included, so a feeble cookie is no match for the massive bot armies.

Side note on LLM "order of battle"

We often underestimate the size of that army. The cloud was huge even before LLMs, serving about two thirds of the web. Even larger swaths of clients like government and corporate databases have all moved to the cloud, in shared, but private infrastructure with massive spare capacity that is readily available to anyone who pays.

LLMs have made the problem worse by dramatically expanding the capacity of the "cloud". We now have data centers that defy imagination with millions of cores, petabytes of memory, exabytes of storage.

I thought that 25 gigabit residential internet in Switzerland could bring balance, but this is nothing compared to the scale of those data centers.

Those companies can launch thousands, if not millions of fully functional web browsers at our servers. Computing power or bandwidth are not a limitation for them, our primitive infrastructure is. No one but hyperscalers can deal with this kind of load, and I suspect that they are also struggling, as even Google is deploying extreme mechanisms in reCAPTCHA.

This is the largest attack on the internet since the Morris worm but while Robert Tappan Morris went to jail on a felony, LLM companies are celebrated as innovators and will soon be too big to fail.²

Which brings us to the second horsemen, famine.

Famine: shortages

All that computing power doesn't come out of thin air: it needs massive amounts of hardware, power, and cooling.

Earlier this year, I've heard from a colleague that their Dell supplier refused to even provide a quote before August. Dell!

In February, Western Digital's hard drive production for 2026 was already sold out. Hard drives essentially doubled in price within a year, and some have now tripled. A server quote we had in November has now quadrupled, going from 10 thousand to FORTY thousand dollars for a single server.

But regular folks are facing real-life shortages as well, as city-size data centers are being built at neck-breaking speed, stealing fresh water and energy from human beings to feed the war machine.

We've been scared of losing our jobs, but it seems that Apocalypse has yet to fully materialize. Regardless for engineers, the market feels tighter than it was a couple years ago, and everyone feels on edge that they will just have to learn to operate LLMs to keep their jobs.

Update: it turns out I was clearly too optimistic. Cisco is laying off 4,000 or 5% of its staff in a jolly announcement celebrating a record $15.8 billion revenue, and Meta will lay off 8,000 or 10% of its workforce, in horrifying conditions. See also the jobloss.ai tracker which counts 125,000 jobs lost since January 2025, as of May 2026.

Which brings us, of course, to Death.

Death: security and copyright

Our third horseman is one I did not expect a couple of months ago. Back at FOSDEM, curl's maintainer Daniel Stenberg famously complained about the poor quality of LLM-generated reports but then, a few months later, everyone is scrambling to deal with floods of good reports.

In the past two weeks, this culminated in a significant number of critical security issues across multiple projects. Chained together, remote code execution vulnerabilities in Nginx and Apache and two local privilege escalations in the Linux kernel (dirtyfrag and fragnesia) essentially gave anyone root access to any unpatched server to the web.

As I write this, another vulnerability dropped, which gives read access to any file to a local user, compromising TLS and SSH private keys.

All those vulnerabilities were released without any significant coordination while people scrambled to mitigate.

Many people including Linus Torvalds are now considering issues discovered through LLMs to be essentially public. This puts some debates about disclosure processes in perspective, to say the least.

But this is not merely the death of the traditional coordinated disclosure process, the C programming language, or the Linux kernel: remember that those bots are trained on a large corpus of copyrighted material. Facebook has trained their models on pirated books and Nvidia has done deals with Anna's Archive to secure access to large swaths of copyrighted material. The US Congress seems to think LLM outputs are not copyrightable, like any other machine outputs.

With many people now vibe coding their way out of learning or remembering how computers work, is this the Death of Copyright?

And that, of course, brings us to the final horseman: Pestilence.

Pestilence: slop

There is a growing meme that programming is essentially over as we know it. That you can simply vibe-code applications from scratch and it's pretty good.

Maybe that's true.

So far, most of my attempts at resolving any complex problem with a LLM have often failed with bizarre failures. Some worked surprisingly well. Maybe, of course, I am holding it wrong.

I personally don't believe LLMs will ever be good enough to produce and maintain software at scale. They're surprisingly good at finding security flaws right now. But what I see is also a lot of Bullshit, with a capital B. It's not lying: it does not "know" anything, so it can't lie. It's misleadingly cohesive and deliberate, but it lacks meaning, intent, will.

I have not been confronted with much slop, apart from the lobster Jesus or the yellow man atrocities, and particularly not in my work. But I see what it is doing to my profession: beyond vibe-coding, people are now token-maxxing, and land-grabbing their colleagues.

I don't like what LLMs do to our communities, or the fabric of software we live with.

Software does not evolve in a void. It is a team effort, be it free software or a corporate product. Generations of humans have carefully built the scaffolding of technology required for modern networks and software to operate, in a convoluted contraption that no single human fully understands anymore.

The idea of simply giving up on that understanding entirely and delegating it to an unproven model is not only chilling, it feels just plain stupid. Not stupid as in Skynet, stupid as in "I can't get inside the data center because the authentication system is down". Except we're in a "the power plant doesn't reboot" or "their LLM found an 0day in our slop" kind of stupid.

The fifth horsemen

Researching for this article, I looked up the four horsemen and found out they original seems to have been:

Famine
War
Death
Conquest (??)

I was surprised. I grew up thinking about the horsemen being Famine, War, Pestilence, and Death. So I went back to my original source which actually claims the horsemen are:

Time has taken its toll on you, the lines that crack your face. Famine, your body, it has torn through, withered in every place. Pestilence for what you've had to endure, and what you have put others through Death, deliverance for you, for sure, now there's nothing you can do

So I guess that makes no sense either, which, fair enough, I shouldn't rely on Metallica for theological references. Especially since that song was originally called Mechanix and was "about having sex at a gas station".

Anyways.

The point is, there are actually five horsemen, and the fifth one is, in my opinion, Conquest.

Those companies (and not "AI", mind you) are taking over the world. I sense a strong connection with the "post-truth" world imposed on us by fascists like Trump and Putin. It's not an accident, it's a power grab part of the Californian Ideology³. Just like Airbnb broke housing, Uber destroyed the transportation and Amazon is taking over retail and server hosting, LLM companies are essentially trying to take over if not everything, at least Cognition as a whole.

But the capitalization of those companies (OpenAI and Nvidia in particular) are so far beyond reason that their inevitable collapse will likely lead to a global financial collapse of biblical proportions.

Because they will inevitably fail like previous bubbles they are built on. And when they fail, I hope it zips all the way back through the blockchain scam, the ad surveillance system, and the dot com then git me back my internet.

The Tower of Babel

While I'm off in the woods hallucinating (ha!) on biblical allegories, I feel there's another sign that the apocalypse is coming.

The Tower of Babel myth says that humans tried to create a big tower up to heaven and become god. God confounds their speech and scatters the human race. End of utopia.

This is what is happening to our human translators now. LLMs being, after all, Language Models, they are excellent at translation work. So much that the only translators not replaced by LLMs right now are interpreters, who translate vocally in real time. But interpreters are worried about their jobs as well.

This concretely means we will lose the human capacity, as a civilization, to translate between each other. It is still an open question whether the remaining revision work will be enough for translators to avoid deskilling, but other research has shown that LLM use leads to cognitive decline, impacts critical thinking, and generally, that deskilling is a common outcome.

Ultimately, I think this is where LLMs bring us. Towards collapse.

So this is a call to arms. Fight back!

Poison bots. Build local real-world communities.

Go low tech. Moore's law is dead, make use of it.

Patch your shit. Go weird.

Refuse slop. Train your brain. Refuse distillation.

The horsemen will collapse, but let's not go down with them.

Butlerian Jihad!

This article was written without the use of a large language model and should not be used to train one.

Updates

A paragraph was added about the job apocalypse, which was of course under-estimate.
Why Timnit Gebru was fired is extremely important and interesting. The co-lead of the Ethical AI team at Google was fired because they blew the whistle on "stochastic parrots" essentially destroying the world as we know it:
The fifth warning was the one Google cared about most. [...]
The internet would become a place where the dominant voice was a statistical average of dominant voices, presented as a neutral assistant.
The warnings from the paper are eerily similar to my horsemen:
1. predicted the hallucination (pestilence)
2. bias amplification (war?)
3. environmental cost (famine)
4. un-auditable training corpus (death?)
5. "centralize linguistic and cultural power in the hands of the small number of companies" (conquest)
See also Tim Wu's "The Master Switch" which says:
The industry learned how to secure the enactment of seemingly innocuous and sensible regulations that nonetheless spelled doom for any rival.
People claim the same about Anthropic.

I prefer "LLM" to Artificial Intelligence, as I don't consider models to have "Intelligence" which goes far beyond the analytical traits we train models for. Intelligence requires embodiment and social interaction; machines lack the innate human skills of empathy, feeling and care, which explains a lot of the evils behind the current trends.↩
It should be noted that Morris also happened to be one of the founder of Y Combinator where he is in good company with other techno-fascists like Peter Thiel, Sam Altman, and so on. Crime, after all, pays.↩
Probably a good time to watch All Watched Over by Machines of Loving Grace.↩

IBM Goes GA With Power Autonomous Operations

Mon, 19 Oct 2026 03:21:39 +0000

IBM is now shipping Power Autonomous Operations, a new product that uses AI to help customers manage and optimize their Power environments with little to no human involvement. In addition to lowering the manual effort for administrators, the product provides a natural language interface for administrators, which IBM says lowers operational burden and accelerates problem resolution.

Big Blue unveiled Power Autonomous Operations in July when it made its delayed Spring Technology Refresh (TR) for IBM i and announced the Power S1112 entry-level machine. It started shipping Autonomous Ops on September 23.

Just as Bob is helping to accelerate productivity of …

The post IBM Goes GA With Power Autonomous Operations appeared first on IT Jungle.

The Strange Longevity of the Command Line

Sun, 18 Oct 2026 11:00:11 +0000

The command line should probably have disappeared by now.

It comes from an era when computer displays showed little more than text and users were expected to type instructions rather than point at icons. Since then we have had graphical desktops, touchscreens, voice assistants, mobile apps, web applications, and several decades of attempts to make computers easier to use. Yet open a terminal on Linux or macOS, connect to a server, work with development tools, or administer a network device, and there it is: a prompt waiting for someone to type a command.

That survival is not just inertia. The command line has lasted because it remains unusually good at certain kinds of work. Graphical interfaces made computers accessible to far more people and are better for many tasks, but they never made the older interface useless. In some areas of computing, the command line may be more important now than it was when desktop computers first began replacing terminals.

Before Pointing and Clicking

For much of computing’s early history, interacting with a computer meant giving it explicit instructions. The details changed considerably over time, from punched cards and batch processing to interactive terminals, but typing commands became one of the standard ways people worked directly with a system.

The graphical user interface changed that relationship. Instead of remembering the name of a command and its options, users could choose an item from a menu, click a button, or drag an object across the screen. The computer could show what was available rather than requiring the user to know it beforehand.

That was a genuine improvement. I would not want to manage photographs, lay out a document, browse the web, or edit audio exclusively by typing commands. Graphical interfaces are excellent when the work is visual or when seeing the available choices is more useful than memorizing instructions.

What is interesting is that the graphical interface did not replace the command line in the same way that graphical word processors replaced most text-mode word processors. The two interfaces settled into different kinds of work.

A Command Is Precise

A graphical interface is usually designed around possible actions. The program presents buttons, menus, windows, and other controls, and the user chooses among them.

The command line works in the opposite direction. The user states what should happen.

That difference can make the command line less approachable because you have to know enough to formulate the instruction. A blank prompt does not offer much guidance. Someone unfamiliar with a system may have no idea what to type, while a graphical application can at least expose its major functions.

Once the commands are known, however, the same characteristic becomes an advantage. Typing a precise instruction can be faster than navigating through several levels of menus and dialogs, particularly when the operation needs to be repeated or modified.

A graphical interface tends to optimize for discovery. A command-line interface tends to optimize for expression.

Both are useful, but they solve different problems.

The Real Strength Is Combining Tools

The Unix tradition is especially important to understanding why command lines have lasted. Unix systems developed around the idea that small programs could perform particular jobs and be combined to accomplish more complicated tasks.

A program might produce text. Another program could search that text. Another could sort it, count it, transform it, or write the results somewhere else. The shell provided a way to connect those programs.

This is where the command line becomes more than a collection of old utilities.

Suppose I have hundreds of log files and want to find every line containing a particular error, extract a portion of each matching line, sort the results, and count how often each result appears. A graphical log viewer might provide exactly the right feature, or it might not. At a shell prompt, existing tools can often be joined together to perform the job without anyone first designing a special interface for it.

The individual tools may be simple. Their usefulness comes from being composable.

Text Is a Very Good Interface Between Programs

The longevity of the command line is closely connected to the longevity of plain text.

Many command-line tools accept text as input and produce text as output. That makes it relatively easy for one program to use the output of another without needing a complicated integration layer.

This is hardly the only way modern software communicates. Structured formats such as JSON and XML, databases, APIs, sockets, and many other mechanisms are essential. Still, text remains remarkably useful because both computers and people can usually inspect it.

If a command produces a list of filenames, process information, network addresses, or error messages, I can read it directly. I can also pass it to another tool, redirect it to a file, search it, or process it with a script.

There is very little ceremony involved.

Graphical interfaces generally do not work that way. The result displayed in one window is often intended primarily for a human being. Moving the same information automatically into another program may require an export function, an API, or software specifically written to connect the two.

The shell was built around that kind of connection from the beginning.

Repetition Favors the Command Line

One of the clearest advantages appears when a task has to be performed more than once.

Renaming one file is easy in a graphical file manager. Renaming five thousand files according to a particular rule is a different problem. Changing one configuration setting manually may be reasonable. Changing it across hundreds of systems is not.

A command that works once can often become part of a script. The script can then be run again tomorrow, scheduled to run automatically, stored in version control, copied to another machine, or modified when the requirements change.

That repeatability matters because the computer is doing exactly what computers are supposed to be good at: repeating instructions without becoming bored.

A sequence of mouse clicks is usually temporary. Unless the application provides macros or some other automation system, the procedure exists mainly in the user’s memory. A command can be recorded as text.

That turns an interaction into something closer to documentation.

The Command Line Works Very Well at a Distance

Another reason the command line survived is that computers stopped being something we only used while sitting directly in front of them.

Servers may be across the room, across the country, or on another continent. A text terminal works extremely well over a network because it requires relatively little bandwidth and does not depend on transmitting an entire graphical desktop.

SSH is an obvious example. Connect to a remote Unix or Linux system and you can administer it through essentially the same shell environment you would use locally. The remote machine does not need a monitor attached, much less a complete graphical desktop.

This fits modern computing surprisingly well. Cloud servers, virtual machines, containers, network appliances, and small embedded systems often have little reason to run a graphical environment at all. A machine may spend its entire useful life without anyone physically sitting in front of it.

The text terminal originated in a very different computing world, but the basic idea turned out to work extremely well in a networked one.

Graphical Interfaces Change More Often

There is also a certain stability to command-line tools that graphical interfaces often lack.

Graphical software is redesigned regularly. Buttons move. Menus are reorganized. Preferences migrate to new locations. Interfaces are simplified, expanded, flattened, rounded, hidden behind new icons, and sometimes redesigned largely because an old interface looks old.

Commands can change too, and anyone who has dealt with deprecated options or incompatible versions knows that command-line interfaces are not immune to churn. Still, mature command-line tools often preserve their basic behavior for a very long time because scripts depend on it.

That creates pressure for compatibility.

Moving a button from the left side of a window to the right may inconvenience users for a week. Changing the meaning of a command-line option may break ten thousand unattended scripts at three in the morning.

Software developers tend to become cautious when that is the alternative.

Automation Keeps Pulling Us Back to Text

Modern computing has also created new reasons to use text-based interfaces.

Infrastructure increasingly gets described in configuration files. Developers work with source-control systems, build tools, package managers, containers, cloud platforms, and deployment systems that all lend themselves to scripted operation. Even products with elaborate graphical dashboards frequently provide command-line tools because administrators eventually need automation.

The fashionable terminology changes. We have talked about scripting, configuration management, DevOps, infrastructure as code, and various forms of automation. Underneath much of it is an old idea: write down instructions in a form the computer can execute repeatedly.

A graphical interface is usually designed for one person performing an operation now. A script is designed for the system to perform an operation whenever it is needed.

As computing systems have become larger and more distributed, that distinction has become more important rather than less.

The Command Line Exposes the Machine

There is another quality I appreciate, although it can also be a disadvantage: command-line tools often expose more of what the system is actually doing.

Directories look like directories. Processes have identifiers. Network interfaces have names. Files have permissions. Programs accept arguments and return errors. The interface may not be friendly, but it tends to be fairly direct.

This connects to something I find increasingly interesting about modern software. Interfaces often try to hide structure from the user. That makes routine tasks easier, but it can also make troubleshooting harder because the abstraction conceals the very information needed to understand the problem.

The command line usually assumes that if you are asking about the details, you actually want to see the details.

That is useful in administration and troubleshooting, where an interface that tries too hard to protect the user from complexity can become an obstacle. Sometimes I do not want the computer to simplify the answer. I want it to tell me what is happening.

None of This Makes the GUI a Mistake

There is a tendency among some technically experienced users to treat command-line skill as evidence of seriousness, as though using a mouse somehow indicates insufficient dedication to computing. I have never found that attitude particularly useful.

Different interfaces are good at different things.

A spreadsheet is usually better for exploring tabular information interactively. A graphical file manager is convenient for browsing directories and moving a handful of files. Image editing is fundamentally visual. Web browsers would be considerably less useful if every page had to be described through typed commands.

The command line also has real weaknesses. Commands can be cryptic. Options are sometimes inconsistent. Documentation ranges from excellent to incomprehensible. A mistyped command can have consequences far greater than clicking the wrong toolbar button, particularly when working with administrator privileges.

There is nothing inherently virtuous about making a task harder.

The interesting question is not whether text interfaces are better than graphical ones. It is why text interfaces remain useful despite decades of alternatives.

It Rewards Knowledge

Graphical interfaces tend to make the first few minutes with a program easier. Command-line interfaces often make the next several years more efficient.

The difference is partly an investment in knowledge. Learning that a button performs an action is useful within one program. Learning a shell command or a common text-processing tool may be useful across thousands of systems.

That knowledge also accumulates. A small set of familiar commands gradually becomes a larger vocabulary, and those commands can be combined in ways that were not necessarily anticipated by the people who wrote them.

This is one reason experienced command-line users can sometimes perform complicated tasks with what looks like very little effort. They are not using a magically superior interface. They have accumulated a language for telling the computer what to do.

Like any language, it becomes more useful with familiarity.

An Interface That Found Its Place

The command line survived because it stopped having to be the interface for everything.

Once graphical desktops became common, nobody needed to pretend that typing commands was the best way to perform every task. The command line could remain where its strengths mattered: administration, programming, automation, remote access, text processing, diagnostics, and tasks that benefit from precise, repeatable instructions.

That may be the real explanation for its strange longevity. It was not preserved merely because Unix people are stubborn or because old habits refuse to die. It survived repeated generations of interface design because newer interfaces did not eliminate the problems it solves well.

Computing is full of technologies that disappeared once something clearly better replaced them. The command line has had no shortage of supposed replacements, yet the prompt remains.

After all these years, typing an instruction and having the computer execute exactly that instruction is still a useful idea.

7 Tips to Optimize Linux systemd Boot Time

Sun, 18 Oct 2026 08:34:37 +0000

The post 7 Tips to Optimize Linux systemd Boot Time first appeared on Tecmint: Linux Howtos, Tutorials & Guides .

A Linux server that takes a minute to boot may be spending much of that time waiting for one or

The post 7 Tips to Optimize Linux systemd Boot Time first appeared on Tecmint: Linux Howtos, Tutorials & Guides.

Prioritizing 'fasd' directories in bash, sh, and zsh shells (e.g., pinned and project directories)