Die SMLIGHT SLZB-06 Modelle werden auf Reddit und in Smart Home Foren sehr oft empfohlen. Anfang dieses Jahres hatte ich euch zwei der Modelle genauer vorgestellt. Im April hat SMLIGHT mit dem SLZB-MR1 die...

Viele unter euch kennen bestimmt den Spruch: „Traue nie einer Statistik, die du nicht selbst gefälscht hast.“

Mit Umfrageergebnissen verhält es sich ähnlich. Häufig werden Dinge in diese hineininterpretiert, welche durch die erfassten Daten gar nicht belegt werden können. In diesem Text möchte ich anhand eines einfachen Beispiels erläutern, was man aus einer Umfrage alles nicht ableiten bzw. lernen kann.

Wir unterscheiden zwei Arten von Umfragen

Umfrage ist nicht gleich Umfrage. Dies wird offensichtlich, wenn man sich der englischen Sprache bedient, in der zwischen Poll und Survey unterschieden wird. Ich habe Gemini um eine prägnante Erklärung der Unterschiede gebeten und folgende Antwort erhalten:

Der wesentliche Unterschied zwischen einer Poll und einer Survey liegt in ihrem Umfang und ihrer Komplexität.

• Eine Poll (Meinungsumfrage oder Abstimmung) ist in der Regel eine schnelle, auf eine einzige Frage beschränkte Erhebung. Sie dient dazu, eine sofortige Meinung oder Präferenz zu einem spezifischen Thema zu erfassen, oft mit einfachen Multiple-Choice-Antworten.
• Eine Survey (Befragung, Erhebung oder Umfrage) ist ein umfassenderer Prozess, der aus mehreren Fragen besteht und darauf abzielt, detailliertere Daten und tiefere Einblicke zu sammeln. Sie kann verschiedene Fragetypen enthalten, darunter offene Fragen, um qualitative Informationen zu erhalten.

In diesem Text betrachte ich eine Meinungsumfrage bzw. Abstimmung. Nach obiger Definition zeichnet sich daher schon ab, dass daraus kein großer Erkenntnisgewinn zu erwarten ist.

Umfrage auf Mastodon

Stand 28. August folgen mir auf Mastodon 249 Personen Accounts. Ob es sich dabei um natürliche Personen oder Bots handelt, weiß ich nicht sicher. Dies festzustellen, bedarf einer eigenen Analyse.

Am 20. August habe ich die in Abbildung 1 dargestellte Umfrage gestartet. Die Umfrage lief für die Dauer von einer Woche und ist mittlerweile beendet.

Gewonnene Erkenntnisse

In Abb. 1 ist zu erkennen, dass 21 Personen abgestimmt haben, die Umfrage 5-mal geteilt und 3-mal favorisiert wurde. Laut dem Ergebnis benutzen von den 21 Personen:

• 6 Personen (29 %) die nativen Podman-Befehle podman {run,start,stop} etc.
• 9 Personen (43 %) verwenden Quadlets
• 6 Personen (29 %) verwenden podman-compose

Das ist alles.

Der Erkenntnisgewinn ist tatsächlich recht gering. Aber mehr gibt diese kurze Umfrage einfach nicht her.

Was kann man hingegen nicht aus der Umfrage ableiten?

Einige Menschen neigen dazu, Dinge in Umfrageergebnisse hineinzuinterpretieren, die durch die Daten nicht belegt werden können. Dies passiert oftmals eher unterbewusst und völlig ohne böse Absicht. Um dem zu begegnen, hilft es, sich bewusst zu machen, was man alles nicht ableiten kann:

• Ich habe keine Ahnung, wer an der Umfrage teilgenommen hat, da die Beantwortung anonym möglich war und ich keinerlei demographische Daten erhoben habe.
• Da sich in sozialen Medien in der Regel Filterblasen bilden, liegt der Schluss nahe, dass die Antworten vorwiegend aus meiner Filterblase stammen und nicht repräsentativ sind.
• Da die Umfrage mehrfach geteilt wurde, weiß ich nicht, ob nur direkte Follower oder auch indirekte Kontakte abgestimmt haben.
• Ob Menschen die kein Podman nutzen, stattdessen Docker oder gar keine Container nutzen, weiß ich auch nicht.
• Darüber wie viele Menschen in der IT nun Linux-Container betreiben und wie viele davon dies mit Podman tun, weiß ich nichts.
• Diese Umfrage war sicher nicht repräsentativ.

Ziel der Umfrage – Was interessiert mich eigentlich?

Um ehrlich zu sein, habe ich mir zum Ziel der Umfrage gar nicht viele Gedanken gemacht. Ich habe sie spontan erstellt und wollte mich vom Ergebnis überraschen lassen. Während die Umfrage lief, kam in mir die Frage auf, was Menschen versuchen können, aus diesen Umfragen abzuleiten. Das führte zu diesem Artikel.

Grundsätzlich interessieren mich Antworten auf folgende Fragen:

• Wie verbreitet werden Linux-Container in der IT eingesetzt?
• Gibt es signifikante Unterschiede hinsichtlich ihrer Verwendung in Abhängigkeit der Branche?
• Wie groß ist der Anteil von Docker, HELM, Kubernetes, OpenShift, Operator, Podman, Rancher und weiterer Werkzeuge?
• Was sind die bevorzugten Werkzeuge?
• Welche Werkzeuge werden für welchen Zweck bevorzugt genutzt?
• Ist im zeitlichen Verlauf ein Trend zu erkennen?
• Mit welchem Konfigurations-Format erreiche ich eine möglichst große Zielgruppe?
• Wie stelle ich sicher, dass diese Daten unabhängig und repräsentativ erhoben wurden?

Besonders unter Berücksichtigung des letzten Stichpunktes wird deutlich, dass die Beantwortung dieser Fragen mit einer Menge Arbeit verbunden ist. Ich bin nicht so sehr an den Antworten interessiert, als dass ich bereit bin, diese Arbeit und Zeit zu ihrer Erledigung zu investieren.

Kann Künstliche Intelligenz hierbei helfen?

Das herauszufinden, wird Gegenstand eines kommenden Wochenendprojekts sein. Ich sehe dabei grundsätzlich folgende Herausforderungen auf mich zukommen.

Die diversen KI-Chatbots werden meine Fragen grundsätzlich mit einer starken Überzeugung beantworten. Einige listen dabei sogar die Quellen auf, welche sie für die Formulierung ihrer Antwort berücksichtigt haben. Daraus lässt sich dann immerhin ein Quellenverzeichnis erstellen. Die Arbeit liegt dann in der Quellenprüfung:

• Was sind Primärquellen und Sekundärquellen?
• Wie erfolgte die Datenerhebung?
• Gibt es Interessenskonflikte? (z.B. hat der Gewinner eines Vergleichstest den Test bezahlt?)
• Kann ich die Quellen prüfen oder liegen diese hinter Bezahl- bzw. Login-Schranken?

Ich habe noch Zweifel inwieweit mich die KI bei der Quellenprüfung unterstützen kann. Doch darum wird es in einem zukünftigen Artikel gehen. Hier ist nun für heute Schluss.

Am 16. und 17. August 2025 fand die 20. Free and Open Source Conference (FrOSCon) an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin statt.

Ich möchte mich ganz herzlich beim Orga-Team, C3VOC, allen helfenden Händen, Ausstellern, Vortragenden und Besucher:innen bedanken, die dieses Wochenende zu einem schönen Erlebnis gemacht haben.

Es folgt mein kurzer, ganz persönlicher Konferenzbericht.

Anreise am Freitag Nachmittag

Ich hatte am Freitag frei und konnte daher entspannt mit dem Auto bereits am Nachmittag anreisen. Kurz nach meiner Ankunft in Siegburg konnte ich dann schon Dirk, Sujeevan und ein neues Gesicht begrüßen. An dem neuen Gesicht hängt eine Person namens Gerald dran. Gerald, es freut mich dich kennen gelernt zu haben.

Wir sind in Siegburg ein Eis essen gegangen, haben das tolle Wetter genossen und uns mental auf das Abendessen vorbereitet, wo sich Ulf und Andreas zu uns gesellten.

Essen gut, Gespräche gut, Freitag gut.

Samstag – FrOSCon Tag 1

Am Samstag konnte ich dann auch Christoph und Christian begrüßen, die ich ebenfalls schon viel zu lange nicht mehr gesehen habe. Nach einer kurzen Begrüßung schwärmten wir aus und erkundeten die verschiedenen Stände.

Am Stand des Fedora & CentOS Projekts habe ich erstmalig meine Arbeitskolleginnen Julia Bley und Aleksandra Fedorova getroffen. Ich freue mich immer andere Red Hatter zu treffen, welche durch ihre Beiträge Community-Konferenzen unterstützen. Beide haben auch direkt mir Unterstützung angeboten, da ich bei einer der nächsten Konferenzen gerne einmal vorstellen möchte, wie aus Fedora und CentOS Stream ein Red Hat Enterprise Linux Release entsteht.

Kaum habe ich mich umgedreht, habe ich mit Armin Warda und Christoph Görn gleich noch zwei weitere Red Hatter getroffen. Hier muss irgendwo ein Nest sein. Schön auch euch mal wiedergesehen zu haben. :-)

Das Vortragsprogramm hielt dieses Jahr einige interessante Vorträge für mich bereit. So hörte ich um 10:00 Uhr zuerst OpenCloud: Unsere Learnings für eine einfache, stabile Filecloud (Link zur Aufzeichnung) von Tobias Baader und Klaas Freitag. An dieser Stelle nochmals Danke für euren tollen Vortrag und die guten Gespräche, die wir anschließend noch geführt haben. Ich freue mich, wenn wir in Kontakt bleiben.

Verpasst habe ich leider AI slop attacks on the curl project von Daniel Stenberg. Ich werde mir aber auf jeden Fall die Aufzeichnung ansehen, da ich nur Gutes über diesen Vortrag gehört habe.

Um 14:30 habe ich den OpenVox Vortrag (Link zur Aufzeichnung) von und mit Martin Alfke gehört. Es hat mich gefreut zu hören, dass die Foreman und OpenVox Communities offenbar gut zusammenarbeiten und sich gegenseitig unterstützen. Sie tragen somit dazu bei, dass ein etabliertes Konfigurations-Management-Werkzeug weiterhin frei bleibt und nicht hinter einer proprietären Lizenz verschwindet.

Schießlich war ich um 17:00 Uhr mit meinem Vortrag Bootable Containers (Link zur Aufzeichnung; PDF zum Download) dran. Danke an alle Hörer:innen für euer Interesse und eure Aufmerksamkeit. An dieser Stelle gehen Grüße raus an meinen Kollegen Andreas Bleischwitz. Danke für den Post-Talk-QA und schön auch dich mal wiedergesehen zu haben.

Der 1. Tag klang mit dem Social Event aus. ich habe den innenhof der Hochschule schon lange nicht mehr so voll erlebt. Es war wirklich sehr schön.

Sonntag – FrOSCon Tag 2

Ich hatte schlecht geschlafen. Zum Glück gab es im Hotel einen guten Kaffee, der mich auf die Beine brachte.

Auf der FrOSCon führte mein erster Weg nochmals zu Klaas von OpenCloud. Ich hatte versprochen ihnen Informationen zum Red Hat Partnerprogramm zu senden und brauchte noch eine E-Mail-Adresse, um diese Aufgabe direkt abschließen zu können. Ich freue mich, wenn ich euch in der Zukunft als Partner in unserem Ecosystem Catalog finden kann und wünsche euch auf jeden Fall viel Erfolg mit eurem Projekt.

Als nächsten möchte ich mich bei Susanne Schütze für den Vortrag Festplattenverschlüsselung mithilfe vom TPM 2.0 (Link zur Aufzeichnung) bedanken. Dieser war nicht nur unterhaltsam sondern auch sehr informativ. Du ersparst mir damit, selbst durch etliche Kaninchenbauten zu kriechen. Vielen Dank für deinen Vortrag!

Ebenfalls informativ fand ich den Vortrag Delegate authentication and a lot more to Keycloak with OpenID Connect (Link zur Aufzeichnung) von Alexander Schwarz. Ich muss mich aufgrund anderer Projekte beherrschen, hier direkt ein neues Wochenendprojekt zu starten. ;-)

Und ein weiteres Dankeschön geht raus an Dirk für seinen Vortrag Vom Techniker zum Leader (Link zur Aufzeichnung). Danke, dass wir an deiner Erfahrung teilhaben durften.

Damit war ein tolles Wochenende mit guten Vorträgen und tollen Menschen auch schon wieder vorbei. Es hat mir große Freude bereitet dabei gewesen zu sein und ich freue mich auf ein Wiedersehen, vielleicht schon im nächsten Jahr am 15. und 16. August 2026. Save the date!

Links zu weiterführenden Informationen der Projekte

• https://opencloud.eu/de
• https://docs.opencloud.eu/de/
• https://github.com/opencloud-eu
• https://codeberg.org/tronde/opencloud (Community-Beitrag)
• https://github.com/OpenVoxProject
• https://www.keycloak.org/
• https://fedoraproject.org/
• https://centos.org/

Heute berichte ich über meine Nutzung großer Sprachmodelle (engl. Large Language Model, kurz LLM) und freue mich, wenn ihr eure Erfahrungen in den Kommentaren oder vielleicht sogar einem eigenen Blog mit mir teilt.

Ich konzentriere mich in diesem Text auf Beispiele, in denen mich die Nutzung von LLMs in meiner Arbeit unterstützt. Dies soll nicht darüber hinwegtäuschen, dass LLMs halluzinieren und falsche Antworten produzieren können. Auch hierzu finden sich diverse Beispiele, die den Fokus des Artikels jedoch verschieben und den Umfang sprengen würden.

Bilder für Präsentationen

Ich nutze ChatGPT und Gemini, um Bilder für Präsentationen zu generieren. Dabei hat bis jetzt ChatGPT die Nase vorn.

Zuvor habe ich Bilder entweder selbst erstellt oder Stunden mit der Suche in Datenbanken mit lizenzfreien Bildern verbracht. Dies war für mich stets eine sehr frustrierende Erfahrung. Nun kann ich beschreiben, was ich in einem Bild sehen möchte und die Künstliche Intelligenz in Form eines LLM generiert mir entsprechende Bilder. Dies bringt für mich eine große Zeitersparnis und ich habe weniger Stress.

Zusammenfassung langer Texte und Diskussionen

Damit ist jetzt nicht gemeint, dass ich mir E-Mails mit mehr als fünf Sätzen zusammenfassen lasse. Aber auf der Arbeit erlebe ich es häufig, dass ich mal kurz nicht in eine Google Group geschaut habe und plötzlich eine Diskussion mit 40-70 Beiträgen darin finde. Diesen Diskussionen zu folgen war in der Vergangenheit sehr zeitaufwendig bis hinzu unmöglich. Und wir haben sehr viele Maillinglisten.

