Open Source Lösungen sind per se gut für den Datenschutz. Irgendwie hat sich diese Gleichsetzung bei vielen festgesetzt. Doch so einfach ist das nicht und vor allem kommt es auf die Umsetzung an.

Die Gleichsetzung alles, was Open Source ist, ist gleichzeitig gut für den Datenschutz, hat sich in den letzten Jahren in der Öffentlichkeit festgesetzt. Dabei ist das gleich auf mehreren Ebenen falsch und entsprechende Behauptungen sollten bei jedem die Alarmglocken läuten lassen.

Open Source bedeutet erst mal nur, dass der Quellcode frei einsehbar ist. Das ist natürlich gut für eine Überprüfung des Datenschutzes, aber jedem sollte einleuchten, dass man die grauenvollste Software grundsätzlich auch Open Source stellen könnte (ich hatte das am Beispiel Linux auch mal durch dekliniert) Zweitens kommt es beim Datenschutz fast immer auf die konkrete Implementierung an und hier sind nicht umsonst aufwendige Prüfverfahren vorgesehen. Wenn irgendjemand in einer Diskussion pauschal behauptet, Lösung XYZ wäre gut für den Datenschutz, ohne auf die konkreten Details einzugehen, sollte bei jedem die Warnglocken läuten, denn entweder verkürzt derjenige stark oder er hat schlicht keine Ahnung.

Warum das so ist, möchte ich an einem kleinen Beispiel ausführen: Big Blue Button (im folgenden BBB) vs. Zoom.

Big Blue Button ist der Darling der Open Source Szene in Pandemie-Zeiten. Eine leistungsstarke Videokonferenzlösung, die quelloffen ist und transparent auf GitHub entwickelt wird. Zoom hingegen war schon vor der Corona-Pandemie suspekt und spätestens seit dem Frühjahr 2020 Gegenstand heißer Auseinandersetzungen. Also eigentlich klar, was hier hinsichtlich Datenschutz die Nase vorn hat, oder?

Das folgende Gedankenexperiment soll zeigen, dass so etwas eben nicht so klar und eindeutig ist, wie das gerne dargestellt wird.

Beide Videokonferenzsysteme arbeiten nicht per P2P-Prinzip, sondern benötigen eine zentrale Infrastruktur. Bei BBB wird meist davon ausgegangen, dass diese durch die nutzende Einrichtung betrieben wird, man kann dafür aber natürlich auch auf Dienstleister zurückgreifen. Zoom wird hingegen in der Regel durch die Zoom Inc. gehostet, es gibt aber auch die Möglichkeit, für große Einrichtungen die Zoom-Server selbst in ihren Rechenzentren zu betreiben.

Beide Systemen haben zudem positive wie negative Funktionen. Nur ein paar Beispiele zum Verständnis: Zoom bietet neben vielen kritisieren Funktionen auch eine Inhalteverschlüsselung für Videokonferenzen und hat dieses Thema erst richtig auf die Agenda gesetzt. BBB wird zwar transparent entwickelt, hat aber in der Vergangenheit Probleme mit der Sicherheit gehabt und die Umsetzung der für den Anwender nicht ersichtlichen Aufzeichnung aller Sessions ist höchst problematisch und muss durch den Administrator ggf. komplett deaktiviert werden.

Spannend wir nun also mal ein denkbar ungünstiges Szenario für BBB auf:

Die Einrichtung hat nicht die notwendigen Kapazitäten oder Expertise BBB selbst zu betreiben. Eine große Instanz für bis zu 300 gleichzeitige Teilnehmer ist schließlich nicht ganz trivial zu betreiben. Stattdessen nimmt man einen Dienstleister. Wenn man jetzt ein richtig negatives Szenario haben möchte, dann sitzt dieser Dienstleister noch nicht mal in der Europäischen Union, aber es funktioniert auch mit einem Sitz in der EU. Weil es schnell gehen musste, ist die vertragliche Basis lückenhaft und der Auftragsdatenverarbeitungsvertrag existiert nicht. Welche BBB-Version genau beim Dienstleister läuft ist unklar, theoretisch könnte es sich sogar um eine von der frei verfügbaren Open Source-Lösung abgewandelte Variante handeln. Ob der Dienstleister die problematischen Funktionen bei BBB deaktiviert hat, kann nicht kontrolliert werden. Ein besonderer Fokus auf Datensparsamkeit bei der BBB-Instanz existiert nicht. Weil BBB nur eine Transport- und keine Inhalteverschlüsselung bietet, sind für den Dienstleister potenziell alle Inhalte und Metadaten frei verfügbar.

Nehmen wir nun das denkbar günstigste Szenario für Zoom zum Vergleich. Die Einrichtung hat nicht nur eine teure Lizenz, sondern betreibt die Zoom-Server sogar in den eigenen Rechenzentren (Zoom on-premise). Die Metadaten, d. h. vor allem welche Benutzer eingeladen sind und wann das Meeting stattfindet, landet zwar weiterhin bei Zoom, der gesamte Meeting-Verkehr wird aber über die eigene Infrastruktur abgewickelt. Durch die Inhalteverschlüsselung ist das zudem deutlich sicherer als bei nahezu allen konkurrierenden Lösungen. Versteckte Aufzeichnungen etc. pp. gibt es bei Zoom nicht, hier hat man in den vergangenen Jahren durch den ständigen Fokus der Öffentlichkeit viel nachgearbeitet.

Welche Lösung ist nun hinsichtlich des Datenschutzes die bessere?

Natürlich hat dieses Szenario in sofern Schlagseite, als dass ich das denkbar ungünstigste BBB-Szenario dem denkbar günstigsten Zoom-Szenario gegenüber gestellt habe und das somit eine eher theoretische Fingerübung ist.

In der Realität würde man als lokaler Datenschutzbeauftragter darauf drängen, eine saubere BBB-Infrastruktur zu betreiben und Verbesserungen in dem Bereich vornehmen, weil das Entwicklungspotenzial hier besser ist als bei Zoom, wo man letztlich um den problematischen Metadatenabfluss an Zoom nicht umhin kommt.

Daraus lernen kann man aber, dass die Aussage, ob etwas gut oder schlecht für den Datenschutz ist, bei nahezu allen komplexeren Fällen wie z. B. einer Videokonferenzinfrastruktur niemals pauschal gesagt werden kann, sondern immer das Ergebnis einer intensiven Prüfung unter Einbeziehung aller Faktoren ist. Hinzu kommt oft eine gewisse Freiheit bei der Risikoabwägung, weshalb ähnlich wie bei Juristen gilt: 3 Datenschützer, 5 Meinungen. Jeder, der mal beruflich im Datenschutz gearbeitet hat, weiß das.

Wenn ihr also Pauschalurteile zum Datenschutz lest, dann wisst ihr entweder, dass derjenige stark verkürzt, seine Meinung schon vorher feststand oder der Autor schlicht keine Ahnung von Datenschutz im wirklichen Arbeitsalltag hat – denn da gibt es selten eindeutige oder perfekte Lösungen.

Der Artikel Open Source = Datenschutz? So einfach ist das nicht! erschien zuerst auf [Mer]Curius

Wie Benjamin Brunner, Entwickler bei SUSE, vor einigen Tagen über die Mailingliste kommunizierte, arbeitet man momentan an der Implementierung der neuen systemd-Funktionen, um LUKS2-Volumes mittels TPM oder FIDO2 zu entsperren.

Dabei handelt es sich um eine Funktion, die Lennart Poettering Anfang diesen Jahres ankündigte und über die ich hier bereits berichtete hatte. Mittels systemd-cryptenroll lassen sich unter anderem TPM oder FIDO2 als Entsperrmechanismen für LUKS2 hinterlegen. Diese neuen Verfahren stehen in einem direkten Kontext zu weiteren Bestrebungen, um den Sicherheitslevel der verbreiteten Linux-Verschlüsselung auf ein zeitgemäßes Niveau zu bringen.

