ubuntuusers.de

29. Juli 2017

New Tab Override ist meine Lösung zum Ersetzen der Seite, welche beim Öffnen eines neuen Tabs in Firefox erscheint. Bei mittlerweile um die 120.000 Nutzern stellt sich natürlich die Frage: wird es eine WebExtension geben, welche auch mit Firefox 57 und höher kompatibel sein wird? Die Antwort ist: Ja. Und mit diesem Artikel möchte ich eine erste Vorschau geben, welche zeigt, dass sich New Tab Override auch in Zukunft nicht auf das absolute Minimum beschränkt, sondern weiter denkt. Diese Vorschau gibt einen Einblick auf die Nutzung des neuen Berechtigungs-Systems von Firefox, welches dem Nutzer die volle Kontrolle gibt.

Was ist New Tab Override?

Seit Firefox 41 ist es nicht länger möglich, die Seite anzupassen, welche beim Öffnen eines neuen Tabs erscheint, indem die Einstellung browser.newtab.url über about:config verändert wird. Da diese Einstellung – wie leider viele gute Dinge – in der Vergangenheit von Hijackern missbraucht worden ist, hatte sich Mozilla dazu entschieden, diese Einstellung aus dem Firefox-Core zu entfernen. Glücklicherweise hat Mozilla nicht einfach nur die Einstellung entfernt, sondern gleichzeitig auch eine neue API bereitgestellt, welche es Entwicklern von Add-ons erlaubt, diese Funktionalität in Form eines Add-ons zurück in Firefox zu bringen. New Tab Override war das erste Add-on, welches diese Möglichkeit zurückgebracht hat, und ist damit das Original. Mittlerweile hat New Tab Override um die 120.000 Nutzer und wurde im Dezember 2016 sogar auf dem offiziellen Mozilla-Blog vorgestellt.

Download New Tab Override für Firefox

Firefox 57: nur noch WebExtensions erlaubt

Im November dieses Jahres wird Mozilla Firefox 57 veröffentlichen und damit wird Firefox nur noch WebExtensions erlauben. Da New Tab Overrride derzeit noch eine SDK-basierte Erweiterung ist, ist New Tab Override in seiner jetzigen Form auch nicht kompatibel mit Firefox 57 und höher.

New Tab Override als WebExtension, Entwicklung auf GitHub

Die gute Nachricht: ja, eine WebExtension-Version ist bereits in Arbeit. Die WebExtension wird mindestens Firefox 55 voraussetzen, also nicht kompatibel mit Firefox ESR 52 sein. Updates für ältere Firefox-Versionen waren von meiner Seite aus aber sowieso keine mehr geplant.

Die Entwicklung wurde umgezogen und findet nun auf GitHub statt. Damit sind auch andere Entwickler und Übersetzer herzlich eingeladen, sich zu beteiligen, um New Tab Override noch besser zu machen. Dies wird in Zukunft auch der Ort sein, an dem Nutzer Fehler melden können – nur bitte nicht mehr für die aktuelle Version 6.0, denn Version 6.0 ist abgeschlossen und wird keine weiteren Updates mehr erhalten. New Tab Override 7.0 ist eine komplette Neuentwicklung.

Feature-Vorschau: Berechtigungs-System

Eine der großartigen Neuerungen von Mozillas neuem Erweiterungs-Standard der WebExtensions ist das Berechtigungs-System. New Tab Override 7.0 wird davon in idealer Weise Gebrauch machen.

Eine Option von New Tab Override ist es, beim Öffnen eines neuen Tabs automatisch die neusten Nachrichten aus der Welt rund um Mozilla anzuzeigen. Diese News kommen, naheliegenderweise, von diesem Blog.

Zugegeben, diese Option nutzen nur die wenigsten meiner Nutzer. Typischerweise wird die Lieblings-Suchmaschine oder eine andere Webseite als neuer Tab genutzt. Da das Auslesen des Feeds eine Berechtigung erfordert, könnte New Tab Override diese Berechtigung direkt bei der Installation verlangen, womit die Erweiterung die Erlaubnis hätte, jederzeit ungefragt Daten von meinem Blog zu laden. Das hat New Tab Override nie getan, vor den WebExtensions hätten Firefox-Erweiterungen das aber heimlich tun können und dafür keine Erlaubnis benötigt!

Sollte New Tab Override also diese Berechtigung von jedem Nutzer der Erweiterung verlangen, obwohl nur ein Bruchteil diese Funktion überhaupt nutzt?

Ich denke: Nein! Darum können Nutzer, welche dieses Feature nutzen möchten, nach der Installation von New Tab Override die Erlaubnis dafür explizit gewähren.

New Tab Override 7.0 Vorschau

Noch besser: wurde die Berechtigung einmal erteilt, kann diese jederzeit über die Einstellungen von New Tab Override wieder entzogen werden. So behält der Nutzer die volle Kontrolle! Wurde beispielsweise die Feed-Funktion einmal getestet und für nicht sinnvoll befunden, einfach die Erlaubnis wieder entziehen und damit der Erweiterung die Möglichkeit nehmen, heimlich etwas zu tun, was sie sowieso nicht tut – aber wir alle wissen: Vertrauen ist gut, Kontrolle (haben) noch besser. Und dafür investiere ich gerne zusätzlichen Aufwand in die Entwicklung.

New Tab Override 7.0 Vorschau

Erscheinungs-Termin New Tab Override 7.0

New Tab Override 7.0 wird im August erscheinen und automatisch per Update an alle bestehenden Nutzer verteilt werden. Informationen zum vollständigen Funktionsumfang von New Tab Override 7.0 werden mit der Veröffentlichung bekannt gegeben.

Der Beitrag Vorschau auf New Tab Override 7.0 (WebExtension) erschien zuerst auf soeren-hentzschel.at.

28. Juli 2017

Bild von TeroVesalainen via pixabay / Lizenz: CC0 Public Domain

Vor kurzem hat das openSUSE-Projekt eine neue Minorversion seiner LTS-Variante Leap herausgegeben. In den Kommentarspalten beschweren sich Endanwender (die lieber dutzende inhaltsgleiche Kommentare verfassen, als einmal vernünftig zu recherchieren) über die vermeintlich verkürzte Supportdauer im Vergleich zum herkömmlichen openSUSE früherer Jahre. Befeuert wird dies durch eine niveaulose Linux-Medienlandschaft, in der mehrheitlich Pressemeldungen abgeschrieben und Klickzahlen generiert werden. Neue Version hier, super-duper Test dort. Manchmal fraglich ob der Redakteur überhaupt schon über die Installation von Ubuntu hinaus ist

Darum nochmal in aller Deutlichkeit: Minorversionen von Enterprise Versionen verkürzen nicht die Gesamtsupportdauer, sie dienen der Produktpflege.

Bereits seit einigen Jahren veröffentlichen die großen Distributionen mit Langzeitpflege Zwischenreleases in denen Bugfixes der vergangenen Monate gebündelt werden. Debian und - abgesehen vom LTS-Stack - auch Ubuntu handeln hierbei strukturkonversativ und halten die Versionen über Jahre hinweg stabil.

RedHat und SUSE haben dagegen bereits vor einiger Zeit begonnen ausgewählt neue Software in den Minorversionen ihrer Hauptveröffentlichungen einzupflegen. Dadurch soll die Software über die langen Supportzeiträume benutzbar gehalten und Veränderungen im Umfeld Rechnung getragen werden. Insbesondere auf dem Desktop war dies eine überfällige Entwicklung.

OpenSUSE hat mit seiner Entscheidung Leap auf SLE aufzubauen, diesen Entwicklungsansatz übernommen. Die Entwicklung der Minorversionen erfolgt aber unter der unbedingten Prämisse einen sehr gut funktionsfähigen Upgradepfad innerhalb der Hauptversion ohne große Brüche zu gewährleisten. Das sieht man nicht zuletzt an den Versionsstabil gehaltenen Ständen von Kernel, Basisbestandteilen wie systemd und den Desktopumgebungen.

Die Supportzeit beträgt deshalb insgesamt mehrere Jahre und stellt damit eine erhebliche Ausweitung gegenüber herkömmlichen openSUSE Veröffentlichungen früherer Jahre dar. Wenn manche Pressetextabschreiber recherchiert hätten, wüssten sie das und könnten dies den Lesern und Anwendern auch so mitteilen. Stattdessen haut man lieber in alter Manier Textbausteine über die superduper neue Version raus.

27. Juli 2017

Vor ein paar Tagen habe ich mich gefreut, dass Adobe 2020 Flash endlich zu Grabe tragen will. Und schon kommen die ersten potentiellen Nekromanten aus Ihrer Gruft gestiegen.

Der Entwickler Juha Lindstedt hat nun eine Petition gestartet in der gefordert wird, dass Flash als Open-Source-Projekt weitergeführt wird. Er begründet diese Forderung damit, dass zukünftige Generationen vorhandene Webseiten, Spiele, usw. die auf Flash basieren nicht mehr konsumieren können.

Ich habe ehrlich gesagt keine Ahnung ob Herr Lindstedt trollt, verrückt ist oder einfach nur sehr große Eier hat. Ich kann mich an kein Update erinnern bei dessen Changelog nicht der Begriff kritische Sicherheitslücke zu lesen war. Ich möchte nicht wissen was alles entdeckt wird, wenn Flash quelloffen werden würde.

Ich werde daher einen Teufel tun und diese Petition unterschreiben. Bei Flash fällt mir persönlich nur das folgende ein. Burn it with fire! Da Adobe aber jetzt nicht dafür bekannt ist, sonderlich viel unter einer OSS-Lizenz zu veröffentlichen, habe ich hier das gute Gefühl, dass die Petition keine Früchte tragen wird.

Bild: openSUSE Leap Desktop Screenshot

