llmfit takes this research off your hands. The open-source tool reads out your hardware and compares it against a database of language models. What you get is a pretty concrete answer to what can actually run sensibly on your own machine.

Which models fit my hardware?

After launching, llmfit first detects your hardware: CPU, RAM, graphics card and available VRAM. It then compares those resources against the models it supports and sorts the list by a score.

This is useful mainly because raw model size isn’t the only thing that counts. A model can theoretically fit into the available memory and still run painfully slowly in practice. So llmfit estimates how well a model suits your hardware and what speed and memory requirements you can expect.

Just how much this differs from machine to machine shows up with two devices from my stash. On the laptop with a dedicated GTX 1050, the 4 GB of VRAM is a hard limit. On a computer with Iris Xe graphics, on the other hand, the CPU and the GPU share the same memory, and suddenly almost everything says “Perfect”.

The program also takes different quantizations into account. With locally run models, you quickly run into terms like Q4, Q5 or Q8. Put simply, this reduces the precision of the model weights to save memory and computing power. Depending on the level, you have to accept some loss in quality in return.

This matters most for GGUF models, which are commonly used for local inference. llmfit factors the different quantization levels into its rating, so it can also compare models that come in several variants.

If you’ve been using tools like Inxi on Linux to get an overview of your hardware, you already know the principle. llmfit goes one step further, though, and puts the collected data directly in relation to possible AI models.

Installation on Arch Linux

Update September 29, 2026: The wheel of time keeps turning, and on Arch it famously turns a little faster. When I started writing this article, llmfit was only available for Arch as an AUR package. Because of the turbulence and attacks on the AUR, I try to avoid it these days. In the meantime, the llmfit package has made it into the official Arch repositories, so all you need to install it is: sudo pacman -S llmfit

On Arch Linux, uv is available directly from the official repositories. That makes the installation pleasantly unspectacular:

sudo pacman -S uv

After that, you can install llmfit as a tool with uv:

uv tool install -U llmfit

Now llmfit is available right away as a command.

If you just want to try the program first, you can use uvx instead. That runs llmfit without installing it permanently as a tool:

uvx llmfit

So on Arch Linux, you don’t need a separate installer for uv.

Installation on Ubuntu

On Ubuntu, the route is a bit different. Depending on your Ubuntu version and the repositories you use, you can’t simply install uv with apt. The installer provided by the uv developers is therefore a straightforward option.

With curl it works like this:

curl -LsSf https://astral.sh/uv/install.sh | sh

Alternatively, you can download and run the installation script with wget:

wget -qO- https://astral.sh/uv/install.sh | sh

After that, first check whether uv is available:

uv --version

From here on, installing llmfit works exactly like on Arch Linux:

uv tool install -U llmfit

If you just want to try it out without a permanent installation, uvx is available on Ubuntu as well:

uvx llmfit

If you’d rather not use uv, you can download the prebuilt binaries from the llmfit GitHub Releases instead.

Getting rid of llmfit again

If the tool doesn’t convince you after all, the way back is short, but on Arch there’s a catch. The tool itself goes away with

uv tool uninstall llmfit

and this tells you whether anything is left over:

uv tool list

If you only tried llmfit with uvx, you never installed anything permanently in the first place. The downloaded packages still sit in uv’s cache, though. You empty it with

uv cache clean

Now for the catch: if you installed uv through the package manager, you’re tempted to simply type

sudo pacman -Rns uv

But pacman only removes its own package. What uv itself created in your home directory is unknown to the package manager, and without uv you can no longer run uv tool uninstall either. So uninstall the tool first and uv second, not the other way around.

These commands show you where the leftovers are:

uv tool dir
uv cache dir

Usually that’s ~/.local/share/uv/tools and ~/.cache/uv. If uv is already gone and llmfit is still around, the only option is to clean up by hand:

rm -r ~/.local/share/uv

Be careful here: this also wipes out all tools installed with uv and the Python versions managed by uv, not just llmfit.

On Ubuntu, where uv comes from the install script, there is no uv self uninstall. There, after the uv tool uninstall, you remove the two launcher binaries yourself:

rm ~/.local/bin/uv ~/.local/bin/uvx

The TUI is more than a simple model list

The terminal interface is one of the more interesting parts of llmfit to me. Instead of just printing a list, it lets you move through the results, search, and pull up more information on each model.

Use / to search for a specific model, the arrow keys or j and k to navigate, and h opens the help. With almost 10,000 entries in the list, the search is no luxury.

The built-in benchmark features are interesting, too. b brings up community benchmarks, while I starts an inference benchmark on your own hardware. That slowly turns a pure estimate into a measurement with real numbers.

It reminds me a bit of classic system tools. If you use Mission Center on GNOME, for example, you get CPU, RAM, GPU and other resources presented graphically. llmfit, on the other hand, looks specifically at the question of what you can do with those resources in terms of local AI.

Estimates instead of marketing promises

Of course, you shouldn’t mistake llmfit’s numbers for a real benchmark. A theoretical calculation can only estimate how fast a certain model might run on a certain piece of hardware.

The hardware simulation is quite nice in this context. You can tweak RAM, VRAM, and core count just to see how the rating shifts. If you’re toying with the idea of buying more memory or a new graphics card, you at least get a ballpark figure.

That’s exactly why the benchmarks that are now built in are interesting. llmfit can download a model, start it via a supported runtime provider, and then measure the actual speed on your own hardware. The results are stored locally.

