staging.inyokaproject.org

Mo, 28. Juni 2021, Marco

Rhys Davies hat auf der Discourse-Instanz von Ubuntu einen Wettbewerb für neue Desktop-Hintergründe angekündigt. Die von der Community erstellten und bewerteten Hintergründe werden in der Version 21.10 von Ubuntu, auch Impish Indri genannt, zum Einsatz kommen und hoffentlich viele Bildschirme bereichern.

Nachdem bereits für die Ubuntu-Version 19.10 die Community aufgefordert wurde, Hintergrundbilder für die Version einzureichen, möchte man dies auch in der folgenden Version wieder tun. Hintergrundbilder können seit dem 25. Juni 2021 eingereicht werden. Der Forumsthread wird am 20. August 2021 geschlossen, was auch den Start des Votings bedeutet. Sämtliche interessierten Personen werden dann darum gebeten für die aus ihrer Sicht zehn besten Hintergründe abzustimmen. Die besten zehn Grafiken werden dann in den sozialen Medien und weiteren Orten publiziert. In die Version 21.10 schaffen es die besten zwei Beiträge und können dann von allen Nutzern als Hintergrundbild gewählt werden.

Folgende Aspekte gilt es bei der Einreichung eines Hintergrundbilds zu berücksichtigen:

• Das Bild muss dein eigenes Bild sein und darf nicht von jemandem einfach genommen werden.
• Die finale Grösse muss 3840 × 2160 Pixel gross sein. Für den Upload im Forum wird allerdings eine kleinere Variante bevorzugt, damit die Ladezeit nicht negativ beeinträchtigt wird.
• Sämtliche Wasserzeichen, Namen, Logos etc. müssen entfernt werden.
• Für die Lizenz des Bildes muss entweder CC BY-SA 4.06 oder CC BY 4.03 gewählt werden. Wenn keine explizite Lizenz angegeben wird, so wird das Bild unter CC BY-SA 4.0 lizenziert.

Wer gerne mitmachen möchte, kann sich mit den unterschiedlichen Tools wie z.B. Krita, GIMP oder Inkscape an die Arbeit machen und das Bild danach im Forum hochladen.

Quelle: https://discourse.ubuntu.com/t/wallpaper-competition-for-impish-indri-ubuntu-21-10/22852

Seit etwas über einem Jahr besitze ich ein „Acer Swift 3„-Notebook mit einer Ryzen 4500U-CPU. Die erste Handlung direkt nach der Anschaffung war das Löschen von Windows 10 und die Installation von Ubuntu 20.04.

Leider habe ich es bis heute nicht geschafft den S2RAM-Modus zuverlässig zum Laufen zu bringen. Zuverlässig heißt, dass das Notebook bei jedem Zuklappen des Deckels einschläft und bei jedem Aufklappen wieder aufwacht. Das liegt vor allem daran, dass die meisten Ryzen-Notebooks (Inkl. meinem) nur den sogenannten „Modern Standby“ (Kurz „s0ix“) unterstützen und nicht den „klassischen“ S3-Modus. Normalerweise half in der Vergangenheit (z.B. bei meinem alten Lenovo T460) ein Kernel-Update auf die neueste Version, nur hier eben leider nicht, da die Kernelentwickler hier noch massiv am Nacharbeiten sind. Ich warte also seit einem Jahr darauf, dass eine Grundfunktionalität eines modernen Notebooks endlich fehlerfrei funktioniert.

Und eventuellen Fragen vorzugreifen:

Ja, ich habe auch andere Distributionen ausprobiert, wie z.B. Fedora 34. Gebracht hat es aber nichts.

Ein paar Hersteller (z.B. Lenovo) bieten in den BIOS-Einstellungen ihrer Ryzen-Notebooks an den Suspendmodus auf S3 zu wechseln, aber leider gibt es diese Option bei meinem Swift-Notebook nicht. Es gibt zwar eine Anleitung wie man die ACPI-Tabelle des Notebooks so patchen kann, dass der S3-Modus unterstützt wird, das funktioniert aber mehr schlecht als recht:

• Man sollte maximal Linux 5.10.x einsetzen, da neuere Kernelversionen bei Ryzen-CPUs auf „s0ix“ ausgelegt sind. Alle Optimierungen die Linux danach für Ryzen-CPUs erhalten hat, bleiben dabei außen vor.
• Trotz S3-Modus wacht das Notebook nicht zuverlässig aus dem Tiefschlaf auf. Je nach Lust und Laune kann es ein paar Mal gut gehen oder auch sofort abstürzen. Das ist insofern problematisch, da LUKS es einem sehr übel nehmen kann, wenn das System einfach mal abstürzt. Bei der ersten Installation von Ubuntu 20.04 hat die Installation nur bis zum ersten Suspend-Versuch überlebt. Danach war das Dateisystem irreparabel beschädigt.

Ich habe diesen Zustand jetzt knapp ein Jahr ertragen. Ich habe mir sogar die Mühe gemacht ein Kernel-Image aus gepatchten Quellen zu kompilieren (Siehe hier), aber nichts hat geholfen.

Aus diesem Grund habe ich heute Tabula rasa gemacht, Ubuntu von der Platte geworfen und Windows 10 installiert. Wahrscheinlich wird das Problem irgendwann mit einer neuen Kernelversion verschwinden, aber ich bin jetzt in einem Alter, in dem ich auf langwierige Basteleien keine große Lust mehr habe. Dazu ist mir meine Freitzeit zu kostbar geworden.

Ich finde das persönlich sehr schade, da ich seit ca. 20 Jahren Linux als mein primäres System einsetze (Seit Oktober 2004 primär Ubuntu) und in den letzten Jahren kaum noch Probleme mit Notebooks unter Linux hatte. Mein altes Thinkpad T460 (Das letztes Jahr in den Fundus meines Arbeitgebers gewandert ist und mir dort als Surf-Notebook dient) läuft seit Jahren 100% zuverlässig, ebenso das Acer-Notebook meiner Frau mit einer Ryzen 3700U-CPU. Beruflich arbeite und entwickle ich nur unter Linux und selbst die neuesten Tiger-Lake-Notebooks laufen dort vollkommen problemlos unter Linux. Gerade deshalb wurmt mich dieser Zustand auch besonders.

Aktuell spiele ich mit dem Gedanken das Swift-Notebook zu verkaufen und mir ein neues Linux-kompatibleres Notebook zuzulegen. Die Frage die sich mir stellt ist aber dabei folgende:

Ist mir das Betriebssystem meines Notebooks so wichtig, dass ich bereit wäre mindestens 800€ für ein gutes, leichtes Notebook auszugeben? Soviel würde nämlich die Tiger-Lake-Variante des Swift 3 kosten. Oder lebe ich einfach mit Windows 10 und arrangiere mich damit? Dadurch dass sich meine Anforderungen an ein Notebook in den letzten zwei Jahren massiv gewandelt haben, könnte ich prinzipiell mit Windows leben.

Android und Custom ROMs sind eine Welt für sich. Selbst erfahrene Linux-Anwender verlieren sich da gerne mal im Dschungel der Begriffe, Plattformen und Entwicklungen. Dieser Artikel stellt alle relevanten Informationen zusammen.

System & Basis

AOSP

Mit AOSP bezeichnet die Community das Android Open Source Project. Google entwickelt Android nach dem Open Core Prinzip – so wie es auch Chrome oder ChromeOS konzipiert. Um einen quelloffenen Kern legt Google viel proprietäre (also geschlossene) Google-Software und Google-Dienste. Das machen auch andere Konzerne so. Apples macOS basiert beispielsweise auf einem freien Unix-Kern, genannt Darwin.

Das besondere an AOSP ist, dass dieser freie Kern so komplett ist, dass er ohne die proprietären Erweiterungen läuft bzw. diese durch quelloffene Pendants ersetzt werden können.

Stock ROM

Im Gegensatz zu AOSP steht die Stock ROM. Darunter versteht die Community die Android-Version des Herstellers, so wie sie beim Kauf des Gerätes vorinstalliert war. Das kann eine sehr minimalistische Variante sein, die sich oberflächlich kaum von AOSP unterscheidet oder mit vielen Veränderungen und einer eigenen Oberfläche versehen sein.

Kernel & Firmware

AOSP läuft allerdings nicht „einfach so“ auf jedem Smartphone, weil die Hardware von Smartphones und Tablets nicht so normiert ist wie z. B. die Hardware von Desktop-PCs oder Notebooks. Mit einem normalen Linux-Kernel bekommt man kein Smartphone zum Laufen. Google versucht hier seit Jahren Verbesserungen zu erzielen, aber wirkliche Fortschritte gab es da bisher nicht.

Um das System lauffähig zu bekommen, benötigt man also den Kernel der Stock ROM und die so genannte Firmware. Dazu gehören Sachen wie Modem, Bootloader oder WiFi-Schnittstelle. Dabei handelt es sich um binäre Dateien, sogenannte „Blobs“, die direkt vom Hersteller bereitgestellt werden und nicht quelloffen sind.

Updates für Kernel und Firmware gibt es so lange wie der Hersteller für sein Stock ROM verteilt. Die Firmware kann bei Custom ROMs nicht über OTA-Updates verteilt werden, sondern muss vom Anwender manuell aktualisiert werden. Die Verfahren dazu unterscheiden sich je nach Hersteller.

Stellt der Hersteller den Support ein, gibt es keine Updates mehr für die Firmware und den Kernel. Meistens können auch danach noch neuere AOSP-Varianten auf altem Kernel ausgerollt werden, aber diese haben dann natürlich Sicherheitsprobleme.

Recovery

Mit Recovery bezeichnet man das Wiederherstellungssystem des Gerätes. Die Hersteller liefern meist eine funktional sehr eingeschränkte Variante aus. Einer der ersten Schritte auf dem Weg zu einem Custom ROM besteht daher aus dem Austauschen des Stock Recovery durch ein Custom Recovery. Am weitesten verbreitet sind hier TWRP und LineageOS-Recovery.

Rooten

Normale Smartphones lassen den Anwender nur mit eingeschränkten Benutzerrechten arbeiten. Im Gegensatz zum Desktop-Betriebssystem sind keine Administratorrechte (Root) für Anwender vorgesehen. Früher war Custom ROM und rooten gleichbedeutend und es wird heute noch fälschlicherweise von vielen als Synonym benutzt.

Aktuelle Custom ROMs bieten in der Regel keine Root-Rechte und das ist auch gut so, weil Root-Rechte das Gerät unsicherer machen.