Gestern wurde das neueste Wartungsupdate von openSUSE Leap 42.3 veröffentlicht. Den Zeitplan hatte man wohl ein bisschen vorverlegt um mit SLE Schritt zu halten, da Leap-Versionen eigentlich im Jahrestakt geplant waren und man die letzte Version 42.2 erst im vergangenen November veröffentlichte. Die Version 42.2 ist somit eine Aktualisierungsversion des LTS-Zweiges. Bedingt durch den Charakter als Minorversion sind keine größeren Änderungen zu erwarten, sondern vor allem Produktpflege im Detail.

Die openSUSE Leap-Version leitete 2015 eine neue Ära bei openSUSE ein. Nach der Aufspaltung der Entwicklung in eine Rolling Release-Variante Tumbleweed folgte die stabile LTS-Version Leap. Die Basis von Leap bilden Pakete aus SUSE Linux Enterprise (SLE), die durch aktuelle Pakete aus dem Tumbleweed-Zweig ergänzt werden. Diese Ergänzungen müssen jedoch einzeln von openSUSE-Maintainern vorgenommen werden, weshalb im Entwicklungsprozess keine ungewarteten Pakete über einen Automatismus nach Leap migriert wurden. Eine Prämisse für die Minorversehen besteht unter anderem darin einen funktionsfähigen Upgradepfad zu garantieren, weshalb Leap kein Klon des aktuellen Tumbleweed-Standes ist.

Basis-Versionen

Leap 42.3 basiert auf dem aktuellen Service Pack 3 (SP3) für SLE 12. Den stärkeren Fokus auf Produktpflege kann man unter anderem darin feststellen, dass die Kernel- und Desktopversionen im Vergleich zu 42.2 stabil gehalten wurden. Dies ist möglich, da man vorausschauend auf die LTS-Versionen gesetzt hatte. OpenSUSE Leap 42.3 liefert somit immer noch Kernel 4.4, den KDE Desktop Plasma in Version 5.8 und GNOME in Version 3.20 aus.

Veränderungen

Aktualisierungen hat das openSUSE-Team vor allem bei den Programmen für den Endanwender vorgenommen. Die KDE Applications wurden beispielsweise auf 17.04 aktualisiert und LibreOffice liegt in der aktuellen Version 5.3 bei. Größere Brüche sind hier aber nicht zu verzeichnen.

Installation und Upgrade

Die Installationsroutine wurde lediglich minimal angepasst. Im Bereich der Desktopauswahl ist es nun einfacher alternative Umgebungen wie MATE oder Xfce auszuwählen. Nach wie vor setzt openSUSE nicht darauf einfach ein Live-System auf die Festplatte zu übertragen, wie dies z.B. Ubuntu macht, sondern setzt eine vollwertige Installationsroutine ein. Das bietet dem Anwender die volle Freiheit, erfordert aber manchmal ein wenig Wissen. Anwender mit wenig Erfahrung sind jedoch nicht schlecht damit bedient, einfach die ausgewählten Voreinstellungen zu bestätigen. OpenSUSE richtet dann eine Root-Partition mit Btrfs, sowie - eine entsprechende Festplattengröße vorausgesetzt - eine Home-Partition mit XFS ein. Sofern gewünscht kann auch mit wenigen Mausklicks eine verschlüsselte LVM-Partitionierung gewählt werden.

Die Aktualisierung von einer bestehenden 42.2 Installation gestaltete sich in einem lokalen Test problemlos, was nicht zuletzt auf die geringen Änderungen im Basisbereich von Kernel, systemd und Plasma-Desktop zurückzuführen ist.

Fazit

Bei openSUSE wird Produktpflege noch groß geschrieben. Man hat sich für den Leap-Zweig vorgenommen eine richtige LTS-Distribution zu entwickeln und beweist mit 42.3, dass man es ernst meint. Während Basissystem und Desktop lediglich gepflegt werden, bekommt das Nutzer im Anwendungsbereich die aktuellen Neuerungen serviert und muss somit nicht Jahre hinter der allgemeinen Entwicklung her hinken. Diese sinnvolle Aufweichung der stabilen Entwicklungsprinzipien konnte man zuletzt auch bei RHEL beobachten.

OpenSUSE ist auf dem Desktop inzwischen absolut zu empfehlen und auch im stabilen Langzeiteinsatz eine ernstzunehmende Alternative zu Ubuntu & Co. Vor allem im KDE-Bereich gibt es kaum noch ernst zu nehmende Alternativen außerhalb des Rolling-Release-Sektors.

Leider sind die Produktzyklen immer noch nicht ganz planbar. Die Veröffentlichung von 42.3 kam für Außenstehende doch recht überraschend, da openSUSE-Releases sonst traditionell im Herbst erfolgen.

26. Juli 2017

Mozilla integriert mit Stylo das in Rust geschriebene CSS-System aus der Servo-Engine in Firefox 57 und bittet nun Nutzer der Nightly-Version, dieses zu testen.

Mozilla hat für Firefox 57 große Pläne. Ein Teil davon ist Stylo, oder auch Quantum CSS. Dabei handelt es sich um das CSS-System aus der Servo-Engine, entwickelt in der Programmiersprache Rust. Stylo ist, im Gegensatz zu aktuellen Engines, auf die Parallelisierung von Aufgaben spezialisiert und soll dadurch die Darstellung von Webseiten beschleunigen.

Stylo steht mittlerweile in Nightly-Versionen von Firefox zur Verfügung, ist standardmäßig allerdings noch deaktiviert. Mozilla bittet nun Nightly-Nutzer, beim Finden von letzten Darstellungs- und Stabilitätsproblemen zu helfen, bevor Stylo standardmäßig aktiviert und in Firefox 57 ausgeliefert werden kann.

Um das zu tun, muss die Seite about:config in Firefox Nightly aufgerufen und der Schalter layout.css.servo.enabled per Doppelklick auf true geschaltet werden.

Für einen kleinen Teil der Nutzer ist Stylo bereits aktiviert. Genauer gesagt führt Mozilla mit 20 Prozent der Nightly-Population ein Experiment durch, bei denen vier von fünf Nutzern Stylo aktiviert haben (ein Gecko-Nutzer pro vier Stylo-Nutzer als Kontrollgruppe des Experiments). In der kommenden Woche soll die Reichweite des Experiments auf 50 Prozent erhöht werden.

Fehler können in Mozillas Bugtracking-System Bugzilla gemeldet werden. Für Fragen stehen die Entwickler im IRC-Kanal #servo bereit.

Der Beitrag Firefox Nightly: CSS-System aus Servo-Engine kann getestet werden erschien zuerst auf soeren-hentzschel.at.

Wie bereits in Teil 1 dieser kleinen Serie angekündigt, möchte ich heute beschreiben, wie wir neben unserer Lehrmittelbibliothek auch mit unserer Schulbibliothek von LITTERA zu Koha umgestiegen sind.

Backup der Daten aus LITTERA

LITTERA macht es einem nicht gerade leicht die aufgenommen Titel und Exemplare zu exportieren, sodass man neben den allgemeinen Angaben zum Titel auch die entsprechenden Schlagworte, Systematik oder die Barcodes in irgendeiner lesbaren Form hat. Die Backupfunktion von LITTERA legt alle Daten in einer Microsoft Access Datenbank ab, in der wiederum alle Daten in Tabellen liegen. Unter Windows ist diese mit einem Passwort geschützt, doch mit Hilfe der mdb-tools (aus den Paketquellen von z.B. Ubuntu) kann man sich ohne Probleme den Inhalt dieser Datenbank anschauen.

Mit mdb-tables littera.mdb kann man sich die einzelnen Tabellen innerhalb der Datenbank anschauen und mit mdb-export littera.mdb tabellenname den Inhalt einer Tabelle. Wenn man das ganze noch mit sed verknüpft kann man mit folgendem Befehl alle Tabellen in eine CSV-Datei exportieren:

$ mdb-tables littera.mdb | sed "s/ /\n/g" | while read in; do  mdb-export littera.mdb "$in" > "$in".csv; done

Nun hat man alle Daten in einer Form, dass man sie weiterverarbeiten kann. Folgende Tabellen sind interessant. Die Spalte „Buchungsnummer“ dient dabei als ID in anderen Tabellen.

  • Verlag → Liste mit allen Verlagen und Ortsangabe
  • Schlagworte → Liste aller Schlagworte
  • Schlag_zuord → Zuordnung der Schlagworte zu einem Titel
  • Medienart → alle Medientypen
  • Interessenkreise → Liste der Interessenskreise
  • IntzuMed → Zuordnung Interessenkreise zu Titel
  • Systematik_OG / Systematik_UG → Ober- und Untergruppen der Systematik
  • Systematik_Zuordnung → Zuordnung der Systematik zu Titel
  • Sprache → Liste der verwendeten Sprachen
  • Reihe → Informationen über Reihen
  • Exemplar → Liste aller Exemplare
  • Titel → Liste aller Titel

Vorbereiten der Daten

Mit Hilfe eines Python-Skripts habe ich diese Tabellen ausgelesen und in einem großen Dictionary zusammengefasst, sodass ich zu jedem Titel alle nötigen Daten hatte (inkl. Exemplardaten).

#read publisher data
with open('Verlag.csv') as exemplarfile:
    reader = csv.DictReader(exemplarfile)
    tmpItem = {}

    for row in reader:
        tmpItem = {}
        tmpItem["name"] = row["Verlag"]
        tmpItem["city"] = row["Ort"]
        publishers[row["Buchungsnummer"]] = tmpItem

Eine weitere Schwierigkeit war der Barcode. Erst nach einiger Recherche habe ich einen Hinweis auf die Zusammenstellung des Barcodes gefunden. Ein Beispiel:

Barcode eines Exemplars: 1456000089443

Das Muster ist folgendes: Exemplarnummer + Nullen + Bibliotheksnummer + Länge der Exemplarnummer + Prüfziffer (EAN13).