If you like, you can then share your measurements with the community via

llmfit bench --share

The results are submitted as a GitHub pull request. This way, a database of real measurements slowly builds up, instead of just theoretical calculations.

With local AI in particular, I find this approach sensible. After all, the statement “fits into VRAM” doesn’t tell you much about whether you can actually work with the model in a reasonable way.

Also usable as a command-line tool

If a TUI isn’t your thing, you don’t have to use llmfit interactively. The program works entirely from the command line, too.

For example,

llmfit recommend

gives you a recommendation for your hardware. With

llmfit recommend --json

you can output the results as JSON. That’s obviously a lot more interesting if you want to build llmfit into your own scripts or other tools.

You can also start a web interface or an API:

llmfit serve --host 0.0.0.0 --port 8787

There is also a ready-made image for containers:

ghcr.io/alexsjones/llmfit

That means llmfit runs on a server or in an existing Docker setup, too. If you keep your containers up to date regularly, you may already know the drill from Dockcheck.

And what do you run the model with?

One distinction you should keep in mind: llmfit is not an AI runtime itself. The program helps you choose and evaluate a model, while other tools do the actual inference.

Supported tools include Ollama, llama.cpp, MLX, Docker Model Runner, and LM Studio. That means llmfit can, for example, benchmark a model through an existing Ollama or llama.cpp stack.

On Linux, Ollama is certainly one of the easier ways to get local models up and running. If you want more control over the inference itself, you quickly end up with llama.cpp. The two projects take somewhat different approaches, but both combine well with llmfit’s hardware check.

Interesting for local AI

To me, llmfit closes a gap between “I’d like to try local AI” and “I first have to work my way through the hardware requirements of dozens of models.” That’s far more helpful than a generic list of the “best” local models. In the end, what matters isn’t which model scores well on some test system, but which one runs properly on your hardware for your use case.

Of course, the estimates don’t replace your own testing. That’s exactly what the built-in benchmarks are for, and they’re what I want to tackle next: my own measurements on different machines, and then a comparison of how well llmfit’s predictions match reality.

The tool should be especially interesting for developers. If you want to use a local AI assistant for programming, you first find out which models fit your hardware, and then experiment with the speeds you can actually reach.

You’ll find more information, the current documentation, and the source code 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.

Among other things, tfm comes with a sidebar, tabs, a dual-pane view, and file previews. The usual file operations like copying, moving, renaming, and deleting are on board as well. What’s interesting: you don’t have to work exclusively with the keyboard. Tfm also supports the mouse, so you can select, move, and rename files by drag and drop, for example.

That way, tfm combines typical features of graphical file managers with the terminal environment. If you spend a lot of time there anyway, you can manage files and directories without opening a separate graphical app.

Installing from the AUR

You can find Tfm in the AUR (Arch User Repository). If you use an AUR helper like yay, you can install the binary version right away. On Arch Linux, this command is all you need:

$ yay -S tfm-tui-bin

After that, start the file manager with:

$ tfm

If you use a different distribution, the project page has instructions for the install script provided there. With it, you install the current version independently of your distribution’s packages.

Nerd Fonts for the icons

For tfm to show folders and files with the intended icons, you need a Nerd Font. These fonts come with additional characters and icons that terminal apps use to display folders, files, and other elements.

For this article, I’m using the Hack Nerd Font. On Arch Linux, the font is available directly in the official repositories and can be installed with pacman:

$ sudo pacman -S ttf-hack-nerd

For tfm to display the icons correctly, the Hack Nerd Font only has to be installed on your system. You don’t need to select the font in your terminal for that. You normally don’t need to refresh the font cache manually for a package from the Arch repositories either.

Beta with a few rough edges

Tfm is still in beta, and you’ll notice it most in how icons are displayed. In my tests, the Nerd Font symbols didn’t show up reliably on every start. Folders and other elements sometimes appear without the icons they’re supposed to have.

Restarting tfm or the terminal usually fixes it. What stands out: the icons come back on the next start even without any changes to the font cache, so the problems can’t be blamed solely on a broken installation of the font.

For graphical image previews, tfm needs a terminal that supports the Kitty Graphics Protocol. On Linux, Ghostty is a good choice, for example, and its Linux interface is built on GTK4. Gnome Terminal can’t offer this feature, because the underlying VTE library doesn’t support the Kitty Graphics Protocol.

The rest of the interface isn’t yet as stable or consistent as what you’re used to from established file managers, either. If you try tfm, start with files that don’t matter, and don’t trust important data to such young software on its own.

The most important keyboard shortcuts

Despite the mouse support, the keyboard plays an important role in tfm. You’ll find the most important commands in the following overview:

All in all, tfm is a likable find for me, especially for anyone who spends all day in the terminal anyway. The sidebar, tabs, dual-pane view, preview and mouse control add a level of comfort you normally don’t get on the command line. If you like, you can even switch on animations – a video on Reddit shows what that looks like.

Keep the quirks of the beta phase in mind, though, above all the icon rendering and the interface, which isn’t quite polished yet. I’ll keep following the development, and right now I’d mainly recommend tfm for trying it out – preferably with non-critical files until the software has matured a bit.

☕ 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.

For Shotwell, the switch to GTK4 is more than a visual facelift. Especially on Arch Linux with a current GNOME and Wayland, the app benefits from the toolkit’s more modern interfaces. Features like drag-and-drop and desktop portals should also work more reliably as a result.

