Wie ich hier berichtet habe, ist der Framework Desktop zwar die meiste Zeit leise, aber ca. alle zehn Minuten heult der Netzteillüfter für ca. 30 Sekunden — selbst dann, wenn das Gerät mehr oder weniger im Leerlauf läuft. Das ist extrem störend. Es hat zwei Versuche gebraucht, aber jetzt herrscht Ruhe. Das Problem Kurz zusammengefasst: … Framework Desktop ruhig gestellt weiterlesen →
Wie ich hier berichtet habe, ist der Framework Desktop zwar die meiste Zeit leise, aber ca. alle zehn Minuten heult der Netzteillüfter für ca. 30 Sekunden — selbst dann, wenn das Gerät mehr oder weniger im Leerlauf läuft. Das ist extrem störend. Es hat zwei Versuche gebraucht, aber jetzt herrscht Ruhe. Das Problem Kurz zusammengefasst: Der Framework Desktop hat eine wunderbare CPU-Kühlung mit einem 120mm-Lüfter. Dieser kann aber das eingebaute Netzteil nicht kühlen. Das gekapselte Netzteil besitzt einen eigenen 40mm-Lüfter (PSU), der zwar die meiste Zeit still steht, aber dafür im Betrieb umso unangenehmer heult. Die Luftzufuhr zum Netzteil wird durch eine enge Röhre und das Gitter des Gehäuses behindert. Das Netzteil ist nur mäßig effizient, was sich vermutlich im Leerlaufbetrieb besonders stark auswirkt. Im Netzteil steht die Luft. Diese wird immer heißer. Ca. 1/2 h nach dem Einschalten wird erstmals eine kritische Temperatur erreicht. Nun startet unvermittelt der winzige Lüfter. Eine halbe Minute reicht, um das Netzteil mit frischer Luft etwas abzukühlen — aber nach ca. 10 Minuten beginnt das Spiel von neuem. Der Netzteillüfter kann nicht durch das BIOS gesteuert werden. Lösungsversuch 1 (unbefriedigend) Aus dem Framework-Forum stammt die Idee, das Netzteil durch einen normalerweise langsam laufenden externen Lüfter regelmäßig zu kühlen. Diese Idee habe ich aufgegriffen. Im ersten Versuch habe ich einen 60-mm-Lüfter mit 5V-Versorgung verwendet. Diesen habe ich über eine USB-Buchse mit Strom versorgt, mit einem ziemlich hässlichen Poti (amazon-Link) zur Regulierung der Drehzahl. Der Lüfter muss so eingebaut werden, dass er nach außen bläst, die warme Luft aus dem Netzteil also heraussaugt. <img fetchpriority="high" decoding="async" src="https://kofler.info/wp-content/uploads/framework-fan-1.jpeg" alt="" width="1201" height="1280" class="size-full wp-image-9289" srcset="https://kofler.info/wp-content/uploads/framework-fan-1.jpeg 1201w, https://kofler.info/wp-content/uploads/framework-fan-1-610x650.jpeg 610w, https://kofler.info/wp-content/uploads/framework-fan-1-901x960.jpeg 901w, https://kofler.info/wp-content/uploads/framework-fan-1-768x819.jpeg 768w" sizes="(max-width: 1201px) 100vw, 1201px" /> Erster Versuch mit USB-Lüfter Prinziell war bereits dieser erste Versuch von Erfolg gekrönt. Der interne PSU-Lüfter schaltete sich nicht mehr ein. Allerdings ist die Konstruktion unschön. Die minimale, per Poti einstellbare Drehzahl war so hoch, dass mich das relativ leise Geräusch des externen Lüfters immer noch störte. Aber prinzipiell war bewiesen, dass bereits eine minimale Durchlüftung des Netzteils ausreicht, um bei geringer Belastung das regelmäßige Aufheulen des PSU-Lüfters zu verhindern. Lösungsversuch 2 (funktioniert) Zwei Dinge sind beim ersten Versuch nachteilig: Einerseits kann der Lüfter nicht so weit nach unten hin reguliert werden (also mit niedriger Drehzahl betrieben werden), dass er für mich unhörbar ist. Andererseits fehlt dem Lüfter die »Intelligenz«, unter Last höher zu drehen. Nun bietet der Framework Desktop einen Anschluss für einen zweiten, internen Gehäuselüfter. phoronix hat damit experimentiert, aber der Nutzen ist überschaubar. Meine Idee war nun, diesen Anschluss für einen externen Lüfter zu verwenden. Die einzige Hürde besteht darin, ein Kabel nach außen zu führen. Dazu muss ein Loch in das Belüftungsgitter gebohrt werden. Am besten wäre es, den Framework Desktop dazu zu zerlegen, bis die Rückwand komplett entfernt werden kann. Das war mir zu mühsam. Ich habe nur den CPU-Lüfter ausgebaut, den Innenraum abgedeckt (damit keine Eisenspäne herumfliegen) und dann mit einem Metallbohrer ein Loch in das Lüftungsgitter gebohrt und mit einem Staubsauger alle Späne sofort weggesaugt. Wirklich elegant ist das Ergebnis nicht, aber es erfüllt seinen Zweck. <img decoding="async" src="https://kofler.info/wp-content/uploads/framework-fan-4.jpeg" alt="" width="1280" height="720" class="size-full wp-image-9292" srcset="https://kofler.info/wp-content/uploads/framework-fan-4.jpeg 1280w, https://kofler.info/wp-content/uploads/framework-fan-4-850x478.jpeg 850w, https://kofler.info/wp-content/uploads/framework-fan-4-768x432.jpeg 768w" sizes="(max-width: 1280px) 100vw, 1280px" /> Anschluss des externen Lüfters (rechts im Bild, »Sys Fan 2«) Anschließend habe ich ein 10-cm-Verlängerskabel für den Lüfter nach außen geleitet und den eigentlichen Lüfter dort angeschlossen. Die Lüftermontage habe ich mit einer festen Plastikfolie (ausgeschnitten aus der Rückseite eines Schnellhefters) und viel Klebeband so bewerkstelligt, dass zwischen Gehäuse und Lüfter ein Luftkanal von ca. 1 cm entsteht. Wichtig: Der Lüfter muss so montiert werden, dass er die Luft aus dem Netzteil nach außen saugt/bläst. <img decoding="async" src="https://kofler.info/wp-content/uploads/framework-fan-2.jpeg" alt="" width="1146" height="1280" class="size-full wp-image-9290" srcset="https://kofler.info/wp-content/uploads/framework-fan-2.jpeg 1146w, https://kofler.info/wp-content/uploads/framework-fan-2-582x650.jpeg 582w, https://kofler.info/wp-content/uploads/framework-fan-2-860x960.jpeg 860w, https://kofler.info/wp-content/uploads/framework-fan-2-768x858.jpeg 768w" sizes="(max-width: 1146px) 100vw, 1146px" /> Zweiter Versuch mit 12-V-Lüfter, der als »System Fan 2« über das BIOS gesteuert wird <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-fan-6.jpeg" alt="" width="1280" height="904" class="size-full wp-image-9294" srcset="https://kofler.info/wp-content/uploads/framework-fan-6.jpeg 1280w, https://kofler.info/wp-content/uploads/framework-fan-6-850x600.jpeg 850w, https://kofler.info/wp-content/uploads/framework-fan-6-768x542.jpeg 768w" sizes="auto, (max-width: 1280px) 100vw, 1280px" /> Aus der Rückseite eines Schnellhefters habe ich einen Kanal für den externen Lüfter gebastelt Zuletzt habe ich das gesamte Gehäuse mit ein paar Filzgleitern höher gestellt, so dass ein Wärmetransport von der Unterseite des Gehäuses möglich ist. Ich vermute, dass diese Maßnahme nur im CPU-intensiven Dauerbetrieb relevant ist. Solange der Framework Desktop nur gelegentlich unter Last läuft, wird die Unterseite nicht besonders warm. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-fan-3.jpeg" alt="" width="696" height="1280" class="size-full wp-image-9291" srcset="https://kofler.info/wp-content/uploads/framework-fan-3.jpeg 696w, https://kofler.info/wp-content/uploads/framework-fan-3-353x650.jpeg 353w, https://kofler.info/wp-content/uploads/framework-fan-3-522x960.jpeg 522w" sizes="auto, (max-width: 696px) 100vw, 696px" /> Filzgleiter erhöhen den Bodenabstand Bleibt noch die Lüftersteuerung: Beim CPU-Lüfter habe ich CPU Fan min duty % auf 25 Prozent eingestellt. Der Lüfter dreht dann so langsam, dass ich ihn nicht höre, sorgt aber dennoch für einen steten Luftzug durch das Gehäuse. Erst unter Last dreht der CPU-Lüfter stärker auf und wird hörbar. Der externe Lüfter wird im BIOS über Chassis Fan 2 gesteuert. Ich habe Chassis 2 Fan min duty % auf 30 Prozent gestellt. Wiederum war das Ziel, einen Wert zu wählen, der für mich unterhalb der Hör/Störschwelle ist, aber gleichzeitig für eine dauerhafte Durchlüftung des engen Netzteilkanals zu sorgen. Als Fan Sensor habe ich Mainboard Power eingestellt, aber vermutlich würde jeder andere Temperatursensor ebenso gut funktionieren. Das Netzteil hat keinen eigenen Sensor. Auf jeden Fall ist es sinnvoll, das Netzteil intensiver zu kühlen, wenn die CPU unter Last heiß wird. Naturgemäß sind meine Einstellungen persönliche Erfahrungswerte, abhängig vom eingesetzten Lüfter (ich habe den Noctua NF-A6x25 PWM verwendet, amazon-Link), vom Nutzungsverhalten und vom Aufstellungsort. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-fan-5.jpeg" alt="" width="1280" height="803" class="size-full wp-image-9293" srcset="https://kofler.info/wp-content/uploads/framework-fan-5.jpeg 1280w, https://kofler.info/wp-content/uploads/framework-fan-5-850x533.jpeg 850w, https://kofler.info/wp-content/uploads/framework-fan-5-768x482.jpeg 768w" sizes="auto, (max-width: 1280px) 100vw, 1280px" /> BIOS/EFI-Einstellungen für den »System Fan 2« Ergebnis Ich bin zufrieden. Im normalen Desktopbetrieb ist der Rechner jetzt (für meine Ohren) lautlos. Wenn ich den Kernel kompiliere oder Sprachmodelle ausführe, die CPU also unter Volllast arbeitet, drehen die beiden Lüfter (CPU-Lüfter intern, mein Netzteil-Lüfter extern) langsam hoch und sind deutlich hörbar, aber auf jeden Fall in einer viel angenehmeren Tonlage als bisher. Den internen PSU-Kühler mit seiner extrem unangenehmen Geräuschkulisse habe ich seit der Inbetriebnahme des externen Lüfters nie mehr gehört. Der außen befestigte Lüfter ist zugegebenermaßen ein hässlicher Hack für ein 2000-€-Gerät. Bei normalen Aufstellung des Rechners am oder unter dem Schreibtisch stört die Konstruktion aber nicht. Mir ist auf jeden Fall die Akustik wichtiger als die Optik. Für einen vollständig lautlosen Betrieb müsste das Framework-Mainboard in ein größeres Gehäuse gebaut und mit einem effizienteren, größeren Netzteil versorgt werden. Dazu habe ich keine Zeit/Lust/Geld. Die hier präsentierte Lösung verursacht weniger als 20 € Kosten und lässt sich in einer Stunde bewerkstelligen. Quellen/Links https://kofler.info/framework-desktop https://community.frame.work/t/exterior-fan-to-solve-the-noisy-psu-fan-problem/76398/37 https://community.frame.work/t/noisy-psu-fan/74751/493 https://www.phoronix.com/review/framework-desktop-power
Beim Experimentieren mit KI-Sprachmodellen bin ich über das Projekt »Toolbx« gestolpert. Damit können Sie unkompliziert gekapselte Software-Umgebungen erzeugen und ausführen. Toolbx hat große Ähnlichkeiten mit Container-Tools und nutzt deren Infrastruktur, unter Fedora die von Podman. Es gibt aber einen grundlegenden Unterschied zwischen Docker/Podman auf der einen und Toolbx auf der anderen Seite: Docker, Podman & … Toolbx weiterlesen →
Beim Experimentieren mit KI-Sprachmodellen bin ich über das Projekt »Toolbx« gestolpert. Damit können Sie unkompliziert gekapselte Software-Umgebungen erzeugen und ausführen. Toolbx hat große Ähnlichkeiten mit Container-Tools und nutzt deren Infrastruktur, unter Fedora die von Podman. Es gibt aber einen grundlegenden Unterschied zwischen Docker/Podman auf der einen und Toolbx auf der anderen Seite: Docker, Podman & Co. versuchen die ausgeführten Container sicherheitstechnisch möglichst gut vom Host-System zu isolieren. Genau das macht Toolbx nicht! Im Gegenteil, per Toolbx ausgeführte Programme können auf das Heimatverzeichnis des aktiven Benutzers sowie auf das /dev-Verzeichnis zugreifen, Wayland nutzen, Netzwerkschnittstellen bedienen, im Journal protokollieren, die GPU nutzen usw. Toolbx wurde ursprünglich als Werkzeug zur Software-Installation in Distributionen auf der Basis von OSTree konzipiert (Fedora CoreOS, Siverblue etc.). Dieser Artikel soll als eine Art Crash-Kurs dienen, wobei ich mit explizit auf Fedora als Host-Betriebssystem beziehe. Grundwissen zu Podman/Docker setze ich voraus. Mehr Details gibt die Projektdokumentation. Beachten Sie, dass die offizielle Bezeichnung des Projekts »Toolbx« ohne »o« in »box« lautet, auch wenn das zentrale Kommando toolbox heißt und wenn die damit erzeugten Umgebungen üblicherweise Toolboxes genannt werden. Hello, Toolbx! Das Kommando toolbox aus dem gleichnamigen Paket wird ohne sudo ausgeführt. In der Minimalvariante erzeugen Sie mit toolbox <name> eine neue Toolbox, die als Basis ein Image Ihrer Host-Distribution verwendet. Wenn Sie also wie ich in diesen Beispielen unter Fedora arbeiten, fragt toolbox beim ersten Aufruf, ob es die Fedora-Toolbox herunterladen soll: toolbox create test1 Image required to create Toolbx container. Download registry.fedoraproject.org/fedora-toolbox:43 (356.7MB)? [y/N]: y Created container: test1 Wenn Sie als Basis eine andere Distribution verwenden möchten, geben Sie den Distributionsnamen und die Versionsnummer in zwei Optionen an: toolbox create --distro rhel --release 9.7 rhel97 Das Kommando toolbox list gibt einen Überblick, welche Images Sie heruntergeladen haben und welche Toolboxes (in der Podman/Docker-Nomenklatur: welche Container) Sie erzeugt haben: toolbox list IMAGE ID IMAGE NAME CREATED f06fdd638830 registry.access.redhat.com/ubi9/toolbox:9.7 3 days ago b1cc6a02cef9 registry.fedoraproject.org/fedora-toolbox:43 About an hour ago CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME 695e17331b4a llama-vulkan-radv 2 days ago exited docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv dc8fd94977a0 rhel97 22 seconds ago created registry.access.redhat.com/ubi9/toolbox:9.7 dd7d51c65852 test1 18 minutes ago created registry.fedoraproject.org/fedora-toolbox:43 Um eine Toolbox aktiv zu nutzen, aktivieren Sie diese mit toolbox enter. Damit starten Sie im Terminal eine neue Session. Sie erkennen nur am veränderten Prompt, dass Sie sich nun in einer anderen Umgebung befinden. Sie haben weiterhin vollen Zugriff auf Ihr Heimatverzeichnis; die restlichen Verzeichnisse stammen aber überwiegend von Toolbox-Container. Hinter den Kulissen setzt sich der in der Toolbox sichtbare Verzeichnisbaum aus einer vollkommen unübersichtlichen Ansammlung von Dateisystem-Mounts zusammen. findmnt liefert eine über 350 Zeilen lange Auflistung! toolbox enter test1 [kofler@toolbx ~]$ cat /etc/os-release NAME="Fedora Linux" VERSION="43 (Toolbx Container Image)" RELEASE_TYPE=stable ID=fedora VERSION_ID=43 ... [kofler@toolbx ~]$ findmnt | wc -l 359 Innerhalb einer Fedora-Toolbox können Sie wie üblich mit rpm und dnf Pakete verwalten. Standardmäßig ist nur ein relativ kleines Subset an Paketen installiert. [kofler@toolbx ~]$ rpm -qa | wc -l 340 Innerhalb der Toolbox können Sie mit sudo administrative Aufgaben erledigen, z.B. sudo dnf install <pname>. Dabei ist kein Passwort erforderlich. ps ax listet alle Prozesse auf, sowohl die der Toolbox als auch alle anderen des Hostsystems! Mit exit oder Strg+D verlassen Sie die Toolbox. Sie können Sie später mit toolbox enter <name> wieder reaktivieren. Alle zuvor durchgeführten Änderungen gelten weiterhin. (Hinter den Kulissen verwendet das Toolbx-Projekt einen Podman-Container und speichert Toolbox-lokalen Änderungen in einem Overlay-Dateisystem.) Bei ersten Experimenten mit Toolbx ist mitunter schwer nachzuvollziehen, welche Dateien/Einstellungen Toolbox-lokal sind und welche vom Host übernommen werden. Beispielsweise ist /etc/passwd eine Toolbox-lokale Datei. Allerdings wurden beim Erzeugen dieser Datei die Einstellungen Ihres lokalen Accounts von der Host-weiten Datei /etc/passwd übernommen. Wenn Sie also auf Host-Ebene Fish als Shell verwenden, ist /bin/fish auch in der Toolbox-lokalen passwd-Datei enthalten. Das ist insofern problematisch, als im Standard-Image für Fedora und RHEL zwar die Bash enthalten ist, nicht aber die Fish. In diesem Fall erscheint beim Start der Toolbox eine Fehlermeldung, die Bash wird als Fallback verwendet: toolbox enter test1 bash: Zeile 1: /bin/fish: Datei oder Verzeichnis nicht gefunden Error: command /bin/fish not found in container test1 Using /bin/bash instead. Es spricht aber natürlich nichts dagegen, die Fish zu installieren: [kofler@toolbx ~]$ sudo dnf install fish Auf Host-Ebene liefern die Kommandos podman ps -a und podman images sowohl herkömmliche Podman-Container und -Images als auch Toolboxes. Aus Podman-Sicht gibt es keinen Unterschied. Der Unterschied zwischen einem Podman-Container und einer Toolbox ergibt sich erst durch die Ausführung (bei Podman mit sehr strenger Isolierung zwischen Container und Host, bei Toolbox hingegen ohne diese Isolierung). Eigene Toolboxes erzeugen Eigene Toolboxes richten Sie ein wie eigene Podman-Images. Die Ausgangsbasis ist ein Containerfile, das die gleiche Syntax wie ein Dockerfile hat: # Datei my-directory/Containerfile FROM registry.fedoraproject.org/fedora-toolbox:43 # Add metadata labels ARG NAME=my-toolbox ARG VERSION=43 LABEL com.github.containers.toolbox="true" \ name="$NAME" \ version="$VERSION" \ usage="This image is meant to be used with the toolbox(1) command" \ summary="Custom Fedora Toolbx with joe and fish" # Install your software RUN dnf --assumeyes install \ fish \ joe # Clean up RUN dnf clean all Mit podman build erzeugen Sie das entsprechende lokale Image: cd my-directory podman build --squash --tag localhost/my-dev-toolbox:43 . Jetzt können Sie auf dieser Basis eine eigene Toolbox einrichten: toolbox create --image localhost/my-toolbox:43 test2 toolbox enter test2 KI-Sprachmodelle mit Toolbx ausführen Das Toolbx-Projekt bietet eine großartige Basis, um GPU-Bibliotheken und KI-Programme auszuprobieren, ohne die erforderlichen Bibliotheken auf Systemebene zu installieren. Eine ganze Sammlung von KI-Toolboxes zum Test diverser Software-Umgebungen für llama.cpp finden Sie auf GitHub, beispielsweise hier: https://github.com/kyuz0/amd-strix-halo-toolboxes toolbox create erzeugt eine Toolbox mit dem Namen llama-vulkan-radv auf Basis des Images vulkan-radv, das der Entwickler kyuz0 im Docker Hub hinterlegt hat. Das alleinstehende Kürzel -- trennt die toolbox-Optionen von denen für Podman/Docker. Die folgenden drei Optionen sind erforderlich, um der Toolbox direkten Zugriff auf das Device der GPU zu geben. toolbox create llama-vulkan-radv \ --image docker.io/kyuz0/amd-strix-halo-toolboxes:vulkan-radv \ -- --device /dev/dri \ --group-add video \ --security-opt seccomp=unconfined Mit toolbox enter starten Sie die Toolbox. Innerhalb der Toolbox steht das Kommando llama-cli zur Verfügung. In einem ersten Schritt können Sie testen, ob diese Bibliothek zur Ausführung von Sprachmodellen eine GPU findet. toolbox enter llama-vulkan-radv llama-cli --list-devices ggml_vulkan: Found 1 Vulkan devices: ggml_vulkan: 0 = Radeon 8060S Graphics (RADV GFX1151) (radv) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat Available devices: Vulkan0: Radeon 8060S Graphics (RADV GFX1151) (107008 MiB, 99195 MiB free) Wenn Sie auf Ihrem Rechner noch keine Sprachmodelle heruntergeladen haben, finden Sie geeignete Modelle unter https://huggingface.co. Ich habe stattdessen im folgenden Kommando ein Sprachmodell ausgeführt, das ich zuvor in LM Studio heruntergeladen haben. Wie gesagt: In der Toolbox haben Sie vollen Zugriff auf alle Dateien in Ihrem Home-Verzeichnis! llama-server \ -m /home/kofler/.lmstudio/models/lmstudio-community/gpt-oss-20b-GGUF/gpt-oss-20b-MXFP4.gguf \ -c 32000 -ngl 999 -fa 1 --no-mmap Dabei gibt -c die maximale Kontextgröße an. -ngl bestimmt die Anzahl der Layer, die von der GPU verarbeitet werden sollen (alle). -fa 1 aktiviert Flash Attention. Das ist eine Grundvoraussetzung für eine effiziente Ausführung moderner Modelle. --no-mmap bewirkt, dass das ganze Modell zuerst in den Arbeitsspeicher geladen wird. (Die Alternative wären ein Memory-Mapping der Datei.) Der Server kann auf der Adresse localhost:8080 über eine Weboberfläche bedient werden. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/toolbx-llama-cpp.png" alt="" width="1920" height="1447" class="size-full wp-image-9280" srcset="https://kofler.info/wp-content/uploads/toolbx-llama-cpp.png 1920w, https://kofler.info/wp-content/uploads/toolbx-llama-cpp-850x641.png 850w, https://kofler.info/wp-content/uploads/toolbx-llama-cpp-1274x960.png 1274w, https://kofler.info/wp-content/uploads/toolbx-llama-cpp-768x579.png 768w, https://kofler.info/wp-content/uploads/toolbx-llama-cpp-1536x1158.png 1536w" sizes="auto, (max-width: 1920px) 100vw, 1920px" /> Weboberfläche zu llama.cpp. Dieses Programm wird in einer Toolbox ausgeführt. Anstatt erste Experimente in der Weboberfläche durchzuführen, können Sie mit dem folgenden Kommando einen einfachen Benchmarktest ausführen. Die pp-Ergebnisse beziehen sich auf das Prompt Processing, also die Verarbeitung des Prompts zu Input Token. tg bezeichnet die Token Generation, also die Produktion der Antwort. llama-bench \ -m /home/kofler/.lmstudio/.../gpt-oss-20b-MXFP4.gguf \ -ngl 999 -fa 1 model size params ... test t/s gpt-oss 20B MXFP4 MoE 11.27 GiB 20.91 pp512 1219 gpt-oss 20B MXFP4 MoE 11.27 GiB 20.91 tg128 78 Quellen/Links https://containertoolbx.org/doc https://developers.redhat.com/articles/2024/07/16/introducing-toolbx https://github.com/containers/toolbox/blob/main/doc/toolbox-create.1.md https://github.com/kyuz0/amd-strix-halo-toolboxes
Die Kinder bekommen ihre Weihnachtsgeschenke am 24.12., bei mir war diesmal zufällig schon eine Woche vorher Bescherung. Direkt von Taiwan versendet traf gestern ein Framework Desktop ein (Batch 17). Wobei von »Geschenk« keine Rede ist, ich habe den Rechner ganz regulär bestellt und bezahlt. Über das Preis/Leistungs-Verhältnis darf man gar nicht nachdenken … Aber für … Framework Desktop weiterlesen →
Die Kinder bekommen ihre Weihnachtsgeschenke am 24.12., bei mir war diesmal zufällig schon eine Woche vorher Bescherung. Direkt von Taiwan versendet traf gestern ein Framework Desktop ein (Batch 17). Wobei von »Geschenk« keine Rede ist, ich habe den Rechner ganz regulär bestellt und bezahlt. Über das Preis/Leistungs-Verhältnis darf man gar nicht nachdenken … Aber für die Überarbeitung des Buchs Coding mit KI will ich nun mal moderat große Sprachmodelle (z.B. gpt-oss-120b) selbst lokal ausführen. Dieser Blog-Beitrag fasst meine ersten Eindrücke zusammen. In den nächsten Wochen werden wohl noch ein paar Artikel rund um Ollama und llama.cpp folgen. Framework Desktop Auswahl Ich war auf der Suche nach einem Rechner mit 128 GByte RAM, das von der GPU genutzt werden kann. Dafür gibt es aktuell drei Plattformen (Intel glänzt durch Abwesenheit): AMD Ryzen AI Max+ 395 (»Strix Halo«): Dieser Prozessor kombiniert 16 Zen-5-CPU-Cores und 40 GPU-Cores (Radeon 8060S). Die Speicherbandbreite (LPDDR5X) beträgt bis zu 250 GiB/s. Desktop-PCs mit 2 TB SSD kosten zwischen 2.000 und 3.000 €, Notebooks ca. 4.000 €. Apple Max CPUs: Der Prozessor M4 Max vereint 16 CPU-Cores mit 40 GPU-Cores. Die Speicherbandbreite erreicht beeindruckende 550 GiB/s. Ein entsprechender Mac Studio mit 2 TB SSD kostet ca. 5000 €, ein MacBook mit vergleichbarer Ausstattung ca. 6000 €. NVIDIA DGX Spark: Diese Plattform besteht aus einer 20-Core ARM-CPU plus NVIDIA Blackwell GPU mit 48 Compute Units. Wegen des LPDDR5X-RAMs ist die Speicherbandbreite wie bei Strix Halo auf ca. 250 GiB/s limitiert. Komplettsysteme kosten ca. 4000 € (Asus, Dell, NVIDIA). Was die Rechenleistung betrifft, spielen alle drei Plattformen in der gleichen Liga, vielleicht mit kleinen Vorteilen bei Apple, vor allem was Effizienz und Lautstärke betrifft. Gegen die NVIDIA-Lösung spricht, dass diese Rechner dezidiert für KI-Aufgaben gedacht sind; eine »normale« Desktop-Nutzung ist nur mit großen Einschränkungen möglich. Generell darf man sich von der KI-Geschwindigkeit der aufgezählten Geräten keine Wunder erwarten: GPU-Leistung und Speicherbandbreite sind nur mittelprächtig. Praktisch jede dezidierte Grafikkarte kann kleine Sprachmodelle schneller ausführen — aber nur, solange das Sprachmodell komplett im dezidierten VRAM Platz hat. (Bei Desktop-PCs können Sie mehrere Grafikkarten einbauen und kombinieren, aber das ist teuer und kostet viel Strom.) Die oben aufgezählten CPUs mit integrierter GPU können dagegen das gesamten RAM nutzen. Das ist langsamer als bei dezidierten GPUs, aber es macht immerhin die Ausführung von relativ großen Modellen möglich. Apple ist wie üblich bei vergleichbarer Ausstattung am teuersten. Umgekehrt muss man anerkennen, dass von allen hier aufgezählten Geräten ein Mac Studio vermutlich der einzige Computer ist, der in drei Jahren noch einen nennenswerten Wiederverkaufswert hat. Am anderen Ende des Preisspektrums befindet sich die AMD-Variante. Es gibt diverse chinesische Mini-PCs mit der AMD-395-CPU: z.B. Bosgame (aktuell am billigsten), GMKtec EVO-X2, Beelink GTR9 (instabil, Probleme mit Intel-Netzwerkadapter) und Minisforum MS-S1 MAX. HP bietet den Z2 Mini G1a zu einem relativ vernünftigen Preis an, aber das Gerät ist anscheinend sehr laut. Schließlich gibt es den Framework Desktop, der ansprechend aussieht, in Tests gut abgeschnitten hat und die beste/leiseste Kühlung hat (leider ein Irrtum, siehe unten). Ich habe mich nach wochenlanger Recherche für das Framework-Angebot entschieden. Das Konzept der Framework-Geräte ist sympathisch. Außerdem gibt es eine große Community rund um das Gerät. Zum Zeitpunkt der Bestellung kostete der Rechner mit 128 GByte RAM, ein paar Adaptern, Kacheln und Lüfter knapp 2.500 € (inkl. USt). Eine SSD habe ich anderswo besorgt. Lieferung Der Rechner wurde am 12.12. von Taiwan versendet und kam sechs Tage später bei mir an. Faszinierend. (Ich habe noch nie bei Temu & Co. bestellt, habe diesbezüglich auch keine Ambitionen. Insofern war die Verfolgung des Pakets rund um die halbe Welt für mich Neuland.) In sechs Tagen um die halbe Welt. Ökologisch ein Alptraum, logistisch ein Wunder. Bis zum Schluss wusste ich nicht, ob nun Zoll zu zahlen ist oder nicht. Offenbar nicht. Ich kann nicht sagen, ob sich Framework bei EU-Lieferungen um die ganze Abwicklung kümmert oder ob es Zufall/Glück war. (Das Gerät ist weiß Gott auch ohne Zoll teuer genug …) Der Zusammenbau ist unkompliziert und gelingt in einer halben Stunde. Ich habe dann Fedora 43 installiert (weitere zehn Minuten). Alles funktionierte auf Anhieb, das Gerät lief die erste halbe Stunde praktisch lautlos. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-2.jpeg" alt="" width="1379" height="1080" class="size-full wp-image-9239" srcset="https://kofler.info/wp-content/uploads/framework-2.jpeg 1379w, https://kofler.info/wp-content/uploads/framework-2-830x650.jpeg 830w, https://kofler.info/wp-content/uploads/framework-2-1226x960.jpeg 1226w, https://kofler.info/wp-content/uploads/framework-2-768x601.jpeg 768w" sizes="auto, (max-width: 1379px) 100vw, 1379px" /> Der Framework Desktop wird als Bastel-Set geliefert <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-gnome.png" alt="" width="1914" height="1526" class="size-full wp-image-9254" srcset="https://kofler.info/wp-content/uploads/framework-gnome.png 1914w, https://kofler.info/wp-content/uploads/framework-gnome-815x650.png 815w, https://kofler.info/wp-content/uploads/framework-gnome-1204x960.png 1204w, https://kofler.info/wp-content/uploads/framework-gnome-768x612.png 768w, https://kofler.info/wp-content/uploads/framework-gnome-1536x1225.png 1536w" sizes="auto, (max-width: 1914px) 100vw, 1914px" /> Systemzusammenfassung von Gnome Benchmark-Tests Ich habe mich nicht lange mit Benchmark-Tests aufgehalten. BIOS in Grundzustand, Fedora 43 mit Gnome im Energiemodus Ausgeglichen. Geekbench lieferte 2790 Single / 20.700 Multi-Core Kernel kompilieren (Version 6.18.1): 9:08 Minuten <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/kernel.png" alt="" width="2192" height="2024" class="size-full wp-image-9255" srcset="https://kofler.info/wp-content/uploads/kernel.png 2192w, https://kofler.info/wp-content/uploads/kernel-704x650.png 704w, https://kofler.info/wp-content/uploads/kernel-1040x960.png 1040w, https://kofler.info/wp-content/uploads/kernel-768x709.png 768w, https://kofler.info/wp-content/uploads/kernel-1536x1418.png 1536w, https://kofler.info/wp-content/uploads/kernel-2048x1891.png 2048w" sizes="auto, (max-width: 2192px) 100vw, 2192px" /> Systemüberwachung während der Kernel kompiliert wird BIOS F2 bzw. je nach Tastatur Fn+F2 führt in die BIOS/EFI-Einstellungen. Dort gibt es eine Menge Optionen zur Steuerung des CPU-Lüfters. Der GPU kann ein fixer Speicher (bis zu 96 GiB) zugewiesen werden. Für die meisten Anwendungen ist das aber nicht sinnvoll. Viele Bibliotheken sind in der Lage, den GPU-Speicher dynamisch anzufordern. Insofern ist es zweckmäßig, den fix reservierten GPU-Speicher möglichst klein einzustellen. Es gibt keine Optionen, die die CPU/GPU-Leistung beeinflussen. Achtung: Es gibt ein BIOS-Update von Version 0.03.03 auf 0.03.04. Gnome Software bietet das Update zur Installation an. Allerdings bereitet die neue BIOS-Version Probleme und verlangsamt den Boot-Prozess massiv. Das Update sollte daher nicht installiert werden! <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-bios.jpeg" alt="" width="1160" height="829" class="size-full wp-image-9246" srcset="https://kofler.info/wp-content/uploads/framework-bios.jpeg 1160w, https://kofler.info/wp-content/uploads/framework-bios-850x607.jpeg 850w, https://kofler.info/wp-content/uploads/framework-bios-768x549.jpeg 768w" sizes="auto, (max-width: 1160px) 100vw, 1160px" /> Mit F2 gelangen Sie in die BIOS-Einstellungen Stromverbrauch Ich habe den Stromverbrauch am Netzstecker mit einem uralten Haushalts-Strommessgerät gemessen. Dessen Genauigkeit ist sicher nicht großartig, aber die Größenordnung meiner Messwerte klingt plausibel: Demnach beträgt die Leistungsaufnahme im Ruhezustand ca. 12 bis 13 Watt (wieder: Fedora mit Gnome Desktop, Energie-Modus ausgeglichen, keine rechenintensiven Vorgänge, BIOS im Grundzustand). Beim Kompilieren des Kernels steigt die Leistung kurz auf 160 Watt und pendelt sich dann ziemlich stabil rund um 140 Watt ein. Geräuschentwicklung Der Rechner hat zwei Lüfter: einen großen für die CPU (kann beim Bestellprozess konfiguriert werden, ich habe mich für das etwas teurere Noctua-Modell entschieden) und einen kleinen, der unsichtbar aber unüberhörbar im Netzteil am Boden des Rechners eingebaut ist. Der CPU-Lüfter läuft standardmäßig nur unter Last und produziert dann ein gut erträgliches Geräusch (mehr Brummen als Surren). Die Steuerung des CPU-Lüfters kann im BIOS verändert werden. Ich habe probeweise einen Dauerbetrieb mit 25 % eingestellt. Der Lüfter bleibt dann für meine Ohren bei knapp einem Meter Abstand immer noch lautlos, sorgt aber für eine stetige leichte Kühlung. Das Problem ist das äußerst schmale Netzteil, das sich im unteren Teil des Gehäuses befindet. Framework ist auf das Netzteil ziemlich stolz, aber viele Desktop-Besitzer können diese Begeisterung nicht teilen. Ein schier endloser Forum-Thread dokumentiert den Frust über das Netzteil. Im Prinzip ist es einfach: Das Netzteil ist komplett gekapselt. Der große CPU-Lüfter kann es daher nicht kühlen. Die Luftzufuhr wird durch eine enge Röhre und das Gitter des Gehäuses enorm behindert. Das Netzteil ist mit 80 Plus Silver nur mäßig effizient, was sich vermutlich im Leerlaufbetrieb besonders stark auswirkt. Im Netzteil steht die Luft. Dieses wird durch die Abwärme immer heißer. Ca. 1/2 h nach dem Einschalten wird eine kritische Temperatur erreicht. Nun startet unvermittelt der winzige Lüfter. Eine halbe Minute reicht, um das Netzteil mit frischer Luft etwas abzukühlen — aber nach ca. 10 Minuten beginnt das Spiel von neuem. (Unter Last läuft natürlich auch der Netzteillüfter häufiger.) Das Geräusch des Netzteil-Lüfters ist leider wesentlich unangenehmer als das des CPU-Lüfters. Der kleine Lüfter hat eine unangenehme Frequenz, und das regelmäßige Ein/Aus stört. Eine BIOS-Steuerung ist nicht vorgesehen. Vermutlich wäre es gescheiter, den Netzteil-Lüfter ständig bei niedriger Frequenz laufen zu lassen, um ohne viel Lärm einen andauernden Luftaustausch zu gewährleisten. Aber diese Möglichkeit besteht nicht. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-luefter.jpg" alt="" width="2038" height="2086" class="size-full wp-image-9244" srcset="https://kofler.info/wp-content/uploads/framework-luefter.jpg 2038w, https://kofler.info/wp-content/uploads/framework-luefter-635x650.jpg 635w, https://kofler.info/wp-content/uploads/framework-luefter-938x960.jpg 938w, https://kofler.info/wp-content/uploads/framework-luefter-768x786.jpg 768w, https://kofler.info/wp-content/uploads/framework-luefter-1501x1536.jpg 1501w, https://kofler.info/wp-content/uploads/framework-luefter-2001x2048.jpg 2001w" sizes="auto, (max-width: 2038px) 100vw, 2038px" /> Blick in das Innenleben. Der große Lüfter kühlt die CPU. Das Netzteil ist ganz unten und hat einen weiteren, nicht sichtbaren Lüfter <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/framework-abdeckung.jpg" alt="" width="1660" height="1747" class="size-full wp-image-9243" srcset="https://kofler.info/wp-content/uploads/framework-abdeckung.jpg 1660w, https://kofler.info/wp-content/uploads/framework-abdeckung-618x650.jpg 618w, https://kofler.info/wp-content/uploads/framework-abdeckung-912x960.jpg 912w, https://kofler.info/wp-content/uploads/framework-abdeckung-768x808.jpg 768w, https://kofler.info/wp-content/uploads/framework-abdeckung-1460x1536.jpg 1460w" sizes="auto, (max-width: 1660px) 100vw, 1660px" /> Die Luftzufuhr wird durch die Abdeckung weiter behindert Um es klar zu stellen: Selbst wenn der Netzteillüfter läuft, ist das Gerät nicht wirklich laut — und vermutlich immer noch leiser als Konkurrenzprodukte (die ich aber nicht ausprobiert habe). Und dass der Computer unter Last nicht lautlos ist, war sowieso zu erwarten. Ärgerlich ist, dass das Gerät trotz seines ausgezeichneten CPU-Kühler-Designs im Leerlauf bzw. bei geringer Belastung nicht leiser ist. Technisch wäre das möglich. Da wurde rund um das Netzteil viel Potenzial verschenkt. Fazit Der Framework Desktop wurde offensichtlich mit viel Liebe zum Detail entwickelt. Der Rechner ist optisch ansprechend und liegt preislich im Vergleich zu seinen Konkurrenzprodukten im Mittelfeld. (Generell ist leider zu befürchten, dass die Preise von Computern in den nächsten Monaten steigen werden, weil sowohl RAM als auch SSDs fast täglich teurer werden.) Die CPU-Kühlung ist vermutlich die beste aller aktuellen Strix-Halo-Angebote. Bei meinen bisherigen Tests lief der Rechner absolut stabil. Extrem schade, dass das Netzteil so ein Murks ist. Wenn das Netzteil intelligenter gekühlt würde, wäre im Leerlauf bzw. bei moderater Nutzung ein weitgehend lautloser Betrieb möglich. Stattdessen nervt das Gerät mit einem hochfrequenten Gesurre, das alle paar Minuten startet und eine halbe Minute später wieder aufhört. Ärgerlich! Quellen/Links https://frame.work/at/de/desktop https://guides.frame.work/Guide/Framework+Desktop+(AMD+Ryzen+AI+Max+300+Series)+DIY+Edition+%E2%80%93+Kurzanleitung/464 https://community.frame.work/c/desktop/203 https://community.frame.work/t/fedora-43-slow-to-boot-update-because-of-system-firmware-3-04/78930 Netzteil https://frame.work/at/de/products/desktop-power-supply-400w https://frame.work/at/de/blog/framework-desktop-deep-dive-power-supply https://community.frame.work/t/noisy-psu-fan/74751/493 https://community.frame.work/t/exterior-fan-to-solve-the-noisy-psu-fan-problem/76398/37 Andere Geräte https://www.bosgamepc.com/products/bosgame-m5-ai-mini-desktop-ryzen-ai-max-395 https://www.notebookcheck.com/Bester-Mini-PC-des-Jahres-AMD-Strix-Halo-128-GB-RAM-Radeon-RX-8060S-im-Bosgame-M5-getestet.1084304.0.html https://www.bee-link.com/de/products/beelink-gtr9-pro-amd-ryzen-ai-max-395 https://craigwilson.blog/post/2025/2025-09-25-beelink395bsod/ (Bee Link Netzwerkprobleme) https://www.notebookcheck.com/HP-Z2-Mini-G1a-mit-AMD-Strix-Halo-im-Test-Kompakte-Workstation-mit-Ryzen-AI-Max-und-Radeon-RX-8060S.1059460.0.html https://minisforumpc.eu/de/products/minisforum-ms-s1-max-mini-pc https://www.heise.de/bestenlisten/testbericht/minisforum-ms-s1-max-mit-ryzen-ai-max-395-einer-der-staerksten-mini-pcs-im-test/6n5m46y
COSMIC, der komplett neue Desktop der Firma system76 ist fertig! COSMIC ist integraler Teil von Pop!_OS. Diese ebenfalls von system76 entwickelte Distribution basiert auf Ubuntu, zeichnet sich aber durch viele Eigenheiten ab. Weil ich mir COSMIC ansehen wollte, habe ich die aktuelle Version von Pop!_OS auf meinen MiniPC installiert. Dieser Artikel fasst ganz kurz meine … Pop!_OS 24.04 mit COSMIC weiterlesen →
COSMIC, der komplett neue Desktop der Firma system76 ist fertig! COSMIC ist integraler Teil von Pop!_OS. Diese ebenfalls von system76 entwickelte Distribution basiert auf Ubuntu, zeichnet sich aber durch viele Eigenheiten ab. Weil ich mir COSMIC ansehen wollte, habe ich die aktuelle Version von Pop!_OS auf meinen MiniPC installiert. Dieser Artikel fasst ganz kurz meine Beobachtungen zusammen. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/cosmic-desktop.png" alt="" width="1920" height="1080" class="size-full wp-image-9222" srcset="https://kofler.info/wp-content/uploads/cosmic-desktop.png 1920w, https://kofler.info/wp-content/uploads/cosmic-desktop-850x478.png 850w, https://kofler.info/wp-content/uploads/cosmic-desktop-1280x720.png 1280w, https://kofler.info/wp-content/uploads/cosmic-desktop-768x432.png 768w, https://kofler.info/wp-content/uploads/cosmic-desktop-1536x864.png 1536w" sizes="auto, (max-width: 1920px) 100vw, 1920px" /> Der COSMIC-Desktop im Light Mode und mit Dock auf der linken Seite Installation Die Installation erfolgt aus einem Live-System. Der einzig spannende Punkt ist die Partitionierung der SSD. Sofern Sie sich für die manuelle Partitionierung entscheiden, zeigt das Installationsprogramm einen Überblick über die vorhandenen Disks und Partitionen aus. Sie können nun die Partitionen, die Sie einbinden (EFI) oder mit einem Dateisystem ausstatten möchten (zumindest die Systempartition) per Maus aktivieren. Wenn Sie die Partitionierung verändern wollen (Modify Partitions), startet das Installationsprogramm einfach das Programm gparted. Das ist ein pragmatischer Ansatz, mit dem fortgeschrittene Benutzer ans Ziel kommen. Wer verschlüsselte LVM-Setups will, muss selbst Hand anlegen und die erforderlichen Schritte vorweg selbst erledigen. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/pop-install.png" alt="" width="950" height="700" class="size-full wp-image-9212" srcset="https://kofler.info/wp-content/uploads/pop-install.png 950w, https://kofler.info/wp-content/uploads/pop-install-850x626.png 850w, https://kofler.info/wp-content/uploads/pop-install-768x566.png 768w" sizes="auto, (max-width: 950px) 100vw, 950px" /> Auswahl der aktiven Partitionen COSMIC Desktop Der COSMIC Desktop besteht aus dem Fenstermanager/Compositor mit den üblichen Desktop-Elementen (Panel, Dock) sowie einigen COSMIC-spezifischen Programmen: Dateimanager, Terminal, Systemeinstellungen, Paketverwaltung, Texteditor und Media-Player. Bei den sonstigen Programmen greift COSMIC auf die üblichen Linux- (Firefox, Thunderbird, LibreOffice, Gimp) oder Gnome-Apps zurück (Systemüberwachung, Laufwerke). Bei der Fensterverwaltung unterscheidet COSMIC zwischen dem Standardmodus, der im Prinzip wie unter Gnome oder KDE funktioniert, und einem Tiling-Modus mit halbautomatischer Fensteranordnung, wobei stets alle Fenster sichtbar sind. Zwischen den beiden Modi kann über ein Icon im Panel oder mit Super+Y gewechselt werden. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/cosmic-tiling-scaled.png" alt="" width="2560" height="1440" class="size-full wp-image-9224" srcset="https://kofler.info/wp-content/uploads/cosmic-tiling-scaled.png 2560w, https://kofler.info/wp-content/uploads/cosmic-tiling-850x478.png 850w, https://kofler.info/wp-content/uploads/cosmic-tiling-1280x720.png 1280w, https://kofler.info/wp-content/uploads/cosmic-tiling-768x432.png 768w, https://kofler.info/wp-content/uploads/cosmic-tiling-1536x864.png 1536w, https://kofler.info/wp-content/uploads/cosmic-tiling-2048x1152.png 2048w" sizes="auto, (max-width: 2560px) 100vw, 2560px" /> Im Tiling-Modus werden alle Fenster nebeneinander platziert. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/cosmic-settings.png" alt="" width="851" height="889" class="size-full wp-image-9225" srcset="https://kofler.info/wp-content/uploads/cosmic-settings.png 851w, https://kofler.info/wp-content/uploads/cosmic-settings-622x650.png 622w, https://kofler.info/wp-content/uploads/cosmic-settings-768x802.png 768w" sizes="auto, (max-width: 851px) 100vw, 851px" /> Die Systemeinstellungen wirken übersichtlicher als bei Gnome oder KDE Die Bedienung ist intuitiv und funktioniert zumeist problemlos. Aber natürlich (Version 1.0!) gibt es noch kleinere Ungereimtheiten. Um ein paar zu nennen: Während sich echte COSMIC-Programme perfekt in den Desktop integrieren, wirken KDE- oder Gnome-Programme ein wenig wie Fremdkörper. Dieses Problem haben natürlich auch andere Desktop-Systeme. Obwohl ich Deutsch als Sprache eingestellt habe, bleibt es im Panel bei Workspaces und Applications, der Dateimanager zeigt das Änderungsdatum der Dateien mit AM/PM an usw. Wiederum: Ähnliche Probleme gibt es auch bei anderen Desktops. Drag&Drop zwischen Dateimanager und Webbrowser funktioniert unzuverlässig. (Diesem Wayland-Problem bin ich in den vergangenen Jahren auch schon oft begegnet, zuletzt aber immer seltener.) Das Erstellen von Screenshots in die Zwischenablage funktioniert unzuverlässig. Beim Verschieben von Icons im Dock hatte ich mehrfach Probleme. Manche Icons werden gar nicht oder mit falschen Symbolen angezeigt (z.B. Google Chrome). Die Tiling-Steuerung erfordert eine längere Eingewöhnung, erlaubt dann aber eine Bedienung weitgehend ohne Maus. Für Tiling- bzw. COSMIC-Einsteiger wäre hier mehr Dokumentation bzw. ein gutes Video hilfreich. Die Kennzeichnung des gerade aktiven Fensters durch einen farbigen Rahmen ist funktionell, aber nicht besonders ästhetisch. Im Dateimanager gibt es keine Funktion, um mehrere Dateien umzubenennen. Letztlich sind das alles Kleinigkeiten. Meine Tests verliefen absturzfrei, ich konnte mit COSMIC gut und stabil arbeiten. Der Desktop hinterließ dabei einen sehr schnellen, flüssigen Eindruck — aber das ist eine eher subjektive Feststellung, die ich nicht durch Benchmark-Tests untermauern kann. Meine Lieblingseinstellungen (Dock links, Light Mode, Maus mit Natural Scrolling, 4k-Monitor mit 150%-Skalierung) habe ich mühelos in den gut organisierten Systemeinstellungen gefunden. Anders als unter Gnome musste ich dazu keine Extensions installieren :-) Paketverwaltung Pop!_OS basiert auf Ubuntu, verwendet aber eigene Paketquellen und weicht nicht nur beim Desktop vom Original ab (z.B. beim Boot-System, siehe unten). Anstelle von Snap-Paketen setzt Pop!_OS auf Flatpaks. Flathub ist per Default eingerichtet, Flatpaks können mühelos aus dem COSMIC Store installiert werden. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/cosmic-store1.png" alt="" width="1011" height="960" class="size-full wp-image-9219" srcset="https://kofler.info/wp-content/uploads/cosmic-store1.png 1011w, https://kofler.info/wp-content/uploads/cosmic-store1-685x650.png 685w, https://kofler.info/wp-content/uploads/cosmic-store1-768x729.png 768w" sizes="auto, (max-width: 1011px) 100vw, 1011px" /> Der COSMIC Store basiert auf Flatpak <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/cosmic-store2.png" alt="" width="1024" height="768" class="size-full wp-image-9220" srcset="https://kofler.info/wp-content/uploads/cosmic-store2.png 1024w, https://kofler.info/wp-content/uploads/cosmic-store2-850x638.png 850w, https://kofler.info/wp-content/uploads/cosmic-store2-768x576.png 768w" sizes="auto, (max-width: 1024px) 100vw, 1024px" /> Installation von VS Code als Flatpak Boot-System Pop!_OS verwendet systemd_boot (nicht GRUB). Die erforderlichen Kernel- und Initrd-Dateien werden direkt in der EFI-Partition gespeichert (Verzeichnis /boot/efi/EFI/Pop-OS-xxx, Platzbedarf ca. 140 MByte). Auf meinem Testrechner erfolgt der Bootvorgang ohne die Anzeige eines Auswahlmenüs blitzschnell. Einige Hintergründe zur Konfiguration inklusive Reparatur-Tipps sind hier in einem Support-Artikel beschrieben. Fazit Für ein 1.0-Release funktioniert COSMIC sehr gut. Dafür muss man system76 einfach Respekt zollen! Einen kompletten Desktop neu zu implementieren (in der Programmiersprache Rust, noch ein Pluspunkt!) — das ist einfach bemerkenswert. system76 hat damit ein Fundament geschaffen, aus dem in den nächsten Jahren ein echter Mainstream-Desktop werden könnte, auf einer Stufe mit Gnome oder KDE. Dessen ungeachtet verspüre ich aktuell keine Versuchung, auf COSMIC umzusteigen. Für meine Zwecke funktioniert Gnome mit ein paar Erweiterungen zufriedenstellend. Auch mit KDE kann ich gut arbeiten. Mein Leidensdruck, einen anderen Desktop zu suchen, ist gering. Meine Linux-Probleme haben selten mit dem Desktop zu tun. Für Linux-Einsteiger betrachte ich weiterhin Gnome als den besten Startpunkt. system76 sieht hingegen primär Entwickler und fortgeschrittene Entwickler als Zielgruppe. Die Rechnung könnte aufgehen, insbesondere für Tiling-Fans. Heute auf Pop!_OS 24.04 umzusteigen wirkt wenig attraktiv — in nur vier Monaten wird es mit Ubuntu 26.04 ein von Grund auf modernisiertes Fundament geben, wenig später vermutlich die entsprechende Pop!_OS-Version 26.04 mit sicher schon etwas verbesserten COSMIC-Paketen. Im Übrigen steht COSMIC als echtes Open-Source-Projekt auf für andere Distributionen zur Verfügung, z.B. in Form des durchaus attraktiven Fedora Spins. Quellen/Links https://system76.com/pop https://system76.com/cosmic https://blog.system76.com/ https://support.system76.com/articles/pop-cosmic-keyboard-shortcuts https://support.system76.com/articles/bootloader https://www.fedoraproject.org/spins/cosmic https://www.youtube.com/watch?v=7JX6xWg5lx4 (langes Interview mit Carl Richell and Jeremy Soller, beide von system76, über Pop!_OS und Cosmic)
Die Docker Engine 29 unter Linux unterstützt erstmals Firewalls auf nftables-Basis. Die Funktion ist explizit noch experimentell, aber wegen der zunehmenden Probleme mit dem veralteten iptables-Backend geht für Docker langfristig kein Weg daran vorbei. Also habe ich mir gedacht, probiere ich das Feature einfach einmal aus. Mein Testkandidat war Fedora 43 (eine reale Installation auf … Docker mit nftables ausprobiert weiterlesen →
Die Docker Engine 29 unter Linux unterstützt erstmals Firewalls auf nftables-Basis. Die Funktion ist explizit noch experimentell, aber wegen der zunehmenden Probleme mit dem veralteten iptables-Backend geht für Docker langfristig kein Weg daran vorbei. Also habe ich mir gedacht, probiere ich das Feature einfach einmal aus. Mein Testkandidat war Fedora 43 (eine reale Installation auf einem x86-Mini-PC sowie eine virtuelle Maschine unter ARM). Inbetriebnahme Das nft-Backend aktivieren Sie mit der folgenden Einstellung in der Datei /etc/docker/daemon.json: { "firewall-backend": "nftables" } Diese Datei existiert normalerweise nicht, muss also erstellt werden. Die Syntax ist hier zusammengefasst. Die Docker-Dokumentation weist darauf hin, dass Sie außerdem IP-Forwarding erlauben müssen. Alternativ können Sie Docker anweisen, auf Forwarding zu verzichten ("ip-forward": false in daemon.json) — aber dann funktionieren grundlegende Netzwerkfunktionen nicht. # Datei /etc/sysctl.d/99-docker.conf net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 sysctl --system aktiviert die Änderungen ohne Reboot. Die Docker-Dokumentation warnt allerdings, dass dieses Forwarding je nach Anwendung zu weitreichend sein und Sicherheitsprobleme verursachen kann. Gegebenenfalls müssen Sie das Forwarding durch weitere Firewall-Regeln wieder einschränken. Die Dokumentation gibt ein Beispiel, um auf Rechnern mit firewalld unerwünschtes Forwarding zwischen eth0 und eth1 zu unterbinden. Alles in allem wirkt der Umgang mit dem Forwarding noch nicht ganz ausgegoren. Praktische Erfahrungen Mit diesen Einstellungen lässt sich die Docker Engine prinzipiell starten (systemctl restart docker, Kontrolle mit docker version oder systemctl status docker). Welches Firewall-Backend zum Einsatz kommt, verrät docker info: docker info | grep 'Firewall Backend' Firewall Backend: nftables+firewalld Ich habe dann ein kleines Compose-Setup bestehend aus MariaDB und WordPress gestartet. Soweit problemlos: docker compose up -d [+] Running 2/2 Container wordpress-sample-wordpress-1 Running 0.0s Container wordpress-sample-db-1 Running 0.0s Attaching to db-1, wordpress-1 docker compose ps NAME IMAGE ... PORTS wordpress-sample-db-1 mariadb:latest 3306/tcp wordpress-sample-wordpress-1 wordpress:latest 127.0.0.1:8082->80/tcp Firewall-Regeln Auch wenn ich kein nft-Experte bin, wollte ich mir zumindest einen Überblick verschaffen, wie die Regeln hinter den Kulissen funktionieren und welchen Umfang sie haben: # ohne Docker (nur firewalld) nft list tables table inet firewalld nft list ruleset | wc -l 374 # nach Start der Docker Engine (keine laufenden Container) nft list tables table inet firewalld table ip docker-bridges table ip6 docker-bridges nft list ruleset | wc -l 736 Im Prinzip richtet Docker also zwei Regeltabellen docker-bridges ein, je eine für IPv4 und für IPv6. Die zentralen Regeln für IPv4 sehen so aus (hier etwas kompakter als üblich formatiert): nft list table ip docker-bridges table ip docker-bridges { map filter-forward-in-jumps { type ifname : verdict elements = { "docker0" : jump filter-forward-in__docker0 } } map filter-forward-out-jumps { type ifname : verdict elements = { "docker0" : jump filter-forward-out__docker0 } } map nat-postrouting-in-jumps { type ifname : verdict elements = { "docker0" : jump nat-postrouting-in__docker0 } } map nat-postrouting-out-jumps { type ifname : verdict elements = { "docker0" : jump nat-postrouting-out__docker0 } } chain filter-FORWARD { type filter hook forward priority filter; policy accept; oifname vmap @filter-forward-in-jumps iifname vmap @filter-forward-out-jumps } chain nat-OUTPUT { type nat hook output priority dstnat; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump nat-prerouting-and-output } chain nat-POSTROUTING { type nat hook postrouting priority srcnat; policy accept; iifname vmap @nat-postrouting-out-jumps oifname vmap @nat-postrouting-in-jumps } chain nat-PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter packets 0 bytes 0 jump nat-prerouting-and-output } chain nat-prerouting-and-output { } chain raw-PREROUTING { type filter hook prerouting priority raw; policy accept; } chain filter-forward-in__docker0 { ct state established,related counter packets 0 bytes 0 accept iifname "docker0" counter packets 0 bytes 0 accept comment "ICC" counter packets 0 bytes 0 drop comment "UNPUBLISHED PORT DROP" } chain filter-forward-out__docker0 { ct state established,related counter packets 0 bytes 0 accept counter packets 0 bytes 0 accept comment "OUTGOING" } chain nat-postrouting-in__docker0 { } chain nat-postrouting-out__docker0 { oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade comment "MASQUERADE" } } Diese Tabelle richtet NAT-Hooks für Pre- und Postrouting ein, die über Verdict-Maps (Datenstrukturen zur Zuordnung von Aktionen) später dynamisch auf bridge-spezifische Chains weiterleiten können. Für das Standard-Docker-Bridge-Netzwerk (docker0, 172.17.0.0/16) sind bereits Filter-Chains vorbereitet, die etablierte Verbindungen akzeptieren, Inter-Container-Kommunikation erlauben würden und nicht veröffentlichte Ports blocken, sowie eine Masquerading-Regel für ausgehenden Traffic von Containern, damit diese über die Host-IP auf das Internet zugreifen können. Die meisten Chains sind vorerst leer oder inaktiv (nat-prerouting-and-output, raw-PREROUTING, nat-postrouting-in__docker0). Wenn Docker Container ausführt, interne Netzwerk bildet etc., kommen weitere Regeln innerhalb von ip docker-bridges hinzu. Zusammenspiel mit libvirt/virt-manager Vor ca. einem halben Jahr bin ich das erste Mal über das nicht mehr funktionierende Zusammenspiel von Docker mit iptables und libvirt mit nftables gestolpert (siehe hier). Zumindest bei meinen oberflächlichen Tests klappt das jetzt: libvirt muss nicht auf iptables zurückgestellt werden sondern kann bei der Defaulteinstellung nftables bleiben. Dafür muss Docker wie in diesem Beitrag beschrieben ebenfalls auf nftables umgestellt werden. Nach einem Neustart (erforderlich, damit alte iptables-Docker-Regeln garantiert entfernt werden!) kooperieren Docker und libvirt so wie sie sollen. libvirt erzeugt für seine Netzwerkfunktionen zwei weitere Regeltabellen: nft list tables table inet firewalld table ip docker-bridges table ip6 docker-bridges table ip libvirt_network table ip6 libvirt_network Einschränkungen und Fazit Die Docker-Dokumentation weist darauf hin, dass das nftables-Backend noch keine Overlay-Regeln erstellt, die für den Betrieb von Docker Swarm notwendig sind. Docker Swarm funktioniert also aktuell nicht, wenn Sie Docker auf nftables umstellen. Für mich ist das kein Problem, weil ich Docker Swarm ohnedies nicht brauche. Ich habe meine Tests nur unter Fedora durchgeführt. (Meine Zeit ist auch endlich.) Es ist anzunehmen, dass RHEL plus Klone analog funktionieren, aber das bleibt abzuwarten. Debian + Ubuntu wären auch zu testen … Ich habe nur einfache compose-Setups ausprobiert. Natürlich kein produktiver Einsatz. Meine nftables- und Firewall-Kenntnisse reichen nicht aus, um eventuelle Sicherheitsimplikationen zu beurteilen, die sich aus der Umstellung von iptables auf nftables ergeben. Losgelöst von den Docker-spezifischen Problemen zeigt dieser Blog-Beitrag auch, dass das Zusammenspiel mehrerer Programme (firewalld, Docker, libvirt, fail2ban, sonstige Container- und Virtualisierungssysteme), die jeweils ihre eigenen Firewall-Regeln benötigen, alles andere als trivial ist. Es würde mich nicht überraschen, wenn es in naher Zukunft noch mehr unangenehme Überraschungen gäbe, dass also der gleichzeitige Betrieb der Programme A und B zu unerwarteten Sicherheitsproblemen führt. Warten wir es ab … Insofern ist die Empfehlung, beim produktiven Einsatz von Docker auf dem Host möglichst keine anderen Programme auszuführen, nachvollziehbar. Im Prinzip ist das Konzept ja nicht neu — jeder Dienst (Web, Datenbank, Mail usw.) bekommt möglichst seinen eigenen Server bzw. seine eigene Cloud-Instanz. Für große Firmen mit entsprechender Server-Infrastruktur sollte dies ohnedies selbstverständlich sein. Bei kleineren Server-Installationen ist die Auftrennung aber unbequem und teuer. Quellen/Links https://kofler.info/dockers-nft-inkompatibilitaet-wird-zunehmend-zum-aergernis/ https://docs.docker.com/engine/release-notes/29/ https://docs.docker.com/engine/network/firewall-nftables/ https://docs.docker.com/engine/network/firewall-nftables/#migrating-from-iptables-to-nftables https://docs.docker.com/engine/daemon/ https://docs.docker.com/engine/security/#docker-daemon-attack-surface
Die Raspberry Pi Foundation hat vor einigen Tagen eine komplett reorganisierte Implementierung Ihres Raspberry Pi OS Imager vorgestellt. Das Programm hilft dabei, Raspberry Pi OS oder andere Distributionen auf SD-Karten für den Raspberry Pi zu schreiben. Mit der vorigen Version hatte ich zuletzt Ärger. Aufgrund einer Unachtsamkeit habe ich Raspberry Pi OS über die Windows-Installation … Raspberry Pi Imager 2.0 weiterlesen →
Die Raspberry Pi Foundation hat vor einigen Tagen eine komplett reorganisierte Implementierung Ihres Raspberry Pi OS Imager vorgestellt. Das Programm hilft dabei, Raspberry Pi OS oder andere Distributionen auf SD-Karten für den Raspberry Pi zu schreiben. Mit der vorigen Version hatte ich zuletzt Ärger. Aufgrund einer Unachtsamkeit habe ich Raspberry Pi OS über die Windows-Installation auf der zweite SSD meines Mini-PCs geschrieben. Führt Version 2.0 ebenso leicht in die Irre? Installation unter Linux Der Raspberry Pi Imager steht für Windows als EXE-Datei und für macOS als DMG-Image zur Verfügung. Installation und Ausführung gelingen problemlos. Unter Linux ist die Sache nicht so einfach. Die Raspberry Pi Foundation stellt den Imager als AppImage zur Verfügung. AppImages sind ein ziemlich geniales Format zur Weitergabe von Programmen. Selbst Linux Torvalds war begeistert (und das will was sagen!): »This is just very cool.« Leider setzt Ubuntu auf Snap-Pakete und die Red-Hat-Welt auf Flatpaks. Dementsprechend mau ist die Unterstützung für das AppImage-Format. Ich habe meine Tests unter Fedora 43 durchgeführt. Der Versuch, den heruntergeladenen Imager einfach zu starten, führt sowohl aus dem Webbrowser als auch im Gnome Dateimanager in das Programm Gnome Disks. Fedora erkennt nicht, dass es sich um eine App handelt und bietet stattdessen Hilfe an, in die Image-Datei hineinzusehen. Abhilfe: Sie müssen zuerst das Execute-Bit setzen: chmod +x Downloads/imager_2.2.0.amd64.AppImage Aber auch der nächste Startversuch scheitert. Das Programm verlangt sudo-Rechte. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/imager-2.0-sudo.png" alt="" width="1460" height="1074" class="size-full wp-image-9184" srcset="https://kofler.info/wp-content/uploads/imager-2.0-sudo.png 1460w, https://kofler.info/wp-content/uploads/imager-2.0-sudo-850x625.png 850w, https://kofler.info/wp-content/uploads/imager-2.0-sudo-1280x942.png 1280w, https://kofler.info/wp-content/uploads/imager-2.0-sudo-768x565.png 768w" sizes="auto, (max-width: 1460px) 100vw, 1460px" /> Der Raspberry Pi Imager muss mit sudo ausgeführt werden Mit sudo funktioniert es schließlich: sudo Downloads/imager_2.2.0.amd64.AppImage Tipp: Beim Start mit sudo müssen Sie imager_n.n.AppImage unbedingt einen Pfad voranstellen! Wenn Sie zuerst mit cd Downloads in das Downloads-Verzeichnis wechseln und dann sudo imager_n.n.AppImage ausführen, lautet die Fehlermeldung Befehl nicht gefunden. Hingegen funktioniert sudo ./imager_n.n.AppImage. Bedienung Ist der Start einmal geglückt, lässt sich das Programm einfach bedienen: Sie wählen zuerst Ihr Raspberry-Pi-Modell aus, dann die gewünschte, dazu passende Distribution und schließlich das Device der SD-Karte aus. Vorsicht!! Wie schon bei der alten Version des Programms sind die Icons irreführend. In meinem Fall (PC mit zwei zwei SSDs und einer SD-Karte) wird das SD-Karten-Icon für die zweite SSD verwendet, das USB-Icon dagegen für die SD-Karte. Passen Sie auf, dass Sie nicht das falsche Laufwerk auswählen!! Ich habe ein entsprechendes GitHub-Issue verfasst. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/imager-2.0-os.png" alt="" width="1578" height="1538" class="size-full wp-image-9183" srcset="https://kofler.info/wp-content/uploads/imager-2.0-os.png 1578w, https://kofler.info/wp-content/uploads/imager-2.0-os-667x650.png 667w, https://kofler.info/wp-content/uploads/imager-2.0-os-985x960.png 985w, https://kofler.info/wp-content/uploads/imager-2.0-os-768x749.png 768w, https://kofler.info/wp-content/uploads/imager-2.0-os-1536x1497.png 1536w" sizes="auto, (max-width: 1578px) 100vw, 1578px" /> Distributionsauswahl <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/imager-2.0-card.png" alt="" width="1578" height="1110" class="size-full wp-image-9181" srcset="https://kofler.info/wp-content/uploads/imager-2.0-card.png 1578w, https://kofler.info/wp-content/uploads/imager-2.0-card-850x598.png 850w, https://kofler.info/wp-content/uploads/imager-2.0-card-1280x900.png 1280w, https://kofler.info/wp-content/uploads/imager-2.0-card-768x540.png 768w, https://kofler.info/wp-content/uploads/imager-2.0-card-1536x1080.png 1536w" sizes="auto, (max-width: 1578px) 100vw, 1578px" /> Die Icons zur Auswahl der SD-Karte sind irreführend. Der obere Eintrag ist eine SSD mit meiner Windows-Installation, der untere Eintrag ist die SD-Karte! In den weiteren Schritten können Sie eine Vorabkonfiguration von Raspberry Pi OS vornehmen, was vor allem dann hilfreich ist, wenn Sie den Raspberry Pi ohne Tastatur und Monitor (»headless«) in Betrieb nehmen und sich direkt per SSH einloggen möchten. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/imager-2.0-configuration.png" alt="" width="1578" height="1320" class="size-full wp-image-9182" srcset="https://kofler.info/wp-content/uploads/imager-2.0-configuration.png 1578w, https://kofler.info/wp-content/uploads/imager-2.0-configuration-777x650.png 777w, https://kofler.info/wp-content/uploads/imager-2.0-configuration-1148x960.png 1148w, https://kofler.info/wp-content/uploads/imager-2.0-configuration-768x642.png 768w, https://kofler.info/wp-content/uploads/imager-2.0-configuration-1536x1285.png 1536w" sizes="auto, (max-width: 1578px) 100vw, 1578px" /> Diverse Parameter können vorkonfiguriert werden Bei den Zusammenfassungen wäre die Angabe des Device-Namens der SD-Karte eine große Hilfe. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/imager-2.0-summary.png" alt="" width="1578" height="1320" class="size-full wp-image-9185" srcset="https://kofler.info/wp-content/uploads/imager-2.0-summary.png 1578w, https://kofler.info/wp-content/uploads/imager-2.0-summary-777x650.png 777w, https://kofler.info/wp-content/uploads/imager-2.0-summary-1148x960.png 1148w, https://kofler.info/wp-content/uploads/imager-2.0-summary-768x642.png 768w, https://kofler.info/wp-content/uploads/imager-2.0-summary-1536x1285.png 1536w" sizes="auto, (max-width: 1578px) 100vw, 1578px" /> In der Zusammenfassung fehlt der Device-Name der SD-Karte Fazit Die Oberfläche des Raspberry Pi Imager wurde überarbeitet und ist ein wenig übersichtlicher geworden. An der Funktionalität hat sich nichts geändert. Leider kann es weiterhin recht leicht passieren, das falsche Device auszuwählen. Bedienen Sie das Programm also mit Vorsicht! Quellen/Links https://www.raspberrypi.com/software/ https://www.raspberrypi.com/news/a-new-raspberry-pi-imager/ https://kofler.info/raspberry-pi-os-trixie/ https://appimage.org/ https://github.com/raspberrypi/rpi-imager/issues/1327
Endlich bin ich dazugekommen, einen Blick auf die aktuelle Xcode-Version 26.1.1 zu werfen: Die KI-Integration in Xcode wurde stark verbessert; grandios ist sie noch immer nicht. Der Attribute Inspector wurde ersatzlos gestrichen. Keiner weiß, warum. Neue Projekte verwenden immer noch Swift 5 per Default. (?!) Das primäre neue Feature von 6.2 ist der vereinfachte Umgang … Swift 6.2 und Xcode 26.1 weiterlesen →
Endlich bin ich dazugekommen, einen Blick auf die aktuelle Xcode-Version 26.1.1 zu werfen: Die KI-Integration in Xcode wurde stark verbessert; grandios ist sie noch immer nicht. Der Attribute Inspector wurde ersatzlos gestrichen. Keiner weiß, warum. Neue Projekte verwenden immer noch Swift 5 per Default. (?!) Das primäre neue Feature von 6.2 ist der vereinfachte Umgang mit Multi-Threading (Approachable Concurrency, Default Actor Isolation = MainActor). Update: Mittlerweile habe ich Xcode 26.2 installiert und den Artikel an ein paar Stellen aktualisiert. KI-Funktionen Apple bewegt sich in der schnell-lebigen KI-Landschaft wie ein überladener Supertanker bei der Hafeneinfahrt: behäbig und vorsichtig. Die 2024 versprochene KI-Integration Swift Code wurde im Herbst 2025 endlich ausgeliefert und nennt sich jetzt Coding Intelligence. Das bedeutet, dass es neben der schon länger verfügbaren Code Completion auf Basis eines lokalen Modells nun auch einen Chat-Bereich in Xcode gibt. Dort können Sie den Code eines Projekts analysieren, neue Funktionen entwickeln, Fehler beheben usw. Wie in anderen KI-Editoren verweisen Sie mit @ auf Dateien, Klassen, Funktionen und helfen so dem Sprachmodell bei der Zusammenstellung des richtigen Kontexts. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/xcode-ai-analyse.png" alt="" width="1920" height="1020" class="size-full wp-image-9148" srcset="https://kofler.info/wp-content/uploads/xcode-ai-analyse.png 1920w, https://kofler.info/wp-content/uploads/xcode-ai-analyse-850x452.png 850w, https://kofler.info/wp-content/uploads/xcode-ai-analyse-1280x680.png 1280w, https://kofler.info/wp-content/uploads/xcode-ai-analyse-768x408.png 768w, https://kofler.info/wp-content/uploads/xcode-ai-analyse-1536x816.png 1536w" sizes="auto, (max-width: 1920px) 100vw, 1920px" /> Analyse eines Projekts durch Claude Die KI-Chat-Funktionen werden normalerweise nicht lokal ausgeführt, sondern von externen KI-Dienstleistern ausgeführt. Die Xcode-Einstellungen stehen aktuell ChatGPT und Claude direkt zur Auswahl, wobei ChatGPT in beschränkten Ausmaß ohne Login genutzt werden kann. Eine intensivere Nutzung erfordert bei beiden Varianten einen Login. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/xcode-ai-settings.png" alt="" width="1200" height="847" class="size-full wp-image-9149" srcset="https://kofler.info/wp-content/uploads/xcode-ai-settings.png 1200w, https://kofler.info/wp-content/uploads/xcode-ai-settings-850x600.png 850w, https://kofler.info/wp-content/uploads/xcode-ai-settings-768x542.png 768w" sizes="auto, (max-width: 1200px) 100vw, 1200px" /> KI-Backend konfigurieren Ich habe die KI-Funktionen mit meinem Claude-Konto ausprobiert. Es reicht ein »gewöhnlicher« Account, es muss kein Account speziell zur API-Nutzung sein. Die Xcode-Integration mit Claude ist leider weniger gut als die mit ChatGPT. Insbesondere kann Xcode nicht anzeigen, welche Code-Dateien als Kontext an Claude weitergegeben wurden. (‚Project Context: Viewed Files‘ kann nicht angeklickt werden.) Andere AI-Dienste können mit Add Model Provider hinzugefügt werden. Erfreulicherweise gibt dieser Dialog auch die Möglichkeit, lokale Modelle (z.B. via Ollama) zu nutzen (siehe z.B. diese Anleitung). Leider ist die Implementierung der Chat-Funktion noch recht instabil. Bereits in den ersten 15 Minuten meiner Tests ist Xcode zweimal komplett abgestürzt (spinning wheel of death). Xcode musste »sofort beendet« werden. Der Versuch, eine von den KI-Funktionen vorgeschlagene Änderung wieder rückgängig zu machen, scheiterte. Sie sind gut beraten, vor jedem Arbeitsschritt einen Commit Ihres Projekts zu machen. Funktionen zum Agentic Coding, das in modernen Editoren wie VSCode, Cursor, Windsurf oder AntiGravity im letzten halben Jahr zur Selbstverständlichkeit geworden ist, suchen Sie in Xcode sowieso vergeblich. Immerhin sind die vorhandenen Features gut zugänglich dokumentiert, siehe z.B. das Xcode-Handbuch und dieses WWDC-Video. Das ändert aber nichts daran, dass Xcode noch einen weiten Weg vor sich hat, wenn es in der ersten KI-Liga mitspielen will. Wo ist der Attribute Inspector? (»Unapproachable SwiftUI«) In meinem Swift-Buch weise ich mehrfach auf den Attribute Inspector hin, der gerade für SwiftUI-Einsteiger eine große Hilfe war, um die wichtigsten Modifier einer View einzustellen. Natürlich lässt sich das alles auch per Code erledigen. Aber gerade bei den ersten Experimenten mit SwiftUI kennen Sie die ganzen Modifier-Namen ja noch nicht auswendig. Insofern empfand ich den Attribute Inspector als eine wichtige Hilfe. Apple hat das anders gesehen und hat dieses UI-Element von Xcode in Version 26 einfach eliminiert. Apple empfand den Attribute Inspector offenbar als so unwichtig, dass seine Entfernung nicht einmal in den Release Notes erwähnt wurde. Und so haben sich nicht wenige Entwickler gefragt: Gibt es das Teil wirklich nicht mehr? Ist es woanders in Xcode versteckt? Ist das ein Bug? Update 15.12.2025: Mit dem Attribute Inspector hat Apple auch einige Refactoring-Werkzeuge aus Xcode eliminiert. Extract Subview gibt es nicht mehr (siehe developer.apple.com/forums), aus Embed in Xxx wurde das weniger flexible Embed etc. Es ist eigentlich absurd: Will Apple den Zugang zu SwiftUI absichtlich erschweren? Einsteigern das Leben schwerer als notwendig machen? Swift 5 forever … Zusammen mit Xcode wird Swift 6.2 ausgeliefert: swift --version swift-driver version: 1.127.14.1 Apple Swift version 6.2.1 (swiftlang-6.2.1.4.8 clang-1700.4.4.1) Target: arm64-apple-macosx26.0 Da würde man annehmen, dass diese Version bei neuen Xcode-Projekten auch zum Einsatz kommt. Weit gefehlt! Per Default verwenden neue Projekte weiterhin Swift 5 (siehe den folgenden Screenshot). Wenn Sie Swift 6 wünschen, müssen Sie diese Version explizit in den Build Settings einstellen. Setzt Apple selbst so wenig Vertrauen in Version 6? <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/xcode-swift5.png" alt="" width="1200" height="623" class="size-full wp-image-9152" srcset="https://kofler.info/wp-content/uploads/xcode-swift5.png 1200w, https://kofler.info/wp-content/uploads/xcode-swift5-850x441.png 850w, https://kofler.info/wp-content/uploads/xcode-swift5-768x399.png 768w" sizes="auto, (max-width: 1200px) 100vw, 1200px" /> Unverständlicherweise verwenden neue Projekte per Default noch immer Swift 5 Update 13.12.2025: Auch mit Xcode 26.2 bleibt Swift 5 die Default-Version. Swift 6.2: »Approachable Concurrency« Apple hat nicht nur bei seinen Produkten einen perfektionistischen Ansatz — dieser gilt auch für die Programmiersprache Swift. Dieser Perfektionismus hat der Sprache in den letzten Jahren eine Flut von Features beschert, aber auch eine immer schwerer zugängliche, abstrakte Syntax. Offensichtlich über das Ziel hinausgeschossen sind die Entwickler bei den asynchronen Funktionen (Nebenläufigkeit, Concurrency): Seit Version 6 überschüttet Sie der Swift-Compiler mit Warnungen und Fehlermeldungen (Race Conditions, Isolation-Konflikte etc.). Der Compiler ist so pingelig, dass die Entwicklung asynchronen Codes sowie die Umstellung von Swift-5-Projekten auf Swift 6 zum Albtraum geworden sind. Swift hat es nicht bei Task, async und await belassen, sondern eine Menge weiterer Sprachmerkmale, Schlüsselwörter und Zusatz-Features geschaffen hat: Task-Gruppen, Aktoren, verteilte Aktoren, das Sendable-Protokoll, isolated und nonisolated Methoden usw. Zum Glück hat auch Apple erkannt, dass es praktisch niemanden mehr gibt, der die vielen Features versteht und richtig anwenden kann (siehe auch Concurrency Migration / Common Problems). Daher hat Apple Anfang 2025 neue Zielvorgaben formuliert, wie die asynchrone Swift-Programmierung vereinfacht werden soll. Den ersten großen Schritt zurück zu mehr Einfachheit macht nun Swift 6.2. <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/xcode-approachable-concurrency.png" alt="" width="1200" height="550" class="size-full wp-image-9162" srcset="https://kofler.info/wp-content/uploads/xcode-approachable-concurrency.png 1200w, https://kofler.info/wp-content/uploads/xcode-approachable-concurrency-850x390.png 850w, https://kofler.info/wp-content/uploads/xcode-approachable-concurrency-768x352.png 768w" sizes="auto, (max-width: 1200px) 100vw, 1200px" /> In neuen Projekte gilt die Option »Approachable Concurrency«, der gesamte Code ist dem MainActor zugeordnet. Es gibt zwei neue Einstellungen: Approachable Concurrency = Yes soll in Zukunft diverse Features zur Vereinfachung der asynchronen Programmierung aktivieren. Was die Einstellung aktuell (also in Swift 6.2) bewirkt, ist nur dürftig dokumentiert. Höchstwahrscheinlich wird damit nur SE-470 aktiviert. SE-470 (SE steht für Swift-Evolution) bewirkt, dass bei einem Typ, der einem Aktor (meist @MainActor) zugeordnet ist, die dort implementierten Protokolle automatisch ebenfalls diesem Aktor zugeordnet werden. Das war bisher nicht der Fall. In Zukunft (Swift 6.3?) wird wohl auch SE-461 aktiviert (siehe unten). Default Actor Isolation = MainActor aktiviert ein Compiler-Feature, das alle asynchronen Typen/Funktionen innerhalb des Moduls automatisch dem Main Actor zuordnet. Kurz gesagt erspart Ihnen diese Einstellung, dass Sie alle selbst definierten Klassen sowie oft auch deren Methoden mit dem Attribut @MainActor kennzeichnen müssen. Dieses Attribut gilt nun per Default. Und das ist in den meisten Fällen gut so! Downloads, Netzwerk-Aktionen usw. blockieren die Oberfläche dennoch nicht, weil sie bei Wartezeiten suspend nutzen. Probleme schaffen nur lang andauernde, CPU-intensive Vorgänge. Diese dürfen nicht mit dem MainActor verbunden werden, sonst »hängt« die Oberfläche Ihrer App. Derartige Vorgänge sind in typischen Apps aber die Ausnahme. Insofern ist die neue Einstellung Default Actor Isolation = MainActor für den Großteil aller Apps die richtige Wahl und geht ganz vielen Concurrency-Problemen und -Konflikten von vorne herein aus dem Weg. In zukünftigen Swift-Versionen sollen laut SE-461 asynchrone Funktionen/Methoden automatisch im Kontext des gerade aktuellen Aktors laufen (siehe auch Upcoming Language Features. In welchem sonst, werden Sie vielleicht fragen? Aktuell werden non-isolated Funktionen automatisch dem global generic executor zugeordnet. Aus Effizienzgründen mag das vorteilhaft sein, allerdings muss das asynchron ermittelte Ergebnis später mit der Benutzeroberfläche synchronisiert werden. Und das ist schwierig. Wenn ich es richtig verstanden habe, wird dieses Feature in Swift 6.2 trotz Approachable Concurrency = Yes noch NICHT aktiviert. Es kann aber mit -enable-upcoming-feature NonisolatedNonsendingByDefault:migrate schon jetzt ausprobiert werden. Die Zielsetzung all dieser Neuerungen ist es, dass das Concurrency-Verhalten von Swift per Default ein einfacher zu beherrschen ist. Für die meisten iOS- und macOS-Apps sollte das Default-Verhalten ausreichend sein. Nur wenn Ihr Code ganz spezielle Wünsche erfüllen muss (z.B. für Server-Anwendungen oder im Gaming-Bereich), können/müssen Sie die Fülle der sonstigen asynchronen Features von Swift explizit aktivieren und nutzen. Tipp Wenn Sie ein vorhandenes Projekt umstellen, werden die neuen Optionen Approachable Concurrency und Default Actor Isolation in den normalen Build Settings nicht angezeigt und können daher auch nicht aktiviert werden. Wechseln Sie die Ansicht von Basic auf All und suchen Sie nach Default Actor bzw. Approachable! <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/xcode-build-settings.png" alt="" width="1200" height="531" class="size-full wp-image-9173" srcset="https://kofler.info/wp-content/uploads/xcode-build-settings.png 1200w, https://kofler.info/wp-content/uploads/xcode-build-settings-850x376.png 850w, https://kofler.info/wp-content/uploads/xcode-build-settings-768x340.png 768w" sizes="auto, (max-width: 1200px) 100vw, 1200px" /> Bei vorhandenen Projekten werden die neuen Features werden in den ‚Basic Build Settings‘ nicht angezeigt. Aktivieren Sie ‚All Build Settings‘ und verwenden Sie die Such-Funktion! Sonstige Neuerungen in Swift 6.2 können Sie im Swift-Blog sowie auf den wie immer großartigen Seiten von Hacking with Swift nachlesen. Quellen/Links https://developer.apple.com/documentation/Xcode/writing-code-with-intelligence-in-xcode https://developer.apple.com/videos/play/wwdc2025/247/?time=637 https://docs.ollama.com/integrations/xcode https://developer.apple.com/documentation/xcode-release-notes/xcode-26-release-notes https://developer.apple.com/forums/thread/801679 https://www.youtube.com/shorts/7XlsEuHKhoE Swift 6.2 / Multi-threading / Concurrency https://github.com/swiftlang/swift-evolution/blob/main/visions/approachable-concurrency.md https://www.swift.org/migration/documentation/swift-6-concurrency-migration-guide/commonproblems/ https://github.com/swiftlang/swift-evolution/blob/main/proposals/0466-control-default-actor-isolation.md https://github.com/swiftlang/swift-evolution/blob/main/proposals/0470-isolated-conformances.md https://github.com/swiftlang/swift-evolution/blob/main/proposals/0461-async-function-isolation.md https://docs.swift.org/compiler/documentation/diagnostics/nonisolated-nonsending-by-default/ https://www.swift.org/blog/swift-6.2-released/ https://www.hackingwithswift.com/articles/277/whats-new-in-swift-6-2 https://www.donnywals.com/setting-default-actor-isolation-in-xcode-26 https://useyourloaf.com/blog/approachable-concurrency-in-swift-packages/
Ende November erscheint die 19. Auflage meines Linux-Buchs und markiert damit ein denkwürdiges Jubiläum: Das Buch ist jetzt 30 Jahre alt! Gleichzeitig ist das Buch so modern wie nie zuvor. Bei der Überarbeitung habe ich das Buch an vielen Stellen gestrafft und von Altlasten befreit. Das hat Platz für neue Inhalte gemacht, z.B. rund um … 📚 30 Jahre Linux-Buch weiterlesen →
Ende November erscheint die 19. Auflage meines Linux-Buchs und markiert damit ein denkwürdiges Jubiläum: Das Buch ist jetzt 30 Jahre alt! <img loading="lazy" decoding="async" src="https://kofler.info/wp-content/uploads/IMG_6511-scaled.jpeg" alt="" width="2560" height="1103" class="size-full wp-image-9156" srcset="https://kofler.info/wp-content/uploads/IMG_6511-scaled.jpeg 2560w, https://kofler.info/wp-content/uploads/IMG_6511-850x366.jpeg 850w, https://kofler.info/wp-content/uploads/IMG_6511-1280x552.jpeg 1280w, https://kofler.info/wp-content/uploads/IMG_6511-768x331.jpeg 768w, https://kofler.info/wp-content/uploads/IMG_6511-1536x662.jpeg 1536w, https://kofler.info/wp-content/uploads/IMG_6511-2048x882.jpeg 2048w" sizes="auto, (max-width: 2560px) 100vw, 2560px" /> Das Linux-Buch: 1995, 2004, 2010, 2014, 2025 Gleichzeitig ist das Buch so modern wie nie zuvor. Bei der Überarbeitung habe ich das Buch an vielen Stellen gestrafft und von Altlasten befreit. Das hat Platz für neue Inhalte gemacht, z.B. rund um die folgenden Themen: Die Shell fish (neues Kapitel) Swap on ZRAM Geoblocking mit nft (neuer Abschnitt) Samba im Zusammenspiel mit Windows 11 24H2 Monitoring mit Prometheus und Grafana (neues Kapitel, Docker-Setup mit Traefik) KI-Sprachmodelle ausführen (neues Kapitel) Berücksichtigung von CachyOS Umfang: 1429 Seiten ISBN: 978-3-367-11069-8 Preis: Euro 49,90 (in D inkl. MWSt.) Weitere Informationen zum Buch finden Sie hier. Aus dem Vorwort Sowohl Linux als auch mein Buch haben sich in den vergangenen 30 Jahren natürlich dramatisch verändert. Die folgenden Absätze stammen aus dem Vorwort. Das gesamte Vorwort befindet sich in der Leseprobe (PDF) zum Buch. Als ich an der ersten Auflage dieses Buchs schrieb, hatten die meisten Privatanwenderinnen und -anwender noch gar keinen Internetzugang, und wenn doch, dann über ein unzuverlässiges Modem. Das World Wide Web war gerade im Entstehen. In der ersten Auflage des Buchs habe ich Mosaic als Linux-tauglichen Webbrowser empfohlen. Erst in der zweiten Auflage konnte ich auf Netscape eingehen, der damals als erster »richtiger« Browser kostenlos für Linux zur Verfügung stand. (Aus Netscape wurde später Mozilla Firefox.) Das wichtigste Medium zur Verbreitung von Linux war in den 90er-Jahren die CD. Die ersten Auflagen dieses Buchs enthielten deswegen CDs (später DVDs) mit Linux-Distributionen. Der Siegeszug des Internets veränderte den Charakter dieses Buchs: Es war nicht mehr notwendig, alle Optionen diverser Kommandos bis ins letzte Detail zu beschreiben; jetzt reicht ein Link auf eine Webseite mit vertiefenden Informationen. In den Vordergrund des Buchs rückte die Vermittlung von Unix/Linux-Grundlagen. Ja, alles steht im Internet, aber Leserinnen und Leser schätzen den geordneten Überblick über Linux, die strukturierte Sammlung von Basiswissen so sehr, dass sich regelmäßige Neuauflagen lohnen. Die altmodische, aber werbefreie Präsentation auf Papier (oder in einem E-Book), frei von blinkenden Bannern und lästigen Werbevideos, ist ein entscheidender Vorteil. Parallel zur Entwicklung des Internets bekam dieses Buch einen neuen inhaltlichen Fokus. Immer mehr Organisationen und Firmen betreiben selbst Linux-Server, sei es zu Hause, auf gemieteten Root-Servern oder in virtuellen Maschinen (Cloud-Instanzen). Dementsprechend erklärt dieses Buch, wie Sie selbst SSH-, Web-, Mail- und Datenbank-Server einrichten und sicher betreiben. Ein weiterer Meilenstein der Linux-Geschichte war die Vorstellung des Raspberry Pi vor gut einem Jahrzehnt. Dieser preisgünstige Linux-basierte Mini-Computer bietet viele Anwendungen, von elektronischen Bastelprojekten bis zur Basisstation für die eigene Home Automation. Seit 2022 zeichnet sich eine weitere IT-Zeitenwende ab: Mit ChatGPT wird der erste brauchbare KI-Chatbot frei verfügbar. Es lässt sich trefflich darüber streiten, wie »intelligent« dieses und konkurrierende Systeme sind. Fest steht, dass KI-Tools eine großartige Hilfe bei Linux-Problemen aller Art sind. Nachdem ich mich vor zwei Jahrzehnten gefragt habe, ob das Internet IT-Bücher obsolet macht, stellt sich diese Frage jetzt wieder. Und neuerlich glaube ich, dass dies nicht der Fall sein wird. KI-Tools helfen (auch) bei der Lösung von Linux-Problemen. Dennoch brauchen Sie einiges an Grundwissen, um funktionierende Prompts zu formulieren. Und noch mehr Wissen zur Abschätzung, ob die Antworten von ChatGPT & Co. plausibel, veraltet oder frei erfunden sind. Genau dieses Wissen vermittele ich hier — seit 30 Jahren! Links https://kofler.info/20-jahre-linux-buch/ https://kofler.info/25-jahre-linux-buch/
Aktuell schreibe ich hier mehr zu Docker als mir lieb ist. Es ist eigentlich absurd: Ich verwende Docker seit Jahren täglich und in der Regel ohne irgendwelche Probleme. Aber in den letzten Wochen prasseln Firewall-Inkompatibilitäten und anderer Ärger förmlich über Docker-Anwender herein. Konkret geht es in diesem Beitrag um zwei Dinge: Mit dem Update auf … Vorsicht bei Docker-Updates weiterlesen →
Aktuell schreibe ich hier mehr zu Docker als mir lieb ist. Es ist eigentlich absurd: Ich verwende Docker seit Jahren täglich und in der Regel ohne irgendwelche Probleme. Aber in den letzten Wochen prasseln Firewall-Inkompatibilitäten und anderer Ärger förmlich über Docker-Anwender herein. Konkret geht es in diesem Beitrag um zwei Dinge: Mit dem Update auf containerd 1.7.28 hat Docker eine Sicherheitslücke durch eine zusätzliche AppArmor-Regel behoben. Das ist eigentlich gut, allerdings führt diese Sicherheitsmaßnahme zu Ärger im Zusammenspiel mit gewissen Containern (z.B. immich) unter Host-Systemen mit AppArmor (Ubuntu, Proxmox etc.) Docker Engine 29 verlangt die API-Version 1.44 oder neuer. Programme, die eine ältere API-Version verwenden, produzieren dann den Fehler Client Version 1.nnn is too old. Betroffen ist/war unter anderem das im Docker-Umfeld weit verbreitete Programm Traefik. AppArmor-Problem / net.ipv4.ip_unprivileged_port_start permission denied Im Anfang war der Bug, in diesem Fall CVE-2025-52881. Ein Angreifer kann runc (das wiederum Teil von containerd.io ist) mit Shared Mounts dazu bringen, /proc-Schreibvorgänge auf andere procfs-Dateien umzuleiten. Das ist wiederum sicherheitstechnisch ziemlich ungünstig (Severity ist High). Docker hat das Problem mit containerd 1.7.28-2 behoben — aber jetzt spießt es sich mit AppArmor, das nicht mehr den kompletten Pfad sieht und deswegen eingreift. Der Docker-Security-Fix kann auf Hosts mit AppArmor also dazu führen, dass auch korrekte Zugriffe blockiert werden. Die beste Beschreibung gibt dieser Blog-Beitrag. Ich kann aus eigener Erfahrung nicht viel zu diesem Problem sagen. Ich betreibe aktuell kein System, das betroffen ist. Besonders oft tritt der Bug in Kombination mit Proxmox oder LXC auf (siehe dieses containerd Issue). Aber auch die weit verbreitete immich.app zum Foto-Management ist betroffen (siehe diese Diskussion). Die in den verlinkten Beiträgen präsentierten Lösungsvorschläge sind leider allesamt wenig überzeugend: Das Docker-Update nicht durchführen/blockieren, eine alte Docker-Version re-installieren, AppArmor-Regeln ändern etc. Client Version too old Vollkommen unabhängig vom ersten Probem, aber fast zeitgleich aufgetreten ist der Fehler Client Version 1.nnn too old. Er resultiert daraus, dass die Docker Engine ab Version 29 für die API-Steuerung zumindest die API-Version 1.44 voraussetzt. (Bis zur Docker Enginge 28 reichte die API-Version 1.24.) docker version ... Server: Docker Desktop 4.51.0 (210443) Engine: Version: 29.0.0 API version: 1.52 (minimum version 1.44) <------ ... Wenn nun ein Programm eine ältere API-Version nutzt, kommt es zum in der Überschrift genannten Fehler. Betroffen ist davon Traefik. (Das ist ein HTTP-Reverse-Proxy für Microservices und Container-Umgebungen.) Dort ist das Problem bekannt und wurde vorgestern mit Traefik Version 3.6.1 behoben. Wenn Sie also ein Update auf die neueste Docker-Version durchführen, müssen Sie in compose.yaml für die Traefik-Version 3.6.1 oder einfach 3 oder latest angeben. Denken Sie daran, vor einem Neustart der Container ein Update des Traefek-Images mit docker pull traefik zu erledigen! sudo apt full-upgrade -y cd /mein/projekt/verzeichnis docker pull traefik docker compose down docker compose up -d Quellen/Links AppArmor-Problem / net.ipv4.ip_unprivileged_port_start permission denied (containerd 1.7.28) https://github.com/containerd/containerd/issues/12484 https://nvd.nist.gov/vuln/detail/CVE-2025-52881 https://github.com/immich-app/immich/discussions/23644 https://blog.ktz.me/apparmors-awkward-aftermath-atop-proxmox-9/ Client Version 1.nn is too old (Docker Engine 29) https://docs.docker.com/engine/release-notes/29/ https://www.docker.com/blog/docker-engine-version-29/ https://github.com/traefik/traefik/issues/12253 https://forums.docker.com/t/docker-29-increased-minimum-api-version-breaks-traefik-reverse-proxy/150384 https://github.com/traefik/traefik/issues/12253 https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions
Dockers nft-Inkompatibilität wird zunehmend zum Ärgernis
Ca. seit 2020 kommt nftables (Kommando nft) per Default als Firewall-Backend unter Linux zum Einsatz. Manche Distributionen machten den Schritt noch früher, andere folgten ein, zwei Jahre später. Aber mittlerweile verwenden praktisch alle Linux-Distributionen nftables. Alte Firewall-Scripts mit iptables funktionieren dank einer Kompatibilitätsschicht zum Glück größtenteils weiterhin. Viele wichtige Firewall-Tools und -Anwendungen (von firewalld über … Dockers nft-Inkompatibilität wird zunehmend zum Ärgernis weiterlesen →
Ca. seit 2020 kommt nftables (Kommando nft) per Default als Firewall-Backend unter Linux zum Einsatz. Manche Distributionen machten den Schritt noch früher, andere folgten ein, zwei Jahre später. Aber mittlerweile verwenden praktisch alle Linux-Distributionen nftables. Alte Firewall-Scripts mit iptables funktionieren dank einer Kompatibilitätsschicht zum Glück größtenteils weiterhin. Viele wichtige Firewall-Tools und -Anwendungen (von firewalld über fail2ban bis hin zu den libvirt-Bibliotheken) brauchen diese Komaptibilitätsschicht aber nicht mehr, sondern wurden auf nftables umgestellt. Welches Programm ist säumig? Docker! Und das wird zunehmend zum Problem. Update 11.11.2025: In naher Zukunft wird mit Engine Version 29.0 nftables als experimentelles Firewall-Backend ausgeliefert. (Aktuell gibt es den rc3, den ich aber nicht getestet habe. Meine lokalen Installationen verwenden die Engine-Version 28.5.1.) Ich habe den Artikel diesbezüglich erweitert/korrigiert. Sobald die Engine 29 ausgeliefert wird, werde ich das neue Backend ausprobieren und einen neuen Artikel verfassen. Docker versus libvirt/virt-manager Auf die bisher massivsten Schwierigkeiten bin ich unter Fedora >=42 und openSUSE >= 16 gestoßen: Wird zuerst Docker installiert und ausgeführt, funktioniert in virtuellen Maschinen, die mit libvirt/virt-manager gestartet werden, das NAT-Networking nicht mehr. Und es bedarf wirklich einiger Mühe, den Zusammenhang mit Docker zu erkennen. Die vorgebliche »Lösung« besteht darin, die libvirt-Firewall-Funktionen von nftables zurück auf iptables zu stellen. Eine echte Lösung wäre es, wenn Docker endlich nftables unterstützen würde. # in der Datei /etc/libvirt/network.conf firewall_backend = "iptables" Danach starten Sie den libvirt-Dämon dann neu: sudo systemctl restart libvirtd Weitere Infos gibt es hier und hier. Die openSUSE-Release-Notes weisen ebenfalls auf das Problem hin. Sicherheitsprobleme durch offene Ports Weil Docker iptables verwendet, ist es mit nftables oder firewalld nicht möglich, Container mit offenen Ports nach außen hin zu blockieren. Wenn Sie also docker run -p 8080:80 machen oder in compose.yaml eine entsprechende Ports-Zeile einbauen, ist der Port 8080 nicht nur auf dem lokalen Rechner sichtbar, sondern für die ganze Welt! nftables- oder firewalld-Regeln können dagegen nichts tun! Deswegen ist es wichtig, dass Docker-Container möglichst in internen Netzwerken miteinander kommunizieren bzw. dass offene Ports unbedingt auf localhost limitiert werden: # Port 8080 ist nur für localhost zugänglich. docker run -p localhost:8080:80 ... Ihre Optionen in compose.yaml sehen so aus: ```bash # compose.yaml # Ziel: myservice soll mit anderem Container # in compose.yaml über Port 8888 kommunizieren services: myservice: image: xxx ports: # unsicher! # - "8888:8888" # besser (Port ist für localhost sichtbar) # - "127.0.0.1:8888:8888" # noch besser (Port ist nur Docker-intern offen) - "8888" otherservice: ... Die sicherste Lösung besteht darin, die Container ausschließlich über ein Docker-internes Netzwerk miteinander zu verbinden (siehe backend_network im folgenden schablonenhaften Beispiel). Die Verbindung nach außen für die Ports 80 und 443 erfolgt über ein zweites Netzwerk (frontend_network). Die Angabe des drivers ist optional und verdeutlicht hier nur den Default-Netzwerktyp. # compose.yaml # am besten: die beiden Services myservice und # nginx kommunizieren über das interne Netzwerk # miteinander services: myservice: build: . ports: - "8888:8888" networks: - backend_network nginx: image: nginx:alpine ports: - "80:80" - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf - /etc/mycerts/fullchain.pem:/etc/nginx/ssl/nginx.crt - /etc/mycerts/privkey.pem:/etc/nginx/ssl/nginx.key depends_on: - myservice networks: - frontend_network - backend_network networks: # Verbindung zum Host über eine Bridge frontend_network: driver: bridge # Docker-interne Kommunikation zwischen den Containern backend_network: driver: bridge internal: true Restriktive Empfehlungen Docker hat es sich zuletzt sehr einfach gemacht. Auf https://docs.docker.com/engine/install/ubuntu/#firewall-limitations steht: If you use ufw or firewalld to manage firewall settings, be aware that when you expose container ports using Docker, these ports bypass your firewall rules. For more information, refer to Docker and ufw. Docker is only compatible with iptables-nft and iptables-legacy. Firewall rules created with nft are not supported on a system with Docker installed. Make sure that any firewall rulesets you use are created with iptables or ip6tables, and that you add them to the DOCKER-USER chain, see Packet filtering and firewalls. Und https://docs.docker.com/engine/security/#docker-daemon-attack-surface gibt diese Zusammenfassung: Finally, if you run Docker on a server, it is recommended to run exclusively Docker on the server, and move all other services within containers controlled by Docker. Of course, it is fine to keep your favorite admin tools (probably at least an SSH server), as well as existing monitoring/supervision processes, such as NRPE and collectd. Salopp formuliert: Verwenden Sie für das Docker-Deployment ausschließlich für diesen Zweck dezidierte Server und/oder verwenden Sie bei Bedarf veraltete iptable-Firewalls. Vor fünf Jahren war dieser Standpunkt noch verständlich, aber heute geht das einfach gar nicht mehr. Die Praxis sieht ganz oft so aus, dass auf einem Server diverse »normale« Dienste laufen und zusätzlich ein, zwei Docker-Container Zusatzfunktionen zur Verfügung stellen. Sicherheitstechnisch wird dieser alltägliche Wunsch zum Alptraum. Land in Sicht? Bei Docker weiß man natürlich auch, dass iptables keine Zukunft hat. Laut diesem Issue sind 10 von 11 Punkte für die Umstellung von iptables auf nftables erledigt. Aber auch dann ist unklar, wie es weiter gehen soll: Natürlich ist das ein massiver Eingriff in grundlegende Docker-Funktionen. Die sollten vor einem Release ordentlich getestet werden. Einen (offiziellen) Zeitplan für den Umstieg auf nftables habe ich vergeblich gesucht. Docker ist als Plattform-überschreitende Containerlösung für Software-Entwickler fast konkurrenzlos. Aber sobald man den Sichtwinkel auf Linux reduziert und sich womöglich auf Red-Hat-ähnliche Distributionen fokussiert, sieht die Lage anders aus: Podman ist vielleicht nicht hundertprozentig kompatibel, aber es ist mittlerweile ein sehr ausgereiftes Container-System, das mit Docker in vielerlei Hinsicht mithalten kann. Installationsprobleme entfallen, weil Podman per Default installiert ist. Firewall-Probleme entfallen auch. Und der root-less-Ansatz von Podman ist sicherheitstechnis sowieso ein großer Vorteil (auch wenn er oft zu Netzwerkeinschränkungen und Kompatibilitätsproblemen führt, vor allem bei compose-Setups). Für mich persönlich war Docker immer die Referenz und Podman die nicht ganz perfekte Alternative. Aber die anhaltenden Firewall-Probleme lassen mich an diesem Standpunkt zweifeln. Die Firewall-Inkompatibilität ist definitiv ein gewichtiger Grund, der gegen den Einsatz der Docker Engine auf Server-Installationen spricht. Docker wäre gut beraten, iptables ENDLICH hinter sich zu lassen! Update 11.11.2025: Als ich diesen Artikel im Oktober 2025 verfasst und im November veröffentlicht habe, ist mir entgangen, dass die Docker-Engine in der noch nicht ausgelieferten Version 29 tatsächlich bereits ein experimentelles nftables-Backend enthält! Version 29 liegt aktuell als Release Candidate 3 vor. Ich warte mit meinen Tests, bis die Version tatsächlich ausgeliefert wird. Hier sind die Release Notes, hier die neue Dokumentationsseite. Vermutlich wird es ein, zwei weitere Releases brauchen, bis das nftables-Backend den Sprung von »experimentell« bis »stabil« schafft, aber immerhin ist jetzt ganz konkret ein Ende der Firewall-Misere in Sicht. Quellen / Links https://github.com/moby/moby/issues/49634 https://github.com/docker/for-linux/issues/1472 https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables\ https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/16.0/html/~|~release-notes-leap-160\ https://docs.docker.com/engine/install/ubuntu/#firewall-limitations https://docs.docker.com/engine/network/packet-filtering-firewalls\ https://docs.docker.com/engine/security/#docker-daemon-attack-surface Das neue nftables-Backend für Docker https://docs.docker.com/engine/release-notes/29/ https://docs.docker.com/engine/network/firewall-nftables/ https://www.docker.com/blog/docker-engine-version-29/