ubuntuusers.de

12. Februar 2024

Stellt euch vor, ihr habt eine Menge von Servern, welche ausschließlich über IPv6-Adressen verfügen und deshalb keine Dienste nutzen können, welche nur über IPv4 bereitgestellt werden. Wer sich dies nicht vorstellen mag, findet in „IPv6… Kein Anschluss unter dieser Nummer“ ein paar Beispiele dafür.

Was kann man nun tun, damit diese IPv6-only-Hosts dennoch mit der IPv4-only-Welt kommunizieren können?

Eine mögliche Lösung ist die Nutzung eines Dualstack-Proxy-Servers. Das ist ein Server, welcher über Adressen beider Internet-Protokoll-Versionen verfügt und so stellvertretend für einen IPv6-Host mit einem IPv4-Host kommunizieren kann. Das folgende Bild veranschaulicht den Kommunikationsablauf:

Ablauf der Netzwerkkommunikation eines IPv6-Hosts mit einem IPv4-Host über einen Dualstack-Proxy-Server

Im Bild ist zu sehen:

  1. Wie IPv6-Host A eine Verbindung über IPv6 zum Proxy-Server B aufbaut und diesem bspw. die gewünschte URL mitteilt
  2. Der Proxy-Server B baut nun seinerseits eine IPv4-Verbindung zu IPv4-Host C auf, welcher die gewünschten Inhalte bereitstellt
  3. IPv4-Host C sendet seine Antwort über IPv4 an den Proxy-Server
  4. Der Proxy-Server sendet die gewünschten Inhalte anschließend via IPv6 an den IPv6-Host A zurück
Screencast zur Demonstration der Proxy-Nutzung

Das obige Video demonstriert die Nutzung eines Proxy-Servers durch den Abruf einer Demo-Seite mit curl:

  1. Mit dem host-Kommando wird gezeigt, dass für die Demo-Seite kein AAAA-Record existiert; die Seite ist also nicht via IPv6 erreichbar
  2. Mit dem ip-Kommando wird geprüft, dass der Host auf dem Interface ens18 ausschließlich über IPv6-Adressen verfügt
  3. Ohne Proxy ist die Demo-Seite nicht abrufbar
  4. Erst durch Nutzung des Proxys kann die Seite abgerufen werden

Funktioniert das auch von IPv4 nach IPv6?

Ja. Entscheidend ist, dass der verwendete Proxy beide IP-Versionen unterstützt.

Welcher Proxy ist empfehlenswert?

Der Proxy-Server muss beide IP-Versionen beherrschen. Ich persönlich bevorzuge Squid. Dieser ist in so gut wie allen Linux-Distributionen verfügbar, weit verbreitet, robust und selbstverständlich Freie Software.

Sind damit alle Herausforderungen bewältigt?

Für eine Virtualisierungs-Umgebung mit einer IPv4-Adresse und einem /64-IPv6-Netzsegment funktioniert diese Lösung gut. Sie funktioniert auch in jeder anderen Umgebung, wie gezeigt. Man beachte jedoch, dass man mit nur einem Proxy einen Single-Point-of-Failure hat. Um diesem zu begegnen, kann man Squid mit keepalived hochverfügbar gestalten.

Keepalived ist ebenfalls Freie Software. Sie kostet kein Geld, erhöht jedoch die Komplexität der Umgebung. Verfügbarkeit vs. Komplexität möge jeder Sysadmin selbst gegeneinander abwägen.

Wie mache ich meine IPv6-Dienste für IPv4-User erreichbar, die keinen Proxy haben?

Das Stichwort lautet Reverse-Proxy. Ein Artikel dazu erscheint in Kürze in diesem Blog. ;-)

Weiterführende Quellen und Links

11. Februar 2024

Firefox bekommt eine neue Funktion, um bei Herüberfahren mit der Maus über einen Tab eine Vorschau der jeweiligen Website anzuzeigen.

Bislang zeigt Firefox bei Herüberfahren mit der Maus über einen Tab einen ganz einfachen Tooltip mit dem Titel der Website als Inhalt an. Diesen hat Mozilla für die Tabs nicht nur optisch überarbeitet, sondern zeigt jetzt zusätzlich die URL sowie einen Screenshot der geöffneten Website an.

Tabvorschau Firefox

Die Funktion kann ab Firefox 123 über about:config aktiviert werden, indem der Schalter browser.tabs.cardPreview.enabled per Doppelklick auf true gesetzt wird. Allerdings ist zu beachten, dass die Arbeiten an der Funktion noch nicht komplett abgeschlossen sind und daher für die finale Version von Firefox 123 auch noch keine standardmäßige Aktivierung geplant ist.

Wird zusätzlich der Schalter browser.tabs.cardPreview.showThumbnails auf false gesetzt, können die neuen Tooltips ohne Vorschaubilder genutzt werden. Der Schalter browser.tabs.cardPreview.delayMs kontrolliert die Verzögerung, wann der Tooltip gezeigt werden soll. Standardmäßig steht diese Option auf 1000 (Millisekunden), sodass der Tooltip erst erscheint, nachdem man wenigstens eine Sekunde mit der Maus auf dem Tab war.

Der Beitrag Firefox bekommt Tabvorschau erschien zuerst auf soeren-hentzschel.at.

Gestern hatte ich einen Artikel veröffentlicht, in dem ich darauf hingewiesen habe, dass ich vorerst nichts mehr (automatisiert) auf Mastodon veröffentlichen werden. Grund hierfür war, dass nach der Deaktivierung des Applets (durch mich selbst) bei IFTTT eine erneute Aktivierung gescheitert ist. Der Grund ist wohl, dass die Funktion, neue Einträge eines RSS Feeds bei Mastodon (oder anderen Plattformen) per Webhook zu veröffentlichen, nun kostenpflichtig ist.

Bis gestern hat das Applet, soweit ich es nachvollziehen kann, aber seinen Dienst getan. Hätte ich es nicht deaktiviert, würde es vermutlich immer noch funktionieren. Wenn ich recht habe, finde ich die Art Leute zu kostenpflichtigen Tarifen zu “überreden” fragwürdig. Laut Quellen wie beispielsweise https://old.reddit.com/r/ifttt/comments/18p7pxa/webhooks_suddenly_stopped_working_requires_pro/ sind scheinbar auch andere Nutzer betroffen.

Aufgrund meines Artikels hat PepeCyB eine Alternative bei https://rss-parrot.net erstellt https://fryboyter.de/vorerst-keine-veroeffentlichungen-mehr-bei-mastodon/#isso-977. Und Masin hat auf den Dienst https://mastofeed.org hingewiesen https://fryboyter.de/vorerst-keine-veroeffentlichungen-mehr-bei-mastodon/#isso-978

Vielen Dank hierfür.

Ich habe mich allerdings für eine andere Lösung entschieden, da ich möglichst unabhängig von Diensten Dritter sein möchte. Gestern hatte ich mir noch diverse alternative Lösungen angesehen. Schlussendlich bin ich bei https://gitlab.com/chaica/feed2toot gelandet. Das Tool macht, was es soll und man kann es leicht selbst hosten. Auf “Dirks Logbuch” wurde schon vor einiger Zeit eine entsprechende Anleitung veröffentlicht, an der ich mich orientiert habe.

Das Konto bei IFTTT habe ich übrigens gelöscht.

… und warum und wie ich es trotzdem tat.

Vor wenigen Wochen habe ich mein zweites Fachbuch fertiggestellt. In diesem Blogpost gehe ich ein wenig tiefer ein, was meine Motivation war, wie sich der Fortschritt gestaltet hat und welche Hilfsmittel (nicht) geholfen haben.

Bücher schreiben klingt für viele total toll. Die Realität fühlte sich häufig allerdings das Meme oben an …

Rückblick

Vor langer Zeit fing ich hier auf meinem Blog eine vierteilige Tutorial-Reihe zu Git an. Der erste Blogpost erschien im Oktober 2014. Das ist jetzt auch schon fast zehn Jahre her. Meine damalige Intention war recht einfach: Ich hatte Lust etwas über das Thema zu schreiben, denn ich bekam sowohl bei der Arbeit, als auch bei der Mitarbeit in Open-Source-Projekten ständig Fragen, wie dieses Git denn nun funktioniert. Da ich keine Lust hatte, es immer wieder zu erklären, schrieb ich es eben einmal ordentlich runter und verlinkte diese Blog-Posts und beantwortete erst später konkretere Fragen.

Durch eine Verkettung von Umständen kam es dann dazu, dass ich die Möglichkeit hatte, ein Buch über Git zu schreiben. Diese vier Artikel dienten als Basis für das Buch, wo ich natürlich dann sehr sehr viel erweitert habe. Zwei Jahre später im August 2016, erschien dann die erste Auflage meines Git-Buches beim mitp-Verlag. Im Mai 2019 folgte die zweite Auflage, im März 2021 die dritte und im März 2022 folgte der Git Schnelleinstieg als abgespeckte Variante. Über die vergangenen 7,5 Jahre verkauften sich knapp über 4000 Exemplare.

Die Vor- und Nachteile des Autorendaseins

Ein Buch geschrieben zu haben, hat sowohl diverse Vor- als auch Nachteile. Jedes Mal, wenn mir jemand Anfängerfragen zu Git gestellt hat, folgte von mir ein stark ironisches „Also … ich kann dir da ein Buch empfehlen“. Das war immer wieder zur Aufheiterung lustig. Was ich meistens nicht so geil fand, waren Random Gespräche bei Feiern jeglicher Art. Da wurde man plötzlich von Freunden, Bekannten und Verwandten anderen Personen als Autor vorgestellt … was dazu geführt hat, dass ich ständig wildfremden Leuten, die nicht in der IT sind, erklären musste, was denn diese Versionsverwaltung mit Git ist. Meistens sah ich nach zwei oder drei Sätzen schon, wie sie bei meinem Versuch es zu erklären, ausgestiegen sind, aber natürlich empfanden sie es als super und toll! Spaß macht das nicht. Außerdem ist scheinbar „Buch schreiben“ ein Bucketlist-Item für viele Leute. Ich weiß bis heute nicht, warum, aber ich muss auch nicht alles verstehen.

Wer übrigens etwas näher hören will, wie so ein Buch entsteht, darüber habe ich in der zweiten Folge unseres Podcasts TILpod von und mit Dirk Deimeke gesprochen.

Ursprüngliche Motivation & Umsetzung

Zurück zur Motivation und der Umsetzung: Nachdem ich die ursprünglichen Blogposts ohne tieferen Hintergedanken geschrieben habe, war das bei einem Buch natürlich etwas anderes. Die Qualitätsansprüche sind hier natürlich deutlich höher, denn hier bezahlen die Kunden mit Geld. Von diesem Geld blieb allerdings nicht sehr viel in meinem Geldbeutel hängen. Dass man als Autor nicht reich wird, war mir bewusst.

Eine gewisse Reputation und ein „einfacherer“ Einstieg in idealerweise gut bezahlten Job mit guten Arbeitsbedingungen war mein Hauptmotivationstreiber. 2015, als ich mit der Arbeit am Buch begann, war ich gerade erst mit dem Bachelor fertig. Die darauffolgenden Jobwechsel waren beim Hinblick auf Gehalt, Arbeitsbedingungen und Interessantheit der Tätigkeiten alle nicht so das wahre (in verschiedenen Konstellationen).

Long story short: Im April 2020 fing ich meinen Job als Solutions Architect bei GitLab an. Zu den ausgeschriebenen Jobs bei GitLab hatte ich ohnehin schon seit einigen Jahren einen Blick geworfen und dann hat es auch auf Anhieb geklappt. Ein deutlicher Gehaltssprung war dabei, deutlich bessere Arbeitsbedingungen und auch die Tätigkeit im Pre-Sales, was ich so vorher auch nie gemacht habe, hat super gepasst. Mein Plan ging also einige Jahre später auf: Durch das Git-Buch habe ich mich deutlich tiefer in Git und dem gesamten Software-Delivery-Lifecycle eingearbeitet, sodass ich mich für den Job qualifizieren konnte.

Soweit so gut. Ein Grund für ein komplett neues Buch brauchte ich eigentlich nicht … oder? Oder?

Motivation für das zweite Buch

Tja, ich wäre nicht ich, wenn ich immer wieder ein größeres Projekt angehen würde.

Fachliche Motivation

Zunächst zur fachlichen Motivation: In tagtäglichen Gesprächen mit diversen (potenziellen) Kunden von GitLab merkte ich primär eins: Viele fokussieren sich viel zu stark auf die eingesetzten Tools – etwa GitLab –, ohne jedoch zu schauen, ob und wie „kaputt“ die Arbeitskultur ist.

GitLab selbst positioniert sich als ganzheitliche DevOps-Plattform, womit man einfacher und schneller Projekte mit DevOps-Prinzipien umsetzen kann, in dem besser in einem, statt in vielen, Tools kollaboriert wird. Das ist gut, richtig und wichtig.

Wichtige Voraussetzung ist allerdings, dass man erst die Arbeitskultur anpasst und dann die Prozesse anpasst, gefolgt vom Tooling. Im DevOps-Kontext spricht man nicht umsonst von „People over Processes over Tools“. Die besten Tools helfen nicht, wenn die Prozesse beschissen sind. Die Prozesse helfen nicht, wenn die Kolleginnen und Kollegen mit den verschiedenen Rollen (Development, Operations, Security, QA, …) gegeneinander statt miteinander arbeiten.

Mit diesem Buch möchte ich aufklären, wie es „richtig“ geht. Das beste, tollste, schnellste und effizienteste Auto bringt schließlich auch nicht, wenn man keine Straßen hat … und einen Führerschein auch nicht.

Fachlich war die Motivation also klar: Wenn es um DevOps geht, gibt es großen Nachholbedarf, das sehe ich schließlich bei den ganzen Gesprächen. Ein „echtes“ deutsches Buch zu DevOps gab es auch nicht, sondern nur zwei Übersetzungen aus dem Englischen. Und so reifte die Idee für das zweite Buch.

Nicht fachliche Motivation

Auf der nicht fachlichen Ebene sah es noch ein wenig anders aus. Hier kommen gleich mehrere Faktoren ins Spiel. Zunächst einmal war das Git-Buch recht technisch. Obwohl ich die Arbeit an dem Buch schon ziemlich herausfordernd fand, gab es hier meist nur eine technische Lösung, was das Schreiben deutlich vereinfacht hat. Bei DevOps ist das Ganze anders. Hier geht es viel um „weiche“ Themen, wie Menschen miteinander arbeiten. Das ist um ein Vielfaches herausfordernder. Das hat mich auch angespornt.

Weiterhin wollte ich dieses Mal bei einem größeren Verlag veröffentlichen. Die Zusammenarbeit mit dem mitp-Verlag war zwar gut und ich soweit zufrieden, aber im Marketing und bei Verkaufszahlen merkt man dann schon einige Unterschiede. Der Einstieg beim größten deutschen IT-Verlag, dem Rheinwerk-Verlag, hat mit diesem Buch dann auch funktioniert.

Die damalige Motivation für einen „besseren“ Job hatte ich beim DevOps-Buch hingegen nicht. Finanzielles spielte demnach weder primär noch sekundär eine Rolle. Ich bin trotzdem gespannt, welche neue Türe sich hierdurch gegebenenfalls öffnen.

Meine grundlegende Motivation liest sich bis hierhin eigentlich gut, aber die Motivation muss schließlich nicht nur beim Start vorhanden sein, sondern auch während man das Buch schreibt …

Der Fortschritt …

