Ubuntu wechselt die Benutzeroberfläche und die Welt geht unter

Ubuntu stampft also Unity ein und wechselt auf Gnome. Das sollte inzwischen eigentlich fast jeder mitgekommen haben. Aber was soll der ganze Aufriss? Die Erde dreht sich auch morgen noch und das Ende von Linux ist dadurch auch nicht eingeläutet.

Aber trotzdem wird das Thema in den letzten Tagen wie die Sau durchs Dorf getrieben (jep, ich renne gerade auch hinter der Sau her) und geforkt bis der Arzt kommt. Scheinbar bin ich einer der Wenigen, die den Umstieg auf Gnome vorsichtig optimistisch sehen. Und das obwohl mir Gnome komplett am Podex vorbeigeht. Genauso wie Unity, Canonical und Ubuntu sowie deren Forks. Scheinbar ist endlich mal Schluss mit den Alleingängen von Canonical (Mir, Unity usw.). Unity zum Beispiel braucht einen ziemlichen Aufwand um überhaupt abseits von Ubuntu (oder einem Fork) nutzbar zu sein. Ich möchte nicht wissen wie viele Stunden die Leute hinter Unity-For-Arch hier investiert haben.

Zukünftig soll nun Gnome die Wahl sein. Eine Desktop-Umgebung die auch von einigen anderen Distributionen abseits von Ubuntu eingesetzt wird. Sollte sich hier Canonical positiv einbringen, profitieren dann auch andere von diesen Änderungen / Neuerungen. Sofern diese überhaupt Einzug in Gnome halten. Gefühlt (da ich Gnome ja nicht selbst nutzt) werden ja lieber Funktionen entfernt statt hinzugefügt. Aber das ist ein anderes Thema.

Von daher stelle ich mir noch einmal die Frage, was soll der Aufriss?

Und selbst wenn mit der Abkehr von Unity das Ende von Ubuntu eingeläutet wurde (wovon ich nicht ausgehe) dann bleiben doch immer noch andere Distributionen wie OpenSuse oder Mageia übrig. Letztere, damals noch als Mandrake bzw. Mandriva bekannt, war schon immer sehr einsteigerfreundlich. Und das Jahre bevor es Ubuntu überhaupt gegeben hat. Leider war das Unternehmen dahinter nicht in der Lage soviel Marketing zu betreiben wie Canonical.

Von daher… Die Welt wird sich auch ohne Unity noch drehen. Egal ob nun mit Gnome, XFCE, LXQT oder KDE.

Das Ende von WordPress naht

Vor einigen Monaten hatte ich hier schon mal geschrieben, dass ich WordPress den Rücken kehren will. Als neue Plattform habe ich Bolt CMS gewählt. Der Wechsel ist in letzter Zeit aus beruflichen Gründen, aber auch weil ich wenig Lust hatte, ins Stocken geraten. Aber es geht in die nächste Runde.

Seit heute bin ich quasi in der Beta-Phase angekommen. Was das Template betrifft, habe ich es bewusst schlicht gehalten. Und das nicht nur weil ich von Grafikbearbeitung keine Ahnung habe.

Das Template an sich ist aktuell gerade mal 18 KB groß und besteht aus 10 Dateien (inkl. Bilddateien, exklusive Webfonts). Allerdings blähen die eingebetten Webfonts (EOT, SVG, TTF, WOFF und WOFF2) das ganz auf 1,9 MB auf. Bezüglich der CSS-Datei lässt sich vermutlich noch das eine oder andere KB einsparen, da viele Einträge nicht genutzt werden.

Was mir allerdings richtige Sorgen gemacht hat, war der Import der WordPress-Artikel. Denn hier gibt es leider keine Erweiterung die unter Bolt CMS 3.x funktioniert. Ich habe mir daher ein abenteuerliche Lösung selbst gebaut. Leider hat diese aktuell noch dermaßen Ecken und Kanten, so dass ich vermutlich auch gleich die Artikel per Copy and Paste übertragen hätte können. Von der Entwicklungsdauer will ich erst gar nicht anfangen. Zudem sind bei einigen Artikeln Nachbesserungen nötig (spezielle Formatierungen von WordPress-Erweiterungen usw.). Kurz gesagt, der Import war zum kotzen. Vermutlich wäre das aber auch so spaßig geworden, hätte ich auf ein anderes System gesetzt.

Ein weiteres Sorgenkind ist die Suchfunktion. Ich habe unter Bolt das Routing so geändert, dass die Links nicht https://planetlinux.de/entrie/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux lautet sondern https://planetlinux.de/deutschsprachiger-usenet-server-mit-schwerpunkt-arch-linux. Dann zickt allerdings die Suchfunktion von Bolt. Allerdings bin ich mir nicht sicher, ob es wirklich an Bolt liegt oder ob ich hier das Problem bin. Hiermit werde ich die Entwickler von Bolt bzw. die Gemeinschaft um Bolt wohl noch mal um Hilfe bitten müssen. Alternativ überlege ich mir auch, ob ich überhaupt eine SuFu brauche…

Ansonsten läuft alles genauso wie ich es mir vorgestellt habe. Schnell, stabil und resourcenschonend. Im Debug-Modus werden gerade mal 2 MB in der Spitze verbraucht. Mein PHP Speicherlimit liegt bei 128 MB. Wenn ich den Debug-Modus deaktiviere, wird vermutlich noch weniger Speicher benötigt. Alles in allem war der Wechsel die richtige Entscheidung für mich. Vor allem wenn es um die Templates geht.