Im obigen Bespiel wäre als 1456 die Nummer unsere Exemplars, gefolgt von Nullen. 894 ist die Nummer der Bibliothek gefolgt von der 4, da unsere Exemplarnummer 4stellig ist. 3 ist die Prüfnummer des Barcodes (die sich Über Division mit Rest berechnen lässt – einfach mal das weite Netz danach durchsuchen).

MAB zu MARC21

LITTERA verwendet MAB als Format für alle Titel und Exemplare und Koha dagegen MARC21. Die Daten, die nun mit Hilfe des Python-Skripts vorbereitet sind, müssen nun noch in MARC21 „umgewandelt“ werden. Wie ich schon in Teil 1 erwähnte, ist MARC21 nicht gerade einsteigerfreundlich und relativ komplex. Es dauert etwas bis man die Struktur verstanden hat. Mir hat an dieser Stelle in Website „Understanding MARC“ geholfen.

In MARC21 gibt es verschiedene Felder mit Unterfeldern, die dazu noch bis zu 2 Indikatoren haben. In Koha wird z.B. das Fled 952 für alle Exemplardaten verwendet. im Unterfeld „p“, also 952$p befindet sich z.B. der Barcode. Im Feld 245$a und 245$b werden der Titel und der Untertitel festgehalten usw. Eine genaue Auflistung in deutsch gibt es bei der Deutschen Nationalbibliothek.

Mehr oder weniger zufällig bin ich auf pymarc gestoßen, eine Python-Bibliothek zum Bearbeiten von MARC21 Daten. Diese Bibliothek nimmt einem viel Arbeit ab. Ich habe also aus den vorbereiteten Daten die einzelen Einträge der MARC21-Felder erstellt und am Ende als MARC21XML exportiert. Hier ein Auszug aus dem Skript:

if "ISBN" in titles[recordID] and titles[recordID]["ISBN"] != "":
    record.add_field(
        Field(
            tag = '020',
            indicators = ['',''],
            subfields = [
                'a', titles[recordID]["ISBN"]
            ]
        )
    )

Die Felder 000 bis 008 sind besondere Felder in MARC21, deren Bedeutung ich noch nicht 100%ig verstanden habe. Auf jeden Fall ist der „Leader“ ein sehr wichtiges Feld, weil in ihm wichtige Daten über z.B. die Medienart festgehalten sind. Deshalb hier noch ein Auszug, wie ich den Leader konstrukiert habe (anhand des Medientyps):

l = list(record.leader)

l[5] = ’n‘ l[6] = ‚a‘ l[7] = ‚m‘ l[9] = ‚a‘ l[17] = ‚7‘ l[18] = ‚a‘ if titles[recordID][„type“][„short“] in („BU“, „ZS“): l[6] = ‚a‘ l[7] = ‚m‘ if titles[recordID][„type“][„short“] in („CD“, „TC“, „HB“): l[6] = ‚j‘ if titles[recordID][„type“][„short“] in („KA“): l[6] = ‚e‘ if titles[recordID][„type“][„short“] in („VI“, „DV“, „DI“, „FI“, „OV“): l[6] = ‚g‘ if titles[recordID][„type“][„short“] in („CR“, „FD“): l[6] = ‚m‘ if titles[recordID][„type“][„short“] in („SP“, „SO“): l[6] = ‚o‘ record.leader = „“.join(l) (mehr …)

2 Kommentare

Der Beitrag Umstieg von LITTERA zu Koha – Teil 2 erschien zuerst auf .:zefanjas:..

25. Juli 2017

Adobe hat heute das Ende des Adobe Flash Players für Ende 2020 angekündigt. Für die meisten Firefox-Nutzer wird die Unterstützung bereits Anfang 2020 auslaufen.

Der Adobe Flash Player ist das letzte verbliebene NPAPI-Plugin, welches von Firefox noch unterstützt wird, nachdem andere NPAPI-Plugins wie Oracle Java oder Microsoft Silverlight bereits seit Firefox 52 nicht mehr unterstützt werden. NPAPI-Plugins waren für viele Jahre ein wichtiger Teil der Webplattform. In den letzten Jahren hat deren Bedeutung aber immer stärker abgenommen. Praktisch alles, was früher ausschließlich mittels NPAPI-Plugin umsetzbar war, wird heute, dank entsprechender Weiterentwicklung von Webstandards, nativ durch die Browser unterstützt. Heute gelten NPAPI-Plugins vor allem aus Sicherheits-Perspektive als problematisch.

Dass der Adobe Flash Player, auch in anderen Browsern, weiterhin unterstützt wird, liegt vor allem an der immer noch sehr großen Verbreitung von Flash-Inhalten. Nun hat Adobe gemeinsam mit seinen Technologie-Partnern Mozilla, Google, Microsoft, Apple und Facebook einen Zeitpunkt festgelegt, an dem Schluss ist: mit Ende 2020 erreicht der Adobe Flash Player sein sogenanntes End of Life. Mit anderen Worten: ab dann wird es keine Updates mehr für den Adobe Flash Player geben. Nicht nur das, zu diesem Zeitpunkt werden auch die wichtigen Browser wie Firefox, Chrome, Internet Explorer und Edge nicht länger in der Lage sein, Flash-Inhalte abzuspielen.

Mozillas Roadmap im Hinblick auf Flash sie wie folgt aus:

August 2017

Mozilla wird am 8. August Firefox 55 veröffentlichen. Mit Firefox 55 wird der Adobe Flash Player nicht länger standardmäßig aktiviert sein, sondern im sogenannten Click-to-Play-Modus betrieben werden. Das heißt, dass das Plugin erst nach ausdrücklicher Bestätigung auf der Webseite aktiviert wird. Der Nutzer kann Firefox die Entscheidung, ob der Flash Player geladen werden soll oder nicht, pro Webseite merken lassen. Diese Änderung wird schrittweise zwischen August und September ausgerollt werden.

Darüber hinaus wird Mozilla eine Liste von Webseiten pflegen, welche überhaupt kein Flash mehr nutzen können.

September 2017

Mit Version 56 (geplante Veröffentlichung: 26. September) wird Mozilla die Unterstützung von Plugins aus Firefox für Android entfernen.

Ende 2018

Firefox wird sich nicht länger merken, auf welchen Seiten Click to Play deaktiviert werden soll. Dann muss der Flash Player in jeder Browser-Sitzung erneut aktiviert werden, wenn er genutzt werden soll.

Anfang 2019

Anfang des Jahres 2019 wird Firefox Warnungen auf Webseiten anzeigen, welche weiterhin den Adobe Flash Player benötigen.

Anfang 2020

Mozilla wird bereits Anfang 2020 die Unterstützung von Flash für die meisten Nutzer, sprich aus der Mainstream-Version von Firefox, entfernen. Firefox ESR wird weiterhin bis Ende 2020 den Adobe Flash Player unterstützen.

Ende 2020

Ab Ende 2020 wird auch Firefox ESR nicht länger den Adobe Flash Player unterstützen.

Der Beitrag Unterstützung für Adobe Flash Player wird Anfang 2020 eingestellt erschien zuerst auf soeren-hentzschel.at.

Nach einigem ausprobieren von verschiedenen Self-Hosted Notes App, bin ich zu dem Schluss gekommen, mir selbst eins zu schreiben. Gesagt getan. Gestern schnell angefangen und kann heute schon den ersten Working Release veröffentlichen:

SiMPad ~ A simple self hosted Markdown Notepad

Aktuell läuft der Code, doch einige ToDo's von mir sind noch nicht umgesetzt. So sollen aktuell noch folgende Dinge integriert werden:

  • Passwortschutz
  • Verschlüsselte Ablage

Doch aktuell kann man selbst Notes anlegen und diese durch kopieren des Links teilen.

Nach einigem ausprobieren von verschiedenen Self-Hosted Notes App, bin ich zu dem Schluss gekommen, mir selbst eins zu schreiben. Gesagt getan. Gestern schnell angefangen und kann heute schon den ersten Working Release veröffentlichen:

SiMPad ~ A simple self hosted Markdown Notepad

Aktuell läuft der Code, doch einige ToDo’s von mir sind noch nicht umgesetzt. So sollen aktuell noch folgende Dinge integriert werden:

  • Passwortschutz
  • Verschlüsselte Ablage

Doch aktuell kann man selbst Notes anlegen und diese durch kopieren des Links teilen.

24. Juli 2017

Mozilla hat die Sitzungswiederherstellung von Firefox 55 drastisch beschleunigt und dabei gleichzeitig den Speicherverbrauch spürbar gesenkt.

Wer Firefox mit vielen Tabs nutzt, darf sich auf Firefox 55 freuen (geplante Veröffentlichung: 8. August 2017). Mozilla hat die Sitzungswiederherstellung in Firefox 55 erheblich verbessert, was sich vor allem bei der Nutzung vieler Tabs bemerkbar macht.

Mozillas Dietrich Ayala hat ein Firefox-Profil mit der unglaublichen Menge von 1.691 Tabs als Ausgangs-Situation genommen und die Leistung zwischen Firefox 20, Firefox 30, Firefox 40, Firefox 50, Firefox 51, Firefox 52, Firefox 53, Firefox 54 sowie schließlich Firefox 55 und Firefox 56 verglichen. Alle Messungen beziehen sich auf das reine Laden der Tabs. Die Internet-Verbindung war zum Testen getrennt, das Laden der Webseiten selbst und der von den Webseiten verursachte RAM-Verbrauch findet in diesen Statistiken also keine Beachtung.

Auffallend dabei ist, dass die Startzeit des Browsers bis einschließlich Firefox 51 kontinuierlich zugenommen hat. Bereits in Firefox 52 bis Firefox 54 gab es jeweils Verbesserungen der Startzeit, mit Firefox 55 erreicht der Mozilla-Browser allerdings ein bisher nie erreichtes Niveau: Hatte Firefox 51 mit sage und schreibe fast acht Minuten Startzeit den negativen Spitzenwert markiert und auch Firefox 54 noch immer fast fünf Minuten zum Starten benötigt, benötigte Firefox 55 gerade einmal noch 15 Sekunden für dieselbe Anzahl von Tabs.

