ArchLinux Image mit qemu reparieren

Klassische stable-release Betriebssysteme sind für die Anwender ein Rund-um-Sorglos Paket. Einmal installiert laufen sie jahrelang ohne Störungen. Bei Rolling-Release Distributionen wie ArchLinux können jedoch tiefergehende Probleme auftauchen die dazu führen, dass das System nicht mehr bootet. Als Ausweg bietet es sich an, eine Ebene oberhalb des Betriebssystems zu gehen. Dort befindet sich beispielsweise der Bootmanager grub2. In diesem kann man mehrere Betriebssysteme gleichzeitig installieren, wenn eines davon strekt hat man noch die anderen zur Auswahl.

Aber, das Partionieren einer Festplatte ist nichts für Einsteiger. Und da Linux gerne mehrere Partitionen auf einmal belegt (swap, boot und root) ist es wohl nur für Profis mögliche, 2 oder nochmehr Linux-Distributionen gleichzeitig zu installieren. Die Alternative dazu ist die Verwendung von dd in Verbindung mit qemu. Mittels dd kann man eine Festplatte klonen inkl. aller Partitionen und in eine raw-Datei schreiben. Mit qemu kann man diese Datei dann in einer virtuellen Maschine booten.

Machen wir doch einmal einen Versuch. Als erstes muss man eine externe Festplatte mounten weil man sonst das Image auf die selbe Platte schreibt, die man kopieren will. Schreibrechte auf die externe Festplatte gibt es dank „sudo chmod 0777 /drive“ und jetzt kann man auch schon den dd Befehl einsetzen, um /dev/sda zu klonen:

dd if=/dev/sda conv=sync,noerror bs=64K | gzip -c  > ./backup.img.gz

Eine Statusanzeige gibt es nicht, der Progress-Schalter der im ArchWiki https://wiki.archlinux.org/index.php/disk_cloning erwähnt wird funktioniert nicht. Aber egal, dafür kann man zusehen, wie die image-Datei rasant an Größe gewinnt. Der Flaschenhals dabei ist weniger das gzip Tool und auch nicht die Blockgröße von 64k, sondern die Datenrate der USB Schnittstelle, mit der die externe Festplatte angeschlossen ist.

Nachdem man den Befehl ausgeführt hat, ist eine Festplatte die ursprünglich 120 GB groß war auf eine 60 GB .gz Datei komprimiert worden. Auf der Festplatte befanden sich ursprünglich 40 GB an Daten, warum die .gz Datei trotzdem größer ist, bleibt unklar. Wenn man diese versucht mittels qemu zu starten, erscheint die Meldung dass die Bootdisk fehlerhaft sei. Genauer gesagt heißt die Fehlermeldung „No bootable device“.

Nachdem die Datei jedoch entpackt wurde und erneut über qemu gestartet wird,

gunzip -c backup.img.gz > backup.img
qemu-system-x86_64 -hda backup.img -m 1024 -enable-kvm

erhält man eine perfekt startende virtuelle Maschine. Also eine virtuelle Kopie des ursprünglichen Computers. Die Geschwindigkeit ist zwar niedrig, weil die 120 GB große backup.img Datei von der externen USB Festplatte gelesen wird, aber sie ist funktionsfähig. Das heißt, alle Daten und alle Programme sind exakt kopiert worden. Und wenn man in dieser .img Datei eine Datei erstellt, also schreibend zugreift, ist sie nach einem Reboot immernoch vorhanden.

Advertisements

Kritik an ArchLinux

Auf den ersten Blick erscheint ArchLinux als gute Alternative zu dem behäbig wirkenden Debian und Redhat. Leider handelt es sich dabei um eine Illusion, die so nicht realisierbar ist. Selbst im offiziellen ArchLinux wird bezweifelt, dass man die Distribution für einen Produktiv-Webserver einsetzen kann. Weiterhin stellen Desktop User von ArchLinux regelmäßig fest, dass nach einem Kernel Update plötzlich ihre Grafikkarte nicht mehr erkannt wird. Das mag sinnvoll sein wenn man neue Patches bei kernel.org einreichen will, ist aber bei der täglichen Arbeit der Super-GAU. Und zu guter letzt wird nach der letzten Erhebung über Webserver in der Realität festgestellt, dass zwar Ubuntu, Debian, Redhat und CentOS auf vielen Root-Servern im Internet installiert ist, nicht jedoch Debian SID oder ArchLinux.

