• Rapidly reduce the size of a PDF

    I am sure you have been there before, trying to submit an important form and your PDF with high resolution scans is too big to be accepted.

    As you probably entered a lot of other data, you do not want to repeat the entire form if the page times out (which they seem to always do!).

    This is an instant one-liner that substantially reduces the PDF size without much quality degradation (my PDF went from 8.9 MiB to 1.1 Mib):

    gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 \
    -dPDFSETTINGS=/ebook \
    -dNOPAUSE -dQUIET -dBATCH \
    -sOutputFile=output.pdf input.pdf

    There are tons of options and parameters in Ghostscript to play with if you are interested, but the above will work for a start. Simply edit the input.pdf and output.pdf paths/files.

  • Toolbx mount access from host on Fedora Kinoite

    Since Toolbx mounts are running in different namespaces than the host, the mounts cannot be accessed from the latter. I tried many workarounds to see if it really was possible to get around this limit. After some time I decided that using the network stack was probably a better solution to communicate between Toolbx and host.

    In my particular case I never do any layering but instead try to use Flatpak, Toolbx, or even a Boxes virtual machine for any specific software not included in the base layering.

    I needed to run restic to access some documents on a remote restic repo backup. Since restic is not included I had to use Toolbx for this task. Restic uses FUSE to mount the remote end on the local system. In an ideal world I could just have opened this mount in Dolphin to search and open the needed documents. However due to the namespaces difference this mount just shows empty on the host.

    A really quick and dirty solution is to simply use rclone and its webdav option, then Dolphin just opens the webdav address with no issues. Yes, there is a tiny performance hit, but the speed and easy execution greatly makes up for this:

    restic mount ~/remote-restic

    Now that the mount is working from Toolbx itself run rclone to serve it over the network:

    rclone serve webdav ~/remote-restic --addr :8080 -L

    That is all! Now simply open Dolphin and paste the webdav address and there you have your Toolbx mount visible from the host:

    dav://127.0.0.1:8080

    Please note that this is not only for restic but can be used with any mount type like sshfs or even another rclone mount like S3.

    Is it not ironic… using a 1990s protocol (WebDAV) to solve a 2026 container problem!

  • Fedora Thunderbird flatpak crashes attaching or saving a file

    The latest flatpak version of Thunderbird from Fedora (not Flathub):

    Commit: 936d9f60ac420057270d5c0c26b3383b04177b678afd6f6e7b7b59df3f0e6663
    Subject: Export net.thunderbird.Thunderbird
    Date: 2025-10-12 19:21:33 +0000

    Crashes when trying to attach a file or save an attachment:

    [Parent 3, Main Thread] WARNING: Could not load a pixbuf from icon theme.
    This may indicate that pixbuf loaders or the mime database could not be found.: 'glib warning', file /builddir/build/BUILD/thunderbird-140.3.0-build/thunderbird-140.3.0/toolkit/xre/nsSigHandlers.cpp:201
    
    (net.thunderbird.Thunderbird:3): Gtk-WARNING **: 12:25:17.580: Could not load a pixbuf from icon theme.
    This may indicate that pixbuf loaders or the mime database could not be found.
    **
    Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/host/share/icons/breeze/status/16/image-missing.svg: Failed to create file “~/.var/app/net.thunderbird.Thunderbird/cache/tmp/gdk-pixbuf-glycin-tmp.KSAZE3”: No such file or directory (g-file-error-quark, 4)
    Bail out! Gtk:ERROR:../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /run/host/share/icons/breeze/status/16/image-missing.svg: Failed to create file “~/.var/app/net.thunderbird.Thunderbird/cache/tmp/gdk-pixbuf-glycin-tmp.KSAZE3”: No such file or directory (g-file-error-quark, 4)
    Redirecting call to abort() to mozalloc_abort
    
    Exiting due to channel error.
    Segmentation fault         (core dumped) thunderbird
    [📦 net.thunderbird.Thunderbird ~]$ exit
    exit

    There is already a Bugzilla entry but until it is solved you can simply remove the TMPDIR environment variable:

    flatpak override --user --unset-env=TMPDIR net.thunderbird.Thunderbird

    To check that it has been done:

    cat ~/.local/share/flatpak/overrides/net.thunderbird.Thunderbird
    [Environment]
    TMPDIR=
    
    [Context]
    unset-environment=TMPDIR; 

    Now just run Thunderbird as usual and it will again allow to save and attach files.

    To later remove the override once Fedora has fixed the bug just run:

    flatpak override --user --reset net.thunderbird.Thunderbird
  • Quick Fedora release version upgrade command

    If you manage many Fedora machines here is a quick one-liner to upgrade Fedora to the next release version:

    dnf --refresh upgrade -y && dnf system-upgrade download --releasever=42 -y && dnf system-upgrade reboot

    As of today Fedora is at version 42, but simply change the release version to the desired target for any past/future version.

    Please note that only one release version jump is supported by Fedora, e.g. from 41 to 42. If you need to upgrade from older versions to the latest, simply run the one-liner sequentially after each reboot.

  • AF60-LR Ethernet Carrier Drop option missing

    Dealing with rain on a 60 GHz radio link can be tricky. It works flawlessly with high capacity in the Gbit range when the weather is nice. Once raindrops start pouring down the link will degrade to a point where it may drop the connection completely, all depending on precipitation level and radio frequency/channel selection.

    When running OSPF over such a wireless bridge there is no indication that the link has failed until the next “Hello” receives no answer from the neighbouring router and the “Dead Interval” is reached. At this point the link would be brought down by OSPF and assuming there are redundant paths, traffic would be routed through another part of the network to its final destination.

    The problem here is the long time the link is reported as being up by OSPF when it is really down. This means traffic is being sent through this dysfunctional path and getting nowhere for as long as the duration of the OSPF “Hello” plus “Dead Interval” timer. Of course one could decrease this timer to a bare minimum, however in a wireless network there could be some brief interference at times which usually would not last long enough for the user to notice. It also increases load on the routers and albeit minimally, the network itself due to the extra packets.

    What we really need is the same experience for the router as if the network cable was to be pulled out of its port socket. The OSPF process would immediately bring the interface down and the path would no longer exist in the OSPF topology database. Traffic would be routed without delay and any downtime via the redundant path. Here is where Ethernet Carrier Drop comes into the picture. As described by Ubiquiti itself in the info label:

    Carrier drop monitors your link and disables Ethernet interface in case downlink capacity drops below configured threshold.
    Port is disabled, if capacity remains below threshold for Carrier Down delay.
    Once capacity exceeds specified threshold for Carrier Up delay, port will be enabled.

    I needed a link consisting of a pair of Ubiquiti 60 GHz airFiber (AF60-LR) to use Ethernet Carrier Drop when rain faded the signal strength killing the connection. The pair runs in a Master & Station mode so wireless configuration is done in the Master and propagates to the Station. However I could not find the Ethernet Carrier Drop selector anywhere. Looking through all the setting pages revealed nothing, however I knew it was present in the firmware.

    Digging around I found a reference to the feature in the old 2021 2.5.0 firmware change-log:

    - Ethernet Carrier Drop is configured on the Station side of the link. When Station DL capacity drops below configured threshold, Ethernet port will be disabled. Management will be available only via wireless link.

    So there you go, the Ethernet Carrier Drop feature is actually in the Station and not the Master wireless settings page.

    I guess the logic behind it is that usually the Master peer is more centrally located in the network topology and the Station in the remote branch. One cannot access the device while the Ethernet port is disabled, so if done on the Master one could be locked out from doing any further configuration changes. Still, it is a bit curious the feature is not explained anywhere apart from in a four year old firmware change-log.