Ein offenen Bootloader und eine Custom Recovery bieten aber grundsätzlich die Möglichkeit, ein Gerät zu rooten. Das kann man allerdings sowohl mit der Stock ROM als auch mit einer Custom ROM machen. Das Werkzeug hört auf den Name Magisk.

OTA

OTA bezeichnet Updates Over The Air. Damit gemeint sind Updates, die über ein integriertes Tool ausgeführt werden können, ohne das Gerät mit einem Notebook oder Desktop-PC zu verbinden oder das Update manuell über das Recovery Tool einzuspielen. Die meisten Custom ROMs bieten heute solche Update-Routinen.

Community & Projekte

LineageOS

Theoretisch kann jeder aus Recovery, AOSP und Firmware seine eigene Custom ROM erzeugen. Praktisch ist das in den letzten Jahren immer komplexer geworden und heutige Custom ROMs bestehen aus einer abgestimmten Komposition vieler Komponenten. Deshalb gibt es nur noch wenige große Projekte, die Custom ROMs entwickelt.

Das größte, älteste und wichtigste Projekt ist LineageOS, das auf CyanogenMod zurückgeht. LineageOS bildet die Basis für viele weitere Custom ROMs. Es gibt heute nur noch sehr wenige ROMs, die direkt auf AOSP aufsetzen, die meisten basieren auf LineageOS.

Damit ein Gerät auf LineageOS offiziell zur Verfügung steht, muss ein Maintainer dafür Verantwortung übernehmen. In den letzten Jahren wurde das mehr und mehr zu einem Problem, weshalb die Zahl der offiziell unterstützten Geräte kontinuierlich rückläufig ist.

GrapheneOS / CalyxOS

GrapheneOS und CalyxOS sind die zwei wichtigsten ROMs neben LineageOS. Während LineageOS eine Basis für möglichst viele Geräte bieten möchte, streben die Entwickler dieser beiden Alternativen möglichst sichere ROMs an. Die beiden ROMs werden fast ausschließlich für Google-Hardware der Pixel-Serie angeboten.

XDA Developers

XDA Developers ist die wichtigste Plattform, über die sich die Android-Community organisiert. Im Forum gibt es einzelne Unterforen für jedes auf dem Markt verfügbare Gerät. In diesen Unterforen werden Themen zur Stock ROM und Custom ROMS diskutiert.

Wenn man wissen möchte, wie verbreitet ein Gerät in der Community ist und die Unterstützung dafür abschätzen möchte, lohnt sich ein Blick in die entsprechenden Foren bei XDA.

In den Foren finden sich inoffizielle Portierungen von Custom ROMs für einzelne Geräte und Modifikationen von Stock ROMs und Custom ROMs. Das Angebot kann je nach Gerät erheblich variieren. Es ist eine kleine Community, meist bieten 3-5 Contributors pro Gerät ihre ROMs an.

Die meisten der auf XDA angebotenen ROMs sind Portierungen von LineageOS auf die jeweilige Hardware. Manchmal ist ein solcher Port auf XDA die Vorstufe zu einer offiziellen Variante, meistens bleibt es jedoch bei dem inoffiziellen Status, weil die Contributors nicht formell die Verantwortung für das Gerät übernehmen möchten.

Ob die Patches und Änderungen an LineageOS zurückgereicht werden, hängt vom einzelnen Contributor ab. Manche schätzen und pflegen die Gepflogenheiten von Open Source, andere werkeln lieber im Hinterzimmer.

---

Ich hoffe diese kleine Übersicht hilft bei der Orientierung im Custom ROM-Universum. Wenn irgendwas nicht verständlich ist oder ich etwas vergessen habe, schreibt gerne ein Kommentar, dann überarbeitete ich den Artikel.

Der Artikel Alles Wichtige über Android und Custom ROMs erschien zuerst auf [Mer]Curius

Kurz notiert: wer eine AMD GPU mit VEGA-Technologie nutzt, wird wenig Freude mit Linux 5.12.13 haben. Nach dem Kernelupdate fiel mir auf, dass der GPU-Lüfter durchgängig lief und sensors einen durchgängig hohen Stromverbrauch, auch bei abgeschaltetem Display Manager, angab. Komischerweise war der Google-Vorschlag bei "linux 5.12.13" auch sofort "gpu usage". Ein kurzer Blick ins 5.12.13 shortlog zeigt, dass es tatsächlich Änderungen an den amdgpu-Treibern gab.

Hier ist der dazugehörige Bug im Bugtracker des Kernelteams und hier der Revert im Code.

Der Autor Yifan Zhang von AMD gibt als Grund an:

Reason for revert: side effect of enlarging CP_MEC_DOORBELL_RANGE may cause some APUs fail to enter gfxoff in certain user cases.

Der Fix sollte somit in den nächsten Versionen inkludiert sein.

Der Synology DiskStation Manager ist letztlich nur ein speziell angepasstes Linux und unter der Oberfläche befindet sich viel freie Software. Seit Längerem setzt man bei nahezu allen Modellen (außer absoluten Einstiegsgeräten) auf Btrfs als Dateisystem. Mit allen Vorteilen, die dieses tolle Linux-Dateisystem mit sich bringt.

Dazu gehören natürlich die Btrfs-Prüfsummen gegen den berüchtigten „Bitrot“, aber eben auch die vermutlich bekannteste Funktion von Btrfs: Dateisystem-Schnappschüsse.

Dateisystem-Schnappschüsse lassen sich für viele Einsatzszenarien nutzen. Bei mir dienen sie zur Umgehung von Limitationen des Linux-Desktops. Linux fehlt nämlich schon immer eine einfache und leistungsstarke Backup-Lösungen wie Apples TimeMachine. Also ein Werkzeug, mit dem man die Daten auf ein Ziel (externe Festplatte oder Netzlaufwerk) schaufelt und nach der initialen Vollsicherung nur noch inkrementelle Backups anlegt sowie gelegentlich alte Versionsstände löscht.

Mit Snapshot Replication kann man einen Teil dieser Arbeit an die DiskStation auslagern und muss nur noch die Sicherung am Linux-Desktop starten.

Synology Snapshot Replication installieren und einrichten

Im Paket-Zentrum findet sich das Paket Snapshot-Replication. Das Paket zieht als Abhängigkeit noch den Replication Service auf das System.

Nach der Installation findet sich in der App-Übersicht der Menüpunkt Snapshot-Replication. In der Seitenleiste kann der Bereich Schnappschüsse ausgewählt werden.

Dort werden die angelegten Ordner angezeigt. Über den Menüpunkt Schnappschuss kann man entweder manuell einen Schnappschuss erzeugen oder einen Zeitplan anlegen, nach dem automatisch in einem festgelegten Intervall Schnappschüsse angelegt werden sollen. Dort lässt sich auch die maximale Anzahl an Schnappschüssen und ein detaillierter Löschplan festlegen.

Über den Bereich Replikation lassen sich Freigaben zudem zusätzlich auf bis zu drei lokale oder entfernte Ziele replizieren.

Einbindung in die Backup-Routine

Die Snapshot-Replication kann man theoretisch für jeden Ordner auf dem NAS machen. Im vorliegenden Fall nutze ich es vor allem für den Backup-Ordner.

Diesen binde ich als SMB-Freigabe in mein Linux-System ein. Auf diese Freigabe sichere ich mit LuckyBackup (Frontend für rsync) meine Dateien. Über die Snapshot-Replication Funktion von Synology erzeuge ich davor einen Snapshot, womit ich Schnappschüsse für jeden einzelnen Backup-Zustand erhalten.

Das ist immer noch nicht so komfortabel wie Apples Time Machine, aber viel besser als alles, was Linux sonst im Backup-Bereich zu bieten hat.

Der Artikel Synology NAS XIII – Schnappschüsse mit Snapshot Replication erschien zuerst auf [Mer]Curius

Am 29. Juni beginnt Synology mit der offiziellen Verteilung des DiskStation Manager 7. Bis das Update alle Anwender unterstützter NAS-Hardware erreicht dürfte noch einige Zeit verstreichen. Neugierige und etwas risikobereite Anwender können das Update-Paket bereits direkt über die Synology Webseite beziehen.

Das Update ist die erste größere Aktualisierung seit DSM 6.2 im Jahr 2018. Das ist nicht unwichtig, da Synology von seinen Kunden für das Paket aus Hardware und Software gekauft wird (ähnlich wie bei Apple). Die reine NAS-Hardware bekommt man in Einzelteilen deutlich preiswerter.

Beginnen wir mit dem positiven. Das Update hat reibungslos funktioniert und alle Daten und Dienste laufen wie gewünscht. Die Liste der unterstützten Hardware ist zudem lang und beinhaltet auch noch Geräte von 2014 und vereinzelt 2013. Das klingt jetzt so schnöde, aber ist natürlich eigentlich schon eine Meldung für sich wert.

Leider gilt das aber nicht für alle Nutzungszenarien. Wenn man intensiv mit den alten Apps Photos und Moments gearbeitet hat dürfte man eher entäuscht sein. Synology hat beide Anwendungen in der neuen App Synology Photos zusammen geführt und die Supportforen und Kommentarspalten sind voll von enttäuschten Nutzern.

Es scheint bei Synology momentan in der Softwareentwicklung zu klemmen. Hinter der optisch hübsch überarbeiteten GUI verbirgt sich nämlich weiterhin gut abgehangene Hardware. Das war ja bereits bei der Vorgängerversion zu beobachten.

Der Kernel trägt die Versionsnummer 4.4.180+. PostgresSQL liegt immerhin in Version 11.11 bei und nginx mit Version 1.17.10. Das sind Fortschritte, aber aktuell ist wahrlich was anderes. Das betrifft leider nicht nur die Basis, sondern auch die Synology App – sowohl für DSM als auch für Desktop- und Mobilsysteme – haben keine nennenswerten Updates erfahren.

Wirkliche Neuerungen gibt es nur um Bereich der engeren Verzahnung mit Synology-Diensten, wie z. B. dem neuen Synology C2.

Für so ein großes und langerwartetes Update nach drei Jahren Entwicklungszeit und so viel Verspätung ist das ein wenig schwach auf der Brust. Ich kann gegenwärtig meine Ansprüche noch alle gut mit meinem Synology NAS realisieren, aber man sollte die weitere Entwicklung (oder ihr Ausbleiben) aufmerksam verfolgen.

Der Artikel Synology veröffentlicht DSM 7 erschien zuerst auf [Mer]Curius

Die Linux-Paketverwaltung wird ja immer für ihre Effizienz gelobt. Es kommen Updates nur an den notwendigen Stellen und eine Bibliothek ist nur ein einziges Mal installiert und nicht Dutzende Male, wenn unterschiedliche Programme sie benötigen. Das ist nette Theorie, hilft aber nicht, wenn Entwickler sie unterlaufen.