Wir haben auf der Arbeit Google Workspace und ich gebe gerne zu, dass sich damit bereits ohne KI-Unterstützung super arbeiten lässt. Die nahtlose Integration von Gemini macht es allerdings noch besser.

Wenn ich eine E-Mail Diskussion öffne, kann ich mir mit einem Klick eine Zusammenfassung erstellen lassen. Folgender Prompt hat sich bisher als nützlich erwiesen, um mir einen Überblick zu verschaffen: „Erstelle eine kurze Zusammenfassung, die den Diskussionsgegenstand wiedergibt. Führe auf, wer welche Argumente vertritt. Falls es Lösungsvorschläge und Action Items gibt, liste diese stichpunktartig auf.“

Anhand der Zusammenfassung kann ich in kurzer Zeit beurteilen, ob eine Diskussion für mich von Relevanz ist oder nicht. Auch hier ist der Vorteil durch Nutzung der KI im Allgemeinen die Zeitersparnis und im Speziellen die gute Integration in die vorhandenen Werkzeuge. Ich würde mir nicht die Mühe machen, alle Nachrichten einer langen Diskussion in einen Prompt zu kopieren, um diese dann von einem LLM analysieren zu lassen.

Generierung von Textvorschlägen für E-Mails

Ich weiß, was ich sagen möchte und drücke mich gerne direkt aus. Das kommt in der Kommunikation mit internationalen Empfängern aus anderen Kulturkreisen nicht immer gut an. Ich schätze auch hier die gute Integration von Gemini in Google Mail, wo ich es manchmal als Formulierungshilfe nutze.

Gemini bietet 3-4 Antwortvarianten an, die in einer Vorschau im Nachrichtenfenster angezeigt werden. Manche sind fernab meiner Vorstellung, andere kommen erstaunlich nah heran. So kann ich die am besten zutreffende Antwort auswählen, kürze sie etwas ein, ergänze evtl. noch 1-2 Sätze und bin fertig.

Vorteile auch hier die Zeitersparnis und die etwas höflicher bzw. runder formulierten E-Mails.

Zusammenfassung von Videokonferenzen

Ihr ahnt vielleicht schon, wo es jetzt hingeht. Google Gemini integriert sich auch hervorragend in Google Meet. Und so haben wir in einer internen Besprechung mit Zustimmung aller Beteiligten die Funktion ausprobiert, ein Besprechungs-Protokoll zu erstellen. Wir waren positiv überrascht.

Die Besprechung wurde auf Deutsch durchgeführt. Gemini war für diese Sprache offiziell noch als Alpha markiert, was das Ergebnis umso beeindruckender macht. Nach der Besprechung wurde ein Google Doc mit einer deutschsprachigen Zusammenfassung erstellt und im Kalender in den Termin eingefügt, so dass alle Teilnehmer es finden und darauf zugreifen können.

Ich habe das Protokoll gelesen und musste lediglich einige Schreibfehler bei Namen und englischen Fachbegriffen korrigieren. Alle Teilnehmer waren sich einig, dass die wesentlichen Punkte korrekt zusammengefasst wurden. Bei englischsprachigen Meetings, welche aufgezeichnet werden, enthält die Zusammenfassung sogar die Zeitstempel, zu denen protokollierte Aussagen gemacht wurden.

Es muss nun also kein Protokollant mehr ausgelost werden und alle Teilnehmer:innen können sich auf die Besprechung konzentrieren.

Da sich die Zusammenfassung auf das Wesentliche konzentriert, finde ich diese noch besser als ein Transkript, welches auch die belanglosen Beiträge wiedergibt und viel Redundanz enthalten kann.

Als Organisator verlasse ich mich nicht blind auf die KI. Ich lese das Protokoll zeitnah nach der Besprechung und korrigiere es ggf. Es ist bei uns auch nicht unüblich, dass Teilnehmer:innen auch im Nachgang zu einer Besprechung Ergänzungen und Korrekturen zum gemeinsamen Dokument beitragen.

Google NotebookLM

Google NotebookLM bietet eine Umgebung, in der mit KI-Unterstützung Inhalte von PDFs, Google Docs & Slides sowie Webseiten verarbeitet werden können. Ich möchte die Nutzung anhand eines konkreten Beispiels erläutern.

Leider habe ich mir die konkreten Prompts und detaillierten Antworten nicht gespeichert, so dass ich meine Erfahrung aus dem Gedächtnis aufschreibe.

Ich betreibe einen Server für Laborumgebungen aus der Hetzner-Serverbörse. Zu diesem gab es eine IPv4-Adresse und ein IPv6-Subnetz. Des Weiteren hat Hetzner eine Richtlinie zur Nutzung von MAC-Adressen. In meinem Fall darf nur die MAC der physischen Netzwerkkarte auf dem Switch im Rechenzentrum erscheinen, nicht jedoch die virtuellen MACs meiner virtuellen Maschinen (VM). Möchte ich meinen Server als Hypervisor-Host verwenden und die darauf laufenden VMs im Internet erreichbar machen, benötige ich dafür ein geroutetes Netzwerk auf dem Hypervisor.

Prinzipiell weiß ich, was zu tun ist. Es gibt bei Hetzner auch eine Anleitung, wie man Debian für Proxmox entsprechend konfiguriert, die ich auf RHEL mit Network Manager adaptieren kann. Deshalb schien mir diese Aufgabe geeignet, um zu testen, wie sich ChatGPT und NotebookLM dabei schlagen.

Ich habe beide Lösungen dabei angewiesen, mit folgenden Quellen zu arbeiten:

• RHEL 9: Configuring and managing networking
• RHEL 9: Configuring and managing virtualization
• Hetzner-FAQ: Reasons you received an abuse email regarding MAC-Errors
• Libvirt: Virtual Networking

Bei ChatGPT sind die URLs zu den Quellen in den Prompt einzugeben. Bei NotebookLM kann zu Beginn konfiguriert werden, welche Quellen im aktuellen Notebook zu verwenden sind. Diese kann man flexibel selektieren oder abwählen, um zu steuern, mit welchen Quellen die KI arbeiten soll.

Beiden Werkzeugen habe ich über den Prompt mitgeteilt, welche IPv6-Adresse ich auf der physischen Netzwerkkarte des Hosts nutzen möchte. Anschließend habe ich via Prompt eine zu RHEL 9 passende Schritt-für-Schritt-Anleitung gefordert, mit der die gewünschte Netzwerkkonfiguration umgesetzt werden kann. Die angebotenen Lösungen wurden in beiden Fällen durch weitere Prompts verfeinert.

ChatGPT

Die von ChatGPT generierte Lösung war komplex und falsch. Aufgrund meiner eigenen Erfahrung hatte ich direkt Zweifel und glaubte nicht, dass der vorgeschlagene wilde Mix aus Bridge und Teaming mit Master- und Slave-Interface auf der Bridge funktionieren würde.

Um meine Annahme zu verifizieren, habe ich die vorgeschlagene Lösung trotzdem umgesetzt und nach der Hetzner-MAC-Abuse-Meldung wieder zurückgebaut.

Ich hatte keine Lust, ChatGPT mit dem Ergebnis zu konfrontieren und weiter mit dem Bot zu chatten, da ich wenig Hoffnung hatte, dass ich noch zu einer funktionierenden Lösung komme.

NotebookLM

Hier hat mir die Erfahrung deutlich besser gefallen. Gemini hat auf meinen Prompt mit einer Zusammenfassung reagiert, welche Informationen über die bereitgestellten Quellen zu meinem Prompt bieten. Dabei wurden auch Referenzen mit ausgegeben, um direkt zur Quelle springen zu können. Im Anschluss gab es eine Schritt-für-Schritt-Anleitung mit Code-Beispielen. Zu jedem Code-Beispiel erfolgte dazu eine Erklärung, was man dort sieht und was die einzelnen Parameter bedeuten. Dies hat mir gut gefallen.

Die ersten zwei Anleitungen waren noch etwas ungenau, ließen sich jedoch durch weitere Prompts soweit verfeinern, dass ich sie fast 1-zu-1 übernehmen konnte.

Warum nur fast? Ich habe mir die in der Schritt-für-Schritt-Anleitung referenzierten Quellen angeschaut und mit den dortigen Informationen die Code-Beispiele weiter optimiert, so dass sie besser zu meiner Umgebung passen. Evtl. hätte Gemini dies mit besseren Prompts ebenfalls hinbekommen.

Auch diese Lösung habe ich implementiert und sie läuft bis heute. Die KI hat mich auf dem Weg zur Lösung unterstützt und ich musste nicht die vier Quellen komplett und im Detail lesen, um mir die Lösung komplett selbst zu erarbeiten. Ich bin mit dem Ergebnis sehr zufrieden.

Fazit

Künstliche Intelligenz und deren Nutzung ist nicht unumstritten. Der aktuelle Energiebedarf ist enorm und es ist zu befürchten, dass dies negative Umweltauswirkungen zur Folge hat. KI-Modelle können halluzinieren, was zu Fehlern führt, wenn man die Antworten der Modelle nicht verifiziert.

Die Weigerung, KI im Beruf zu benutzen und ihre Möglichkeiten zu erkunden, führt meiner Einschätzung nach jedoch nur dazu, dass man sich selbst benachteiligt. KI mag Arbeitsplätze nicht so schnell ersetzen. Aber Menschen, die KI effizient nutzen können, werden Menschen von Stellen verdrängen, die dies nicht können. Es erscheint mir daher sinnvoll, den Einsatz von KI im Beruf und Alltag zu erkunden.

Den größten Vorteil bietet mir die KI-Nutzung aktuell dort, wo sie gut in meine Anwendungen und Werkzeuge wie z.B. Mail, Videokonferenzen und Kalender integriert ist. Der Vorteil besteht überwiegend in Zeitersparnis. Ich habe die gewünschten Informationen schneller mit weniger eigenem Aufwand in ausreichender Qualität zur Verfügung, wobei die Qualität mit geringem Aufwand durch manuelle Überarbeitung schnell gesteigert werden kann, um ein gutes Ergebnis zu erzielen.

KI-Assistenten lassen sich nutzen, um die Zeit zur Lösung zu verkürzen. Ich hätte die Dokumentationen alle selbst lesen und mir die Lösung erarbeiten können. Ich bin mir jedoch sicher, dass ich dafür deutlich mehr Zeit hätte investieren müssen.

Im Endeffekt hilft mir KI dabei, mehr Aufgaben im gleichen Zeitintervall zu erledigen.

Ich lese und schreibe gerne. Lesen kann ich fast überall, ohne meine Umgebung zu stören. Gleichzeitig habe ich meine Ohren frei, um meine Konzentration schnell auf andere Dinge lenken zu können, ohne dass sich jemand durch Kopfhörer auf bzw. in meinen Ohren ausgeschlossen fühlt.

Ähnlich ist es mit dem Schreiben. Ich kann schreiben, während nebenbei das Fernsehen oder Radio läuft oder ich im Park oder einem Biergarten sitze. Podcasts und Videos lassen sich in diesen Umgebungen nur schwierig aufzeichnen.

Zudem bin ich in einer Zeit aufgewachsen, wo die Internetbandbreite noch so schmal war, dass an die flächendeckende Verbreitung von Audio und Video noch nicht zu denken war.

So ist das geschriebene Wort bis heute mein Favorit für die Aufnahme und Verbreitung von Wissen. Und damit sind Blogs für mich auch heute ein wichtiger und geschätzter Bestandteil des Internets, die für mich einen hohen Stellenwert besitzen.

Ich habe noch kein einziges TikTok-Video gesehen und kann dessen Stellenwert für die Gesellschaft nicht beurteilen. Ich finde generell nur sehr wenig Gefallen an Internetvideos, da sich bei mir der Eindruck verfestigt hat, dass diese häufig in die Länge gezogen werden, um noch eine Werbeunterbrechung oder Produktplatzierung unterbringen zu können. Ich fand bisher nur sehr wenige Videos hilfreich.

Wir Menschen sind jedoch teils sehr unterschiedlich und so ist mir bewusst, dass es natürlich auch eine Nutzergruppe gibt, welche Videos jederzeit den Vorzug vor einem Blogartikel gibt. Das ist auch vollkommen in Ordnung. Nutzt das Medium, welches euch am meisten anspricht.

Microblogging und Social Media sind für mich persönlich Synonyme für Mastodon. Hier folge ich meinen Bekannten, Freunden und interessanten Personen, deren Beiträge mich interessieren. Ich selbst teile hier meine Gedanken, Tageslaune und weise auf neue Artikel in meinem Blog hin. Falls ihr daran interessiert seid, findet ihr mich unter @Tronde@social.anoxinon.de.

Microblogging sehe ich es bestenfalls als Ergänzung zu einem Blog. Mit den Threads auf den diversen Plattformen konnte ich mich nie anfreunden. Wenn jemand etwas in mehr als 512 Zeichen ausdrücken möchte, freue ich mich, wenn dies in einem Blog niedergeschrieben wird, den ich gemütlich am Stück lesen kann.

Dies war nun meine Meinung. Welchen Stellenwert besitzen Blogs für euch?

Dieser Beitrag ist Teil der #BlogWochen2025, welche von von Benedikt, Dirk und Robert zum runden Geburtstag ihrer Blogs ausgerufen wurden.

SMLIGHT hat mit dem SLZB-MR2 einen weiteren ZigBee und Thread Multiradioadapter vorgestellt. Dieser kombiniert den CC2652P von Texas Instruments mit dem EFR32MG21 von Silicon Labs im bekannten Gehäuse der SLZB06 Reihe. Oder mit anderen...

SMLIGHT hat mit dem SLZB-MR3 einen weiteren ZigBee und Thread Multiradioadapter vorgestellt. Dieser kombiniert den CC2674P10 von Texas Instruments mit dem EFR32MG24 von Silicon Labs im bekannten Gehäuse der SLZB06 Reihe. Oder mit anderen...

Anzeige – Ich habe für diesen Artikel Produkte der Firma Paulmann zur Verfügung gestellt bekommen.
Wie man sein Smart Home mithilfe von Home Assistant und vielen kleinen Helferlein aufbaut, beschreibe ich nun schon seit geraumer Zeit hier im Blog. Dabei genieße ich es, dass die meisten Smart Home Anwendungen über den ein oder anderen Standard verfügen, mit dem sich Komponenten verbinden lassen. Bei Zigbee ist das generell zwar auch so, aber im Speziellen ist die Sache dann doch etwas komplizierter. Viele Anbieter von smarter Hardware haben auch eine Bridge, Gateway oder ähnliches im Portfolio, mit dem die Zigbee-Anbindung bewerkstelligt werden kann. So ist es auch bei meinen ersten Zigbee Produkten gewesen. Im Folgenden beschreibe ich, wie man die Zigbee Leuchten der Firma Paulmann aus der Serie „Plug & Shine“ einrichtet. Hierfür verwende ich deren Gateway namens Smik.