Startzeit Firefox 55

Einen ähnlich positiven Effekt konnte Mozilla beim Speicherverbrauch erreichen, welcher eine Minute nach dem Start gemessen wurde. Hier hatte Firefox in diesem Szenario bisher einen Verbrauch erzielt, der sich immer im Bereich um die 2 GB bewegt hatte. In Firefox 55 sind es nur noch 0,5 GB, also nur noch ein Viertel des bisherigen Bedarfs.

RAM-Verbrauch Firefox 55

Die Verbesserungen sind auf Mozillas Quantum Flow-Initiative zurückzuführen, einem Teil des übergeordneten Quantum-Projekts. Mozilla hatte mit Quantum einen Quantensprung in Sachen Performance versprochen und liefert mit Firefox 55 bereits einen kleinen Vorgeschmack.

Der Beitrag Firefox 55: Sehr viel schnellere Sitzungswiederherstellung bei deutlich weniger RAM-Verbrauch erschien zuerst auf soeren-hentzschel.at.

Die nächsten großen Umbrüche bei Firefox kündigen sich an, das bisherige Erweiterungs-Ökosystem steht vor dem Aus – und die Marktanteile sollen schwinden. Könnte das tatsächlich irgendwann das Ende von Firefox sein?

Es geht gerade durch alle IT-Medien: Mozillas Ex-Technikchef Andreas Gal gibt Googles Werbemaßnahmen die Schuld für einen schwindenden Marktanteil des Firefox-Browsers. Das klingt durchaus plausibel, denn Google hat von Anfang an relativ viel Werbung für seinen Chrome-Browser gemacht. Während Firefox vor allem durch Mundpropaganda groß wurde – eine (!) großseitige Anzeige in der FAZ vor Jahren bezahlten die Nutzer, nicht Mozilla – gab es Chrome-Werbung nicht nur bei Google-Suchen, sondern auch im Real Life auf Plakatflächen oder im Fernsehen zu sehen.

Werbung ist nicht alles

Aber so wichtig Werbung auch ist, sie sollte bei der Beurteilung für Chromes Aufstieg nicht überbewertet werden. Denn Chrome überzeugte auch durch das Produkt an sich: der Google-Browser wurde zum technischen Vorreiter, nahm Entwicklungen vorweg, die Firefox teilweise bis jetzt noch nicht wieder aufgeholt hat. Die Trennung von Tabs und Plugins in unterschiedliche Prozesse, die Vereinfachung der Benutzeroberfläche.

Chrome lief Firefox recht schnell den Rang ab als modernster zu habender Browser für unterschiedliche Systeme. Während früher Derivate fast immer auf Mozilla-Technik aufsetzten, ist es heute die Technik hinter dem Google-Browser, die als Grundlage für weitere Browser – wie etwa Opera oder Vivaldi – dient … und damit zumindest die Darstellung des Internets immer homogener werden lässt.

Firefox hingegen hat sich auch danach noch lange Zeit auf seinem Alleinstellungsmerkmal des umfassenden Erweiterungssystems ausgeruht – und traf dann einige strategische Fehlentscheidungen. Statt sich ganz auf sein Aushängeschild Firefox zu konzentrieren, wurden viele Ressourcen in das inzwischen gescheiterte Firefox OS gesteckt. Statt den Browser schneller auf eine technisch neue Grundlage zu stellen, wurden teils merkwürdige Features integriert.

Nicht mehr die Nr. 1

Dass Firefox nicht mehr die Richtung vorgab, war spätestens daran zu merken, als Firefox begann, Chrome zumindest auch optisch zu imitieren. Das Australis-Design brach visuell mit der Firefox-Historie und machte den Open-Source-Browser zwar nicht zum Chrome-Klon, rückte ihn aber deutlich in dessen Nähe. Und auch das Veröffentlichungsmodell mit vielen schnellen und regelmäßigen Neuversionen, die aber meist nichts wesentlich Neues brachten, ließ die Unterschiede zu Chrome weiter abnehmen.

Firefox ist nach dem Ende von Operas „Presto“ faktisch die letzte mit Chrome konkurrierende Browsertechnik, die plattformübergrreifend verfügbar ist. Doch die Notwendigkeit von einst, die die Leute zu Firefox trieb, der technisch schlimme Zustand des Internet Explorer mit seinen vielen Sonderwegen, ist heute nicht mehr das Problem. Chrome ist nicht nur überall präsent, sondern hält sich auch an die Webstandards. Webentwickler haben keinen Anlass, Chrome zu verteufeln. Firefox ist dadurch nur noch ein Konkurrent, kein Heilsbringer mehr, kein David gegen Goliath, der sich anschickt, das Web zu retten.

Die Sympathien liegen im Zweifel immer noch eher beim Mozilla-Browser, der theoretisch unabhängig von Konzerninteressen entsteht und die Nutzerinteressen an erste Stellen rücken kann – doch in der Praxis spielt das letztlich kaum eine Rolle.

Der Fuchs ist noch lange nicht tot

Für Schwarzmalerei ist es aber noch zu früh. Im Vergleich zur einstigen Statistik ist auch bei uns die Entwicklung deutlich abzulesen, Chrome und andere auf Blink-Technik setzende Browser führen auch auf den Knetfeder-Seiten die Statistik an.

Firefox hat Platz 1 an Chrome verloren und folgt nun auf dem 2. Platz vor den Microsoft- und Apple-Browsern. Während vor 5 Jahren noch fast die Hälfte der Nutzer mit Firefox unterwegs waren und vor 3 Jahren immerhin noch ein gutes Drittel den Fuchs nutzte, ist die Zahl der Firefox-Fans nun auf ein Viertel gefallen. Knapp 27 Prozent Firefox stehen knapp 30 Prozent Chrome gegenüber, wenn man die Apple-Browser nicht mitzählt. Zählt man sie mit, dann dominiert die Google/Apple-Technik mit deutlichen runden 50 Prozent.

Das Verhältnis von Firefox zu anderen Browsern hat sich also in den letzten 8 Jahren genau umgekehrt. Ein Anteil von einem knappen Viertel ist andererseits auch alles andere als blamabel, sondern vor allem vor dem Hintergrund, dass Microsoft, Google und Apple in einer ganz anderen Liga mit ganz anderen Möglichkeiten spielen, weiter respektabel.

Ob es für Firefox tatsächlich irgendwann einmal gefährlich wird, das wird sich in den kommenden Jahren zeigen, ob die Nutzer den neuen Firefox annehmen werden – oder noch weniger Gründe für den Firefox-Einsatz sehen, wenn der Mozilla-Browser dann zwar technisch zu Chrome aufschließt, sich dann aber noch weniger von diesem unterscheiden wird.

Eigentlich war ich ja ganz zufrieden mit Hugo, doch war es mir immer noch zu gewaltig. Zusätzlich brauchte ich immer den Zugang zu meinem Server via SSH oder FTP um einen neuen Artikel zu schreiben. Das war nach einiger Zeit doch ziemlich nervig.

So habe ich mich entschieden auf ein anderes Static CMS umzusteigen und ich bin bei BaunCMS gelandet.

Nach einem kurzen und schnellen einarbeiten in die Doku, war die Seite schnell installiert und die alten Blog Beiträge schnell kopiert.

Jetzt folgt in den nächsten Tagen noch ein neues Template.

Malte

23. Juli 2017

Spätestens ab Debian 10 (Buster) wird das alte Verfahren zur Namensvergabe von Netzwerkschnittstellen nicht mehr unterstützt, und das System muss auf das neue Verfahren umgestellt sein (Predictable Network Interface Names).

Bei einer Neuinstallation von Debian 9 (Stretch) passiert diese Umstellung automatisch. Bei einem Upgrade von Debian 8 (Jessie) muss hingegen manuell umgestellt werden.

Auf das neue Verfahren zur Namensvergabe von Netzwerkschnittstellen umstellen

Um auf das Verfahren Predictable Network Interface Names umzustellen, muss die Datei /etc/udev/rules.d/70-persistent-net.rules gelöscht werden:

mv /etc/udev/rules.d/70-persistent-net.rules{,.old}

Danach muss das System neu gestartet werden.

Dieser Schritt stellt eine entsprechend weitreichende Änderung am System da. Eventuelle Konfigurationsdateien müssen angepasst und getestet werden. Wer statt des Network-Manager die Datei interfaces(5) nutzt, muss zumindest diese anpassen.

Siehe auch: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.de.html#new-interface-names, https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20 (Beschreibt nach welchen Regeln, die neuen voraussagbaren/vorhersagbaren Namen aufgebaut sind), https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/, file:///usr/share/doc/udev/README.Debian.gz

Benutzerdefinierte Namen für Netzwerkschnittstellen

In manchen Fällen ist es praktisch, eigene Namen für Netzwerkschnittstellen zu definieren.

Dies kann mittels zwei verschiedener Methoden erreicht werden. Einmal mittels Network Device Configuration: systemd.link(5) und einmal mittels Dynamic Device Management: udev(7), welche wesentlich mehr Möglichkeiten bietet.