Das openSUSE-Projekt hat für Tumbleweed die nette Tradition, auf der Mailingliste die Changelogs für neue Snapshots zu veröffentlichen. Als Beispiel möchte ich einfach mal auf den Snaptshot 20220620 verweisen. An dem Tag rollte ein Bugfix-Update für Plasma rein. Das bedeutet auf meinem System den Download und die Aktualisierung von ~200 Paketen. Beim Durchsehen des Changelogs fällt aber auf, dass die große Mehrheit der Pakete folgende Zeile im Changelog hat:

No code changes since 5.22.0

Ein Einzelfall? Nein, leider nicht. Insbesondere bei Bugfix-Releases wird bei KDE die große Mehrheit der Programme und Pakete gar nicht angefasst. Wenn ein Plasma-Release nur 5 Bugs behebt, ist das wohl auch logisch. Noch schlimmer ist das bei KDE Gear (ehm. Applications), wo das Verhältnis aktiv gepflegter Pakete zu „mitgeschleppten“ Programmen noch ungünstiger ist.

Ich persönlich finde es deshalb auch nicht vorteilhaft, wenn immer mehr Programme unter solche „Dächer“ schlüpfen. Das Problem ist bei KDE wegen der absurd hohen Update-Frequenz (bei gleichzeitig nur moderater Entwicklung) der drei Säulen – Plasma, Gear und KDE Framework – besonders ausgeprägt, aber sicher nicht darauf beschränkt. Auch bei einem GNOME-Release oder einem von MATE wird nicht jedes Paket angefasst. Genau so auf Bibliotheken-Ebene, wenn man sich z. B. Qt anschaut.

Bei manchen Programmen wie LibreOffice ist das logisch, weil die Trennung in mehrere Pakete hier künstlich durch die Distributionen herbeigeführt wurde und Updates immer alle Pakete tangieren. Bei anderen Software-Sammlungen sind das aber eigentlich eigenständige Programme ohne Interdependenzen.

Früher haben Linux-Anwender sich über Windows oder macOS lustig gemacht, wenn ein Bugfix-Update mal wieder 1,5 GB groß war. Heute sind wir selbst nicht mehr anders.

Ich finde das ärgerlich. Aus mehreren Gründen:

• Es gibt immer noch Anwender mit schmalen Internetverbindungen oder Volumen-Tarifen. Man ist mit seinem Mobilgerät ja auch mal längere Zeit nicht im heimischen Internet (1 GB im Hotel WLAN zu beziehen ist nicht erstrebenswert).
• Es kostet gerade auf älteren Systemen lange Zeit Ressourcen.
• Es ist ineffizient.
• Es konterkariert die Vorteile der Paketverwaltung
• Es erzeugt die Illusion von Softwarepflege, wo eigentlich nichts passiert.

Etwas überspitzt gesagt: Wenn das so weiter geht können wir auch die Paketverwaltung einstampfen und ähnlich wie bei FreeBSD oder macOS Updates als riesiger „Blob“ einmal alle 1-2 Monate ins System bügeln.

Die Frage, die sich mir stellt: Wer ist hier eigentlich in der Pflicht? Müsste Upstream diese ineffiziente Sammlung von Software einstellen oder müssten die Distributoren hier eingreifen? Verkürzt: Habe ich ein KDE- oder habe ich ein openSUSE-Problem?

Nachtrag 01. Juli 2020

Passend zu diesem Artikel ist die Diskussion um die sinnlosen KDE-Updates inzwischen auch auf der openSUSE-Factory Mailingliste angekommen.

Der Artikel Programm-Kompilationen – Updates für nichts? erschien zuerst auf [Mer]Curius

Mozilla hat mit Firefox 89.0.2 ein Updates seines Desktop-Browsers außer der Reihe veröffentlicht.

Download Mozilla Firefox 89.0.2

Mit dem Update auf Firefox 89.0.2 behebt Mozilla ein mögliches Einfrieren des Browsers, von dem manche Linux-Nutzer mit aktiviertem Software-WebRender betroffen waren.

In Sprachversionen, welche standardmäßig mit Yandex als Suchmaschine ausgeliefert werden, wurde das Logo von Yandex aktualisiert. Interne Anpassungen gab es außerdem bei der mitgelieferten Amazon-Suchmaschine.

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

Mi, 26. Juni 2021, Niklas

Wie bereits im letzten Monatsbericht von Haiku angedeutet, nähert sich das Projekt einer dritten grossen Beta-Version. Das System wird seit dem Jahr 2001 entwickelt und befindet sich nach wie vor in der Beta-Phase, auch wenn es für eine Vielzahl von Aufgaben bereits produktiv einsetzbar ist.

Erst 2018 wurde Beta 1 veröffentlicht und im Sommer 2020 von Beta 2 abgelöst. Dass der Release-Zyklus jedes Mal kürzer wird, lässt darauf schliessen, dass man sich möglicherweise sogar einer ersten stabilen Version nähert. Nun aber erst einmal zu Beta 3, die soll nämlich bereits diesen Juli erscheinen.

Am 24. Juli, um genau zu sein. Das ist zumindest der Plan, wie er auf der Webseite des Projekts bekannt gegeben wurde. Man weist deutlich darauf hin, dass sich der Termin auch noch verschieben kann, wenn zu diesem Zeitpunkt zu viele Fehler offen bleiben.

Bereits diese Woche soll ein Git Branch für Beta 3 erstellt werden, wodurch kaum noch funktionelle Änderungen am Code stattfinden sollen. Über die nächsten Wochen soll diese Version dann ausführlich getestet werden. Mitte Juli sollen die endgültigen ISO Abbilder gebaut und andere Release Management Aufgaben durchgeführt werden.

Zu den wichtigsten Änderungen der neuen Haiku Version gehört zweifelsohne die deutlich modernere WebKit Version für Haikus eigenen WebPositive Browser. Es war früher nicht einfach möglich, WebKit über das Repository zu aktualisieren, weshalb sich hier Änderungen von einem Jahr angesammelt haben, die Unterstützung für zahlreiche neue Webstandard hinzufügen. Zukünftig möchte man die Bibliothek häufiger aktualisieren, unabhängig vom System selbst.

Selbstverständlich werden wir die neue Haiku Version umgehend ausprobieren, sobald sie verfügbar ist und dann genaueres über die Neuigkeiten berichten.

Quellen:

• https://www.phoronix.com/scan.php?page=news_item&px=Haiku-R1-Beta-3-Release-Plan
• https://www.haiku-os.org/news/2021-06-14_haiku_r1beta3_timeline_approved/
• Bild: https://de.wikipedia.org/wiki/Datei:Haiku-logo.svg

Mi, 23. Juni 2021, Lioh Möller

Kurz nach der Veröffentlichung der Community Variante openSUSE Leap 15.3 (wir berichteten), steht nun das Enterprise Pendant in der Version 15 SP3 zur Verfügung.

Durch die Angleichung der Basis zwischen den beiden Distributionszweigen wird eine hundertprozentige Binärkompatibilität gewährleistet. Eine einfache Migration zwischen Leap und SLE sollte ebenfalls möglich sein.

Für die aktuelle Version SLE 15 SP3 wurden weitere Voraussetzungen für den reibungslosen Betrieb in Cloud-Infrastrukturen geschaffen. Das Unternehmen bietet eine entsprechende Registry mit Container-Images zur Nutzung mittels Podman oder Docker an.

Ausserdem wurde die Unterstützung für moderne Prozessoren der AMD EPYC und Intel Xeon Serie verbessert sowie die Software-Beschleunigungen mit dem NVIDIA Compute Module und CUDA (Compute Unified Device Architecture) optimiert.

Weiter Informationen finden sich in der Release-Ankündigung.

Im Sommer des vergangenen Jahres hat Mozilla sein eigenes VPN-Angebot gestartet. Mittlerweile kann das Mozilla VPN in acht Ländern gebucht werden, darunter seit April in Deutschland. Bereits in Kürze fällt der Startschuss für Österreich, Schweiz sowie weitere Länder.

Mozilla VPN in 13 Ländern

Im Juli 2020 ist das Mozilla VPN offiziell gestartet. Bislang ist das Angebot in den USA, Kanada, Großbritannien, Neuseeland, Singapur und Malaysia, seit April außerdem in Deutschland und Frankreich verfügbar. Über die Veröffentlichung in Deutschland und Frankreich hatte ich bereits knapp drei Monate vor Start weltweit als erstes berichtet.

Jetzt Mozilla VPN nutzen

Nun liegen mir auch Informationen für den nächsten Schritt der Ausrollung vor. Demnach wird das Mozilla VPN bereits in Kürze in den folgenden Ländern starten: Österreich, Schweiz, Belgien, Italien sowie Spanien.

Der exakte Start-Termin ist noch nicht bekannt. Sobald der Marktstart in diesen Ländern erfolgt ist, wird man es natürlich hier auf dieser Seite lesen können.

Das Mozilla VPN

Für das Mozilla VPN arbeitet Mozilla mit dem schwedischen VPN-Anbieter Mullvad zusammen und verspricht neben einer sehr einfachen Bedienung eine durch das moderne und schlanke WireGuard-Protokoll schnelle Performance, Sicherheit sowie Privatsphäre: Weder werden Nutzungsdaten geloggt noch mit einer externen Analysefirma zusammengearbeitet, um Nutzungsprofile zu erstellen.

Das Mozilla VPN besteht aus über 400 Servern in mehr als 30 Ländern, hat keine Bandbreiten-Beschränkung und erlaubt die Verbindung auf bis zu fünf Geräten. Es stehen Apps für Windows 10, Apple macOS, Ubuntu, Android sowie Apple iOS zur Verfügung.

Die Kosten belaufen sich auf 9,99 Euro für einen Monat. Bei Bindung für sechs Monate beträgt der Monatspreis 6,99 Euro (30 Prozent Ersparnis), bei Bindung für ein Jahr werden 4,99 Euro pro Monat fällig (50 Prozent Ersparnis). Eine Rückerstattung ist innerhalb von 30 Tagen nach dem Kauf möglich.

Der Beitrag Mozilla VPN: Start in Österreich, Schweiz und weiteren Ländern steht bevor erschien zuerst auf soeren-hentzschel.at.

