The start page simply froze Epiphany solid. Afterwards, the journal held a core dump of the web process, and systemd had logged a memory peak of 5.8 GB. For a news site with a handful of cards, that’s a bit much in my opinion. Restarting didn’t help either: Epiphany dutifully restores the PlanetFOSS tab and promptly chokes on it again.

Following the trail

A look at the package history gave the first clue: on October 7, Arch Linux had updated WebKitGTK, the browser engine behind Epiphany, to version 2.54. The browser itself was quickly off the hook. MiniBrowser, a bare-bones test browser that ships with WebKitGTK, ballooned to several gigabytes within seconds on the PlanetFOSS start page. A plain example page, on the other hand, gets by with 170 MB.

The trail leads to the star

An AI gave me a hand with the debugging, but narrowing things down was good old process of elimination. Without JavaScript, the page still hung. Without the stylesheet, it ran just fine. After that, one style rule after another got the boot until the culprit was clear: backdrop-filter. It blurs the background behind an element and creates the popular frosted-glass look.

PlanetFOSS uses the effect in several places, but mostly on the small bookmark stars in the top left corner of every article card. The start page has 55 of them, plus eight news cards and ten play icons on the videos. Each of these elements gets its own frosted-glass layer. In those numbers, WebKitGTK 2.54 apparently buckles. Tiny star, massive impact.

To double-check, I built a test page full of cards, each with one small frosted-glass element. With ten to 14 cards, memory stayed in the green. With 18 cards, around one gigabyte was already taken, and from 22 cards on, usage shot up to seven or eight gigabytes. So things tip over somewhere around 20 layers, although the exact limit is hard to pin down.

The interesting part: the blur itself isn’t to blame at all. Frosted glass without any blur, or a simple grayscale filter, bloats WebKitGTK just the same. So the problem lies in how the new version manages these layers. Turning off the engine’s hardware acceleration does keep the test page lean. That’s no fix, though, since I can hardly tell my visitors how to launch their browser.

Firefox and Chrome couldn’t care less

That leaves the question of whether only WebKitGTK is affected. So I loaded the same copy of the start page in different browsers, once with the old and once with the new design, and measured memory usage each time. I did this on my Arch notebook and in a virtual machine running Ubuntu 26.04. Images and text were identical in every run.

The result is clear. Firefox and Chrome show practically the same usage before and after. Even Ubuntu’s older WebKitGTK 2.52 stays perfectly calm at around 680 MB. Only version 2.54 explodes: on my notebook, memory usage climbed to 9.8 GB in 40 seconds. After reworking the page, it was a mere 300 MB.

In the VM, Epiphany ran as a Flatpak, which brings the new engine along. There, the browser ballooned to 4.3 GB within a minute, until only 300 MB of the roughly 5 GB of RAM were left. In an earlier run, the tab threw in the towel entirely: Oops! Something went wrong while displaying this page. With the new design, it stayed at 721 MB.

Opaque background instead of frosted glass

The fix on the PlanetFOSS side is unspectacular. Stars, news cards, and play icons now do without frosted glass, and their background is simply a little less transparent instead. You’ll really only notice the difference if you put both versions side by side and look very closely. For a few gigabytes less memory hunger, that’s more than a fair trade in my opinion.

The change has been live for a few days, and MiniBrowser once again gets by with 213 MB on the real start page. I kept the frosted-glass effect in the pop-out section bar and on the source links in the lead story. That’s only a handful of layers, and they don’t throw WebKit off balance. linuxundich.de also uses the effect in just two places and was never affected.

All in all, the problem clearly lies in WebKitGTK 2.54 and not in my stylesheet. Presumably every page that uses enough elements with backdrop-filter is affected. So my advice to everyone who builds websites: go easy on the frosted glass and load your site in Epiphany every now and then. I’ve filed a bug report with a test case in the WebKit Bugzilla. Hopefully I didn’t kill anyone’s browser session.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

The holes are plugged in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For PHP 8.1 and older there are no regular releases with the fix so far, so the only way out is moving to a supported branch. On a regular server, the package manager takes care of that. Docker is a different story: every container brings its own PHP, and that PHP stays exactly as old as the image.

Which container runs which PHP?

So the first question is: which containers on my little home server actually contain PHP? For Nextcloud or WordPress that’s obvious, for self-built images or small web apps less so. Instead of going through every container by hand, the following loop asks all running containers for their PHP version and compares it with the patched releases right away.

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  case "${v%.*}" in
    8.5) fix=8.5.12 ;;
    8.4) fix=8.4.27 ;;
    8.3) fix=8.3.36 ;;
    8.2) fix=8.2.35 ;;
    *)   fix=99 ;;
  esac
  if [ "$(printf '%s\n' "$fix" "$v" | sort -V | head -n1)" = "$fix" ]; then
    printf '\e[32m%-30s %-8s ok\e[0m\n' "$c" "$v"
  else
    printf '\e[31m%-30s %-8s anfällig?\e[0m\n' "$c" "$v"
  fi
done

The loop silently skips containers without PHP. For all others, the version shows up in green if it is at least at the patch level and in red if it is below. PHP 8.1, 7.x and older also end up in red, because there simply is no fix for them. The red lines say “anfällig?”, German for “vulnerable?”. On my server, the result looks like this:

$ ./php2shell-simple.sh
nextcloud-app-1                8.5.12   ok
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
planetfoss-web                 8.3.33   anfällig?
sisu-web                       8.4.26   anfällig?

So Nextcloud and the test WordPress had already pulled their updates, while PlanetFOSS and the site for Sisu were still lagging behind. By the way, the question mark after “vulnerable” is on purpose. The loop only compares version numbers. If an image uses the PHP package from Debian, Ubuntu or Alpine, the fix may have been backported without the number changing. In that case, only the distribution’s security advisories can tell you more.

For a closer look, there is php2shell-check by EXT IT. The MIT-licensed script is read-only and judges PHP by package versions rather than just the version number, so it also takes backported fixes into account. It looks into Docker containers, FPM pools and old processes that are still running, and on request sends a harmless request to your website. For the containers it needs root or membership in the docker group.