In folgenden Beispielen, wird der Netzwerkschnittstelle mit der MAC-Adresse 00:a0:de:63:7a:e6, der feste Namen dmz zugewiesen:

  • Dynamic Device Management – udev(7):
    Beispielsweise kann /etc/udev/rules.d/76-netnames.rules erstellt und dort Netzwerkgeräte anhand beliebiger Attribute und Eigenschaften identifiziert und benannt werden.
    Hier ein Beispiel, um ein Gerät über die MAC-Adresse zu identifizieren und zu benennen:
    cat /etc/udev/rules.d/76-netnames.rules
    # identify device by MAC address
    SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:a0:de:63:7a:e6", NAME="dmz"
    

    Gegenüber systemd.link(5), bietet diese Methode auch die Möglichkeit Geräte anhand anderer Übereinstimmungsschlüssel, wie der Vendor/Model-ID oder des Gerätepfads zu Identifizieren. Siehe dazu auch die Handbuchseite udev(7), für die Dokumentation, wie man udev-Regeln schreibt.

  • Network Device Configuration – systemd.link(5):
    Alternativ geht auch eine Konfiguration ohne udev(7), mittels systemd.link(5) und des Name-Schlüssels:
    cat /etc/systemd/network/10-dmz.link
    [Match]
    MACAddress=00:a0:de:63:7a:e6
    [Link]
    Name=dmz
    

Damit diese Änderungen übernommen werden, ist ggf. eine Aktualisierung der initrd-Datei mittels update-initramfs -u und ein Neustart des Systems erforderlich.

22. Juli 2017

Gnome ist wieder da. Nach vielen Querelen in Folge der Neuausrichtung, die viele Abspaltungen nach sich zog, hat die originale Gnome-Oberfläche wieder eine gute Balance gefunden. Die Gnome-Shell wirkt wieder attraktiv – und wird so auch immer öfter wieder zur ersten Wahl. Dass nun auch Ubuntu wieder auf originales Gnome setzen will, beweist es.

Das Gnome-Projekt ist seit der Einführung der Gnome-Shell viel gescholten worden. Das lag an zwei Dingen: einerseits am nahezu kompromisslosen Vereinfachungsparadigma, andererseits am davon beflügelten Über-Bord-Werfen von bewährten Konzepten.

Dafür merkt man an jeder Ecke, dass sich da jemand wirklich Gedanken gemacht hat. Die Gnome-Macher sind innovativ. Sie fragen sich in erster Linie, wie man die PC-Bedienung für den Nutzer optimieren kann, die tägliche Arbeit mit dem Computer so eingängig wie möglich gestaltet – und nicht nur, wie man Gewohntes auf moderne Weise umsetzt. Gewohntes, das zwar viele kennen, aber das vielleicht gar nicht das Optimum in der Computerbedienung darstellt, sondern einfach nur vertraut wirkt.

Mut zu eigenen Wegen

Gnome ist sichtbar etwas Eigenes, keine hundertste CDE-, Mac- oder Windows-Inkarnation. Wer zum Beispiel Schnellzugriff-Listen oder Favoriten-Ordner vermisst, wird schnell feststellen, dass er sie in Gnome eigentlich gar nicht braucht. Denn die Verzahnung der Desktop- bzw. Dateisuche ist deutlich komfortabler und intuitiver, als es manuelle Favoriten sein können.

Während andere Linux-Desktops die Windows-Taste, die heute faktisch auf jeder Tastatur zu finden ist, lange Zeit einfach ignorierten, wurde sie bei Gnome zum zentralen Bestandteil der Bedienung. Dass die „Windows“-Taste dann tatschlich (auch) die Fenster-Übersicht hervorzaubert, also das Windows-Logo für die Zwecke von Linux quasi umdeutet, macht die Angelegenheit nur noch sympathischer.

Den gesamten Bildschirm auch als eine Art Startmenü zu nutzen, statt es in ein kleines Feld an irgendeiner Leiste zu quetschen, gab es für den Desktop ebenfalls zuerst bei Gnome.

Fehlentwicklungen

Natürlich besteht dabei das Risiko, dass es auch mal zu Fehlentwicklungen kommt, die zwar in der Theorie sinnvoll erscheinen, von den Nutzern aber überhaupt nicht angenommen werden. Das birgt zugleich die Gefahr, dass viele, die dann anderes von einer Desktopumgebung erwarten, Gnome den Rücken kehren und zu anderen Oberflächen wechseln.

Von absoluter Kompromisslosigkeit kann aber auch längst nicht mehr die Rede sein. Was für gut erachtet wird, wird konsequent beibehalten, aber wenn sich Lösungen nicht bewähren, dann werden sie auch wieder abgeschafft und durch Alternativen ersetzt, der Desktop in dieser Hinsicht weiterentwickelt. Das war etwa beim standardmäßig ausgeblendeten Abschaltknopf der Fall oder bei der Umbelegung der Entfernen-Taste im Dateimanager.

Eine Spatial-Modus-Debatte (jeder Klick auf einen Unterordner öffnet ein neues Fenster), wie zu Gnome-2-Zeiten, die vorübergehend den Browser-Modus mit Vor- und Zurück-Pfeilen im Dateimanager ersetzte, muss man daher nicht mehr befürchten.

Zugehen auf Traditionalisten und Individualisten

Gnome hält im Grundsatz weiter stur an seinem aktuellen Konzept fest, ist mittlerweile aber doch flexibler geworden. Wer mit der Standardkonfiguration nicht zurechtkommt oder zurechtkommen will, wird nicht mehr zu seinem Glück gezwungen. Die Einstellungsmöglichkeiten sind umfangreicher geworden, die erweiterten Einstellungen im „Optimierungswerkzeug“ befriedigen Spezialwünsche – und wenn das immer noch nicht reicht, kann man das Erweiterungssystem nutzen, das Gnome wie keine andere Linuxoberfläche den eigenen Vorlieben anzupassen vermag.

Dabei sind einige nützliche Erweiterungen in Gnome sogar schon ab Werk integriert – vornehmlich jene, die es erlauben, die Gnome-Shell wieder wie frühere Versionen mit traditionellem Verhalten aussehen zu lassen und die auch für die Umsetzung des „Gnome Classic“-Modus benötigt werden. So lassen sich altbekannte Elemente auch in der modernen Shell schnell wiederherstellen, die Traditionalisten werden nicht im Regen stehen gelassen.

Wer also gar nicht mit der neuen Bedienphilosophie zurechtkommt, weil er z. B. auf windowsartige Bedienweisen konditioniert ist, der hat inzwischen die Möglichkeit, Gnome ein wenig mehr seinen Bedürfnissen anzupassen. Mit Bordmitteln, aber auch mit einer Vielzahl von internen und externen Erweiterungen.

Die Basics stimmen

Dabei ist die in den Anfängen kritisierte drastische Vereinfachung letztlich nicht so schlimm gekommen, wie es zunächst den Anschein hatte. Die „Basics“ stimmen bei Gnome, die Linux-typischen Eigenheiten sind vorhanden. Alt+F2 zaubert den Befehl-Ausführen-Dialog auf den Bildschirm, die virtuellen Arbeitsflächen sind sogar nicht nur Feature, sondern elementarer Bestandteil der Desktopumgebung. Einen „Systray“ gibt es ebenso weiterhin wie eine Art „Start“-Button. Desktop-Symbole lassen sich einschalten. Die gängigen Tastenkürzel sind ebenfalls da – und der Dateimanager reagiert so, wie man es von ihm erwartet. F2 benennt Dateien um, mit Strg plus Maus wird selektiert, der mittlere Tastenklick öffnet in neuen Tabs, Dateien können über das Kontextmenü sortiert werden usw. Gnome bricht also keineswegs willkürlich mit althergebrachten Lösungen und Vertrautem, sondern unterstützt die klassischen Bedienweisen weiter.

Reifeprozess

Bemerkenswert ist bei aller Innovation und Eigensinnigkeit jedoch auch, dass, wenn die Innovation erst einmal umgesetzt wurde, sie auch konsequent zu Ende entwickelt und weitergedacht wird. Radikal Neues wird bei Gnome nicht alle naselang eingeführt, sondern die neuen Konzepte werden behutsam fortentwickelt. Das war schon bei Gnome 2 zu beobachten, welches recht umfassend mit dem Vorgänger brach, und danach jahrelang stabilisiert und perfektioniert wurde. Gleiches lässt sich nun bei „Gnome 3“, der Gnome-Shell, beobachten – und den zu Gnome gehörenden Anwendungen. Das bringt eine gewisse Verlässlichkeit und auch Planbarkeit mit sich, die vor allem auch manche Distributoren schätzen.

Modernes Linux

Die Gnome-Entwickler waren mutig in jeder Hinsicht: Mutig genug, sich von veralteten Konzepten zu trennen, um etwas Neues auszuprobieren. Mutig genug, um neue Ideen dann auch konsequent umzusetzen. Und mutig genug, um gegen alle Widerstände und heftige Kritik an diesem Kurs weiter festzuhalten, obwohl die Akzeptanz zunächst rapide sank und zahlreiche Forks entstanden. Das hat letztlich zu einer modernen Oberfläche geführt, während die Forks nur Altes erhalten, nachgebaut oder bereits bestehende Konzepte kopiert haben.

Die Entwickler haben, obwohl die Gnome-Shell im Standardfunktionsumfang deutlich reduzierter als frühere oder vergleichbare Entwicklungen daherkommt, den wahrscheinlich visuell und funktional modernsten Desktop für Linux geschaffen, den es momentan gibt. Dass nun auch Ubuntu – selbst immer darum bemüht, Neues auszuprobieren, nach dem Abschied von der Eigenentwicklung Unity wieder auf Gnome setzt, dürfte nicht nur historische Gründe haben. Es ist die logische Wahl – und ein Eingeständnis, dass die Entwickler von Gnome einen exzellenten Job gemacht haben – und weiterhin machen.

20. Juli 2017

Am 19. und 20. August findet in St. Augustin bei Bonn die FrOSCon statt. Für mich ist es mittlerweile eine der Open Source Veranstaltung neben der OpenRheinRuhr und der Ubucon, die ich möglichst nicht verpassen will. Dieses Jahr bin ich so da zum (erst) dritten Mal in Folge.

Das Programm der diesjährigen FrOSCon veröffentlicht. Ich selbst bin dieses Mal mit einem Vortrag und einem Workshop vertreten.

Nicht alltägliche Git-Funktionen