Die Motivation kontinuierlich und mit (höchster) Disziplin am Buch zu arbeiten, klang zu Beginn viel einfacher als es am Ende dann war. Um es kurz zu sagen: Es war ein Kampf. Und das war überhaupt nicht geil.

Der Unterschied zu damals™

Im Vergleich zum Git-Buch hatte ich ein Aspekt komplett vernachlässigt. Mein Job damals war deutlich weniger anstrengend. Damals war ich rein in der Technik und ohne Reisetätigkeiten. Das lässt sich viel einfacher steuern, als mein jetziger Job. Bei GitLab hatte und habe ich jeden Tag etliche Videocalls mit Kunden. Bei diesen Calls muss ich stets fokussiert und effizient sein, was für den Kopf deutlich anstrengender ist. Zudem machte mir der Job auch noch deutlich mehr Spaß, ich hatte auch noch (ab Mai 2022) etliche Dienstreisen, die einen regelten Tagesablauf nicht ermöglicht haben. Am Ende des Arbeitstages und auch am Wochenende war so nicht mehr so viel Gehirnkapazität übrig, um stetigen Fortschritt zu gewährleisten.

Das „weiche“ Thema führte auch dazu, dass ich immer wieder überlegen musste, wie ich diverse Themen angehen sollte, damit man daraus auch etwas Sinnvolles herausziehen kann. Das führte immer wieder zu Verzögerungen, da ich dann noch die Gedanken schweifen lassen oder mit der ein oder der anderen Person aus dem Arbeitsumfeld besprechen musste, um mir neue Eindrücke abzuholen. Gleichzeitig hing die Frist immer im Nacken …

Produktivitätstechniken

Während des Schreibens probierte ich auch immer wieder ein paar Produktivitätstechniken aus. Je nach Phase des Buches war das auch relativ gut und hilfreich.

Zu Beginn, nachdem die Grobstruktur gestanden hatte, fokussierte ich mich zunächst um Stichpunkte. Ich tippte also, was mir in den Kopf kam zu den einzelnen Themen in Stichpunkten herunter, und kümmerte mich kaum um die Grammatik. Das war wichtig, um überhaupt mal die Gedanken strukturieren zu können. Dabei fielen mir noch etliche Themen ein, die ich vorher gar nicht betrachtet hatte … die dann zu neuen Kapiteln führten.

Ich setzte hierfür auf die Pomodoro-Technik: Ich versuchte jeden Tag mindestens 25min, ohne Ablenkungen, Stichpunkte herunterzuschreiben, gefolgt von einer 5min Pause. Danach habe ich weiter gemacht … oder häufig auch nicht. Das war auch völlig in Ordnung.

Das Ganze funktionierte so lange, bis es nicht mehr funktionierte. Irgendwann hatte ich dann alles notiert und es ging mehr Zeit drauf, zu überlegen, was man noch vergessen hat. Gerade für diese Phase benötigte ich viel Ruhe und Zeit, die durch Real-Life und Vollzeitjob nicht sonderlich gegeben war.

Es gab also immer wieder Phasen – teilweise einige Monate – wo ich wenig bis gar nicht am Buch gearbeitet habe. Dabei war das offene Großprojekt, das Wissen, noch etwas erledigen zu müssen, die Frist und was sonst noch dazu gehört, stets im Hinterkopf. Schön war das zugegeben nicht wirklich.

Später, beim Ausformulieren der Stichpunkte, habe ich mir hingegen ein Output-Ziel gesetzt. An Arbeitstagen wollte ich für zwei zusätzliche Seiten sorgen, an arbeitsfreien Tagen hingegen fünf. Da dann primär viel ausformuliert werden musste, klappte das für eine Weile auch einigermaßen gut.

Öffentlicher Statusbericht

Gleichzeitig habe ich meinen eigenen Podcast TILpod, den ich mit Dirk Deimeke betreibe, vorangetrieben. Dort erzählte ich in jeder Folge, wie der Fortschritt am Buch ist. Treue Hörer und Hörerinnen haben also stets mitbekommen, wie ich vorankomme … oder auch nicht.

Das öffentliche Dokumentieren des Fortschritts hat hingegen nicht zu mehr Druck geführt, zumindest nicht bewusst. Einige lustige Gegebenheiten haben sich hingegen schon dadurch ergeben. Vergangenes Jahr war ich dienstlich bei der KubeCon in Amsterdam, wo ich Standdienst bei GitLab gemacht habe. Es kamen erstaunlich viele mir unbekannte Personen auf mich zu und fragten, ob mein Buch denn nun fertig ist. Auch eine spannende Form, auf Hörer vom Podcast zu treffen.

Ursprünglich war mein Plan, bis Ende 2022 fertig zu werden. Dass das nicht zu halten war, war mir schon zu Beginn klar. Unterschrieben habe ich den Autorenvertrag übrigens im Januar 2022. Erst im Sommer 2023, nachdem ich mehrfach die Fertigstellung nach hinten schieben musste, war der erste Entwurf fertig. Und dann ging erst die Arbeit mit diversen Korrekturläufen, dann zusammen mit meinem Lektor, los.

Mein Ziel es dann noch im Jahr 2023 fertigzustellen hat dann nicht auch nicht mehr geklappt. Nachdem ich selbst für so viel Verspätung gesorgt hatte, lag es dann auch noch eine Weile bei meinem Lektor auf Halde: Mein Buch ist schließlich nicht das Einzige, meins musste entsprechend warten.

Der Spätsommer und Herbst war dann ebenfalls ziemlich frustrierend. Jeden Monat verschob sich die Fertigstellung um einen Monat. Jedes Mal, wenn ich dachte, dass ich jetzt wirklich mal fertig wurde, mussten wir es abermals um einen Monat verschieben. Insgesamt lagen zwischen der Unterzeichnung des Autorenvertrags und der Fertigstellung ziemlich genau zwei Jahre.

(Keine) Hilfsmittel

Ganz unabhängig von der Motivation und der Produktivität finde ich es auch noch spannend auf mögliche Hilfsmittel zu werfen. Insbesondere ChatGPT, LanguageTool und Obsidian.

ChatGPT

Während des Schreibens des Buches ploppte dann auch noch ChatGPT auf und der AI-Hype ging so richtig los. An vielen Stellen las ich dann, dass man ja jetzt „ganz einfach“ Texte schreiben lassen kann und bald nur noch AI-generierte Bücher gibt.

Ich dachte dann: Ja gut, ich habe hier ja ein Beispiel, schauen wir mal, ob ChatGPT hier überhaupt realistisch helfen kann. Tja, nun … tat es nicht wirklich.

Ich hatte natürlich nicht vor, mein Buch per ChatGPT schreiben zu lassen. Das funktioniert ohnehin nicht. Die Frage, die ich mir stattdessen stellte, ging mehr in die Richtung: Wie kann mir ggf. ChatGPT helfen?

Typische Prompts à la „Schreib mir etwas zu $THEMA im Rahmen von DevOps“ produzierten (natürlich) sehr, sehr oberflächliche Texte, die sich zu 95 % ohnehin immer nur wiederholten. Praktisch war hingegen, ChatGPT zu nutzen, um zu prüfen, ob man etwas vergessen hatte. So ergänzte ich zur „normalen“ Recherche auch ChatGPT, wobei der tatsächliche Nutzen eher gering war, schließlich stand der Großteil und ChatGPT kann man ja bekanntlich auch nicht alles glauben. Häufig kam da auch nur Mist raus.

LanguageTool

ChatGPT war also nur wenig hilfreich, anders sah es bei LanguageTool aus, was für sprachliche Korrekturen sehr hilfreich war. Dafür setzte ich auf die Premium-Variante für knapp 60 € pro Jahr.

LanguageTool gab mir einige Hinweise für die korrekte Nutzung der deutschen Sprache. Viel zu lange Sätze, Wortwiederholungen, Kommasetzung und noch etliche weitere Hinweise wurden mir dann regelmäßig angezeigt, sodass ich da noch einmal drauf geschaut habe.

Praktisch war zudem das Feature „Sentence rephrasing by A.I.“. Hier konnte man einzelne Sätze aus einigen Paragrafen neu formulieren lassen. Das half mir insbesondere dann, wenn ich an einigen komplexen Sätzen viel zu lange hing, weil diese kaum verständlich waren.

Obsidian

DIe meiste Zeit beim Schreiben verbrachte ich im Tool Obsidian. Das ist eigentlich mehr als persönliches Knowledge-Base gedacht. Für mich half es hingegen das Buch primär in Markdown herunter zu schreiben, da es mich nicht zu sehr abgelenkt hat. Viele der Features von Obsidian habe ich allerdings nicht verwendet. Einige fehlerhafte Verlinkungen fielen mir dann nur regelmäßig auf. LanguageTool ließ sich zudem als Plug-in einbinden und nutzen.

Zum Ende hin musste ich allerdings sowieso auf Microsoft Word switchen, weil das der Workflow vom Verlag so vorgibt. Bis dahin konnte man es wenigstens gut in Git-Repositorys tracken, sodass ich Anpassungen von Reviewern und Lektor einfach nachvollziehen konnte.

Fazit

Warum sollte man also eher kein Fachbuch schreiben?

Es ist verdammt anstrengend, es geht richtig viel Zeit drauf und ist häufig auch echt frustrierend. Reich wird man nicht. Ob es sich für mich gelohnt hat, wird sich zeigen. In den letzten zwei Jahren verbrachte ich also sehr viel Zeit mit meinem Vollzeitjob und dem Schreiben des Buches. Viel Zeit drum herum, blieb da nicht. Gesund war das ganze auch nicht sonderlich.

Das fertige Buch

Wer bis hierhin gelesen hat, wird gemerkt haben, dass das Thema des Buches eine untergeordnete Rolle gespielt hat, dazu folgt noch ein weiterer Artikel. Das DevOps-Buch gibt es überall da, wo es Bücher gibt – insbesondere direkt beim Verlag. Es erscheint am 5. März 2024. Ich warte zurzeit noch auf meine Belegexemplare und kann es kaum erwarten.

10. Februar 2024

Seit einiger Zeit wird unter https://social.tchncs.de/@fryboyter ein Hinweis angezeigt, wenn ich einen neuen Artikel veröffentlicht habe. Damit ist vorerst Schluss.

Für die automatische Veröffentlichung hatte ich bisher den Dienst IFTTT verwendet. Vorhin wollte ich etwas an dem betreffenden Applets ändern und habe dies hierbei deaktiviert. Was ich wohl lieber nicht gemacht hätte. Wenn ich das Applet nun aktivieren will, erhalte ich nun den Hinweis “This Applet has Pro features”. Scheinbar sind Webhooks bei IFTTT zwischenzeitlich kostenpflichtig geworden. Und sobald man ein ehemalig kostenloses Applet deaktiviert, hat man die Arschkarte gezogen und soll nun zahlen, wenn man es wieder aktivieren will. 2,92 Dollar im Monat, wenn man jährlich zahlt oder 3,49 Dollar, wenn man monatlich bezahlt.

Wenn man bedenkt, dass ich bei Mastodon im Grunde nicht aktiv bin und dort nur entsprechende Hinweise auf neue Artikel veröffentlicht habe, will ich weder 2,92 noch 3,29 Dollar bezahlen. Zumal ich auch beispielsweise RSS-Feeds wie https://fryboyter.de/index.xml anbieten über die man sich über neue Artikel in Kenntnis setzen lassen kann und ich IFTTT für nichts anderes nutze.

Ich hatte schon vor einiger Zeit mit Alternativen wie Node Red oder N8N experimentiert. Leider bin ich entweder komplett daran gescheitert, dass es funktioniert hat oder es wurden alle Beiträge der angegebenen Feed-Adresse bei Mastodon veröffentlicht und nicht nur der neuste Beitrag. Falls jemand hierfür eine Lösung hätte und bereit ist mir sinnvoll zu helfen, wäre es sehr nett. Ich aktiviere daher bei diesem Beitrag die Kommentarfunktion. Alternativ kann man mir auch eine E-Mail schreiben. Die Adresse ist im Impressum genannt.

  1. Experiment: Pixel Tablet als Notebook-Ersatz
  2. Google Pixel Tablet als Notebook-Ersatz: Die Hardware
  3. Google Pixel Tablet als Notebook-Ersatz: Erste Erfahrungen

Vor circa einem Monat habe ich mein Notebook gegen ein Google Pixel Tablet ersetzt. Es ist ein Experiment, weil ich immer häufiger gesehen habe, dass andere das machen und ich mein Notebook nur noch selten nutze. Zuletzt war ich damit ein bisschen unterwegs und konnte das praktisch testen.

Zunächst zur Hardware. Das Pixel Tablet reicht von den Leistungsdaten natürlich spielend für meine Anforderungen. Den Stylus benötige ich überraschend selten, aber ab und an ist er ganz hilfreich. Wegen des praktischen Covers stört er auch nicht, sondern ist immer gut aufgeräumt. Die Tastatur ist leider ziemlich mäßig, da muss ich nochmal schauen, ob es Alternativen gibt. Andererseits war es zum längere Texte tippen sowieso nicht gedacht.

Android taugt als Notebook-Ersatz überraschend gut. Das Dock ist als zentrales Steuerungsinstrument im Alltag brauchbar und ermöglicht einen schnellen Wechsel zwischen den wichtigsten Apps im Vollbildmodus. Die Möglichkeit zwei Apps gleichzeitig anzuzeigen nutze ich erstaunlich selten. Die verfügbaren System-Apps und das Angebot an Drittanbieter-Apps genügen meinen Ansprüchen weitestgehend. Allerdings ist das Angebot in F-Droid für diese Zwecke noch schmaler als beim Smartphone, weshalb der Aurora Store auf dem Tablet für mich unverzichtbar ist.

Es überrascht kaum, dass das Tablet für rein konsumierende Nutzung geeignet ist. Surfen im Internet, Videos schauen, Musik hören. Dafür hat Google es ja auch ausgelegt. Die Android-Version von VLC überzeugt schon auf dem Smartphone und skaliert auf dem Tablet ebenso hervorragend.

Ein paar Veränderungen bei den Apps verglichen mit meinem Smartphone-Nutzungsverhalten habe ich aber vorgenommen. Beim Browser bin ich von Firefox (Fennec) zu Vanadium gewechselt und bei der E-Mail-App von K9 zu FairEMail. Die Gründe waren unterschiedlich. K9-Mail ist eine gute Smartphone-App, aber war mir auf dem Tablet zu limitiert. FairEmail ist zwar bei den Einstellungen maßlos überladen, aber kann dadurch natürlich viel kleinteiliger angepasst werden. Bei Fennec vs. Vanadium überwogen Sicherheitsüberlegungen. Chromium-Forks haben insbesondere auf der Android-Plattform die Nase vorn und da ich den Browser viel intensiver nutze als auf dem Smartphone, habe ich hier umgestellt. Für den PIM-Bereich habe ich auf Fossify Kalender umgestellt (Fork von Simple Mobile Tools nach dem Verkauf). Etar wird kaum noch entwickelt und für das Tablet genügte die App mir dann einfach nicht mehr. nicht mehr.

Andere Programme spielen auf dem Smartphone nur eine untergeordnete Rolle. Die integrierte Dateiverwaltung reicht auch am Tablet völlig für meine Bedarfe. Synology Drive nutze ich nun intensiver und synchronisiere die wichtigsten Verzeichnisse mit meinem Desktop. Office-Arbeiten lassen sich sehr gut mit SoftMaker Office erledigen.

Das Bild zeigt einen Screenshot der Android-App SoftMaker TextMaker