The project page suggests the usual one-liner with curl and sudo bash. For a script that runs with root privileges on my server, I’m not too fond of that. Better download the script together with SHA256SUMS from the releases, check it with sha256sum -c SHA256SUMS, skim through it once and then start it by hand. According to the developers, a “not vulnerable” is no guarantee, by the way:

$ sudo bash php2shell-check.sh https://eure-seite.example

On my home server I ran the script with sudo. As a member of the docker group it would see the containers without root as well, but running processes of other users and some logs would stay hidden. This is how I fetched and started it:

$ curl -fsSLO https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh
$ chmod +x php2shell-check.sh 
$ sudo ./php2shell-check.sh 

The verdict matches the loop: planetfoss-web with PHP 8.3.33 and sisu-web with PHP 8.4.26 are vulnerable, Nextcloud and the test WordPress are not. On top of that, it found a stopped container from Tuxsucht that my loop had completely missed:

PHP in docker containers
  [ OK ] container      nextcloud-app-1 (nextcloud:35-apache)
         PHP 8.5.12 (fixed from 8.5.12)
[...]
  [VULN] container      planetfoss-web (planetfoss-web:local)
         PHP 8.3.33, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
[...]
  [VULN] container      sisu-web (sisu-web:local)
         PHP 8.4.26, fixed in 8.4.27
[...]
  [WARN] container      php83 (stopped, tuxsucht-php)
         stopped, but its image ships PHP 8.3.33: it comes back vulnerable on the next start
[...]
Summary  2 vulnerable, 3 undecided, 12 warnings, 11 ok

Sure, docker ps only lists running containers, and a stopped container doesn’t accept any requests. But if someone starts it again at some point, the hole is back right away. The script is also very clear about mod_php: all five running containers serve PHP through the Apache module, and the advisory demonstrates a complete attack without login against exactly this setup.

Until you can update, the script suggests a stopgap: set session.upload_progress.enabled=0 and expose_php=0, and keep post_max_size below a quarter of memory_limit. The check from the outside, on the other hand, wasn’t much help. For the two websites, the script only reports that the headers don’t reveal a PHP version and that there is no WAF in front. That says nothing about the patch level, which the script honestly admits.

And how do you update PHP?

Don’t update anything inside the container itself, it would be gone again with the next recreate. Instead, pull the new image in the respective Compose directory and recreate the container with it. For self-built images with their own Dockerfile you need docker compose build --pull, so that Docker also fetches a fresh base image:

docker compose pull && docker compose up -d

Important: of course this only helps if the base image already contains the patched version. According to IT-Connect, the new tags initially even showed up without an image behind them, but by now generic tags such as php:8.3-apache ship the patched PHP. If your Dockerfile pins a fixed version like php:8.4.24-fpm, you have to bump it yourself. Simply run the loop again after the update. Take care of the containers that are reachable from the internet first.

The PlanetFOSS test environment shows what this looks like in practice. Its image is based on php:8.3-apache, and the Dockerfile only adds extensions such as GD and Intl. My deploy script does call docker compose up -d --build, but that doesn’t fetch a new base image, it takes the one from August out of the cache. That’s where the old PHP 8.3.33 came from. Only --pull fetches the fresh version:

$ cd /data/docker/planetfoss
$ docker compose build --pull web
$ docker compose up -d web

After a good minute the new image was ready, and the container ran PHP 8.3.36. The database in the same Compose project stays untouched, because both commands only address the web service. Afterwards the loop shows PlanetFOSS in green, and php2shell-check also reports only sisu-web as vulnerable. The old image is still lying around on disk as a leftover, by the way; docker image prune cleans it up.

$ ./php2shell-simple.sh
[...]
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
sisu-web                       8.4.26   anfällig?

All in all, PHP2Shell is a good example of how self-hosting with Docker is convenient, but the updates don’t come by themselves. heise has collected more details on the vulnerabilities. How to keep containers up to date without a lot of fiddling, I covered in Keeping Docker containers up to date with Dockcheck. How do you keep your containers up to date?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

That’s exactly what PlanetFOSS is for. The site has been running in a trial phase for a few days, and starting today I’d like to launch it officially. The idea is a planet that isn’t tied to one project but collects across topics: distributions, desktops, the kernel, self-hosting, gaming, security, politics. The sources are publishers, blogs, project sites, and video channels, in German and English, and every visitor decides which language they want to see.

A magazine, not a list

Visually, PlanetFOSS takes its cue from a modern computer magazine rather than the classic Planet list. There’s a lead story, cards with an image and a teaser, categories, and a bar with the topics of the day. The site only takes what the source sites themselves provide for previews, meaning Open Graph data or the content of the RSS feed. Every card links straight to the original article. There are no full texts.

I also put some effort into privacy. The preview images are stored as WebP on PlanetFOSS’s own server, so no visitor IP ends up on third-party servers. There are no cookies, no external scripts, and no tracking. You can still mark articles with a star as worth reading, without an account: instead of a CAPTCHA, your browser solves a small computing puzzle, and the star is only remembered locally in your browser.

Under the hood, it’s good old PHP with MySQL, no framework, on ordinary shared hosting. Every five minutes, a cron job kicks off a cycle: fetch feeds, enrich new articles, sort them, rebuild the front pages. The real work, though, isn’t the fetching but the sorting. A site with more than a hundred sources quickly turns into a wall of text when ten sites report on the same thing.

Same news, one bundle

When a new Firefox version comes out, it feels like everyone writes about it. On a regular Planet site, you’d see Firefox ten times in a row. That’s why PlanetFOSS compares every new article with all articles from other sources published in the last 48 hours. If the title contains the same topic with the same version number, say “Firefox 158” or “Ubuntu 26.10”, the articles end up in a shared bundle, even across the language barrier.

There are two more signals. If two news items link to the same primary source, such as the release notes or a press release, they very likely belong together. Run-of-the-mill targets like GitHub or Wikipedia don’t count. As a last resort, the aggregator compares the titles themselves: stop words get thrown out, and if half of the remaining words match and the titles share a topic, it’s a bundle.