Im letzten Slot am Samstag um 17:45 findet mein Talk mit dem Titel „Nicht alltägliche Git-Funktionen – Committen, Pushen, Mergen kann jeder – aber was gibt es darüber hinaus?“ statt.

Wie der (Unter)Titel schon verrät, geht es hier eben nicht um die alltäglichen Funktionen von Git, sondern die Funktionen, die man eher nicht so oft nutzt und eben auch nicht jeden Tag braucht. Darunter fallen Funktionen wie die Fehlersuche mit Git, das Neuschreiben der kompletten Historie, Wiederherstellen von kaputten und „verlorenen“ Commits und noch einige weitere Funktionen.

Der Talk richtet sich an diejenigen, die Git schon kennen und neue nützliche Kenntnisse in der Nutzung gewinnen wollen. Der Link zum Programmpunkt findet sich an dieser Stelle.

Git-Workshop für Einsteiger

Für die Personen, die noch keine Erfahrung und Ahnung von Git haben, biete ich auch noch einen Einsteiger-Workshop an. Dieser findet am Sonntag von 14 bis 18 Uhr statt. In den vier Stunden wird es einen grundlegenden Einstieg in die Versionsverwaltung mit Git. Konkret fällt darunter: Was ist Git und worin unterscheidet es sich von anderen Versionsverwaltungssystemen? Wie erstelle ich ein Repository und füge Änderungen hinzu? Wie erstelle ich Branches und führe sie wieder zusammen?

Vier Stunden sind wahrlich nicht viel für einen Workshop. Je nach Zeit wird die Arbeit mit Remote-Repositorys auf das nötigste beschränkt. Der Workshop empfiehlt sich daher wirklich nur für die Leute, die wirklich noch nicht die wesentlichen Git Funktionen kennen. Der Link zum offiziellen Programmpunkt findet sich an dieser Stelle.

Der Workshop basiert auf mein Git-Buch. Eben dieses Buch wird auch – wenn nichts dazwischen kommt – nach dem Workshop und nach dem Talk verlost.

Unabhängig von meinen Talk und Workshop lohnt sich natürlich auch ein Blick auf die anderen Vorträge und Workshops im Programm der FrOSCon!

Am 19. und 20. August findet in St. Augustin bei Bonn die FrOSCon statt. Für mich ist es mittlerweile eine der Open Source Veranstaltung neben der OpenRheinRuhr und der Ubucon, die ich möglichst nicht verpassen will. Dieses Jahr bin ich so da zum (erst) dritten Mal in Folge.

Das Programm der diesjährigen FrOSCon veröffentlicht. Ich selbst bin dieses Mal mit einem Vortrag und einem Workshop vertreten.

Nicht alltägliche Git-Funktionen

Im letzten Slot am Samstag um 17:45 findet mein Talk mit dem Titel „Nicht alltägliche Git-Funktionen – Committen, Pushen, Mergen kann jeder – aber was gibt es darüber hinaus?“ statt.

Wie der (Unter)Titel schon verrät, geht es hier eben nicht um die alltäglichen Funktionen von Git, sondern die Funktionen, die man eher nicht so oft nutzt und eben auch nicht jeden Tag braucht. Darunter fallen Funktionen wie die Fehlersuche mit Git, das Neuschreiben der kompletten Historie, Wiederherstellen von kaputten und „verlorenen“ Commits und noch einige weitere Funktionen.

Der Talk richtet sich an diejenigen, die Git schon kennen und neue nützliche Kenntnisse in der Nutzung gewinnen wollen. Der Link zum Programmpunkt findet sich an dieser Stelle.

Git-Workshop für Einsteiger

Für die Personen, die noch keine Erfahrung und Ahnung von Git haben, biete ich auch noch einen Einsteiger-Workshop an. Dieser findet am Sonntag von 14 bis 18 Uhr statt. In den vier Stunden wird es einen grundlegenden Einstieg in die Versionsverwaltung mit Git. Konkret fällt darunter: Was ist Git und worin unterscheidet es sich von anderen Versionsverwaltungssystemen? Wie erstelle ich ein Repository und füge Änderungen hinzu? Wie erstelle ich Branches und führe sie wieder zusammen?

Vier Stunden sind wahrlich nicht viel für einen Workshop. Je nach Zeit wird die Arbeit mit Remote-Repositorys auf das nötigste beschränkt. Der Workshop empfiehlt sich daher wirklich nur für die Leute, die wirklich noch nicht die wesentlichen Git Funktionen kennen. Der Link zum offiziellen Programmpunkt findet sich an dieser Stelle.

Der Workshop basiert auf mein Git-Buch. Eben dieses Buch wird auch – wenn nichts dazwischen kommt – nach dem Workshop und nach dem Talk verlost.

Unabhängig von meinen Talk und Workshop lohnt sich natürlich auch ein Blick auf die anderen Vorträge und Workshops im Programm der FrOSCon!

18. Juli 2017

Da bei meinem letzten Versuch auf meinem bestehenden Server PHP7.0 zu installieren, sich der Server verabschiedet hat, war ich gezwungen alles neu zu machen. Das habe ich gleich zum anlass genommen, meinen Server sauber neu aufzusetzen. Im folgenden werde ich kurz erläutern, wie ich meinen Debian Jessie Server mit PHP7.0 und nginx HTTP/2 ausgestattet habe.

Quellen

Leider ist in den aktuellen Repos von Debian Jessie kein PHP7.0 enthalten, so das man gezwungen ist, Fremdquellen zu nutzen. Das selbe geht auch für nginx, welches auch nur in einer veralteten Version vor liegt. Im folgenden sollten diese Quellen der /etc/apt/sources.list hinzugefügt werden.

deb http://packages.dotdeb.org jessie all
deb-src http://packages.dotdeb.org jessie all

deb [arch=amd64,i386] http://nginx.org/packages/debian/ jessie nginx
deb-src [arch=amd64,i386] http://nginx.org/packages/debian/ jessie nginx

Danach sollten die GPG Keys für beide Quellen eingebunden werden:

wget https://www.dotdeb.org/dotdeb.gpg && apt-key add dotdeb.gpg
wget https://nginx.org/keys/nginx_signing.key && apt-key add nginx_signing.key

Jetzt noch ein update und dann installieren wir die benötigten Pakete:

apt update && apt dist-upgrade -y
apt install nginx php7.0 php7.0-fpm php7.0-mysql mariadb-server

PHP 7.0 Konfiguration

In der PHP INI File werden wir einige wichtigen Einstellungen setzten:

vim /etc/php/7.0/fpm/php.ini

Als erstes werden wir die Option cgi.force_redirect unkommentieren und dann werden wir sie wie folgt setzen:

cgi.force_redirect = 0

Als nächstes passen wir noch die Zeitzone an:

date.timezone = "Europe/Berlin"

Jetzt starten wir das PHP FPM Modul noch neu:

service php7.0-fpm restart

Nginx konfigurieren

Um nginx mit dem PHP FPM Modul nutzen zu können, müssen wir noch die Konfiguration von nginx anpassen:

vim /etc/nginx/sites-available/default

Im Server Block ganz unter (vor der geschloßenen geschweiften Klammer), wird folgender Block angefügt:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}

Jetzt noch nginx Dienst neustarten, und schon läuft der nginx mit PHP Support.

MariaDB

Nach der Installation von mariadb läuft der Datenbankdienst bereits, doch sollte noch der Befehl

mysql_secure_installation

ausgeführt werden, um die Sicherheit von dem Datenbankdienst zu erhöhen.

Auf meinen Artikel "OPENSTREETMAPS PFLEGEN" hat sich ein Leser (Sven) bei mir gemeldet, und von der schönen App StreetComplete erzählt.

SC

Installation

Diese App kann man über Google Play, F-Droid oder IzzyOnDroid F-Droid repository installieren.

Nutzung

Diese kleiner App ermöglicht dem Benutzer ohne großes Fachwissen, ein Teil der OSM Community zu werden. Durch das hinzufügen des persönlichen OSM Accounts in den Einstellungen, kann es auch schon direkt los gehen.

Beim starten der App, sucht die App den aktuellen Standort und prüft im Hintergrund, ob es unfertige Angaben gibt. Diese unfertigen Angaben können z.B. sein:

  • Straßentyp (befestigt, unbefestigt)
  • Hausnummern
  • Straßennamen
  • Öffnungszeiten
  • Stockwerke
  • Dachform
  • etc.

Durch das klicken auf das entsprechende Icon:

Stick

öffnet sich im unteren Teil der App ein entsprechendes Bearbeitungsfenster. Nichts großes, Schlank und Rank, kurze Frage, wie z.B.

Wie ist der Name dieser Straße?

Schnell die Antwort eingetippt und fertig. In der Standardeinstellungen, werden die Änderungen Sofort hochgeladen.

Herzlichen Glückwunsch, ihr habt eure erste Änderungen im OSM Kartenwerk vorgenommen.

Fazit

Also noch leichter kann man es wirklich nicht mehr machen. Die App ist wirklich klasse um schnell kleine Änderungen einzupflegen. Ich nutze die App zur Zeit mehrmals am Tag und ich bin total begeistert.

Nutzt sie einfach.

Bild von via IO-Images pixabay / Lizenz: CC0 Public Domain

Eine eigene Cloud ist abgesehen von gar keiner Cloud die sicherste Alternative. Vorbei sind aber die Zeiten, da man hier nur zu einem Anbieter greifen konnte. Neben Spezialisten wie Seafile oder Pydio dominieren hier vor allem die beiden Konkurrenten ownCloud und Nextcloud. Letzteres ist dabei das Ergebnis einer Abspaltung durch Teile der Community und des Gründerteams von ownCloud, weil man mit der Entwicklung unzufrieden war.