Bei der Sanierung unseres Außenbereichs haben wir viel Energie in die Auswahl der Materialien gelegt. Sowohl die Terrassenplatten, als auch die Mauersteine haben uns viel Kopfzerbrechen bereitet. Bei der Außenbeleuchtung war es glücklicherweise nicht ganz so schwierig, da die Auswahl an smarten Außenleuchten deutlich kleiner ist. So sind wir auf die Firma Paulmann aufmerksam geworden, die Zigbee-fähige Außenleuchten anbietet und noch dazu einen sehr einfachen Weg zu deren Einbindung bereithält.

Außenleuchten, welche Produkte habe ich verwendet?

Die Gartenmauer lassen wir uns mit der Leuchte „Plug & Shine Floor“ bescheinen. Sie leuchtet in weiß, die Farbtemperatur kann man hier einstellen. Außerdem hat sie alle RBG-Farben. Das ist ein tolles Feature, das man bei Gartenpartys verwenden kann. Über die Farbtemperatur vom weiß kann man die Lichtstimmung auf der Terrasse maßgeblich beeinflussen.

Den Treppenaufgang beleuchten wir mit der Pollerleuchte Ito. Diese ist von Haus aus leider nicht smart, lässt sich über den „Plug & Shine Controller“ aber smart machen. Mit diesem Controller kann man den gesamten Kabelstrang ein- bzw. ausschalten. Hier lassen sich weitere Paulmann-Produkte, die nicht von Haus aus smart sind, in die Steuerung einbinden und danach über das Smart Home steuern.

Die Einfassung der Terrasse beleuchten wir mit dem LED-Streifen „Plug & Shine Smooth Strip RGBW„, der Zigbee-fähig ist. Wie man dem Namen schon entnimmt, kann dieser in allen RGB-Farben leuchten. Für die Farbe weiß ist die Farbtemperatur wählbar.

Bäume und Sträucher setzen wir mit der smarten Leuchte „Plug & Shine Pike“ in Szene. Die Farben sind, ihr ahnt es schon, wieder in allen RBG-Farben möglich. Die Farbtemperatur von weiß ist wieder wählbar.

Elektrisch verkabelt werden die Leuchten mit Kabeln namens „Plug & Shine Connector„, die man in verschiedenen Längen und Anzahl von Abgängen erwerben kann. Das System ist einfach, aber genial: Eine 24 VDC-Spannungsquelle stellt die Spannung zur Verfügung. Die Kabel verfügen über Schraubverbinder, an die man wiederum die Leuchten verbinden kann. Auch Kabelabgänge als Verlängerungsleitung sind hiermit möglich. Die Kabel und die Verbinder sind dabei IP68 wasserfest – sogar für Pools geeignet. Die Anbindung der Leuchten ist somit werkzeuglos, verpolungssicher und sehr einfach möglich. Die Intelligenz der Leuchten steckt bereits in den Leuchten drin, sodass hier keine Bastel- oder Verkabelungsarbeit anfällt. Somit lässt sich das Projekt auch nach und nach erweitern.

Als Spannungsquelle verwende ich die „Plug & Shine Einspeisung 230/24V DC„. Diese sind mit IP67 ebenfalls für den Außenbereich geeignet. Ihre Größe kann man an der Gesamtleistung aller Leuchten berechnen. Es stehen mehrere Größen zur Verfügung. Durch die Kunststoff-Abdeckung „Plug and Shine Trafoabdeckung“ lässt sich das Netzteil sogar unauffällig verkleiden.

Zur Steuerung verwende ich die Fernbedienung „Plug & Shine Gent 2„. Mit ihr kann man die Leuchten gruppenweise an- bzw. ausschalten sowie die Farben vorgeben. Das ist sehr nett gelöst, da man über ein Farbfeld intuitiv die Farben auswählen kann. Großer Pluspunkt für die Fernbedienung! Dafür ist für die Einrichtung bzw. das Anlernen der Leuchten etwas Übung notwendig. Die Anleitung dazu liegt der Fernbedienung bei. Mit etwas Konzentration versteht man aber die Logik dahinter.

Einrichtung des Zigbee Gateways und der Leuchten

Dreh- und Angelpunkt für die Steuerung der Außenbeleuchtung ist das Gateway. Hier ist die Schnittstelle zwischen der Smartphone App und den Leuchten. Die Einrichtung ist denkbar einfach. Man schließt das Gateway mittels Ethernet-Kabel an das Netzwerk an (z.B. an eine Fritzbox) und stellt die Spannungsversorgung her. Die Schwierigkeit besteht in der sehr geringen Reichweite des Signals. Sie wird mit 100 m angegeben, berücksichtigt aber weder Wände noch Fensterscheiben. Folglich muss das Gerät sehr nahe an den Garten gebracht werden.

Auf dem Smartphone installiert man sich die App „Paulmann Smik“ und folgt den Anweisungen auf dem Bildschirm. Man muss im Laufe der Einrichtung den QR-Code auf der Rückseite des Gateways scannen. Hierdurch gelingt die Einrichtung sehr schnell und einfach.

Neue Leuchten fügt man hinzu, indem man sie auf Werkseinstellungen zurückstellt. Das ist etwas herausfordernd, da man die Leuchten hier schnell an- und ausschalten muss, insgesamt 5 mal hintereinander. Die Leuchte darf dabei nicht länger als 2 Sekunden an und nicht länger als 5 Sekunden aus sein. Ich habe das geschafft, indem ich die Spannungsversorgung an eine schaltbare Steckdose angeschlossen habe. Mit ihr kann ich über einen Schalter die Ein- und Ausschaltdauer sehr gut timen. Sobald sie zurückgesetzt wurden, können sie über die App gefunden werden.

Best Practises und Tipps

Gruppiert eure Leuchten am besten thematisch, um zusammengehörige Leuchten gemeinsam zu schalten. Ich habe beispielsweise die Mauerspots gruppiert. Sie liegen in der Fernbedienung auf der Schnellwahltaste 1. Ist die Gruppe gewählt, steuere ich alle Mauerspots gemeinsam. Die Fernbedienung erlaubt auch das Steuern von mehreren Gruppen gleichzeitig. Dadurch kann man die Farben von allen Leuchten gemeinsam verändern. Sehr nice!

Macht die Steckdose schaltbar. Wenn die Spannungsversorgung an einer schaltbaren Steckdose angeschlossen ist, könnt ihr die Leuchten sehr viel komfortabler zurücksetzen und für die Einrichtung vorbereiten.

Setzt das Gateway möglichst nahe an den Außenbereich. Die geringe Reichweite ist relativ nervig, daher muss das Gateway recht nahe an den ersten Teilnehmer. Das Signal wird vom ersten Teilnehmer verstärkt, sodass alle weiteren Leuchten dann gutes Signal haben sollten. In der Praxis muss man das ein bisschen ausprobieren, was gut funktioniert.

Ausblick: Einbindung in Home Assistant

Die Einbindung der Außenbeleuchtung in Home Assistant ist möglich. Hat man einen Zigbee-Stick, zum Beispiel den von Nabu Casa selbst, kann man die Lampen damit einbinden. Hierfür muss man eine Instanz von Zigbee2MQTT installiert haben. Bei vielen Home Assistant Anwendern geht das über den Addon Store oder über einen Docker Container, wie es bei mir der Fall ist. Aus zwei Gründen habe ich das bei mir allerdings nicht getan.

1) Die Steuerung über die Paulmann App bzw. über die Gent 2 Fernbedienung ist sehr komfortabel. Es sind viele Funktionen voreingestellt, die Wahl der Farbtemperatur zum Beispiel oder die sehr einfache Auswahl der Farbe über das Farbfeld ist sehr cool. In Home Assistant müsste man sich diese Funktionen erst selbst konfigurieren. Ich bin mir sicher, dass viele Leute das schaffen würden. Für mich steht der Aufwand in keinem Verhältnis.

2) Während er Zeit auf der Terrasse möchte ich weitestgehend auf das Smartphone verzichten. Für die Lichtsteuerung möchte ich deshalb nicht aufs Smartphone angewiesen sein. Im Gegenteil: ich möchte auch unseren Gästen die einfache Möglichkeit geben, unsere Beleuchtung zu kontrollieren. Die Fernbedienung ist hierfür ideal geeignet.

Für die Einbindung in Home Assistant gibt es jedoch ebenfalls gute Argumente

1) Das ganze Haus lässt sich über eine zentrale Steuereinheit kontrollieren. Hier wäre es nur konsequent, die Außenbeleuchtung mit einzubinden.

2) Logging und Kontrolle von den Lampen: Von unterwegs aus sehen, ob die Lampen noch an sind? Kann man mit Home Assistant.

3) Kombination mit anderen Systemen. Die Sensoren und Aktoren könnten auch von anderen Herstellern kommen. Dämmerungs- und Bewegungsmelder von Paulmann könnten dann auch andere smarte Aktoren schalten.

The post Smarte Außenbeleuchtung mit Zigbee-Schnittstelle first appeared on bejonet - Linux | Smart Home | Technik.

In diesem Artikel halte ich fest, was es mit den genannten Begriffen auf sich hat und was ich in den vergangenen Tagen mit ihnen angestellt habe. Dabei gehe ich auch auf das Warum ein, während Fragen nach dem Wie vorwiegend in den Verweisen im Text beantwortet werden.

Der Artikel dient mir als Dokumentation und meinen Leser:innen zur Unterhaltung und zum Wissenstransfer.

Codeberg.org

Codeberg ist eine demokratische, gemeinschaftsgetriebene, gemeinnützige Softwareentwicklungsplattform, die von Codeberg e.V. betrieben wird und sich um Codeberg.org, eine auf Forgejo basierende Software, dreht. Der Sitz des Vereins ist in Berlin. Hier wird Codeberg.org auch gehosted.

Auf Codeberg könnt ihr eure eigenen Freie Software-Projekte entwickeln, zu anderen Projekten beitragen, inspirierende und nützliche Freie Software durchstöbern, euer Wissen teilen oder euren Projekten mit Codeberg Pages ein Zuhause im Web geben, um nur einige Beispiele zu nennen.

Die beiden vorstehenden Abschnitte wurden übersetzt mit DeepL.com (kostenlose Version) und anschließend leicht angepasst und mit Links angereichert.

Mit Codeberg.org werden keine kommerziellen Interessen verfolgt. Man ist hier (nur) Nutzer und/oder Unterstützer, jedoch nicht selbst ein Produkt. Mir gefällt die Mission des Projekts. Daher bin ich dazu übergegangen, einen Teil meiner Repositories hier zu verwalten. Zwar bin ich kein Mitglied des Vereins, unterstütze diesen jedoch durch gelegentliche Spenden.

Actions, Runner und Workflows

Plattformen wie Codeberg.org, GitHub und GitLab unterstützen Softwareentwicklungsprozesse durch CI/CD-Funktionalität.

Ein Forgejo-Runner ist ein Dienst, der Workflows von einer Forgejo-Instanz abruft, sie ausführt, mit den Protokollen zurücksendet und schließlich den Erfolg oder Misserfolg meldet.

Dabei ist ein Workflow in der Forgejo-Terminologie eine YAML-Datei im Verzeichnis .forgejo/workflows eines Repositories. Workflows umfassen einen oder mehrere Jobs, die wiederum aus einem oder mehreren Steps bestehen. Eine Action ist eine Funktion zur Erfüllung häufig benötigter Aufgaben, bspw. Quelltext auschecken, oder sich bei einer Container-Registry einloggen etc. Siehe für weitere Informationen Abschnitt Hierarchy ff. im Forgejo Actions user guide.

Motiviert, meinen eigenen Forgejo-Runner zu installieren, haben mich zwei Blog-Artikel von meinem Arbeitskollegen Jan Wildeboer:

• Running a runner for codeberg/forgejo on RHEL9 as user
• Be a Builder of Decentralisation – codeberg, forgejo, runners

Durch den Betrieb eigener Forgejo-Runner kann ich bereits vorhandene Rechenkapazität nutzen. Es fallen für mich und den Verein Codeberg e.V. dadurch keine zusätzlichen Kosten an. Für die Installation auf RHEL 9 bin ich dem Forgejo Runner installation guide gefolgt, da das in Jans Artikel erwähnte Repository ne0l/forgejo offensichtlich nicht mehr gepflegt wird und nur eine veraltete Version des Runner enthält.

Ein Dankeschön geht raus an Jan für unseren kurzen und produktiven Austausch dazu auf Mastodon.

Wozu das Ganze?

Ich beschäftige mich beruflich seit einiger Zeit mit dem RHEL image mode und möchte demnächst einen meiner KVM-Hypervisor damit betreiben. Bis es soweit ist, arbeite ich eine Weile im „Jugend forscht“-Modus und baue immer wieder neue Versionen meiner Container-Images. Der Ablauf ist dabei stets derselbe:

1. Containerfile(5) erstellen bzw. anpassen
2. Container-Image mit podman-build erstellen
3. Das erstellte Image mit podman-push in eine Container-Registry hochladen
4. Das Deployment auf diversen Zielsystemen testen

Dazu verwende ich das RHEL 9 Bootc Base Image aus der Registry registry.redhat.io.

The rhel-bootc and user-created containers based on rhel-bootc container image are subject to the Red Hat Enterprise Linux end user license agreement (EULA). You are not allowed to publicly redistribute these images.

Quelle: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/introducing-image-mode-for-rhel_using-image-mode-for-rhel-to-build-deploy-and-manage-operating-systems#introducing-image-mode-for-rhel_using-image-mode-for-rhel-to-build-deploy-and-manage-operating-systems

Um vorstehender Anforderung gerecht zu werden, speichere ich das erzeugte Container-Image in einem privaten Repository auf Quay.io. Sowohl für registry.redhat.io als auch für quay.io ist ein Login erforderlich, bevor es losgehen kann.

Für mich bot sich hier die Gelegenheit, die Nutzung von Forgejo Workflows zu lernen und damit den Ablauf zur Erstellung meines RHEL Bootc Images zu automatisieren.

Forgejo Workflow und Runner-Konfiguration

Im folgenden Codeblock findet ihr meinen Forgejo Workflow aus der Datei .forgejo/workflows/build_image.yaml, gefolgt von einer Beschreibung der einzelnen Schritte. Zur Erklärung der Begriffe name, on, env, jobs, steps, run, etc. siehe Workflow reference guide.

name: build_image

on:
  push:
    branches: main

env:
  REPO_URL: https://codeberg.org/Tronde/rhel-bootc.git
  REPO_NAME: rhel-bootc
  IMAGE_NAME: quay.io/rhn-support-jkastnin/rhel-bootc:9.5

jobs:
  build:
    runs-on: podman
    steps:
      - run: dnf -y install git
      - run: echo ${{ secrets.RH_REGISTRY_TOKEN }} | podman login -u ${{ secrets.RH_REGISTRY_USERNAME }} --password-stdin registry.redhat.io

      - run: echo ${{ secrets.QUAY_ROBOT_TOKEN }} | podman login -u ${{ secrets.QUAY_USERNAME }} --password-stdin quay.io

      - run: git clone ${{ env.REPO_URL }}
      - run: podman build -f /workspace/Tronde/rhel-bootc/rhel-bootc/Containerfile -t ${{ env.IMAGE_NAME }}
      - run: podman push ${{ env.IMAGE_NAME }}