The motto here: better to bundle too little than to bundle wrong. A missing “also at” hardly anyone notices, but two unrelated stories lumped together stand out right away. On the front page, bundles with two sources appear as a card with a source bar underneath. From three sources on, it becomes a story card that’s twice as wide in the grid and lists every additional report with its own headline and its own link to the original.

New topics without a dictionary

PlanetFOSS has a dictionary with terms like GNOME, Plasma, Proxmox, or Steam. It helps with the categories, which a small Naive Bayes classifier also assigns, and with version topics. The thing is, the open source world keeps coming up with new names that aren’t in any dictionary. During the first tests, I noticed ArtCraft, for example: seven articles about a new project, and the site hadn’t picked up on any of it.

Since then, PlanetFOSS looks for new names on its own. A candidate has to appear in the titles of at least three sources within the last 48 hours (four if only one language is involved), but no more than once in the four weeks before. Then there’s a little trick: a name is never written in lowercase. That filters out words like “released” or the German “Sicherheitslücke” (security hole) without endless stop word lists. Whatever is left becomes a new topic.

Comets and supernovas

Now it gets interesting. The name sets the scene: when a topic suddenly gets a flood of coverage, say on the release day of a new Ubuntu version, it becomes a supernova, a sudden, very bright outburst. A topic that’s only just picking up speed is a comet. And once the outburst is over, there’s still an afterglow for a while.

A comet appears as soon as at least three different sources write about a topic within twelve hours. Its cards get a badge, and it moves to the front of the topic bar. So that general catch-all topics like the Linux kernel don’t become permanent comets, they also need twice as many sources as usual. If a comet can’t keep up the momentum, it drops back to a normal topic.

A supernova needs more. Four sources have to report within 24 hours, almost all of them in the last twelve hours. The topic has to be broad, meaning it reaches at least two types of sources (publisher, blog, project, video) or shows up in both languages. On top of that, it needs at least three times as many sources as its average over the last four weeks. Otherwise, every week with some Ubuntu news would be a supernova.

PlanetFOSS knows some things in advance. A release calendar holds the known dates for Ubuntu, GNOME, KDE Plasma, Fedora, Debian, the kernel, and Firefox. If a topic falls within that window, one source fewer is enough to ignite. At the same time, no more than two supernovas may burn at once, so the front page doesn’t drown in nonstop fireworks. If there are more candidates, the strongest ignite and the rest stay comets for the time being.

A supernova burns for at least twelve hours. After that, it cools down once nothing new arrives for six hours or the number of sources drops below half of its peak. If a second wave comes along, such as the first reviews a few days after a release, it can ignite again. After 72 hours, the topic goes to the archive, but its topic page stays online and keeps collecting later posts.

How the front page comes together

When a supernova is burning, it gets its own band at the very top above the lead story, showing the number of posts and sources and a row of cards, sorted by official announcements, news, reviews, how-tos, and videos. Whatever is in that band doesn’t show up again further down. On top of that, PlanetFOSS sends a post to the @planetfoss account on Mastodon half an hour after a supernova ignites.

For everything else, the site hands out points. The score takes into account the size of the bundle, the stars from visitors, an active supernova topic, and the weight of the source. All of that is divided by the age of the article, so older posts gradually slide down. Stories that many sources cover stay up longer, but not forever.

For the lead story, importance beats freshness, but the candidates come from the last 24 hours and preferably bring a large image. The age of a bundle is the age of its second-newest report: if more sources keep writing, it stays up front, but a single latecomer isn’t enough. If a post has already been the lead for more than eight hours, it loses half of its points, and after 14 hours three quarters.

To keep one busy source from filling the whole page, the selection also looks for variety. In the lead story and the top stories next to it, every post comes from a different source, and the “Latest” section shows at most two articles from the same site. That way, smaller blogs get their spot next to the big publishers, and the front page looks a little different every time you visit.

Statistics instead of AI

By the way, there’s no AI in PlanetFOSS that summarizes texts or guesses topics. Everything runs on counting, comparing, and a handful of thresholds. In my opinion, that’s actually the better way: it costs nothing, sends no data anywhere, and stays traceable. When a supernova ignites, you can say exactly why. That said, I did build the site myself with AI assistance.

Of course, it didn’t work without some fine-tuning. Early on, for example, a supernova ignited for Microsoft Defender, even though the four news items were spread over 18 hours. Since then, an outburst has to be genuinely fresh. Ubuntu 26.10 also ignited two hours late on its release day at first, because it was measured against all Ubuntu news. That’s why version topics now get their own baseline.

I keep an eye on cases like these, and for that the site saves a snapshot of topics, bundles, and lead stories every six hours. So the logic will surely keep changing. A wrong bundle or a comet that shouldn’t be one can be corrected by hand in the admin area. The algorithm dutifully respects those corrections on its next run.

Just head over to planetfoss.net and tell me what you think. Which sources are you still missing, and which blogs, magazines, or other publications from the German- or English-speaking Linux and open source world absolutely belong on the planet? I’m happy to take suggestions in the comments. And if you run a blog yourself and would rather not be included, the site of course also offers a way to opt out.

Update: Why the stars on PlanetFOSS no longer use frosted glass, and what that has to do with a memory leak in WebKitGTK, is covered in WebKitGTK 2.54: Tiny Star, Massive Memory Leak.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Why Sonos S1 still needs SMB1

I still have two Play:3, a Play:1, and a Connect:Amp on my network. All of them run the S1 software, for which Sonos only ships bug fixes these days. The speakers don’t just play streams, they also play my music collection from the server. According to a discussion in the Sonos forum, however, the S1 devices only have enough resources for SMBv1 – the old hardware simply can’t do more.

Samba, on the other hand, retired the old protocol a long time ago. Since version 4.11, server min protocol defaults to SMB2_02, and according to the Samba project, NTLMv1 authentication has been disabled since version 4.5. The usual guides turn both back on globally with two lines. Sure, the speakers play after that, but they’re not the only ones who get the door held open for them.