Das ist zwar von der UI kaum auf Touchgeräte ausgelegt, aber funktioniert dafür erstaunlich gut. Als Ansicht habe ich “Symbolleisten: Modernes Thema” mit Toucheingabe gewählt. Dadurch lässt es sich gut mit einem Stylus bedienen, aber die Elemente sind sehr dezent in einer Leiste angeordnet. Passend für meinen Umsteig auf das Tablet hat Zotero eine erste Beta der App für Android veröffentlicht. Die ist zwar optisch ein ziemlich “billiger” iOS-Port, aber funktioniert gut.

Das Bild zeigt einen Screenshot der Android-App Zotero

Verglichen mit meinem letzten Artikel zu Apps für GrapheneOS ergeben sich am Tablet ein paar Abweichungen.

KategorieApp
BrowserVanadium (vorinstalliert)
BrowserTor Browser (zusätzliche Paketquelle The Guardian Project)
RSSFeedMe (Open Source, aber nur über Aurora Store verfügbar)
MailFairEmail
PGP-VerschlüsselungOpenKeychain
PodcastAntennaPod
MultimediaVLC
SicherheitRethink DNS (siehe Artikel)
KalenderFossify Calendar
AufgabenTasks
Kontakt- / KalendersnychronisationDAVx5
Internetkalender abonnierenICSx5
WetterForecastie
OTPFreeOTP+
PC-IntegrationKDE Connect (nur bei KDE Plasma und GNOME möglich)
PasswörterKeePassDX
PDF-DokumentePDF (vorintalliert)
KameraKamera (vorinstalliert)
Karte & NavigationOrganic Maps
NotizenSynology Notes (Synology Download / Aurora Store)
OfficeSoftMaker Office (Aurora Store)
DateiverwaltungDateien (vorinstalliert)
CloudSynology Drive (Synology Download / Aurora Store)

Insgesamt bin ich immer noch hoch zufrieden mit meiner Entscheidung. Ich schleppe jetzt deutlich weniger Ballast durch die Gegend. Sowohl was das physische Gewicht betrifft als auch den Wartungsaufwand eines zweiten Desktopsystems betreffend. Einschränkungen habe ich noch nicht erlebt. Das Notebook ist nun verkauft.

Der Artikel Google Pixel Tablet als Notebook-Ersatz: Erste Erfahrungen erschien zuerst auf Curius

Wenn ich meinen eigenen Aussagen vertrauen kann, habe ich zum Hervorheben von Code seit 2018 Prism.js verwendet. Seit einiger Zeit habe ich allerdings öfters darüber nachgedacht, ob ich Prism.js weiterhin nutzen will. Und die Antwort lautet nein.

Ja, Prism.js funktioniert technisch gesehen. Zwar nicht perfekt, aber es gab bisher keine größeren Probleme damit. Prism.js verwendet allerdings JavaScript. Wer also diese Internetseite ohne aktiviertes JavaScript aufruft, bekommt nur den nackten Code angezeigt. Das ist zwar nicht schön aber auch nicht tragisch.

Schlimmer ist, dass das Projekt Prism.js scheinbar tot ist. Die Entwicklung von Version 1.x wurde zugunsten der Entwicklung von Version 2 mehr oder weniger auf Eis gelegt, sodass Version 1.29 die letzte veröffentlichte Version darstellt. Diese wurde im Augst 2022 veröffentlicht. Die letzten Änderungen an Version 2 wurden vor 9 Monaten durchgeführt. Seit dem gab es unter https://github.com/PrismJS/prism/discussions/3531 mehrere Nachfragen in den letzten Wochen und Monaten wie es um Prism.js steht. Eine Reaktion seitens der Entwickler gab es bisher keine, obwohl diese zwischenzeitlich durchaus auf Github aktiv waren. Daher meine Vermutung, dass das Projekt nicht weiterentwickelt wird. Über die Hintergründe kann ich nur spekulieren, also lasse ich es.

Ja, aber Prism.js funktioniert doch? Richtig. Aber es gäbe Verbesserungsbedarf. Und es wurden in den letzten Jahren schon ein paar Sicherheitslücken entdeckt und behoben. Und genau diese Sicherheitslücken machen mir immer mehr Sorgen. Was, wenn nächste Woche eine weitere entdeckt wird? Wird darauf reagiert und eine neue Version veröffentlicht? Oder zumindest ein Patch? Oder wird darauf nicht reagiert?

Da mir die Situation zu ungewiss ist, habe ich mir einige Code Highlighter wie Highlight.js angesehen. Schlussendlich habe ich mich allerdings für Chroma entschieden. Und das hauptsächlich aus zwei Gründen.

  • Ich nutze Hugo zum Erzeugen dieser Internetseite. Und Chroma ist Bestandteil von Hugo.

  • Und Chroma kommt ohne JavaScript aus. Denn das Hervorheben des Codes wird direkt beim Erzeugen der Internetseite durchgeführt. Ganz so, wie wenn ich das Hervorheben des Codes manuell mit ein paar Tags und CSS gemacht hätte.

Der erste Grund spart mir somit die manuelle Aktualisierung. Der zweite Grund sorgt dafür, dass der Code auch dann hervorgehoben wird, wenn man JavaScript nicht aktiviert hat. Und die beim Aufruf von fryboyter.de übertragene Datenmenge wird auch weniger. Nicht, dass dies ins Gewicht fallen würde, aber ca. 50 Kilobyte sind für diese Seite prozentual gesehen durchaus nicht wenig.

Es gibt aber auch Nachteile.

Ein Umbruch langer Zeilen ist mit Chroma für mich nicht zufriedenstellend möglich. Ich frage mich allerdings, ob es vielleicht nicht sowieso besser ist, darauf zu verzichten. Auch, wenn man somit in einigen Fällen horizontal scrollen muss. Ein Zeilenumbruch im Code verbessert auch nicht unbedingt dessen Lesbarkeit.

Ein weiterer Nachteil ist, dass Chroma manchen Code nicht so gut hervorhebt wie es Prism.js gemacht hat. Dafür unterstützt Chroma zum Beispiel Go Templates, welche oft in meinen Code-Beispielen zum Einsatz kommen. Na ja, nichts ist perfekt.

Alles in allem hat sich meiner Meinung nach die Umstellung und der damit verbundene Aufwand aber gelohnt.

Das Trusted Platform Module 2 (TPM 2) wurde bereits 2014 als Standard veröffentlicht. Dennoch fristete es lange Zeit ein Schattendasein. Microsoft hob es mit den Versionen Windows 10 und Windows 11 aus dem Schatten und seit einigen Jahren befassen sich auch unter Linux mehr Entwickler damit.

Unter Linux ist aktuell TPM 2 bereits jetzt ein wichtiger Baustein für einen verifizierten Systemstart und die Möglichkeit, ein verschlüsseltes System ohne initiale Passworteingabe zu starten. Für einen Überblick über den aktuellen Stand empfehle ich folgende zwei Artikel hier im Blog:

Parallel zu den Entwicklungen bei systemd haben openSUSE und Canonical eigene Anstrengungen gestartet, um TPM stärker in die eigenen Systeme einzubinden. Ich vermute trotzdem, dass systemd als gemeinsamer Nenner vieler Distributionen, ein wichtiger Bestandteil bleiben wird.

Auf der FOSDEM 24 wurde TPM in einem anderen spanneden Kontext präsentiert, und zwar als sicheren Schlüsselspeicher. Für den Hintergrund muss man sich ein wenig mit einem gar nicht mehr so aktuellen Problem befassen. Moderne mobile Hardware wie iPhones, iPads oder Android-Smartphones haben etwas, das bei Apple als Secure Enclave bezeichnet wird oder bei Google als Titan M. Microsoft hat dafür auf einen Standard gesetzt: TPM. Das ist sehr gut, weil dadurch für Desktop-Hardware etwas ähnliches Verbreitung gefunden hat, das auch Linux das nachnutzen kann.

Das Problem ist nämlich, dass manche Daten wie biometrische Daten, aber auch wichtige Schlüssel besser nicht ohne zusätzliche Schutz im System aufbewahrt werden. Sie können dort einfach nicht so sicher geschützt werden, wie das notwendig ist. Datei- und Benutzerrechte hin oder her. Aus diesem Grund rate ich auch dringend davon ab, biometrische Verfahren mit Linux zu nutzen.

In dem FOSDEM Talk werden nun weitere Szenarien präsentiert (siehe auch den Bericht bei Heise). Ihnen gemein ist, dass sie erst möglich sind, seitdem grundlegende Arbeiten unter Linux TPM 2 auch praktisch nutzbar gemacht haben. Zu den neuen Ansätzen gehört die Möglichkeit das TPM 2-Subsystem zum versiegeln (engl. “sealed” – schwierige Übersetzung) und laden von privaten GnuPG-Schlüsseln zu nutzen. Das Verfahren ist in dem vor über einem Jahr veröffentlichten GnuPG 2.4 bereits enthalten, aber wurde bisher wenig beachtet. Möglicherweise auch, weil viele Distributionen ältere Versionen von GnuPG nutzen. Ebenso denkbar ist dies aber auch für OpenSSH, wenngleich hier noch mehr Arbeit investiert werden muss.

Vermutlich ist auch das nur der Anfang und Schlüsselspeicher werden folgen. Ich hatte lange die Sorge, dass der lautstarke FUD aus der angst- und hasserfüllten kleinen Minderheit von Linux-Anwendern, die sich unter entsprechenden Artikeln immer zu Wort meldet, bei Linux hinderlich für die Entwicklung sein könnte, aber glücklicherweise scheinen die Entwickler diese inzwischen zu ignorieren.

Der Artikel TPM 2 als sicherer Datenspeicher für Linux erschien zuerst auf Curius

9. Februar 2024

Vor einiger Zeit habe ich vom X11.org Displayserver auf Wayland umgestellt. In diesem Zusammenhang fingen an meine GTK/Gnome Applikationen überwiegend schlecht auszusehen. Die Schriftarten (Fonts) sahen einfach furchtbar pixelig aus.

Eine Abhilfe schuf dann die Installation des Pakets xdg-desktop-portal-gnome.

sudo apt install xdg-desktop-portal-gnome
sudo apt install adwaita-qt

Zusätzlich musste ich noch folgende Dateien anpassen

sudo vim /usr/share/xdg-desktop-portal/kde-portals.conf
[preferred]
default=kde
org.freedesktop.impl.portal.Settings=kde;gtk;
~                                               

Und dann noch in vim .fonts.conf

<fontconfig>
 <dir>~/.fonts</dir>
<match target="font">
  <edit name="hinting" mode="assign">
    <bool>true</bool>
  </edit>
</match>
</fontconfig>

Dann einmal neu booten und die GTK/Gnome Applikationen sehen wieder gut aus.

The post GTK Apps in KDE gut aussehen lassen first appeared on Dem hoergen Blog.

In diesem Blogpost möchte ich zeigen, wie ich ArchLinux auf einem Laptop installiere. Hierbei erfolgt die Installation auf eine verschlüsselte Partition, was bei tragbaren Geräten empfehlenswert ist. So fallen keine Daten in falsche Hände, falls das Gerät geklaut oder vergessen wird.

Image auf Stick flashen

  • Lade dir ein aktuelles Arch-Image herunter, siehe https://archlinux.org/download/
  • Stecke einen USB-Stick in dein Gerät und checke dessen /dev/-Adresse mittels
$ lsblk

Das kann dann z.B. so aussehen:

NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS  
sda             259:0    0 931,5G  0 disk
sdb               8:0    1   7,4G  0 disk 

In diesem Beispiel ist sda die Festplatte, und sdb der USB-Stick. Bei euch kann das durchaus anders aussehen.

  • Flashe das Arch-Image auf den Stick, z.B. mittels
$ dd if=archlinux*.iso of=/dev/sdb

wobei sdb bei euch evtl. entsprechend angepasst werden muss.

booten vom Stick

Stecke den Stick in den Laptop, und wähle beim Starten den Stick als Bootquelle aus. Bei mir funktioniert das, indem ich F12 beim Starten gedrückt halte.

Es sollte sich recht bald das Arch-Bootmenu melden

Wähle den ersten Eintrag aus und warte, bis dich die Kommandozeile begrüßt.

Netzwerkverbindung herstellen

Ist Arch gestartet, stellen wir als erstes eine Netzwerkverbindung her. Das Netzwerk brauchen wir, um frische Installationspakete zu holen, aber auch, um uns gleich per SSH auf die neue Kiste einzuloggen.

LAN

Wenn ein LAN-Kabel bereit liegt, kann dieses einfach eingesteckt werden, und die Verbindung sollte direkt funktionieren.

WLAN

Möchtet ihr euch mit einem WLAN verbinden, geht dies am Einfachsten mit dem Befehl

$ iwctl

Um den WLAN-Devicenamen herauszufinden hilft der Befehl

$ devices list

Meistens heisst das Device wlan0.

Stelle eine Verbindung zum WLAN her mittels

$ station wlan0 connect <SSID>

Gib das Passwort des WLANs ein. Wenn alles fertig ist, verlasse das Proggi mittels

$ exit

SSH

Ich verbinde mich an dieser Stelle gerne mittels SSH auf den Laptop. Stelle sicher, dass sshd läuft,

$ systemctl start sshd

Setze ein temporäres Admin-Passwort mittels

$ passwd

Finde die IP-Adresse des Laptops heraus, zB mittels

$ ip a

Logge dich von einem anderen PC auf die neue Kiste ein mittels

$ ssh root@IP-ADRESSE

Partitionierung der Festplatte

Nun partitionieren wir die Festplatte. Wir wollen 2 Partitionen erstellen,

  • eine EFI-Partition zum Booten,
  • und eine verschlüsselte root-Partition für das Archsystem.

Zunächst finden wir wieder die /dev/-Bezeichnungen der Laptopfestplatte heraus mittels

$ lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda             259:0    0 931,5G  0 disk 
sdb               8:0    1   7,4G  0 disk  
├─sdb1            8:1    1   917M  0 part  
└─sdb2            8:2    1    15M  0 part  

In diesem Beispiel ist sda die Festplatte des Laptops und sdb der Boot-Stick. Wir wollen also /dev/sda partitionieren.

Starte gdisk mittels

$ gdisk /dev/sda

Wir können mit p schauen, welche Partitionen schon auf der Platte sind. Meine Platte ist neu und leer, und daher gibt es nichts zu sehen. Möchtet ihr eine bereits gebrauchte Festplatte benutzen, könnt ihr die vorhandenen Partitionen mittels d löschen.

Wir erstellen eine neue Partition mittels n.

  • die erste Partition wird unsere Boot-Partition.
  • die voreingestellte Partitionsnummer 1 ist korrekt, so dass wir einfach ENTER drücken können.
  • ebenfalls korrekt ist der erste Sektor. Auch diesen können wir mittels ENTER bestätigen.
  • beim “letzten Sektor” geben wir +512M ein, damit die Partition 512 MB groß wird.
  • der Partitionscode im Hexformat lautet: ef00 (EFI-Partition)

Wir erstellen eine weitere Partition mittels n.

  • diese zweite Partition soll die verschlüsselte Systempartition werden.
  • die voreingestellte Partitionsnummer 2 ist korrekt, so dass wir einfach ENTER drücken können.
  • ebenfalls korrekt ist der erste Sektor. Auch diesen können wir mittels ENTER bestätigen
  • und auch der letzte Sektor ist korrekt, weil wir den gesamten Rest der Festplatte verwenden möchten. Wir können also einfach ENTER drücken können.
  • der Partitionscode im Hexformat lautet: 8309 (LUKS-Partition)

Wir können mittels p überprüfen, ob alles richtig ist.

Zum Schluss schreiben wir die Partitionstabelle mittels w.

Verschlüsselung

Um sicher zu sein, dass alles klappen wird, laden wir die Encryption-Module