1. Der Workflow wird jedes Mal ausgeführt, wenn ich einen Commit in den Branch main pushe
2. Ich definiere einige Umgebungsvariablen, um bei Änderungen nicht alle Schritte im Workflow einzeln auf notwendige Änderungen prüfen zu müssen
3. Mit `runs-on: podman` bestimme ich, dass der Workflow auf einem Runner mit dem Label podman ausgeführt wird; der entsprechende Runner started dann einen rootless Podman-Container, in dem die folgenden Schritte innerhalb von rootful Podman ausgeführt werden (nested Podman bzw. Podman in Podman)
4. Git wird installiert
5. Anmeldung an registry.redhat.io erfolgt
6. Anmeldung an quay.io erfolgt
7. Das Git-Repository wird geklont, um es auf dem Runner verfügbar zu haben
8. Der Runner baut ein Container-Image (Erinnerung an mich selbst: Ersetze den hardcodierten Pfad durch eine Variable)
9. Das erstellte Image wird in die Registry gepusht

Damit mein Runner den obigen Workflow ausführen kann, existiert auf diesem die Konfigurationsdatei /etc/forgejo-runner/config.yml, welche ich mit dem Kommando forgejo-runner generate-config > config.yml erstellt und anschließend angepasst habe. Der folgende Codeblock zeigt nur die Abschnitte, die ich manuell angepasst habe.

…
  fetch_interval: 20s
…
  labels: [
    "rhel-9-ubi:docker://registry.access.redhat.com/ubi9/ubi",
    "podman:docker://registry.access.redhat.com/ubi9/podman",
    "ubuntu-latest:docker://ghcr.io/catthehacker/ubuntu:act-latest",
    "act-runner:docker://node:20-bullseye",
    "centos-stream-9:docker://quay.io/centos/centos:stream9"]
…
  privileged: true
…

Ich greife mal die Zeile podman:docker://registry.access.redhat.com/ubi9/podman heraus:

• podman: am Beginn der Zeile beinhaltet das Label, welches im Worflow mit runs-on verwendet wird
• Mit dem Rest der Zeile wird bestimmt, in welchem Container-Image der Workflow ausgeführt wird
• Ich habe mich für ubi9/podman entschieden, weil
  • ich bei Red Hat arbeite und daher
  • mit den Prozessen zur Erstellung unserer Images vertraut bin,
  • wodurch sich ein gewisses Vertrauen gebildet hat.
  • Ich vertraue unseren Images mehr, als jenen, die irgendein Unbekannter gebaut hat und deren Inhalt ich nicht kenne (man kann den Inhalt aber selbstverständlich überprüfen)
  • und ich so prüfen konnte, ob sich ein Image mit „unseren“ Werkzeugen bauen läst (nicht, dass ich daran gezweifelt hätte).

Die Angabe von privileged: true ist erforderlich, wenn man innerhalb des Containers ebenfalls mit podman oder docker arbeiten möchte.

Entscheidungen

Meinem weiter oben abgebildeten Workflow ist zu entnehmen, dass ich auf die Verwendung von Forgejo Actions verzichtet habe. Das hat folgende Gründe:

• Für die Verwendung ist node auf dem Runner erforderlich
• node ist im Image ubi9/podman standardmäßig nicht installiert
• Node.js ist für mich das Tor zur Hölle und ich vermeide dessen Nutzung wenn möglich
• Die Nutzung ist keine Voraussetzung, da ich mein Ziel auch so ohne Mehraufwand erreicht habe

Sobald die Workflows länger und komplexer werden, mag sich meine Einstellung zu Actions ändern.

Zusammenfassung

Ich habe gelernt:

• Forgejo Runner zu installieren und zu konfigurieren
• Wie Forgejo Workflows funktionieren und auf Codeberg.org genutzt werden können
• Wie ich mir damit zukünftig die Arbeit in anderen Projekten erleichtern kann
• Was für großartige Open Source Projekte Codeberg.org und Forgejo sind

Vorwort

Die Blogs von Benedikt, Dirk und Robert feiern dieses Jahr Geburtstag. Zu diesem Anlass haben die Drei die #BlogWochen2025 ausgerufen. Jede Bloggerin und jeder Blogger ist eingeladen, dabei mitzumachen. Details könnt ihr in den Blogs der drei nachlesen:

• Im Mai beginnen die BlogWochen – Nur ein Blog
• Im Mai beginnen die Blogwochen – Dirks Logbuch
• Hilfe, unsere Blogs wer­den alt! Feiern und mit­ma­chen bei den #BlogWochen2025! – benedikt.io

Zum Thema des heutigen Tages steuere ich gerne einen Beitrag bei.

Was mich zum Bloggen antreibt

Ich verfolge mit meinem Blog drei Ziele:

• Dinge aufschreiben, die mir hilfreich waren bzw. die ich nützlich finde und die ich in Zukunft noch einmal gebrauchen kann – Mein Blog ist mein Gedächtnis für IT-Dinge
• Mein Wissen mit der Welt teilen, damit andere davon profitieren können
• Meine Meinung mit der Welt teilen, um mit anderen ins Gespräch zu kommen und andere Meinungen kennenzulernen

Da es im IT-Bereich bereits sehr viele gute Blogs in englischer Sprache gibt, habe ich mich zu Beginn entschieden, in Deutsch zu bloggen, um zur deutschsprachigen Gemeinschaft beizutragen. Meine Idee war und ist, damit denen zu helfen, für die Englisch gegebenenfalls noch eine Hürde darstellt. Diesen Grundsatz behalte ich bis auf ganz wenige Ausnahmen bis heute bei. Meine Artikel in englischer Sprache veröffentliche ich an anderer Stelle.

Ich freue mich, wenn ich Rückmeldungen erhalte, dass jemand meine Texte hilfreich und nützlich fand und meine Leser Gefallen daran finden. Besonders freue ich mich, wenn darunter Perlen aus der Vergangenheit sind. Dies zeigt mir, dass selbst Artikel von vor über 10 Jahren noch eine gewisse Relevanz besitzen.

Diese Rückmeldungen sind es, die mich motivieren, nach immer neuen Themen zu suchen und diese für den Blog zu verschriftlichen.

Zudem muss ich jedes Mal schmunzeln, wenn ich im Internet die Antwort auf eine Frage suche und diese dann in meinem eigenen Blog finde. So stellt mein Blog inzwischen für mich eine wertvolle Wissensdatenbank dar, auf die ich regelmäßig und gerne zurückgreife.

Wie ist das bei euch? Lest und stöbert ihr gerne in Blogs? Favorisiert ihr andere Formate? Bloggt ihr selbst? Ich freue mich über eure Kommentare oder Blogposts zu diesem Thema.

SMLIGHT hat mit dem SLZB-MR1 den ersten ZigBee und Thread Multiradioadapter vorgestellt. Dieser kombiniert den CC2652P7 von Texas Instruments mit dem EFR32MG21 von Silicon Labs im bekannten Gehäuse der SLZB06 Reihe. Oder mit anderen...

Kürzlich habe ich für eine anstehende Modernisierungsmaßnahme im Haus einen Kredit-vorfinanzierten Bausparvertrag abgeschlossen. In diesem Text möchte ich den Medienbruch hervorheben, der mich dabei genervt hat und aufzeigen, wie es besser gemacht werden kann.

Der Prozess im Überblick

1. Recherche von Anbietern im Internet
2. Erster Angebotsvergleich im Internet
3. Terminvereinbarung eines Beratungsgesprächs via E-Mail und Telefon
4. Erstes Termin in einer Filiale eines Anbieters
5. Übermittlung der erforderlichen Unterlagen via E-Mail
6. Zweiter Termin zum Vertragsabschluss mit jeder Menge Unterschriften und Papier

Die Punkte Terminvereinbarung, Informationsübermittlung und Vertragsabschluss verdienen in meinen Augen eine genauere Betrachtung

Terminvereinbarung

Die Anbieter, welche ich zuerst ins Auge gefasst hatte, boten eine Online-Terminvereinbarung via Webformular an, wo unter freien Terminen ein passender ausgewählt und gebucht werden konnte. Ich bevorzuge diese Art der Terminvereinbarung, da ich so zu einer Zeit die mir gut passt, direkt einen mir passenden Termin buchen kann, ohne E-Mails hin und her zu schreiben oder in einer Telefonwarteschleife zu hängen. Leider waren im gewünschten Zeitraum keine Termine frei und ich wollte die Angelegenheit nicht weiter aufschieben. Also schieden diese Anbieter aus.

Als nächstes habe ich in der nächstgelegenen Filiale einer bekannten Bausparkasse angerufen. Leider habe ich auch hier beim ersten Versuch niemanden erreicht. Also habe ich eine Terminanfrage mit zwei Terminvorschlägen via E-Mail gesendet. Um ein E-Mail-Ping-Pong zu vermeiden, habe ich auch eine Rückrufnummer mitgesendet. Der Rückruf hat mich dann auch prompt aus meinem Tunnel gerissen, als ich mich auf meine Arbeit konzentriert habe. Die Störung konnte ich verschmerzen, da die Freude überwiegte, noch in der gleichen Woche einen Termin vereinbaren zu könnnen.

Ich bin kein Freund von unangekündigten Anrufen, da sie mich entweder bei der Arbeit unterbrechen oder zu einer Zeit erreichen, in der ich lieber meine Ruhe hätte. Allerdings bevorzuge ich ein kurzes Telefonat oder eine Videokonferenz, wenn sich eine Angelegenzeit damit schneller und sicherer regeln lässt, als mehrere E-Mails austauschen zu müssen. Mein Favorit bleibt jedoch die Online-Terminbuchung.

Informationsübermittlung via E-Mail

Während des Beratungstermins in der Filiale wurde mir eine Finanzierungsmöglichkeit vorgeschlagen, die mir zusagte und wir haben geklärt, welche Unterlagen für den Abschluss benötigt werden.

Auf meine Frage, ob ich sämtliche Unterlagen als PDF via E-Mail senden kann oder alles in Papierform mitbringen muss, wurde zu meiner Freude geantwortet: „Selbstverständlich können Sie mir die Unterlagen als PDF per E-Mail senden oder auf einem USB-Stick mitbringen. Dies erleichtert mir die Ablage und ich muss nicht alles einscannen.“

Unterlagen wie Kontoauszüge und Verdienstbescheinigungen per E-Mail zu versenden, bereitet mir keine Sorgen, da mein E-Mail-Provider Mailbox.org eine Funktion bietet, um E-Mails definitiv sicher zu versenden. Kann zum Mailserver des Empfängers keine verschlüsselte Verbindung aufgebaut werden, wird der Versand abgebrochen. In diesem Fall hätte ich die PDFs auf einem USB-Stick mitgebracht. Dies war in diesem Fall jedoch nicht notwendig.

Exkurs E-Mail-Transport: In meinen Augen ist es eine Selbstverständlichkeit, dass Mailserver verschlüsselten Empfang und Versand unterstützen. Allerdings erfolgt der traditionelle Versand mit dem Simple Mail Transfer Protocol (SMTP) unverschlüsselt. Daher schätze ich die zuvor genannte Funktionalität bei Mailbox.org, um ohne technisches Know-how und zusätzlichen Aufwand sicherstellen zu können, dass eine E-Mail nur versendet wird, wenn dies auf einem verschlüsselten Transportweg erfolgt. Dies erleichtert mir auch die Kommunikation mit meinem Steuerberater.

Während ich persönlich die digitale Kommunikation bevorzuge, befürworte ich zugleich, die Möglichkeit beizubehalten, notwendige Unterlagen ohne Mehrkosten in Papierform einreichen zu können. Zumindest so lange es noch Kunden gibt, die diesen Weg bevorzugen (kein Digitalzwang).

Vertragsabschluss mit vielen Unterschriften und noch mehr Papier

Zum Vertragsabschluss wurde ich dann doch von der Bürokratie eingeholt. Ich musste X Seiten unterschreiben und mir wurden Y Seiten an Papierkram mitgegeben.

Ich finde es richtig, dass Anbieter ihren Kunden Verbraucherschutzinformationen in geeigneter Weise zur Verfügung stellen müssen. Aber sind Anbieter wirklich verpflichtet, dies in Papierform zu tun? Warum geht das nicht wahlweise als PDF? Gleiches gilt für die europäischen Standard-Informationen für Verbraucher-Darlehen. Ich behaupte, die meisten Verbraucher werden diese informationen nicht lesen und das Papier landet ungelesen in der Tonne.

Vorschlag zur Verbesserung

Da sind wir so weit gekommen und am Ende liegt doch wieder ein Stapel Papier von ca. 1 cm Höhe auf dem Tisch. Das muss nicht sein. Das kann auch anders gehen. So können unterschriftsreife Unterlagen vorab als PDF versendet oder auf Tablets bwz. E-Ink-Readern zur Durchsicht/Präsentation zugänglich gemacht werden. So kann das Kleingedruckte auch einfach vergrößert werden. ;-)

Und die eigenhändige Unterschrift kann rechtssicher durch die qualifizierte elektronische Unterschrift mit dem Personalausweis geleistet werden. Dank der Fernsignatur ist dies sogar spontan mit dem neuen Personalausweis und der Ausweisapp auf dem Smartphone möglich.

Es gibt also rechtssichere Alternativen zur eigenhändigen Unterschrift. Was (noch) fehlt, sind Angebote auf Seiten diverser Anbieter. Wenn ihr euch ebenfalls die Möglichkeit der elektronischen Unterschrift wünscht, fragt danach und fordert dies von den Anbietern ein. Ohne Nachfrage wird kein Angebot geschaffen!

Quellen und weiterführende Links

• Unterschriftsfunktion des Pesonalausweises: https://www.die-eid-funktion.de/funktionen-des-personalausweises/unterschriftsfunktion-qes/
• Die qualifizierte elektronische Unterschrift: https://www.personalausweisportal.de/Webs/PA/DE/buergerinnen-und-buerger/der-personalausweis/funktionen/funktionen-node.html#doc14626304bodyText3
• Fernsignaturen mit dem Online-Ausweis: https://www.personalausweisportal.de/Webs/PA/DE/wirtschaft/eIDAS-konforme-fernsignatur/eidas-konforme-fernsignatur-node.html#doc14620566bodyText2