Die Zielrichtung der Bestrebungen bei SUSE/openSUSE ist noch nicht klar. Also ob und inwieweit das in die Installationsroutine oder YaST implementiert wird. Zudem sind noch einige Vorarbeiten notwendig. Genaueres können interessierte Anwender im Wiki nachlesen.

Die Funktion systemd-cryptentroll benötigt LUKS2-Volumes. Das ist für SUSE/openSUSE ein Problem, weil die Installationsroutine bis zuletzt LUKS1-Volumes angelegt hat. Daran hat man allerdings anderweitig bereits gearbeitet und ich denke, hier dürfte sich zukünftig was ändern. Bestehende Installationen lassen sich zudem relativ leicht mittels eines Live-Mediums von LUKS1 auf LUKS2 migrieren. Allerdings benötigt systemd-cryptenroll auch eine unverschlüsselte Boot-Partition und das ist standardmäßig bei SUSE/openSUSE schon länger nicht mehr der Fall.

Hinzu kommen noch ein paar Probleme, weil z. B. die FIDO2-Abfrage upstream noch nicht in Plymouth integriert ist und somit nicht optisch schön beim Startvorgang erscheint, sondern „blind“ durch den Anwender erfolgen muss.

Die beiden neuen Authentifizierungsmethoden sind wichtige Ergänzungen für die Legacy-Verfahren mittels Passwort. Teilweise lösen sie auch zusammen gestückelte Skripte bei z. B. Debian und Arch Linux ab, die bereits Sicherheitssticks wie den YubiKey unterstützten. FIDO2 adressiert das Problem der unsicheren Passwörter und TPM2 bietet unter anderem Schutz gegen Angriffe mittels Brute Force und vor allem das beliebte Kopieren der Daten, um sie danach in aller Ruhe zu untersuchen.

Es ist also noch ein wenig Wegstrecke zu meisten, bis diese Funktionen standardmäßig umgesetzt werden können. Wer aber schon ein System mit LUKS2 und unverschlüsselter Boot-Partition hat oder eine Testinstallation betreibt, kann sich die neuen Funktionen mal ansehen. Meiner Meinung nach geht das absolut in die richtige Richtung.

Der Artikel openSUSE arbeitet an LUKS mit TPM und FIDO2 erschien zuerst auf [Mer]Curius

Traditionell gebe ich gegen Ende des Jahres einen kleinen Einblick in mein Nutzungsverhalten und das, was sich im vergangenen Jahr geändert hat. Viele Verfechter von Datenschutz und Privatsphäre schreiben gerne über das richtige Nutzungsverhalten, aber jeder muss Kompromisse machen.

Der Blog auf [Mer]Curius spiegelt meine gegenwärtigen Interessen im Bereich Datenschutz/-sicherheit meist ziemlich gut wider. Für viele Leser dürften sich daher einiges Bekanntes wieder finden.

Hardware & Betriebssysteme

Meine Rückkehr zu Linux hat sich im letzten Jahresrückblick bereits abgezeichnet. Es hat dann doch stärker geruckelt, als ich das anfänglich vermutet hatte. Einfach, weil ich mir in den Apple-Jahren einen gewissen Komfort angewöhnt habe, den ich nicht mehr missen möchte. Ein weiterer für mich wichtiger Aspekt ist Datenschutz und Sicherheit. Linux ist hier nicht so optimal aufgestellt, wie es gerne dargestellt wird. Hier tut sich zum Glück einiges und mittelfristig dürfte Linux hier deutlich besser dastehen. Leider sehen das nicht alle so und so treibt mich die selbstzufriedene Bräsigkeit großer Teile der Community regelmäßig auf die Palme. Zum Leidwesen mancher Leser.

Meine anfängliche Unzufriedenheit konnte ich zumindest teilweise lösen, indem ich von KDE Plasma zur Pantheon Shell migriert bin. Bei der Rückkehr zu Linux hatte ich die Wahl von Plasma als Desktop kaum hinterfragt, schließlich steigt man meist wieder da ein, wo man vorher aufgehört hat, aber nach langen Jahren mit macOS habe ich das Stückwerk ohne erkennbare Leitlinie der VDG einfach nicht mehr ertragen.

Grundsätzlich habe ich die partielle Abkehr von macOS aber nicht bereut. Auch ein Jahr nach der Veröffentlichung der ersten Geräte mit M1 Prozessor kann man kein anderes Betriebssystem auf den Geräten nutzen und Virtualisierung funktioniert nur sehr eingeschränkt mit ARM-VMs. Zudem experimentiert Apple mit zweifelhaften Funktionen wie Client Side Scanning und sollten die zur Marktreife kommen, steht der Kunde mangels alternativer lauffähiger Betriebssysteme mit einem Haufen Elektroschrott da. Jedenfalls sofern das Themen sind, die den Nutzer umtreiben – so wie mich eben. Linux bietet hier mehr Freiheit, wenn sich ein Projekt in die falsche Richtung entwickelt. Man ist nicht derart auf Gedeih und Verderb einem einzigen Hersteller oder Entwicklerteam ausgeliefert.

Wobei das nicht bedeutet, dass ich niemandem zu Apples Hardware raten würde. Vergangene Woche haben wir hier im Haushalt ein MacBook Air 2020 angeschafft. Schönes und extrem flottes Gerät und wunderbar geeignet, wenn der Anwender damit einfach in Ruhe seine Sachen erledigen möchte. Nur für mich eben als Hauptgerät nicht mehr geeignet.

Mobil habe ich vergangenes Jahr verstärkt mit LineageOS gearbeitet und bereite gerade den Umstieg auf GrapheneOS mit neuer Hardware vor. Alternativ gibt es noch ein iPhone SE 2020, das sicher noch viele Jahre als Alltagsgerät seinen Dienst tun wird.

Kern meiner Datenhaltung und Synchronisation ist immer noch das gleiche Synology NAS wie seit Jahren. Ich bin dabei mit Synology nicht übermäßig glücklich, weil ich die Updatepolitik hinsichtlich Sicherheitsupdates bei einem so exponierten System nicht professionell genug finde, aber so lange die Hardware läuft und unterstützt wird, werde ich hier wohl nicht migrieren.

Homeoffice im zweiten Jahr

Während privat Open Source nun wieder viel stärker zum Einsatz kommt, bin ich beruflich so richtig schön proprietär unterwegs und finde das nicht mal schlecht. Ich könnte wegen der aktuellen Sonderregelungen (Corona, Homeoffice etc. pp.) sogar mit Linux arbeiten, aber möchte es gar nicht. Aufgrund ausgedehnter Homeoffice-Zeiten gehören diese Betriebssysteme und Programme inzwischen auch faktisch in meinen IT-Haushalt und werden daher hier aufgeführt.

Windows, Microsoft Office, Citavi, Zoom, das ein oder andere Microsoft Teams oder WebEx-Meeting. Ja, hartleibigen Datenschützern dreht sich hier der Magen um, aber es funktioniert und leider auch viel besser als Lösungen wie Big Blue Button, das wir auch haben und wo die Ärgernisse von der eher bescheiden Oberfläche, den bescheidenen Funktionen und der noch bescheideneren Performance inzwischen zum üblichen Smalltalk der Videocalls gehören. Endlich eine Alternative zum Wetter und Pandemie-Status.

Kommunikation

Abgesehen von der Arbeitskommunikation hat es in diesem Bereich im letzten Jahr erstaunliche Fortschritte gegeben.

Die E-Mail ist bei mir massiv auf dem Rückzug. Da ich E-Mails nie lösche und lediglich in Jahresarchive absortiere kann ich das auch gut quantifizieren. Dieses Jahr habe ich knapp 50 % weniger Mails bekommen und beantwortet als im Vorjahr, womit sich ein langjähriger Trend noch mal beschleunigt hat.