For my test, though, I didn’t install Shotwell on Arch Linux from the repositories but as a Flatpak. That’s especially interesting for larger GNOME apps when you want to try a current version without waiting for your distribution to catch up. It also makes it easy to delete the app’s data without leaving anything behind.

GTK4 brings Shotwell up to date

Besides the GTK4 port, Shotwell 0.33 comes with plenty of smaller improvements. These include an overview of keyboard shortcuts, reworked export and print functions, and toasts as a modern alternative to plain dialog windows. Opening URLs in the viewer has been added as well.

Some features that were temporarily missing during the GTK4 port are back, too, most notably drag and drop. The viewer also shows additional system information, and context menus can now be opened with the keyboard. Navigating between controls has been improved as well.

Publishing and bug fixes

Publishing photos to external services has been reworked as well. The window for external authentication can now be shown in several places. Shotwell replaces the previous separate authentication helper with a simple web server that runs locally on your machine.

On top of that, there are plenty of bug fixes. Among other things, problems with toolbars that hide automatically in fullscreen mode, with the slideshow, with setting desktop wallpapers and with sending many photos at once have been fixed. Working with faces and their tags has also been improved further.

My impression on Arch Linux

To me, the GTK4 port is the really interesting news in this release. It puts Shotwell in much better shape for current Linux desktops. Especially on Arch Linux with GNOME on Wayland, it’s nice when an older app doesn’t stay stuck on its old GTK foundation forever.

If you want to try Shotwell on Arch Linux, you can first check which version is available in your repositories. For my test, I used Flatpak instead. That way you can install the current Shotwell version independently of what Arch Linux ships, and remove it again just as easily. Right now, even Arch Linux is one version behind.

That makes the new version interesting for users who had written off Shotwell because of its technically outdated GTK3 base. Whether the app wins you over as a photo manager in the long run depends heavily on your own workflow, of course. But as a lean GNOME solution, it’s worth a look.

More posts about GNOME and images

You’ll find a few older posts here on the blog about image editing and photo tools. For example, I’ve covered simple image editing on Linux (in German) and a range of tools for taking screenshots and working with images. Gradia has also gone all in on GTK4 by now.

You can get the current version of Shotwell as a Flatpak on Flathub. If you’re interested in the latest technical changes to the app and want to follow how development goes from here, take a look at the official release announcement and the Shotwell project page.

☕ 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 obvious solution: /etc/fstab plus a dispatcher script for NetworkManager that mounts automatically based on the SSID or on whether the server is reachable. Sounds like an evening project. It isn’t quite. I tripped over three pitfalls that you only notice when the machine shuts down, wakes up, or is supposed to go into standby. Those are the three I’ll walk you through here.

I tested all of this on Arch Linux, but the setup is not Arch-specific. As long as your distro ships systemd and NetworkManager (so Fedora, Ubuntu, Debian or openSUSE, for example), everything here works one to one.

The basic setup

Network shares traditionally get noauto in the fstab, so they are not mounted immediately at boot but only when needed:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev 0 0

For the mount type itself, the Arch Wiki has good guides depending on the protocol, for example on Samba/CIFS and on davfs2 for WebDAV. Both work on any distribution, as long as cifs-utils or davfs2 are installed.

The actual mounting is then handled by a script in /etc/NetworkManager/dispatcher.d/. NetworkManager calls such scripts on every connection change and passes along the interface and the status (up, down, pre-down and a few more). All the details are in the NetworkManager dispatcher man page. A simple script checks the active Wi-Fi SSID and mounts if it matches:

#!/bin/bash
IFACE="$1"
STATUS="$2"

case "$STATUS" in
    up)
        SSID=$(nmcli -t -f active,ssid dev wifi | awk -F: '$1 == "yes" {print $2; exit}')
        if [[ "$SSID" == "MeinHeimnetz" ]]; then
            mount /mnt/server/home
            mount /mnt/server/data
        fi
        ;;
    down)
        umount /mnt/server/home
        umount /mnt/server/data
        ;;
esac

Done, right? Not quite. As soon as you shut down the system, wake it from standby or put it into standby, it turns out that this approach has its catches.

Why not just use GVfs?

You may now be wondering why I put myself through fstab and dispatcher scripts at all. GNOME offers “Connect to Server” in the file manager, which is a much easier way to mount network shares via SMB or WebDAV. That is exactly where my problem lies.

Such mounts don’t go through the kernel but through GVfs, GNOME’s virtual file system. Programs that use the GIO library (almost all GTK apps, first and foremost the file manager itself) talk to shares directly through their own URIs like smb:// or dav://, and accordingly display thumbnails and metadata correctly. For programs that can’t do that, GVfs additionally exposes the share as a perfectly normal path under /run/user/<uid>/gvfs. This bridge does run through FUSE. GVfs itself is not a classic FUSE file system but its own architecture with a daemon process per protocol, yet for exactly this case it provides a POSIX-compatible path via gvfsd-fuse.

This very bridge is the sticking point for me: not every program copes with it reliably. In my case it shows up in a Markdown editor where I also embed images for articles. The file manager displays the images on the network drive just fine, because it speaks GVfs natively. The Markdown editor, on the other hand, shows only a placeholder for the same image. Access via the FUSE path simply doesn’t work reliably, even though the file is demonstrably there.