SMLIGHT hat am 13. Februar 2025 die Version v2.8.1.dev9 von SLZB OS mit folgenden Neuerungen veröffentlicht: Generell: SLZB-06Mg24: Verbesserte Unterstützung. SLZB-06Mg24: Neue Zigbee- und Thread-Firmware v20250212 verfügbar. Option zur Aktivierung des IPv6-Protokolls (nur für...

SMLIGHT hat am 31. Januar 2025 die Beta von SLZB OS 2.8.0 mit folgenden Neuerungen veröffentlicht: Zigbee–Hub–Modus – Ihr SMLIGHT–Coordinator kann jetzt als eigenständiger Zigbee–Hub fungieren! Sie benötigen keinen separaten Mini-PC oder Server –...

SMLIGHT hat am Montagabend das Core Firmware Update 2.7.0 für die SLZB-06x Modelle mit folgenden Neuerungen veröffentlicht: Aktive Sockets Multithreading-Verwaltung: Standardmäßig ist 1 aktiver Socket aktiviert (empfohlene Einstellung). Der Benutzer kann dies auf der...

Ende letzten Jahres habe ich euch gezeigt, wie ihr die OpenThread RCP Firmware auf dem SMLIGHT SLZB-07 installiert. Neben den SLZB-07 Modellen gibt es von SMLIGHT noch die SLZB-06 Modelle, welche die im Home...

Während ich den Jahresrückblick 2024 schrieb, wurde mir bewusst, dass ich das im April 2024 behandelte Thema Dokumentation für den Notfall bzw. das digitale Erbe immer noch nicht angegangen hatte. Dies ärgerte mich und so nutzte ich die Zeit zwischen den Jahren, um dies zu ändern.

Der Umschlag für „wichtige Passwörter“

Im ersten Schritt habe ich meine KeePassXC-Datenbank in eine CSV-Datei exportiert und die Zeilen gelöscht, die für meine Erben keine Bedeutung haben. Damit mir die CSV-Datei nicht abhanden kommt, habe ich diese bewusst nur in einem Verzeichnis auf meinem Laptop verarbeitet, das nicht synchronisiert wird und dessen Partition verschlüsselt ist.

Im Anschluss habe ich die CSV-Datei ausgedruckt und in einen Briefumschlag gesteckt. Der Umschlag wurde beschriftet, verklebt und an einem Ort deponiert, der nur meiner Frau und mir bekannt ist.

Kommen im Laufe der Zeit weitere wichtige Passwörter hinzu, wird dieser Prozess wiederholt und der vorhergehende Umschlag vernichtet.

Die IT-Notfalldokumentation

Jeder Systemadministrator schätzt eine gute Dokumentation. Kein Systemadministrator schreibt gerne Dokumentation.

Meinung des Autors

Da die Dokumentation allerdings nicht von allein entsteht, nahm ich mir vor, jeden Tag wenigstens 10 Minuten daran zu arbeiten. Ich öffnete also TeXstudio und tippte auf die Tasten. Die Aussicht, ein feines LaTeX-Dokument zu produzieren, welches in ein gut lesbares PDF mündet, motivierte mich zusätzlich. Einmal angefangen, ging es dann deutlich schneller, als zuerst gedacht und am 27. Dezember war die erste Fassung fertig.

Die roten Rahmen in obigen Bild zeigen an, dass es sich um klickbare Links im PDF handelt. Im Ausdruck erscheinen diese nicht.

Das Dokument enthält Abbildungen der eingesetzten Hardware mit einer Standortbeschreibung, so dass man diese im Zweifel auch schnell findet. Informationen zu Vertrags-, Kundennummern, Online-Kundencentern und Einwahldaten gehören ebenfalls dazu. Ich habe mich bei der Frage, welche Informationen ich aufnehmen soll, daran orientiert, wonach ich gefragt habe, wenn ich bei Kunden vor Ort war und Probleme mit dem Internetzugang oder dem Netzwerk beheben sollte. Eine schematische Übersicht der Netzwerkinfrastruktur gehört natürlich auch dazu:

Das ausgedruckte Dokument habe ich meiner Frau in die Hand gedrückt mit der Bitte um Korrektur und Meinung. Es gefällt ihr und Sie findet es gut, dieses für den Notfall zu haben.

Eine zu Hilfe gerufene IT-Fachkraft kann sich damit schnell einen Überblick verschaffen, was die Zeit zur Lösung eines etwaigen Problems deutlich verkürzen sollte.

Erkenntnisse

Der Aufwand ist geringer als gedacht

Einmal angefangen war die Dokumentation schnell erstellt. Ich habe nicht auf die Uhr geschaut. Doch habe ich, denke ich, nicht länger als drei Stunden daran gesessen. Mich zum Anfangen zu überwinden war schwer, danach lief es wie geschmiert.

Es kommen auch gar nicht viele Seiten zusammen, wenn man sich auf das Wesentliche beschränkt.

Diese Dokumentation ist nicht vollständig

Mir ist bewusst, dass diese Dokumentation nicht vollständig ist. Je länger ich darüber nachdenke, desto mehr Dinge werden mir einfallen, die ich noch aufnehmen möchte. Und das ist vollkommen in Ordnung.

Es ist gut, richtig und wichtig mit den wichtigsten Punkten zu beginnen. Weitere Abschnitte können im Laufe der Zeit ergänzt werden. Wartet bitte nicht, bis ihr glaubt, eine vollständige Gliederung vorliegen zu haben, bevor ihr mit dem Schreiben beginnt. Ich kann mir z.B. vorstellen, noch einen Abschnitt zum Multifuntionsgerät in unserem Netzwerk und zum Troubleshooting häufig auftretender Probleme zu ergänzen.

Mit der Verfügbarkeit steigt auch die Komplexität

Gibt es nur einen Internetanschluss, stellt man schnell fest, ob dieser funktioniert oder nicht. Hat man zwei Internetanschlüsse, die an einer Firewall in einer Failover-Gruppe zusammengeführt werden, wird es schwieriger, denn fällt ein Anschluss aus, merkt man es zuerst gar nicht, wenn der Failover funktioniert.

Kamen früher nur DNS, das WLAN und die ConnectBox in Verdacht, gesellt sich nun die OPNsense zum Kreis der Verdächtigen hinzu. Dies ist evtl. nicht für jeden Heimnetzwerkadministrator oder Laien sofort ersichtlich. Und auch nicht alle Kundendienst-Techniker von Internetdiensteanbietern sind mit der Konfiguration von professionellen Firewalls vertraut.

Mit der vorhandenen Notfalldokumentation und den darin enthaltenen Verweisen auf die OPNsense-Dokumentation kommt man im Notfall zurecht. Ich werde mir jedoch noch Gedanken machen, wie ich dies weiter verbessern kann.

Fazit

Die nun existierende IT-Dokumentation ist definitiv besser, als gar keine zu haben. Es ist keine Schritt-für-Schritt-Anleitung zur Dienst-/Zugangs-Wiederherstellung, bietet aber die wichtigsten Informationen, um sich selbst helfen zu können.

Die Informationen sind ausgedruckt auch dann verfügbar, wenn die gesamte IT ausfällt und z.B. das WLAN oder der Zugriff auf das Dokumenten-Management-System nicht verfügbar sind.

Ich habe ein gutes Gefühl, diese Doku im Schrank liegen zu haben.

Zum Jahresende möchte ich kurz zurückblicken und reflektieren, wie dieses Jahr für meinen kleinen Blog verlaufen ist.

Anzahl veröffentlichter Artikel

• Januar: 4
• Februar: 4
• März: 2
• April: 2
• Mai: 0
• Juni: 4
• Juli: 2
• August: 2
• September: 4
• Oktober: 1
• November: 1
• Dezember: 2

Behandelte Themen

Thematisch haben sich fast alle Artikel mit Freier Software und Open Source beschäftigt oder waren daran angelehnt. Wie auch in den vorangegangenen Jahren habe ich keine bewussten Themenschwerpunkte gesetzt, sonder über die Themen geschrieben, dich mich in der jeweiligen Zeit interessierten und mich beschäftigt haben.

Zu Beginn des Jahres hatte es mir das Thema IPv6 angetan, wozu vier Beiträge erschienen sind:

• Warum beschäftigst du dich mit IPv6?
• Mit einem Dualstack-Proxy Internet-Protokolle verbinden
• Glücksmomente und Zeiten der Schmerzen mit IPv6
• Mit einem Dualstack-Reverse-Proxy Internet-Protokolle verbinden

Das Thema begleitet mich auch weiterhin, jedoch gibt es bisher keine spannenden Neuigkeiten, die ich für berichtenswert halte. Ich fürchte, IPv6 wird sobald nicht die Weltherrschaft an sich reißen.

Ein Thema, welches mir sehr wichtig war und ist, ist die Dokumentation für den Notfall bzw. das digitale Erbe. Wie die Kommentare zu diesem Artikel bezeugen, bin ich nicht der Einzige, der sich darum Gedanken macht. Leider bin ich 2024 kaum damit vorangekommen und schiebe es weiter vor mir her. Dies ärgert mich etwas, da ich mir wünsche, mich für ein so wichtiges Thema besser aufraffen zu können.

In 2024 wurden wir auf allen Kanälen mit Künstlicher Intelligenz, Maschinellem Lernen und großen Sprachmodellen überflutet. Es fällt schon fast schwer noch irgendeine Anwendung oder ein Produkt ohne AI kaufen zu können. Abseits des Hypes habe ich mich ebenfalls mit dem Thema beschäftigt und zwei Beiträge ( [1] und [2]) dazu geschrieben. Ich bin überzeugt, dass die verschiedenen Spielarten der künstlichen Intelligenz unser Leben und unsere Art zu Arbeiten stark beeinflussen und verändern werden. Daher werde auch ich hier am Ball zu bleiben, um nicht von der laufenden Entwicklung abgehängt zu werden.

Fazit

Damit sind 2024 insgesamt 26 Artikel erschinen. Das sind 19 weniger als in 2023. Mein selbst gestecktes Ziel, jeden Monat mindestens zwei Artikel zu veröffentlichen habe ich ebenfalls nicht erreicht. Da dies mein Hobby ist und mir primär Freude bereiten soll, setze ich mich durch diese Zielverfehlung nicht unter Druck.

Das Jahr 2025 lasse ich ohne große Ziele und Bestrebungen auf diesen Blog zukommen. Nur eines ist sicher, ich werde meine Texte weiterhin selbst und ohne KI-Unterstützung schreiben. Denn damit würde ich mir nur selbst die Freude am Bloggen nehmen.

Ich freue mich, wenn ich auch 2025 wieder interessantes Wissen in meinen Texten mit euch teilen kann. Ich wünsche euch einen guten Rutsch ins Jahr 2025!

Unser Buch Coding mit KI wird gerade übersetzt. Heute musste ich diverse Fragen zur Übersetzung beantworten und habe bei der Gelegenheit ein paar Beispiele aus unserem Buch mit aktuellen Versionen von ChatGPT und Claude noch einmal ausprobiert. Dabei ging es um die Frage, ob KI-Tools technische Diagramme (z.B. UML-Diagramme) zeichnen können. Die Ergebnisse sind niederschmetternd, aber durchaus unterhaltsam :-)

UML-Diagramme

Vor einem halben Jahr habe ich ChatGPT gebeten, zu zwei einfachen Java-Klassen ein UML-Diagram zu zeichnen. Das Ergebnis sah so aus (inklusive der falschen Einrückungen):

+-------------------------+
|         Main            |
+-------------------------+
| + main(args: String[]): void |
| + initializeQuestionPool(): List<Question> |
+-------------------------+

+-------------------------+
|        Question         |
+-------------------------+
| - text: String          |
| - answers: List<Answer> |
| - correctAnswers: List<Answer> |
+-------------------------+
| + Question(text: String, answers: List<Answer>, 
|            correctAnswers: List<Answer>) |
| + askQuestion(): void   |
| - validateAnswer(userInput: String): boolean |
+-------------------------+

Dabei war ChatGPT schon damals in der Lage, PlantUML- oder Mermaid-Code zu liefern. Der Prompt Please generate PlantUML code instead liefert brauchbaren Code, der dann in https://www.planttext.com/ visualisiert werden kann. Das sieht dann so aus:

Heute habe ich das ganze Beispiel noch einmal ausprobiert. Ich habe also den Java-Code für zwei Klassen an ChatGPT übergeben und um ein UML-Diagramm gebeten. Vorbei sind die ASCII-Zeiten. Das Ergebnis sieht jetzt so aus:

Leider kann ich hier keinen Link zum ganzen Chat-Verlauf angeben, weil ChatGPT anscheinend nur reine Text-Chat-Verläufe teilen kann.

Visualisierung eines Docker-Setups

Beispiel zwei ergibt sich aus zwei Prompts:

Prompt: I want to build a REST application using Python and Django. The application will run in a Docker container. Do I need a proxy server in this case to make my application visible to the internet?

Prompt: Can you visualize the setup in a diagram?

In der Vergangenheit (Mitte 2024) lieferte ChatGPT das Diagramm als ASCII-Art.

+---------------------------+
|      Client Browser       |
+-----------+---------------+
            |
            v
+-----------+---------------+
|       Nginx Reverse Proxy |
|  (Handles SSL, Load       |
|   Balancing, etc.)        |
+-----------+---------------+
            |
            v
+-----------+----------------+
| Docker Container Network   |
|                            |
|  +----------+   +---------+|
|  |  Web     |   |  DB     ||
|  | Container|   |Container||
|  +----------+   +---------+|
|   (Django)       (Postgres)|
+----------------------------+

Erst auf die explizite Bitte liefert es auch Mermaid-Code, der dann unter https://mermaid.live/ gezeichnet werden kann.

Heute (Dez. 2024) gibt sich ChatGPT nicht mehr mit ASCII-Art ab sondern leitet den Diagrammwunsch an DALL-E weiter. Das Ergebnis ist eine Katastrophe.

Auch Claude.ai zeichnet selbstbewusst ein Diagramm des Docker-Setups. Dabei wird intern Mermaid verwendet.

Fazit

Die Diagramme haben durchaus einen hohen Unterhaltungswert. Aber offensichtlich wird es noch ein wenig dauern, bis KI-Tools brauchbare technische Diagramme zeichnen können. Der Ansatz von Claude wirkt dabei erfolgsversprechender. Technische Diagramme mit DALL-E zu erstellen wollen ist doch eine sehr gewagte Idee von OpenAI.

Die besten Ergebnisse erzielen Sie weiterhin, wenn Sie ChatGPT, Claude oder das KI-Tool Ihrer Wahl explizit um Code in PlantUML oder Mermaid bitten. Den Code können Sie dann selbst visualisieren und bei Bedarf auch weiter optimieren.

Dies ist ein Update des Artikels aus dem letzten Jahr. Eine aktuelle Hardwareübersicht gibt es hier.

Smartphone

Als privates Mobiltelefon benutze ich seit 2022 ein Samsung Galaxy S22 mit einem Congstar-Tarif, welcher mich im Monat 10,- EUR kostet. Ich bin mit dem Gerät weiterhin zufrieden und plane, es in 2025 ebenfalls zu nutzen.

Im Folgenden führe ich einige von mir genutzte Apps auf, mit einer kurzen Erklärung, wofür ich diese verwende. Wo möglich verlinke ich in den F-Droid Store. Wo dies nicht möglich ist, führen diese in den Google Play Store.

Hier die am häufigsten verwendeten Apps zählen in alphabetischer Reihenfolge:

• Aegis Authenticator (F-Droid) ist meine favorisierte 2FA App
  • Mittels der integrierten Backup- und Import-Funktion nutze ich die gleichen Daten auch auf meinem Diensthandy; so bleibt der Zugriff auf meine Online-Accounts auch bei Verlust eines Telefons erhalten
• Amazon – Ja, ich kaufe bevorzugt online, da es bequem ist und es bei Rücksendungen und Umtausch keine Diskussionen gibt
• ChatGPT (Google Play Store) nutze ich auf dem Handy nur sehr sporadisch; ob es bessere Ergebnisse als eine klassische Suchanfrage liefert, kann ich aktuell noch nicht beurteilen
• Element (F-Droid)
  • Veröffentlichung von Hinweisen zu Blog-Artikeln in #my-it-brain:matrix.org
  • Hier lese ich vor allem passiv in wenigen Kanälen
  • Vereinzelte Nutzung zu individueller Kommunikation
  • Abstimmung von Konferenzbesuchen und Beiträgen
• Fedilab (F-Droid) ist mein Zugang ins Fediverse, wobei ich dort ausschließlich Mastodon nutze
• Firefox (Google Play Store) zur Nutzung von Online-Accounts
• Firefox Klar (Google Play Store) zum Surfen im Internet
• K-9 Mail (F-Droid)
  • Primär zum Lesen von E-Mail
  • Seltener zum Schreiben und Antworten auf E-Mail, hierfür bevorzuge ich den Laptop
• Kalender (Google Play Store)
  • Für mich die wichtigste App auf dem Telefon
  • Einbindung diverser CalDAV-Kalender mittels DAVx⁵ (Google Play Store)
• KeePassDX (F-Droid), um auch unterwegs auf wichtige und häufig benötigte Passwörter zugreifen zu können
• LinkedIn (Google Play Store) nutze ich auch regelmäßig unterwegs
• Signal (Google Play Store), da einige Kontakte nur hierüber erreichbar sind (2-3)
• Threema (Google Play Store) ist der Messenger, den ich mit Abstand am häufigsten verwende
  • Auch als Threema Libre bei F-Droid erhältlich
• Perplexity (Google Play Store) – Ich mag, dass diese GenKI Referenzen benennt, aus denen sie Informationen genutzt hat

Zu den eher sporadisch genutzten Apps zählen in alphabetischer Reihenfolge:

• EasyPark (Google Play Store)
  • Weil ich es nicht mag, wenn das Parkzeitende mein Leben bestimmt
  • Weil mir häufig das Kleingeld für die Parkuhr fehlt
• Merlin Bird ID (Google Play Store)
  • Nutze ich gern, um Vogelstimmen zu bestimmen
  • Ich möchte gern wissen, wer in meiner Nachbarschaft lärmt ;-)
  • Danke an Jörn C. für diesen Tipp
• ObsIdentify (Google Play Store)
  • Zur Bestimmung von allem was in der Natur wächst, kreucht, fleucht und kein Vogel ist
  • Auch hier geht mein Dank an Jörn C. für den Tipp
• Post & DHL (Google Play Store), damit wenigstens das Porto digital entrichtet wird, wenn ich schon einen Brief versenden muss
• Tank-Datenbank (Google Play Store), da ich nichts zu verschenken habe
  • Freue mich über empfehlenswerte Alternativen

Evtl. ist euch aufgefallen, dass eine prominente App in obiger Aufzählung fehlt. Tatsächlich widerstehe ich weiterhin dem sozialen Druck und verweigere mich der Nutzung von WhatsApp. Der Verzicht auf WhatsApp schnitt mich leider ausgerechner bei der Freiwilligen Feuerwehr von einem Teil der Kommunikation ab. Daher freue ich mich nun umso mehr, dass unsere Feuerwehr zur Planung von Dienstabenden, Veranstaltungen und sonstigen Terminen auf Spond (Google Play Store) umgestiegen ist.

Ich nutze auch Online-Banking-Apps auf dem Smartphone. ich nutze diese z.B., um am Laptop getätigte Überweisungen oder Online-Einkäufe zu autorisieren. Darüber hinaus schätze ich die Benachrichtigung über getätigte Umsätze.

Insgesamt sind aktuell 168 Apps installiert. Ehrlicherweise werde ich vermutlich erst ausmisten, wenn der Speicher knapp wird.

Ach ja, telefonieren tue ich damit natürlich auch. ;-)

Tablet

Seit Mitte 2019 [verwende ich] auch ein Samsung T830 Galaxy Tab S4 Wi-Fi Tablet. Durch seine 10,5 Zoll (ca. 27 cm) Bildschirmdiagonale, das geringe Gewicht und mit der App ReadEra eignet es sich hervorragend zum Lesen von PDF-Dateien und E-Books.

https://www.my-it-brain.de/wordpress/meine-privaten-arbeitsmittel-anfang-2022/

Darüber hinaus nutze ich das Gerät:

• Für Online-Shopping (mehr als das Smartphone)
• Lesen im Internet (Blogs, Dokus, etc.) mit Firefox Klar

Dabei verwende ich mehr oder weniger die gleichen Apps wie auf dem Smartphone. Für den Zugriff auf Mastodon verwende ich hier statt Fedilab die App Tusky (F-Droid).

Seit 2024 neu auf dem Tablet sind FeedMe (Google Play Store) und Wallabag (Google Play Store). FeedMe teste ich als Alternative zu Feedly (Google Play Store), da dieser die Synchronisierung mit meiner FreshRSS-Instanz unterstützt. Er ist etwas langsam, ansonsten zufriedenstellend. In Wallabag speichere ich Artikel, die ich später lesen oder für Workshops, Talks und Blog-Artikel nutzen möchte.

Laptop

• Ich arbeite weiterhin mit einem Lenovo ThinkPad T14s (seit 2021)
• Das Betriebssystem wurde im Laufe der Zeit von Fedora 37 auf Fedora 40 aktualisiert; Das Upgrade auf Fedora 41 folgt bald
• Nach Rambox ist auch hamsket entsorgt worden, da mich diese Apps im Laufe der Zeit doch mehr genervt als unterstützt haben
  • Dienste wie Element, Mastodon, GMail, Slack, etc. nutze ich jetzt direkt im Webbrowser
  • Ich nutze die Funktion Tabs zu pinnen, um häufig verwendete Dienste im Browser im schnellen Zugriff zu haben

Der Laptop ist mein Hauptarbeitsmittel, den ich für so gut wie alle anfallenden Aufgaben verwende. Lediglich zum Lesen von E-Books bevorzuge ich das Tablet und zum Instant Messaging das Smartphone.

• Mein Lieblingsbrowser ist Firefox
• Mein Lieblingseditor ist Vim
• Thunderbird ist die Anwendung meiner Wahl für Aufgaben, E-Mail und Kalender
• TeXstudio ist mein Lieblings-LaTeX-Editor

Ich habe immer mal wieder Evolution ausprobiert, da dies eine bessere Integration in GNOME bietet. Doch bin ich nie damit warm geworden. Da ich mehrere E-Mail-Konten bei verschiedenen Anbietern sowie Kalender für verschiedene Zwecke habe, finde ich die Zusammenführung und Nutzung in Thunderbird ideal.

Desktop-/Server-PC

Mein ehemaliger Desktop-PC ist in ein 19-Zoll-Gehäuse und mit diesem in einen Serverschrank im Keller umgezogen. Die ganze Geschichte dazu kann in „Ein Serverschrank mit Kompromissen“ nachgelesen werden.

• Ein Selbstbau mit RHEL dient mir als Libvirt/KVM-Hypervisor für virtuelle Maschinen
  • Mainboard: B550-A PRO (MS-7C56)
  • CPU: AMD Ryzen 5 PRO 4650G with Radeon Graphics
  • RAM: 32 GB DDR4
  • Festplatten:
    • ADATA SU800 256 GB
    • SanDisk SSD PLUS 1000GB

Auf diesem Rechner laufen dauerhaft zwei virtuelle Maschinen:

• Home Assistant
• Eine RHEL 9 VM zur Bereitstellung einer rootless Podman Umgebung; darüber werden bereitgestellt:
  • Paperless-ngx via podman-compose; siehe auch: Mein Paperless-NGX-Mini-Konzept
  • Uptime Kuma – Meine Monitoring-Lösung

Als dauerhaft laufender Rechner führt dieser Host meine Cronjobs und Ansible-Playbooks aus, erzeugt Backups und kopiert/synchronisiert Daten von hier nach dort.

Die Untersützung von Podman bzw. der weiteren Container-Tools Buildah und Skopeo in RHEL ist super. Die kostenlose Developer Subscription for Individuals ermöglicht mir die produktive Nutzung von bis zu 16 RHEL-Servern. Das sind mehr als genug für meine privaten Zwecke.

Sonstige Geräte im Netzwerk

• Mein Brother DCP-540CN wurde dieses Jahr nach 18 Jahren ausgemustert; ich nutze jetzt einen Brother MFC-J890DW im Haus mit, falls ich mal etwas drucken muss
• Meine Synology Diskstation DS213air dient mir seit 2013 als Netzwerkspeicher (NAS)
  • Dient als Backup-Senke
  • Beheimatet Foto-, Video- und Musiksammlung
  • Stellt Netzlaufwerke für Windows und Linux bereit
  • Bietet aktuell 2,7 TB Speicherkapazität (2 Disks als RAID 1)
  • Externe USB-Festplatte (500 GB) für lokale Backups
  • Sie ist alt, aber verrichtet zuverlässig ihren Dienst
• Neu seit diesem Jahr dabei ist eine Protectli VP2410 – 4 Port Intel ® CeleVP2410 – 4 Port Intel ® Celeron J4125ron J4125 mit OPNSense
  • Dieses Gerät lag seit 2023 ungenutzt herum, da sich die Anschaltung des Glasfaseranschlusses um ein Jahr verzögert hat; jetzt ist er in Betrieb
  • Die OPNSense wird in 2025 meinen Pi-Hole ablösen und den Zugang zum Internet über Dual-WAN bereitstellen

Cloud-Dienste

• Auf einem Virtual Private Server bei Contabo betreibe ich auf Debian stable
  • diesen WordPress Blog sowie
  • eine Nextcloud als rootless Podman Container
• Meine wichtigen E-Mails und Kalender liegen bei Mailbox.org
• Meine weniger wichtigen E-Mails liegen bei GMail
• Meine Domain wird bei ClouDNS verwaltet

Hier hat es im laufenden Jahr keine Änderungen gegeben. Ich gehe davon aus, dass es hier in 2025 ebenfalls keine Änderungen geben wird. Drei neue Dienste sind hinzugekommen, die ich bei adminforge.de nutze. Dies sind:

• DNSforge
• Bandbreite messen
• ToDo App
• FreshRSS Reader
• Linkwarden
• Wallabag

Die letzten vier befinden sich noch in der Testphase. Ob die Nutzung in 2025 anhält, werdet ihr im nächsten Rückblick erfahren können.

Ich freue mich, wenn euch dieser kleine Überblick gefällt und ihr vielleicht die ein oder andere Inspiration darin findet. Ich freue mich auch, wenn ich in euren Blogs lesen kann, womit ihr 2024 so gearbeitet habt.

Im Beitrag „SMLIGHT SLZB-07: OpenThread RCP Firmware flashen“ habe ich euch gezeigt, wie ihr die Openthread RCP Firmware auf den SMLIGHT SLZB-07 flasht. In diesem Beitrag zeige ich euch nun, wie ihr mit dem...

Kürzlich habe ich auf Fryboyter diesen Artikel gelesen: Wie sollte man Veröffentlichungen versionieren?

Meine Gedanken zu dem Artikel und dem Thema möchte ich an dieser Stelle mit Fryboyter und euch teilen.

Fryboyter favorisiert nach eigener Darstellung Calendar Versioning (CalVer), da dies seiner Meinung nach aussagekräftiger ist, als z.B. 0.78.1, was sehr stark nach Semantic Versioning (SemVer) aussieht. Meiner Meinung nach kann man dies nicht pauschal sagen, da beide Versionsschemata ihre eigenen Vor- und Nachteile haben. Doch wann sollte man zu welchem Schema greifen?

Calendar Versioning

Die folgende Liste ist eine Übersetzung des englischen Textes, welcher hier zu finden ist. Wenn einer der in dieser Liste genannten Punkte auf ein Projekt zutrifft, scheint CalVer ein geeignetes Schema für die Versionierung zu sein.

• Hat Ihr Projekt einen großen oder ständig wechselnden Umfang?
• Große Systeme und Frameworks, wie Ubuntu und Twisted.
• Amorphe Gruppen von Dienstprogrammen, wie Boltons.
• Ist Ihr Projekt in irgendeiner Weise zeitkritisch? Beeinflussen externe Änderungen neue Projektveröffentlichungen?
• Geschäftliche Anforderungen, wie Ubuntus Fokus auf Unterstützungstermine.
• Sicherheitsupdates, wie certifi’s Notwendigkeit, Zertifikate zu aktualisieren.
• Politische Veränderungen, wie die Handhabung von Zeitzonenänderungen durch die IANA-Datenbank.

Einige Betriebssysteme wie z.B. Ubuntu haben einen festen Veröffentlichungsrythmus und Unterstützungszeitraum. So werden Ubuntu LTS Versionen ohne Zusatzverträge für 5 Jahre unterstützt und mit Aktualisierungen versorgt. Bei Ubuntu 24.04 LTS kann man bereits am Namen erkennen, wie alt dieses Release ist und wie lange es mit Aktualisierungen versorgt wird. Ubuntu veröffentlicht Aktualisierungen für die enthaltenen Pakete in unregelmäßigen Abständen, meist sobald diese verfügbar sind. Aufgrund der vielen enthaltenen Pakete und der Aktualisierungsrichtlinie scheint SemVer (siehe nächster Abschnitt) hier nicht vorteilhaft zu sein.

Bei Debian 12, RHEL 9 oder SLES 15 erkennt man das Datum der Veröffentlichung hingegen nicht. Hier hilft nur ein Blick in die jeweilige Versionshistorie der Projekte, um Informationen über den Zeitpunkt der Veröffentlichung und der jeweiligen Unterstützungszeiträume zu finden.

Semantic Versioning

Auf Grundlage einer Versionsnummer von MAJOR.MINOR.PATCH werden die einzelnen Elemente folgendermaßen erhöht:
1. MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden,
2. MINOR wird erhöht, wenn neue Funktionalitäten, die kompatibel zur bisherigen API sind, veröffentlicht werden, und
3. PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.

Quelle: https://semver.org/lang/de/

SemVer ist stringent, einfach nachzuvollziehen und bietet für mich als Systemadministrator die folgenden Vorteile.

Wird PATCH erhöht, weiß ich, dass lediglich Fehler behoben wurden, sich am Funktionsumfang einer Anwendung jedoch nichts ändert. Das Einzige, was mir hierbei den Tag vermiesen kann, sind Regressionen. Das Risiko, dass irgendetwas kaputtgeht oder schlimmer wird, ist jedoch gering.