Stattdessen hat aufgrund der amateurhaften Kommunikationspolitik von Facebook Signal bei mir dieses Jahr einen Quantensprung gemacht. 70 % meiner Kontakte und Gruppen kann ich inzwischen über Signal abwickeln. Die Migrationsbewegung hielt aber nur kurz an und seit dem Sommer hat sich hier nichts mehr getan. Die verbliebenen WhatsApp-Kontakte sind echt renitent, weshalb mir WhatsApp erhalten bleibt. Wirklich verloren hat Threema, das bei mir fast keine Rolle mehr spielt. Wenn die Handvoll Kontakte dort noch auf Signal migriert, brauche ich es eigentlich nicht mehr.

Dienste

Ähnlich wie letztes Jahr ist dieser Bereich bei mir sehr statisch. Gerade noch einen Blick auf Desktop und Smartphone geworfen. Das meiste wie z. B. den PIM-Bereich, „Cloudspeicher“ oder RSS-Synchronisation betreibe ich selbst. Der Eigenbetrieb gewährleistet bei mir die höchstmögliche Sicherheit bei gleichzeitigem maximalen Komfort, weil ich eben doch alle Vorteile nutzen kann, die sich aus „Clouddiensten“ und Synchronisation ergeben.

Bei der Suchmaschine nutze ich immer noch DuckDuckGo. Vermutlich nicht die beste Lösung hinsichtlich des Datenschutzes, aber für mich die beste Kombination aus Ergebnisqualität und Datenschutz. Eine Suchmaschine mit der ich nichts oder nur mangelhafte Ergebnisse erziele, nützt mir schließlich auch nichts. Am Desktop arbeite ich für die Navigation sehr zufrieden mit GNOME Maps, für Android nutze ich OsmAnd, wobei ich damit nicht sonderlich zufrieden bin, weil die Oberfläche überladen und die Suchfunktion unterirdisch ist.

Sünden

Nicht nur die genutzten Dienste ändern sich kaum, sondern auch der Katalog an „problematischen“ Diensten und Lösungen ist ziemlich statisch. Twitter, WhatsApp und als besonderes Ärgernis der DB Navigator bleiben mir als besonders problematische Dienste erhalten. Perspektivisch hoffe ich hier wenigstens auf WhatsApp verzichten zu können. Zudem habe ich immer noch zwei Streaming-Dienste für Serien und die DSGVO-Auskunft bei beiden hat es in sich.

Bei der Hardware meide ich den Smart Home-Trend, habe aber inzwischen einen TV von LG mit webOS Betriebssystem (was so gut wie nichts mehr mit den Palm-Wurzeln zu tun hat), von dem ich lieber nicht so genau wissen möchte, was er so an Daten sendet und Sonos Speaker, bei denen das Gleiche gilt.

Der Artikel Wasser predigen, Wein trinken? – Mein Nutzungsverhalten 2021 erschien zuerst auf [Mer]Curius

Fr, 26. November 2021, @65536@troet.cafe

Dieser dritte Teil der NixOS-Artikelserie befasst sich mit einigen und doch längst nicht allen der grossen und kleinen Tricks, die der Paketmanager Nix im Ärmel hat.

Kurz vorab: was er im Gegensatz zu den meisten anderen Paketmanagern wie apt, pacman, dnf und Flatpak leider nicht bietet, ist die Integration in GUI-Softwaremanager wie Gnome Software. Doch wer sich bereits durch die Installation und Konfiguration von NixOS gearbeitet hat, den wird das vermutlich nicht abschrecken.

Systemkonfiguration

Der auf NixOS wichtigste Weg, um Software zu installieren oder zu entfernen ist, sie in der Systemkonfiguration /etc/nixos/configuration.nix zu deklarieren. Viele Optionen, die hier gesetzt werden können, implizieren bereits die Installation der benötigten Software. Darüber hinaus können in environment.systemPackages = [ ... ] weitere gewünschte Softwarepakete gelistet werden.

Updates

NixOS wird beim Ausführen des Befehls sudo nixos-rebuild switch --upgrade nicht nur, wie aus Teil 2 bekannt, die Konfiguration neu anwenden, sondern auch alle Software auf den neuesten Stand aktualisieren.

Anstatt dies immer wieder neu auszuführen, kann auch ein automatischer Dienst dafür in der Konfigurationsdatei aktiviert werden, mit der Zeile:

system.autoUpgrade.enable = true;

nix-shell

Nix ermöglicht es, mit dem Befehl nix-shell eine Shell zu starten, in der bestimmte gewünschte Software ohne Installation zum Ausprobieren zur Verfügung steht. nix-shell -p htop öffnet diese Shell beispielsweise mit htop als zusätzlich verfügbarem Befehl. nix-shell startet in diesem Beispiel htop, ohne es systemweit oder auch nur, wie im Folgenden beschrieben, im Benutzer-Kontext verfügbar zu machen.

Auf -p dürfen auch mehrere Paketnamen folgen. Die zwei Befehle lassen sich auch zu einem verbinden: nix-shell -p htop --run htop.

nix-env

NixOS erlaubt auch das dauerhafte Installieren von Software, ohne sie in die Systemkonfiguration einzutragen. Allerdings sollte man sich gut überlegen, ob man das tun möchte, denn nix-env ist ein einzelner Befehl, der Zustand ändert, und widerspricht somit dem deklarativen Ansatz.

Bei nix-env wird nur das jeweilige Profil geändert, das bedeutet, dass nur der jeweilige Nutzer beeinflusst ist. nix-env -iA nixos.htop installiert htop somit nur für den einzelnen Nutzer. Installieren zwei Nutzer dasselbe Paket, wird es nicht den doppelten Speicherplatz benötigen, sondern derselbe Nix-Store-Eintrag einfach beiden Nutzern zur Verfügung gestellt.

Weitere Optionen sind -u '*' für Updates in dem Profil, -e htop zum deinstallieren, sowie --rollback. Führt man nix-env mit sudo bzw. mit dem Rootaccount durch, wird das Systemprofil bearbeitet. Dessen Pakete stehen allen Nutzern zur Verfügung.

nix-collect-garbage

Der Nix-Store behält alle Softwareversionen, Systemgenerationen, Profile und per nix-shell genutzte Software im Hintergrund. Mit nix-collect-garbage lässt sich ein wenig aufräumen: alles, was von keinem Profil und keiner Systemgeneration mehr gebraucht wird, wird gelöscht.

Wichtiger ist die Variante nix-collect-garbage -d. Hier werden vor dem Löschen alle Systemgenerationen bis auf die aktuelle aus den Bootoptionen entfernt. Dabei ist zu bedenken, dass man anschliessend nicht mehr zurückrollen kann. Nun resultiert das Löschen in potenziell sehr viel mehr frei werdenden Speicherplatz, weil die alten Generationen alle nicht mehr behalten werden müssen.

Beides lässt sich automatisieren. Beispielsweise wird mit der folgenden Konfiguration täglich gelöscht, was seit 30 Tagen von keiner Konfiguration genutzt wurde:

nix.gc = {
    automatic = true;
    dates = "daily";
    options = "--delete-older-than 30d";
};

Und die folgende Option (hier bei einer UEFI-Installation) limitiert die Bootoptionen auf die neuesten 10:

boot.loader.systemd-boot.configurationLimit = 10;

Ältere Generationen werden aus den Bootoptionen entfernt, und die entsprechenden Nix-Store-Inhalte können vom Garbagecollector gelöscht werden.

Optimierung

Der sehr zeitintensive Befehl nix-store --optimize dedupliziert den Nix-Store auf Dateiebene, was in einigen Fällen ebenfalls beträchtliche Speicherplatzeinsparung bedeuten kann. Auch er kann als Hintergrunddienst eingerichtet werden, mit der Konfigurationsoption