Ich habe mich heute selbst ge-DoS-ed, und dabei wieder 1-2 wichtige Lektionen gelernt, die ich euch nicht vorenthalten möchte. Gut, technisch gesehen war es kein DoS, da der Service nicht in die Knie ging. Andrerseits musste das System heute ein vielfaches (d.h. 190000-fache dessen, was es sonst so im Schnitt macht) leisten, und da's auch irgendwie lustig war gibt's jetzt einen Blogpost dazu.

Damit man das Ausmaß versteht ein paar Hintergrundinfos: Seit geraumer Zeit bastle ich auf Basis des ZigBee-Protokolls an meinem SmartHome. Ich persönlich bin absolut kein Fan von Cloud-basierten Diensten, daher übernimmt die Steuerung des Systems mein Homeserver, auf welchem wiederum diverse Dienste abgeschottet laufen.

Die Kommunikation mit den ZigBee-Geräten übernimmt dabei ein ConBee II USB-Stick, einfache Steuerungsaufgaben (Ein/Aus von Lampen bspw.) werden über die vom Hersteller verfügbare Software erledigt.

Komplexere Aufgaben übernimmt eine Node-RED-Instanz. Node-RED ist eine Browser-basierte Entwicklungs- und Laufzeitumgebung, mit der man so gut wie alles machen kann. Im Prinzip läuft da ein NodeJS-Server mit Weboberfläche, auf der Flows (d.h. Abläufe) definiert und ausgeführt werden können. Es gibt ein paar vorgefertigte Nodes die viele Dinge erleichtern, dann eine gefühlte Million Drittanbieternodes, als auch die Möglichkeit Code direkt in JavaScript zu schreiben. Ich bin kein Fan von JavaScript, aber Node-RED macht die Entwicklung und das Deployment schon sehr einfach. Nutzen wir unter anderem aus diesem Grund auch in der Firma bei Industrieanlagen. Man kommt damit sehr schnell an Ergebnisse, und ich muss zugeben, dass ich auch privat einfach keine Lust mehr habe riesen Projekte aufzusetzen wenn man einfach nur ein paar Sachen automatisiert haben will. Und dafür ist Node-RED echt genial.

Das hat mir aber noch nicht gereicht, nein, ich wollte auch die Möglichkeit haben über gewisse Dinge auch unterwegs benachrichtigt werden zu können (bspw. wenn ein Paket ankommt). Und da mir Sicherheit schon so halbwegs wichtig ist, laufen Benachrichtigungen von Node-RED an mein Smartphone über den Signal Messenger.

Und da fängt der Spaß jetzt an. Damit nicht jeder über Signal mit meiner Node-RED-Instanz kommunizieren kann, habe ich eine Allowlist implementiert. Da ist aktuell nur meine Mobilfunknummer hinterlegt, und wenn ich eine Anfrage via Signal schicke, bekomme ich auch eine Antwort. Das habe ich gestern Abend noch getestet, war glücklich damit, und ging guten Gewissens ins Bett.

Heute Morgen dann, als ich bereits außer Haus war, kam mir die wunderbare Idee auch mal zu sehen ob der Filter auch für Geräte funktioniert, die nicht in der Allowlist hinterlegt sind. Also das Zweithandy gezückt, Die Nachricht „Test“ getippt, auf Senden gedrückt, und die Antwort abgewartet. Relativ genau 1,6 Sekunden später kam dann ein „You're not allowed to use this service.“ zurück, und für weitere 1,6 Sekunden hatte ich auch ein Lächeln im Gesicht. Und dann kam die gleiche Meldung nochmal, und weitere 1,6 Sekunden später nochmal.

Kein Stress dachte ich mir, Signal hat ja ein Rate Limit eingebaut, das geht vielleicht 100 Nachrichten oder so gut, und dann werd ich eh blockiert. Denkste.

Nach 150 Nachrichten habe ich dann langsam mal das Smartphone stummgeschaltet, und nach den ersten 500 Nachrichten kam ich ins Zweifeln, ob es tatsächlich ein Rate Limit gibt. Nach 1000 Nachrichten war klar: Es gibt keines.

Exakt 19056 Nachrichten später hatte ich dann auch den Fehler gefunden: Wenn man in Signal eine Nachricht sendet, bekommt man standardmäßig auch eine Nachricht ohne Inhalt zurück. Ich konnte nicht herausfinden, wofür genau (ist das die Benachrichtigung dass die Nachricht zugestellt wurde, oder die Benachrichtigung, dass die Nachricht gelesen wurde?), aber das war die Ursache.

Nachdem ich mein „Test“ abgesendet hatte, hat Node-RED die Nachricht empfangen, und mit einem „You're not allowed to use this service.“ quittiert. Das hat wiederum mein Smartphone mit einer Inhaltslosen Nachricht quittiert, was Node-RED wiederum zum Anlass nahm, mir den gleichen Text nochmal zu schicken. Und das eben den ganzen Tag. Die Fehlerbehebung bestand entsprechend darin innerhalb meines Node-RED-Flows zu schauen ob die via Signal übertragene Nachricht überhaupt einen Inhalt hat, und falls nicht kann die Nachricht direkt verworfen werden.

Gelernt habe ich also:

• Dass Signal entgegen der üblichen Meinungen (und ich habe echt viele Threads dazu gefunden) zumindest bei mir absolut kein Rate Limit anwendet. Ich kann anscheinend den ganzen Tag senden was ich will ohne dass das irgendeine Auswirkung hätte. Und wenn es SPAM ist, ist es halt so
• Unterwegs nicht testen, ob der Code, den man am Abend zuvor geschrieben hat, auch wirklich funktioniert, das macht man zu Hause
• Code spätestens dann testen, wenn man den Spaß live schaltet
• Akkus in Smartphones enorme Sprünge gemacht haben, ebenso wie die verbauten CPUs. Nachdem Signal verhindert hat, dass sich Android in den Deep Sleep begibt, habe ich nach 9 Stunden gerade mal 57% Akku verbraten. Finde ich, dafür dass das Gerät den ganzen Tag aktiv war, in Ordnung
• Signal relativ problemlos mit mehreren tausend Nachrichten zurechtkommt. Allerdings auch nur so lange, wie man nicht den ganzen Thread dazu öffnet
• Es gut ist, dass mein Node-RED-Service eine Ablaufzeit für verschwindende Nachrichten bei Signal erzwingt. Die Nachrichten, die ich von meinem SmartHome bekomme, sind immer nur kurze Zeit relevant (Paket angekommen, Licht noch an, Bewegung erkannt, whatever), und werden in der Regel nach einem Tag automatisch gelöscht. Das war übrigens der ausschlaggebende Punkt in diesem Anwendungsfall auf Signal anstelle von Matrix zu setzen
• Der Spaß deutlich weniger Datenvolumen verbraucht hat als erwartet. Der komplette bisherige Monat wird mir mit 5MB angezeigt, was bei über 19000 Nachrichten deutlich weniger ist, als ich erwartet habe, zumal da auch noch ein paar Mediendateien mit drin sind.

Dieser Beitrag ist eine deutsche Übersetzung von Great Invitations (CC BY-SA 4.0). Mit wir o.ä. ist dementsprechend das Prosody-Team gemeint, welches diesen Artikel ursprünglich verfasst hat.

Es gibt derzeit zwei Arten von Servern im XMPP-Netzwerk: solche mit öffentlicher Registrierung und solche ohne.

Die Server, die eine Registrierung unterstützen, erlauben es in der Regel, Konten über das Web oder mit einem XMPP-Client (XEP-0077) zu erstellen. Das Problem ist, dass dies den Server für die ganze Welt öffnet.

Selbst wenn CAPTCHAs und andere Schutzmechanismen genutzt werden, wird selbst der sorgfältigste Administrator eines öffentlichen XMPP-Servers irgendwann feststellen, dass Spammer Konten auf seinem Server registrieren.

Die Alternative ist, die Registrierung zu deaktivieren und alle Konten manuell einzurichten. Dies funktioniert für einen privaten Server, bedeutet aber zusätzlichen Aufwand und zusätzliche Verantwortung des Administrators. In vielen Fällen bedeutet es auch, dass der Admin dafür verantwortlich ist, das Passwort des Benutzers zu generieren und einen Weg zu finden, es irgendwie sicher an den Benutzer zu senden.

Aber halt! Es gibt einen dritten Weg! Das Konzept von Internetdiensten, die nur für eingeladene Benutzer zugänglich sind, gibt es schon seit langer Zeit. Als Google Gmail auf den Markt brachte, war es bekanntlich nur möglich, sich per Einladung anzumelden. Heute hat Gmail über 1,5 Milliarden Nutzer! Vielleicht sind die Ambitionen als Prosody-Administrator nicht so hoch, aber es gibt einige eindeutige Vorteile für einen einladungsbasierten Registrierungsablauf:

• Server-Administratoren können Einladungen erstellen und müssen niemals das Passwort eines anderen Benutzers generieren oder sehen.
• Einladungs-Links nutzen natürlich den Server, von dem sie stammen, so dass der Benutzer nicht manuell einen Server in seinem Client auswählen muss (eine überraschend häufige Schwierigkeit für Leute, die mit dem Konzept von föderierten Messaging-Netzwerken nicht vertraut sind).
• Benutzer-zu-Benutzer-Einladungen können vom Administrator aktiviert werden, was ein natürlicheres und vertrauensvolleres Wachstum ermöglicht als eine offene Registrierung.
• Eingeladene Benutzer können die Person, die sie eingeladen hat, direkt in ihrer Kontaktliste finden, was eine weitere Hürde beseitigt, mit der sich Erstbenutzer normalerweise auseinandersetzen müssen.
• Missbräuchliche Accounts (z.B. solche, die Spam versenden) können zu einem einladenden Benutzer zurückverfolgt werden, und dieser Benutzer kann daran gehindert werden, weitere Einladungen zu erstellen.

Die Erfahrung mit dem einladungsbasierten Registrierungsablauf, den wir für Snikket entwickelt haben, hat gezeigt, dass Einladungs-Links ein wirklich einfacher Weg sind, um Leute auf einem Server anzumelden, ohne offene Registrierung aktivieren zu müssen. Daher haben wir uns entschlossen, dies auf das weitere XMPP-Ökosystem zu übertragen.

Screenshot der neuen Prosody-Einladungsseite

Unser Ziel war es, die Einfachheit des Snikket-Registrierungsablaufs so weit wie möglich beizubehalten und gleichzeitig zu ermöglichen, mit anderen Clients auf so vielen Plattformen wie möglich zu arbeiten. Dies ist nicht so einfach, wie man vielleicht denkt!

Wie es funktioniert

Wir haben die Clients in drei Kategorien eingeteilt, basierend darauf, was sie unterstützen:

• “Magischer” Installationslink - im Moment wird dies nur von einigen Apps im Google Play Store (Conversations und yaxim) unterstützt. Eine Anfrage wurde bei F-Droid eingereicht, um zu sehen, ob wir diese praktische Funktion auch auf FOSS-App-Stores ausweiten können.
• xmpp: URIs mit Einladungs-Tokens (derzeit von Conversations, yaxim und Siskin unterstützt).
• Manuelle Einrichtung von Konten

Die Funktion “magischer Link” bietet den nahtlosesten Ablauf. Der Benutzer folgt dem Link, um die App zu installieren, und das Invite-Token wird nach der Installation auf magische Weise von der App erkannt. Das heißt, der Ablauf ist kurz und reibungslos:

Der Ablauf für magische Installationslinks

Wenn dieser Ablauf nicht unterstützt wird, ist die nächste bevorzugte Option, dass der Benutzer den Einladungs-URI mit der von ihm gewählten App öffnet. Die Schwierigkeit dabei ist, dass der Client zuerst installiert werden muss, da der Browser sonst nicht weiß, wie er den URI behandeln soll. Das bedeutet, dass der Benutzer zum Herunterladen und Installieren des Clients umgeleitet wird und dann zurück auf die Einladungsseite gehen muss:

Der Ablauf der Einladungs-URIs

Wenn der Client keine Einladungs-URIs unterstützt, wird der Benutzer durch die Online-Registrierung seines Kontos geführt (Prosody validiert das Invite-Token) und muss dann nur noch seine Anmeldedaten in den Client eingeben, nachdem er ihn installiert hat:

Der Ablauf der manuellen Registrierung

Mit diesen drei Abläufen können wir einen Einladungslink in einen angemeldeten Benutzer überführen, egal für welche Plattform- und Client-Kombination sich der Benutzer entscheidet.

Daten über Clients werden in mod_register_apps gesammelt und können auch von Server-Administratoren konfiguriert werden (die vielleicht eine bestimmte Gruppe von Apps empfehlen wollen, die sie für die Verwendung auf ihrem Server unterstützen wollen).

Wie man es einrichtet

Alle Module befinden sich in unserem Community-Repository¹ und sollten mit Prosody 0.11 und trunk funktionieren.

Einfach einen Blick auf das Beispiel-Konfigurations-Snippet in mod_invites werfen, um loszulegen! Wenn man fertig ist, fügt man vielleicht noch mod_invites_api hinzu, um sich eine URL mit Lesezeichen zu erstellen, die auf Knopfdruck eine Einladung für ein neues Konto generieren kann.

Vieles davon ist sehr neu, daher freuen wir uns über Feedback. :)

Und nicht vergessen: Wer einen einfachen Prosody-Server für eine kleine Gruppe einrichten und Funktionen wie diese und mehr fertig konfiguriert haben möchte, sollte einen Blick auf Snikket werfen.

Die Zukunft

Es gibt viele Möglichkeiten, auf diesem System aufzubauen. Wir hoffen, dass mehr Clients Token-URIs implementieren, und vielleicht finden ein paar schlaue Leute sogar heraus, wie man den “magischen Link”-Ablauf auf weitere Plattformen ausweiten kann. Wir denken auch, dass die Einladungs-API, die es vertrauenswürdigen Dritten erlaubt, Einladungen für einen Server zu generieren, einige sehr interessante Einsatzmöglichkeiten bietet.

In der Zwischenzeit freuen wir uns auf Feedback und Beiträge und darauf, von den Erfolgsgeschichten beim Onboarding zu hören :)

---

1. Prosody Community Modules ↩︎

Mo, 21. Juni 2021, Lioh Möller

Kurz nach dem Erscheinen des Release Candidates von Rocky Linux 8.4 steht nun die erste stabile Version der RHEL-kompatiblen Enterprise Distribution zur Verfügung.

"Wir haben uns vorgenommen, ein freies, offenes, gemeinschaftliches Enterprise-Betriebssystem zu entwickeln, das vollständig kompatibel zum Upstream Enterprise Linux ist. Was wir aufgebaut haben, ist so viel mehr: eine Community."

Gregory Kurtzer, Executive Director, Rocky Enterprise Software Foundation

Das Projekt bietet Installationsmedien für die Architekturen x86_64 und ARM64 (aarch64) an. Zusätzlich stehen Container-Images auf Docker Hub und Quay.io bereit.

Detaillierte Hinweise zu den Neuerungen finden sich in den Release Notes.

Das gesamte Team bedankt sich bei allen engagierten Helfern, Testern und Sponsoren die diese Version erst möglich gemacht haben.

Quelle: https://forums.rockylinux.org/t/rocky-linux-8-4-available-now/3015

Mit meinen Plädoyers für LTS-Distributionen scheine ich bei manchen immer wieder einen Nerv zu treffen. Einige scheinen in ihrer RR-Blase vergessen zu haben, wo die Mehrheiten sind.

Anlass für diesen kleinen Kommentar ist die Feststellung bei Heise, dass Desktop-Anwender bei Debian doch eher Testing verwenden, worauf sich schon in den Kommentaren Widerspruch äußerte. Das möchte ich mal aufgreifen, um hier ein paar Grundannahmen zu äußern, die ich für Linux/Linux-Anwender veranschlage und den meisten Blog-Artikeln zugrunde lege.

Zahlen sind natürlich bei Linux ein schwieriges Thema, weil die wenigstens Distributionen wirklich Zahlen erheben und jene, die das tun (wie z. B. Ubuntu) diese nicht transparent teilen, sondern lediglich in Form von Berichten. Man kann also anders als Apple oder Microsoft schlecht sagen, dass x. Mio. Anwender dieses oder jenes Release nutzen. Unstrittig ist, dass die Zahlen von Distrowatch nichts taugen.

Relativ unstrittig dürfte auch sein, dass die meisten „normalen“ Anwender von Updates tendenziell genervt sind und eher selten den Mehrwert sehen. Die meisten machen Updates erst, wenn die Systeme sie penetrant daran erinnern oder sie gar einfach erzwingen. Nicht umsonst haben Apple und Microsoft automatische Updates im Hintergrund im Dienste einer allgemeinen Systemsicherheit in den letzten Jahren zum Standard erklärt.

Schauen wir uns mal an, welche Distributionen groß sind. Das sind jetzt „gefühlte“ Werte. Sie ergeben sich aus den Zahlen der Distributionen, der Resonanz in den Medien, der Größe der Communitys und der subjektiv wahrgenommenen Präsenz im öffentlichen Raum. Ich mache mal ganz bewusst keine nummerische Liste, sondern gehe alphabetisch vor.

• Arch Linux
• Debian
• Fedora
• Manjaro
• Mint
• openSUSE
• RHEL & Clone
• Ubuntu

Ich behaupte mal ganz dreist: Alle anderen Distributionen kann man von den Marktanteilen unter „ferner liefen“ eingruppieren. Bei den meisten darf man wohl sogar bezweifeln, dass sie vierstellige Nutzerzahlen haben. Und auch diese Liste dürfte eine erhebliche Spannbreite aufweisen. Vermutlich sind Ubuntu und Mint mit weitem Abstand führend.

Man muss kein Zahlenakrobat sein, um die Mehrheit der Nutzer bei stabilen Distributionen zu sehen. Das müssen jetzt nicht gleich extreme LTS-Varianten sein. Vermutlich aktualisieren die meisten Nutzer irgendwo in einem Intervall zwischen den 12 Monaten, die bei Fedora das Maximum sind, bis zu den 24 Monate zwischen zwei Ubuntu LTS-Varianten. Das ist übrigens auch der Zyklus den Windows 10 und macOS vorgeben.

Eines dürfte jedenfalls auch klar sein: Manjaro und Arch haben nicht mehr Anwender als die hier gelisteten stabilen Varianten. Selbst dann nicht, wenn man Debian und openSUSE wegen ihrer rollenden Zweige dazu zählt.

Nur mal so als Hinweis, weil viele Poweruser und Entwickler manchmal vergessen, wo die Masse der Anwender sind. Das soll natürlich niemanden daran hindern, RR-Distributionen zu nutzen.

Manche Entwickler/Projekte sollten sich allerdings schon fragen, ob ihr Zyklus mit 3-4 Monaten Sinn ergibt und welche Anwender sie damit erreichen, oder ob dahinter nur die Unfähigkeit zur Produktpflege steht. Einer der häufigst gelesenen Artikel hier im Blog ist ausgerechnet: Kommentar: KDE und die Distributionen – zwei Antipoden. Im Grunde genommen kann man Veröffentlichungen ab einer gewissen Häufigkeit und bei fehlender Pflege der Vorgängerversionen auch gleich bleiben lassen und den Distributoren einfach Git-Snapshots zur Paketierung überlassen.

Der Artikel Kommentar: Linux – Die Mehrheit nutzt kein Rolling Release erschien zuerst auf [Mer]Curius

Ein qualitativ hochwertiges Custom ROM mit langfristiger Pflege zu finden, ist gar nicht so einfach. Aktuelle Firmware-Dateien noch viel weniger. Beides ist notwendig für den leidlich sicheren und Datenschutz-freundlichen Betrieb eines Android Smartphones.

Über den allgemeinen Zustand der Custom ROM Entwicklung habe ich mich kürzlich ja bereits hinreichend ausgelassen. Aber man muss ja weiter machen und deshalb heute ein paar eher praktische Empfehlungen. Offizielle LineageOS-Builds gibt es zur Zeit nur noch für wenige Geräte und diese sind meistens ziemlich alt. Deshalb muss man für neuere Modelle (und in der Custom ROM-Szene ist das Samsung Galaxy S10 noch verhältnismäßig neu) in den Weiten von XDA Developers suchen.

Kriterien für ein Custom ROM sind bei mir:

• Offene Verwaltung des Quellcodes des Custom ROMs
• Aktuelles Android
• Aktueller Patchlevel von AOSP und Hersteller
• Aktives SELinux
• Aktive Verschlüsselung
• Keine vorinstallierten Google-Dienste

Ich habe dafür längere Zeit die Variante von modpunk genutzt, aber wie man im entsprechenden Thread sehen kann, entwickelt modpunk eher erratisch. Nach langen Phasen ohne Updates kommt dann ab und mal wieder was. Das soll jetzt definitiv nicht als Vorwurf missverstanden werden, denn bei einem in der Freizeit entwickelten Projekt kann man keine Updates erzwingen.