Im Zuge der Abspaltung wechselten große Teile der medial wahrnehmbaren Nutzerschaft zu Nextcloud. Das Projekt wirkte frischer, brachte neuen Wind und ownCloud sah ziemlich schnell wie einer toter Zweig der Entwicklung aus. Knapp ein Jahr nach dem Fork bin ich zurück bei ownCloud, weil Nextcloud inzwischen für mich sinnbildlich für all die kleinen Open Source-/Community-Probleme steht.

Natürlich gefiel allen erst einmal die Idee Funktionen, die bis dahin der kommerziellen Enterprise-Variante von ownCloud vorbehalten waren, in den Hauptzweig zu integrieren und für alle nutzbar zu machen. Freibier kommt immer gut an! Nextcloud legte auch ein ordentliches Tempo vor, während ownCloud mit der X genannten Version 10 gerade mal eine Veröffentlichung hervorbrachte, steht Nextcloud bereits bei 12. Ein Hoch auf die Versionitis! Für den Anwender hat sich jedoch kaum etwas getan. Während man bei ownCloud die Konfigurationsoberfläche mal ordentlich strukturiert hat, herrscht bei Nextcloud ein Wildwuchs, den man kaum noch durchblickt. Produktpflege ist ja auch tendenziell nicht so die Stärke von Communityprojekten, weil es oftmals attraktiver ist neue Funktionen zu implementieren. Was nutzt dem Anwender da die höhere Version?

Wo eine höhere Version allerdings mal nötig wäre tut sich nichts. Für macOS ist die aktuelle Client-Version immer noch bei 2.2 und die meisten Linux-Distributionen werden nur noch durch von Dritten gebaute Binaries bedient. Diese sind zudem ziemlich oft fehlerhaft, wie man in den entsprechenden Supportforen mehrfach feststellen musste. Hier kommt dann gerne der Hinweis, selber zu kompilieren, der Quellcode ist ja da. Der einfache Anwender ist da mal wieder aus den Augen verloren. Müßig zu erwähnen, dass bei ownCloud die Clientversionen für alle Betriebssysteme auf dem aktuellen Stand sind.

OwnCloud ist vielleicht nicht so angesagt, die Entwicklung bei Nextcloud eventuell auch viel agiler. Dafür schafft ownCloud ein gepflegtes Produkt und stellt für die Anwender leicht zu installierende Clients bereit - Dinge, auf die das agile Communityprojekt Nextcloud scheinbar nicht so viel wert legt. Ich bin vorerst zurück bei ownCloud und beobachte wohin sich beide gegabelten Zweige entwickeln.

Auf meinen Artikel “OPENSTREETMAPS PFLEGEN” hat sich ein Leser (Sven) bei mir gemeldet, und von der schönen App StreetComplete erzählt.

SC

Installation

Diese App kann man über Google Play, F-Droid oder IzzyOnDroid F-Droid repository installieren.

Nutzung

Diese kleiner App ermöglicht dem Benutzer ohne großes Fachwissen, ein Teil der OSM Community zu werden. Durch das hinzufügen des persönlichen OSM Accounts in den Einstellungen, kann es auch schon direkt los gehen.

Beim starten der App, sucht die App den aktuellen Standort und prüft im Hintergrund, ob es unfertige Angaben gibt. Diese unfertigen Angaben können z.B. sein:

  • Straßentyp (befestigt, unbefestigt)
  • Hausnummern
  • Straßennamen
  • Öffnungszeiten
  • Stockwerke
  • Dachform
  • etc.

Durch das klicken auf das entsprechende Icon:

Stick

öffnet sich im unteren Teil der App ein entsprechendes Bearbeitungsfenster. Nichts großes, Schlank und Rank, kurze Frage, wie z.B.

Wie ist der Name dieser Straße?

Schnell die Antwort eingetippt und fertig. In der Standardeinstellungen, werden die Änderungen Sofort hochgeladen.

Herzlichen Glückwunsch, ihr habt eure erste Änderungen im OSM Kartenwerk vorgenommen.

Fazit

Also noch leichter kann man es wirklich nicht mehr machen. Die App ist wirklich klasse um schnell kleine Änderungen einzupflegen. Ich nutze die App zur Zeit mehrmals am Tag und ich bin total begeistert.

Nutzt sie einfach.

Auf meinen Artikel “OPENSTREETMAPS PFLEGEN” hat sich ein Leser (Sven) bei mir gemeldet, und von der schönen App StreetComplete erzählt.

SC

Installation

Diese App kann man über Google Play, F-Droid oder IzzyOnDroid F-Droid repository installieren.

Nutzung

Diese kleiner App ermöglicht dem Benutzer ohne großes Fachwissen, ein Teil der OSM Community zu werden. Durch das hinzufügen des persönlichen OSM Accounts in den Einstellungen, kann es auch schon direkt los gehen.

Beim starten der App, sucht die App den aktuellen Standort und prüft im Hintergrund, ob es unfertige Angaben gibt. Diese unfertigen Angaben können z.B. sein:

  • Straßentyp (befestigt, unbefestigt)
  • Hausnummern
  • Straßennamen
  • Öffnungszeiten
  • Stockwerke
  • Dachform
  • etc.

Durch das klicken auf das entsprechende Icon:

Stick

öffnet sich im unteren Teil der App ein entsprechendes Bearbeitungsfenster. Nichts großes, Schlank und Rank, kurze Frage, wie z.B.

Wie ist der Name dieser Straße?

Schnell die Antwort eingetippt und fertig. In der Standardeinstellungen, werden die Änderungen Sofort hochgeladen.

Herzlichen Glückwunsch, ihr habt eure erste Änderungen im OSM Kartenwerk vorgenommen.

Fazit

Also noch leichter kann man es wirklich nicht mehr machen. Die App ist wirklich klasse um schnell kleine Änderungen einzupflegen. Ich nutze die App zur Zeit mehrmals am Tag und ich bin total begeistert.

Nutzt sie einfach.

17. Juli 2017

Thunder Lotus Games verschenkt bei Steam den Titel Jotun: Valhalla Edition. Die Gratis-Aktion endet allerdings am 17.7. – Also Heute – um 18 Uhr. Linux und ein Steam-Account sind nötig, um das Spiel zu installieren. Das Spiel bleibt dauerhaft im Account.

Jotun ist ein Computerspiel aus dem Jahr 2016. In dem handgezeichneten Action-Adventure nach dem Vorbild nordischer Mythologie, spielst du Thora, eine Wikingerkriegerin, die einen ruhmlosen Tod starb und sich vor den Göttern beweisen muss, um Walhalla zu erreichen.

GameStar schreibt:

Zum Sterben schön. Jotun verzaubert mit wunderschöner Zeichentrickoptik, verbirgt hinter der zuckersüßen Fassade aber ein anderes Gesicht.

Siehe auch: http://store.steampowered.com/news/30750/, http://store.steampowered.com/app/323580/Jotun_Valhalla_Edition/, http://jotungame.com/, https://en.wikipedia.org/wiki/Jotun_(video_game)

16. Juli 2017

Wenn ich gefragt werde, mit welcher Distribution man anfangen sollte, lautet meine Antwort in der Regel nicht Ubuntu sondern Mageia. Version 6 wurde heute veröffentlicht.

Die neue Version setzt nun auf die LTS-Version 5.8 von KDE Plasma und auf den LTS-Kernel 4.9. Zum bisherigen Paketmanager urpmi hat nun DNF 2 einzug gehalten. Weiterhin wurde auf ARMv5 und ARMv7 portiert, so dass man nun Mageia z. B. auf einem Raspberry Pi installieren kann.

Eine detaillierte Zusammenfassung der Änderungen / Neuerungen findet man im offiziellen Wiki. Ein Download der Iso-Dateien ist über die offizielle Seite möglich.

Mit der üblichen Verspätung ist Fedora 26 vor einigen Tagen fertig geworden. Fedora zählt seit Jahren zu meinen Lieblingsdistributionen, vor allem deswegen, weil sich damit neue Linux-Features frühzeitig ausprobieren lassen. So hatte ich auch Fedora 26 schon seit der Alpha-Version im Einsatz — und das weitgehend ohne Probleme. Dieser Artikel gibt eine Kurzvorstellung von Fedora 26 und setzt den Schwerpunkt auf Wayland.

[Update 17.7.: Fedora verwendet Wayland schon seit Version 25 standardmäßig, wie ich ja schon selbst berichtet habe. In der ersten Version dieses Texts hatte ich geschrieben, dies sei erst mit Version 26 der Fall. Ich habe den Text nach einem Leserhinweis korrigiert.]

Standardmäßig kommt Wayland zum Einsatz, der X Window Server wird aber weiterhin als Option beim Login angeboten

Installation

An der Installation hat sich grundsätzlich nichts geändert — bis auf ein Detail: Fedora stellt mit der »Blivet GUI« ein zweites Werkzeug zur Festplattenpartitionierung zur Auswahl. Das Installationsprogramm stellt es als Profi-Werkzeug vor und rät normalen Nutzern von seiner Anwendung ab. Persönlich sehe ich es eher umgekehrt: Selbst nach mehreren Jahren fällt es mir schwer, die Logik des »normalen« Partititionseditor zu durchblicken.

Die neue Blivet GUI funktioniert dagegen so wie die Partitionierungswerkzeuge vieler anderer Distributionen. In der linken Seitenleiste werden die auf dem Rechner vorgefundenen Festplatten, SSDs und LVM-Systeme angezeigt. Zum gerade ausgewählten Element zeigt der Hauptbereich des Editors dann die Liste der Partitionen bzw. Logical Volumes (LVs) an. Über Buttons und Kontextmenükommandos können Sie nun Partitionen und LVs ändern, neu einrichten oder löschen.

Die »Blivet GUI« ist ein alternativer Partitionseditor, der während der Installation eingesetzt werden kann.

Der Goldstandard unter den Partitionierungswerkzeugen ist meiner Ansicht nach noch immer SUSE. Aber mit der Blivet GUI steht nun auch unter Fedora wieder ein in der Logik begreifbares Werkzeug zur Verfügung.