Obwohl ArchLinux suggeriert, man könnte das System produktiv sowohl als Desktop als auch als Server einsetzen spricht die Praxis eine andere Sprache. Als Konkurrenz zu Debian SID oder zu Fedora mag es seine Vorteile habe (ich würde sogar sagen, dass ArchLinux die beste Test-Distribution) aber um mit ArchLinux Briefe zu schreiben, im Internet zu surfen oder in C++ zu programmieren eignet sich die Distribution nicht.

Die Nachteile von gängigen Distributionen wie Ubuntu und Co kann man nicht durch den Wechsel auf ein Rolling-Release beheben, sondern sie müssen innerhalb von Stable-Release Zyklen gelöst werden. Es mag auf den ersten Blick verwunderlich klingen, dass man bei Debian lieber ungepatchte Sicherheitslücken im System belässt, anstatt mit häufigen Updates zu arbeiten, aber so ist nunmal der Ablauf. Die Hauptproblematik in der Softwareentwicklung ist, dass man Änderungen nur schwer oder gar nicht in virtuellen Umgebungen automatisiert testen kann. Mit Qemu ist es zwar möglich, zu überprüfen ob nach einem Patch der PC noch bootet, Qemu kann jedoch keine Grafikkarten emulieren oder WLAN Karten nachbilden. Um hier Fehler zu entdecken, muss man den Umweg über reale Hardware gehen und das ist ein sehr langsamer Vorgang. Wenig verwunderlich, dass Ubuntu 6 Monate hinter dem Upstream hinterherhinkt.

Anders ausgedrückt, bei Softwareversionen die nicht im letzten Ubuntu Release enthalten sind, ist die Wahrscheinlichkeit hoch, dass diese auf realer Hardware und auf realen Servern nicht korrekt arbeiten. So dass entweder der Sourcecode selbst noch verbessert werden muss, die Software bestimmte Compiler-Parameter benötigt oder überhaupt nicht für den Produktiveinsatz geeignet ist. Sowenig wie man „Debian SID“ auf einem Produktivserver einsetzen kann, kann man ArchLinux dafür verwenden.

Der Update-Knopf bei ArchLinux

In Betriebssystemen wie Debian oder Ubuntu bedeutet „update“ in aller Regel, dass die neuesten Sicherheitsaktualisierungen eingespielt werden um das System auf den neuesten Stand zu bringen. Bei ArchLinux und Antergos bedeutet Update jedoch etwas vollkommen anderes. Obwohl es vielleicht paradox klingt, aber ein einmalig installiertes ArchLinux System erhält keinerlei Updates. Es gibt nach der Erstinstallation keinerlei Bugfixes oder ähnliches, der Support ist gleich Null. Der Update-Knopf bei ArchLinux macht etwas vollkommen anderes und zwar installiert er das komplette Betriebssystem neu.

Schauen wir uns entsprechend der Guidelines einmal an, wie oft man den Update-Knopf zu drücken hat: einmal täglich. Anders gesagt, soll der Anwender einmal täglich sein komplettes Betriebssystem neu installieren und die dabei auftrentenden Probleme beheben. Wie lange dauert soetwas realistischerweise? Bei Ubuntu benötigt eine Neuinstallation rund 1 Stunde, wenn man die Datensicherung davor und danach gewissenhaft betreibt und wenn Probleme auftreten auch gerne einen kompletten Tag. Bei ArchLinux muss man mit dem selben Zeitaufwand rechnen. Das Problem bei ArchLinux ist, dass es einen reduzierten Updateknopf wo zwar das System aktualisiert wird, aber keine Neuinstallation durchgeführt wird nicht vorhanden ist. Da die wenigsten User Zeit und Muße habe, einmal täglich ihr Betriebssystem neu zu installieren, fällt ArchLinux für den Produktiveinsatz leider aus.

Das ist vielleicht die tragischste Eigenschaft von Rolling-Release Distributionen dass sie keinen eigentlichen Update-Knopf mehr haben. Den Stress den man bei Ubuntu einmal alle 6 Monate hat wenn das neue Release erscheint, gibt es bei ArchLinux einmal täglich. Die Alternative besteht darin, nur alle 6 Monate einmal auf den Update-Button zu klicken was jedoch zahlreiche Sicherheitsprobleme nach sich zieht.

ArchLinux rocks