A classic kernel mount via CIFS or davfs2, as described in the rest of this article, shows up as a perfectly normal, stable POSIX path in the file system, with no special treatment and the same for every program. So the extra effort with fstab and dispatcher scripts pays off precisely when you want to use shares reliably not just in the file manager but in all kinds of apps.

Problem 1: The computer doesn’t shut down cleanly anymore

If the fstab lacks the option _netdev, systemd doesn’t know that this is a network share. On shutdown, systemd may then try to unmount after the network is already gone. The umount blocks until the job timeout kicks in, and your system hangs on shutdown.

_netdev fixes that, because systemd then knows the right order: unmount first, then cut the network. It is also important that a dispatcher script reacts not just to down but to pre-down. That status fires before the connection actually drops, while down comes afterward and is too late for a clean unmount. For this to work, you additionally need a symlink in the subfolder pre-down.d/.

Problem 2: The file manager freezes after waking up

A mount call for CIFS or WebDAV runs in the kernel and can block for quite a while if the server is unreachable, especially right after waking up, when DNS or routing aren’t fully back yet. By default, NetworkManager waits synchronously until such a dispatcher script has finished before it carries on. If the mount call hangs, suddenly your file manager or the network indicator hangs too, because they depend on the connection state.

The fix: just run the mount attempts in the background, so the dispatcher script itself returns immediately, no matter how long the actual mount takes.

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

Problem 3: Suspend suddenly stops working

And this is where it gets interesting. With the fix from problem 2 you stumble into a new and much nastier problem, which in my case looked like this: the screen turns off, but the keyboard backlight and LEDs stay on, and you have to force a hard power-off. What happened?

The mount syscall for CIFS or davfs blocks with an unreachable server in the so-called D state (uninterruptible sleep), a state that no signal can interrupt, not even SIGKILL. Before the kernel actually goes to sleep, it tries to freeze all processes. A process in D state can’t be frozen, so the whole suspend hangs until the network operation in the kernel gives up on its own, which can easily take a few minutes.

Because the mount attempts from problem 2 now keep running in the background for longer, the chance also goes up that such a blocking connection attempt is active at exactly the moment you want to suspend.

The reliable way out: before every mount, first check with a real userspace connection test whether the server is reachable at all. That kind of test can actually be aborted with a timeout, for example via Bash’s built-in /dev/tcp:

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

Only if the test succeeds does the actual mount follow. That way you almost never end up in the risky, blocking kernel connect, because by then you already know the server is there.

The combination that works for me

In the end, a robust setup needs four ingredients:

• _netdev in the fstab, so systemd classifies network shares correctly on shutdown.
• pre-down handling plus a symlink in pre-down.d/, so the unmount is guaranteed to happen before the connection is torn down, with a timeout and lazy unmount as a backup in case the normal umount acts up.
• Asynchronous mounts on up, so NetworkManager and everything that depends on it doesn’t block.
• A reachability test before every mount, so the actual, potentially blocking kernel connect never happens in the first place.

On top of that, a small health check via a systemd timer that looks a few minutes after boot and regularly afterward to see whether the shares are really there, and nudges things along if needed. Handy in case the triggering network event comes too early or too late.

All files at a glance

So you can rebuild all of this right away, here is the complete set of files. I replaced the example names from my own setup (a Samba server called bender, WebDAV via tuxedo) with generic placeholders. You’ll of course have to adapt them to your own environment.

/etc/fstab: the two shares, one Samba, one WebDAV:

//server/home /mnt/server/home cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
//server/data /mnt/server/data cifs credentials=/etc/samba/server.credentials,rw,uid=1000,gid=100,noauto,_netdev,x-systemd.mount-timeout=15s,soft 0 0
https://cloud.example.com/remote.php/dav/files/user /mnt/webdav davfs noauto,_netdev,uid=1000,gid=100,x-systemd.automount,x-systemd.idle-timeout=300,x-systemd.mount-timeout=15s 0 0

The fstab only references the credentials; they are stored in separate files, if only so the password doesn’t sit in plain text in a file that everyone can read.

/etc/samba/server.credentials: credentials for the Samba share:

username=maxmuster
password=GeheimesPasswort123

/etc/davfs2/secrets: credentials for the WebDAV share. Here the mount point is referenced instead of an option in the fstab:

/mnt/webdav maxmuster GeheimesPasswort123

Both files belong to root and must not be readable by anyone else:

$ sudo chmod 600 /etc/samba/server.credentials /etc/davfs2/secrets
$ sudo chown root:root /etc/samba/server.credentials /etc/davfs2/secrets

/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh: the shared library that all the other scripts source:

#!/bin/bash
log() {
    [[ "$DEBUG" == "1" ]] && logger -t "$LOG_TAG" -- "$1"
}

run_async() {
    ( "$@" ) &>/dev/null &
    disown
}

tcp_reachable() {
    local HOST="$1"
    local PORT="$2"
    local TIMEOUT_SECONDS="${3:-2}"
    timeout "${TIMEOUT_SECONDS}s" bash -c "echo >/dev/tcp/${HOST}/${PORT}" &>/dev/null
}