If you run an S2 system, you’re off the hook. Sonos added SMBv2 and SMBv3 there with version 13.4.1 in December 2021 and no longer speaks SMBv1 at all. S2 users can leave Samba’s defaults alone. The rest of this article is for everyone who, like me, is still attached to their old speakers and doesn’t want to throw them out over a protocol.

What’s wrong with the quick fix

Samba can only allow SMB1 for the whole server, not for individual shares or devices. Ever since WannaCry exploited a hole in Microsoft’s SMB1 in 2017 at the latest, the protocol has been considered legacy baggage, and NTLMv1 makes it easy for attackers to crack captured logins. If the speaker then logs in with your regular user on top of that, it’s your main password of all things that travels across the network using the weakest method available.

On top of that come lines that people like to copy along while they’re at it. With wide links and allow insecure wide links, Samba follows symlinks even when they point outside the share. Often the entire data directory is shared writable, too. Sure, from the outside a little home server like this is usually locked down. But the same LAN is also home to TVs, smart plugs, and speakers whose software you have no control over.

A dedicated user just for Sonos

The most important step is a dedicated user that exists only for the speakers and isn’t allowed to do anything else. It needs neither a home directory nor a shell; Samba only knows it for logging in. You set the password once and don’t use it anywhere else, because with NTLMv1 you should consider it semi-public. Creating it from scratch takes two commands:

$ sudo useradd -r -M -s /usr/bin/nologin sonos
$ sudo smbpasswd -a sonos

If you already have a user the speakers log in with, trim it down with usermod. It loses its shell and gets / as its home directory and a locked Unix password. Logging in to Samba uses the separate password from smbpasswd and keeps working regardless. If your speakers have been using your regular user so far, however, you’re better off creating a new one:

$ sudo usermod -s /usr/bin/nologin -d / sonos
$ sudo passwd -l sonos

The smb.conf

The configuration allows SMB1 and NTLMv1 but fences in everything around it. Samba only listens on the LAN interface and not on Docker bridges or VPN tunnels. Guests are kicked out, there are no printers, and every share gets a list of users who are allowed in. You’ll of course have to adapt the name of the network interface (enp0s25 on my machine) and the paths to your system:

[global]
   workgroup = WORKGROUP
   server string = bender
   server role = standalone server

   # Sonos S1: nur SMB1 + NTLMv1
   server min protocol = NT1
   server max protocol = SMB3
   ntlm auth = ntlmv1-permitted

   # nur LAN und lokal, nicht auf den Docker-Bridges
   interfaces = lo enp0s25
   bind interfaces only = yes

   map to guest = never

   # keine Drucker
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

[homes]
   browseable = no
   writable = yes
   valid users = %S
   invalid users = sonos

[musik]
   path = /data/musik
   browseable = yes
   read only = yes
   valid users = sonos anna ben lena

[data]
   path = /data
   writable = yes
   valid users = anna ben

By the way, ntlmv1-permitted is just the more descriptive name for the old yes. The [musik] share (German for music) is read-only; sonos and the family, here anna, ben, and lena, are allowed to read it. Even if someone cracks the speaker’s login, all they get is the music. Only anna and ben can access [data], wide links doesn’t appear anywhere, and symlinks therefore stay within their share.

The line invalid users = sonos under [homes] matters, too. This share offers every user their home directory, and for the speaker user that’s the root directory after the usermod above. Without that line, there would be a writable share \\bender\sonos covering the entire system. What actually works there is still governed by file permissions, but directories like /tmp are open to everyone.

If you can’t set up the Sonos library from scratch right now, there’s also an intermediate step without a separate music share. In that case, add sonos to the valid users of the existing share and also set read list = sonos. The speaker can then still read everything the file permissions allow, but can’t write anything. In the long run, though, a separate share is clearly the better choice.

Before you activate the new file, have testparm check it. It complains about typos and unknown options before Samba trips over them. Then restart the service – on Arch it’s called smb, on Debian and Ubuntu smbd. Open connections drop briefly, but mounted shares on your computers usually reconnect on their own:

$ sudo testparm -s
$ sudo systemctl restart smb

The music library in the Sonos app

Finally, add the share as a music library in the S1 app. Open Settings and go to Music Library and Music Library Setup. Enter the share in Windows format as the path, i.e. \\bender\musik, followed by the user sonos and its password. Sonos then indexes the collection, which can take a while for large libraries.

Checking the result

smbstatus shows you whether everything works as intended. The Protocol Version column tells you who is connected with which protocol. Regular computers should keep connecting via SMB3 – my notebook, for example, uses SMB3_11 – and only the speakers show up with NT1. A guest login without a password, on the other hand, should bounce off with NT_STATUS_ACCESS_DENIED when you try it with smbclient from another computer:

$ sudo smbstatus -b
$ smbclient -N //bender/data -c ls

Don’t let the output of the second command mislead you. The line “Anonymous login successful” sounds like an open door, but it only concerns the connection to the server itself, which a client uses to fetch the list of shares, for example. The second line is what counts, because nobody gets into the share itself without a user name and password:

$ smbclient -N //bender/data -c ls
Anonymous login successful
tree connect failed: NT_STATUS_ACCESS_DENIED

On my server it looks like this: The speaker in the bedroom reads as sonos via NT1, while the notebook is connected with SMB3_11 and a signed connection. That’s exactly how it should be, because the old protocol stays limited to the devices that can’t do anything else. The other speakers only show up while they’re actually accessing the library:

$ sudo smbstatus -b

Samba version 4.25.0
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing              
----------------------------------------------------------------------------------------------------------------------------------------
732192  sonos        sonos        192.168.0.60 (ipv4:192.168.0.60:38427)    NT1               -                    -                    
711090  anna         anna         192.168.0.191 (ipv4:192.168.0.191:52826)  SMB3_11           -                    partial(AES-128-CMAC)

And in the long run?