Nachdem hier einige Linux-Distributionen verglichen wurden kann man einige Dinge geraderücken. Zunächst einmal sind die meisten Linux Distributionen Stable-Release basiert. Sowohl bei Debian als auch bei Redhat arbeitet man nach diesem Konzept. Obwohl die Vermutung naheliegt, dass Redhat als große Firma die bessere Linux-Distribution besitzt der irrt. Wenn man sich einmal konkret anschaut was Fedora, CentOS und Redhat zu bieten haben so wird man enttäuscht sein. Einerseits ist die Aktualisierung mit Bugfixes zwar besser als bei Ubuntu auf der anderen Seite sind viele Pakete im RedHat Universum schlichtweg nicht mit dabei. Lyx lässt sich in Fedora gar nicht installieren, Spiele gibt es bei CentOS auch keine und eine Übersicht welche Pakete in CentOS vorhanden sind, existiert nicht. Beim direkten Vergleich Debian vs Redhat liegt Debian vorne. Mag sein, dass wenn man die Subscription Verson von Redhat gegen ein Debian vergleicht, dass man mit Redhat besser fährt, aber dieser Service ist für Privatanwender schlichtweg zu teuer. Hinzu kommt, dass durch die Kostenbarriere es um Redhat auch keine echte Community gibt, sondern fast alle Informationen werden von oben nach unten hineingedrückt.

Es bleibt noch die alte aber berechtigte Frage zu klären was denn besser ist: Stable-Release oder Rolling-Release. Genaugenommen gibt es also nur eine Frage: Ubuntu oder ArchLinux. Hier ist die Antwort nicht eindeutig. Ubuntu/Debian haben den Vorteil, dass sie stabil laufen und Sicherheitsupdates von alleine eingespielt werden. Es gibt aber den Nachteil, dass nicht alle Pakete aktualisiert werden und dass man bei der Benutzung nicht viel lernen kann. Wenn man hingegen an Linux an sich interessiert ist, dürfte ArchLinux die beste Distribution sein. Einerseits produziert es permanent Fehler auf der anderen Seite ist der Wissenszuwachs beim Anwender nicht zu verachten. Ein Debian oder ein Redhat System kann man theoretisch 10 Jahre lang als Admin betreiben, ohne danach zu wissen wie man einen Kernel kompiliert. Bei ArchLinux gehört das zum Basiswissen. Hier eine subjektive Rangliste der Linux Distributionen:

1. Platz: ArchLinux (das Hackerbetriebssystem schlechthin, sowohl für Programmierer als auch für Gamer geeignet, die ihr System verstehen wollen)
2. Debian/Ubuntu: die beste Stable-Release Distribution welche sowohl auf dem Desktop als auch für Server 24/7 stressfrei betrieben werden kann. Hat aber den Nachteil, dass man nicht wirklich Linux-Wissen dazulernt
3. CentOS/Redhat: Firmen und Behörden lieben diese Distribution. Eigeninitative und Basteln ist verboten.

Warum steht ArchLinux auf Platz1? Weil diese Rangliste weniger den Ist-Zustand als vielmehr eine erwünschte Zukunft wiederspiegelt. ArchLinux ist derzeit die einzigste Distribution bei der Standardmäßig aktuelle Software zum Einsatz kommt. Das heißt, der Upstream wird erstngenommen, die dort erzeugten Verbesserungen werden tatsächlich ausgeliefert. Das mag Probleme bereiten wenn nach einer Aktualisierung das System nicht mehr geht, ist aber längerfristig die einzig gangbare Möglichkeit. Ob es tatsächlich gelingt in der Praxis ArchLinux als einziges System sowohl auf dem Desktop als auch auf dem Server zu betreiben sei dahingestellt. Es gibt derzeit keine Success-Story wo man das im Detail nachlesen kann. Aber zumindest sollte das die Messlatte sein, an der man sich orientiert. Es kann nicht angehen, dass die Zukunft entweder aus verwaisten Debian Packages besteht, die seit 4 Jahren kein Update mehr erhalten haben oder alternativ aus CentOS Installationen die von einem einzigen Hersteller kontrolliert werden.

Umstieg auf ArchLinux erneut gescheitert

Vor einiger Zeit wollte ich bereits auf ArchLinux umsteigen, bin dann aber reumutig zu Ubuntu zurückgekehrt. Grund war damals, dass zwar grundsätzlich ArchLinux das bessere System ist, dass aber die Anforderungen an den Nutzer einfach zu hoch sind.