nix.optimise.automatic = true;

Links

https://nixos.org
https://nixos.org/manual/nixos/stable/
https://nixos.org/manual/nix/stable/
https://nixos.wiki
https://search.nixos.org

Fr, 26. November 2021, Caos

Als es im letzten Jahr unerwartet ins Homeoffice oder ins Homeschooling ging, brauchten in meinem Umfeld viele plötzlich einen (weiteren) Laptop. Zum Teil waren noch ältere Geräte vorhanden, die wiederbelebt werden konnten. Diese stammten teilweise noch aus der Windows-XP-Ära und unterstützten kein 64-Bit. Aus diesem Anlass habe ich etwas ausführlicher recherchiert, welche Distributionen noch für ältere Geräte einsetzbar sind, habe einiges ausprobiert und einige alte Geräte konnten so zu neuem Leben erweckt werden.

Linke Spalte v. oben n. unten: Bunsenlabs, Raspberry Pi OS Desktop, Sparky; Mitte v.o.n.u.: LMDE, Q4OS, MX; Rechts v.o.n.u.: Bodhi, Slitaz (Bildquelle: eigene Screenshots)

Die meisten grossen Linux-Distributionen haben im Laufe der letzten Jahre die Unterstützung für 32-Bit eingestellt. Vor allem seit Ubuntu mit Version 19 keine 32-Bit Hardware mehr unterstützt, sind nicht nur auch die leichtgewichtigeren Ubuntu-Flavours wie Lubuntu und Xubuntu nur noch als 64-Bit-Variante verfügbar. Der Support für die 18.04 LTS-Versionen der Flavours endete bereits im April 2021. Auch andere auf Ubuntu basierende Distributionen bieten infolgedessen keine aktuelle 32-Bit-Version mehr an. So etwa auch die aktuellste Puppy-Version (FossaPub), obwohl Puppy explizit auf ältere Hardware abzielt und extrem ressourcenschonend läuft. Einige „Puppies“, die auf älteren Ubuntu-Versionen aufsetzen, bieten aber noch 32-Bit-Varienten an und eignen sich besonders als Live-System. Ubuntu-Abkömmlinge wie Linux Lite und das aktuelle Linux Mint 20 laufen dagegen nur noch auf 64-Bit-Geräten.

Doch nicht verzagen! Ein bisschen Auswahl besteht noch und es gibt immer noch einige 32-Bit-Distributionen, die aktuell gepflegt werden und auch für einen Produktivbetrieb einsetzbar sind.

Dies sind zum Grossteil Distributionen wie Debian selbst und solche, die auf Debian basieren. Allen voran die Linux Mint-Variante LMDE4 (Linux Mint Debian Edition). Die offizielle Version gibt es mit Cinnamon-Desktop, aber die Mint-Community bietet auch fertige ISOs mit leichtgewichtigeren Desktops wie LXDE an. Für Zorin OS 16 ist die Lite-Version bislang nur im Zorin-Forum angekündigt. MX-Linux ist mit XFCE und mit Fluxbox-Desktop (nicht jedoch mit KDE) als 32-Bit-Version verfügbar. LMDE, Zorin Lite und MX sind mittelschwere Distributionen, die auf Geräten mit 3-4 GB Arbeitsspeicher noch sehr komfortabel nutzbar sind. Die Mindestanforderung ist 1 GB RAM, bei 2 GB oder weniger sind aber möglicherweise noch schlankere Distributionen von Vorteil:

• Sparky-Linux basiert auf Debian „Buster“ und bietet 32-Bit-Abbilder mit LXQt, Xfce sowie MinimalGUI und MinimalCLI. Die minimalen Systemanforderungen variieren dementsprechend zwischen 128 MB (CLI) und 512 MB (Xfce).

• Bunsenlabs ist aus CrunchBang-Linux hervorgegangen und bietet einen flotten Window-Manager (modifiziertes Openbox) und eine besondere und minimalistische Ästhetik.

• Slitaz verwendet ebenfalls Openbox als Window-Manager und eignet sich eher als Bunsenlabs auch für unerfahrenere Anwender:innen.

• Elive mit Enlightment-Desktop beschreibt sich selbst als „Fast, Beautiful and Powerful OS“. Die Schnelligkeit ist relativ unbestritten und die Schönheit können sicher nicht alle, aber bestimmt einige darin erkennen.

• Eine gute und ebenfalls anwenderfreundliche Alternative insbesondere für Netbooks ist auch Raspberry Pi OS Desktop (ehemals Raspbian).

Distributionen, die besonders ressourcenschonend sind und auch mit äusserst geringer RAM-Kapazität schnell laufen, sind Bodhi Linux und Antix. Bodhi Linux ist enorm schnell, aber hat mit dem Desktop-Unikat „Moksha“ eine eher gewöhnungsbedürftige Optik und ist umständlich in der Benutzerführung. Die aktuellste 32-Bit Version ist angekündigt als "cooming soon". Antix bietet eine Fülle von schlanker Software und eignet sich sehr gut als Livesystem, unter anderem die Menüführung ist jedoch etwas verwirrend und überladen. Sowohl Bodhi als auch Antix verbrauchen im Leerlauf aber nur ca. 100 MB RAM.

Wer es etwas konventioneller mag, sollte sich einmal Q4OS ansehen: Q4OS ist nicht nur für Windows-Nostalgiker geeignet, sondern eine wirklich solide und benutzerfreundliche Distribution, die mit Trinity-Desktop auch bei geringen RAM-Ressorcen sehr schnell läuft. Auch hier ist der initiale RAM-Bedarf nur ca. 100-150 MB.

Wenn die Möglichkeit besteht, kann vielleicht auch die Hardware noch mit RAM nachgerüstet werden. Dies ist jedoch nicht immer realisierbar: Entweder, weil passende RAM-Riegel gar nicht mehr oder nicht zu angemessenen Preisen erhältlich sind oder weil das Gerät nur bis maximal 2 GB aufrüstbar ist, was bspw. auf viele Netbooks oder ältere Thinkpads wie das T42 zutrifft.

Ein weiterer Faktor bei geringen RAM-Ressourcen ist der Einsatz von ressourcenschonenden Software-Alternativen: Wenn bspw. der Funktionsumfang der LibreOffice-Suite überdimensioniert ist, kommen Abiword als Writer- und Gnumeric als Calc-Alternative infrage. Auch Firefox schraubt leider den Arbeitspeicher-Gebrauch erheblich in die Höhe. Als Browser-Alternative ist hier u.a. Palemoon einen Versuch wert. Palemoon ist ein Fork einer älteren Firefox-ESR-Version, der zwar ein weniger modernes Design bietet, aber merklich schneller läuft. Auch wichtige Addons wie Ublock Origin sind damit nutzbar.

Etwas schwieriger gestaltet sich die Distributions-Suche für Geräte, deren Prozessor die Erweiterung PAE (Physical Adress Extension) nicht unterstützt. Zum Teil kann das durch Ergänzung des Bootparameters „forcepae“ erzwungen werden, was jedoch oft nicht zum Erfolg führt. Von den genannten Distributionen laufen LMDE, Bunsenlabs, Sparky, Antix und Bodhi auch ohne PAE bzw. bieten spezielle Abbilder für diesen Zweck an.

Weitere aktuelle Linux-Distributionen, die noch 32-Bit-Varianten anbieten, sind unter anderem: Emmabuntüs, Escuelas, Devuan, Fluxuan und Miyo (alle mit Debian-Basis). Hinzu kommen einige Distributionen, die nicht direkt oder indirekt auf Debian aufbauen wie Mageia, Artix oder VOID.

Fazit