Versionsnummern

Basis           Desktop            Programmierung    Server
--------------  ------------------ --------------    --------------
Kernel    4.11  Gnome        3.24  bash       4.4    Apache     2.4
glibc     2.25  Firefox        54  gcc        7.1    CUPS       2.2
X-Server  1.19  Gimp          2.8  Java         8    MariaDB   10.1
Wayland   1.13  LibreOffice   5.3  PHP        7.1    OpenSSH    7.5
Mesa      17.1  Thunderbird    52  Python     3.6    qemu/KVM   2.9
Systemd    233                                       Postfix    3.2
NetworkMan 1.8                                       Samba      4.6
GRUB      2.02 

Eine bemerkenswerte Nebensächlichkeit: Nachdem die wichtigsten MP3-Patente ausgelaufen sind, enthält Fedora bereits seit Version 25 standardmäßig alle erforderlichen Bibliotheken zum Abspielen von MP3-Dateien. Selbst lame (ein MP3-Encoder) kann aus den offiziellen Paketquellen installiert werden. (Bisher standen diese Pakete in der rpmfusion-Paketquelle zur Verfügung. Diese Paketquelle brauchen Sie aber weiterhin, wenn Sie unter Fedora eine zeitgemäße Multimedia-Unterstützung wünschen oder andere, offiziell nicht unterstützte Pakete benötigen.)

Die Paketverwaltungs-Software DNF wurde auf Version 2 aktualisiert. Spürbare Änderungen gibt es keine, aber hinter den Kulissen hat sich offensichtlich einiges getan (Changes in DNF 2).

Der Touchpad-Treiber Synaptic wurde zugunsten von libinput in den Ruhestand geschickt (siehe die Release Notes). Zur Not steht aber das Paket xorg-x11-drv-synaptics-legacy zur Verfügung.

Wayland

Eines gleich vorweg: Wayland ist kein Programm, sondern »nur« ein Protokoll für die Kommunikation zwischen dem Wayland Compositor (einem Display-Server) und grafischen Anwendungsprogrammen (Clients). Das ist ein gravierender Unterschied zu X, wo es ein richtiges Client/Server-Modell gibt und der X-Server im Hintergrund läuft.

Wayland greift teilweise auf dieselben im Kernel verankerten Mechanismen bzw. Treiber zurück wie X. Dazu zählen die Verarbeitung von Eingaben (libinput), die Einstellung der Auflösung (Kernel Mode Setting = KMS) und der Zugriff auf den Video-Speicher (Direct Rendering Manager = DRM). Insofern erfindet Wayland das Rad nicht neu, sondern greift auf viele Bausteine zurück, die auch unter X eingesetzt werden. Grundlegend anders als unter X erfolgt die Kommunikation mit den 3D-Funktionen der Mesa-Bibliothek über die Schnittstelle EGL. Für die Kompatibilität zu alten X-Programmen ist Xwayland zuständig.

Während unter X ein eigener Window Manager für die Dekoration der Fenster zuständig ist, übernimmt diese Aufgabe der Wayland Compositor. Dieses Programm kümmert sich auch um Aufgaben, die unter X der Xorg-Server übernimmt
— z.B. um die Verarbeitung von Eingaben. Insofern gibt es eine Menge Details, die nicht davon abhängig sind, wie Wayland funktioniert, sondern wie der Wayland Compositor für das jeweilige Desktop-System implementiert ist.

Wenn Gnome unter Wayland läuft, dann fungiert Mutter als Wayland Compositor. Mutter wird nicht als eigenständiges Programm ausgeführt, sondern in Form von Bibliotheken, mit denen die Gnome Shell verlinkt ist. (Aktuell ist Gnome das einzige Desktop-System, dessen Wayland Compositor stabil funktioniert. Bei KDE sind die Arbeiten auch schon relativ weit fortgeschritten. Die Neon-Distribution experimentiert gegenwärtig mit Wayland, will Wayland aber frühestens 2018 standardmäßig aktivieren.)

Läuft Wayland oder X?

Ein Blick in die Prozessliste verrät, ob X (genau genommen der X-Server mit dem Programmnamen Xorg) oder Wayland läuft (genau genommen die Kompatibilitätsschicht zu X, weil es ja keinen eigenen Wayland-Prozess gibt):

ps ax | egrep -i "xorg|wayland"

    898 tty1     Ssl+   0:00 /usr/libexec/gdm-wayland-session ...
   1058 tty1     Sl+    0:00 /usr/bin/Xwayland :1024 -rootless ...

Bei der Interpretation des Ergebnisses müssen Sie aber aufpassen. Das Grafiksystem wird nämlich zweimal gestartet: einmal zur Anzeige der Login-Box (dafür ist der sogenannte Display Manager zuständig) und noch einmal nach dem Login für den Desktop des eingeloggten Benutzers. Fedora hat den Display Manager schon in Version 24 standardmäßig auf Wayland umgestellt, den Gnome-Desktop aber erst in Version 26.

Gewissheit gibt das Kommando loginctl, das alle Sessions unter der Kontrolle von systemd ausgibt:

loginctl

SESSION     UID   USER     SEAT   TTY             
     c1      42   gdm      seat0  /dev/tty1       
      2    1000   kofler   seat0  /dev/tty2       
      4    1000   kofler

Auf der Konsole 1 läuft also der Display Manager gdm. Auf Konsole 2 läuft ein Desktop-System, in dem der Benutzer kofler eingeloggt ist.

Im zweiten Schritt können Sie nun Details zu einer Session ermitteln und so unter anderem feststellen, ob die Session X, Wayland oder nur eine TTY-Schnittstelle verwendet, wie dies bei SSH-Logins oder beim Arbeiten in einer Textkonsole der Fall ist:

loginctl show-session -p Type 2

  Type=wayland

Wayland-Einschränkungen

Eigentlich sollten gewöhnliche Linux-Benutzer nicht merken, ob das Grafiksystem nun auf X oder auf Wayland basiert. Tatsächlich ist das auch schon weitestgehend der Fall — gäbe es nicht diverse Einschränkungen:

  • Wayland ist aktuell nicht netzwerktauglich. Sie können also nicht wie unter X ein Grafikprogramm auf dem Host 1 ausführen, dieses aber z.B. via SSH auf dem Host 2 anzeigen und bedienen. Es ist unklar, ob Wayland diese Funktionalität später erhalten wird. Einen Implementierungsversuch hat es schon gegeben, aber er ist gescheitert.
  • Remote-Desktop-Programme wie VNC- oder RDP-Server sind nicht Wayland-kompatibel. Sofern auf dem Rechner alle erforderlichen X-Pakete installiert sind, ist es aber möglich, parallel zu Wayland einen VNC- oder RDP-Server einzurichten. Lokales Arbeiten am Computer erfolgt dann via Wayland, der Netzwerkzugriff hingegen via X. Das erfordert zwangsläufig zwei getrennte Desktop-Sessions. Screen-Sharing ist aktuell mit Wayland nicht möglich. (Das gilt auch für das kommerzielle Programm TeamViewer.)

  • Die meisten Tools zur Aufnahme von Screenshots und Screencasts funktionieren nicht. Das ist eigentlich ein Sicherheits-Feature (It’s not a bug, it’s a feature!): Es soll verhindern, dass ein Programm Informationen eines anderen Programms auslesen kann. Ausgenommen von dieser Einschränkung sind in das Desktop-System integrierte Werkzeuge, also z.B. die Screenshot-Tools von Gnome.

  • Unter Wayland können Sie nicht einfach ein grafisches Programm mit root-Rechten ausführen (z.B. aus einem Terminal heraus, in dem Sie vorher sudo ausgeführt haben). Diese Einschränkung ist gerade für Power-User schwerwiegend und betrifft z.B. das grafische Partitionswerkzeug gparted, diverse Installations- und Setup-Programme, Backup-Tools etc. Selbst ein simpler Start eines Editors oder Dateimanagers mit root-Rechten ist unmöglich. Die Lösung zu diesem Problem soll so aussehen, dass grafische Programme, die root-Rechte benötigen, in zwei Teile getrennt werden: In die Oberfläche, die mit gewöhnlichen Rechten läuft, und in operative Module, die sich via PolicyKit root-Rechte erwerben. Teile der Gnome-Systemeinstellungen funktionieren so (z.B. die Benutzerverwaltung und Software).

  • Diverse X-spezifische Werkzeuge wie xkill, xrandr oder xmodmap können nicht mehr verwendet werden. Nur fallweise gibt es dafür Wayland-spezfischen Ersatz. So kann die Auflösung im laufenden Betrieb durch die Gnome-Einstellungen verändert werden.

  • Spiele können nicht die Auflösung des Grafiksystems ändern.

  • Der proprietäre NVIDIA-Treiber und Wayland sind aktuell inkompatibel zueinander. Im Oktober 2016 gab es zwar Berichte darüber, dass an der Lösung des Problems gearbeitet würde, das Ergebnis steht aber noch aus.

  • Erfreulicherweise funktioniert Wayland mittlerweile sogar unter VirtualBox. Allerdings hat bei meinen Tests dort ständig das Bild geflackert — sicher ein Problem, das Updates in Fedora oder in VirtualBox bald lösen werden.

  • Da es unter Wayland anders als bei X keinen zentralen Server-Dienst gibt, fehlt auch ein entsprechendes Fehlerprotokoll (also ein Gegenstück zu /var/log/Xorg.0.log). Tipps zur Fehlersuche bei Wayland-Problemen gibt die folgende Seite: How to debug Wayland problems

Wenn Sie von einer der Wayland-Einschränkungen betroffen sind, ist es das einfachste, Gnome eben unter X auszuführen. Aber es ist jetzt leichter zu verstehen, warum Canonical davor zurückschreckt, Wayland in Version 18.04 per Default zu aktiveren. (Die Entscheidung ist noch nicht gefallen.)

Quellen und Links

Wayland