Vor einiger Zeit erschien das ArchLinux Derivat Antergos was versprach den Umstieg zu erleichtern. Also war es Zeit, erneut den Wechsel auf ein Rolling-Release System zu wagen. Leider war auch dieser Wechsel erfolglos. Antergos lässt sich zwar ähnlich leicht wie Ubuntu installieren (das Menü ist grafisch und Gnome wird vorinstalliert) allerdings treten im echten Betrieb viele kleine wie große Probleme auf. Erstens, fühlt man sich bei Rolling-Release permanent ermuntert auf den Upstream zu schielen um die neuesten Features als erstes zu haben, so dass man stundenlang sich mit neuen Dingen wie Wayland und Co beschäftigt. Auf der anderen Seiten gibt es aber auch echte Hardwareprobleme wie nicht erkannte Touchpads, falsche Grafikkarten usw. Wie auch bei ArchLinux gilt, dass keines dieser Dinge nicht lösbar wäre, aber auch der Antergos User muss im Grunde ein absoluter Linux Experte sein. Das geht sogar soweit, dass man irgendwann auf der Redhat Bugtracker Liste landet, wo dann allen ernstes empfohlen wird, man soll doch einfach den Linux Kernel patchen um so das Grafikkartenproblem zu lösen. Wer das nicht will, sondern einfach nur Spiele spielen fühlt sich da ein wenig verloren.

Lange Rede kurzer Sinn. Obwohl Antergos gut gemeint ist wird es in der Praxis immer Probleme machen. Wirklich einen Vorwurf machen kann man den Entwicklern nicht, weil die meisten Probleme Nutzerbedingt sind. Eher im Gegenteil: die Leute welche ArchLinux und Antergos entwickelt haben, sind topfit. Meiner Meinung nach jedoch hat es gute Gründe warum zwischen Upstream und User eine weitere Schicht (die Ubuntu Distribution) existiert. Technisch mag dieses überflüssig wirken und es behindert vermutlich auch den Fortschritt. Aber dafür fühlt sich der User bei Ubuntu einfach besser aufgehoben.

Es ist unklar, woran das genau liegt. Ich vermute, dass es eigentlich um den Unterschied zwischen RollingRelease vs StableRelease geht. Wenn man beispielsweise Ubuntu SID installiert wird man mit ähnlichen Problemen konfrontiert wie bei ArchLinux. Auch von Ubuntu SID ist abzuraten.

Auf der einen Seite ist es schade, dass ich an dieser Stelle keine Erfolgsmeldung verbreiten kann, dass der Umstieg auf Antergos reibungslos funktioniert hat. Denn im Grunde hätte ich mir gewünscht, dass ein Konzept wie „RollingRelease“ sich durchsetzen wird. Die Vorteile sind überweltigend: erstens, erhält man tagesaktuelle Sicherheitsupdates die es bei Ubuntu nicht gibt und zweitens kann man die ArchLinux DIstribution mit einem Mini-Team aus 25 Leuten erstellen weil im Grunde alles auf nightlybuild basiert.

Ohne Zweifel ist Antergos Linux einmal die Zukunft. Gegenüber Ubuntu ist es das bessere System und der durchdachtere Ansatz. Wenn man jedoch ein Betriebssystem möchte, was ein weniger perfekt ist aber dafür gnädiger mit dem User umgeht, der sollte bei Ubuntu bleiben. Vielleicht nicht gerade ein Ubuntu LTS wo die Versorgung mit Updates wirklich schlecht ist, sondern nur das normale Ubuntu was im 6 Monatsrhytmus aktualisiert wird.

Gerade bei OpenSource Software die auf sehr vielen unterschiedlichen Endgeräten läuft, darf man nicht die sozialen Dinge unterschätzen. Anders als es bei ArchLinux postuliert wird, geht es eben nicht nur um Softwareentwicklung, sondern es geht darum mit den dabei entstehenden Frustrationen angemessen umgehen zu lernen. Man kann auch nicht wirklich von Betriebssystemen sprechen sondern sollte das ganze eher als Lernumgebung bezeichnen. Das heißt, Leute die noch viel lernen müssen wählen Ubuntu und Leute die schon im Upstream mitentwickeln nehmen ArchLinux.