Raspberry Pi – Gefälschte Echtzeituhr

Da die Raspberry Pi nicht mit einer Echtzeituhr ausgerüstet sind, stellt dich das Datum nach jedem Reboot erst einmal auf den 01.01.1970 00:00 Uhr.

Wer seinem Raspberry kein RTC-Modul (z. B. DS3231) spendieren möchte und es mit der Zeit nicht ganz so genau nimmt, kann schummeln und sich fake-hwclock installieren. Hiermit wird die aktuelle Uhrzeit des Raspberry Pi periodisch sowie beim Herunterfahren in eine Datei gespeichert und beim Booten wiederhergestellt. In Verbindung mit einem NTP-Client lässt sich so die Uhrzeit des Raspberry Pi durchgehend halbwegs aktuell halten.

Benutzer von nano können sich nun in den elitären Olymp erheben

Wer nano als Editor benutzt braucht sich zukünftig keine dummen Sprüche überheblicher Linuxer mehr anhören. Ab sofort können Nutzer von nano nun Neovim einsetzen und sich somit in dem Olymp erheben und sich zu dem elitären Teil der Vim-Nutzer gesellen.

Um Teil der elitären Gesellschaft zu werden, installiert man sich einfach Neovim sowie vim-nano und ruft Neovim mittels „nvim -u nano.vim“ auf. Und schon steht Neovim in der gewohnten Optik von nano zur Verfügung.

Dank des Entwicklers Nimesh Ghelani können nun auch Nutzer von nano mit stolz geschwellter Brust das Haus verlassen und müssen sich nicht mehr in dunklen Ecken verbergen.

Wie Probleme zwischen sddm und den Nvidia-Treibern mein Problem mit Steam gelöst haben

Vor ein paar Wochen wurden die Nvidia-Treiber unter Arch auf Version 378.13 aktualisiert. Eine Installation und ein Neustart hatten immer einen black Screen auf beiden Monitoren zur Folge. Journalctl war der Meinung dass sddm nichts mit der OpenGL-Version anfangen kann (Unrecognized OpenGL Version).

Da alle Suchergebnisse, die sich auf „Unrecognized OpenGL Version“ beziehen, absolut nichts gebracht haben, habe ich ein Downgrade der Pakete nvidia-dkms sowie nvidia-utils gewagt. Hierzu habe ich das Tool downgrade aus dem AUR verwendet und beide Pakete in Version 375.26-2 installiert. Und siehe da, sddm hat wieder funktioniert und ich konnte mich normal an KDE Plasma anmelden.

Am Wochenende hatte ich jetzt mal etwas Zeit und ich habe mich auf das Problem gestürzt, da man Downgrades unter Arch eigentlich vermeiden sollte. Da Version 375.26-2 ja funktioniert ging ich davon aus, dass Version 378.13 das Problem ist. Und ich sollte mich irren. Nach x Fehlversuchen habe ich wieder die alte, funktionierende Version der Nvidia-Treiber installiert und wollte fürs erste erst einmal aufgeben. Irgendwie bin ich dann noch auf die Idee gekommen mir glxinfo aus dem AUR zu installieren. Nachdem ich dann glxinfo | grep OpenGL ausgeführt habe, ist mir mein Gesicht mal so richtig eingeschlafen. Eigentlich hatte ich erwartet, dass die Ausgabe etwas mit Nvidia ausspuckt. Statt dessen wurde ich mit Mesa konfrontiert. Um es mal mit dem fränkischen Fragewort auszudrücken… Hä?

Böses ahnend habe ich dann mal nachgeschaut, ob die Pakete nvidia-libgl und lib32-nvidia-libgl installiert sind. Natürlich nicht. Aber warum nicht? Ich bin mir absolut sicher, dass ich diese Pakete installiert hatte. Und ich habe absolut keinen Schimmer warum ich diese deinstalliert haben sollte. Hier wären wir dann wieder beim fränkischen Fragewort mit zwei Buchstaben.

Nachdem ich dann beide Pakete installiert und die Nvidia-Treiber aktualisiert hatte, hatte auch sddm wieder ein Einsehen und der Rechner konnte wie gewohnt gestartet werden.

Einen schönen Nebeneffekt hat das Ganze auch noch. Vor einigen Wochen hatte ich nach einem Update von Steam festgestellt, dass alle Spiele total ruckeln und quasi unspielbar waren. Da ich aktuell fast nur Overwatch bzw. Quake Live unter Windows spiele, habe ich mich damit aber nicht befasst. Aber wenigstens hatte ich am Wochenende mal einen halbwegs vorzeigbaren Geistesblitz und habe 1 und 1 zusammengezählt. Nach mehreren Runden CS:GO war ich mir sicher, dass das Problem mit Steam ebenfalls an den fehlenden libgl-Paketen lag.

Warum aber Version 375.26-2 funktioniert und wieso die libgl-Pakete bei mir nicht (mehr) installiert waren, wird wohl ein Rätsel bleiben. Allerdings haben auch einige andere Arch-Nutzer die sddm einsetzen mit den aktuellen Nvidia-Treibern einen Blackscreen. Vielleicht liegt das Problem dieses eine mal nicht auf meiner Seite…