Es gibt also auch im Jahre 2021 noch vielfältige Möglichkeiten, alte PCs oder Laptops mit 32-Bit-CPUs weiterzubetreiben oder zu reaktivieren. In noch folgenden Artikeln werde ich einige der genannten Distributionen noch etwas genauer vorstellen.

Do, 25. November 2021, Niklas

Am 31. Januar 2021 wurde ein neues Betriebssystem-Projekt gestartet. Helium, so hiess airyxOS am Anfang, sollte ein freier Nachbau von Apples proprietärem macOS werden, der viel weiter geht, als die vielen Open-Source Docks oder Themes für KDE und GNOME. Es soll tatsächlich auch original macOS Programme ausführen können, während die Unterstützung für FreeBSD Programme beibehalten wird. Linux Programme sollen über FreeBSDs Linux-Kompatibilitätsschicht ebenfalls unterstützt werden.

Damit geht das Projekt mehr in die Richtung dessen, was ReactOS für Windows ist - allerdings ohne komplett eigenen Kernel, was die Entwicklungszeit von airyxOS hoffentlich beschleunigen dürfte. Stattdessen will das Projekt auf FreeBSD aufbauen. Da Apple selbst Teile von FreeBSD für seinen Darwin Kernel verwendet, dürfte eine Kompatibilitätsschicht hier einfacher machbar sein, als beispielsweise mit Linux.

Erst vor wenigen Tagen hat airyxOS mit Version 0.3.0 "Tanuki" seine erste Beta-Version veröffentlicht. Ich habe sie ausprobiert und bin angesichts des sehr frühen Entwicklungsstadiums noch nicht voll überzeugt, aber ich denke, das Projekt hat Potenzial. Die durchaus gelungene Erfahrung mit der Bedienoberfläche wird überschattet von diversen Bugs und Treiberproblemen.

Der Desktop von airyxOS basiert auf KDE Plasma, aber das ist kaum noch zu erkennen. Das komplette Design wurde macOS nachempfunden. Einzig die KDE-typischen Systemeinstellungen und einige der Pop-ups, die beim Klick auf Tray Icons erscheinen, verraten noch, welche Software hier läuft. Alles in allem wirkt das sehr stimmig und durchdacht.

Mit dem Dock fehlt allerdings noch eine wichtige Komponente des macOS UI. Es ist so nicht ganz einfach, Programme zu starten. Es gibt nur einen Applications Ordner im Filer, von dem aus man Programme starten kann. Um geöffnete, minimierte Programme wieder hervorzuholen, gibt es ein Hot Corner in der oberen linken Ecke.

Der Filer ist der Dateimanager von airyxOS. Er wurde vom helloSystem Projekt geforkt, das wir bereits vorgestellt haben. Die beiden Systeme haben bezüglich ihrer Bedienoberfläche ja sehr ähnliche Ziele, auch wenn sie zum Teil sehr unterschiedlich umgesetzt wurden. Der erste Eindruck ist gut, ein sehr simples Programm, in dem man sich schnell zurechtfindet. Nur ein schwerwiegender Bug ist mir hier aufgefallen: Wenn man im Root Verzeichnis auf Get Info klickt, stürzt das komplette System ab und startet neu. In anderen Ordnern funktioniert das korrekt.

Die Auswahl an vorinstallierten Programmen ist noch eher klein. Hier finden sich nur Kate als Texteditor und Firefox als Browser. Mit diesen beiden hat man auf jeden Fall eine gute Wahl getroffen. Der Firefox bringt bei mir leider nach ein paar Sekunden das ganze System zum Hängen, nur ein Neustart hilft. Ich gehe aber davon aus, dass das noch behoben wird.

Bis jetzt handelt es sich bei der vorinstallierten Software komplett um native FreeBSD Programme, wie sie auch im FreeBSD Repository verfügbar wären (allerdings teilweise ins airyxOS-eigene .app Format verpackt). airyxOS soll auch quelloffene Cocoa Programme, also native macOS Programme ausführen können, wenn man diese auf airyxOS neu kompiliert. Zu gerne hätte ich das ausprobiert, aber das scheitert am nicht funktionierenden Internet, wodurch ich mir keine Repositorys zum Testen clonen kann.

Zu einem späteren Zeitpunkt will airyxOS auch Binärpakete von macOS ausführen können, wodurch auch proprietäre Software genutzt werden kann. Ob das langfristig funktionieren kann, ist fraglich, nachdem Apple auf die ARM Architektur gewechselt hat und airyxOS weiterhin auf x86_64 setzt. Solange noch Software für Intel Macs erscheint, sollte es aber machbar sein.

Ich halte airyxOS für ein höchst interessantes Projekt, das nach nicht mal einem Jahr Entwicklungszeit schon etwas auf die Beine gestellt hat, was man fast als nutzbar bezeichnen könnte. Die Version wird zwar Beta genannt, fühlt sich aber eher nach pre-Alpha an. Wenn wir airyxOS noch ein oder zwei Jahre Zeit geben, kann ich mir gut vorstellen, dass hier etwas entstehen wird, was sich insbesondere für weniger technisch versierte Nutzer gut im Alltagsgebrauch eignet.

Zur Hardwareunterstützung: Hier wird FreeBSD 12.3 eingesetzt, also sollte airyxOS mit jedem Gerät funktionieren, das auch mit FreeBSD 12.3 funktioniert. In der Praxis sieht das nicht ganz so aus, aber es kann als Anhaltspunkt dienen. Auf meinem Testlaptop, ein Lenovo 3000 N200, mit dem ich bereits einige Systeme auf FreeBSD 12 Basis erfolgreich getestet habe, will airyxOS gar nicht. Einmal bootet es in einen schwarzen Bildschirm mit Mauszeiger, beim zweiten Versuch in einen schwarzen Bildschirm ohne Mauszeiger. Ich habe dann aufgegeben.

Auf meinem Computer, ein HP Compaq aus dem Jahre 2009, bekomme ich kein Internet (weder WLAN-Stick noch Handy mit Tethering werden erkannt) und die Bildschirmauflösung ist zu gering. Mit dem neueren FreeBSD 13, das ich auf diesem Gerät normalerweise nutze, funktioniert Internet, aber die Bildschirmauflösung... ist halt einfach Nvidia... Hier konnte ich die Tests mit gewissen Einschränkungen (keine Downloads, keine Programme installieren, keine Repositorys clonen, ...) durchführen.

Natürlich behalte ich die Entwicklung von airyxOS im Blick und werde berichten, was sich mit der nächsten Version verändert und was jetzt funktioniert, womit ich heute noch Probleme hatte. Über Kommentare mit eigenen Testberichten würde ich mich freuen, vielleicht kommt der eine oder andere ja schon weiter mit dem System.

Quellen:

• https://airyx.org
• https://github.com/mszoek/airyx
• https://github.com/mszoek/airyx/releases
• https://github.com/mszoek/airyx/tree/d4895aba2d59b17368bf5d285ee03cc2f4a6e719

Do, 25. November 2021, Ralf Hersel

Endless OS 4.0 ist eine Hauptversion, die zahlreiche neue Funktionen und Verbesserungen einführt, beginnend mit einer verbesserten App-Grid-Navigation mit anklickbaren Pfeilen, die es dem Benutzer ermöglichen, einfacher zwischen den App-Seiten zu navigieren, mit Punkten, die die Gesamtzahl der Seiten und die Seite anzeigen, auf der man sich gerade befindet.

Mit dieser Version wird ein schneller Benutzerwechsel eingeführt, der es ermöglicht, einfach zu einem anderen Benutzer zu wechseln, während ein anderer Benutzer noch angemeldet ist. Die neue Funktion wurde sowohl in das Benutzermenü als auch in den Sperrbildschirm implementiert. Die Standard-Desktop-Umgebung basiert auf der GNOME 3.38-Serie.