UBUNTU
Zugegeben, im Ubuntu Projekt läuft eine Menge falsch. Der Teamleiter Marc Shuttleworth ist ein Träumer der zwar Menschen begeistert aber keine Ahnung hat von Software. Die Leute welche Ubuntu Packages maintainen sind ebenfalls primär daran interessiert ihre Wichtigkeit für das Projekt zu betonen selbst wenn darunter die Software leidet. Und die Ubuntu Anwender sind nichts anderes als Windows-Umsteiger die sich in Wahrheit nie mit Linux haben anfreunden können. Im Gegensatz dazu sind bei der ArchLinux Community viel bessere Strukturen vorhanden. ArchLinux baut komplett auf dem Konzept des nightlybuild auf, was bedeutet, dass die Distribution von Scripten und nicht von Menschen erstellt wird. Eine maximale Effizienz ist die Folge. Dementsprechend sind ArchLinux Programmierer auch deutlich progressiver ausgerichtet. Sie interessieren sich nicht nur für gesellschaftliche Themen wie Umweltschutz oder Bildung sondern sind auch am Kernel, an C++ und Maschineller Intelligenz interessiert.

SOURCECODE
Wenn man auf Linie mit RollingRolease und ArchLinux ist, so ist manuelles Backporting Zeitverschwendung genauso wie das Zurückhalten von neuer Features zugunsten eines vermeintlich stabilen Systems. Demzufolge ist die überwiegende Arbeit welche Debian-Maintainer leisten überflüssig und nutzlos. Aber, geht es wirklich nur darum ein Betriebssystem zu programmieren im Upstream oder ist Ubuntu nichtvielmehr eine Lernumgebung bei der ganz bewusst überflüssige Arbeit geleistet wird aus didaktiven Gründen? Man kann sich das ungefähr so vorstellen: natürlich sind die Mofikationen welche durch Ubuntu Maintainer eingebracht werden nutzlos, weil beim nächsten Release-Zyklus ohnehin das nightly-build des Debian SID verwendet wird. Aber wenn man keine Backports erstellt kann man auch nichts lernen. Im Grunde ist Debian / Ubuntu eine Parallelentwicklung zu Fedora und ArchLinux. Es geht nicht so sehr um Resltate oder die neusten Kernel-Features sondern es geht um kreatives Spielen was kein Ziel verfolgt.

Die Ubuntu Community kann was die Manpower, den technischen Sachverstand und Innovationen angeht nicht mit richtigen Linux-Distributionen wie ArchLinux mithalten. Bei Ubuntu wird Unity genutzt obwohl Gnome3 das bessere System ist, bei Debian wird Systemd verhindert obwohl alle wissen, dass das die Zukunft ist — aber ist Leistung wirklich der einzige Maßstab? Schaut man sich die Philosophie hinter Ubuntu etwas näher an, so wird das bezweifelt. Natürlich kann Ubuntu nicht mit Fedora konkurrieren, dafür wurde es nicht gegründet. Sondern Ubuntu ist eher ein Schonraum für Leute, die nicht fit genug sind für das Tempo auf der Kernel Mailing Liste, die nicht in der Lage sind mit Linus Torvalds sachlich über Probleme zu diskutieren weil sie dabei den kürzeren ziehen würden.

DEBIAN
Um den technischen Zustand des Debian Projektes ist es nicht besonders gut bestellt. Objektiv betrachtet haben die darin vertretenden Maintainer keine Ahnung von dem was sie da tun. Auf einer Debconf meinte ein Mann auf der Bühne, der für das Debian Projekt gesprochen hat, dass er selbst gar kein Debian auf seinem Laptop installiert hat sondern mit Windows 8 arbeitet und bei Debian nur mit dabei ist, weil ihm das Team sogut gefällt. Noch expliziter sagen, was man Debian hält kann man wohl nicht.

Aber ist dieser mangelnde technische Sachverstand wirklich ein Problem? Muss man bei Debian und Ubuntu das Niveau erhöhen und die Leute auf Kurs bringen? Schauen wir unsmal die Philosophie des Projektes an: es wird ein integrativer Ansatz bevorzugt bei dem anders als beim Team rund um Linus Torvalds eben nicht in der Sache gestritten wird, sondern es um einen Wohlfühlraum geht bei dem gegenseitiger Respekt wichtig ist. So eine Arbeitsatomosphäre hat zur Folge dass man sich ausruhen kann und auf Leistung kein Wert gelegt wird. Es hat zur Folge dass die Qualität der Software leidet und man den Anwender stattdessen mit warmen Worten trösten muss wenn seine Spiele nicht laufen.

Antergos — -Ein Blick zurück

Was hat der Umstieg auf Antergos/ArchLinux gebracht? Die ehrliche Antwort lautet: gar nichts, weil nach wie vor Ubuntu mein Hauptbetriebssystem ist. Im Grunde ist Antergos vielmehr eine Aussicht auf eine mögliche Zukunft wo Betriebssysteme deutlich leichter funktionieren als es heute ist. Eine Welt wo Rolling-Release tatsächlich praktiziert wird.