Wird MINOR erhöht, weiß ich, dass die Anwendung neue Funktionalität enthält und ich weiß, dass nun ein genauerer Blick erforderlich ist, um zu entscheiden, ob diese Funktionalität in meiner Umgebung bereitgestellt werden soll bzw. darf. Gegebenenfalls sind vor einer Aktualisierung Anwenderschulungen durchzuführen und interne Prozessbeschreibungen zu aktualisieren, bevor die neue Version zur Nutzung freigegeben werden kann.

Einem an Featureritis erkrankter Nerd mag jede neue Funktion gefallen. Unzureichend geplante Veröffentlichungen neuer Funktionen in Unternehmen können hingegen interessante Folgen haben.

Wird MAJOR erhöht, ist ein Blick in die Release Notes angeraten. Denn man weiß schon mit einem Blick auf die Versionsnummer, dass diese Version Breaking Changes enthält. Dies können sein:

• API-inkompatible Änderungen
• Entfallene bzw. entfernte Funktionalität
• Geänderte Architektur
• Geändertes Format der Konfigurationsdatei(en)
• etc.

Eine solche Aktualisierung kann man in aller Regel nicht ohne sorgfältige Planung installieren. Das Risiko, dass dabei etwas kaputtgeht und Stress und Produktionsausfall folgen ist einfach zu groß.

Aussagekraft

Fryboyter schreibt: „Zumal meiner Meinung nach 2024.10.11 aussagekräftiger als 0.78.1 ist.“

Aber ist es wirklich aussagekräftiger? Wenn ich nur das Datum sehe, weiß ich lediglich, wann die Version veröffentlicht wurde. Welchen Funktionsumfang die Version hat, welche Änderungen es zur vorhergehenden Version es gibt, ob diese Version stabil ist oder ob es die aktuellste Version ist, erkennt man nicht. Bei zwei Daten erkennt man zumindest, welches die aktuellere Version ist.

Sehe ich nur 0.78.1, weiß ich nicht, wann diese Version veröffentlicht wurde. Ich sehe jedoch auf den ersten Blick, dass sich diese Version in einer initialen Entwicklungsphase befindet, der Funktionsumfang nicht abschließend definiert ist und sich jederzeit ändern kann. Kurz gesagt, mit jeder weiteren Erhöhung von MINOR und PATCH ist damit zu rechnen, dass sich das Verhalten und der Funktionsumfang signifikant ändern. Da die einzelnen Elemente bei SemVer ausschließlich erhöht jedoch nie gesenkt werden, kann man bei Vorliegen von zwei Versionsnummern der gleichen Anwendung erkennen, welches die aktuellere ist. Details zu Änderungen gegenüber der Vorgängerversion verrät SemVer zwar auch nicht, doch kann ich den Umfang der Änderungen erkennen. Für mich besitzt SemVer damit in den meisten Fällen die größere Aussagekraft.

Die Frage wann es Zeit für Version 1.0.0 ist, beantwortet SemVer wie folgt:

Wenn die Software schon in der Produktion verwendet wird, sollte sie bereits in Version 1.0.0 vorliegen. Falls eine stable API existiert, auf die sich Nutzer bereits verlassen, sollte es ebenfalls die Version 1.0.0 sein. Auch wenn Kompatibilität zu vorherigen Versionen bereits eine wichtige Rolle spielt, ist Version 1.0.0 angebracht.

Quelle: https://semver.org/lang/de/#woher-wei%C3%9F-ich-wann-es-zeit-ist-version-100-zu-ver%C3%B6ffentlichen

Abschließende Bemerkung

Ich gehöre tendenziell eher zu Team SemVer und denke, dass dies eine höre Aussagekraft als CalVer besitzt.

Grundsätzlich halte ich es für sinnvoll und wichtig, wenn sich Entwickler bzw. Organisationen Gedanken machen, welches Versionsschema am besten zu ihrem Projekt passt.

Wie denkt ihr darüber? Hinterlasst doch gern einen Kommentar mit eurer Meinung oder veröffentlicht einen eigenen Text dazu in eurem Blog.

In meinem heutigen Beitrag kommentiere ich den 2024 State of Open Source Report und vergleiche die enthaltenen Ergebnisse mit meinen persönlichen Erfahrungen.

Der 2024 State of Open Source Report (im Folgenden auch als Bericht oder Report bezeichnet) wurde von der Firma OpenLogic in Zusammenarbeit mit der Open Source Initiative (OSI) und der Eclipse Foundation erstellt. Der Bericht kann hier als PDF kostenlos heruntergeladen werden (der Haken für den Empfang von Kommunikation muss nicht gesetzt werden). Ich werde in diesem Text häufig auf den Bericht als Quelle verweisen, sodass ich euch empfehle, den Report ebenfalls verfügbar und im besten Fall gelesen zu haben. Seitenangaben beziehen sich auf das PDF mit dem Bericht.

Transparenzhinweis: Ich arbeite als Technical Account Manager für die Firma Red Hat. Meine Arbeit beeinflusst meinen Blick auf den Bericht. Dieser Kommentar stellt ausschließlich meine persönliche Sicht dar.

Informationen zum Bericht

Im Zeitraum vom 10. Oktober bis 8. November 2023 wurde weltweit eine anonyme Umfrage durchgeführt, welche insgesamt 2046 Antworten erhielt (siehe S. 4-6). Es findet sich darin kein Hinweis, ob die Umfrage repräsentativ ist. Es werden jedoch Angaben darüber gemacht, aus welcher Weltregion, Unternehmensgröße und Job-Rolle die Antworten stammen, um diese einordnen zu können.

Nutzung und Verbreitung von Open Source in Unternehmen

Es freut mich zu lesen, dass 95 Prozent der Antworten belegen, dass der Anteil an Open Source in den an der Umfrage teilnehmenden Unternehmen gestiegen (67,57 %) oder gleichgeblieben (27 %) ist (siehe S. 7). Auffällig ist allerdings auch, dass im Mittleren Osten 22,22% angaben, dass der Einsatz von Open Source zurückgegangen ist. Unternehmen, die gar keine Open-Source-Software einsetzen, haben vermutlich nicht an der Umfrage teilgenommen. Der Bericht macht dazu keine Aussage.

Auf Seite 8 findet sich die Aussage, dass 40 % aus der C-Level-Abteilung (z.B. CEO, CTO, CIO, CFO, etc.) angegeben haben, dass der Anteil an Open Source gleichgeblieben ist, während über 60% der Teilnehmer aus technischen Rollen eine Zunahme von Open Source sehen. Laut Bericht deutet dies auf eine mögliche Entfernung bzw. Trennung der Führung von der Basis hin. Dieser Ansicht mag ich mich nicht anschließen, da immerhin 58,46% der Führungskräfte ebenfalls eine Zunahme von Open Source in ihren Unternehmen sehen; das ist von den 60% der technischen Rollen doch nun wirklich nicht weit weg.

Interessant finde ich die genannten Gründe für den Einsatz von Open Source in Unternehmen (siehe S. 9-10). Ein wenig betrübt es mich, dass knapp 37 % „Keine Lizenzkosten“ und „Kostenminimierung“ als wichtigstes Argument für den Einsatz von Open Source nannten; hat Open Source in meinen Augen doch so viel mehr zu bieten, während sich das Ziel der Kostenminimierung nicht in jedem Fall erreichen lässt.

Meiner persönlichen Erfahrung nach verschieben sich die Aufwände in vielen Fällen lediglich. So stellten einige Organisationen fest, dass der Einsatz kostenlos verfügbarer Open-Source-Software mit einem höheren Personalbedarf bzw. einem erhöhten Aufwand für Wissensaufbau und Fehleranalysekompetenz einhergeht. Hier finden sich zum Teil die Kosten wieder, die man zuvor für Lizenzen und externen Support aufgewendet hat. Es gibt hier keine pauschal gültige Empfehlung. Jedes Unternehmen muss für sich selbst bewerten, ob es das erforderliche Personal selbst aufbauen bzw. einstellen kann oder ob der Einkauf externer Unterstützung in Zeiten von Fachkräftemangel nicht doch günstiger ist.

Macht man sich von externem Wissen abhängig, läuft dies dem Ziel entgegen, sich mit Open Source unabhängiger von einzelnen Herstellern machen zu wollen. Hier ist darauf zu achten, wie viel Auswahl an Anbietern am Markt besteht.

Ich nehme allerdings ebenfalls wahr, dass die wirtschaftliche Situation in vielen Unternehmen angespannt ist und kann das Ziel, Kosten zu reduzieren, nachvollziehen. Ich hoffe darauf, dass Unternehmen, die Open Source zur Kostensenkung einführen, auch die weiteren Vorteile, wie z.B. die Vermeidung von Vendor Lock-ins sowie offene Standards und Interoperabilität erkennen und zu schätzen lernen. Die zuletzt genannten Punkte sind immerhin 21 % der Befragten heute schon wichtig.

Herausforderungen beim Einsatz von Open Source

Wie bereits im vorangegangenen Abschnitt erwähnt, ist für den Einsatz von Open Source die Verfügbarkeit des notwendigen Wissens und entsprechende Fertigkeiten notwendig. Immerhin 38 % der befragten Unternehmen sehen es als eine Herausforderung an, das notwendige Wissen und die Fähigkeiten zum effizienten Einsatz von Open Source im Unternehmen verfügbar zu machen (S. 13). Dabei versuchen sie, dies auf unterschiedlichen Wegen verfügbar zu machen. Das Diagramm auf Seite 14 zeigt, dass die Mehrheit mit 45% auf Training des eigenen Personals setzt. Weitere 38% versuchen, Personal mit dem benötigten Wissen einzustellen.

Ich arbeite aktuell selbst in einem Unternehmen, in dem die Fort- und Weiterbildung der eigenen Mitarbeiter einen hohen Stellenwert besitzt. Ich freue mich sehr, dass mein Unternehmen mich aktiv dabei unterstützt, mein Wissen aktuell zu halten und in verschiedenen Bereichen auszubauen.

Ohne einen Beleg zur Hand zu haben, meine ich mich zu erinnern, dass die Qualifizierung bestehenden Personals für ein Unternehmen häufig günstiger ist, als neues Personal einstellen und einarbeiten zu müssen. Falls ihr dazu eine gute Quelle habt, teilt sie mir doch bitte in den Kommentaren mit.

Updates und Patches

Auf Seite 13 des Berichts findet sich die Aussage, dass es für 40 % aller Umfrageteilnehmer eine große bis sehr große Herausforderung darstellt, die Systeme und Anwendungen auf einem aktuellen Stand (Patchlevel) zu halten.

Nach meiner Erfahrung zählen ein geringer Automatisierungsgrad, unzureichende Testprozeduren und eine zu starre Aufbauorganisation mit komplizierten und langwierigen Abstimmungsprozessen zu den größten Problemen in diesem Bereich. Wenn Wartungsfenster zur Installation von (Sicherheits-)Updates mit 3-6 Monaten Vorlauf angekündigt und geplant werden müssen und es keinen Prozess für schnelle Notfallupdates gibt, kann man halt nicht innerhalb von 72 Stunden reagieren und Schwachstellen schließen. Wenn die Kommunikation zwischen Betriebs- und Anwendungs-Team rein über Ticketsystem läuft, hat man zwar einen sauberen Prozessablauf mit Genehmigungs- und Prüfschritten; werden die Schritte jedoch alle manuell ausgeführt, darf man sich nicht wundern, wenn Updates vier Tage statt vier Stunden brauchen.

Noch immer begegnen mir im Gespräch Szenarien, wo Anwendungsteams nicht über Testsysteme und Testpläne verfügen. Die Folgen eines Updates/Patches lassen sich nur direkt in Produktionsumgebung prüfen. Bei Fehlern kommt es dann sofort zu einer Beeinträchtigung des Dienstes und der Stresslevel steigt. Wo es bereits an der Fähigkeit mangelt, Änderungen zeitnah zu verifizieren, fehlt oft auch die Möglichkeit, auf einen zuletzt als funktionierend bekannten Stand zurückzurollen. Hier bleibt nur der Weg voran unter Einsatz aller verfügbaren Ressourcen, bis das Problem behoben oder das Unternehmen insolvent ist.

Nicht immer ist es ganz so dramatisch. Häufig löst mangelnde Automation einen langwierigen Abstimmungsprozess aus. Viele Personen müssen Zeit einplanen, um diverse Schritte im Prozessablauf manuell auszuführen, zu testen und zu dokumentieren. Schnell sind 3,6 kg Excel-Dateien erstellt, das Update aber immer noch nicht abgeschlossen.

Ich erinnere mich an die schöne Zeit zwischen 2011 und 2014. Unser damaliger stellvertretender Abteilungsleiter hatte die Idee, DevOps auszuprobieren. Dazu wurden Teams aus Entwicklern und Systemadministratoren gebildet, die nun gemeinsam für den Betrieb und die Verfügbarkeit bestimmter Anwendungen verantwortlich waren. Statt den auf Papier dokumentierten Verantwortungsübergängen und dem daraus häufig folgenden Hin- und Herschiebens des schwarzen Peters saßen wir jetzt gemeinsam in einem Boot und hatten gemeinsame Ziele. Wir lernten dabei die Sicht- und Arbeitsweise der jeweils anderen Job-Rolle kennen und zu verstehen. Und im gemeinsamen Dialog, gelang es uns Automationsprozesse zu entwickeln, um Updates schneller und erfolgreicher durchführen zu können. Leider überlebte dieses Modell die Zeit nicht. Heute ist mir bekannt, dass mit dem Wechsel dieses Modells auch die alten Probleme zurückkehrten und deutlich weniger Updates durchgeführt werden.

Oft liegt die Verantwortung für die Installation von Updates/Patches beim Betrieb. Jedoch ist nur das Anwendungsteam in der Lage, die korrekte Funktionsfähigkeit der Anwendung/des Dienstes zu beurteilen. Auch wenn manche Abteilungsleiter es nicht gerne hören, es geht am besten gemeinsam, mit kurzen Abstimmungswegen über Team- und Abteilungsgrenzen hinweg.

Der zweite Schlüssel zum Erfolg ist Automation. Lasst den Automaten die einzelnen Prozessschritte ausführen, welche in der Regel wie folgt aussehen:

1. Anwendung bzw. Dienste stoppen
2. Updates/Patches installieren
3. System neu starten
4. Anwendung bzw. Dienste starten
5. Anwendung/Dienst auf korrekte Ausführung testen
6. Bei Fehlschlag –> Rollback bzw. bei Erfolg –> Update erfolgreich

Zeit und Energie, die hier investiert werden, zahlen sich in aktuellen Systemen mit weniger Sicherheitslücken aus. Schafft einen Raum, in dem sich eure Experten aus Systemadministration und Anwendungsentwicklung austauschen und abstimmen können.

Selbstverständlich haben die Qualität der vom Hersteller bereitgestellten Updates ebenfalls einen großen Einfluss auf den Erfolg von Patchinstallationen. Sollte es hier wiederholt Probleme geben und keine Besserung in Sicht sein, ist ggf. ein Wechsel des Anbieters in Erwägung zu ziehen. Doch bevor ihr euch Hals über Kopf in die Migration stürzt, denkt daran, dass das Gras auf der anderen Wiese stets grüner wirkt, als es ist. Es geht nicht ohne ausführliche Tests.