Of course, I’m still not entirely happy with SMB1. My server already runs bonob, which brings Navidrome into the Sonos app as a music service. If the music comes through that, no speaker needs a Samba share anymore, and SMB1 could go for good. But if you can’t do without Sonos’s built-in library, the restricted setup is a good compromise in my view.

All in all, the clean approach only costs you one user and a few extra lines in smb.conf. The speakers play just as well as with the quick fix, except that they no longer offer a path to the rest of the server. How did you hook up your old Sonos speakers? Is SMB1 still running on your network, too, or did you switch to S2 long ago?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Then again: If you open the announcement, you may well get nothing but an error message. DoSed? More like MS-DOSed! Of all things, the blog for a product that’s supposed to detect and fend off attacks is pretty much down and loads at a snail’s pace. Whether someone helped it along or too many Linux users just wanted to see it with their own eyes, I don’t know. Either way, a Defender for its own web server would be a good start.

And I had committed myself so firmly. When Sophos released a free virus scanner for Linux (in German) back in 2015, I cheekily wrote that you’re allowed to do online banking without a virus scanner. A few months later, in my article on AVG’s privacy policy (in German), I used the words snake oil. Eleven years later, I guess I owe the industry an apology. After all, Microsoft has spoken.

Microsoft discovers the Linux desktop

The real bombshell sits in the very first sentence of the announcement: “As more developers begin to use Linux desktops”. So Microsoft itself confirms that more and more people run Linux on the desktop. We Linux users have been cracking jokes about the Year of the Linux Desktop for decades. Now it’s proclaimed by none other than the company from Redmond. I never thought I’d read that confirmation in a press release for security software.

If you’ve been reading along for a while, you know the backstory. In 2009, Microsoft had to confess to the US Securities and Exchange Commission that Linux is officially a competitor (in German). In 2014, Microsoft then declared that as a server system, Linux “falls short” (in German). Today the company sells protection software for Linux servers and Linux desktops. So Gandhi was right, he just forgot the last stage: First they laugh at you, then they fight you, then they sell you a virus scanner.

What Defender can do on the Linux desktop

Technically, by the way, this isn’t new software at all. Microsoft uses the same agent it has been offering for Linux servers for a few years now. Defender figures out on its own whether it’s running on a server or a workstation. That’s real progress: In 2014, the Microsoft homepage still sold my Linux as Windows 8.1 (in German). Today Redmond can at least tell a server from a desktop.

On board are a “next-gen” virus scanner, endpoint detection and response (EDR), vulnerability management, and a device inventory. For emergencies, there’s Live Response and Device Isolation. In other words: Corporate IT gets a shell on your machine and can cut it off the network with a mouse click. Back in the day, we’d have called that a remote access trojan and hunted it down with ClamAV. Today it’s called enterprise-grade protection and comes with a license agreement.

Supported are RHEL, CentOS, Ubuntu, Debian, SLES, Fedora, and Oracle Linux, running Gnome, KDE, or any other desktop. That a security product of all things lists CentOS, which hasn’t received updates since 2024, has a certain charm. Arch Linux, on the other hand, is missing from the list. So sadly I remain unprotected – I use Arch, btw. And, to be perfectly honest, I’m a little relieved.

Who is this actually for?

You won’t find Defender as a package in your software center, and it’s certainly not free. You need Microsoft Defender for Endpoint Plan 2 or a Microsoft 365 E5 or E7 license. A Phoronix reader asked in the forum if someone could please translate these marketing terms into plain language. Happy to help: It’s not meant for your average Joe’s Linux. And anyway, it’s still in public preview.

All joking aside: Microsoft does have a point. Developer machines are hooked up to Git repos, CI/CD pipelines, and cloud accounts, and whoever breaks in there gets a grip on the entire supply chain. The real target audience, though, is compliance departments. They finally have a checkbox that lets them allow Linux notebooks in the company. Whether you’ll still be allowed to use sudo is another story. Microsoft already patented sudo back in 2009 (in German), after all.

The best summary came from a reader in the Phoronix forum: “Number of viruses on Linux: 1”. In my opinion, that hits the nail on the head. If you use Linux privately, install software from your distro’s repositories, and don’t blindly run every script from the internet with root privileges, you still don’t need a virus scanner. A Defender whose main job on Linux is hunting Windows malware won’t change that.

There’s just one punchline I can’t resist at the end. The German state of Schleswig-Holstein wants to throw Windows and Microsoft Office (in German) out of its administration and schools by the end of 2026. Right on the home stretch, Microsoft shows up at the door with the matching Defender for the new Linux machines. Who says Redmond isn’t flexible? What do you think: genuine care, telemetry, or just good business?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Updated October 15, 2026

I brought this article from 2014 up to date: the links to Intel and Logitech point to the official sources again, a step-by-step guide sums up the fixes, and the charts have been redrawn. The problem itself hasn’t changed, USB 3.0 still interferes with 2.4 GHz wireless today.

I have to admit: I’m a fan of wireless mice. Sure, ordinary rechargeable batteries drain far too quickly, but Eneloop batteries take care of that nicely. Mousing around without a cable is simply more comfortable. When I switched to a new computer and installed Arch Linux, though, my previously flawless Logitech wireless mouse drove me to despair.

Where I used to move the cursor across the screen with precision, after the switch it just jerked and stuttered along miserably. The cause wasn’t the system, as I first suspected. The culprit is USB 3.0: the fast ports get in the way of wireless keyboards and mice. By the way, this isn’t a Linux problem, the mouse stutters on Windows just the same.

Tracking down the cause cost me quite a few nerves over several weeks. I suspected the new computer, combed through Arch Linux forums for problems with USB mice and tried the mouse’s dongle in every port on the machine. No matter what I did, the mouse simply refused to work as precisely as I was used to from Logitech.

Not even the USB port of the monitor right next to the computer helped. The mouse itself, a Logitech Anywhere MX, wasn’t to blame either: it worked flawlessly on other computers. In other words, I had tried all the obvious tips, and nothing helped. In the end, it was pure chance that put me on the right track.