Ebenfalls neu in Endless OS 4.0 ist das treiberlose Drucken, eine Funktion, die das Internet Printing Protocol verwendet, um Drucker im lokalen Netzwerk automatisch zu erkennen. Wird ein Upgrade von Endless OS 3.9 durchgeführt, so werden alle konfigurierten Drucker entfernt, dann wieder automatisch erkannt, können aber auch manuell wieder hingezufügt werden.

Neben anderen Änderungen enthält diese Version den Rhythmbox-Musikplayer und den Cheese-Webcam-Viewer als Flatpak-Applikationen, das Standard-Icon-Thema von GNOME sowie getrennte Repositories für Flatpak-Applikationen und den Rest des Betriebssystems, um die Leistung und Zuverlässigkeit der App-Installationen zu verbessern.

Interessant ist auch die Tatsache, dass Endless OS 4.0 nun ein optionales Metriksystem enthält, das automatisch anonyme Nutzungsstatistiken und Problemberichte an die Endless-OS-Entwickler speichert und sendet. Hierbei handelt es sich um eine optionale Funktion, die bei der Ersteinrichtung oder unter Einstellungen > Datenschutz > Metriken deaktiviert werden kann.

"In Endless OS 4 werden übermittelte Datenpunkte nicht mehr mit dem jeweiligen Computer in Verbindung gebracht, der sie übermittelt hat, sondern mit dem Vertriebskanal für diesen Computer, der durch die Build-ID des Installations-Images identifiziert wird, das in der Regel von Tausenden von Systemen gemeinsam genutzt wird", erklären die Entwickler.

Unter der Haube basiert Endless OS 4.0 auf Debian GNU/Linux 11 "Bullseye" und wird von der Linux 5.11 Kernel-Serie angetrieben. Bei dieser Version handelt es sich um eine langfristig unterstützte (LTS) Veröffentlichung, die für mehrere Jahre Software- und Sicherheitsaktualisierungen erhalten wird, sogar nach der Veröffentlichung von Endless OS 5.

Mit dieser Version können Benutzer ihr eigenes Endless OS-Installations-Image anpassen, sie unterstützt den Einplatinencomputer Raspberry Pi 4 Model B mit 8 GB RAM, L2TP und OpenConnect/AnyConnect VPNs sowie den neuen SBAT Secure Boot-Widerrufsmechanismus.

Verschiedene Funktionen, die in früheren Endless OS-Versionen vorhanden waren, wurden entfernt, z. B. die Funktion "Gemeinsames Konto", die App "Remote Desktop Viewer", integrierte Desktop-Verknüpfungen für Websites, der automatische Google Chrome-Downloader, die chinesische Zhuyin-Eingabemethode und die Unterstützung für Computer mit einer "Split-Disk"-Konfiguration.

Endless OS verwendet eine Technologie namens OSTree, um das Basissystem zu verwalten und ein read-only Root-Dateisystem zu ermöglichen. Anwendungen werden als Flatpaks installiert und verwaltet. OSTree funktioniert in etwa so, wie ein Git-Repository aktualisiert wird; das gesamte System wird synchronisiert und in einem Zug aktualisiert, so wie ein "Git Pull"-Befehl ein Quellcode-Repository aktualisiert.

Wer Endless OS ausprobieren möchte, kann die Distribution von der Website herunterladen. Es werden Live- und Installations-Images für verschiedene Sprachen und Plattformen bereitgestellt. Weitere Einzelheiten zu dieser Version finden sich in den Release Notes:

Quelle: https://support.endlessos.org/en/endless-os/release-notes/4-0

Beim Betrieb eines Servers wird der Nutzer schnell feststellen, dass er nicht der einzige ist, der gerne Zugriff auf den Ser­ver hätte. Um zu häu­fige Log­in­ver­su­che abzu­blo­cken, gibt es Fail2ban. Die­ses Pro­gramm­pa­ket durch­sucht die ent­spre­chen­den Logs und blockiert bös­wil­lige Ver­su­che, in das Sys­tem ein­zu­bre­chen. Damit gehört Fail2ban zu den Intru­sion Preven­tion-Sys­te­men. Damit kann es auch zur Auswertung von Login-Versuchen auf die eigenen WordPress-Installationen genutzt werden. Wer in die Logs schaut, wird dort ähnliche Zeilen finden:

18.217.216.181 – – [23/Nov/2021:19:32:40 +0100] „POST /wp-login.php HTTP/1.1“ 200 8408 „https://seeseekey.net/wp-login.php“ „Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:94.0) Gecko/20100101 Firefox/94.0“

Um WordPress mit Fail2ban zu verheiraten muss ein einsprechender Jail und ein Filter angelegt werden. Was mich im Vorfeld in Bezug auf WordPress irritierte war der Statuscode 200, wenn ein Login in WordPress fehlschlägt. Hintergrund ist hier das WordPress bei einem erfolgreichen Login stattdessen den Statuscode 302 (Found) nutzt. Damit kann im ersten Schritt der Jail für Fail2ban erstellt werden:

nano /etc/fail2ban/jail.d/wordpress.conf

Diese Datei wird nun wie folgt befüllt:

[wordpress]
enabled = true
port = http,https
filter = wordpress
logpath = /var/log/nginx/access.log
maxretry = 3

Anschließend muss der genutzte Filter ebenfalls angelegt werden:

nano /etc/fail2ban/filter.d/wordpress.conf

Der entsprechende Filter sieht wie folgt aus:

# Filter for WordPress login

[INCLUDES]

before = common.conf
 
[Definition]

failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).* 200

datepattern = %%d/%%b/%%Y:%%H:%%M:%%S %%z

Nach einem Neustart von Fail2ban mittels:

service fail2ban restart

ist der neue Jail aktiv. Über das Log kann die Arbeit desselben betrachtet werden:

tail -f /var/log/fail2ban.log

Damit sind die WordPress-Installationen gegen den Versuch unbefugter Logins besser abgesichert. Nach drei Fehlversuchen, wird die entsprechende IP-Adresse gesperrt, sodass weitere Verbindungsversuche von dieser IP-Adresse vom Server nicht mehr beantwortet werden.

Do, 25. November 2021, Ralf Hersel

Alpine Linux ist ein von der Community entwickeltes Betriebssystem für Router, Firewalls, VPNs, VoIP-Boxen und Server. Es wurde mit Blick auf die Sicherheit entwickelt; es verfügt über proaktive Sicherheitsfunktionen wie PaX und SSP, die verhindern, dass Sicherheitslücken in der Software ausgenutzt werden können. Die verwendete C-Bibliothek ist musl und die Basis-Tools befinden sich alle in BusyBox. Diese sind normalerweise in eingebetteten Systemen zu finden und sind kleiner als die Werkzeuge, die in GNU/Linux-Systemen zu finden sind.

Fünf Monate nach der letzten Version 3.14 ist gestern ein grosses Update dieser auf Sicherheit fokussierten GNU/Linux-Distribution erschienen. Alpine Linux 3.15 wartet mit dem Linux Kernel 5.15 LTS auf.

Zu den Highlights dieser Version gehören die Unterstützung für UEFI Secure Boot auf der 64-Bit-Architektur (x86_64), Festplattenverschlüsselung im Installationsprogramm, Support für Out-of-Tree-Kernelmodule über AKMS (inspiriert von DKMS), gzip-komprimierte Kernelmodule und SimpleDRM als standardmässiger In-Kernel-Framebuffer-Treiber für einen flackerfreien Start.

Zusätzlich zu diesen neuen Funktionen enthält Alpine Linux 3.15 einige der neuesten GNU/Linux-Technologien und Open-Source-Software, darunter die Desktop-Umgebungen GNOME 41 und KDE Plasma 5.23 (zur Installation in den Archiven verfügbar), LLVM 12, XOrg Server 21.1, Rust 1.56, Ruby 3.0, Kea 2.0, Node.js 16.13, OpenLDAP 2.6, PostgreSQL 14 sowie OpenJDK 17.