$ modprobe dm-crypt
$ modprobe dm-mod

Nun erstellen wir ein LUKS-LVM auf der root-Partition (/dev/sda2):

$ cryptsetup luksFormat -v -s 512 -h sha512 /dev/sda2

Hier geben wir unser gewünschtes Passwort ein und merken es uns!!!. Wenn ihr das Passwort vergesst, kommt ihr nicht mehr an eure Daten!!!

Jetzt können wir das Laufwerk mounten

$ cryptsetup open /dev/sda2 luks_lvm

(hier muss das Passwort eingegeben werden, welches wir soeben für die Partition erzeugt haben)

Volume Setup

Zunächst erstellen wir ein Volume und eine Volume-Gruppe

$ pvcreate /dev/mapper/luks_lvm
$ vgcreate arch /dev/mapper/luks_lvm

Wir benötigen auch ein SWAP-Volume. Als Faustregel gilt: RAM-Größe plus 2GB. Mein Laptop hat zB 8GB RAM, daher erstellen wir 10GB Swap mittels

$ lvcreate -n swap -L 10G arch

Den Rest der Platte verwenden wir für unser Arch-System

$ lvcreate -n root -l +100%FREE arch

Filesystems

Nun müssen die Partitionen formatiert werden.

Die EFI-Partition benötigt das Format FAT32:

$ mkfs.fat -F32 /dev/sda1 

Für die verschlüsselte root-Partition können wir z.B. btrfs oder ext4 verwenden. Ich persönlich begnüge mich mit ext4.

$ mkfs.btrfs -L root /dev/mapper/arch-root
# oder
$ mkfs.ext4 -L root /dev/mapper/arch-root

Nun formatieren wir noch unseren Swap:

$ mkswap /dev/mapper/arch-swap

Mounten

Zuerst mounten und aktivieren wir die SWAP-Partition

$ swapon /dev/mapper/arch-swap
$ swapon -a

Anschließend mounten wir die root-Partition nach /mnt:

$ mount /dev/mapper/arch-root /mnt

Unterhalb von /mnt erstellen wir das /boot-Verzeichnis:

mkdir -p /mnt/boot

Hierhin mounten wir die erzeugte boot Partiton (/dev/sda1)

$ mount /dev/sda1 /mnt/boot

Installiere ArchLinux

Nun ist es endlich an der Zeit gekommen, Archlinux zu installieren. Dieser Befehl bringt die essentiellen Pakete auf die neue Platte:

$ pacstrap -K /mnt base base-devel linux linux-firmware nano openssh

Wir erzeugen die fstab-Datei für unser neues System mittels:

$ genfstab -U -p /mnt > /mnt/etc/fstab

chroot in die Installation

Wir wechseln in unser neues System mittels:

$ arch-chroot /mnt /bin/bash

Hier können wir nun die grundlegenden Konfigurationen vornehmen.

Konfiguration

entschlüssele die Laufwerke

Damit Linux unsere Partition entschlüsseln kann, müssen wir die Datei mkinitcpio.conf anpassen.

Öffne mkinitcpio.conf

$ nano /etc/mkinitcpio.conf

und füge encrypt lvm2 zwischen die Hooks block und filesystem ein. Das sieht dann in etwa so aus:

HOOKS=(... block encrypt lvm2 filesystems fsck)

Wir müssen gleich noch weitere Änderungen an der Datei vornehmen, aber zunächst installieren wir den Volumemanager lvm2

$ pacman -S lvm2

Bootloader

Wir werden systemd-boot für unser System nutzen. Dafür benötigen wir noch ein paar Pakete:

$ pacman -S efibootmgr dosfstools gptfdisk

Zuerst installieren wir den EFI-Booteintrag per:

$ bootctl install

Jetzt müssen wir die UUID unserer verschlüsselten LUKS-Partition herausfinden. Da wir Partition /dev/sda2 verschlüsselt haben, erhalten wir dessen UUID per:

$ blkid /dev/sda2

Das sieht dann in etwa so aus:

/dev/sda2: UUID="272b13c4-ce78-47de-b04c-66210edb977d" TYPE="crypto_LUKS" PARTLABEL="Linux LUKS" PARTUUID="6b6b86e4-b8fe-4b7d-874d-96c67075b90c"

Die UUID lautet in unserem Beispiel also 272b13c4-ce78-47de-b04c-66210edb977d.

Mit diesem Wissen können wir die Datei /boot/loader/entries/arch-uefi.conf mit folgendem Inhalt erstellen:

$ nano /boot/loader/entries/arch-uefi.conf
title    Arch Linux
linux    /vmlinuz-linux
initrd   /initramfs-linux.img
options  root=/dev/mapper/arch-root cryptdevice=UUID=<uuid>:luks_lvm  locale=de_DE.UTF-8

In unserem Beispiel ändert sich die letzte Zeile in

options  root=/dev/mapper/arch-root cryptdevice=UUID=272b13c4-ce78-47de-b04c-66210edb977d:luks_lvm  locale=de_DE.UTF-8

Nun bearbeiten wir die Datei /boot/loader/loader.conf so, dass automatisch in unser Archsystem gebootet wird:

$ nano /boot/loader/loader.conf
default   arch-uefi
timeout   1

Keyfile

Optional können wir noch Keyfiles erstellen. Hierfür erzeugen wir ein eigenes Verzeichnis:

$ mkdir /secure

…und erstelle ein Keyfile für unserer root-Partition.

$ dd if=/dev/random of=/secure/root_keyfile.bin bs=512 count=8

Anschließend muss die Berechtigung geändert werden:

$ chmod 000 /secure/*

Jetzt können wir den Keyfile der Partition zuweisen:

$ cryptsetup luksAddKey /dev/sda2 /secure/root_keyfile.bin

(hier muss wieder das Passwort eingegeben werden, welches wir für die Partition erzeugt haben)

Den Schlüssel müssen wir noch für Linux bekanntmachen:

$ nano /etc/mkinitcpio.conf

Unter FILES fügen wir den Pfad auf den Keyfile hinzu:

FILES=(/secure/root_keyfile.bin)

…und erstellen Linux neu:

$ mkinitcpio -p linux

Systemkonfiguration

Zeit für ein paar weitere Systemkonfigurationen.

Timezone

Unsere Zeitzone ist Europe/Berlin.

$ ln -sf /usr/share/zoneinfo/Europe/Berlin /etc/localtime

NTP

Mittels NTP holen wir uns die aktuelle Zeit aus dem Netz

$ nano /etc/systemd/timesyncd.conf

Folgende NTP Server können wir verwenden.

[Time]
NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org 
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org

Jetzt kann NTP aktiviert werden

$ systemctl enable systemd-timesyncd.service

Locale

Wir stellen die Sprache auf “deutsch”. Hierfür öffnen wir /etc/locale.gen

$ nano /etc/locale.gen

und kommentieren die Zeile mit de_DE.utf8 aus.

#de_CH ISO-8859-1
de_DE.UTF-8 UTF-8
#de_DE ISO-8859-1
#de_DE@euro ISO-8859-15

Jetzt erzeugen wir alle lokalen Sprachdateien

$ locale-gen

…und schreiben es auch noch in /etc/locale.conf

$ nano /etc/locale.conf
LANG=de_DE.UTF-8

virtuelle und TTY Konsolen

Damit auch die virtuellen Tastaturen auf deutsch eingestellt sind, gebe ich noch ein:

$ echo KEYMAP=de-latin1-nodeadkeys > /etc/vconsole.conf
$ localectl --no-convert set-x11-keymap de pc105 deadgraveacute
$ localectl --no-convert set-keymap de-latin1-nodeadkeys

Wir können die Einstellungen noch überprüfen mit

$ localectl status

Die Ausgabe sollte so aussehen:

System Locale: LANG=de_DE.UTF-8
    VC Keymap: de-latin1-nodeadkeys
   X11 Layout: de
    X11 Model: pc105
  X11 Variant: deadgraveacute

Beim nächsten Neustart ist das Tastaturlayout auch für TTY auf deutsch.

Hostname

Mein Laptop soll “Norbert” heissen.

$ echo "Norbert" > /etc/hostname

Users

Bislang waren wir als root unterwegs. Erzeugen wir uns also einen neuen Benutzer “produnis” mit sudo-Rechten

$ useradd -m -G wheel -s /bin/bash produnis

und vergeben ein Passwort für diesen User mittels

$ passwd produnis

Damit “produnis” sudo-Rechte bekommt, führen wir folgenden Befehl aus

$ EDITOR=nano visudo

und kommentieren die folgende Zeile aus:

%wheel ALL=(ALL:ALL) ALL

Damit unsere sudo-Befehle nicht aus-timen, kann am Ende der Datei noch hinzugefügt werden:

Defaults passwd_timeout=0

Netzwerk

Damit wir beim Neustart Netzwerk haben, installieren und aktivieren wir den Networkmanager.

$ pacman -S networkmanager
$ systemctl enable NetworkManager

Damit auch ssh funktioniert, ergänzen wir

$ systemctl enable sshd

Microcode

Es wird empfohlen, die Micorcodes entsprechend eurer CPU zu installieren.

# Für AMD
$ pacman -S amd-ucode
# ODER
# Für Intel
$ pacman -S intel-ucode

Desktop

An dieser Stelle sind wir eigentlich schon fertig und können zum ersten Mal neustarten. Ich installiere aber noch einen Desktop und Login-Manager, damit ich direkt auf einer graphischen Oberfläche loslegen kann. Ich selbst verwende am liebsten KDE (also Plasma) mit Wayland (ihr könnt aber auch GNOME oder XFCE installieren). Für eine minimale Installation wähle ich

$ pacman -S plasma-desktop plasma-wayland-session  kde-applications  sddm sddm-kcm plasma-nm

Ich bestätige immmer die Vorauswahl, falls Pacman fragt.

Zum Schluss aktiviere ich noch den Loginmanager sddm

$ systemctl enable sddm

Fertig, Zeit für einen Reboot.

Reboot

Zunächst verlassen wir die chroot-Umgebung und unmounten die Partitionen.

$ exit
$ umount -R /mnt
$ reboot now

Bei mir meldet sich nach dem Start nun das UEFI-Bootmenu, welches nach 2 Sekunden Archlinux bootet. Hier werde ich nach dem Verschlüsslungspasswort gefragt. Anschließend meldet sich der sddm-Loginbildschirm, und ich kann meine Plasmasession starten.

Deutsches Tastaturlayout

Noch ist die KDE-Tastatur nicht auf deutsch eingestellt. Hierfür geht ihr in die Systemeinstellungen, und wählt unter “Tastaur” den Reiter “Belegungen”.

Setzt den Haken bei “Belegungen einrichten” und fügt “Deutsch” hinzu. Sobald ihr unten auf “Anwenden” klickt, ist die Tastatur auf deutsches Layout eingestellt.

…what if?

Falls doch etwas schief laufen sollte, und ihr z.B. nicht ins System booten könnt, stellt ihr wie folgt wieder die chroot-Umgebung her:

  • boote vom USB-Stick, so wie oben beschrieben
  • cryptsetup open /dev/sda2 luks_lvm
  • mount /dev/mapper/arch-root /mnt
  • mount /dev/sda1 /mnt/boot
  • arch-chroot /mnt /bin/bash

Jetzt liegt es aber an euch, den Fehler zu finden… ;)

Weblinks


Diskussion per Matrix unter https://matrix.to/#/#produnis-blog:tchncs.de

 

8. Februar 2024

Mozilla hat heute einen Wechsel auf der CEO-Position der Mozilla Corporation bekannt gegeben. Demnach wird Laura Chambers für Mitchell Baker übernehmen.

Mozilla besetzt die höchste Position der Mozilla Corporation, welche unter anderem für die Entwicklung von Firefox verantwortlich ist, neu. Laura Chambers, die bereits seit drei Jahren Mitglied im Verwaltungsrat der Mozilla Corporation sitzt, ist ab sofort und zunächst bis zum Ende des Jahres neuer CEO der Mozilla Corporation. Chambers hatte bereits Führungspositionen bei eBay, PayPal, Skype und AirBnb, zuletzt war sie CEO von Willow Innovations.

Mitchell Baker, bereits seit 25 Jahren bei Mozilla und seit 2020 in der Rolle des CEO, wird wieder in die Rolle des Executive Chairwoman zurückkehren und ihren Fokus verstärkt auf die Repräsentation von Mozilla als Ganzes und in der Öffentlichkeit legen. Schwerpunkte dabei sind Politik, Open Source und Community. Die Öffentlichkeitsarbeit schließt Vorträge und direkten Kontakt mit der Community ein.

Als die zwei Hauptziele von Laura Chambers werden zum einen die Verfeinerung der Unternehmensvision und Ausrichtung der Unternehmens- und Produktstrategie auf diese Vision genannt. Zum anderen sollen die Bemühungen bei den Kernprodukten wie Firefox verstärkt und neue Produkte auf den Markt gebracht werden.

Der Beitrag Laura Chambers ersetzt Mitchell Baker als CEO der Mozilla Corporation erschien zuerst auf soeren-hentzschel.at.

New Tab Override ist eine Erweiterung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Die beliebte Erweiterung ist nun in Version 16.0 erschienen.

Was ist New Tab Override?

Die Erweiterung New Tab Override erlaubt das Überschreiben der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Dies kann eine beliebige Website, immer automatisch die aktuelle Startseite, eine lokale Datei, eine Hintergrundfarbe oder die neuesten Nachrichten von diesem Blog sein.

New Tab Override war das erste Add-on, welches das Überschreiben des neuen Tabs ermöglichte, und ist damit das Original und auch heute noch die meistgenutzte Erweiterung dieser Art. New Tab Override wurde im Dezember 2016 auf dem offiziellen Mozilla-Blog vorgestellt, schon mehrfach im Add-on Manager von Firefox beworben und gehört außerdem zu Mozillas handverlesener Auswahl empfohlener Erweiterungen.

Download New Tab Override für Firefox

Die Neuerungen von New Tab Override 16.0

Eine wichtige Änderung betrifft New Tab Override unter der Haube: Die Erweiterung nutzt jetzt das Manifest v3. Während diese Anpassung für den Nutzer nichts ändert, gewährleistet dies die langfristige Kompatibilität von New Tab Override mit Firefox. Dafür ist New Tab Override nicht länger mit Firefox ab Version 78 kompatibel, sondern erfordert in Zukunft Firefox 115 oder höher.

Neben URLs, die mit https:// oder http:// beginnen, können ab sofort auch URLs als Seite für den neuen Tab eingetragen werden, die mit moz-extension:// beginnen, also Seiten anderer Erweiterungen sind.

Wird ein nicht unterstütztes Protokoll angegeben, zeigt New Tab Override nun eine Fehlermeldung anstatt einfach http:// voranzustellen. Wird kein Protokoll durch den Nutzer angegeben, ergänzt New Tab Override jetzt https:// anstelle von http://.

Bei Verwendung eines dunklen Themes flackert der Hintergrund nicht länger für einen ganz kurzen Moment in weißer Farbe, sondern verwendet einen dunklen Hintergrund.

Wird die Option verwendet, eine farbige Fläche als neuen Tab anzuzeigen, wird dabei eine leere Adressleiste angezeigt.

Für eine verbesserte Barrierefreiheit wurden die Farben der Einstellungsseite sowohl im hellen als auch dunklen Theme überarbeitet.

Mit Indonesisch steht eine komplett neue Sprache zur Verfügung. Damit ist New Tab Override jetzt in insgesamt 15 Sprachen übersetzt.

Dazu kam noch eine ganze Reihe kleinerer Verbesserungen unter der Haube, welche Altlasten entfernen und den Code modernisieren.

Der Beitrag New Tab Override 16.0 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

hinweis
Der Pull Request wurde vor ein paar Tagen angenommen und www.linuxatemyram.com somit aktualisiert.

Zumindest bis auf Weiteres. Wenn es um die Speicherverwaltung von Linux geht bzw. darum wie viel Speicher tatsächlich belegt bzw. frei ist, wird gerne auf www.linuxatemyram.com verwiesen. Immer mehr Nutzer raten von dieser Quelle allerdings ab, weil die dort genannten Informationen teilweise veraltet, ungenau bzw. falsch sind. Und das seit Jahren.

Ein Nutzer hat sich im April letzten Jahres die Mühe gemacht und einen Pull Request mit 12 Commits erstellt, um die Internetseite an die aktuellen Gegebenheiten anzupassen.

So wie es aussieht hat die betreffende Seite für den Betreiber, welcher übrigens auch für das von mir geschätzte Tool shellcheck verantwortlich ist, allerdings keine allzu hohe Priorität. Zumindest ist bisher weder eine Reaktion auf den Pull Request erfolgt noch wurde dieser angenommen oder abgelehnt. Vielleicht wäre es daher sinnvoller die Seite einfach zu deaktivieren. Zumal .com Domains ja auch nicht zu den billigsten Domains gehören.

7. Februar 2024

Mozilla hat seinem Dienst Firefox Monitor wie erwartet einen neuen Anstrich verpasst und diesen in Mozilla Monitor umbenannt. In den USA ist außerdem das kostenpflichtige Premium-Angebot Mozilla Monitor Plus gestartet.

Bereits im April 2023 hatte ich exklusiv darüber berichtet, dass Mozilla an einer Premium-Version von Firefox Monitor arbeitet, und seit dem mehrfach über neue Informationen berichtet, zuletzt im Januar über den bevorstehenden Relaunch am 6. Februar.

Relaunch von Mozilla Monitor

Mozillas kostenfreier Dienst Mozilla Monitor zeigt nach Eingabe einer E-Mail-Adresse an, ob diese Teil eines bekannten Datendiebstahls in der Vergangenheit war. Neben dem Zeitpunkt des Diebstahls und dem Zeitpunkt des Bekanntwerdens wird auch angegeben, welche Daten gestohlen worden sind, zum Beispiel E-Mail-Adressen, Benutzernamen oder Passwörter. Darüber hinaus nennt Mozilla Monitor allgemeine Tipps, welche man in Betracht ziehen sollte, wenn man von einem Datendiebstahl betroffen ist.

Der bisher als Firefox Monitor bekannte Dienst, der nach Angaben von Mozilla über zehn Millionen angemeldete Nutzer hat, ist ab sofort unter dem neuen Namen Mozilla Monitor und mit neuer Website online.

Mozilla Monitor Plus in den USA

Für Nutzer in den USA ist außerdem Mozilla Monitor Plus an den Start gegangen. Damit können persönliche Informationen von über 190 Personen-Suchmaschinen entfernt werden – einer laut Mozilla 240 Milliarden Dollar schweren Industrie, welche mit der Bildung von Profilen und dem Verkauf dieser Daten Profit generiert.

Nutzer der kostenlosen Version von Mozilla Monitor können ihre Daten einmalig überprüfen lassen. Für Nutzer von Mozilla Monitor Plus erfolgt eine monatliche Überprüfung – immerhin könnten diese Seiten ja jederzeit wieder neue Informationen hinzufügen. Außerdem kann Mozilla Monitor Plus automatisch die Entfernung von diesen Seiten in die Wege leiten, während Nutzer der kostenlosen Version beim einmaligen Check zwar gesagt bekommen, wo ihre Daten zu finden sind, die Entfernung aber manuell bei den jeweiligen Websites beantragen müssen.

Mozilla Monitor Plus kostet 13,99 USD pro Monat bei nur einem Monat Vertragsbindung. Wer sich direkt für ein ganzes Jahr bindet, spart 35 Prozent und zahlt nur 8,99 USD pro Monat.

Da Mozilla für das neue Feature auf die Dienste von OneRep setzt, welche ausschließlich in den USA aktiv sind, ist mit keiner zeitnahen Ausrollung in weiteren Ländern zu rechnen – sofern OneRep selbst keine Expansions-Pläne verfolgt. Sollte der Dienst in den USA gut angenommen werden, ist natürlich nicht auszuschließen, dass sich Mozilla mittelfristig nach vergleichbaren Lösungen auch für andere Länder umsehen wird.

Der Beitrag Relaunch von Mozilla Monitor, Premium-Angebot in den USA gestartet erschien zuerst auf soeren-hentzschel.at.

Die Distro wurde vor einem Jahr angekündigt, im August gab es die Entwicklervorschau und nun steht die Beta-Version zum Testen bereit.

Orchid ist eine komplette Neufassung des Projekts Vanilla OS mit dem Ziel, ein stabiles, sicheres, schnelles und benutzerfreundliches Betriebssystem ohne Kompromisse zu bieten. Das Projekt von Grund auf neu bewertet, wobei das umfangreiche Feedback, welches mit der ersten Version eingegangen ist, berücksichtigt.

Alles zu beschreiben, was sich in Vanilla OS 2 Orchid geändert hat, ist in einem Artikel kaum möglich, denn auch wenn es auf den ersten Blick ähnlich aussieht wie die erste Version, ist es unter der Haube eine völlig neue Welt mit neuen Technologien, Konzepten und Standards.

Daher beschränke ich mich auf eine Kurzfassung der Neuerungen. Viel mehr Details findet ihr in diesem Blog-Beitrag des Entwicklerteams zur Beta Version.

Es gibt ein neues Hintergrundbild in heller und dunkler Version, dass das Thema der Orchidee wiedergibt (siehe Titelbild). Die Version 2 verabschiedet sich von Ubuntu als Basis und setzt nun auf Debian auf. Dabei kommen Debian Pakete und Vib Container Images zum Einsatz. Bei den Updates wurde von einer paketbasierten Struktur auf eine OCI-Image basierte Struktur gewechselt.

Auch die A/B-Partitionierung wurde weiterentwickelt. Die Version 2 von ABRoot soll zuverlässiger und schneller arbeiten. Die Transaktionen erfolgen nun über die OCI-Image-Erweiterung, anstatt über die Anwendung von Paket-Updates, wodurch sichergestellt wird, dass das System eine exakte Kopie des getesteten Images erhält. In ABRoot v1 konnten Benutzer auf die transaktionale Shell zugreifen, um atomare Systemänderungen vorzunehmen. In ABRoot v2 wurde diese Funktion entfernt und durch die Unterstützung für die Erstellung benutzerdefinierter lokaler Images ersetzt. Wenn etwa ein Treiber installiert wird, der nicht im System vorhanden ist, kann ABRoot ein benutzerdefiniertes Abbild mit dem installierten Treiber erzeugen.

Um einen der Hauptkritikpunkte von Vanilla OS 22.10 zu beseitigen, nämlich den zugewiesenen Speicherplatz für die beiden Root-Partitionen, die insgesamt 20 GB für Root ausmachen und 40 GB Festplattenplatz beanspruchen, wurde Unterstützung für LVM Thin Provisioning eingeführt. Diese Technologie ermöglicht die Erstellung von logischen Volumes mit variabler Grösse und optimiert so die Nutzung des Festplattenplatzes. Jetzt teilen sich die beiden Root-Partitionen insgesamt 20 GB, die dynamisch auf der Grundlage der Grösse der beiden Partitionen zugewiesen werden, wodurch mehr Speicherplatz für Benutzerdaten zur Verfügung steht.

In Vanilla OS 2 Orchid wurde sudo durch PolKit-Richtlinien ersetzt, die es den Benutzern ermöglichen, privilegierte Operationen auf eine kontrolliertere und sicherere Weise durchzuführen. Der Benutzer hat weiterhin Zugriff auf sudo, aber nur innerhalb des VSO-Subsystems (Vanilla System Operator).

Benutzer haben nun keinen direkten Zugriff mehr auf die System-Shell; wenn sie die Konsole öffnen, gelangen sie in die VSO-Shell, ein integriertes und veränderbares Subsystem von Vanilla OS. Es ermöglicht den Nutzern, Anwendungen wie in jeder Linux-Distribution zu installieren und auszuführen, ohne das System zu beeinträchtigen. Ausserdem unterstützt VSO jetzt Android-Anwendungen, die als native Anwendungen installiert und ausgeführt werden können, ohne dass ein Emulator erforderlich ist. Zudem wurde F-Droid als Paketquelle integriert. Nutzer können .deb- und .apk-Pakete installieren, indem sie sie einfach mit der Sideloading-Anwendung öffnen, die die Installation in das richtige Subsystem übernimmt.

Apx v2 spielt jetzt eine völlig neue Rolle, indem es als leistungsstarkes Werkzeug für Entwickler und Kreative dient. Es ermöglicht die Erstellung von benutzerdefinierten Umgebungen (Stacks) für verschiedene Bedürfnisse. Benutzer können etwa einen Stack auf Basis von Arch Linux erstellen, yay als Paketmanager anstelle von pacman definieren und Pakete von AUR ohne Probleme installieren.

FsGuard ist das Tool, das während des Systemstarts die Integrität der System-Binärdateien prüft, um sicherzustellen, dass keine Diskrepanzen mit dem vom System-Image bereitgestellten Zustand bestehen. Wird eine Änderung festgestellt, startet FsGuard FsWarn, das den Systemstart unterbricht, den Benutzer über das Problem informiert und ihm rät, das System im vorherigen Zustand neu zu starten, um die Integrität des Systems zu gewährleisten.

Das Installer-Backend wurde von DistInst zu Albius gewechselt, weil dieser die Systeminstallation von OCI-Images unterstützt. Dem Vanilla-Installer wurden einige überarbeitete Fenster spendiert:

Sobald das System installiert ist, fragt das First Setup nicht nur nach den zu installierenden Anwendungen, sondern ermöglicht dem Benutzer auch die Konfiguration von Benutzername, Gerätename, Zeitzone, Sprache, Tastatur und Netzwerk.

Nach Abschluss der Ersteinrichtung wird der Benutzer von einer neuen Anwendung auf eine Systemtour mitgenommen, die die wichtigsten Funktionen des Systems vorstellt und so die erste Begegnung mit Vanilla OS einfacher und verständlicher macht.

Wie geht es weiter?

Orchid befindet sich derzeit in einem Feature Freeze, und das Team arbeitet an der Behebung kleinerer und während des Testzeitraums gemeldeter Fehler. Die stabile Version wird veröffentlicht, sobald alle gemeldeten Fehler behoben sind, optimistischerweise noch in diesem Sommer.

Wer beim Testen mitmachen möchte, findet die Beta-Version zum Downloaden auf dieser Seite. Dabei hilft auch die aktualisierte und zusammengeführte Dokumentation, die allerdings noch nicht vollständig ist.

Quelle: https://vanillaos.org/blog/article/2024-01-30/vanilla-os-2-orchid-beta-is-here


GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

6. Februar 2024

Mozilla hat Firefox 122.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion.

Download Mozilla Firefox 122.0.1

Mit dem Update auf Firefox 122.0.1 behebt Mozilla das Problem, dass bei Benachrichtigungen unter Windows trotz Klicken auf die Schaltfläche zum Ausblenden die mit der Benachrichtigung verknüpfte Website geöffnet worden ist.

Für Linux-Nutzer mit dem Yaru Remix Theme sowie für Nutzer älterer Ubuntu-Versionen wurden nicht die korrekten Farben verwendet.

Das Kontextmenü für Tab-Umgebungen in der Bibliothek sowie in der Sidebar zeigte nur die Icons und nicht die Namen der jeweiligen Umgebungen.

Mit Firefox 122 hatte Mozilla die Tastatur-Steuerung des Regeln-Panels im Inspektor-Werkzeug überarbeitet. Diese Änderung hat Mozilla aufgrund von Nutzer-Feedback wieder rückgängig gemacht. Wer das geänderte Verhalten bevorzugt hat, kann dieses über about:config wieder aktivieren, indem der Schalter devtools.inspector.rule-view.focusNextOnEnter auf false gesetzt wird. Ab Firefox 124 wird es dafür eine sichtbare Option in den Einstellungen der Entwicklerwerkzeuge geben.

Beim Kopieren von CSS aus dem Inspektor wurde fälschlicherweise die öffnende Klammer in einer neuen Zeile angezeigt.

Ein Webkompatibilitätsproblem wurde behoben, bei dem das Einfügen einer Importmap verursachen konnte, dass darauffolgende Module nicht geladen werden konnten. Ein weiteres Webkompatibilitätsproblem betrifft eine in Firefox 122 durchgeführte Änderung bezüglich externer Protokoll-Handler, welche korrekt gemäß Spezifikation war, in der Praxis aber Probleme verursacht hat und mit Firefox 122.0.1 rückgängig gemacht worden ist.

Eine mögliche Absturzursache beim CSS-Rendering wurde behoben, ebenso ein Rundungs-Problem bei der Berechnung der Scroll-Position. Außerdem wurde eine hohe CPU-Auslastung auf Websites korrigiert, welche Animationen und einen ResizeObserver verwenden.

Darüber hinaus gab es noch Verbesserungen in Zusammenhang mit der Funktion, über das Firefox-Menü Kompatibilitätsprobleme mit Websites an webcompat.com zu melden, welche derzeit experimentell für einen Teil der Nutzer aktiviert ist.

Der Beitrag Mozilla veröffentlicht Firefox 122.0.1 erschien zuerst auf soeren-hentzschel.at.

5. Februar 2024

Bereits letzte Woche hat die UBports Foundation die Verfügbarkeit von Ubuntu Touch OTA-4 angekündigt. Das Update verbessert die Systemeinstellungs-App sowie die Unterstützung für Google-Dienste.

Das vierte "Over The Air" Update von Ubuntu Touch basiert nach wie vor auf der LTS Version 20.04 von Ubuntu. Zu den wesentlichen Neuerungen gehören:

  • Die Möglichkeit, den Inhalt von Benachrichtigungen auszublenden, wenn das Smartphone gesperrt ist.
  • Eine Schätzung der Ladezeit auf dem Sperrbildschirm.
  • Die Möglichkeit, einem bestimmten Kontakt einen Klingelton zuzuweisen.

Ausserdem gibt es einen neuen Kippschalter in den Systemeinstellungen, mit dem man das Design ändern kann, ohne eine zusätzliche App zu verwenden. Ferner behebt OTA-4 die Möglichkeit für Apps, benutzerdefinierte Vibrationsmuster festzulegen, verbessert die Zuverlässigkeit von Bluetooth-Headsets für Sprachanrufe und lässt die Double-Tap-to-Wake-Einstellung, sodass sie einen Neustart übersteht.  Auch die Kameraunterstützung für Waydroid-Benutzer wurde verbessert und die Barcode-Reader-App aktualisiert, sodass die Warnung "Geringer Speicherplatz" nicht mehr angezeigt wird.

Überdies behebt es die "Anmeldung bei Google" für bestimmte Webseiten und die Unterstützung für ähnliche Funktionen auf Websites, die Pop-ups erfordern. Die mobile Datenkonnektivität wurde verbessert, um sofort nach dem Beenden eines Telefonanrufs wieder aktiviert zu werden, und die Systemeinstellungs-App erhielt mehrere Verbesserungen für das Layout einiger Seiten. Benutzerdefinierte Hintergrundbilder können jetzt auch gelöscht werden und die Empfindlichkeit der Randgesten kann man nun anpassen.

Zu guter Letzt können Benutzer mit dem Ubuntu Touch OTA-4 Software-Update endlich die physische Kamerataste auf ihren Geräten verwenden, um ein Foto aufzunehmen, und Anwendungsentwickler sehen jetzt eine Bestätigung, wenn sie ihr Gerät mit einem neuen Computer verbinden. Verschiedene Sicherheits- und Fehlerkorrekturen sind ebenfalls in dieser Version enthalten.

Ubuntu Touch OTA-4 wird jetzt auf alle unterstützten Geräte ausgerollt, einschliesslich:

  • Asus Zenfone Max Pro M1
  • Pro1-X
  • Fairphone 3
  • Fairphone 3+
  • Fairphone 4
  • Google Pixel 3a
  • Google Pixel 3a XL
  • JingPad A1
  • OnePlus 5
  • OnePlus 5T
  • OnePlus 6
  • OnePlus 6T
  • PinePhone
  • PinePhone Pro
  • PineTab
  • PineTab2
  • Sony Xperia X
  • Vollaphone
  • Vollaphone X
  • Vollaphone 22
  • Vollaphone X23
  • Xiaomi Poco M2 Pro
  • Xiaomi Poco X3 NFC / X3
  • Xiaomi Redmi Note 9
  • Xiaomi Redmi Note 9 Pro
  • Xiaomi Redmi Note 9 Pro Max
  • Xiaomi Redmi Note 9S

Alle weiteren Änderungen finden sich in den Release Notes für OTA-4:

Quelle: https://ubports.com/en/blog/ubports-news-1/post/ubuntu-touch-ota-4-focal-3912


GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.

3. Februar 2024

Wenn man im Internet nach Lösungen für Probleme mit LibreOffice & Co. bei wissenschaftlichen Arbeiten sucht, kommt meist sehr schnell der Hinweis, dass man gar nicht mit dem richtigen Werkzeug unterwegs ist, sondern eigentlich LaTeX viel besser wäre. Frei nach dem Motto: Alles andere sind Amateure. Aber ist das immer so? Oder war es jemals so? Nein. LaTeX ist eine gute Option, aber es legt einem auch Steine in den Weg. Jedes mögliche Werkzeug hat seine Stärken und Schwächen.

Ich beschäftige mich viel mit LibreOffice & Co. und werde oft gefragt, warum mich die Entwicklungen bzw. Nicht-Entwicklungen in diesem Bereich so interessieren. Das liegt daran, dass Office für mich immer noch ein zentrales Werkzeug ist. Das ist wohl eine Generationenfrage. Textverarbeitung, Präsentation, Tabellenkalkulation. Das sind Programme, die ich täglich brauche, und vor allem die Textverarbeitung ist das, was ich wirklich ausreize. Umfangreiche Formatvorlagen, Verzeichnisse, Fuß- und Endnoten, Register usw.. Meine Doktorarbeit zum Beispiel habe ich in einem einzigen Dokument geschrieben. Hunderte von Seiten, Tausende von Fußnoten, viel zu viele Jahre. Immer mit dem leisen Zweifel im Hinterkopf, ob LaTeX nicht doch die bessere Lösung gewesen wäre.

Und diese Zweifel sind keineswegs ein Produkt der Vergangenheit, sondern ich habe immer wieder mit Studierenden zu tun, die fragen, ob sie nicht LaTeX lernen sollten. Irgendjemand kennt immer jemanden, der gelesen oder gehört hat, dass LaTeX die einzige adäquate Methode für längere Texte sei. Das Gerücht ist irgendwie nicht tot zu kriegen. Daher hier noch mal deutlich: Dem ist nicht so!

Richtig ist, dass LaTeX-Dokumente in der Regel ein besseres Schriftbild und einen besseren Satz haben. Eine Textverarbeitung ist eben kein Satzprogramm. Wer also nur am Ende auf Drucken klicken will, bekommt mit LaTeX das schönere Ergebnis. Die steile Lernkurve verhindert daneben auch schlechte Ergebnisse, weil es dann meist gar keine gibt. Auch bei den Formeln hatte LaTeX lange Zeit die Nase vorn, aber viele Textverarbeitungen haben hier nachgebessert, um den Autoren das Leben leichter zu machen. Ein entscheidender Vorteil ist die Formatstabilität über sehr lange Zeiträume. Aber auch Textverarbeitung ist nicht so schlecht wie ihr Ruf und ich kann problemlos 15 Jahre alte Dokumente ohne sichtbare Abweichungen öffnen. Eine Garantie habe ich bei proprietären Formaten hier natürlich nicht. Mal ganz unabhängig von der Frage, ob dieses Anwendungsszenario überhaupt notwendig ist.

Unbestritten ist auch, dass man mit LaTeX sehr gut längere Arbeiten schreiben kann. Das kann man auch mit Markdown und im Prinzip sogar mit einem normalen Editor. Wobei es da mit den Fußnoten und Endnoten schwierig wird. Generationen von Wissenschaftlerinnen und Wissenschaftlern haben bahnbrechende Arbeiten mit Papier und Stift oder später mit der Schreibmaschine verfasst. Jeder kann und soll mit dem Werkzeug seiner Wahl arbeiten. Nur sind es irgendwie immer die LaTeX-Anwender, die ihr Werkzeug zum Maßstab erklären. Muss die steile Lernkurve mit Sendungsbewusstsein kompensiert werden? Ich weiß es nicht. Es ist aber auf jeden Fall falsch, denn bei einem der letzten Schritte im Wissenschaftskreislauf steht LaTeX seinen Anwendern massiv im Weg: Publizieren. Ausgerechnet LaTeX, das großartige Satzprogramm.

Jede wissenschaftliche Zeitschrift, die ich bisher gesehen habe und jeder Verlag für eine Buchpublikation nimmt oder verlangt gar eine Word-Datei. Auch moderne Open-Access-Zeitschriften mit OJS-Systemen wollen in der Regel Word-Dateien zur Weiterverarbeitung. Niemand besteht auf ein LaTeX-Dokument, manche nehmen solchen nicht mal an. Manchmal gibt es Vorlagen für Word, manchmal nur Satzhinweise und manchmal geht es wirklich nur um eine Rohtextdatei. Danach beginnt gegebenenfalls die Korrektur und das Lektorat, auf jeden Fall aber der Satz. Die Korrekturschleifen bis zur Fahnenkorrektur laufen in der Regel über Worddateien mit Änderungshistorie und Kommentaren in PDF-Dateien. Für die Worddateien kann in der Regel jedes Textverarbeitungsprogramm verwendet werden, da die Dateien ohnehin weiterverarbeitet werden. Open-Source-Nutzer sind hier jedenfalls nicht im Nachteil. Auch das muss mal geschrieben werden.

Denn kein Verlag druckt ein Manuskript so, wie es die Autoren abliefern. Jeder Verlag und manchmal sogar jede Zeitschrift hat ihr eigenes Design. Der Textsatz schafft Wiedererkennung. Kein Verlag, den ich kenne, macht den Textsatz mit LaTeX. Manchmal kann man es aus den Metadaten herauslesen, manchmal nicht. Oft wird Adobe InDesign verwendet, manchmal wird das Produkt in ein XML-Dokument umgesetzt oder in ein proprietäres Verlagsprodukt. Das Endprodukt ist längst nicht mehr nur das gedruckte Buch oder das E-Book als dessen digitaler Klon, sondern formatunabhängige Publikationen.

Wenn man also mit LaTeX schreiben möchte, weil es dem eigenen Arbeitsablauf besser entspricht, dann kann man das natürlich tun. Man sollte aber nicht dem Irrglauben verfallen, dass man sich das Leben im letzten Schritt des wissenschaftlichen Zyklus irgendwie leichter macht. Im Gegenteil: Wer mit LaTeX schreibt, hat am Ende mehr Konvertierungsschleifen als ein Autor, der ein normales Textverarbeitungsprogramm benutzt. Auf keinen Fall sollte man sich aber von irgendwelchen LaTeX-Nutzern einreden lassen, dass man LaTeX für eine wissenschaftliche oder auch nur längere Arbeit zwingend braucht. Das ist schlichtweg falsch.

Der Artikel Kein Verlag will ein LaTeX-Dokument erschien zuerst auf Curius

2. Februar 2024

Der neue Raspberry Pi 5 verfügt erstmals über eine PCIe-Schnittstelle. Leider hat man sich bei der Raspberry Pi Foundation nicht dazu aufraffen können, gleich auch einen Slot für eine PCIe-SSD vorzusehen. Gut möglich, dass es auch einfach an Platzgründen gescheitert ist. Oder wird dieser Slot das Kaufargument für den Raspberry Pi 6 sein? Egal.

Mittlerweile gibt es diverse Aufsteckplatinen für den Raspberry Pi, die den Anschluss einer PCIe-SSD ermöglichen. Sie unterscheiden sich darin, ob sie über oder unter der Hauptplatine des Raspberry Pis montiert werden, ob sie kompatibel zum Lüfter sind und in welchen Größen sie SSDs aufnehmen können. (Kleinere Aufsteckplatinen sind mit den langen 2280-er SSDs überfordert.)

NVMe Base von Pimoroni

Für diesen Artikel habe ich die NVMe Base der britischen Firma Pimoroni ausprobiert (Link). Inklusive Versand kostet das Teil ca. 24 €, der Zoll kommt gegebenenfalls hinzu. Die Platine wird mit einem winzigen Kabel und einer Menge Schrauben geliefert.

Die PCIe-Platine von Pimoroni mit einem Kabel und diversen Schrauben

Der Zusammenbau ist fummelig, aber nicht besonders schwierig. Auf YouTube gibt es eine ausgezeichnete Anleitung. Achten Sie darauf, dass Sie wirklich eine PCIe-SSD verwenden und nicht eine alte M2-SATA-SSD, die Sie vielleicht noch im Keller liegen haben!

Raspberry Pi 5 + Pimoroni PCIe-Platine mit SSD

Nachdem Sie alles zusammengeschraubt haben, starten Sie Ihren Raspberry Pi neu (immer noch von der SD-Karte). Vergewissern Sie sich mit lsblk im Terminal, dass die SSD erkannt wurde! Entscheidend ist, dass die Ausgabe eine oder mehrere Zeilen mit dem Devicenamen nmve0n1* enthält.

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0  29,7G  0 disk 
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0  29,2G  0 part 
nvme0n1     259:0    0 476,9G  0 disk 
Nach der Sandwich-Montage

Raspberry-Pi-OS klonen und von der SSD booten

Jetzt müssen Sie Ihre Raspberry-Pi-OS-Installation von der SD-Karte auf die SSD übertragen. Dazu starten Sie das Programm Zubehör/SD Card Copier, wählen als Datenquelle die SD-Karte und als Ziel die SSD aus.

Inhalt der SD-Karte auf die SSD übertragen

SD Card Copier kopiert das Dateisystem im laufenden Betrieb, was ein wenig heikel ist und im ungünstigen Fall zu Fehlern führen kann. Der Prozess dauert ein paar Minuten. Während dieser Zeit sollten Sie auf dem Raspberry Pi nicht arbeiten! Das Kopier-Tool passt die Größe der Partitionen und Dateisysteme automatisch an die Größe der SSD an.

Als letzten Schritt müssen Sie nun noch den Boot-Modus ändern, damit Ihr Raspberry Pi in Zukunft die SSD als Bootmedium verwendet, nicht mehr die SD-Karte. Dazu führen Sie im Terminal sudo raspi-config aus und wählen Advanced Options -> Boot Order -> NVMe/USB Boot.

Mit »raspi-config« stellen Sie den Boot-Modus um

Selbst wenn alles klappt, verläuft der nächste Boot-Vorgang enttäuschend. Der Raspberry Pi lässt sich mit der Erkennung der SSD so viel Zeit, dass die Zeit bis zum Erscheinen des Desktops sich nicht verkürzt, sondern im Gegenteil ein paar Sekunden verlängert (bei meinen Tests ca. 26 Sekunden, mit SD-Karte nur 20 Sekunden). Falls Sie sich unsicher sind, ob die SSD überhaupt verwendet wird, führen Sie noch einmal lsblk aus. Der Mountpoint / muss jetzt bei einem nvme-Device stehen:

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476,9G  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part /boot/firmware
└─nvme0n1p2 259:2    0 476,4G  0 part /

Wie viel die SSD an Geschwindigkeit bringt, merken Sie am ehesten beim Start großer Programme (Firefox, Chromium, Gimp, Mathematica usw.), der jetzt spürbar schneller erfolgt. Auch größere Update (sudo apt full-upgrade) gehen viel schneller vonstatten.

Benchmark-Tests

Ist die höhere Geschwindigkeit nur Einbildung, oder läuft der Raspberry Pi wirklich schneller? Diese Frage beantworten I/O-Benchmarktests. (I/O steht für Input/Output und bezeichnet den Transfer von Daten zu/von einem Datenträger.)

Ich habe den Pi Benchmark verwendet. Werfen Sie immer einen Blick in heruntergeladene Scripts, bevor Sie sie mit sudo ausführen!

wget https://raw.githubusercontent.com/TheRemote/ \
       PiBenchmarks/master/Storage.sh
less Storage.sh       
sudo bash Storage.sh
SSD-Benchmarktest

Ich habe den Test viermal ausgeführt:

  • Mit einer gewöhnlichen SD-Karte.
  • Mit einer SATA-SSD (Samsung 840) via USB3.
  • Mit einer PCIe-SSD (Hynix 512 GB PCIe Gen 3 HFS512GD9TNG-62A0A)
  • Mit einer PCIe-SSD (wie oben) plus PCIe Gen 3 (Details folgen gleich).

Die Unterschiede sind wirklich dramatisch:

Modell                 Pi 5 + SD     Pi 5 + USB    Pi 5 + PCIe     Pi 5 + PCIe 3
-----------------    -----------  -------------  -------------   ---------------
Disk Read                73 MB/s       184 MB/s       348 MB/s          378 MB/s
Cached Disk Read         85 MB/s       186 MB/s       358 MB/s          556 MB/s
Disk Write               14 MB/s       121 MB/s       146 MB/s          135 MB/s
4k random read         3550 IOPS     32926 IOPS    96.150 IOPS      173.559 IOPS
4k random write         918 IOPS     27270 IOPS    81.920 IOPS       83.934 IOPS
4k read               15112 KB/s     28559 KB/s   175.220 KB/s      227.388 KB/s
4k write               4070 KB/s     28032 KB/s   140.384 KB/s      172.500 KB/s   
4k random read        13213 KB/s     17153 KB/s    50.767 KB/s       54.682 KB/s
4k random write        2862 KB/s     27507 KB/s   160.041 KB/s      203.630 KB/s        
Score                       1385           9285         34.723            43.266

Beachten Sie aber, dass das synthetische Tests sind! Im realen Betrieb fühlt sich Ihr Raspberry Pi natürlich schneller an, aber keineswegs in dem Ausmaß, den die obigen Tests vermuten lassen.

PCIe Gen 3

Standardmäßig verwendet der Raspberry Pi PCI Gen 2. Mit dem Einbau von zwei Zeilen Code in /boot/firmware/config.txt können Sie den erheblich schnelleren Modus PCI Gen 3 aktivieren. (Der Tipp stammt vom PCIe-Experten Jeff Geerling.)

# in /boot/firmware/config.txt
dtparam=pciex1
dtparam=pciex1_gen=3

Die obigen Benchmarktests beweisen, dass die Einstellung tatsächlich einiges an Zusatz-Performance bringt. Ehrlicherweise muss ich sagen, dass Sie davon im normalen Betrieb aber wenig spüren.

Bleibt noch die Frage, ob die Einstellung gefährlich ist. Die Raspberry Pi Foundation muss ja einen Grund gehabt haben, warum sie PCI Gen 3 nicht standardmäßig aktiviert hat. Zumindest bei meinen Tests sind keine Probleme aufgetreten. Auch dmesg hat keine beunruhigenden Kernel-Messages geliefert.

Fazit

Es ist natürlich cool, den Raspberry Pi mit einer schnellen SSD zu verwenden. Für Bastelprojekte ist dies nicht notwendig, aber wenn Sie vor haben, Ihren Pi als Server, NAS etc. einzusetzen, beschleunigt die SSD I/O-Vorgänge enorm.

Schön wäre, wenn der Raspberry Pi in Zukunft einen PCIe-Slot erhält, um (zumindest kurze) SSDs ohne Zusatzplatine zu nutzen. Bis dahin sind die Erweiterungsplatinen eine Übergangslösung.

In der Community ist zuletzt die Frage aufgetaucht, ob der Raspberry Pi überhaupt noch preiswert ist. Diese Frage ist nicht unberechtigt: Die Kosten für einen neuen Pi 5 + Netzteil + Lüfter + SSD-Platine + SSD + Gehäuse gehen in Richtung 150 €. Sofern Sie ein Gehäuse finden, in dem der Pi samt SSD-Platine Platz findet … Um dieses Geld bekommen Sie auch schon komplette Mini-PCs (z.B. die Chuwi Larkbox X). Je nach Anwendung muss man fairerweise zugeben, dass ein derartiger Mini-PC tatsächlich ein besserer Deal ist.

Quellen/Links

Mitte Dezember 2023 hatte ich bekannt gegeben, dass ich die Kommentarfunktion deaktiviere. Seit dem habe ich einige, wenige Rückmeldungen über andere Kommunikationsmöglichkeiten erhalten. Inhaltlich haben sie mir nicht unbedingt zugestimmt, aber sie waren bisher alle neutral bis freundlich formuliert. Es geht also, wenn man will.

In einigen Fällen wurde ich gefragt, wie man mit mir in Kontakt treten kann, da die Kommentarfunktion nun deaktiviert ist. Na ja im Grunde eben wie diese Leute es gemacht haben oder könnten. Zum Beispiel per E-Mail, per Matrix-Netzwerk, per Telefon oder indem man mich persönlich besucht. So gut wie alle Informationen sind auf fryboyter.de genannt bzw. man bekommt sie leicht mit einer Suchmaschine seiner Wahl heraus. Aber darum geht es mir nicht.

Nehmen wir mal meinen letzten Artikel als Beispiel, der wohl die meisten Reaktionen in der letzten Zeit bewirkt hat. Wer mir deswegen beispielsweise eine E-Mail geschrieben hat, hat allerdings das gleiche Problem wie mit der Kommentarfunktion. Entweder reagiere ich darauf, wann ich will (oder kann) oder ich reagiere gar nicht darauf.

Aber warum muss man es von mir abhängig machen? Wenn ihr beispielsweise etwas zu einem meiner Artikel zu sagen habt, dann erstellt doch einfach einen eigenen Artikel auf eurer eigenen Internetseite. Früher gab es mal etwas, dass als “Stöckchen zuwerfen” bezeichnet wurde. Also jemand hat einen Artikel geschrieben, und jemand anderes hat mit einem Artikel darauf reagiert. Das wurde entweder vorher abgesprochen, wer reagiert oder es war zufällig. Warum diese “Tradition” nicht weiterführen?

Einige werden jetzt vermutlich argumentieren, dass ich auf diese Reaktionen spät oder gar nicht reagieren werde. Korrekt. Aber andere Leute werden vielleicht zeitnah reagieren. Seit es nun in Form von Kommentaren oder indem sie selbst Artikel veröffentlichen. Das finde ich nicht schlecht. Es geht ja nicht nur um mich. Und umso mehr Meinungen umso besser.

Im vergangenen Sommer interpretierte ich die Ankündigung von LibreOffice als “wir haben fertig” und prognostizierte, dass das neue Versionierungsschema dies vor allem kaschieren soll. Dagegen gab es viel Protest über meine vermeintliche LibreOffice-feindliche Haltung. Den Zwischenstand konnte man am 31.1.24 bewundern.

Vorgestern wurde die Version 24.2 durch die Document Foundation freigegeben. Zur Erinnerung: Im neuen Schema handelt es sich um ein größeres halbjährliches Update, da kleinere Updates in dritter Stelle folgen. Die nächste Version wird voraussichtlich 24.8 sein und im August veröffentlicht werden.

Neuerungen darf man mit der Lupe suchen. Eine deutschsprachige Zusammenfassung gibt es bei Heise. Es gibt ein paar Detailverbesserungen an der Oberfläche und Fehler wurden behoben. Das Highlight der Hauptversion ist die automatische Aktivierung der Wiederherstellungsfunktion, wodurch jetzt im Hintergrund permanent Sicherungen angelegt werden. Die LibreOffice-Entwickler haben das Programm also tatsächlich offenkundig in den Wartungsmodus versetzt. Wichtige Themen wie generative KI sehe man sich laut Heise in Ruhe an. Vermutlich genau so in Ruhe wie mobile Apps für iOS und Android. Smartphones und Tablets sind ja nun wirklich Neuland, da muss man erstmal abwarten, ob sich das etabliert und Marktanteile vom technisch überlegenen Personal Computer abzieht.

Die Entwickler haben also offensichtlich entweder keine Kapazitäten für neue Funktionen oder keine gemeinsame Idee, wohin sie die einzige freie Office-Suite entwickeln möchten. Bestandsnutzer werden das wohl noch akzeptieren, aber beim Megathema “souveräner Arbeitsplatz” wird der Graben zu proprietären Produkten täglich größer. Ich prognostiziere, dass LibreOffice in Zukunft nur noch eine untergeordnete Rolle bei etwaigen Migrationen spielen wird und stattdessen andere Produkte zum Einsatz kommen.

Der Artikel Kommentar: LibreOffice mit neuer Version ohne Neuerung erschien zuerst auf Curius

1. Februar 2024

Vermutlich hat es schon fast jeder erlebt. Jemand stellt ein neues Programm vor und früher oder später (meist früher als später) wird die Frage gestellt, warum es nicht die Befehle von vim unterstützt bzw. ob eine Unterstützung geplant ist.

Fragt man dann nach dem Grund für diesen Wunsch, wird meist das sogenannte Muskelgedächtnis angegeben. Bei manchen Nutzern haben sich die Befehle von vim scheinbar so tief in dieses eingebrannt, dass ohne diese eine Nutzung von Programmen schwer bis unmöglich ist. Zumindest habe ich dieses Gefühl, wenn ich die eine oder andere Diskussion verfolge.

Im Grunde habe ich damit kein Problem. Wenn ein Programm optional die Befehle von vim unterstützt oder es eine entsprechende Erweiterung gibt, soll es mir recht sein. Ich nutze dann einfach beides nicht und das Thema ist für mich erledigt.

Nehmen wir nun den Editor Helix als Beispiel, über den ich bereits vor ein paar Monaten einen Artikel veröffentlicht habe. Bei Helix handelt es sich ebenfalls um einen modalen Editor. Allerdings selektiert man bei diesem erst, was man ändern will und führt dann die Aktion aus. Bei vim ist es genau umgekehrt. Es dürfte somit gar nicht machbar sein, die Bedienung von vim auf Helix komplett zu übertragen. Projekten wie https://github.com/LGUG2Z/helix-vim gelingt das daher auch nur teilweise.

Und trotzdem gibt es regelmäßig Anfragen ob Helix nicht die Shortcuts von vim unterstützen kann. Aber warum?

Ich habe schon immer vermieden vim zu nutzen, da mir dessen Bedienung nicht zusagt. Trotzdem ist es mir bisher noch nie in den Sinn gekommen, dass ich einen Feature Request für vim Stelle, damit dieser Editor beispielsweise die Shortcuts von micro unterstützt. Dieser würde vermutlich schneller geschlossen als ich bis 3 zählen kann. Und das zu Recht. Genauso wie ich es akzeptiert habe, dass ich Helix nicht so bedienen kann, wie ich es von anderen Editoren in den letzten Jahren gewohnt bin. Und trotzdem kann ich mit Helix inzwischen ganz gut umgehen. Und das trotz des Muskelgedächtnisses und der Tatsache, dass ich schon einige Jahrzehnte auf dem Zähler habe.

Von daher liebe Nutzer von vim (also der Teil auf den ich mich mit diesem Artikel beziehe), schaut euch gerne Alternativen zu vim an. Aber bitte versucht zu verstehen, dass nicht jede Alternative das Ziel hat eine bessere / andere Version von vim anzubieten. Viele Projekte, wie Helix, wollen einfach nur Ihr eigenes Ding machen. Wenn euch das nicht zusagt, was ich durchaus nachvollziehen kann, nutzt einfach weiterhin vim. Vim ist, objektiv betrachtet, ja kein schlechter Editor.

31. Januar 2024

Es gibt wieder neue Sicherheitslücken in glibc. Dabei betrifft eine die syslog()-Funktion, die andere qsort(). Letztere Lücke existiert dabei seit glibc 1.04 und somit seit 1992. Entdeckt und beschrieben wurden die Lücken von der Threat Research Unit bei Qualys.

Die syslog-Lücke ist ab Version 2.37 seit 2022 enthalten und betrifft somit die eher die neuen Versionen von Linux-Distributionen wie Debian ab Version 12 oder Fedora ab Version 37. Hierbei handelt es sich um einen "heap-based buffer overflow" in Verbindung mit argv[0]. Somit ist zwar der Anwendungsvektor schwieriger auszunutzen, weil in wenigen Szenarien dieses Argument (der Programmname) dem Nutzer direkt überlassen wird, die Auswirkungen sind jedoch umso schwerwiegender. Mit der Lücke wird eine lokale Privilegienausweitung möglich. Die Lücke wird unter den CVE-Nummern 2023-6246, 2023-6779 und 2023-6780 geführt.

Bei der qsort-Lücke ist eine Memory Corruption möglich, da Speichergrenzen an einer Stelle nicht überprüft werden. Hierfür sind allerdings bestimmte Voraussetzungen nötig: die Anwendung muss qsort() mit einer nicht-transitiven Vergleichsfunktion nutzen (die allerdings auch nicht POSIX- und ISO-C-konform wären) und über eine große Menge an zu sortierenden Elementen verfügen, die vom Angreifer bestimmt werden. Dabei kann ein malloc-Aufruf gestört werden, der dann zu weiteren Angriffen führen kann. Das Besondere an dieser Lücke ist ihr Alter, da sie bereits im September 1992 ihren Weg in eine der ersten glibc-Versionen fand.

Bei der GNU C-Bibliothek (glibc) handelt es sich um eine freie Implementierung der C-Standard-Bibliothek. Sie wird seit 1987 entwickelt und ist aktuell in Version 2.38 verfügbar. Morgen, am 1. Februar, erscheint Version 2.39.

29. Januar 2024

Der »Fedora Asahi Remix« ist eine für moderne Macs (Apple Silicon) optimierte Version von Fedora 39. Ich habe mich mit Asahi Linux ja schon vor rund zwei Jahren beschäftigt. Seither hat sich viel getan. Zeit also für einen neuen Versuch! Dieser Beitrag beschreibt die Installation des Fedora Asahi Remix auf einem Mac Mini mit M1-CPU. Demnächst möchte ich einen zweiten Artikel schreiben, der auf die Konfiguration eingeht und praktische Erfahrungen zusammenfasst.

Installationsstart

Die Projektseite von Asahi Linux empfiehlt, die Installation von Asahi Linux in einem Terminal wie folgt zu starten:

curl https://alx.sh | sh

Ich habe bei solchen Dingen immer etwas Bauchweh, zumal das Script sofort nach dem sudo-Passwort fragt. Was, wenn irgendjemand alx.sh gekapert hat und mir ein Script unterjubelt, das einen Trojaner installiert? Daher:

curl https://alx.sh -o alx.sh
less alx.sh
sh alx.sh 

Die Kontrolle hilft auch nur bedingt. Das Script ist nur wenige Zeilen lang und lädt alle erdenklichen weiteren Tools herunter. Aber der Code sieht zumindest so aus, als würde er tatsächlich Asahi Linux installieren, keine Malware. Eine echte Garantie, dass das alles gefahrlos ist, gibt auch less nicht. Nun gut …

Zuerst aufräumen

Auf meinem Mac fristet eine uralte Asahi-Installation schon seit Jahren ein Schattendasein. Ich wollte das neue Asahi Linux einfach darüber installieren — aber das Installationsprogramm bietet dazu keine Möglichkeit. Die richtige Vorgehensweise sieht so aus: Zuerst müssen die drei damals eingerichteten Partitionen gelöscht werden. Dann kann das Installationsprogramm den partitionsfreien Platz auf der SSD für eine Neuinstallation nutzen.

Dankenswerterweise hat Asahi-Chefentwickler Hector Martin auf einer eigenen Seite eine Menge Know-how zur macOS-Partitionierung zusammengefasst. Dort gibt es auch gleich ein Script, mit dem alte Asahi-Linux-Installationen entfernt werden können. Gesagt, getan!

curl -L https://github.com/AsahiLinux/asahi-installer/raw/main/tools/wipe-linux.sh -o wipe-linux.sh
less wipe-linux.sh
sh wipe-linux.sh

THIS SCRIPT IS DANGEROUS!
DO NOT BLINDLY RUN IT IF SOMEONE JUST SENT YOU HERE.
IT WILL INDISCRIMINATELY WIPE A BUNCH OF PARTITIONS
THAT MAY OR MAY NOT BE THE ONES YOU WANT TO WIPE.

You are much better off reading and understanding this guide:
https://github.com/AsahiLinux/docs/wiki/Partitioning-cheatsheet

Press enter twice if you really want to continue.
Press Control-C to exit.

Started APFS operation on disk1
Deleting APFS Container with all of its APFS Volumes
Unmounting Volumes
Unmounting Volume "Asahi Linux - Data" on disk1s1
Unmounting Volume "Asahi Linux" on disk1s2
Unmounting Volume "Preboot" on disk1s3
Unmounting Volume "Recovery" on disk1s4
Unmounting Volume "Update" on disk1s5
...

Bei meinem Test hat das Script exakt getan, was es soll. Ein kurzer Test mit diskutil zeigt, dass sich zwischen Partition 2 und 3 eine Lücke von rund 200 GiB befindet. Dort war vorher Asahi Linux, und dorthin soll das neue Asahi Linux wieder installiert werden.

Zurück an den Start

Nach diesen Vorbereitungsarbeiten (natürlich habe ich vorher auch ein Backup aller wichtiger Daten erstellt, eh klar …) habe ich den zweiten Versuch gestartet.

sh alx.sh 

Bootstrapping installer:
  Checking version...
  Version: v0.7.1
  Downloading...
  Extracting...
  Initializing...

The installer needs to run as root.
Please enter your sudo password if prompted.
Password:*******

Welcome to the Asahi Linux installer!

This installer will guide you through the process of setting up
Asahi Linux on your Mac.

Please make sure you are familiar with our documentation at:
  https://alx.sh/w

Press enter to continue.

Collecting system information...
  Product name: Mac mini (M1, 2020)
  SoC: Apple M1
  Device class: j274ap
  Product type: Macmini9,1
  Board ID: 0x22
  Chip ID: 0x8103
  System firmware: iBoot-10151.81.1
  Boot UUID: 284E...
  Boot VGID: 284E...
  Default boot VGID: 284E...
  Boot mode: macOS
  OS version: 14.3 (23D56)
  OS restore version: 23.4.56.0.0,0
  Main firmware version: 14.3 (23D56)
  No Fallback System Firmware / rOS
  SFR version: 23.4.56.0.0,0
  SystemRecovery version: 22.7.74.0.0,0 (13.5 22G74)
  Login user: kofler

Collecting partition information...
  System disk: disk0

Collecting OS information...

Nach der Darstellung einiger Infos ermittelt das Script eine Partitionstabelle und bietet dann an, Asahi Linux im freien Bereich der Disk zu installieren (Option f).

Partitions in system disk (disk0):
  1: APFS [Macintosh HD] (795.73 GB, 6 volumes)
    OS: [B*] [Macintosh HD] macOS v14.3 [disk3s1s1, 284E...]
  2: (free space: 198.93 GB)
  3: APFS (System Recovery) (5.37 GB, 2 volumes)
    OS: [  ] recoveryOS v14.3 [Primary recoveryOS]

  [B ] = Booted OS, [R ] = Booted recovery, [? ] = Unknown
  [ *] = Default boot volume

Using OS 'Macintosh HD' (disk3s1s1) for machine authentication.

Choose what to do:
  f: Install an OS into free space
  r: Resize an existing partition to make space for a new OS
  q: Quit without doing anything

» Action (f): f

Im nächsten Schritt haben Sie die Wahl zwischen verschiedenen Fedora-Varianten. Ich habe mich für Gnome entschieden:

Choose an OS to install:
  1: Fedora Asahi Remix 39 with KDE Plasma
  2: Fedora Asahi Remix 39 with GNOME
  3: Fedora Asahi Remix 39 Server
  4: Fedora Asahi Remix 39 Minimal
  5: UEFI environment only (m1n1 + U-Boot + ESP)

» OS: 2

Jetzt beginnt die eigentliche Installation. Leider haben Sie keine Möglichkeit, auf die Partitionierung oder Verschlüsselung Einfluss zu nehmen. Es werden zwei kleine Partitionen für /boot (500 MiB) und /boot/efi eingerichtet (1 GiB). Den restlichen Platz füllt ein btrfs-Dateisystem ohne Verschlüsselung. Immerhin können Sie bei Bedarf festlegen, dass nicht der gesamte partitionsfreie Platz von Fedora Asahi Linux genutzt wird.

Downloading OS package info...
- 

Minimum required space for this OS: 14.94 GB

Available free space: 198.93 GB

How much space should be allocated to the new OS?
  You can enter a size such as '1GB', a fraction such as '50%',
  the word 'min' for the smallest allowable size, or
  the word 'max' to use all available space.

» New OS size (max): max

The new OS will be allocated 198.93 GB of space,
leaving 167.94 KB of free space.

Enter a name for your OS
» OS name (Fedora Linux with GNOME):  <return>

Using macOS 13.5 for OS firmware
Downloading macOS OS package info...
Creating new stub macOS named Fedora Linux with GNOME
Installing stub macOS into disk0s5 (Fedora Linux with GNOME)
Preparing target volumes...
Checking volumes...
Beginning stub OS install...
Setting up System volume...
Setting up Data volume...
Setting up Preboot volume...
Setting up Recovery volume...
Wrapping up...

Stub OS installation complete.

Adding partition EFI (524.29 MB)...
  Formatting as FAT...
Adding partition Boot (1.07 GB)...
Adding partition Root (194.83 GB)...
Collecting firmware...
Installing OS...
  Copying from esp into disk0s4 partition...
  Copying firmware into disk0s4 partition...
  Extracting boot.img into disk0s7 partition...
  Extracting root.img into disk0s6 partition...
Downloading extra files...
  Downloading gstreamer1-plugin-openh264-1.22.1-1.fc39.aarch64.rpm (1/3)...
  Downloading mozilla-openh264-2.3.1-2.fc39.aarch64.rpm (2/3)...
  Downloading openh264-2.3.1-2.fc39.aarch64.rpm (3/3)...
Preparing to finish installation...
Collecting installer data... 

To continue the installation, you will need to enter your macOS
admin credentials.

Password for kofler: **********

Setting the new OS as the default boot volume...
Installation successful!
Install information:
  APFS VGID: 0E76...
  EFI PARTUUID: 8d47...

Help us improve Asahi Linux!
We'd love to know how many people are installing Asahi and on what
kind of hardware. Would you mind sending a one-time installation
report to us?

This will only report what kind of machine you have, the OS you're
installing, basic version info, and the rough install size.
No personally identifiable information (such as serial numbers,
specific partition sizes, etc.) is included. You can view the
exact data that will be sent.

Report your install?
  y: Yes
  n: No
  d: View the data that will be sent

» Choice (y/n/d): y

Your install has been counted. Thank you! ❤

Zuletzt zeigt das Installations-Script genaue Anweisungen für den ersten Start von Asahi Linux an:

To be able to boot your new OS, you will need to complete one more step.
Please read the following instructions carefully. Failure to do so
will leave your new installation in an unbootable state.

Press enter to continue.

When the system shuts down, follow these steps:

1. Wait 25 seconds for the system to fully shut down.
2. Press and hold down the power button to power on the system.
   * It is important that the system be fully powered off before this step,
     and that you press and hold down the button once, not multiple times.
     This is required to put the machine into the right mode.
3. Release it once you see 'Loading startup options...' or a spinner.
4. Wait for the volume list to appear.
5. Choose 'Fedora Linux with GNOME'.
6. You will briefly see a 'macOS Recovery' dialog.
   * If you are asked to 'Select a volume to recover',
     then choose your normal macOS volume and click Next.
     You may need to authenticate yourself with your macOS credentials.
7. Once the 'Asahi Linux installer' screen appears, follow the prompts.

If you end up in a bootloop or get a message telling you that macOS needs to
be reinstalled, that means you didn't follow the steps above properly.
Fully shut down your system without doing anything, and try again.
If in trouble, hold down the power button to boot, select macOS, run
this installer again, and choose the 'p' option to retry the process.

Press enter to shut down the system.

Ich habe den Installationsprozess auch in Screenshots dokumentiert:

Asahi-Linux, Teil 1

Asahi-Installation, Teil 2

Reboot

Das Script fährt nun macOS herunter. Zum Neustart drücken Sie die Power-Taste und halten diese ca. 15 Sekunden lang gedrückt, bis ein Auswahlmenü erscheint. Dort wählen Sie Asahi Linux. Dieses wird allerdings nicht gleich gestartet, vielmehr muss nun die Bootkonfiguration fertiggestellt werden. Ich habe die folgenden Schritte mit Fotos dokumentiert.

Fedora Linux auswählen
Bootloader Installation
Bootloader-Installation (Forts.)
Bootloader-Installation (Forts.)
Bootloader-Installation (Forts.)
Bootloader-Installation (Forts.)
Meldungen beim ersten »echten« Linux-Bootprozess. »Failed to load« klingt schlimm, aber unmittelbar danach geht es zum Glück weiter.
Geschafft! Jetzt muss nur noch die Fedora-Installation abgeschlossen werden.

Fedora-Installation abschließen

Fedora Linux läuft zum ersten Mal. Nun müssen Sie einige grundlegende Konfigurationsschritte erledigen (User-Name + Passwort, WLAN, Sprache, Tastaturlayout, Update).

Wechseln zwischen macOS und Fedora

Der Bootprozess ist jetzt so eingerichtet, dass bei jedem Neustart automatisch Fedora gestartet wird. Wenn Sie macOS verwenden möchten, müssen Sie den Rechner zuerst komplett herunterfahren. Dann drücken Sie wieder die Power-Taste, halten Sie ca. 15 Sekunden gedrückt, bis das OS-Menü erscheint, und wählen macOS.

Unter macOS können Sie das Default-OS voreinstellen. Es ist aber leider nicht möglich, den Mac so zu konfigurieren, dass bei jedem Bootprozess automatisch das Auswahlmenü erscheint. Sie müssen sich für eine Hauptvariante entscheiden. Jeder Bootprozess in ein anderes OS bleibt mühsam (Power-Taste 15 Sekunden drücken …).

Default-OS einstellen

Geekbench

Wie schnell ist Linux im Vergleich zu macOS? Ich habe auf meinem Mac Mini M1 Geekbench 6 jeweils unter macOS und unter Fedora Asahi ausgeführt. Das Ergebnis: im Rahmen der Messgenauigkeit etwa gleich schnell.

               Single     Multi Core
---------- ----------   ------------
macOS            2360           8050
Fedora           2357           7998

Quellen/Links

Was ist die Geschichte von BunsenLabs und wie komfortabel ist die Distribution bei der Bedienung? Ich probiere es für euch aus.

Damals

Im ersten Teil dieses Kurztests habe ich die Installation und den ersten Eindruck von BunsenLabs Boron geschildert. In diesem zweiten Teil geht es um die Herkunft und die Tauglichkeit im täglichen Betrieb.

BunsenLabs stellt einen geistigen Nachfolger zum eingestellten CrunchBang Linux dar. Von diesem übernimmt es Openbox als Fenstermanager. Das Design ist schlicht gehalten. Bei den Paketquellen setzt BunsenLabs auf Debian in der stabilen Fassung. Bei der Auswahl an Software wird grösstenteils auf GTK basierte Programme gesetzt. Ein schlankes Grundsystem wird mit einem minimalistischen Erscheinungsbild kombiniert. Der Fenstermanager ist dabei stark anpassbar und unterstützt auch moderne Widescreen-Monitore.

CrunchBang war eine auf Debian GNU/Linux basierende Distribution, die eine Mischung aus Geschwindigkeit, Stil und Substanz bot. Durch die Verwendung des flinken Openbox-Fenstermanagers war es in hohem Masse anpassbar und bot ein modernes, voll ausgestattetes GNU/Linux-System ohne Leistungseinbussen. Die Entwicklung von CrunchBang wurde eingestellt, aber es inspirierte die Mitglieder der Community zur Entwicklung einiger hervorragender Spin-off-Projekte, wie z. B. BunsenLabs.

Weitere Informationen über die Geschichte von BunsenLabs findet ihr im Artikel von caos bei uns.

Heute

Wie im ersten Teil beschrieben, ist die Installation kinderleicht und führt zu einem grafisch ansprechenden OpenBox-Desktop. Ich habe BunsenLabs in der virtuellen Maschine GNOME-Boxes getestet. Die aktuelle Version Boron basiert auf Debian 12 mit dem Kernel 6.1.0-17. Die Distro belegt ca. 500 MB RAM, was am schlanken Fenstermanager liegt. Um die Alltagstauglichkeit zu prüfen, schaue ich mir folgenden Bereiche an:

  • Bildschirmauflösung
  • Spracheinstellung
  • Mitgelieferte Software
  • Paketverwaltung

Bildschirmauflösung

Die Änderung der Bildschirmauflösung auf die Fähigkeiten meines Monitors hat mir Kopfzerbrechen bereitet. Alle üblichen/einfachen Verfahren funktionieren nicht. Ich musste das Internet bemühen, um eine Lösung zu finden. Hallo 90'er-Jahre.

Wer bei BunsenLabs die Bildschirmauflösung verändern möchte, muss ArandR verwenden, oder xrandr im Terminal bemühen. Und dann muss man die Screen-Konfiguration im Autostart unterbringen. Mit ArandR habe ich es nicht geschafft, die Auflösung zu persistieren. Null Punkte.

Spracheinstellung

Während der Installation von BunsenLabs Boron werden alle nötigen Informationen für die Sprach- und Gebietseinstellungen abgefragt. Die Distribution ignoriert diese Angaben und stellt nur englische Labels bereit. Nach langem Suchen habe ich keine Möglichkeit gefunden, die Spracheinstellungen zu ändern. Und nein, ich habe nicht drei Stunden im Internet danach gesucht. Null Punkte.

Mitgelieferte Software

Die Auswahl der vorinstallierten Pakete ist reichhaltig. Da findet sich für jeden Anwendungsfall eine Lösung. Man erreicht diese über das Rechts-Klick-Menü oder über die Suche mit SUPER+Suchbegriff. Hier ist eine kleine Auswahl:

  • Internet: Firefox ESR, HexChat, Filezilla, Transmission
  • Dateiemanager: Thunar
  • Suche: Catfish
  • Editor und IDE: Geany
  • Bilder: Ristretto, ImageMagick
  • Multimedia: Xfburn, VLC, PulseAudio
  • Office: LibreOffice, Evince
  • und viele andere

Bei der Paketverwaltung setzt BunsenLabs auf:

  • apt im Terminal
  • Synaptic (für alle, die es grafisch mögen)
  • und eine Favoriten-Anwendung:

Die vorinstallierten Pakete sind gut ausgewählt und reichhaltig. Vielen mag der Zugriff auf die Apps über das Rechts-Klick-Menü gefallen, andere mögen des als zu Klick-intensiv empfinden. Ebendarum hat BunsenLabs das Tilt2-Panel standardmässig integriert. Doch wie funktioniert es?

Über den Tint2-Manager (findet man im Menü unter "User Settings, Tint2" auswählen) können verschiedene Designs und Anordnungen für das Panel gewählt werden. Im Screenshot seht ihr eine Variante, die das Panel am unteren Bildschirmrand anordnet.

Doch wie bringt man App-Starter in das Tint2-Panel? Dafür gibt es im oben erwähnten Menü den Tint2-Editor. Dieser öffnet eine Konfigurationsdatei, in der man das Tint2-Panel einrichten kann, einschliesslich der App-Starter. An dieser Stelle bin ich ausgestiegen. Null Punkte.

Paketverwaltung

Das Wesentliche habe ich bereits im vorherigen Kapitel erwähnt. Als Debian-basierte Distribution kommt apt als Paketverwaltung zum Zuge. Andere Paketformate werden nicht unterstützt. Mit dem Menüeintrag "Install Favourite Packages" gibt es ein gutes Angebot, um zusätzliche Software mit wenigen Klicks zu installieren.

Wie man sieht, verbergen sich dahinter Shell-Skripte, was keinesfalls als Kritik gemeint ist, aber Einsteiger:innen irritieren könnte. Einer der Neuerungen in der Boron-Version ist das automatische Update von Debian-Paketen. Diese Option kann im Terminal durch den Aufruf des Shell-Skripts bl-welcome eingerichtet werden. Ob das funktioniert, konnte ich aus Zeitgründen nicht überprüfen. Im Zweifel verwendet man sudo apt update && sudo apt upgrade.

Fazit

Wenn ich einen kurzen Testbericht über eine GNU/Linux-Distribution schreibe, wird dieser der Distro oft nicht gerecht. Das zeigt sich gerade bei BunsenLabs Boron. Im ersten Teil war ich begeistert, ob der einfachen Installation und dem tollen Erscheinungsbild. Der zweite Teil ist ziemlich negativ ausgefallen. Das möchte ich nicht der Distro anlasten, sondern der wenigen Zeit, die ich damit verbracht habe. Wer viele Distributionen getestet hat, entwickelt über die Jahre ein Gefühl, das sich kaum beschreiben lässt. Man fühlt das Potenzial einer Distribution; und dieses Gefühl ist bei BunsenLabs Boron gut. Die Entwickler haben viel Liebe in ihre Distribution gegossen. Deshalb ist es wert, mehr Zeit mit Boron zu verbringen, um die Details zu erforschen.


GNU/Linux.ch ist ein Community-Projekt. Bei uns kannst du nicht nur mitlesen, sondern auch selbst aktiv werden. Wir freuen uns, wenn du mit uns über die Artikel in unseren Chat-Gruppen oder im Fediverse diskutierst. Auch du selbst kannst Autor werden. Reiche uns deinen Artikelvorschlag über das Formular auf unserer Webseite ein.