Ich wünsche allen, die sich für Updates und Patches Nächte und Wochenenden um die Ohren schlagen müssen, dass sich die Situation für euch bessert und sich dies im nächsten Open Source Statusbericht ablesen lässt.

Wartung von End-of-Life Versionen

Manche nennen es den Giftschrank, andere die Schmuddelecke. Gemeint sind damit Betriebssystem-Releases und Anwendungen, die das Ende ihres Lebenszyklus erreicht oder schon überschritten haben. Laut Seite 13 des Berichts ist dies für 42 % der Umfrageteilnehmer ein Thema.

Die Gründe warum diese Systeme noch existieren, lauten häufig sehr ähnlich. Fast immer läuft eine geschäftskritische Anwendung darauf,

• Von der im Unternehmen niemand mehr weiß, wie sie funktioniert, um sie auf ein neues Betriebssystem zu migrieren
• Für deren Migration keine Ressourcen verfügbar sind
• Mit der komplizierte und langwierige Abstimmungsprozesse zur Migration verbunden sind; niemand will das Ding anfassen
• Die für keine aktuellere Betriebssystem-Version zertifiziert ist

Im hier kommentierten Bericht wird auf Seite 15 ausgewiesen, dass 22 % der Befragten noch CentOS einsetzten, dessen Release 7 seit dem 30. Juni 2024 End-of-Life (EoL) ist. In der Umfrage kommt es sogar auf Platz 3 der am häufigsten eingesetzten Distributionen.

Egal ob man nun EoL-Betriebssysteme oder EoL-Laufzeitumgebungen betrachtet, die Lösung ist stets dieselbe. Die dazugehörige Anwendung muss zuerst auf einer neueren und unterstützten Version laufen, bevor die alte abgeschaltet werden kann. Dazu müssen Teams in der Lage sein, Anwendungen neu deployen und das Deployment testen zu können. Auch hier helfen Testsysteme, -prozeduren und Automation. Auch hierbei ist es unerlässlich, dass Betrieb und Anwendungsteams zusammenarbeiten, um den Erfolg der Migration sicherzustellen. Je schneller Feedback-Loops und Abstimmungsprozesse sind, desto schneller sind notwendige Prozeduren etabliert. Die Zeit für Releasewechsel lässt sich so signifikant verkürzen. Ressourcen sind damit schneller frei und können für innovative Entwicklungsprojekte genutzt werden.

Leider erlebe ich häufig, dass Abteilungen nur in ihrem eigenen Bereich nach Lösungen suchen und den Kontakt zu anderen Abteilungen meiden, ja beinahe scheuen. Doch ist dies kein technisches Problem. Es ist eine organisatorische Herausforderung, die angegangen werden muss. Es liegt doch im Interesse aller Beteiligten, regelmäßig wiederkehrende Releasewechsel schnell und störungsarm abwickeln zu können.

In meinem beruflichen Alltag erlebe ich häufig, dass In-Place-Upgrades als Allheilmittel angesehen werden. Ich hingegen bin kein großer Freund davon. Sie sind der vermeintlich einfache Weg, doch führen sie zur dunklen Seite der Macht. Ein In-Place-Upgrade aktualisiert das Betriebssystem inkl. der installierten Bibliotheken und Laufzeitumgebungen. Es befreit nicht von der obligatorischen Aufgabe, die darauf laufenden Anwendungen im Anschluss zu testen. Stellt man dabei Fehler fest, gibt es häufig kein Zurück mehr. Eine Ausnahme bilden hier virtuelle Umgebungen, bei denen man zuvor einen Snapshot der virtuellen Maschine erstellen kann.

Wer eine Anwendung immer nur mit In-Place-Upgrades von einem Release auf das nächste rettet, verliert mit einer größeren Wahrscheinlichkeit die Fähigkeit, die Anwendung sauber neu zu deployen. Man tut sich hiermit keinen Gefallen.

Ich bin der Überzeugung, dass Organisationen in der Lage sein müssen, ihre geschäftskritischen Anwendungen mit einem definierten Zustand automatisiert ausrollen zu können. Dies unterstützt Releasewechsel, erleichtert den Auf- und Abbau von Testumgebungen sowie die Verifizierung von Fehlern und das Nachstellen von Bugs. Anwendungen können so auch deutlich leichter und schneller gegen neuen Bibliotheken und Laufzeitumgebungen getestet werden. Es lohnt sich, Zeit zum Schärfen der Axt zu investieren, bevor man mit dem Fällen der Bäume beginnt. Oder anders ausgedrückt, wer keine Zeit hat, den Zaun zu reparieren, weil er mit Kühe einfangen beschäftigt ist, wird nie zum Melken kommen.

Open Source Distributionen

In dieser Kategorie auf Seite 15 listet der Bericht die Linux-Distributionen auf, die von den Umfrageteilnehmern verwendet werden. Ubuntu führt diese Liste an und liegt mit 46 % vor Debian mit 23%. Platz 3 geht an CentOS mit 22%. Den undankbaren vierten Platz belegt Amazon Linux mit knapp 20%. Die noch recht neue Distribution CentOS Stream findet sich auf Platz 13 mit 9,5%.

Ich habe diese Werte mit denen aus dem State of Open Source Report von 2023 verglichen. Ubuntu hat im Vergleich um 27 % zugelegt (Platz 1 mit 29% in 2023). Debian kam 2023 mit 16,63% auf Platz 6 hinter CentOS Stream mit 16,74%. Die Plätze 2 und 3 wurden 2023 von Alpine Linux (21,1%) und Oracle Linux (19,72%) belegt. CentOS kam damals mit 15% auf Platz 8.

Der Bericht von 2024 spekuliert, dass Red Hat’s Änderung beim Zugriff auf den RHEL Quelltext und das EoL von CentOS mitverantwortlich für diese Veränderungen sind, kann jedoch keine klaren Belege dafür liefern. Laut Bericht sind die Linux Wars noch nicht entschieden und wir können auf den kommenden Bericht gespannt sein.

Es hat mich überrascht, dass RHEL und SLES es gar nicht in das Ranking geschafft haben. Unter Berücksichtigung, dass die Kostenreduktion in diesem Bericht die Hauptmotivation für den Einsatz von Open Source darstellt, lässt sich ggf. erklären, warum Distributionen gerade nicht hoch im Kurs stehen, die kostenpflichtige Support-Subskriptionen für den produktiven Einsatz voraussetzen.

Ich freue mich schon darauf, herauszufinden, wie dieses Ranking im nächsten Bericht aussieht.

Cloud-Native Open Source Technologies

Das Diagramm auf Seite 17 zeigt das Ranking der wichtigsten Cloud-Native Open Source Technologies für die Umfrageteilnehmer. Platz 1 wird von Docker mit 44,6 % eingenommen, gefolgt von Kubernetes mit 33,61 %.

Der große Vorsprung von Docker vor Podman mit 16,6 % hat mich ein wenig überrascht. Ich hätte den Abstand nicht als so groß eingeschätzt. Hier interessiert mich, welche Vorteile die Nutzer in Docker gegenüber Podman sehen. Leider macht der Bericht hierzu keine Aussage. Ich selbst nutze Podman unter Debian, Fedora und RHEL. In Debian stehen ungünstigerweise nur ältere Podman Releases zur Verfügung, denen wichtige Funktionen fehlen. Dies ist in meinen Augen eine Erklärung, warum Podman gerade in diesen Distributionen wenig genutzt wird. Dies ist allerdings nur wilde Spekulation meinerseits. Ich kann dies nicht belegen.

Für mich ebenfalls unerwartet ist OpenStack mit knapp 18 % sowie OKD und Rancher mit jeweils unter 10%. In diesem Bereich leide ich vermutlich an Betriebsblindheit. Wenn man bei Red Hat arbeitet, kann man leicht den Eindruck gewinnen, dass die ganze Welt nur noch OpenShift macht.

Ich freue mich darauf, diese Kategorie über die nächsten Jahre zu beobachten und zu sehen, wie sich Podman entwickelt, wofür ich eine gewisse Vorliebe habe.

Automations- und Konfigurations-Management

Wer die Kategorie Ansible in diesem Blog kennt, weiß bereits, dass ich mich gerne mit Ansible beschäftige. So freut es mich zu sehen, dass Ansible im betrachteten Bericht auf Seite 25 Platz 1 mit 30% belegt. Überraschend finde ich hingegen, dass 27% angaben, keinerlei Open Source Automations- bzw. Konfigurationsmanagement zu verwenden. Der Bericht führt dies auf Antworten aus jungen Unternehmen zurück, die (noch) keine Notwendigkeit für Automation sehen. Ich möchte diesen Unternehmen empfehlen, frühzeitig eine Automation First Philosophie zu entwickeln, da ich überzeugt bin, dass sich ein konsequenter Einsatz von Automations- und Konfigurationsmanagementwerkzeugen schnell auszahlt.

Unter den Systemadministratoren liegen Ansible (40 %) und Puppet (36%) als beliebteste Werkzeuge nah beieinander. Es ist immer gut, Auswahl und Wettbewerb zu haben. Ich freue mich über den Anteil von Puppet, gerade weil ich in den Nachrichten nur noch wenig Notiz davon nehme.

Salt liegt bei unter 10 % und ich habe auch schon längere Zeit nichts mehr von diesem Projekt gehört. Schade, die Architektur von Salt finde ich ganz interessant.

Im aktuellen Bericht nutzen knapp 23 % Terraform und der Lizenzwechsel zeigt noch keine große Abwanderung zu dessen Fork OpenTofu. Da die Datenerhebung jedoch Ende 2023 durchgeführt wurde, kann der Bericht eine etwaige Nutzerabwanderung noch nicht darstellen. In 2024 hat IBM die Übernahme von Hashi Corp bekannt gegeben. Ich bin gespannt, wie es mit den Produkten und deren Nutzung weitergeht. Hoffentlich gibt der nächste Bericht erste Einblicke.

Fazit

Durch die Arbeit in einem großen IT-Unternehmen mit einem starken eigenen Portfolio fällt es leicht, eine Betriebsblindheit für die Entwicklungen außerhalb des eigenen Kosmos zu entwickeln. Berichte wie der 2024 State of the Open Source Report helfen, der Betriebsblindheit entgegenzuwirken.

Ich habe nicht alle Kategorien des aktuellen Berichts im Detail betrachtet, sondern mir diejenigen herausgepickt, die mein persönliches Interesse ansprechen. Darüber in diesem Blog zu schreiben, hilft mir, über den Bericht und meine Erfahrungen zu reflektieren. Und wenn euch dieser Kommentar ebenfalls gefällt, freue ich mich umso mehr.

Der Virutal Private Server (VPS), welcher diesen Blog ausliefert, war heute in der Zeit zwischen 08:06 Uhr und 17:52 Uhr nicht erreichbar.

Ursache ist eine Störung im Nürnberger Rechenzentrum meines Anbieters Contabo. Die Störung besteht offenbar schon seit dem 30.08. (siehe Screenhot der Meldung unten), betraf meinen VPS aber erst heute.

Die Störung bei Contabo ist noch nicht behoben. Es ist nicht auszuschließen, dass dieser Blog nocheinmal davon betroffen sein wird. Ich bitte in diesem Fall um etwas Geduld.

Update 2024-09-16: Root Cause Analysis of September 2024 Nuremberg Data Center Outage

Contabo hat einen Blog zur Aufarbeitung der Störung vom 2. September 2024 veröffentlicht. Die URL lautet: https://contabo.com/blog/nuremberg-incident-root-cause-analysis/

Und in diesem Text möchte ich euch mitteilen, welche Faktoren zu meiner Zufriedenheit beitragen.

Seit März 2023 arbeite ich als Senior Technical Account Manager (TAM) bei Red Hat. In diesem Artikel habe ich beschrieben, wie eine Arbeitswoche für mich aussehen kann.

Doch was gefällt mir nun so sehr an diesem Job?

• Ich arbeite full remote. Dies passt aktuell am besten zu meinen Lebensumständen. Hier findet sich ein Erfahrungsbericht dazu.
• Dass ich nicht mehr pendeln muss, gibt mir mehr Zeit für die Familie und schont die Umwelt.
• Unser gesamtes Team arbeitet full remote und alle beherrschen unsere Tools, sodass die Zusammenarbeit reibungslos klappt.
• Wir haben eine tolle Unternehmenskultur und ich fühlte mich selten von so hilfsbereiten Menschen umgeben.
• Diese Kultur motiviert mich, mich selbst stets einzubringen und zu unterstützen, wo ich kann.
• Wir haben anspruchsvolle Ziele und stets mehr als genug zu tun. Dennoch nehmen wir uns stets die Zeit einander zu helfen, unser Wissen zu teilen.
• Wenn jemand mal nicht direkt helfen kann, wird man nicht mit Sätzen wie: „Dafür bin ich nicht zuständig.“ oder „Da kenne ich mich selbst nicht mit aus.“ abgespeist. Bei uns hört man dann eher:
  • „Da kann ich dir leider nicht direkt helfen, aber versuch es mal bei XY, die haben mir schonmal in einer ähnlichen Angelegenheit geholfen.“
  • Oder die Anfrage wird direkt an das richtige Team weitergeleitet
• Wir sind in unserer Arbeitsweise sehr frei. Es gibt kein Mikromanagement. Unser aller Ziel ist, unseren Enterprise-Kunden eine gute Erfahrung zu bescheren. Natürlich gibt es Leitlinien, die einen Rahmen vorgeben. Diese empfinde ich nicht als Einschränkung, sondern als richtungsweisend.
• Im Zweifel haben wir das gemeinschaftlich gepflegte TAM Manual, das uns erklärt, wie was gemacht wird.
• Wir ziehen Besprechungen nicht in die Länge. Wenn wir fertig sind, hören wir einfach auf. Selbst dann, wenn die Zeit noch nicht vorbei ist.

Natürlich gibt es auch bei Red Hat genug Dinge, die verbessert werden können bzw. sollten. Doch konzentriere ich mich hier bewusst auf die Punkte, die zu meiner Zufriedenheit führen, um mich daran zu erfreuen.

Die obigen Punkte beziehen sich nicht ausschließlich auf mein eigenes Team. Ich erlebe dies regelmäßig auch teamübergreifend. Das ist eine tolle Erfahrung.

Mein Tipp für euch: Denkt nicht immer nur an Dinge, die euch nicht gefallen. Macht euch aktiv der Dinge bewusst, die euch gefallen und motivieren. Ihr werdet evtl. erstaunt sein, wie viel Energie ihr draus schöpfen könnt. Mich hat bspw. die Methode Journaling dabei unterstützt, zu einem positiven Mindset zu finden.

Was gefällt euch besonders an eurem Job? Teilt eure Gedanken und Erfahrungen gerne mit uns.