Neben anderen Änderungen fügt Alpine Linux 3.15 Unterstützung für die gleichzeitige Installation mehrerer Hauptversionen von PostreSQL hinzu, um Upgrades zu erleichtern, entfernt qt5-qtwebkit und zugehörige Pakete, verabschiedet sich vom MIPS64-Port, verwendet neue 4096-Bit-RSA-Schlüssel für Paketsignaturen und aktiviert nicht länger IPv6-Weiterleitung für radvd.

Alpine Linux 3.15 kann ab sofort von der offiziellen Website heruntergeladen werden, wo man zwischen den Varianten Standard, Extended, Netboot, Raspberry Pi, Generic ARM, Mini Root Filesystem, Virtual und Xen für die Architekturen 64-bit, 32-bit, AArch64 (ARM64), PowerPC 64-bit Little Endian (ppc64le) und IBM System z (s390x) wählen kann.

Bestehende Benutzer von Alpine Linux 3.14 können ihre Installationen mit dem Befehl apk upgrade --available auf die neue Version aktualisieren. Weitere Details finden Sie auf der Seite mit der Ankündigung der neuen Version:

Quelle: https://alpinelinux.org/posts/Alpine-3.15.0-released.html

Mi, 24. November 2021, Niklas

Das freie Betriebssystem Haiku richtet sich speziell an normale Desktop Computer und konnte schon lange bei einigen Alltagsaufgaben punkten - Das Surfen im Web gehörte allerdings nicht dazu. Mit HaikuWebKit und QtWebKit standen eine fehlerhafte aktuelle und eine hoffnungslos veraltete, aber für den damaligen Stand voll funktionsfähige Version der Apple WebKit Engine zur Verfügung.

Seit dem 20. November ist endlich auch QtWebEngine verfügbar. Die Bibliothek nutzt eine stark angepasste Version der Chromium Browser Engine und macht sie für Qt Programme nutzbar. Davon profitiert unter anderem der KDE Falkon, der gleichzeitig mit der QtWebEngine als erster darauf basierender Browser für Haiku veröffentlicht wurde.

Bis auch weitere QtWebEngine-basierte Browser verfügbar sind, dürfte es nicht lange dauern. Ein Port der Python-Bindings für QtWebEngine ist inzwischen auch vorhanden, womit der tastaturgesteuerte Qutebrowser auf Haiku portiert werden kann. Der Otter Browser, der sich auf Haiku schon lange mit der alten QtWebKit Engine grösster Beliebtheit erfreut, kann ebenfalls QtWebEngine nutzen und damit neuere Webstandards unterstützen, müsste dazu allerdings neu kompiliert werden.

Vom guten alten Konqueror, der mit seiner eigenen KHTML Engine den Grundstein für alle modernen Browser ausser Firefox gelegt hat, gibt es sogar schon einen Screenshot auf Twitter, wie er auf Haiku läuft. Konqueror nutzt standardmässig schon seit einigen Jahren QtWebEngine, das eigene KHTML wird kaum noch gepflegt.

Für Haiku ist diese Entwicklung ein riesiger Meilenstein, erlaubt es doch vielen Nutzern, jetzt komplett auf Haiku als Hauptbetriebssystem umzusteigen. Die Browsersituation wurde im Forum immer wieder als Grund genannt, weshalb man damit noch warten wollte.

Zum jetzigen Entwicklungsstand ist der QtWebEngine Port noch nicht ganz stabil. Er stürzt immer mal wieder ab, wenn man versucht, eine Webseite aufzurufen. Das ist hier allerdings nicht mehr so schlimm: QtWebEngine nutzt für jeden Tab einen eigenen Prozess. Stürzt ein Tab ab, so laufen der Browser und die anderen Tabs problemlos weiter und das Problem kann behoben werden, indem man einfach den einen Tab neu lädt. Bei HaikuWebKit und QtWebKit verhält sich das anders, ein Absturz betrifft den ganzen Browser.

Nachdem bereits so viel Arbeit und Zeit investiert wurde, um die grosse und anspruchsvolle Chromium Engine erstmal zum Laufen zu bekommen, ist es vermutlich ohnehin nur noch eine Frage von wenigen Tagen, bis auch die Abstürze behoben werden.

Ein Test auf HTML5Test.com beweist die enormen Vorzüge von QtWebEngine im Vergleich zu den verfügbaren Alternativen. Aber auch im alltäglichen Gebrauch spürt man eine erhöhte Geschwindigkeit und eine stark verbesserte Kompatibilität mit modernen Webseiten. Mit QtWebKit funktionierte zuletzt nicht einmal mehr Haikus eigenes Forum, nachdem die Forensoftware ein Update erhalten hatte.

Wer auf einen Mainstream Browser wie Brave, Edge oder Firefox wartet, muss sich allerdings weiterhin gedulden: Der Code von QtWebEngine hat erhebliche Unterschiede zum normalen Chromium, also müssten alle Anpassungen nochmal neu gemacht werden. Firefox nutzt zudem eine komplett unterschiedliche Codebasis und benötigt die GTK Bibliothek, die auf Haiku nicht verfügbar ist.

Der KDE Falkon mit QtWebEngine ist bereits im Repository von Haiku angekommen und kann bequem über das HaikuDepot oder im Terminal mit dem Befehl pkgman install falkon installiert werden.

Mi, 24. November 2021, Lioh Möller

Der Hersteller Amazon bietet seit längerem eine hauseigene Linux-Distribution zur Nutzung auf AWS an.

Diese basierte bis anhin auf einer Mischung aus Fedora und Red Hat Enterprise Linux Komponenten. Mit der nun angekündigten Preview Version 2022 ändert sich die Ausrichtung dahingehend, dass in Zukunft lediglich Fedora als Upstream zum Einsatz kommen soll. Diese Neuerung ist unter anderem dem langjährigen Fedora Community Mitglied Tom "spot" Callaway zu verdanken, der aktuell beruflich bei Amazon in der Entwicklung tätig ist.

In diesem Zusammenhang wird auch das Release Modell von Amazon Linux angepasst. Neue Hauptversionen sollen von nun an in einem 2-jährigen Rhythmus erscheinen, wobei eine Version bis zu 5 Jahre lang mit Sicherheitsaktualisierungen versorgt wird. Vierteljährlich sollen zudem Minor-Releases erscheinen, analog zu Fedora.

Unter AL2022 wird darüber hinaus SELinux standardmässig aktiviert sein.

Kunden des Clouddienstleisters werden weiterhin die Möglichkeit haben, alternative Distributionen wie Ubuntu oder Debian nutzen zu können.

Di, 23. November 2021, Norbert Rüthers

Vielleicht ist es dem einen oder anderen schon aufgefallen, das neue Raspberry Pi OS (Bullseye) unterstützt keine angeschlossene Kamera mehr. Kann das sein?  Nein es werden auch weiterhin Kameras unterstützt, nur auf eine andere Weise, was viele Probleme aufwirft.

Aufgefallen ist mir das ganze als ich am neuen Raspberry PI 2 W eine Kamera angeschlossen habe, die einfach nicht funktionierten wollte.

Als ich dann dasselbe Problem an einem Raspberry Pi 3 hatte, der ebenfalls mit Raspberry OS Bullseye lief, wurde ich nachdenklich und begann eine Recherche. Der Grund ist, dass mit Bullseye andere Kommandos verwendet werden müssen. Aus Raspistill und Raspivid wurde nun libcamera.

Im Vergleich:

Aus dem Kommando raspistill -o pic.jpg wird libcamera-jpg -o pic.jpg