When your wireless mouse jumps all over the screen

I stumbled on the solution while rearranging my desk. My second monitor has USB ports as well, and lo and behold: with the Logitech dongle plugged into that monitor, about a meter away from the computer as the crow flies, the mouse works as usual again. No more lag, no dropouts, no twitching. So simple that it’s almost annoying I didn’t think of it right away.

You’ll find the explanation if you add “USB 3.0” to your search for a “choppy mouse” or “mouse lag”. Because that’s where the problem lies: USB 3.0 ports and cables radiate broadband noise into their surroundings that also covers the 2.4 GHz band. That’s exactly where the receivers of mice and keyboards operate, and they simply can’t compete with the noise anymore.

Intel has known about it since 2012

Intel has known about the problem for a long time. In the white paper USB 3.0* Radio Frequency Interference Impact on 2.4 GHz Wireless Devices from April 2012, the chipmaker describes over 22 pages how plugs, sockets and cables of USB 3.0 devices interfere with wireless signals in the 2.4 GHz band. The noise sits right in the middle of the band, so a filter won’t help. It lowers the signal-to-noise ratio and with it the sensitivity and range of the receivers.

Intel advises manufacturers to shield USB 3.0 hardware better. What’s left for you is the practical advice: don’t plug the wireless receivers of your keyboard and mouse into a USB 3.0 port, use a classic USB 2.0 port instead. You can usually spot USB 3.0 ports by their blue insert or the SS logo for SuperSpeed, USB 2.0 by the white or black plastic tab. The small receivers don’t benefit from the higher speed anyway.

Logitech also recommends more distance

Logitech hasn’t missed the problem either, USB 3.0 isn’t exactly new, after all. On the support page Wireless product not working properly when also using a USB 3.0 device, the company lists the typical symptoms: mouse and keyboard respond with a delay, keystrokes or mouse clicks get lost, and the range between device and receiver shrinks noticeably.

Logitech recommends plugging the receiver in as far away from USB 3.0 ports and devices as possible, for example on the opposite side of the computer, and bringing it as close to the mouse or keyboard as you can. According to the support page, Logitech even provides affected customers with a USB extension cable. You have to request it from support, though the page doesn’t say whether any conditions apply.

How to get rid of the lag

In the end, it all comes down to a few simple steps. Ideally, try them in this order:

1. Move the receiver: Plug the dongle into a USB 2.0 port, as far away from USB 3.0 sockets as possible. Watch out for front ports: on newer cases, those are often USB 3.0 as well.
2. Use an extension cable: A simple USB extension cable gets the receiver out of the interference zone and puts it right next to your mouse and keyboard. Whether the cable supports USB 2.0 or 3.0 doesn’t matter, the receiver only runs at USB 2.0 speed anyway.
3. Use your monitor as a hub: If your monitor has USB ports, plug the receiver in there. That’s exactly what fixed it for me.
4. Keep interference sources away: External drives, card readers, hubs and cables with USB 3.0 don’t belong right next to the receiver.
5. Ask the manufacturer: If you own a Logitech device, you can request the extension cable from Logitech support.

It’s not just wireless mice

In general, you should keep devices with 2.4 GHz radios away from USB 3.0 hardware. Besides the ports themselves, cables and electronics of card readers or external drives can also cause interference. And it’s not just wireless mice and keyboards that are affected: Bluetooth, Wi-Fi in the 2.4 GHz band and baby monitors all operate in the same range. By the way, USB 3.0 is now officially called USB 3.2 Gen 1, but the new name doesn’t change the problem.

There’s a catch with laptops that only have USB 3.0 ports or even just USB-C. A short USB-C to USB-A extension helps here, moving the receiver at least a little away from the case. If you don’t want a dongle dangling on a cable at all, go for a mouse that talks to the built-in radio via Bluetooth. Bluetooth isn’t completely immune to USB 3.0 noise either, though.

For me, moving the receiver to the monitor fixed the problem in one go back then, and the cursor has been gliding precisely across the desktop ever since. For weeks I blamed Arch Linux and the new computer, when the solution was just a meter away. Have you had similar experiences with USB 3.0, or do you have a better solution?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

The name originally stood for Kool Desktop Environment, a nod to the commercial Common Desktop Environment (CDE) on other Unix systems. Because KDE was built on Qt, whose license wasn’t really free back then, GNOME came about as the counter-project. The short version of the years that followed, according to heise (in German): the KDE e.V. association in 1997, KDE 1 in 1998, later the much-loved KDE 3, and in 2008 the rather bumpy KDE 4.

KDE 4 drove a lot of users away at the time, and some still maintain its predecessor today as the Trinity desktop. At the same time, that release brought along programs like Dolphin and Okular as well as the Plasma interface. Today the project is split into the KDE Frameworks libraries, the KDE Gear applications, and the KDE Plasma desktop. Plasma now also runs on smartphones, TVs, and the Steam Deck.

Plasma 6.8: So Long, X11

Right on time for the birthday, Plasma 6.8 is out, and this release draws a thick line: Plasma no longer starts an X11 session and runs on Wayland only. GNOME already led the way here. Older programs that still need X11 keep working through XWayland. The KDE applications themselves are supposed to keep working on X11 desktops for the time being.

Under the hood, KWin now renders through OpenGL ES only, according to 9to5Linux, with Vulkan to follow later. NVIDIA graphics get triple buffering by default, and the Plasma shell starts faster. In everyday use, Spectacle stands out: screen recordings now capture system audio and the microphone. Also new are the Kup backup tool and dwell clicking, and Steam windows finally get shadows and rounded corners.

When you get Plasma 6.8 depends, as usual, on your distribution. According to OMG! Ubuntu, rolling-release distros like Arch Linux will ship it in the next few days, while KDE neon will take a few weeks. Kubuntu 26.10 just missed the date and stays on Plasma 6.7. So there it’s a matter of waiting or hoping for a backport.

KDE: The Documentary