Vor Kurzem hat Tim Zimmernann (Linux4) sein eigenes Build veröffentlicht (die GitHub-Projektseite findet sich hier). Das möchte ich hier allen Besitzern eines Gerätes der S10-Familie ans Herz legen. Der Entwickler veröffentlicht nicht nur regelmäßig Updates (1-2x pro Monat), sondern hat auch nervige Bugs wie die Probleme mit der WPA3-Verschlüsselung behoben. Updates laufen unproblematisch OTA über die entsprechende Lineage-Routine. Da er auch der offizielle Maintainer des Galax Tab S6 Lite für LineageOS ist, habe ich die Hoffnung noch nicht aufgegeben, dass das Samsung Galaxy S10 doch noch ein offizielles Build bekommen könnte.

Updates für Android sind das eine, Updates für die Firmware aber ebenso wichtig und bei Custom ROMs oft nicht ganz trivial. Deshalb ist es umso schöner, dass Linux4 hier auch Bundles über die Projektseite anbietet. Linux-Anwender können dann mit heimdall ziemlich unproblematisch die Firmware ihrer Geräte aktualisieren.

Dazu muss das Samsung-Smartphone nur in den Download-Mode versetzt werden und dann folgender Befehl in der Konsole ausführt werden.

$ cd </Pfad/zum/Download>
$ heimdall flash --CM cm.bin --DQMDBG dqmdbg.img --KEYSTORAGE keystorage.bin --RADIO modem.bin --CP_DEBUG modem_debug.bin --PARAM param.bin --BOOTLOADER sboot.bin --UH uh.bin --UP_PARAM up_param.bin 

Wie immer besteht natürlich bei Custom ROMs immer ein gewisses Restrisiko am Ende ein Soft bricked oder gar Hard bricked Gerät zu habe, aber ich habe damit sehr positive Erfahrungen gemacht.

Der Artikel Android Custom ROM und Firmware für Samsung Galaxy S10 erschien zuerst auf [Mer]Curius

Unbemerkt von vielen greift sich das Oligopol aus Verlagen und Wissenschaftsdienstleistern nach und nach die wichtigsten Literaturverwaltungslösungen, um ihre Ausrichtung hin zu Daten-Analyse-Firmen zu stärken. Nach EndNote folgte Papers, nun ist Citavi an der Reihe. Übrig bleiben nur noch Open Source-Lösungen.

Die Literaturverwaltung war damals einer der Gründe für meinen Wechsel zu macOS. Die Möglichkeiten von Linux waren mir einfach zu beschränkt, denn Literaturverwaltungen sind bei Linux-Programmen oft nicht mehr als digitale Literaturlisten oder „Literaturverwaltungs-Bronzezeit“, wie ich 2015 konstatierte. Ich schätze umfassende Literaturverwaltungssysteme wie Citavi, weil sie meinem Arbeitsstil sehr entgegenkommen. Ich weiß aber natürlich auch, dass man das anders sehen kann. Schon damals hatte ich allerdings Datenschutz und individuelle Datensouveränität bei Forschungsvorhaben im Blick.

Die letzten gallischen Dörfen fallen

Die Welt war damals aber noch „in Ordnung“. Mendeley gehörte zwar schon zu Elsevier, aber EndNote wurde noch von Thompson Reuters entwickelt und Citavi von einer Firma namens Swiss Academic Software GmbH. Die größte Kröte bei Citavi war damals „nur“ die Bindung an Windows als einziger Plattform. Mit Papers gab es für macOS eine „Geheimwaffe“, die so taten, als ob sie ein kleines unabhängiges Start-up wären. Sicher alles keine Open Source Software und natürlich kommerziell agierende Unternehmen, aber eben doch verhältnismäßig kleine Player in einem vielfältigen Markt. Die Angebotslage war nicht perfekt, aber man konnte guten Gewissens damit arbeiten.

Kurz darauf übernahm Clarivate Thompson Reuters und Digital Science führte sein mittelmäßig erfolgreiches Cloud-Produkt ReadCube mit der Neuerwerbung Papers (das man erstaunlicherweise von Springer Nature erwarb) unter dem gemeinsamen Label „ReadCube Papers“ zusammen. Hinter Digital Science steht die Holtzbrinck Publishing Group und neben ReadCube Papers hat man einige Produkte für den Wissenschaftssektor im Angebot. Am bekanntesten unter den Produkten von Digital Science dürfte hier Dimensions sein, das sich anschickt, eine Alternative zu Scopus und Web of Science (WoS) zu werden. vor einigen Tagen erhielt ich eine Ankündigung, in der mir das lang versprochene Citavi Web offeriert wurde. Nach dem Login sah die URL so gar nicht nach Citavi aus und eine kurze Recherche ergab, dass Citavi im Februar von QSR International erworben wurde. Von der Firma hatte ich vorher noch nichts gehört, aber die englischsprachige Wikipedia weiß dazu etwas mehr:

QSR International is the developer of qualitative data analysis (QDA) software products, NVivo, NVivo Server, Interpris and XSight. These are designed to help qualitative researchers organize and analyze non-numerical or unstructured data. Qualitative research is used to gain insight into people’s attitudes, behaviours, value systems, concerns, motivations, aspirations, culture or lifestyles. It is used to inform business decisions, policy formation, communication and research. Focus groups, in-depth interviews, content analysis and semiotics are among the many formal approaches that are used, but qualitative research also involves the analysis of any unstructured material, including customer feedback surveys, reports or media clips.

Artikel: QSR International, zuletzt abgerufen am 20.06.2021

Das liest sich nicht nach einer Firma, der ich mit meiner Literatur- und Wissensverwaltung das Herzstück meiner wissenschaftlichen Arbeit überlassen möchte.

---

Exkurs: Geschäftsmodelle von Wissenschaftsverlagen & Co

Mit Elsevier und Springer Nature sind schon zwei wesentliche Akteure im Markt der Wissenschaftsverlage genannt. Clarivate (die nun auch ProQuest übernommen haben) und Holtzbrincks Digital Science sind weitere Akteure unter den Wissenschaftsdienstleistern. Sie alle eint ein sehr „spezielles“ Geschäftsmodell, das sich stark simplifiziert folgendermaßen erklären lässt:

Öffentliche finanzierte Forschung wird publiziert in kommerziellen Zeitschriften, die wiederum zu horrenden Summen von öffentlich finanzierten (Universitäts-)Bibliotheken erworben werden müssen, um ihrem Auftrag in der Zurverfügungstellung von Literatur nachzukommen. Dafür streichen die Verlage eine Rendite von bis zu 30% ein.

Mancher mag jetzt denken, wo sind denn hier die Drittmittel, von denen immer alle reden. Nun, die gibt es eigentlich nicht! Es gibt in Deutschland keine Tradition von privatwirtschaftlicher Wissensförderung. Die Unternehmen haben Grundlagenforschung gerne für Lau (und zahlen dafür nicht mal nennenswert Steuern…). Das was heute meistens Drittmittel genannt wird, hieß früher „Zweitmittel“. Damit waren jene Mittel gemeint, die zwar nicht aus dem eigenen Haushalt stammten, aber dennoch von der öffentlichen Hand in Form von z. B.DFG und BMBF-Förderung. Im neoliberal dominierten Diskurs wollte man das „cooler“ klingen lassen und schaffte die Zweitmittel als Begriff ab, um die Illusion einer nennenswerten Drittmittelförderung zu kreieren. Im Prinzip ist das für den Steuerzahler ein „Linke Tasche, rechte Tasche“-Phänomen.

Weil die Nachwuchswissenschaftlicher im „Ich bin Hanna“-System sich die Zeitschriften, in denen sie publizieren, faktisch nicht selbst aussuchen können, gibt es in vielen Wissenschaften zwangsläufig ein Oligopol aus relevanten Verlagen.

Die Geschäftsmodelle der Datendienstleister im Wissenschaftssektor sind nicht ganz so einfach zu erklären, aber laufen auf ähnliches hinaus. Ohne diese Dienstleister können Einrichtungen ihre Fördermittelanträge nicht mehr ausreichend belegen und haben keine Grundlage für notwendige bibliometrische Verfahren. Diese sind aber mitunter die Grundlage für zahlenbasierte Evaluationsverfahren bei Neuberufungen und Mittelvergabe.

---

Verlage entdecken neue Geschäftsmodelle

Gleichzeitig entdecken die Verlage neue Geschäftsmodelle. Einerseits einfach um neue Märkte zu erschließen, andererseits sicherlich auch, um sich abzusichern, falls die Open Access-Initiative tatsächlich eine Transformation des Publikationssystems schaffen sollte. Die Kriegskassen der Verlage und Wissenschaftsdienstleister sind dank satter Renditen gut gefüllt. Dem Steuerzahlen sei Dank.

Nachdem man bemerkt hat, auf was für einem „Datenschatz“ man durch seine dominante Stellung im Publikationssystem sitzt, möchte man diesen nun heben. Tracking auf den Plattformen der Verlage gehört da ebenso dazu wie die Aushebelung des bisher auf Anonymität ausgerichteten Authentifizierungssystems über Shibboleth. Wer sich für das Thema interessiert, dem seit die Podcast-Folge 197 des Open Science Radio mit Renke Siems und Björn Brembs ans Herz gelegt.

Diese Daten lassen sich natürlich perfekt ergänzen, wenn man nicht nur die Publikationsdaten hat, sondern auch noch Informationen darüber, wie die Forscher so arbeiten. Diese Daten befinden sich zu einem nicht unerheblichen Teil in den Literaturverwaltungen der Wissenschaftler. Also exakt jene Softwarelösungen, die nicht nur seit Jahren auf Cloud-Lösungen umgestellt werden, sondern auch sukzessive in die Hände der großen Player geraten.

Welche Alternativen bleiben?

Um dem wenigstens ein ganz kleines bisschen zu entgehen, bleiben wirklich fast nur noch die klassischen Open Source-Lösungen. Am prominentesten sind hier vermutlich Zotero und JabRef. Daneben gibt es natürlich noch zahlreiche weitere Lösungen, vor allem im Umfeld der BibTex-Manager. Auch hier sollte man aber Abstand von allfällig offerierten Clouddiensten nehmen. Wer weiß schon, wer als nächstes übernommen wird und wohin die Daten dann fließen.

Gemessen den EndNote, Citavi oder ReadCube ist das mit enormen funktionalen Rückschritten verbunden, aber es bleibt einem keine Alternative, sofern man nicht die Hoheit über seine eigene wissenschaftliche Arbeit preisgeben möchte.

Der Artikel Literaturverwaltung: Es bleiben nur noch Zotero und JabRef erschien zuerst auf [Mer]Curius

Fr, 18. Juni 2021, Niklas