Warum die Raspberry Foundation, die sonst so viel Wert auf Abwärtskompatibilität legt, das in diesem Fall nicht tut, bleibt mir verschlossen. Angeblich will man kompatibler zu Industriestandards werden. Dahinter steht Libcamera

Beschreibung auf der Webseite von Libcamera:

Eine komplexe Kamera-Unterstützungsbibliothek für Linux, Android und ChromeOS

Kameras sind komplexe Geräte, die umfangreiche Hardware-Bildverarbeitungsoperationen benötigen. Die Steuerung der Verarbeitung basiert auf fortschrittlichen Algorithmen, die auf einem programmierbaren Prozessor laufen müssen. Dies wurde traditionell in einer dedizierten MCU in der Kamera implementiert, aber in eingebetteten Geräten wurden die Algorithmen auf die Haupt-CPU verlagert, um Kosten zu sparen. Durch die Verwischung der Grenze zwischen Kamerageräten und Linux blieb dem Benutzer oft keine andere Wahl als eine herstellerspezifische Closed-Source-Lösung.
Um dieses Problem zu lösen, arbeitet die Linux-Medien-Community mit der Industrie zusammen, um einen Kamera-Stack zu entwickeln, der Open-Source-freundlich ist und gleichzeitig die Kern-IP des Anbieters schützt. libcamera wurde aus dieser Zusammenarbeit geboren und bietet moderne Kamera-Unterstützung für Linux-basierte Systeme, einschließlich traditioneller Linux-Distributionen, ChromeOS und Android.

Die offizielle Erklärung und Beschreibung zur Verwendung mit dem Raspberry findet sich auf der Raspberry Pi Homepage  Aus diesem Grund sind Millionen Tutorials, die seit dem Erscheinen des Raspberry Pi im Jahr 2012 erstellt wurden, mit dem neuen OS nicht mehr verwendbar. Ebenso sind Python Programme nicht mehr verwendbar, da die picamera Bibliothek nicht mehr verwendbar ist. Ob und wie die Raspberry Foundation in Zukunft doch noch eine Abwärtskompatibilität herstellen will, bleibt abzuwarten Die zurzeit einzige Lösung, ist das vorige Raspberry OS Buster weiterzuverwenden.

Quelle: https://libcamera.org/

Quelle: https://www.raspberrypi.com/

Mozilla hat mit Firefox 94.0.2 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 94.0.2

Mit dem Update auf Firefox 94.0.2 behebt Mozilla eine mögliche Absturzursache, welche einen größeren Teil der Linux-Nutzer potentiell betreffen konnte, sowie eine weitere mögliche Absturzursache. Außerdem wurden Performance-Probleme behoben, die für Nutzer assistiver Technologien wie einem Screenreader auftreten konnten, wenn Firefox über den Microsoft Store installiert worden ist. Dazu kommen noch diverse Anpassungen in Zusammenhang mit Firefox Suggest, einem Feature, welches nur für Nutzer in den USA aktiviert ist.

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

Mo, 22. November 2021, Ralf Hersel

Es ist viereinhalb Jahre her, seit Canonical bekannt gab, den Unity-Desktop anstelle von GNOME aufzugeben, und den Fokus auf die Cloud und IoT-Geräte zu verlagern. Die Reaktionen der Community waren damals gemischt. Einige Leute mochten GNOME, andere nicht. Diejenigen, die es nicht mochten, wechselten zu anderen Desktops wie Cinnamon, MATE, KDE und Xfce. Ubuntu-Nutzer nach 2017 wissen vielleicht nicht einmal, dass es den Unity-Desktop gibt. Aber eine Gruppe von Menschen weigerte sich, Unity loszulassen. Diese Leute gründeten ihr eigenes Ubuntu-Derivat mit dem Namen "Ubuntu Unity Remix", das später einfach als Ubuntu Unity bekannt wurde.

Die Version 21.10 von Ubuntu Unity wurde letzten Monat veröffentlicht, zusammen mit den anderen Ubuntu 21.10-Derivaten.

Die Gemeinschaft, die hinter der Distribution steht, ist allerdings sehr klein. Die offizielle Website und die Bug-Tracker sind halbtot, und es gibt kaum Updates über den Fortschritt der geleisteten Arbeit. Es ist in der Tat eine gewaltige Arbeit diesen Desktop weiterzuentwickeln. Vielleicht wäre es die bessere Strategie, Unity 7 so zu belassen, wie es ist, und nur Fehler zu beheben und kleine neue Funktionen einzuführen.

Schliesslich konnte selbst Canonical mit seinen Ressourcen die Entwicklung von Unity 8.x (das mit dem Qt-Toolkit entwickelt werden sollte) nicht abschliessen, sodass es unwahrscheinlich ist, dass ein oder zwei einzelne Entwickler in absehbarer Zeit eine ähnliche Leistung alleine erbringen können. Insgesamt ist es also eine schwierige Situation für den Unity Desktop. Und ob er in den kommenden Ubuntu-Releases installierbar bleiben wird, hängt ganz von den wenigen Freiwilligen ab, die daran arbeiten.

Quelle: https://ubuntuunity.org/post/ubuntu-unity-21.10/

Mo, 22. November 2021, Lioh Möller

In einem Changelog-Eintrag vom 17.11.2021 hat der Slackware Gründer Patrick Volkerding einen Hard-Freeze für den Entwicklerzweig der Distribution namens -current angekündigt.

Clearly we're going to have to tread more carefully for things to settle down,
so consider this RC2 and a much harder freeze. A test mass rebuild was done
here and there are no more "fails to build from source" remaining (thanks to
nobodino for some amazing and relentless testing).

Mit dem als RC2 deklarierten Stand nähert sich die Distribution der kommenden stabilen Version 15.0, welche möglicherweise noch in diesem Jahr veröffentlicht werden wird. Alle ausstehenden Fehler, bei dem Übersetzen von Paketen aus dem Quellcode konnten bereits ausgeräumt werden.

Interessierte Anwender sind eingeladen, den aktuellen Stand des Entwicklerzweiges zu testen und etwaige Schwierigkeiten bei der Installation und Nutzung zu melden.

Auch der auf Slackware aufbauende Linux-Kurs wurde bereits angepasst. Test und Feedback sind hier ebenfalls ausdrücklich erwünscht, wobei die Installation aktuell mit einem inoffiziellen -current Installationsmedium durchgeführt werden sollte.

Download: https://slackware.nl/slackware/slackware64-current-iso/slackware64-current-install-dvd.iso
Linux-Kurs Git: https://notabug.org/LiohMoeller/LinuxKurs

Ein Web Key Directory (WKD) stellt einen einfachen Weg bereit, um öffentliche GnuPG-Schlüssel für E-Mail-Adressen über eine HTTPS-Verbindung abzurufen. Es ist dazu gedacht, die Benutzererfahrung zur Nutzung verschlüsselter E-Mail-Kommunikation zu vereinfachen.

Ich bin dem ausführlichen Artikel „GnuPG: Web Key Directory (WKD) einrichten“ von Mike Kuketz gefolgt und habe ein WKD für E-Mail-Adressen unter meiner Domain „my-it-brain.de“ konfiguriert. Denn ich teile seine Auffassung:

WKD ist nach meiner Auffassung eine benutzerfreundliche Alternative für den Austausch von Schlüsseln, da Clients wie Thunderbird/Enigmail diesen Standard bereits verwenden, um beim Verfassen einer E-Mail automatisch den öffentlichen Schlüssel eines Benutzers abzurufen. Insgesamt wird der Schlüsseltausch mit WKD stark vereinfacht – das steigert insgesamt die Nutzerfreundlichkeit der E-Mail-Verschlüsselung.

https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten

Probiert es doch selbst einmal aus. Verschlüsselte E-Mail-Kommunikation wird dadurch deutlich vereinfacht.

Quellen und weiterführende Links

• https://wiki.gnupg.org/WKD