mount_with_retry() {
    local MOUNT="$1"
    local MAX_ATTEMPTS="${2:-3}"
    local SLEEP_SECONDS="${3:-2}"
    local MOUNT_TIMEOUT="${4:-10}"

    if mountpoint -q "$MOUNT"; then
        log "$MOUNT ist bereits eingehängt"
        return 0
    fi

    log "Hänge $MOUNT ein"

    local OUT ATTEMPT
    for ((ATTEMPT = 1; ATTEMPT <= MAX_ATTEMPTS; ATTEMPT++)); do
        if OUT=$(timeout "${MOUNT_TIMEOUT}s" mount "$MOUNT" 2>&1); then
            log "$MOUNT erfolgreich eingehängt"
            return 0
        fi
        log "Versuch $ATTEMPT/$MAX_ATTEMPTS für $MOUNT fehlgeschlagen (evtl. Timeout nach ${MOUNT_TIMEOUT}s): $OUT"
        &#91;&#91; "$ATTEMPT" -lt "$MAX_ATTEMPTS" ]] && sleep "$SLEEP_SECONDS"
    done

    log "Alle Versuche für $MOUNT fehlgeschlagen"
    return 1
}

umount_with_fallback() {
    local MOUNT="$1"
    local TIMEOUT_SECONDS="${2:-5}"

    if ! mountpoint -q "$MOUNT"; then
        log "$MOUNT ist nicht eingehängt"
        return 0
    fi

    log "Hänge $MOUNT aus"

    if timeout "${TIMEOUT_SECONDS}s" umount "$MOUNT"; then
        log "$MOUNT erfolgreich ausgehängt"
        return 0
    fi

    log "Normaler Unmount von $MOUNT fehlgeschlagen, versuche Lazy Unmount"
    if umount -l "$MOUNT"; then
        log "$MOUNT per Lazy Unmount ausgehängt"
        return 0
    fi

    log "$MOUNT konnte nicht ausgehängt werden"
    return 1
}

/etc/NetworkManager/dispatcher.d/90-server-mount: Samba share, bound to a specific Wi-Fi SSID or to the wired network:

#!/bin/bash

DEBUG=1
LOG_TAG="server-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTS=(
    "/mnt/server/home"
    "/mnt/server/data"
)

mount_server() {
    if ! tcp_reachable server 445 2; then
        log "server auf Port 445 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    for MOUNT in "${MOUNTS[@]}"; do
        mount_with_retry "$MOUNT" 3 2 10
    done
}

umount_server() {
    for MOUNT in "${MOUNTS[@]}"; do
        umount_with_fallback "$MOUNT" 5
    done
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        if [[ "$IFACE" == wl* ]]; then
            SSID=$(nmcli -t -f active,ssid dev wifi |
                awk -F: '$1 == "yes" {print $2; exit}')

            log "Aktive WLAN-SSID: $SSID"

            if [[ "$SSID" == "MeinHeimnetz" ]]; then
                run_async mount_server
            fi

        elif [[ "$IFACE" == enp* || "$IFACE" == eth* ]]; then
            run_async mount_server
        fi
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mounts aushängen"
        umount_server
        ;;
esac

log "Dispatcher beendet"
exit 0

/etc/NetworkManager/dispatcher.d/90-webdav-mount: WebDAV share, which simply requires a reachable cloud server:

#!/bin/bash

DEBUG=1
LOG_TAG="webdav-mount"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

IFACE="$1"
STATUS="$2"

MOUNTPOINT="/mnt/webdav"
HOST="cloud.example.com"

mount_webdav() {
    if ! tcp_reachable "$HOST" 443 3; then
        log "$HOST auf Port 443 nicht erreichbar, überspringe Mount-Versuch"
        return 1
    fi

    mount_with_retry "$MOUNTPOINT" 3 2 10
}

log "Dispatcher gestartet: Interface=$IFACE, Status=$STATUS"

case "$STATUS" in
    up)
        run_async mount_webdav
        ;;

    pre-down|vpn-pre-down)
        log "Netzwerkverbindung wird beendet – Mount aushängen"
        umount_with_fallback "$MOUNTPOINT" 5
        ;;
esac

log "Dispatcher beendet"
exit 0

For both scripts you also need the matching symlinks, so that pre-down is guaranteed to fire before the connection is torn down:

$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-server-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-server-mount
$ sudo ln -s /etc/NetworkManager/dispatcher.d/90-webdav-mount 
             /etc/NetworkManager/dispatcher.d/pre-down.d/90-webdav-mount

/usr/local/bin/mount-healthcheck.sh: the safety net that checks regularly:

#!/bin/bash
DEBUG=1
LOG_TAG="mount-healthcheck"

LIB="/etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh"
if [[ -r "$LIB" ]]; then
    source "$LIB"
else
    logger -t "$LOG_TAG" -- "Bibliothek $LIB nicht gefunden, breche ab"
    exit 1
fi

log "Healthcheck gestartet"

SSID=$(nmcli -t -f active,ssid dev wifi 2>/dev/null |
    awk -F: '$1 == "yes" {print $2; exit}')

if [[ "$SSID" == "MeinHeimnetz" ]] || ping -c 1 -W 1 server >/dev/null 2>&1; then
    mount_with_retry "/mnt/server/home" 2 3
    mount_with_retry "/mnt/server/data" 2 3
else
    log "server im aktuellen Netz nicht erreichbar, überspringe"
fi

mount_with_retry "/mnt/webdav" 2 3

log "Healthcheck beendet"
exit 0

/etc/systemd/system/mount-healthcheck.service and mount-healthcheck.timer: systemd units that trigger the health check script 60 seconds after boot and every 10 minutes after that:

[Unit]
Description=Prueft und stellt Netzwerk-Mounts sicher
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
TimeoutStartSec=120
ExecStart=/usr/local/bin/mount-healthcheck.sh