helloSystem ist ein relativ junges Projekt mit dem Ziel, das Look-and-Feel einer etwas älteren Mac OS X Version nachzubauen, aber quelloffen und transparent, mit viel Einblick ins System, aber trotzdem sehr einfach zu bedienen. Wir haben es im März bereits genauer vorgestellt.

Mit der neuen Version wird helloSystem von FreeBSD 12.1 auf FreeBSD 12.2 als Basis aktualisiert. Mit dem Update wurde die Grösse der ISO Datei erheblich verkleinert, von 1,7 GB bei Version 0.4.0 auf 1,27 GB. Ausserdem gibt es jetzt ein MTP Programm, um auf Dateien von Android Handys zugreifen zu können.

Besonders viel ist bei helloSystems eigenen Programmen passiert. Das System Menü wird jetzt automatisch aktualisiert, wenn Ordner oder Programme hinzugefügt oder entfernt werden. Im Filer Dateimanager gibt es jetzt die Tastenkombinationen Command+Shift+G, Command+Pfeil hoch und Command+I, um das "Go to:" Menü zu öffnen, in den übergeordneten Ordner zu wechseln und Informationen über eine Datei oder einen Ordner anzuzeigen. Mit dem neuen Spatial Mode wird jeder Ordner im Filer in einem neuen Fenster geöffnet. Ausserdem werden bereits geöffnete Filter Fenster jetzt nach vorne geholt, anstatt den gleichen Ordner mehrmals zu öffnen.

Zu den vorinstallierten Programmen wurde QHexEdit unter den Entwicklungswerkzeugen hinzugefügt. In den Tastatureinstellungen können jetzt Varianten von Tastaturlayouts ausgewählt werden. Das Programm initgfx wurde aktualisiert und Unterstützung für die Grafikkarten AMD Radeon HD 6630M/6650M/6750M/7670M/7690M hinzugefügt, die in Macs aus dem Jahr 2011 vorkommen.

Neu ist ausserdem die Funktion Windowshading, bei der alles ausser der Titelleiste eines Programms ausgeblendet wird, wenn man doppelt auf diese klickt. Ausserdem werden Tastatureinstellungen jetzt über Neustarts hinweg gespeichert und es ist für jeden Nutzer möglich, das Debugging Programm truss auszuführen. Wenn ein Laptop geschlossen wird, wird es jetzt automatisch mit ACPI S3 sleep in das Standby geschaltet.

Filer zeigt Datenträger jetzt auf dem Desktop an und verwendet ihren korrekten Namen. In der Sidebar von Filer werden Datenträger zuerst angezeigt und es gibt die Möglichkeit, Datenträger auszuwerfen. Ausserdem hat der Filer neue Kontextmenü-Einträge für das Öffnen von Dateien und Ordnern als Root erhalten und die Icon-Grösse in der Kachel-Ansicht wurde optimiert.

Für Programme, die mit dem pkg Befehl installiert wurden, werden jetzt automatisch Platzhalter .app Ordner angelegt, damit diese Programme auch im Menü auftauchen. Die Audio-Lautstärke kann jetzt in der Menü-Leiste eingestellt werden. Das "Create Live Media" Tool zeigt jetzt nur noch Release Versionen an. Des Weiteren wurde eine Dokumentation für das Hinzufügen von eigenen Kontextmenü Einträgen im Filer erstellt.

Ausserdem ist jetzt auch ein Menü für den Desktop verfügbar, wenn kein Filer Fenster geöffnet ist. Filer zeigt die Reihen in der Detailansicht jetzt in verschiedenen Farben an. Neu ist ein "open" Befehl im Terminal und das Theme des Betriebssystems wurde leicht optimiert, wobei man hier offen für weitere Verbesserungen ist.

In der neuen helloSystem Version wurden insgesamt 20 kleinere und grössere Fehler behoben, auf die ich hier nicht näher eingehen würde, da das den Rahmen sprengen würde.

Ab sofort können die Komponenten der helloSystem Desktopoberfläche über Weblate von der Community übersetzt werden, sodass diese zukünftig in verschiedenen Sprachen verfügbar sein werden. Alle helloSystem Kernkomponenten lassen sich ab sofort auch auf Linux kompilieren, aber ihre Funktionsfähigkeit könnte dort eingeschränkt sein, da es auf FreeBSD als Basis optimiert ist. Ausserdem kann helloSystem jetzt in Verbindung mit KWin statt Openbox als Window Manager verwendet werden.

Die neue Version kann von den GitHub Releases des Projekts heruntergeladen werden und ist ausschliesslich für 64Bit x86 Hardware verfügbar. Aufgrund der vielen Änderungen könnte sich ein erneuter Versuch jetzt lohnen, wenn euch helloSystem letztes Mal noch nicht voll überzeugt hat.

Quelle: https://github.com/helloSystem/ISO/releases/tag/r0.5.0

Im berühmten Artikel „Linux ist nicht Windows“ wird thematisiert, dass Windows-Kompetenz keine allgemeine IT-Kompetenz ist und nicht einfach 1:1 auf Linux übertragen werden kann. Aber fördern wir überhaupt IT- oder wenigstens allgemeine Linux-Kompetenz oder nicht eher Distributions-Kompetenz?

Ich habe einen ziemlich distanzierten Blick auf Distributionen und Desktopumgebungen. Beides wird maßlos überbewertet. Bevor jetzt ein wütender Kommentar kommt, bitte weiterlesen.

Meiner Meinung nach kochen alle Linux-Distributionen letztlich nur mit Wasser. Das bedeutet, sie können letztlich nur paketieren, was Upstream da ist und die zunehmende Komplexität der Systeme und vielfältige Kooperationen haben in den letzten 15 Jahren eine hohe Standardisierung erzeugt. Eigenentwicklungen und wirklich individuelle Lösungen kann man an einer Hand abzählen. Und selbst die funktionieren oft ähnlich, weil sie die gleichen Aufgaben erfüllen sollen. Das ist wie in der Evolution. Unterschiedliche Arten auf dem Globus, die eine ähnliche ökologische Nische besetzen, prägen vollkommen unabhängig voneinander ähnliche Merkmale aus.

Das Gleiche gilt für Desktopumgebungen. Letztlich haben doch alle ähnliche Konzepte. Es gibt Fenster, in denen Programme laufen. Irgendwo gibt es eine Übersicht der aktuell laufenden Programme (Dock, Fensterleiste o.ä.) und einen Starter (Startmenü, Launchpad etc.). Dazu noch ein bisschen „Gedöns“ für Benachrichtigungen, Systemdienste, Einstellungen. Wir haben dieses Konzept mit Anpassungen inzwischen sogar auf Smartphones und Tablets übertragen. Ob das ein objektiv gutes Konzept für die Bedienung ist oder wir uns einfach kollektiv daran gewöhnt haben, darüber kann man sicher trefflich streiten.

Das so rational herunter zu brechen, beruht auf abstrakter IT- oder Linux-Kompetenz – dazu muss man bei weitem kein Informatik-Studium hinter sich haben. Wenn man mit vielen Distributionen parallel arbeitet und daneben mit macOS und Windows, merkt man mit ein wenig Abstraktionsvermögen schnell, was die funktionalen Grundlagen jedes Systems sind. Dazu muss nicht d-bus verstanden haben, aber das 1×1 der Partitionierung schon. Nur um mal ein paar praktische Beispiele zu bringen. Diese Kenntnisse kann man dann auf jedes neue Systeme anwenden und hat eine deutlich flachere Lernkurse.

Umso mehr überraschen mich immer wieder die entrüsteten Kommentare, die darauf beharren, dass doch alles ganz unterschiedlich sei. Noch mehr überraschen mich in den Supportforen Anwender, die vom Wechsel von Ubuntu zu Debian überfordert sind.

Mir stellt sich die Frage, ob wir als Linux-Community nicht letztlich denselben Fehler wiederholen, den alle Anwender mit Windows machen. Anstelle allgemeine Kompetenz zur Funktionsweise von Betriebssystemen bzw. Linux-Distributionen zu vermitteln (in Wikis, Foren, Blogs etc. pp), lehren wir die Neueinsteiger (und Nicht-mehr-so-Neueinsteiger) die Funktionsweise und Abläufe einer einzelnen Distribution. So wie der Windows-Nutzer dann nur Windows kann, schaffen wir Linux-Anwender, die nur Ubuntu (oder jede beliebige andere Distribution) können.

Werden wir damit unserem eigenen Anspruch eigentlich gerecht? Ein Anspruch, der vor vielen Jahren in solchen Artikeln wie dem oben verlinkten „Linux ist nicht Windows“ formuliert wurde. Ein Anspruch, den viele in Diskussionen wie eine Trophäe vor sich her tragen: „Wir“ vermitteln doch schließlich mehr als nur Klickfolgen-Kompetenz.

Und wenn dem so ist, stellt sich die Frage, warum wir das so machen? Haben wir als – in der Regel – um eine Distribution herum organisierte Community Angst vor mündigen Anwendern, die bei Bedarf schnell das System wechseln können? Verweigern wir in den meisten Supportforen die Unterstützung für „fremde“ Distributionen, um die Anwender im „Walled Garden“ der eigenen Community zu halten? Dienen wir als Community damit eigentlich „Linux“, den „Anwendern“ oder nur unserem eigenen „Walled Garden“?

Der Artikel Fördern wir Betriebssystem-Kompetenz oder Distributions-Kompetenz? erschien zuerst auf [Mer]Curius

Mozilla hat Firefox 89.0.1 veröffentlicht und behebt damit mehrere Probleme der Vorgängerversion, einschließlich einer Sicherheitslücke.

Download Mozilla Firefox 89.0.1

Mit dem Update auf Firefox 89.0.1 behebt Mozilla durch Deaktivierung der erst mit Firefox 89 eingeführten Shared Font List, welche den Speicherverbrauch reduzieren und die Performance verbessern sollte, mehrere Probleme in Zusammenhang mit der Darstellung von Schrift auf Websites, von denen manche Nutzer von Windows und Linux betroffen waren. Auf macOS sind keine Probleme bekannt, hier blieb die Option aktiviert.

Auf macOS konnte es bei Verwendung eines externen Bildschirms zu einem Flackern beim Scrollen kommen. Grund hierfür ist ein Bug in einem AMD-Grafikkartentreiber. In Firefox 89.0.1 wurde dies durch die Deaktivierung von WebRender für die Darstellung der Scroll-Leisten auf macOS behoben. Auf Windows und Linux blieb die entsprechende Option aktiviert.

Dafür gab es für manche Linux-Nutzer Performance- und Stabilitätsprobleme in Zusammenhang mit der Software-WebRender-Implementierung. Diese wurde für betroffene Nutzer deakiviert.