If you’re interested in the story behind the version numbers, set aside a good hour. The YouTube channel CultRepo made a documentary with support from KDE, which premiered at 7:30 p.m. German time (CEST). KDE: The Documentary – The Story of Free Software Underdogs runs for just over an hour.

The video is only loaded from YouTube after you click.

The documentary covers the highs and lows of three decades: the fight over the Qt license and the rivalry with GNOME, the success of KHTML, which later became WebKit and thus also Chrome, and the KDE 4 debacle. Among those interviewed are Matthias Ettrich, Lars Knoll, Aaron Seigo, Nate Graham, and – a nice touch for the GNOME camp – GNOME co-founder Miguel de Icaza.

Birthday Donations

Of course, free software doesn’t run without money either. That’s why KDE has launched a year-end fundraiser, with milestones at 50,000, 75,000, and 100,000 euros listed on the page. Among other things, the money is meant to go into accessible and energy-efficient software. If you want to support KDE in the long run, you can become a supporting member. Fittingly for its founding year, KDE raised that goal from 1,500 to 1,996 members.

KDE and Me

My own Linux journey started with window managers like Window Maker and Enlightenment E17. At some point, around the KDE 3.x days I’d guess, I ended up with KDE as well. A complete desktop with all the bells and whistles – for Linux, that was outstanding at the time. Until then, you usually had to piece together a panel, a file manager, and all the rest yourself.

That said, I never became a KDE devotee. Back when I was posting as “Chrissss” on ubuntuusers.de, the big German Ubuntu community, I was firmly on the GNOME side and regularly asked the KDE folks for help whenever a wiki article needed a KDE section. For an article about Bluetooth mice I did install KDE 4 once – and was surprised it didn’t even come with Bluetooth settings.

Still, KDE never quite let go of me. In 2009 I congratulated KDE on 4.3 (in German) here on the blog and wondered whether the developers might yet convince an old GNOME guy like me to switch. That didn’t quite work out. But I brought KDE Connect into GNOME via an extension (in German), and when I write Markdown on KDE, I do it with Kate (in German). If KDE, then all the way.

All in all, the Linux desktop would look very different today without KDE – and without the never-ending rivalry between the two, so would GNOME. In my opinion, the project did a lot to make Linux usable on ordinary computers in the first place. So: happy 30th birthday, KDE! How long have you been using KDE, and which version stuck with you the most?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

Javad joined the team in 2020 because documentation for Shell extensions was missing back then. So YouTube tutorials came first, and later, on invitation from Sriram Ramkrishna and his GNOME Extensions Rebooted project, the Port Guide for GNOME Shell 40. It helped many authors move from GTK3 to GTK4, and according to Javad, plenty of them would have given up without it.

Today all the documentation you need for your own extensions exists. Still, many people vibe-code their extensions and submit them to EGO without ever having looked at the docs. That leaves Javad with the feeling that the documentation feeds LLMs more than human developers. Since early 2025 submissions have exploded, and the vast majority are AI-generated.

For years Javad has answered questions daily and reviewed extensions, often 4 to 10 hours a day. That work is unpaid and easily matches a full-time job, while monthly donations sit close to zero. The result: Javad is close to burnout and writes that without financial support it won’t be possible to keep going at this pace. At least there was the GNOME Pants Award in 2026.

The main problem is quality. Extensions run directly inside the GNOME Shell process, so bad AI code threatens the stability of the whole desktop. According to Javad, LLMs produce needlessly complex, hard-to-read code that takes much longer to review. Some submitters even let an AI write their replies, and once the instructions meant for the model accidentally ended up in the text.

There is a bright spot, though: Javad’s open letter to AI models corrected specific code patterns the models kept getting wrong. Within a few weeks most of those mistakes were gone. Javad sees that as good news, but also as proof of how heavily the documentation feeds the models. That doesn’t solve the review problem itself.

Who Is Needed?

• Reviewers: Developers who know GTK and the GNOME Shell source code. The role is voluntary, and availability during the week should be consistent. Javad offers mentoring and will teach you the review process.
• Shexli helpers: The linter has existed for a few months and is meant to make reviews easier. Reviewers report false negatives and false positives, and whoever helps fixes them in Shexli. The team needs someone who improves the linter.
• Donors: If you want to support the work financially, there is a donation page.

If you want to join the review team or help with Shexli, get in touch on the Matrix channel #extensions:gnome.org. Javad names no deadline, but does give a reason to hurry: without more help, things can’t go on at this pace. So better sooner than later, even for a first question with no commitment.

In my eyes this is a wake-up call for everyone who uses GNOME extensions day to day. Without reviewers there are no vetted extensions, and without those, many of us would be missing a good piece of GNOME. If you have the time and the know-how, think about it seriously. Everyone else can at least throw a few euros into the donation jar.

Ahem. Me Too.

I have to admit I feel called out here myself. With Pulsgeber I wrote a GNOME Shell extension that was built with AI assistance. And yes, I have real respect for the step of submitting it to EGO. The thought that someone has to go through the resulting code line by line makes me a bit uneasy. I don’t want to dump work on anyone, least of all a team that is already running at its limit.

Still, in my eyes you shouldn’t brand every AI contribution as AI slop. Such extensions move a lot of things forward and enable features that used to be out of reach. In the end what counts is the quality of the code, not the tool it came from. The problem is unreviewed masses, not AI itself.

Behind all this lies a question for me: AI code is quickly generated, but someone still has to read and review it. That probably doesn’t only hit EGO, but every project that takes contributions from outside and checks them before release. What do you think: is the flood of AI submissions a problem on other platforms too, and how should projects deal with it?

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

So I built a client myself: Gnomos is based on GTK4 and libadwaita and is meant to feel like a perfectly normal part of GNOME. You can download the current version 0.28.5 as a Flatpak bundle on GitHub and give it a try. It has been running on my machine for quite a while, so the nastiest bugs should be sorted out by now.

What got me started were my older devices. Sonos has discontinued (in German) support for first-generation products, including the ZonePlayers ZP80, ZP90, ZP100 and ZP120 as well as the CR100 remote. The speakers themselves keep working, it is only the current Android app that no longer plays along. Gnomos talks to these old boxes directly over your home network, so you need neither a Sonos account nor a cloud service.