[Unit]
Description=Fuehrt den Mount-Healthcheck 60s nach Boot und danach alle 10 Minuten aus

[Timer]
OnBootSec=60s
OnUnitActiveSec=10min
AccuracySec=30s

[Install]
WantedBy=timers.target

Don’t forget to enable it:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now mount-healthcheck.timer

/usr/lib/systemd/system-sleep/90-cancel-network-mounts: an optional safety net before suspend:

#!/bin/bash
case "$1/$2" in
    pre/*)
        logger -t sleep-mount-guard "Breche evtl. laufende Netzwerk-Mount-Versuche vor Suspend ab"
        pkill -9 -f 'mount.cifs' 2>/dev/null
        pkill -9 -f 'mount.davfs' 2>/dev/null
        ;;
esac

exit 0

All scripts have to be executable:

$ sudo chmod +x /etc/NetworkManager/dispatcher.d/lib/mount-helpers.sh 
              /etc/NetworkManager/dispatcher.d/90-server-mount 
              /etc/NetworkManager/dispatcher.d/90-webdav-mount 
              /usr/local/bin/mount-healthcheck.sh 
              /usr/lib/systemd/system-sleep/90-cancel-network-mounts

Long story short

Automatically mounting network shares via NetworkManager works well, but it is not a five-minute job, as the docs might make you think. If you just put the mount command into an up script, sooner or later one of the three problems will catch up with you, usually exactly when you’re on the road and have no log at hand.

With _netdev, correct pre-down timing, asynchronous execution and a real reachability test before every mount, you’re on the safe side. And the pattern carries over one to one to other network-dependent automations, such as VPN connections or backup jobs that should only run on the right network.

☕ 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 why Rutile is an interesting project to watch. The developers aren’t simply continuing Tilix. They are rebuilding the terminal emulator completely in Rust, while keeping the same way of working. The goal isn’t to reinvent anything, but to create a modern implementation that fits right into current GNOME systems with GTK4 and libadwaita.

A proven concept on a modern foundation

Many terminal emulators differ mainly in how they look or in a few minor extra features. Rutile takes a different approach. The goal is to carry over the way Tilix works as completely as possible and put it on a modern technical foundation. Existing users should feel at home right away.

The app uses GTK4, libadwaita and VTE4, so it benefits from current libraries of the GNOME desktop. At the same time, the developers have chosen Rust as the programming language. In the long run, that promises a more maintainable codebase and makes it possible to build new features on a modern architecture.

Flexible terminal splitting

Rutile takes its most important feature straight from Tilix. You can split the terminal window recursively, both horizontally and vertically, and every pane can be split again. That gives you flexibly nested workspaces, without the app being locked into a fixed grid or a particular window layout.

In everyday use, this way of working has plenty of advantages. On the left, for example, you can watch log files while several servers or containers are open on the right. You switch between the individual panes comfortably with the keyboard. That saves mouse movements and keeps things flowing when you’re working on more complex tasks.

Other terminals like Ghostty offer this feature too, but you have to memorize key combinations for it. Alternatively, you can of course use a terminal multiplexer like tmux. The same applies there, though. Even if it’s not a lot of key combinations: personally, I simply want buttons for this.

Multiple independent sessions

Besides the freely splittable terminal panes, Rutile supports multiple separate sessions. Each session has its own window layout and its own working context. That way you can keep different projects or tasks neatly apart without having to open several program windows.

You switch between sessions either with a keyboard shortcut or through a sidebar. The sidebar shows small thumbnails of each working environment and is hidden by default. If you need it, just show it from the toolbar, and you’ll find it easier to keep track of things even with lots of open sessions.

Synchronized input

One feature I find especially handy is synchronized input. When you enable it, Rutile sends every keystroke to several terminal panes in a session at the same time. That saves a lot of time when you need to run identical commands on several servers or virtual machines.

You can exclude individual terminal panes from the shared input at any time. That way, specific systems can get different commands without you having to turn off synchronization completely. Still, a bit of caution is a good idea, because a faulty command will otherwise run on all connected systems at the same time, too.

Familiar Controls

The keyboard shortcuts also follow the original closely. With Ctrl+Shift+O and Ctrl+Shift+E you split the window horizontally or vertically. Ctrl+Shift+W closes the active pane, while the arrow keys switch between the individual terminal panes.

You open new sessions with Ctrl+Shift+T. To switch between existing sessions, press Ctrl+Shift+Page Up or Page Down. If you prefer working with the mouse, you can also reach the same functions through the toolbar or the context menu of each terminal pane.

Still in an early stage of development

Rutile is still at the very beginning of its development. The first version deliberately focuses on the most important features. Things like a Quake mode, saving complete sessions, desktop notifications, or Nautilus integration are meant to come later, once the existing features work reliably.

I think this is a sensible approach. Instead of shipping as many features as possible early on, the project first concentrates on a stable core. Especially with tools that many users rely on every day, reliability and a consistent way of working matter more than a long feature list.

What is really missing right now are translations. Some dialogs currently show up only in French. You also can’t change the terminal colors directly in the settings yet. The default color scheme makes programs like Midnight Commander hard to read in places. That said, the current version of Rutile was only released a few days ago, so I expect something will happen here soon.

Installation

On Arch Linux, Rutile is available in the AUR both as a source package and as a precompiled version. For Debian, Ubuntu, and Fedora, the developers provide ready-made DEB and RPM packages. You can also download a standalone binary, as long as the required GTK4 components are already installed. All the installation details are on the project’s GitHub page.

If you have been using Tilix for years and want to move to a modern GTK4 foundation, you should keep an eye on Rutile. A few features are still missing, but what I have seen of its development so far looks very promising. The project has a clear focus and could grow into a worthy successor to Tilix.

☕ 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 culprit is an update to the official Electron-based Linux client that messed up the GTK-style window decoration. Spotify itself works just as before, but visually it looks anything but nice.

Solutions for Spotify

There are two easy ways to fix the problem. The most convenient one is to install Spotify as a Flatpak. The Flatpak version doesn’t show the blue frame, and you don’t have to worry about anything. No configuration changes are needed.

If you installed Spotify via the Spotify Launcher (the spotify-launcher package from Arch’s extra repository) or directly from the AUR (the spotify entry), you need to set the launch flag --ozone-platform=x11 instead. That makes the GTK decoration show up correctly. Depending on how you installed it, add the flag like this:

For AUR Spotify in the file ~/.config/spotify-flags.conf:

--ozone-platform=x11

For Spotify Launcher in ~/.config/spotify-launcher.conf:

[spotify]
extra_arguments = ["--ozone-platform=x11"]

You may have to create these files first. After restarting Spotify, the blue frame should be gone and everything should look normal again.

Correction from Fabian on Mastodon: That’s not quite right. This is solely down to Spotify running natively on Wayland, where under GNOME it needs a client-side decoration (CSD), which it provides through that blue one. Forcing it back to X11 might cause real problems, like blurry fonts, bad (or no) scaling and so on. Also, Spotify isn’t Electron, it’s the Chromium Embedded Framework (CEF).

Sure, it’s a crutch, but one that helps right now. And you can undo the change quickly, too. The other options would be to run GNOME under X11 or to make friends with the blue frames. To me, neither is exactly ideal. So for now this is a workaround, and of course you shouldn’t forget about it in case Spotify starts acting up again at some point.

☕ 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.

Besides these graphical tools, the Music Player Daemon, MPD for short, has been with me for a long time too. The name sounds cryptic at first, but the concept behind it is simple. MPD is a music player that runs in the background and can be remote-controlled through numerous clients. So you can hook a computer or Raspberry Pi up to your stereo, add your own music collection, and control playback from anywhere in the house.

Music Player Daemon aka MPD

MPD is quite different from streaming servers like Jellyfin or Navidrome, which are based on the Subsonic protocol. With those, the server streams the music to the clients. With MPD, the client only controls playback, and the service itself plays directly on the server. What I find remarkable is that development on MPD hasn’t fizzled out even after more than twenty years. The current stable version, MPD 0.24.6, has only just been released.

You can tell that MPD is still alive and kicking on the client side as well. Modern Subsonic clients for Linux (especially for the GNOME desktop) have unfortunately become really rare. Sublime Music and Sonixd have been discontinued, and I can’t warm to Feishin or Supersonic. Around MPD, on the other hand, new projects keep popping up. Lately, more and more apps are appearing based on GTK4 and Libadwaita, which fit perfectly into the current GNOME design and make good use of the desktop’s features.

MPD for GNOME: Plattenalbum

Plattenalbum (Flathub) just received an update to version 2.4.0 and uses GTK4 without getting lost in an overly playful design. The album covers are clearly the center of the interface. The layout stays classic: artists on the left, albums in the middle, and on the right the player with the controls for playback.

If you want to read the lyrics during playback, use the button above the player to switch to the lyrics view. The lyrics don’t have to be stored in the ID3 tag. Plattenalbum loads them automatically from the Brazilian service Letras, which is especially handy if your own files aren’t fully tagged. There aren’t many settings, and honestly, it doesn’t need many.

MPD for GNOME: Euphonica

Unlike Plattenalbum, Euphonica (Flathub) relies much more on visual effects. The window background adapts to the colors of the current album, and an animated spectrum moves along the bottom edge. When you switch between the artist and album views or open an album, the individual elements glide smoothly into view, which gives it a modern feel.

Euphonica also convinces functionally. You can navigate through artists and albums, and filtering by genre is supposed to come in the future. With MPD 0.24 or newer, you can rate albums. Through MPRIS, Euphonica integrates seamlessly into the desktop, shows notifications when the track changes, and lets you control playback through the desktop’s own functions as well.

In general, it would be great if a new GTK4/Libadwaita client for Subsonic showed up again. Navidrome runs very reliably on my small self-hosting server. For Android, there’s Symfonium (proprietary, but worth every cent) and Tempus, an actively developed version of the FOSS client Tempo. Navidrome’s web frontend works great too. On the desktop, though, a native app is missing, and right now there’s a big gap.

☕ 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.

But honestly, for the occasional bit of radio you don’t always need all the bells and whistles. That’s where Yet Another Radio comes in: a compact and handy extension for the GNOME Shell. It plays your favorite stations without you having to open a separate app. You still get the convenience, too: you don’t have to hunt down stations and their URLs online yourself, because a database is built right in.

What is Yet Another Radio?

The developer describes his motivation on Reddit like this:

Hello everyone! Long story short, I recently switched from KDE to GNOME and saw that there is no extension like the popular Advanced Radio Player for GNOME which is simple and easy to use. So I started developing my very first extension.

In short: if you’re looking for a simple, uncluttered tool to control radio stations right from the GNOME panel, this is exactly what you need. Here’s the extension on GNOME Extensions.

Features at a Glance

With Yet Another Radio, you can play your favorite stations straight from the panel, without having to open an extra window. Through the Radio Browser API, you can search thousands of stations and quickly find whatever you’re in the mood for. You can mark your favorites so you can play them any time with a single click.

If you like, you can also add your own stations manually or import and export existing lists. That comes in handy if you use several devices, for example. The extension also displays track information including album covers, although so far I haven’t found a single station where this feature actually shows up.

So Yet Another Radio is ideal for anyone who wants to listen to internet radio in GNOME without fuss, and without depending on a full-blown app like Shortwave. Just install it, search for stations, set your favorites, done. If you want more, you can import station lists or add your own stations. A small, nice extension that shows how handy GNOME extensions can be.

☕ 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.

On a desktop computer, this works perfectly: you build the route in the browser with plenty of time and patience, export it as GPX, and send it to your bike computer or your favorite navigation app. But what if you need a route on the spot while you’re out riding? That’s where Chainlane comes in. It’s a new Android app that brings Brouter, and with it navigation based on OpenCycleMap, straight to your smartphone, and it clearly leaves Google Maps behind as a bike navigation tool.

Chainlane: Brouter in your pocket

With Chainlane, you carry Brouter and offline maps right on your phone. You can plan a route on the spur of the moment, without having to export GPX files on your computer first. In my first test, this already worked quite reliably: enter a start and destination or just tap the map, pick a routing profile, and the app spits out a route.

For navigating on the road, you can use Chainlane with the phone mounted on your handlebars, but you don’t have to. Since a small update, the calculated routes can also be exported without any trouble, for example to bike computers like the Wahoo Roam or to Garmin devices. That makes the app very flexible, especially if you already have a bike GPS but don’t like its built-in routing algorithm, or if you’re riding a “special” bike like a velomobile.

Features and development status

The app is still in the middle of development. Basic features like route planning and simple navigation are already there. Turn-by-turn hints exist, but so far they only work reliably as long as you stay on the planned route. According to the developer, voice announcements and more robust active routing are still to come.

Something interesting for advanced users: you can plug your own BRouter profiles into Chainlane. The interface is still being reworked, but you can already calculate very individual routes with it. You’ll find more insight into the development process in the developer’s introduction post on Reddit. The author of the app is active there under the name RepulsiveRaisin7 and regularly answers questions.

Cost model and future

Right now, Chainlane is free, including all features. A subscription model is planned for later, with around 15 euros per year under discussion. Extra features like points of interest on the map (e.g. water points, cafés, bike shops, shelters) or a power-saving mode are supposed to end up behind that paywall.

There’s a catch for those of us who care about free software: Chainlane is not open source and is currently only available in the Google Play Store. That’s a shame, especially because the foundation, Brouter, is a prime example of how powerful and future-proof open source can be. If you have freed your Android phone from Google, you’ll have to keep relying on OsmAnd~.

A good option with potential

So Chainlane is an exciting addition for anyone who wants to use Brouter flexibly on the road. The app is still in its infancy, but in my testing it already works surprisingly well. If you’ve been wrestling with GPX exports and imports until now, this gives you a handy tool. If you’re a Brouter fan anyway, it’s worth a look. And maybe you can still convince the developer to release Chainlane as free software at some point. That would be a win for all of us.

☕ 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 way, access to your own network stays possible even on the day the server doesn’t work the way it should. If something is wrong with the box itself and the internet connection drops out completely, everything is usually lost anyway. On top of that, you need neither port forwarding nor an extra DynDNS service in this case, because AVM takes care of that with its MyFritz service.

Setting up WireGuard on the Fritzbox

You set this up in the Fritzbox under Internet » Permit Access (Freigaben) on the VPN (WireGuard) tab. Click Add Connection and then choose Connect single device. You can name the connection whatever you like. Usually it’s the name of the client machine or of the person who will use the VPN. At the end, you have to confirm the new connection, for example by phone, by pressing a button on the box, or in the Fritz app.

The Fritzbox then shows you a page with a QR code. Scan it with your smartphone to import the connection straight into the official WireGuard app for Android. Alternatively, you can use the open-source app WG Tunnel, which offers a lot more features than the “official” WireGuard client for Android. Personally, I use WG Tunnel, which I installed via F-Droid.

WireGuard configuration in NetworkManager

For Linux (and desktop PCs in general), the Fritzbox lets you download the configuration. Click the button and save the file to your hard drive. By default, the file is saved as wg_config.conf in the Downloads folder. The name matters a bit, because some WireGuard clients automatically use it to name the interface.

You can import it directly through NetworkManager on the desktop or from the command line. On GNOME, open Settings, go to Network, click the plus icon and choose Import from file … [CHECK: label]. Then select the file wg_config.conf and import it. You can rename the connection however you like in the settings afterwards, but I recommend setting the interface name to wg0.

$ <strong>nmcli connection import type wireguard file ~/Downloads/wg_config.conf</strong>
Verbindung »wg_config« (39724859-b102-4446-bdb2-1ec60f501360) erfolgreich hinzugefügt.

That’s it. You can now activate the VPN directly from the Quick Settings in GNOME. Other desktop environments like KDE offer similar options as well. If you want to check whether the connection is up, install the IP Finder extension on GNOME. It shows you your public IP address along with a country flag. As soon as the flag of your home country shows up instead of the one for where you currently are (for example, abroad on vacation), the VPN is up and running.

☕ 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.