Ebenfalls ein Problem, von dem manche Linux-Nutzer betroffen waren, waren fehlerhafte Scroll-Leisten bei Verwendung mancher GTK-Themes.

Unter Windows haben manche Screenreader nicht mehr korrekt mit Firefox interagiert. Zur Behebung hat Mozilla die mit Firefox 89 erst eingeführte „Pseudo-Oberfläche“ deaktiviert, welche zu Beginn des Startvorgangs angezeigt wurde, um so die gefühlte Performance des Firefox-Starts unter Windows langsameren Systemen zu verbessern.

Die DisableDeveloperTools-Unternehmensrichtlinie zur Deaktivierung der Entwicklerwerkzeuge funktionierte nicht mehr korrekt und wurde repariert.

Außerdem wurde mit Firefox 89.0.1 eine als moderat eingestufte Sicherheitslücke behoben. Von dieser waren ausschließlich Nutzer des Betriebssystem Windows betroffen, welche nicht WebRender als Rendering-Backend von Firefox verwenden.

Schließlich wurden noch einige Übersetzungen aktualisiert.

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

Di, 15. Juni 2021, Niklas

Am 28. Mai hat der leitende Entwickler von SerenityOS (wir haben es vorgestellt), Andreas Kling, auf seinem privaten Blog angekündigt, dass er bei seiner Arbeitsstelle gekündigt hat, um in Zukunft in Vollzeit an dem Projekt zu arbeiten. Möglich ist das aufgrund der vielen Spenden, die er für seine Arbeit erhält.

Die Spenden belaufen sich aktuell auf 2000 US-Dollar pro Monat. Zusätzlich erhält er 150 US-Dollar von YouTube sowie 100 US-Dollar Einnahmen aus dem Verkauf von Merchandise Artikeln. Das reiche zwar noch nicht ganz aus, um ihn und seine Familie zu finanzieren, doch es sei genug, um ausprobieren zu können, wie es sich weiter entwickeln wird, erklärt Kling auf seinem Blog.

Er betont, dass es nicht sein Ziel ist, durch das Projekt reich zu werden. SerenityOS wurde gestartet, um nach einem Aufenthalt in einer Suchtklinik wieder eine richtige Beschäftigung zu haben. Dass es jetzt tausende Menschen gibt, die das Projekt unterstützen und sehen wollen, wie es sich entwickelt, war anfangs nicht geplant.

Zum Abschluss des Blogposts verspricht der Entwickler, weiterhin sein Bestes zu geben, um das Projekt voranzubringen. Es sei eine Ehre, sich in dieser Position zu befinden. Er gibt in dem Beitrag nochmal einen Rückblick auf die letzten zwei Jahre mit dem SerenityOS Projekt und erzählt einiges aus vorherigen Beschäftigungen.

Früher hat Andreas Kling für Apple und Nokia am WebKit Projekt gearbeitet, einer Rendering Engine für Browser. Aufgrund seines Interesses für low-level Programmierung hat er dann aber angefangen, sich mit einem Parser für ELF Executables, einem Browser für Ext2 Dateisysteme und einem kleinen GUI Framework mit Event Loop zu beschäftigen.

Diese drei Bestandteile waren der Grundstein für das SerenityOS Betriebssystem. SerenityOS soll ein Betriebssystem werden, das für die Erledigung alltäglicher Aufgaben geeignet ist. Und nach meinem Review von vor zwei Monaten kann ich sagen, dass es auf einem sehr guten Weg zur Alltagstauglichkeit ist, auch wenn aktuell noch sehr viel fehlt.

Das SerenityOS Projekt hat sich sehr schnell weiterentwickelt und mit dieser Ankündigung des leitenden Entwicklers kann man davon ausgehen, dass es in Zukunft noch deutlich schneller gehen wird. Wir werden SerenityOS natürlich im Auge behalten und berichten, wenn es wieder spannende Neuigkeiten gibt.

Quelle: https://awesomekling.github.io/I-quit-my-job-to-focus-on-SerenityOS-full-time/

Mo, 14. Juni 2021, Niklas

Haiku, der quelloffene Nachfolger von BeOS, bereitet sich fleissig auf die dritte Beta-Version vor und veröffentlicht im "Haiku activity report - May 2021" vom 3. Juni wieder alle wichtigen Neuigkeiten rund um das Projekt. Wir haben Haiku im April ausführlich vorgestellt.

Besonders die Nutzer von Laptops dürften sich über die Nachricht freuen, dass in Zukunft die WLAN-Treiber von FreeBSD Version 13 eingesetzt werden sollen. Die Arbeiten daran wurden nun begonnen. Bislang werden die Treiber von FreeBSD Version 12 verwendet. Mit der Aktualisierung kommt Unterstützung für neue WLAN-Chips dazu.

Auch die Implementierung von TCP selective ACK wurde vervollständigt. Diese wurde im Rahmen eines vergangenen GSoC Projekts begonnen. Hierdurch wird die Performance von TCP Verbindungen bei verlustreichen Verbindungen (insbesondere WLAN) verbessert. Der wavelanwifi Treiber und die FireWire Unterstützung wurden deaktiviert, da diese auf moderner Hardware keine Rolle mehr spielen und nie korrekt funktioniert haben. Weiter wurden mehr Details zu den ifconfig Ausgaben bei 10 Gbps Verbindungen hinzugefügt.

An den HID Input Treibern wurde ebenfalls gearbeitet. Zunächst wurde ein experimenteller Treiber für I2C Eingabegeräte (hauptsächlich Touchpads) geschrieben, doch dieser funktioniert nicht zuverlässig. Als Konsequenz daraus wurde der bestehende USB HID Treiber überarbeitet und der HID Teil herausgetrennt, um die gleichen HID Treiber auch in Verbindung mit I2C Eingabegeräten und Bluetooth verwenden zu können.

Ausserdem wurden Fehler im XHCI Treiber behoben, um die Fehlerbehandlung zu verbessern. Der intel_extreme Treiber wird aktualisiert, um Geräte neuer als Sandy Bridge zu unterstützen. Die Arbeiten daran dauern allerdings noch an. Ein kleiner Teil der Änderungen wurde schon in den Haiku Quellcode übernommen, die grösseren Änderungen müssen aber zuerst von mehreren Nutzern ausprobiert werden.

Natürlich wurde nicht nur an den Treibern gearbeitet. Auch das User-Interface wurde an ein paar Stellen verbessert. Die BControlLook API hat eine neue Methode, um die Breite der Scrollbar zu ermitteln. Das wird zum Beispiel in HaikuWebKit verwendet, wo keine nativen Scrollbars benutzt werden, damit diese trotzdem wie native aussehen. Vorher musste eine richtige BScrollBar erzeugt werden, um daraus die Breite abzuleiten.

Es wird weiterhin an der Verbesserung der BTextView Implementierung gearbeitet. Auch beim vorinstallierten Text-Editor StyledEdit gab es Optimierungen, die einige Probleme mit dem Text Area Management beheben. Ausserdem wurde die Open-Source Schriftart Spleen neu zur KDL Console hinzugefügt und wird bei Bildschirmen mit grösserer Auslösung als 1080p automatisch verwendet, weil die Standardschrift hier zu klein ist.

Mithilfe statischer Analysetools werden immer wieder Fehler im Quellcode von Haiku aufgedeckt. Diesen Monat wurden einige Fehler in Format Strings im userlandfs BeOS Dateisystem Treiber gefunden und behoben. Auch versetzte Strukturen in cpu.h und verschiedene Definitionen in Funktionen an verschiedenen Stellen konnten optimiert werden. Beim NFS4 Dateisystem Treiber wurden verbesserte Debugging Möglichkeiten hinzugefügt.

Auch am Build System wurde gearbeitet. Es wurden einige Fehler im Konfigurationsscript behoben. Das Repository mit Paketen zum Erstellen von Haiku Images wurde modernisiert. Hier kommen Pakete aus dem HaikuDepot zum Einsatz, allerdings mit festen Versionen, um Probleme durch zu neue HaikuDepot Pakete zu vermeiden. Auch einige Dockerfiles für das Cross-Compiling von Haiku Programmen auf Linux wurden aktualisiert.

Die Sicherheit von Haiku wurde ebenfalls verbessert. Es wurde erstmals eine Implementierung für Stack Protection in Haiku eingebaut. Damit lassen sich Buffer Overflow Bugs erkennen. Viel wichtiger ist aber, dass damit Schadcode erkannt werden kann, der versucht, sich ins System einzuschleusen. Es wurde ausserdem ein Fehler behoben, der dem Kernel erlaubt hat, auf den Userland RAM zuzugreifen und den SMAP Schutz zu umgehen.

In den Einstellungen wurden Probleme mit den Eingabegeräteeinstellungen behoben, die im Zusammenhang mit einer Änderung an der API entstanden sind. Die Bluetooth-Einstellungen werden jetzt in einer BMessage gespeichert, statt als Rohdaten. Das macht spätere Änderungen am Speicherformat einfacher.

Weiter wurde die C und POSIX Kompatibilität verbessert. Es wurden Änderungen am features.h Header vorgenommen, um C11 besser zu unterstützen. Das Header versteckt einige Systemfunktionen, die nicht im C oder POSIX Standard definiert sind, um eine strikte Konformität zu gewährleisten. Ab sofort kann es auch bestimmte Funktionen aktivieren oder deaktivieren, die nur in bestimmten Versionen der C Sprache vorkommen.

Die Implementierung von ioctl wurde auch überarbeitet. Haiku lässt hier mehr Freiheiten, als andere Betriebssysteme, was manchmal zu undefiniertem Verhalten in Verbindung mit den Variadic Argumenten geführt hat. Die Funktion wurde so umgebaut, dass jetzt Structs und Macros statt Variadic Argumenten verwendet werden.

Am Paketsystem wurden einige Aufgaben vom ersten Start des Systems auf das Kompilieren verlagert. Dadurch wird Haiku beim ersten Start etwas schneller. Im Blog Post wird ausserdem die Portierung von Haiku auf die RISC-V Architektur angesprochen. Darüber haben wir bereits einen ausführlichen Artikel veröffentlicht. Der Entwickler Máximo Castañeda, bekannt als madmax, ist dem Haiku Entwicklerteam offiziell beigetreten und hat Commit Zugriff auf das Git Repository erhalten.

Quellen:

• https://www.haiku-os.org/blog/pulkomandy/2021-06-03-haiku_activity_report_may_2021/
• Bild: https://de.wikipedia.org/wiki/Datei:Haiku-logo.svg