Das Hauptproblem mit Antergos Linux ist, dass es ähnlich wie Debian SID nach dem Rolling-Release Prinzip arbeitet. Das ist ein sehr fortschrittliches Entwicklungsmodell was einen Effizienzvorteil verspricht. Mit Rolling-Release könnte man im Grunde die 8000 Ubuntu Maintainer die sich heute für gesellschaftliche Themen der Informatik stark machen durch ein Build-Script ersetzen was den Upstream-Sourcecode in Binärcode übersetzt. Vollautomatisch und nachts. Das Problem damit ist jedoch, dass dieses Konzept zuweit vorausgreift, die Welt ist noch nicht so weit.

In der Praxis wird man als Fallback nicht etwa auf eine ältere Version von Antergos zurückfallen wo man dann mittels Rescue-USB-Stick das Problem fixt, sondern in der Praxis fällt man auch bei Antergos auf Ubuntu zurück. Genauer gesagt besteht die Gefahr bei Rolling-Release dass im Worst-Case man eben doch wieder ein stable-Release System einsetzen muss. Da Antergos jedoch keine stable-Releases anbietet bleibt nur Ubuntu übrig.

Natürlich kann man stable-Release und Rolling-Release ergänzend einsetzen, beispielsweise als Dual-Boot-System. Was in der Praxis jedoch nicht funktioniert ist es, vollständig auf Rolling-Release umzusteigen weil man dann möglicherweise den Rechner nicht mehr starten kann.

Wayland in ArchLinux

bildschirmfoto-von-2016-09-20-09-56-29

Um das neue Wayland auszuprobieren was bei Fedora Rawhide schon eine Weile vorinstalliert ist, muss man in ArchLinux eingeben: „pacman -S wayland weston xwayland“ und kann dann im Login-Manager auswählen „Gnome unter Wayland“. Viel verändert hat sich nicht, es sieht alles noch genauso aus. Insbesondere wenn man weiß, dass Anwendungen ohnehin nur in xwayland gestartet werden, also in Wayland nochmal eine X.org Simulation durchgeführt wird.

Ein weiterer Kritikpunkt ist, dass out-of-the-box das Trackpad nicht korrekt funktioniert. Das Scrolling geht nicht. Wo man das umstellt ist unklar, in der weston.ini Datei offenbar nicht. https://bugzilla.redhat.com/show_bug.cgi?id=1350084

Es gibt zwar im Internet einige Foreneinträge die sich dieser Frage annehmen, doch funktionieren tut davon aktuell nichts. Es ist aber Hoffnung in Sicht: angeblich soll ab Gnome 3.22 das Settingsmenu deutlich angenehmer gestaltet sein, so dass man mit etwas Glück dort einfach die Option auswählen kann.

Es bleibt die Frage, wozu der Wechsel auf Wayland? Eine Antwort darauf liefert chromium. Wenn man diesen Webbrowser in Wayland startet, erscheint in der Statusleiste irgendwas von „gpu in usage“, was schonmal ein gutes Zeichen ist. Es besteht also Grund zur Hoffnung, dass sich mit Wayland die GPU beschleunigte Ausgabe verbessert und so Youtube weniger CPU Last benötigt? Bisher ist davon leider noch nichts zu merken: spielt man ein Video ab, geht der CPU Load auf konstant 50% hoch und bleibt dort. Aber zumindest besteht die Hoffnung dass Wayland hier in Zukunft die Lage etwas entspannt, damit auch Linux Nutzer in den Genuss von effizienter Bildausgabe kommen. Mal abwarten, was sich das Freedesktop Konsortium da noch einfallen lässt.

Leider ist es nicht möglich, Wayland in Kombination mit LXDE zu benutzen. Außer Gnome unter Wayland kann man höchstens noch Weston pur starten, was nicht viel anders aussieht als ein OpenBox mit einer Menüleiste am oberen Rand ansonsten aber keinerlei Programmstarter enthält.

UPDATE
Im längeren Betrieb scheint die Mischung aus Wayland und Chromium tatsächlich weniger CPU Load zu verursachen. Selbst auf einem älteren Notebook bleibt der Lüfter angenehm ruhig. Offenbar wird die Grafikausgabe effizienter erzeugt. Dennoch ist die nominelle Auslastung die im Systemmonitor angezeigt wird konstant hoch.