Heute vor genau 10 Jahren, am 04.01.2014, ging adminForge ans Netz. 🍾️🥳️🎉️ Der erste Hallo Welt Beitrag zeigt noch ganz gut was ich damals mit dem Blog vor hatte. Mittlerweile konzentriere ich mich nicht...
by adminForge.
Im März 2023 wechselte ich von Flex-Work in eine neue Rolle, in der ich 100 % remote arbeite. Heute möchte ich meine Erfahrungen mit euch teilen, die ich bisher damit gemacht habe.
Bevor es richtig losgeht, schreibe ich etwas zur Terminologie der Remote-Arbeit. Denn hier geht es mit den Begrifflichkeiten teilweise ganz schön durcheinander. Daher möchte ich sicherstellen, dass ihr versteht, was ich mit bestimmten Begriffen meine.
Von allen verwendeten Begriffen ist dies der Einzige, welcher in Deutschland in der Arbeitsstättenverordnung definiert ist:
Telearbeitsplätze sind vom Arbeitgeber fest eingerichtete Bildschirmarbeitsplätze im Privatbereich der Beschäftigten, für die der Arbeitgeber eine mit den Beschäftigten vereinbarte wöchentliche Arbeitszeit und die Dauer der Einrichtung festgelegt hat. Ein Telearbeitsplatz ist vom Arbeitgeber erst dann eingerichtet, wenn Arbeitgeber und Beschäftigte die Bedingungen der Telearbeit arbeitsvertraglich oder im Rahmen einer Vereinbarung festgelegt haben und die benötigte Ausstattung des Telearbeitsplatzes mit Mobiliar, Arbeitsmitteln einschließlich der Kommunikationseinrichtungen durch den Arbeitgeber oder eine von ihm beauftragte Person im Privatbereich des Beschäftigten bereitgestellt und installiert ist.
ArbStättV §2 Abs.7
Erbringen Arbeitnehmende die geschuldete Arbeitsleistung zum Teil am Telearbeitsplatz und zum Teil in einem Büro des Arbeitgebers, wird von alternierender Telearbeit gesprochen.
Bei dieser Form ist der Arbeitgebende für die vollständige Ausstattung des Arbeitsplatzes mit Mobiliar und Arbeitsmitteln sowie der Einhaltung arbeitsrechtlicher Vorschriften (z.B. Ergonomie, UVV, Prüfung ortsveränderlicher Elektrogeräte, etc.) verantwortlich.
Diese Begriffe werden häufig verwendet, wenn Arbeitnehmende die geschuldete Arbeitsleistung teilweise außerhalb der Büroräume des Arbeitgebers erbringen und es sich nicht um Telearbeit handelt.
Angestellte erhalten hierbei häufig keine komplette Büroeinrichtung für den Telearbeitsplatz im privaten Raum, sondern lediglich die notwendigen Arbeitsmittel, wie z.B. Laptop und Telefon. Dafür dürfen sie häufig auch außerhalb der eigenen vier Wände bzw. des Büros z.B. aus einer Ferienwohnung arbeiten.
In manchen Fällen werden voll ausgestattete Büroarbeitsplätze für die Angestellten vorgehalten. In anderen Fällen existiert eine Form von Desksharing.
Details werden in Arbeitsverträgen, Betriebsvereinbarungen und Tarifverträgen geregelt.
Der Duden definiert das Wort Homeoffice wie folgt:
[mit Kommunikationstechnik ausgestatteter] Arbeitsplatz im privaten Wohnraum
URL: https://www.duden.de/rechtschreibung/Homeoffice
Der Begriff wird jedoch nicht einheitlich verwendet. Betrachtet man die Quellen [1]-[5], so wird er sowohl als Synonym für Telearbeit als auch als Oberbegriff für alle Formen von Arbeit verwendet, die nicht in Büroräumen des Arbeitgebers ausgeführt werden.
Wenn ich in diesem Text den Begriff Homeoffice verwende, meine ich damit mobile Arbeit, wie sie im folgenden Abschnitt beschrieben wird.
Bei der mobilen Arbeit sind Angestellte keinem Büro zugeordnet und nicht an einen Teleheimarbeitsplatz gebunden. Die geschuldete Arbeitsleitung kann von einem beliebigen Ort wie z.B. dem Auto, Café, Hotel oder dem Strand erbracht werden. Dies schließt die eigenen vier Wände jedoch explizit mit ein.
Dem Arbeitnehmenden werden bei dieser Form häufig nur die zwingend benötigten Arbeitsmittel wie Laptop, Mobiltelefon und ggf. Headset gestellt. Bring you own device ist ebenso möglich. Häufig erhalten Angestellte eine Pauschale, mit der sie benötigte Arbeitsmittel selbst beschaffen können.
Details werden auch hierbei im Arbeitsvertrag, in Betriebsvereinbarungen oder Tarifverträgen geregelt.
Nicht jede Tätigkeit ist dazu geeignet, im Homeoffice ausgeführt zu werden. Pflegepersonal kann den Beruf meist ebensowenig aus den eigenen vier Wänden ausüben wie Bus-, LKW-, Zug-Fahrer und Kapitäne. Auch Berufe mit Laufkundschaft eignen sich in der Regel schlecht für Arbeit außerhalb eines festen Büros.
Ich gehöre hingegen zu den glücklichen Menschen, deren Job von einem fast beliebigen Ort aus erfüllt werden kann. Die einzige Bedingung ist eine gute Daten- und Kommunikations-Verbindung. Meine berufliche Tätigkeit lässt sich dabei mit folgenden Stichpunkten beschreiben:
Mit diesen Merkmalen habe ich die besten Voraussetzungen, um nicht auf einen festen Arbeitsplatz beschränkt bzw. angewiesen zu sein.
Zu Beginn meines Arbeitsverhältnisses wurde ich mit folgenden Arbeitsmitteln ausgestattet:
Ausgeliefert wurde das System mit einem RHEL 8 Corporate Standard Build (CSB). Die Installation wird also von unserer internen IT verwaltet. Ich selbst habe sudo-Rechte auf dem System und fühle mich in keinster Weise eingeschränkt. Ich bin fasziniert, wie gut die Inbetriebnahme ablief und es so gut wie keine Probleme gab, wegen denen ich den IT-Support bemühen musste.
Bei dem Laptop handelte es sich nicht um ein topaktuelles Modell, doch ist es für meine tägliche Arbeit sehr gut geeignet. Ich nutze es täglich für die Arbeit mit:
Im Vergleich mit meinem privaten ThinkPad T14s ist das Gerät nach einigen Videokonferenzen deutlich lauter. Die Effizienz der CPU und Lüftersteuerung sind beim P1 nicht so gut wie beim T14s.
Das Thunderbold-Dock hingegen ist das schlechteste Dock, das ich je selbst benutzen musste. Dass für diesen elektronischen Briefbeschwerer im Online-Versandhandel zwischen 250,- und 300,- EUR aufgerufen werden, macht mich fassungslos. Hier funktioniert nichts, wie es soll. Und auch nach einer Firmware-Update-Orgie ändern sich die Fehler, in Summe bleiben sie jedoch gleich. Ich musste mich jedoch nicht lange damit ärgern. Da die Probleme bekannt sind, konnte ich mir ein Dock meiner Wahl beschaffen und die Kosten dafür erstatten lassen.
Zusätzlich zu diesen Arbeitsmitteln bekam ich noch ein Budget, für das ich mir weitere notwendige Arbeitsmittel kaufen konnte, plus ein separates Budget für ein Mobiltelefon. Von diesen Mitteln habe ich beschafft:
Zum Telefon gehört ein Vertrag. Ich konnte beides aus einer Liste auswählen. Zur Auswahl standen auch diverse Geräte von Apple, Samsung und weiteren Herstellern.
Mein Arbeitsplatz sieht in der Regel sehr aufgeräumt und unaufgeregt aus.
Ich besaß bereits vor meinem Jobwechsel einen höhenverstellbaren Schreibtisch, den ich mir für meinen Rücken gegönnt habe. Aus privater Tasche habe ich mir dann noch Bürostuhl Tailwind 2 mit Pending-System und Ponso-Sitzfläche beim lokalen Händler https://www.fair-kauf.net/ gekauft.
Wenn während der Zeit etwas kaputtgeht oder ich feststelle, dass mir doch noch etwas fehlt, bespreche ich dies mit meinem Manager. Bisher war es kein Problem, die Ausgaben für Anschaffungen, die ich sinnvoll begründen konnte, erstattet zu bekommen.
Ich bin mit meinen Arbeitsmitteln sehr zufrieden und kann meine Arbeit damit gut erledigen. Neben der Technik betrachte ich es als unschlagbaren Vorteil, ein eigenes Arbeitszimmer zu besitzen, welches nur von mir zum Zweck der Arbeit genutzt wird. Dies hat für mich folgende unschlagbare Vorteile:
Hinsichtlich Raum und Arbeitsmittel kann ich aktuell nichts bemängeln und fühle mich gut ausgestattet.
Kommunikation ist wichtig und findet statt, sobald sich mindestens zwei Menschen eine Situation teilen, sich am gleichen Ort oder in der gleichen Videokonferenz befinden. Die Kommunikation findet dabei auf unterschiedlichen Ebenen statt, der Sach- und der Beziehungsebene, wobei die Beziehungsebene die Sachebene bestimmt.
Eine Nachricht, die von Mensch zu Mensch übertragen wird, hat mehrere Seiten und muss vom Empfänger nicht so verstanden werden, wie der Sender sie gemeint hat.
Bei diesen Aussagen handelt es sich um Erkenntnisse von Paul Watzlawick und Friedemann Schulz von Thun aus der Kommunikationswissenschaft (siehe [7]-[10] in den Quellen unten). Kommunikation stellt einen sehr wichtigen Faktor bei der Arbeit dar und beeinflusst in hohem Maße die Produktivität sowie die Motivation der Angestellten.
Viele Artikel und Blogs verkürzen dieses Thema auf Aussagen wie:
Mich stört, wenn so getan wird, als wäre die Realität schwarz oder weiß. Ist sie doch in Wirklichkeit grau (ein Blick aus dem Fenster bestätigt dies aktuell) und liegt die Wahrheit doch meist in der Mitte.
Ich möchte hier die Kommunikationskultur in der Firma und dem Team beschreiben, wo ich aktuell beruflich zu Hause bin. Da ich zu 100 % remote arbeite, finden für mich, von wenigen Kundenbesuchen im Jahr abgesehen, fast alle Meetings per Videokonferenz oder Telefon statt. Die einzige Bewertung, die ich dabei vornehme ist, dass es mir persönlich gut gefällt.
Wie in vermutlich jeder Firma gibt es auch bei uns regelmäßig wiederkehrende Meetings. Dazu gehören unter anderem:
Kurz gesagt, die 40-Stunden-Woche bietet nicht genug Zeit, um an allen möglichen Meetings teilzunehmen. Doch das erwartet auch niemand.
Was mir gut gefällt:
Benötigt man ein paar zusätzliche Augen bzw. Ideen beim Troubleshooting bzw. der Suche nach Informationen, öffnet man ein virtuelles Meeting und lädt Kolleg*innen via Chat ein. Entweder wählt man einen Kanal mit vielen Mitgliedern und hofft, dass jemand kommt oder man schreibt Teilnehmer gezielt an. Dabei gebietet die Etikette, dass man vorher prüft, ob die entsprechende Person auch frei ist. Möglich ist dies mithilfe unserer Kalender oder des Status im Chat.
Dabei ähneln diese Meetings den Störungen im Büro, wo die Tür aufgeht und Kollegen mit ihren Sorgen, Nöten und Anträgen plötzlich vor dem eigenen Schreibtisch stehen. Vorteil der Remote-Arbeit ist in meinen Augen, dass die Hemmschwelle sich diesen Störungen zu entziehen geringer ist. Eine Meetinganfrage lehnt man schneller ab oder verlässt ein Meeting schneller, als jemanden aus dem Büro hinauszubitten.
Für mich ist wichtig, vorher zu überlegen, ob der synchrone Austausch einen Vorteil über asynchrone Kommunikation bietet. Dies ist zum Beispiel der Fall, wenn sich ein Sachverhalt nur umständlich in einer E-Mail erklären lässt, oder das Risiko eines Missverständnisses hoch ist. Grundsätzlich gebe ich der asynchronen Kommunikation den Vorzug, da ich Kollegen so nicht in ihrer Arbeit störe, sie in ihrer eigenen Zeit antworten können und E-Mails Beweise generieren.
Obwohl ich ausschließlich aus dem Homeoffice arbeite, habe ich das Gefühl, weniger Zeit in Meetings zu verbringen als zuvor. Gemessen habe ich dies jedoch nicht.
Kaffeeküchengespräche, Gesabbel beim Mittagessen und Flurfunk sterben bei mobiler Arbeit aus. Das stimmt in meiner Erfahrung so nicht.
Wir treffen uns sporadisch zum Kaffeetrinken in einer Videokonferenz und sprechen darüber, wie unser Tag so läuft, was es Neues gibt. Dabei werden sowohl dienstliche wie private Themen diskutiert.
Manche Kollegen treffen sich sogar in einer Videokonferenz, ohne aktiv miteinander zu sprechen. Man könnte auch sagen: „Sie schweigen sich konstruktiv an.“ Dies kann das Gefühl reduzieren, allein zu sein. Es ist jemand in der Nähe, der zuhört und in aller Regel auf geräuschvolle Äußerungen reagiert.
„Vermisse ich regelmäßige persönliche Treffen in der realen Welt? Nein.“
„Weiß ich diese Treffen dennoch zu schätzen? Ja.“
In meinen Augen ist dies kein Widerspruch in sich. Ich habe mich schnell daran gewöhnt, dass mein Team verteilt sitzt und die meisten Kontakte durch Chat, E-Mail und Videokonferenz stattfinden. Dennoch freue ich mich, diese Menschen am Rande von Veranstaltungen auch mal persönlich zu treffen. Besonders gern, wenn dies ungezwungen außerhalb formal organisierter Teambildungsmaßnahmen passiert.
Dies sind definitiv zwei meiner Hauptarbeitsmittel. Beide sind Werkzeuge zur asynchronen Kommunikation. Chat ist dabei in der Regel schneller als E-Mail, wobei ich persönlich E-Mails besser strukturieren kann und Dinge leichter in E-Mails wiederfinde.
Aus Gesprächen mit Menschen aus verschiedenen Unternehmen weiß ich, dass Chat Fluch und Segen sein kann. Dies ist jedoch kein technisches Problem, sondern hängt von der Unternehmenskultur und der persönlichen Disziplin ab. Wird erwartet, dass jeder zu jederzeit erreichbar ist und prompt reagiert, kann das die Produktivität ziemlich in den Keller drücken.
Setzt man einen Status wie verfügbar, beschäftigt, im Termin u.ä. und wird dies respektiert, kann Chat die Kommunikation wunderbar unterstützen. Das klappt selbst dann, wenn es mehrere Chats-Werkzeuge gibt.
Zum Glück werde ich nur sehr selten angerufen und ich rufe auch nur selten jemanden an. Warum? Ich empfinde unangekündigte Anrufe als Störung, denn sie unterbrechen meine Arbeit. Und was ich selbst nicht will, das man mir tu, das füge ich niemand anderem zu.
Das Telefon ist für mich ein Kommunikationsmittel für den Fall, wenn es etwas sehr Dringendes zu bereden gibt. Oder wenn ich weiß, dass es das bevorzugte Kommunikationsmittel der Person ist, von der ich etwas möchte.
Es gibt Dinge, die kann man am Telefon oder in einer Videokonferenz schneller bzw. einfacher klären als in einer langen Chat- oder E-Mail-Diskussion. Ich empfinde es dann allerdings als höflich, wenn man für das Telefonat einen Termin vereinbart, statt ohne Vorwarnung durchzuklingeln.
Mich freut es sehr, dass ich nicht ständig von eingehenden Anrufen und Video-Calls gestört werde.
Aktuell passt die Form der mobilen Arbeit, wie sie in meinem Team bei Red Hat gelebt wird, sehr gut zu meinen persönlichen Vorlieben und meiner Lebenssituation.
Mir gefällt es, dass ich in Ruhe und allein arbeiten kann, gleichzeitig aber ein guter Kontakt zu Kolleg*innen existiert, mit denen ich mich austauschen kann. Ich bin sehr zufrieden und hoffe, dass es noch lange so weitergeht.
Herausforderungen in der Zusammenarbeit und Kommunikation liegen in meiner Erfahrung meist in der Unternehmenskultur begründet und nur selten in der Technik. Daher empfehle ich allen, bei denen es nicht optimal läuft, über Anforderungen zu sprechen und erst danach über mögliche Programme zur Lösung derselben.
Euch wünsche ich, dass ihr ein Arbeits(zeit)modell findet, das gut zu euch passt. Wenn ihr Lust habt, teilt doch gern eure Erfahrungen mit eurer Arbeit im Büro, hybrid oder remote hier. Ich freue mich zu erfahren, wie ihr heute arbeitet und wie zufrieden ihr damit seid.
Es ist der 31.12.2023 und somit wird es wieder Zeit für den traditionellen Jahresrückblick. Dieses Jahr dominierten zwei Buchstaben: KI. Die Veröffentlichung von ChatGPT erfolgte zwar kurz vor 2023, in diesem Jahr wurden allerdings die Auswirkungen sichtbar. Ich muss sagen, dass es lange kein Werkzeug gab, an dem ich so viel Experimentierfreude erleben konnte.
Dabei ist die Mensch-Maschine-Schnittstelle besonders spannend. Die natürlichsprachliche Interaktion verbessert nicht nur die Zugänglichkeit, sondern erhöht auch die Interoperabilität: Das Werkzeug kann nicht nur die Aufgabe verstehen, sondern die Ergebnisse in der gewünschten Form darstellen. Schreibe ich eine Software, erfüllt sie nur einen Zweck. ChatGPT kann besonders einfach an neue Aufgabenbereiche angepasst werden. Man muss nicht einmal im klassischen Sinne "programmieren". Somit wird die Arbeit mit dem Computer auf eine ganz neue Stufe gehoben.
Auf die technische Ebene möchte ich heute gar nicht direkt eingehen, das haben wir das Jahr schon im Detail in diesem Blog ergründet. Diskussionen über Technik und Innovationen stellen nur eine Augenblickaufnahme dar. Im Rückblick auf eine größere Zeitepisode wie ein mindestens Jahr werden allerdings gesellschaftliche Entwicklungen deutlich. Und hier gab es einiges zu beobachten.
ChatGPT hat eine große Nutzerbasis erreicht, die zumindest ein Mal das Werkzeug ausprobiert hat. Im deutschsprachigen Raum, der sonst sich so "datenschutzorientiert" und innovationskritisch gibt, ist das schon bemerkenswert. Diskussionen über Datenschutz waren zweitrangig, die Menschen waren von der Innovation durch das Werkzeug fasziniert. Natürlich kam über das Jahr die Erkenntnis, dass in der aktuellen Form die Technologie je nach Branche noch nicht weit genug ausgereift ist, trotzdem wollte jeder einmal schauen, was es damit auf sich hat und ob es den Alltag erleichtern kann.
Und doch hat OpenAIs Werkzeug in meinen Augen ein wenig den Blick verengt: Durch das schnelle Wachstum wurde ChatGPT zum Sinnbild von "KI" und hat Ängste geschürt. Denn einerseits will jeder, dass KI ihm das Leben einfacher macht, jedoch nicht, dass andere mit KI ihm seine Lebenssituation verschlechtern bzw. ihn zu einem Umdenken zwingen. Ein Zeitungsredakteur möchte gerne KI für die Verbesserung seiner Texte einsetzen, fürchtet jedoch um seine Jobzukunft, wenn andere ihn durch automatische Generierung ganzer Zeitungsbeiträge drohen, überflüssig zu machen.
Dieser Umstand hat die Diskussion rund um den europäischen AI Act noch einmal deutlich angeheizt. An Large Language Models wurden auf einmal hohe Anforderungen gestellt, um subjektiven Ängsten entgegenzutreten. Dann war man sich aufgrund der Innovationsgeschwindigkeit auf einmal nicht sicher, ob es jetzt schon Zeit für eine starre Regulierung ist. Und schlussendlich zeichnet sich eine politische Entwicklung ab, jetzt lieber irgendeinen Kompromiss als später eine gut ausgearbeitete Fassung präsentieren zu können. Wie der AI Act kommt, werden wir dann im nächsten Jahr sehen.
Das alles war aber nicht das, was dieses Jahr in meinen Augen besonders gemacht hat. Es ist etwas anderes: die neue Rolle von Open Source.
Anfang des Jahres sah es so aus, als setzt eine besondere Kommerzialisierung in der Technikwelt ein: die Kommerzialisierung von Basistechnologie. Über die verschiedenen Jahre haben wir gesehen, dass es für verschiedene Produkte in der IT proprietäre und freie Lösungen gibt. Zwar sind erstere gerne technologisch mitunter überlegen, da die Profitorientierung Anreize setzt, für bestimmte Anwendungszwecke besonders passende Lösungen zu entwickeln. Kostet eine Software Geld, kann der Hersteller Programmierer anstellen, die auch die Features entwickeln, die man ungern freiwillig programmiert. Auf diese Weise entstehen runde Produkte für einen Anwendungszweck.
Freie bzw. zumindest quelloffene Software ermöglicht zumindest aber der Öffentlichkeit, einen Blick in die Funktionsweise zu werfen, um zu sehen, wie etwas funktioniert. Das ist die Grundlage, um Technologie zu verbessern.
In der Welt des maschinellen Lernens entstand allerdings durch die benötigte Compute Power eine hohe Eintrittshürde. Es sah so aus, als wären die Large Language Models nur noch großen Konzernen bzw. gut finanzierten Start-ups vorbehalten, die sich die Trainingspower leisten können. Während die Vorgängersysteme wie GPT-2 noch öffentlich zugänglich waren, wurden gerade Systeme wie GPT-3 und GPT-4, bei denen das Produkt endlich richtig nutzbar wurde, zurückgehalten.
Im Laufe des Frühlings habe ich allerdings vermutet, dass freie Modelle die proprietären outperformen können, weil die öffentliche Zugänglichkeit die Chance eröffnet, dass Experten weltweit mit ihren eigenen Erfahrungen, Eindrücken und ihrem Domänenwissen eine Technologie entwickeln können, die verschlossenen Produkten überlegen ist.
Überraschend war, dass es gerade das AI-Team von Facebook war, das den Stein mit LLaMA ins Rollen gebracht hat. Es folgten zahlreiche weitere Abkömmlinge, Weiterentwicklungen oder gänzliche Alternativansätze, die eines gemein hatten: ihr Kern mit den Gewichten war zugänglich.
Wie es aussieht, könnte die Dominanz proprietärer Systeme gebrochen werden, sodass auch die Möglichkeit gewahrt bleibt, einen wissenschaftlichen Diskurs zu führen. Technische Berichte proprietärer Modelle sind zwar nett, aber die Forschungsarbeiten, in denen reproduzierbare Fortschritte aufgezeigt werden, bringen uns tatsächlich eher voran.
Um die rasante Entwicklung im Frühling, als scheinbar jedes KI-Team großer Konzerne und Forschungseinrichtungen alle in der Schublade angesammelten LLM-Projekte zu veröffentlichen versuchte, im Auge zu behalten, habe ich die LLM-Timeline entwickelt. Sie wurde vor einigen Tagen wieder aktualisiert und zeigt besonders, wie sehr LLaMA als eines der ersten praktisch verwertbaren Modelle mit offenen Gewichten die Entwicklung beeinflusst hat.
Ein weiteres Projekt, das ich in der Zusammenarbeit mit der Fachhochschule Kiel realisiert habe, war der Podcast KI & Kultur, der generative Modelle aus der Perspektive Kulturschaffender beleuchtet hat.
Das Jahr hat den 70 Jahre alten Begriff der KI wieder mal in die Massen gebracht. Dabei wird ChatGPT dem Begriff eigentlich gar nicht gerecht, weil es streng genommen relativ dumm ist. Insbesondere beschränkt es die Zustandsfähigkeit nur auf eine Prompt und lernt nicht, während es denkt. Training und Inferenz sind entkoppelt.
Und trotzdem ist es diese natürlichsprachliche Schnittstelle, die es so faszinierend macht. Allerdings ist auch diese Erkenntnis nicht neu und wurde schon vor 55 Jahren mit ELIZA diskutiert.
Erfreulich ist es, dass "Open Source" nicht mehr nur bei Software, sondern in neuen Technologien Anwendung findet. Der Gedanke, dass Technologie zugänglich sein muss, kann so erhalten werden. Und dass es hilft, wenn Wissenschaftler auf der ganzen Welt mit ihrem Wissen beitragen können, sehen wir weiterhin auch in dieser Thematik.
LLMs ermöglichen es, dass wir uns endlich wieder der Mensch-Maschine-Schnittstelle widmen können, die Technologie nutzbar macht. Menschen wollen, dass Technik das Leben einfacher macht. Die bisher begrenzte Rechenleistung hat uns zu Hilfsmitteln wie Displays, Touchscreens oder Tastaturen gezwungen. In den nächsten Jahren können wir schauen, wie wir das überwinden können, um endlich nutzbare Computer zu erhalten, die wirklich was bringen.
Und so ist es schon fast ironisch, dass die naheliegendste Technologie, die in den 2010er-Jahre euphorisch gefeiert wurde, von den LLMs noch wenig profitiert hat: Sprachassistenten. Sie sind überwiegend noch genau so begrenzt und unflexibel wie früher. Hier gibt es einiges zu tun.
Abschließend möchte ich meinen Lesern des Blogs und Zuhörern des Podcasts Risikozone sowie KI & Kultur danken, dass ihr den Blog lest, den Podcast hört und regelmäßig Feedback gebt. Ich wünsche euch einen guten Rutsch in das neue Jahr 2024.
Im nächsten Jahr werden wir wieder gemeinsam neue Technologien ergründen und die aktuellen Nachrichten diskutieren. Es wird auch mehr um Grundlagen und Visualisierungen gehen, hierauf freue ich mich schon besonders!
Viel Glück, Gesundheit und Erfolg!
Ein neuer adminForge Service kann ab sofort genutzt werden. Mit OpenTalk könnt ihr Videokonferenzen abhalten und dabei euren Bildschirm freigeben. OpenTalk Videokonferenzen Mit OpenTalk könnt ihr Videokonferenzen abhalten und dabei euren Bildschirm freigeben....
by adminForge.
Dieser Artikel ist der Auftakt einer Mini-Serie, die sich mit der Script-Programmierung des Raspberry Pi 5 beschäftigt. Geplant sind drei Artikel:
Hinter den Kulissen hat sich mit der Vorstellung des Raspberry Pi 5 mehr geändert, als es in den ersten Testberichten den Anschein hatte. Schuld daran ist der neue I/O-Chip RP1, der unter anderem für die Kommunikation mit der GPIO-Leiste und der Kamera zuständig ist. Der RP1 bringt natürlich viele Vorteile mit sich (u.a. die Möglichkeit, zwei Kameras anzuschließen und größere Bild- bzw. Videomengen zu verarbeiten); er führt aber auch dazu, dass über Jahre etablierte Module und Kommandos nicht mehr funktionieren. Ja, die Raspberry Pi Foundation hat vorgearbeitet und empfiehlt schon eine Weile alternative Werkzeuge. Aber aus Bequemlichkeit blieben viele Programmierer bei langjährig bewährten Tools. Damit ist jetzt Schluss. Wer den Pi 5 als Maker-Tool nutzen will, muss umlernen.
In der Vergangenheit gab es mehrere GPIO-Kommuniktionsmechanismen, z.B. das Lesen/Schreiben von sysfs-Dateien (sys/class/gpio) bzw. das direkte Verändern von Speicherbereichen. Diese Verfahren haben schon in der Vergangenheit oft Probleme bereitet. Beim Raspberry Pi 5 funktionieren sie schlicht nicht mehr. Neue Verfahren verwenden die lgpio-Bibliothek, die wiederum auf eine neue Kernel-Schnittstelle zurückgreift. Diese ist nach außen hin durch die Device-Dateien /dev/gpiochip* sichtbar.
Aus Python-Sicht ist insbesondere das Modul rpi.gpio betroffen. Es ist inkompatibel zum Pi 5 und es gibt anscheinend auch keine Pläne, den Code RP1-kompatibel zu reorganisieren.
Schon seit einiger Zeit empfiehlt die Raspberry Pi Foundation, das gpiozero-Modul zu verwenden. Es stellt für den Einstieg gut geeignete Klassen wie LED oder Button zur Verfügung, eignet sich aber auch für anspruchsvollere Maker-Aufgaben.
Wenn Sie sich partout nicht mit gpiozero anfreunden wollen, gibt es drei Alternativen: lgpio, gpiod und rpi-lgpio.
Das Python-Modul gpiozero macht die Steuerung von Hardware-Komponenten durch GPIOs besonders einfach. Für häufig benötigte Hardware-Komponenten gibt es eigene Klassen. Dazu zählen unter anderem:
Anmelden
LED (Leuchtdiode ein-/ausschalten)PWMLED (Helligkeit einer Leuchtdiode mit Software Pulse Width Modulation steuern)RGBLED (dreifarbige LED, die über drei GPIO-Ausgänge gesteuert wird) TrafficLights (Kombination aus einer roten, gelben und grünen Leuchtdiode)MotionSensor (für PIR-Bewegungssensoren)LightSensor (Lichtdetektor)Button (Taster) Buzzer (Summer)Motor (zur Steuerung von zwei GPIOs für Vorwärts- und Rückwärts-Signale)Robot (zur Steuerung mehrerer Motoren)MCP3008 (für den gleichnamigen A/D-Converter) Das Modul gpiozero ist umfassend dokumentiert:
https://gpiozero.readthedocs.io/en/latest
Ein Hello-World-Beispiel sieht so aus:
#!/usr/bin/env python3
from gpiozero import LED
import time
myled = LED(7) # BCM-Nummer 7 = Pin 26 des J8-Headers
print("LED ein")
myled.on()
time.sleep(1)
print("LED aus und Programmende")
myled.off()
Dieses Script setzt voraus, dass Pin 26 der GPIO-Leiste (intern BCM/GPIO 7) über einen Vorwiderstand mit einer Leuchtdiode verbunden ist. Anstelle der GPIO-Nummer gibt es einige alternative Adressierungsverfahren, wobei Sie den gewünschente GPIO-Kontakt als Zeichenkette angeben:
# alternative, gleichwertige Schreibweisen
myled = LED(7) # GPIO 7 = BCM-Nummer 7
myled = LED("GPIO7") # GPIO 7 (Achtung, nicht "GPIO07")
myled = LED("BCM7") # BCM 7 (nicht "BCM07")
myled = LED("BOARD26") # Pin 26 auf der GPIO-Leiste des Boards
myled = LED("J8:26") # Pin 26 des J8-Headers (= GPIO-Leiste)
lgpio (der Projektname lautet noch kürzer lg) ist eine C-Bibliothek zur lokalen Steuerung der GPIOs. Das gerade erwähnte Modul gpiozero verwendet intern seit Version 2.0 die lgpio-Bibliothek. Alternativ stellt das gleichnamige lgpio-Modul eine direkte Python-Schnittstelle zur lgpio-Bibliothek her. Deren Funktionen sind Hardware-näher implementiert. Der GPIO-Zugriff verbirgt sich also nicht hinter Klassen wie LED oder Button, vielmehr werden die GPIO-Schnittstellen direkt angesprochen.
Ein Hello-World-Beispiel mit lgpio sieht so aus:
#!/usr/bin/env python3
import lgpio, time
# Zugriff auf /dev/gpiochip4 für RP1-Chip
handle = lgpio.gpiochip_open(4)
# Raspberry Pi 4 und früher:
# handle = lgpio.gpiochip_open(0)
# GPIO 7 = Pin 26 als Output verwenden
led = 7
lgpio.gpio_claim_output(handle, led)
# LED zehnmal ein- und ausschalten
for i in range(10):
print("LED ein")
lgpio.gpio_write(handle, led, 1)
time.sleep(1)
print("LED aus")
lgpio.gpio_write(handle, led, 0)
time.sleep(1)
# nichts blockieren
lgpio.gpiochip_close(handle)
Beachten Sie, dass die Initialisierung des Handles für den GPIO-Zugriff je nach Modell variiert! Bei den älteren Raspberry-Pi-Modellen bis einschließlich 4B/400 müssen Sie handle = lgpio.gpiochip_open(0) ausführen. Beim Raspberry Pi 5 ist für die GPIO-Steuerung dagegen der neue RP1-Chip zuständig, den Sie mit gpiochip_open(4) ansprechen. (Die richtige Chip-Nummer stellen Sie am einfachsten mit dem Kommando gpioinfo aus dem Paket gpiod fest. Der hier benötigte Kontakt GPIO7 heißt in gpioinfo ein wenig verwirrend PIN7.)
Wenn Sie mit Python ein lgpio-Script schreiben wollen, das auf allen Pi-Modellen funktioniert, müssen Sie Code zur Erkennung des Pi-Modells integrieren.
Weiterer Codebeispiele finden Sie hier:
Was tun, wenn Sie Code für ältere Modelle entwickelt haben, den Sie nun für den Raspberry Pi 5 portieren möchten? Am schnellsten wird dies oft mit dem neuen Modul rpi-lgpio gelingen, das weitgehende Kompatibilität zu rpi.gpio verspricht.
Vor der Installation müssen Sie das in Raspberry Pi OS standardmäßig installierte Modul rpi.gpio installieren. Eine Parallelinstallation beider Module ist ausgeschlossen, weil rpi.gpio und rpi-lgpio den gleichen Modulnamen verwenden (import RPi.GPIO).
sudo apt remove python3-rpi.gpio
Da es in Raspberry Pi OS für rpi-lgpio kein fertiges Paket, installieren Sie dieses am einfachsten mit pip. Da es kein passendes Systempaket gibt, sind keine Konflikte zu erwarten. Wenn Sie die Option --break-system-packages dennoch vermeiden möchten, müssen Sie eine virtuelle Python-Umgebung einrichten.
pip install --break-system-packages rpi-lgpio
Das obige pip-Kommando installiert das Modul lokal, also nur für Ihren Account. Wenn Sie Ihr Script in einem anderen Account ausführen möchten (z.B. als Cron-Job), stellen Sie dem Kommando sudo voran und installieren so rpi-lgpio systemweit.
Nach diesen Vorbereitungsarbeiten sollten viele Ihre alten Scripts ohne Änderungen laufen. Einige Sonderfälle sind hier dokumentiert:
https://rpi-lgpio.readthedocs.io/en/release-0.4/differences.html
Die folgenden Zeilen zeigen einmal mehr eine Schleife zum Ein- und Ausschalten einer Leuchtdiode:
#!/usr/bin/env python3
# Das Script setzt voraus, dass vorher
# rpi-lgpio installiert wurde!
import RPi.GPIO as gpio
import time
# BCM-GPIO-Nummern verwenden
gpio.setmode(gpio.BCM)
# LED an Pin 26 = GPIO 7
gpio.setup(7, gpio.OUT)
# LED über Pin 26 fünf Mal ein- und ausschalten
for _ in range(5):
print("LED ein")
gpio.output(7, gpio.HIGH)
time.sleep(1)
print("LED aus")
gpio.output(7, gpio.LOW)
time.sleep(1)
# alle vom Script benutzten GPIOs/Pins wieder freigeben
gpio.cleanup()
Das Python-Modul gpiod wird durch das Paket python3-libgpiod zur Verfügung gestellt, das unter Raspberry Pi OS standardmäßig installiert ist. Das Modul stellt eine Python-Schnittstelle zur Bibliothek libgpiod her. Diese Bibliothek ist wiederum eine Alternative zu der schon erwähnten lgpio-Bibliothek. Da es zum Python-Modul kaum Dokumentation gibt, ist gpiod nur für Entwickler von Interesse, die mit libgpiod bereits C-Programme entwickelt haben. Als Ausgangspunkt für eine eigene Recherche eignen sich die beiden folgenden Seiten:
Das folgende Minibeispiel zeigt, wie Sie eine LED an Pin 26 (GPIO 7) fünf mal ein- und ausschalten:
#!/usr/bin/env python3
import gpiod, time
chip = gpiod.Chip('gpiochip4') # RP1 (Raspberry Pi 5)
led = chip.get_line(7) # GPIO 7 = Pin 26 des J8-Headers
led.request(consumer="example", type=gpiod.LINE_REQ_DIR_OUT)
for _ in range(5): # 5x ein- und ausschalten
led.set_value(1)
time.sleep(1)
led.set_value(0)
time.sleep(1)
Dieser Beitrag baut auf dem Artikel „PHP7.4-fpm auf PHP8.1-fpm für Nextcloud“ auf.
Im Januar 2023 hatte ich erklärt, wie ich mein Raspberry Pi OS 11 (basierend auf Debian 11 Bullseye), durch Einbinden einer Fremdquelle, von PHP7.4-fpm auf PHP8.1-fpm aktualisiert habe. Warum ich zu diesem Zeitpunkt die Version 8.1 installiert habe, ist recht einfach zu beantworten. Die aktuelle Version Nextcloud 25 war noch nicht kompatibel zu PHP 8.2. Erst mit Nextcloud 26 war ein Upgrade möglich.
Nun habe ich mich nach der Aktualisierung auf Nextcloud 28 entschieden auf PHP 8.2 zu wechseln. Da ich den FastCGI-Prozessmanager FPM bevorzuge, unterscheidet sich das Upgrade etwas von einer herkömmlichen PHP-Installation.
Zuerst wird das System auf den aktuellen Stand gebracht.
sudo apt update && sudo apt upgrade -y
Ein Check zeigt, welche PHP-Version momentan aktiv ist.
php -v
Hier die Ausgabe:
PHP 8.1.27 (cli) (built: Dec 21 2023 20:17:59) (NTS) Copyright (c) The PHP Group Zend Engine v4.1.27, Copyright (c) Zend Technologies with Zend OPcache v8.1.27, Copyright (c), by Zend Technologies
Jetzt werden alle benötigten Pakete nachinstalliert (auch das von Nextcloud 28 verlangte bz2 und der von mir eingesetzte Redis-Server).
sudo apt install php8.2 php8.2-mbstring php8.2-gd php8.2-curl php8.2-imagick php8.2-intl php8.2-bcmath php8.2-gmp php8.2-mysql php8.2-zip php8.2-xml php8.2-apcu libapache2-mod-php8.2 php8.2-bz2 php8.2-redis
Nun wird via CLI die PHP-Version von 8.1 auf 8.2 mit
sudo update-alternatives --config php
umgestellt.
sudo update-alternatives --config php Es gibt 5 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen). Auswahl Pfad Priorität Status ------------------------------------------------------------ 0 /usr/bin/php.default 100 automatischer Modus 1 /usr/bin/php.default 100 manueller Modus 2 /usr/bin/php7.4 74 manueller Modus * 3 /usr/bin/php8.1 81 manueller Modus 4 /usr/bin/php8.2 82 manueller Modus 5 /usr/bin/php8.3 83 manueller Modus
sudo update-alternatives --config php Es gibt 5 Auswahlmöglichkeiten für die Alternative php (welche /usr/bin/php bereitstellen). Auswahl Pfad Priorität Status ------------------------------------------------------------ 0 /usr/bin/php.default 100 automatischer Modus 1 /usr/bin/php.default 100 manueller Modus 2 /usr/bin/php7.4 74 manueller Modus 3 /usr/bin/php8.1 81 manueller Modus * 4 /usr/bin/php8.2 82 manueller Modus 5 /usr/bin/php8.3 83 manueller Modus
Ein abschließender Check zeigt die aktuelle Version.
php -v
PHP 8.2.14 (cli) (built: Dec 21 2023 20:18:00) (NTS) Copyright (c) The PHP Group Zend Engine v4.2.14, Copyright (c) Zend Technologies with Zend OPcache v8.2.14, Copyright (c), by Zend Technologies
Ist die Ausgabe korrekt, kann PHP8.1-fpm deaktiviert, PHP8.2-fpm installiert und aktiviert werden.
sudo a2disconf php8.1-fpm sudo apt install php8.2-fpm sudo a2enconf php8.2-fpm
Der Restart des Webservers führt nun die Änderungen aus.
sudo service apache2 restart
Da in der Nextcloud nun wieder die bekannten Fehlermeldungen auftauchen, heißt es, diese schrittweise abzuarbeiten. Dazu wird die neue php.ini geöffnet
sudo nano /etc/php/8.2/fpm/php.ini
und die Werte für memory_limit sowie session_lifetime wie empfohlen angepasst.
memory_limit = 512M session.gc_maxlifetime = 3600
Der Block
opcache.enable=1 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=10000 opcache.memory_consumption=256 opcache.save_comments=1 opcache.revalidate_freq=1
für den Zwischenspeicher OPchache wird ans Ende der php.ini gesetzt.
Zur Optimierung von PHP8.2-fpm werden speziell für das Modell Raspberry Pi 4 mit 4GB RAM in der Datei www.conf mit
sudo nano /etc/php/8.2/fpm/pool.d/www.conf
folgende Werte von
pm = dynamic pm.max_children = 5 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3
auf
pm = dynamic pm.max_children = 120 pm.start_servers = 12 pm.min_spare_servers = 6 pm.max_spare_servers = 18
angepasst und der Dienst neu gestartet.
sudo service php8.2-fpm restart
Danach muss in der apcu.ini das Command Line Interface des PHP Cache noch aktiviert werden, indem
sudo nano /etc/php/8.2/mods-available/apcu.ini
folgende Zeile am Ende eingetragen wird.
apc.enable_cli=1
Ist dies geschehen, wird der Webserver ein letztes Mal neu gestartet.
sudo service apache2 restart
Die Umstellung bringt zwar im Moment keine erkennbaren Vorteile, jedoch verschafft es wieder ein wenig Zeit und senkt den Druck das eigentliche Raspberry Pi OS 11 Bullseye durch die aktuelle Version 12 Bookworm zu ersetzen.
PHP-FPM (FastCGI Process Manager) ist eine leistungsstarke Erweiterung für den PHP-Interpreter, die die Ausführung von PHP-Skripten optimiert und verbessert. Entwickelt, um die Skalierbarkeit von PHP-basierten Webanwendungen zu erhöhen, spielt PHP-FPM eine entscheidende Rolle in modernen Webserver-Umgebungen.
Traditionell wurde PHP als Modul für Webserver wie Apache bereitgestellt. Dieser Ansatz hatte jedoch seine Einschränkungen, insbesondere wenn es um die Verwaltung von Ressourcen und die Skalierung von Webanwendungen ging. PHP-FPM wurde als Lösung für diese Herausforderungen entwickelt, indem es die FastCGI-Protokollspezifikation implementiert und PHP-Skripte als separate Prozesse ausführt.
PHP-FPM ermöglicht eine effiziente Verwaltung von Ressourcen, indem es separate Prozesse für jede Anforderung erstellt. Dadurch wird der Arbeitsspeicher besser genutzt und die Gesamtleistung der Webanwendung verbessert.
Durch die Nutzung von PHP-FPM können Webentwickler ihre Anwendungen leichter skalieren, da sie die Anzahl der gleichzeitig ausgeführten PHP-Prozesse steuern können. Dies ist besonders wichtig in Umgebungen mit starkem Datenverkehr.
Jede PHP-Anwendung wird in ihrem eigenen Prozess isoliert, wodurch Konflikte zwischen verschiedenen Anwendungen vermieden werden. Dies trägt zur Stabilität des Gesamtsystems bei.
PHP-FPM bietet eine umfangreiche Konfiguration, die es Administratoren ermöglicht, Parameter wie Prozessprioritäten, Anzahl der Kinderprozesse und andere Einstellungen zu optimieren.
Die Konfiguration von PHP-FPM erfolgt über die php-fpm.conf-Datei und optionale Pool-Konfigurationsdateien. Administratoren können Parameter anpassen, um die Leistung und Ressourcennutzung nach den Anforderungen ihrer Anwendung zu optimieren.
Die Integration von PHP-FPM in Webserver wie Nginx oder Apache erfolgt durch die Konfiguration von FastCGI-Servern. Dies ermöglicht eine reibungslose Kommunikation zwischen dem Webserver und PHP-FPM.
PHP-FPM hat sich als wesentliches Werkzeug für die Verwaltung von PHP-Anwendungen in produktiven Umgebungen etabliert. Durch die Bereitstellung von effizienter Ressourcennutzung, Skalierbarkeit und Anwendungsisolierung spielt PHP-FPM eine Schlüsselrolle bei der Gewährleistung der Leistungsfähigkeit von PHP-Webanwendungen. Bei der Entwicklung und Verwaltung von Webanwendungen ist es wichtig, die Vorteile von PHP-FPM zu verstehen und richtig zu konfigurieren, um eine optimale Leistung zu gewährleisten.
Das Jahr 2023 neigt sich langsam dem Ende zu. In diesem Monat for 25 Jahren wurde das IPv6-Protokoll in RFC 2460 beschrieben, bevor es 2017 in RFC 8200 als Internet-Standard von der Internet Engineering Task Force (IETF) veröffentlicht wurde.
Seit immerhin sechs Jahren ist dieses IP-Protokoll also schon standardisiert. Da sollte man doch meinen, dass man im Jahr 2023 problemlos ein vernetztes System betreiben kann, welches nur mit einer IPv6-Adresse mit dem Internet verbunden ist. Leider ist dem nicht so.
In den folgenden kurzen Abschnitten schreibe ich mir meinen Frust von der Seele und dokumentiere, was heute alles mit IPv6 noch nicht geht. Falls ihr weitere Fälle ergänzen möchtet, nutzt gerne die Kommentare, um eurem IPv6-Frust Luft zu machen.
Bei der Planung einer Red Hat Satellite 6.14 Installation bin ich über folgenden Satz in der Dokumentation gestolpert:
You can install Satellite and Capsules in IPv6-only systems, dual-stack installation is not supported.
URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite
Das ist schade. Betreibt man Server in IPv4- und IPv6-Netzwerken und möchte eine vollständig unterstützte Lösung, muss man aktuell zwei Satellite installieren.
Ich wollte jedoch einen Satellite in einer reinen IPv6-Umgebung installieren, daher sollte mich diese Anmerkung nicht weiter stören. Da störten mich folgende Stellen im gleichen Kapitel der Dokumentation schon mehr:
You must deploy an external IPv4 HTTP proxy server. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this proxy to pull content into the Satellite on your IPv6 network.
You must configure Satellite to use this IPv4 HTTP proxy server as the default proxy. For more information, see Adding a Default HTTP Proxy to Satellite.
URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite#requirements-for-installation-in-an-ipv6-network_satellite
Zuerst wollte ich dies nicht glauben, habe einen Fehler in der Dokumentation vermutet. Es ist 2023 und Content Delivery Network (CDN) von Red Hat unterstützt kein IPv6? Das kann doch nicht sein! Kann es doch:
Der zweite Link in obiger Liste führt ausschließlich IPv4-Adressen auf. Einzelne Kommentare lassen darauf schließen, dass es jedoch durchaus Interesse an IPv6-Konnektivität gibt. Also installiere ich erstmal einen Proxy-Server mit Dual-Stack, damit ich Hosts aus einem reinen IPv6-Netzwerk via subscription-manager register beim Red Hat Subscription Management (RHSM) registrieren kann.
Nachzulesen in:
Die gute Nachricht, es sind gefixte Versionen für RHEL 9 und RHEL 8 in Aussicht. Auf einen Fix für RHEL 7 würde ich nicht warten und diese Systeme lieber migrieren oder aktualisieren, ist das Support-Ende doch bereits nah.
Also lege ich mein Vorhaben erstmal beiseite und wende mich anderen Wochenendprojekten zu, die vielleicht mehr Erfolg versprechen.
Nun guck an, da ist mein Kollege Andreas also schon im Jahr 2022 in den Ansible-Issue #77308 gelaufen. Ihr interessiert euch für den aktuellen Stand dieser Geschichte? Siehe:
So langsam komme ich mir vor wie ein bekannter spanischer Junker, welcher gegen Windmühlen pardon Riesen anritt. Aber es ist ja nicht so, dass mir die Themen ausgehen. Klone ich mir halt ein Repo von Github und trage ein bisschen zu Open Source bei…
Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:
$ host -t AAAA github.com
github.com has no AAAA recordURL zur Diskussion: https://github.com/orgs/community/discussions/10539
Auch hier kein Anschluss unter dieser Nummer.
Ich möchte meine jüngsten Erfahrungen umschreiben mit: „An manchen Tagen hat man kein Glück und an anderen kommt auch noch Pech dazu.“
Für Red Hat möchte ich sagen, ist es ein Priorisierungs-Thema. Wenn der Wunsch nach IPv6 auf Kundenseite hinreichend groß wird, wird man hier handeln. Bei Github wird es ähnlich sein. Ich muss vielleicht nur nochmal 25 Jahre warten.
Ich wünsche allen Besuchern des Blogs intux.de ein frohes und besinnliches Weihnachtsfest sowie einen guten Rutsch ins neue Jahr 2024.
Ich kann nicht für alle TAMs bei Red Hat sprechen, denn wir arbeiten sehr selbstständig und haben nur wenige feste Vorgaben. Doch möchte ich euch einen Einblick geben, wie eine Woche in meinem aktuellen Job aussehen kann.
Bitte bedenkt, dass nicht jede Woche gleich aussieht. Das wäre ja auch schrecklich eintönig und langweilig. Dennoch habe ich eine gewisse Routine, mit der ich den Alltag bewältige.
Ich wünsche euch viel Spaß bei diesem Wochenrückblick.
Hinweis: Die hier beschriebene Woche liegt schon etwas zurück. Der Bericht wurde erst kürzlich fertiggestellt.
Die Woche begann mit einem etwas ungewöhnlichen Montag. Denn mein Sohn hatte schulfrei und brachte meine Morgenroutine gehörig durcheinander.
Statt vor dem Monitor begann mein Arbeitstag daher mit dem Diensthandy. Hierauf habe ich mir einen Überblick über Chat und E-Mail verschafft, um zu sehen, ob über das Wochenende irgendetwas eskaliert ist oder es Themen gibt, denen ich mich zuerst widmen muss. Bei dieser Gelegenheit habe ich direkt alle E-Mails, die ich ob ihres Betreffs als unwichtig klassifiziert habe, direkt gelöscht.
Beim Üerfliegen verschiedener Newsletter ist mir aufgefallen, dass mein Name im letzten TGIF Newsletter auftaucht. Denn ich habe letzte Woche KCS2 erreicht. KCS ist die Abkürzung für Knowledge-centered support. Level 2 bedeutet, dass ich mein Training abgeschlossen habe und zukünftig Lösungs-Artikel selbst veröffentlichen darf. Bisher hat dies mein KCS-Coach nach einem Review der jeweiligen Artikel getan. Ich habe mich über diese kleine Anerkennung gefreut. :-)
Wie fast jeden Morgen habe ich einen Blick in unser Support-Tool geworfen, um mir einen Überblick über mir zugewiesene Cases und ggf. neue Cases meiner Kunden zu verschaffen. Heute sah es hier sehr ruhig aus und es gab nichts zu tun.
Als TAMs arbeiten wir an strategischen und wichtigen Cases unserer Kunden. Damit ihr euch ein bisschen besser vorstellen könnt, was damit gemeint ist, beschreibe ich euch, wie ich Support-Cases handhabe.
Exkurs: Case Work
Als TAM arbeite ich auf Kundenseite mit einem Team zusammen, welches in der Regel aus 4-6 Personen besteht. Dies sind meine TAM-Kontakte. Wenn ein TAM-Kontakt einen Support-Case öffnet, wird dieser mit einem TAM-Flag versehen und wird in meiner View des Support-Tools sichtbar.
Üblicherweise wird der TAM Eigentümer dieser Tickets und bearbeitet sie, bis sie mit dem Einverständnis des Kunden als gelöst geschlossen werden. Die folgende Liste bietet einen kleinen Auszug aus den Themen, die ich überlichweise selbst bearbeite:
Allerdings bearbeite ich nicht alle Support-Fälle selbst. In folgenden Fällen überlasse ich dies unseren Spezialisten aus den unterschiedlichen Support-Bereichen:
Kunden haben bereits mit ihrer RHEL-Subskription den Support erworben, der ihnen im Fehlerfall hilft. Als TAM bin ich bestrebt, Support-Fälle dann zu bearbeiten, wenn ich für den Kunden dadurch einen Mehrwert bieten kann. Dies ist nicht der Fall, wenn ich nur als Durchlauferhitzer oder zusätzliches Glied in der Stille-Post-Kette beteiligt bin. Jedoch habe ich auch ein Auge auf die Cases meiner TAM-Kontakte, die ich nicht selbst bearbeite. Ich teile in diesen Fällen häufig Informationen über die Umgebung des Kunden und den Einfluss des Problems auf die Geschäftsprozesse, welche ich in meinen Abstimmungsterminen mit dem Kunden gesammelt habe.
TL;DR: Ich bearbeite Support-Fälle dann, wenn ich dadurch einen Mehrwert für meine Kunden bieten kann.
Exkurs Ende.
Der Montag Vormittag ist in aller Regel eher ruhig. Daher nutze ich die Zeit für Themen, die ich in Ruhe bearbeiten möchte. Darunter fallen Dinge wie:
Diese Woche war es wirklich ein sehr ruhiger Montag. Ich habe eine Übergabe an meine Vertretung für einen Kunden organisiert und Account-Informationen aktualisiert. Mein Posteingang, ToDo-Liste und Check-Status sind bearbeitet und bei den Kontakten in der WaitingOnReply-Box habe ich um ein Update ersucht. Heute war ein schöner Tag. :-)
Der Dienstag begann mit einem TAM-Team-Meeting. Vorbildlich mit Agedna, Moderator, Protokollant und Zeitwächter. Dies haben wir alle zwei Wochen, wenn es Themen gibt. Die Stimmung war gut. So bin ich gut gelaunt in den Tag gestartet.
Mit dem Daily Stand-up und einem Abstimmungsmeeting zu unserem Vortrag auf dem Summit Connect Darmstadt hatte ich noch zwei weitere Meetings am Vormittag.
Daneben standen heute insgesamt 3,5 Stunden Focus Time in meinem Kalender. Dabei handelt es sich um Zeiten, die ich mir reserviere, um konzentriert an Themen zu arbeiten. Heute habe ich die Zeit genutzt, um:
Das besondere an Focus Time ist bei uns, dass weitere Termineinladungen, die in die Focus Time fallen, automatisch abgelehnt werden und man im Chat als beschäftigt markiert ist. Dies wird von den allermeisten Kollegen respektiert und man kann in Ruhe arbeiten.
Zwischendurch habe ich nach offenen Support-Cases geschaut und Informationen ergänzt. Manchmal reagieren Kunden nicht auf Updates im Support-Portal. Wenn ich dies feststelle, kontaktiere ich sie per E-Mail und informiere über Updates und stelle sicher, dass auf beiden Seiten die gleiche Erwartungshaltung zum Verlauf der Bearbeitung existiert.
Der Tag begann um Punkt 09:00 Uhr einem Quarterly Service Review für einen unserer Kunden. Hier präsentieren meine TAM-Kollegen und ich, was wir im letzten Quartal für unseren Kunden geleistet haben und gleichen dies mit der Wahrnehmung unseres Kunden ab. Der Termin endete mit einer Aussicht auf das laufende Quartal.
Danach hieß es für mich meine Sachen zu packen, denn heute stand noch die Reise nach Darmstadt auf dem Programm. Ich bin mit der Bahn gereist, da ich so im Zug arbeiten konnte.
Damit meinen Kunden während meiner Reise und Teilnahme am Summit Connect der TAM-Service in gewohnter Weise zur Verfügung steht, habe ich mir im Vorfeld Vertretungen für meine Kunden organisiert.
Während der Bahnfahrt habe ich einen TAM-Call durchgeführt. Dies war nicht optimal, aber besser, als den Termin ausfallen zu lassen. Während eines TAM-Call bespreche ich mit Kunden aktuelle Themen wie offene Support-Cases, anstehende Changes und Projekte, Trainingsbedarf, etc. Er dient der Abstimmung untereinander und Planung der nächsten Schritte.
Mit 45 Minuten Verspätung erreichte ich am Abend Darmstadt Hbf. Nun hieß es schnell im Hotel einchecken und zum Abendessen eilen.
Den Abend verbrachte ich in angenehmer Atmosphäre mit tollen Kollegen. Es war schön, sie mal wieder persönlich zu treffen.
Heute gab es den ganzen Tag nur ein Thema: Red Hat Summit: Connect Darmstadt
Vier Stichpunkte, die mich von 08:00-23:00 Uhr beschäftigt haben. Es hat sich aus meiner Sicht gelohnt. Unser Vortrag kam trotz der Kürze der Zeit gut an und ich habe einige Kunden das erste Mal in der Realität getroffen (und erst gar nicht wiedererkannt).
Heimreise mit der Bahn. Während der Fahrt in verschiedenen Zügen habe ich mit einem Support-Engineer und meinem Kunden zusammen an einem kniffligen Case gearbeitet, Life-Cycle- und Support-Dokumente geprüft, die Folien zum Quarterly Service Review vom Mittwoch an den betreffenden Empfängerkreis verteilt sowie abgelegt und an diesem Blog-Post geschrieben.
Die Kunden bekommen meist gar nicht mit, wie viel hinter dem Support-Ticket kommuniziert wird. Mir macht es Spaß auch mal über knifflige Problem zusammen mit Kollegen nachzudenken, nach Lösungen und Workarounds zu suchen.
Die ungeplante Verlängerung der Reisezeit nutzte ich, um mein Compliance & Ethics Training abzuschließen. Damit ist dieser Punkt auch erledigt.
Mit 3 Stunden Verspätung, was mich tierisch genervt hat, bin ich daheim bei meiner Familie angekommen, was mich dann sehr gefreut hat.
Eine spannende und anstrengende Woche ist vorbei. Ich hoffe ich konnte euch einen kleinen Einblick in eine nicht ganz normale Woche meiner Arbeit geben.
Das Interessante an den Open-Source-Modellen ist ja, dass sie das umsetzen, was bei den proprietären Modellen gemunkelt wird, aber nicht nachgewiesen werden kann. Mein aktuelles Highlight: Mixture of Experts (MoE).
Im Sommer kamen Behauptungen auf, dass OpenAIs GPT-4 eigentlich aus acht kleineren Modellen besteht, die zusammengeschaltet werden. Dieses Verfahren nennt man auch Ensemble Learning.
Das klassische Beispiel dafür ist Random Forest, wo mehrere Decision Trees parallel zu so einem Ensemble zusammengeschaltet werden. Soll das Ensemble dann eine Klassifikation vornehmen, nimmt jeder Decision Tree mit seinen eigenen Gewichten die Klassifikation vor. Anschließend entscheidet die Mehrheit der Decision Trees im Ensemble, wie das Gesamtmodell nun klassifizieren soll. Analog würde auch eine Regression umgesetzt werden können, als Aggregierungsfunktion kommt dann statt Mehrheitswahl eben sowas wie Mittelwert o. ä. zum Einsatz. Das besondere ist, dass mit Random Forest üblicherweise bessere Vorhersagen erzielt werden können, als mit einem einfachen Decision Tree.
MoE funktioniert in den groben Zügen ähnlich. Es gibt "Experten" (ähnlich wie die Decision Trees bei Random Forest), die dann gewichtet aggregiert werden (Gating). Die Technik ist eigentlich recht alt und viele waren überrascht, dass OpenAI genau so etwas einsetzen soll.
Umso besser, dass Mistral als das europäische LLM-Startup sich der Sache angenommen hat. Anfang des Wochenendes schwirrte schon ein Torrent durchs Netz, heute gibt es dann auch eine offizielle Pressemitteilung zu Mixtral 8x7B. Hierbei handelt es sich um ein "Sparse Mixture of Experts"-Modell (SMoE). Die Gewichte sind wieder offen und unter der Apache 2.0 lizenziert.
Kurz zu den Eckdaten: 32k Token Kontextlänge können verarbeitet werden. Dabei spricht das Modell Englisch, Französisch, Italienisch, Deutsch und Spanisch und wurde auch auf Codegenerierung optimiert. Fine-tuning ist ebenfalls möglich - so wurde bereits eine instruction-following-Variante trainiert.
Im Vergleich zu Llama 2 70B soll es in einer Vielzahl von Benchmarks bessere Ergebnisse abliefern und dabei schneller arbeiten. Die einzelnen Ergebnisse können der Pressemitteilung entnommen werden.
Einen klassischen Downloadlink konnte ich auf die schnelle nicht finden, das Twitter-Profil verweist nur auf die Torrents. Parallel kündigt das Start-up an, einen eigenen Dienst für API-Endpoints anzubieten, sodass ein Deployment auf eigener Infrastruktur nicht mehr zwangsläufig notwendig ist.
Aktuell sollte beim Updaten des Linux-Kernels Vorsicht walten gelassen werden. Bestimmte Kernel-Releases weisen ein Problem mit ext4 auf, das theoretisch im schlimmsten Fall zu einer Datenbeschädigung führen kann.
Es gibt eine Konstellation, in der in einem Release nur der erste ohne den zweiten Commit enthalten ist und somit der Code nicht wie gewünscht arbeitet. Konkret geht es um
Jan Karas E-Mail auf der LKML zufolge geht es darum, dass der erste Commit nur dann im Code vorhanden sein darf, wenn der zweite Commit bereits enthalten ist. Eigentlich ist das logisch, weil das ja mit der Reihenfolge dann auch so passt.
Jetzt kommen allerdings noch die Backports und Distributionen ins Spiel. Für den Kontext: da nicht jeder immer auf die neuste Linux-Version aktualisieren kann, gibt es ein Team, was alte Versionen nachpflegt und kleine, unkritische Fixes neuerer Versionen auf die älteren Versionen "rückportiert", also backported. Allerdings kann es nun passieren, dass etwas ganz neues rückportiert wird, ohne, dass eine ältere Voraussetzung rückportiert wurde. Die Fehler, die dann auftreten, nennt man klassicherweise eine Regression. Die einzelnen Codeänderungen sind da nicht an sich das Problem, sondern eher die Konstellation, in der sie zusammengesetzt wurden.
Linux 6.1.64 und 6.1.65 sind betroffen, 6.1.66 enthält den Fix. Debian 12, das auf die Kernels setzt, ist dabei besonders in Aufruhe, da eine problematische Kernel-Version verteilt wird. Aus diesem Grund wurde auch die Veröffentlichung von Debian 12.3 verzögert.
Der Black Friday ist für den Einzelhandel ein willkommenes Datum, um Waren an den Mann bzw. die Frau zu bringen. In dieser Zeit wird Lagerware abverkauft, um Platz für Neues zu schaffen. Der Endverbraucher profitiert meist durch Rabatte und Nachlässe auf interessante Artikel.
Angelockt durch solch ein Angebot, habe ich mir eine externe 2TB-SSD zugelegt, um den Speicher meiner Nextcloud zu erweitern. Im Vorfeld hatte ich mir hierzu schon einige Gedanken gemacht, wie ich die alte 500GB SSD durch das neue und größere Speichermedium ersetze.
Die perfekte Lösung für mich war das Duplizieren der Quelle mit Clonezilla. Hierbei wurden beide Festplatten an den Rechner angeschlossen, Clonezilla gestartet und mit device-device ein Duplikat erstellt. Bei diesem musste dann nur noch die Partition vergrößert werden. Da der Zielfestplatte die selbe UUID vergeben wurde, waren im Anschluss keine weiteren Maßnahmen erforderlich.
In diesem Artikel stelle ich euch die RHEL System Role nbde_client vor, mit welcher sich Hosts für Network Bound Disk Encryption (NBDE) installieren lassen. Er ist Bestandteil einer losen Serie, in der ich eine Reihe von System Roles vorstelle, mit denen häufig anfallende Aufgaben in der Systemadministration erledigt werden können.
Wer sich zuerst über die genannten Begriffe informieren möchte, lese:
Für das folgende Beispiel verwende ich eine Umgebung, bestehend aus:
ansible-corerhel-system-roles/dev/sdc in den Beispielen in diesem Text)Die Installation von RHEL sowie der genannten Pakete sind nicht Bestandteil dieses Artikels. Wer hierzu einen Einstieg sucht, findet entsprechende Dokumentation unter:
Durch die Installation des Pakets rhel-system-roles existiert diese Rolle bereits auf meinem System und muss nur noch konfiguriert werden. Die Rolle selbst findet man im Pfad /usr/share/ansible/roles/rhel-system-roles.nbde_client/ und die Dokumentation in /usr/share/doc/rhel-system-roles/nbde_client/README.md. Letztere enthält verschiedene Beispiele für häufige Anwendungsfälle.
In meinem Labor betreibe ich zwei NBDE-Server (TANG-Server) rhel-hetz-tang1 und rhel-hetz-tang2 sowie zwei NBDE-Clients (Clevis-Clients) rhel-hetz-clevis1 und rhel-hetz-clevis2. Die beiden NBDE-Clients besitzen jeweils ein LUKS-Device /dev/sdc, welches aktuell durch eine LUKS-Passphrase gesichert ist.
Zukünftig sollen diese LUKS-Devices durch die Kommunikation mit einem NBDE-Server entschlüsselt werden. Die LUKS-Passphrase soll entfernt werden.
Damit wird zukünftig ein Neustart der Clients aus der Ferne ermöglicht. Gleichzeitig bleibt das verschlüsselte Gerät bei Diebstahl vor unbefugtem Zugriff geschützt.
Hinweis: Das folgende Playbook ist nicht idempotent. Um dies zu ändern, ist dem ersten Task eine Bedingung hinzuzufügen, damit dieser nur dann ausgeführt werden, wenn die Bedingung erfüllt ist.
Für dieses Beispiel ist die fehlende Idempotenz des Playbooks jedoch kein Problem, da grubby das Argument nur dann hinzufügt, wenn es nicht bereits vorhanden ist.
---
- hosts: clevis
tasks:
- name: Configure ip address for interface during early boot
ansible.builtin.command:
cmd: grubby --update-kernel=ALL --args='GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 ip={{ ansible_default_ipv4.address }}::{{ ansible_default_ipv4.gateway }}:{{ ansible_default_ipv4.netmask }}::{{ ansible_default_ipv4.alias }}:none"'
- name: Enroll Clevis clients
include_role:
name: rhel-system-roles.nbde_client
vars:
nbde_client_bindings:
- device: /dev/sdc
encryption_password: "{{ luks_password }}"
password_temporary: true
slot: 2
servers:
- http://rhel-hetz-tang1.example.com
- http://rhel-hetz-tang2.example.comluks_password stecktluks_password mit ansible-vault vor neugierigen Blicken zu schützenpassword_temporary: true wird die LUKS-Passphrase aus dem jeweiligen Key-Slot gelöscht, nachdem das LUKS-Device für NBDE konfiguriert wurdeAchtung (I know, the warning comes after the spell): Wenn zur Laufzeit ein Fehler auftritt und der Key-Slot mit der LUKS-Passphrase bereits gelöscht wurde, die NBDE-Konfiguration jedoch nicht erfolgreich war, verliert man Zugriff auf das LUKS-Device. In meiner Labor-Umgebung bin ich das Risiko eingegangen. In der echten Welt, müsst ihr selbst entscheiden, ob ihr mehr Vorsicht walten lasst.
Zur Erstellung des Playbooks habe ich die Informationen aus /usr/share/doc/rhel-system-roles/nbde_client/README.md und dem Kapitel 12.18. Using the nbde_client System Role for setting up multiple Clevis clients genutzt. Bis ich festgestellt habe, dass ich auch noch den Task „Configure ip address for interface during early boot“ benötige, hat es ein wenig gedauert. Nun habe ich allerdings ein Playbook, dass ich zukünftig wiederverwenden kann.
In der erstellten Konfiguration, können die LUKS-Devices nur entschlüsselt werden, wenn mindestens einer der beiden Tang-Server im Netzwerk erreichbar ist. Wird ein so gesicherter Server gestohlen und sind die Tang-Server nicht aus dem Internet erreichbar, bleiben die Daten in der verschlüsselten Partition wie gewohnt geschützt. Es ist jedoch möglich den Server neuzustarten, ohne manuell die LUKS-Passphrase an der Konsole eingeben zu müssen.
Kurz notiert: Nextcloud (Dateispeicher) und Roundcube (Webmail) gehen eine Partnerschaft ein. Wie heute das Nextcloud-Team in einer Blogmitteilung bekannt gab, wird Roundcube in die "Nextcloud family" aufgenommen. Dabei lässt sich die Kooperation in erster Linie strategisch verstehen, wird aber bereits kurzfristige Auswirkungen haben, da das Entwicklerteam des bekannten Webmail-Clients vergrößert werden kann.
Die wichtigste Information bei der Nachricht ist, dass Roundcube nach aktuellem Stand weiterhin als eigenes Produkt erhalten bleibt. Es handelt sich somit nicht um eine "Verschmelzung" bzw. "Übernahme" des Produkts.
Die Nachricht sendet allerdings ein positives Signal für produktiv eingesetzte Open-Source-Systeme aus: Nextcloud als ein in Unternehmensumgebungen weit verbreiter Cloud-Dienst (Dateispeicher, Kalender, etc.) ermöglicht anderen Büroprogrammen, sich weiterzuentwickeln und auf dem technisch aktuellen Stand zu bleiben. Dies meine ich dabei besonders im Sicherheitskontext. Zero-Days können immer auftreten, aber mit viel Entwicklungsressourcen kann die Wahrscheinlichkeit proaktiv gesenkt werden.
Nextcloud möchte somit auch einen attraktiven Gegenpol für klassische proprietäre Anwendungen aufbauen. Wir können also gespannt sein, was sich aus der Partnerschaft entwickelt.
Aktuell setze ich mich ein wenig mit MongoDB auseinander und habe mir lokal mit Docker eine Test-Installation eingerichtet:
docker run --name mongo -d mongodb/mongodb-community-server:latest
docker exec -it mongo mongosh
Using MongoDB: 7.0.3
Using Mongosh: 2.1.0
test> ...
Je nachdem, wie Sie Docker installiert haben, müssen Sie sudo vor jedes docker-Kommando stellen.
Zum Kennenlernen hätte ich nun gerne ein paar Beispieldatenbanken. Und tatsächlich stellt Mongo für sein Cloud-Angebot Atlas eine ganze Palette von Testdatenbanken zur Verfügung. Eine Kurzbeschreibung der Datenbanken finden Sie hier:
https://www.mongodb.com/docs/atlas/sample-data
Genau die Datenbanken hätte ich gerne in meiner lokalen Installation als »Spielwiese«. Leider ist die Installation dieser Beispieldatenbanken bei der lokalen Verwendung von MongoDB umständlich. Auf GitHub gibt es Dumps (Backups) der Beispieldateien im JSON-Format:
git clone https://github.com/mcampo2/mongodb-sample-databases.git
cd mongodb-sample-databases
lstree sample_*
sample_airbnb/
listingsAndReviews.json
sample_analytics/
accounts.json
customers.json
transactions.json
sample_geospatial/
shipwrecks.json
...
Jetzt geht es darum, die Datenbanken zu importieren. Unter Linux oder macOS führen Sie dazu für jede JSON-Datei aus samples_xxx ein Kommando nach dem folgenden Muster aus:
cat sample_airbnb/listingsAndReviews.json | \
docker exec -i mongo mongoimport --db sample_airbnb --collection listingsAndReviews
Beachten Sie, dass Sie docker exec mit der Option -i ausführen müssen (nicht -it wie bisher für den interaktiven Betrieb), damit die Weitergabe von Daten über den Pipe-Operator | funktioniert.
Anstatt nun jede JSON-Datei einzeln zu importieren, bietet sich die Formulierung eines winzigen Scripts an. Er richtet für jedes DB-Verzeichnis sample_xxx eine gleichnamige Datenbank ein und importiert jedes JSON-Dokument als Collection. (Beachten Sie, dass die auf Atlas definierten Indize nicht eingerichtet werden. Wenn Sie zum Testen einen Index brauchen, müssen Sie diesen selbst einrichten.)
#!/bin/sh
for db in sample_*; do
for file in $db/*.json; do
collection="$(basename $file .json)"
cat $file | docker exec -i mongo mongoimport --db $db --collection $collection
done
done
Das Script muss in dem Verzeichnis ausgeführt werden, in dem sich die von GitHub heruntergeladenen sample_xxx-Verzeichnisse befinden.
Nach dem Import können Sie sich in der Mongo Shell überzeugen, dass alles geklappt hat:
docker exec -it mongo mongosh
test> show dbs
admin 40.00 KiB
config 72.00 KiB
local 40.00 KiB
sample_airbnb 52.09 MiB
sample_analytics 9.39 MiB
sample_geospatial 784.00 KiB
sample_mflix 28.39 MiB
sample_supplies 968.00 KiB
sample_training 61.30 MiB
sample_weatherdata 2.55 MiB
samples_airbnb 52.09 MiB
test 112.00 KiB
test> use sample_airbnb
sample_airbnb> show collections
listingsAndReviews
sample_airbnb> db.listingsAndReviews.findOne()
{
_id: '10009999',
listing_url: 'https://www.airbnb.com/rooms/10009999',
name: 'Horto flat with small garden',
...
}