The communication with the speakers is handled by noson, the library behind the Noson-App. On top of it sits a user interface of its own, one that follows the current GNOME design principles instead of copying the official Sonos apps or the Noson-App that inspired it. Disclaimer up front: AI took care of the heavy lifting during development. Architecture, technical decisions and testing are still down to me, though.

Now Playing, With Lyrics

Click the playback bar at the bottom edge of the window and the current track fills the whole window. The cover appears in large size on a background in its colors. Next to it you find the upcoming tracks of the queue and, if you switch it on, synced lyrics from LRCLIB. Click a line and the song jumps to the matching spot.

If you like it nostalgic, you can let the cover spin as a vinyl record. A gimmick, sure, but a nice detail. On top of that there is a poster-style mini player: the cover fills a small, square window. The controls only fade in when you move the mouse over it. That way the music stays in view without taking up much space on your desktop.

All Rooms in One Place

The room picker in the header bar shows what is currently playing in which room. Drag one room onto another and Gnomos groups the two, one click dissolves the group again. Inside a group you set the volume per room. On top of that you can start or pause each room with a single click, without having to break up the group.

You edit the queue right in the app as well. You move or remove tracks, and a finished list can be saved as a Sonos playlist. Favorites and the Sonos alarms are on board too, and you can create, edit and duplicate the alarms. Sonos itself does not keep a playback history, so Gnomos records it locally. From each entry you can find the artist or album again later.

The Whole Music Collection

Gnomos searches the music share on your network, Sonos favorites and playlists, internet radio and the services you have linked in Sonos. Those include Spotify and, via bonob, also Navidrome or other Subsonic servers. Large libraries open quickly as a cover grid, or as a list if you prefer. A live filter helps with long lists, and you search for internet radio stations on radio-browser.info by name or country.

Part of the GNOME Desktop

Gnomos supports MPRIS2. Media keys, the lock screen and the player in Quick Settings therefore work right away, including shuffle and repeat. Optionally there is a small Shell extension that puts a volume slider for each room into Quick Settings. It is not part of the Flatpak, you install it separately, and the instructions are in the repository. After that you control your rooms without opening the app at all.

There is also a dark mode, desktop notifications on track changes and keyboard shortcuts for playback, volume, search and the current track. On the speakers themselves you adjust bass, treble, loudness, night mode and subwoofer. A dialog for each room shows the model, IP and MAC address as well as the software version, handy when you have several devices on the network. First-generation devices get a badge of their own in the app.

A short video shows how it all works together. In it I use Gnomos and walk through the most important features.

Gnomos does not leave your home network for the actual control. The app only queries two things online: lyrics from LRCLIB and artist photos through the public Deezer API. Both are switched off by default, and you decide in the settings whether you want to use them. Everything else stays in your own network, no data goes to third parties, not even secretly.

Installation

So far Gnomos is only available as a Flatpak bundle. My plan is to get the app onto Flathub, but for that it needs a few more testers first. Until then you download gnomos-<Version>-x86_64.flatpak from the releases page and install the file with this command:

flatpak install --user gnomos-*.flatpak

If the GNOME 51 runtime is missing, Flatpak fetches it from Flathub. Bundles do not update themselves, so check the releases page for new versions now and then, because Gnomos gets regular fixes and new features. You find the build instructions, the translations (German and English are included) and the source code in the GitHub repository. Gnomos is licensed under the GPL-3.0.

Not Finished Yet

So far I only test Gnomos with my own Sonos household of first-generation devices. I cannot check other models, newer generations and unusual setups, so feedback is worth its weight in gold. Gnomos is still short of version 1.0, and there are surely a few rough edges left. You find more about the project on the project page (in German).

For me, though, Gnomos has long been good enough that I use it every day. Do you have Sonos speakers and a GNOME desktop? Then give the app a try and tell me in the comments what works for you and what does not, preferably with hardware other than mine. You can also report bugs and ideas as an issue on GitHub.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.

I signed up there in May 2014, and DDNSS has been with me ever since. In 2016, I recommended the service myself in the comments (in German) as a provider “without the nagging.” Now there is an email from Robert in my inbox that I really didn’t see coming. After more than 13 years in operation, DDNSS.de is facing a change: Robert is currently in talks about a possible takeover of the service.

A takeover, not a shutdown

That doesn’t mean the end is sealed, though. A decision is due by October 31, 2026 at the latest, with the handover settled by then – provided the talks lead somewhere. If the takeover goes through, the new operator will simply keep DDNSS running. If the talks fall through, Robert wants to let everyone know in good time so you can prepare for a switch without any rush.

So if you have DDNSS set up in your FRITZ!Box or on your own little server, you don’t need to do anything for now. Your existing DynDNS entries keep working unchanged for the time being, and according to Robert there is no immediate need to act. He answers questions at webmaster@ddnss.de. Still, it can’t hurt to check everywhere you have DDNSS set up – in the router, in ddclient or in some script.

Thank you, Robert

Robert isn’t taking this step lightly. By his own account, he has put a lot of time and work into DDNSS.de since May 2013 – there was never a business model behind it, and anyone who wanted to could donate. After more than 13 years, a decision like this is anything but easy for him personally. That’s why he is looking for a solution that will last instead of simply pulling the plug.

I’d like to take this opportunity to thank Robert very much. To me, keeping a free service like this running for so many years is not something to take for granted. With DynDNS, you usually only notice what you had once it suddenly stops working. I hope Robert finds a good new home for his baby.

These days, I treat myself to a “proper” domain for my self-hosting projects. With my web host, that’s pretty easy: the FRITZ!Box updates the records of my own domain directly via DynDNS, so I no longer need an external service for it. If you own a domain anyway, check whether your host offers something like this.

☕ Support Linux und Ich
Thanks for reading Linux und Ich. If you enjoy the blog and would like to support my work, you will find more information on the donation page.