Debian 9 „Stretch“

Nach etwas über zwei Jahren Entwicklungszeit wurde Debian 9 „Stretch“ am 17. Juni 2017 freigegeben. Für mich ist Debian deshalb von Interesse, weil es das Betriebssystem ist, mit dem ich im Job zu tun habe. Dort läuft es als mein Desktop- und Entwicklungssystem. Ich habe es als ein zuverlässiges, stabiles Betriebssystem kennen und schätzen gelernt. Den Ruf, der diesem Betriebssystem anhaftet, kann ich also genauso bestätigen.

Gegensätze

Privat bin ich eher der Red Hat/Fedora Typ und da ist Debian ein krasser Gegensatz. Innerhalb der Stretch-Entwicklungszeit gab es 4 Fedora-Releases und hätte es nicht die vielen Verzögerungen gegeben, wäre auch Fedora 26 noch vor Debian Stretch veröffentlicht worden. Fedora ist bei seinen Releases meist seiner Zeit voraus, indem neue Technologien, die ja oft genug von Red Hat selbst vorangetrieben werden, frühzeitig integriert werden. Dadurch bekommt man manchmal auch noch ein paar Kinderkrankheiten mit. Nichts desto trotz empfinde ich Fedora – zumindest für den Privatbetrieb – als stabil genug.

Debian auf der anderen Seite hat eine relativ lange Entwicklungszeit von ca. 2 Jahren und integriert nur gut erprobte Komponenten. Dadurch wirkt die Software im Vergleich zu anderen Systemen in Teilen wenig taufrisch. Dafür ist sie, wie schon gesagt, wirklich stabil. Und für Nutzer, die in der Debian-Welt leben, ist sie auch neu, denn innerhalb von zwei Jahren tut sich ja eine ganze Menge. Das läuft dann ja so ungefähr wie bei den „Innovationen“ im Apple-Universum 😉

Upgrade

Am Freitag habe ich das Upgrade auf Stretch am Arbeitsplatz durchgeführt. Was soll ich sagen? Es lief alles sauber und problemlos durch, Debian-like eben. Danach noch alle verwaisten Pakete (also alle, die nicht mehr als Abhängigkeit von anderen Paketen benötigt werden) und alle obsoleten Pakete (welche nicht mehr im Repository sind) entfernt und schon hatte ich eine saubere Stretch-Installation. Es fühlt sich gut an, wieder ein Stück näher an die Gegenwart gerückt zu sein.

Am Arbeitsplatz nutze ich die GNOME-Shell, während ich zu Hause KDE Plasma benutze, so kommt man bei den Entwicklungen gut mit und schießt sich nicht zu sehr auf einen Desktop ein.

Mal sehen, wie die nächsten zwei Jahre mit Debian 9 „Stretch“ so werden.

KDE – Rolling oder nicht?

Manjaro

Meine Suche nach der – für mich – perfekten Linux-Distribution mit KDE Plasma-Desktop ist noch nicht zu Ende. Eines aber hat mich selbst verwundert: Dass Manjaro KDE immer noch mein Hauptsystem ist, seit ich meinen Rechner neu aufgesetzt hatte. Es hat seine Ecken und Kanten aber ich mag es irgendwie.

Ich war bislang immer skeptisch, ob diese „neumodischen“ Rolling Release Distributionen tatsächlich etwas für mich sind. Lange habe ich das Semi-Rolling-Modell von Fedora verteidigt, wo zwar die meisten Basiskomponenten bleiben, jedoch behutsame Versionsupgrades, sogar beim Kernel, gemacht werden. Und ich halte dieses Modell immer noch für eine gute Lösung.

Versionen …

Wenn man aber jetzt die ganze KDE-Welt nimmt, das Dreigespann aus Plasma, Applications und Frameworks, die mehr oder minder losgelöst von einander entwickelt werden und dementsprechend auch unterschiedliche Releasezyklen haben, ist Aktualität schon eine ganz andere Geschichte. Wobei man Frameworks hier eigentlich außen vor lassen kann, denn da gibt es jeden Monat ein Update mit Bug- und Securityfixes. Schauen wir uns aber mal die beiden anderen Teile an:

• Applications wird alle vier Monate released. Im April, im August und im Dezember.
• Plasma eher undefiniert alle drei/vier Monate. Version 5.9 wurde Ende Januar 2017 released, 5.10 ist Ende Mai erschienen.

Natürlich passen die Daten dann nicht zueinander, daher kann es sein, dass man beim Release der Distribution eine brandneue Applications-Version bekommt aber noch auf einer „alten“ Plasma-Version sitzt. Oder umgekehrt.

Feste Releases

Bei Kubuntu bspw. wird es dann innerhalb des Release kein Major-Update geben, sodass man ein halbes Jahr warten muss, nur um dann möglicherweise wieder eine veraltete Version von Plasma oder Applications untergeschoben zu bekommen. Natürlich kann man über die Backports teilweise neuere Versionen einspielen, was aber nur semi-offiziell angeboten wird und möglicherweise die Stabilität beeinflusst.

Feste Releases mit behutsamen Updates

Oder nehmen wir wieder das Fedora-Beispiel: Wenn es keine weitere Verschiebung gibt, wird Fedora 26 am 11. Juli erscheinen. Dann ist Plasma 5.10 noch relativ frisch (obwohl man da schon beim 3. Bugfix-Release ist), Applications jedoch schon länger abgehangen, schließlich kommt im August dann schon die nächste Version. Glücklicherweise wird in den meisten Fällen das Update auf die nächste Plasma/Applications-Version innerhalb des Release-Zyklus ganz regulär angeboten. Es sei denn, die Ressourcen sind schon für die Erstellung der nächsten Fedora-Version an sich gebunden. Eine Garantie gibt es also nicht. Außerdem ist man natürlich längst nicht so schnell, wie bei einer Rolling-Release Distribution. Die Hoffnung ist natürlich, dass Bugs oder Unstimmigkeiten erkannt werden, bevor die neuen Pakete auf die Benutzer losgelassen werden.

Stabile Basis, aktuelles KDE

Hier kommt dann so etwas wie KDE neon ins Spiel, wo auf einer stabilen Basis, in diesem Fall Ubuntu 16.04 LTS, Updates des KDE-Stacks nach dem Rolling Release Prinzip kommen. Das ganze birgt natürlich das Risiko, dass Abhängigkeiten gebrochen werden, weil die Pakete nicht mehr zueinander passen. Ich hatte diesen Fall bspw. als ich den Qt Creator aus den Ubuntu-Quellen installieren wollte, der noch Qt 5.5. benötigte, welches jedoch schon mit 5.7 aus neon ersetzt war. Seit Kurzem steht der Qt Creator auch in neon zur Verfügung aber das Problem kann einem natürlich bei einem beliebigen anderen Paket begegnen. Alles in allem ist neon jedoch total stabil und natürlich auf der KDE Seite topaktuell.

Rolling Releases

Die nächste Stufe sind dann tatsächliche Rolling Release Distributionen, wie Arch und dessen Abkömmlinge oder openSUSE Tumbleweed. Hier ist man mit seinem ganzen System immer up to date. Bei Arch tröpfeln die Pakete so rein, während es bei openSUSE immer wieder sogenannte Snapshots gibt, wo bestimmte Teile des Systems als Ganzes aktualisiert werden um noch besser sicherzustellen, dass keine Inkompatibilitäten entstehen.

Arch selbst habe ich noch nicht in der Tiefe ausprobiert, letzte Versuche sind bereits Jahre her. Wie oben erwähnt, setze ich jedoch auf Manjaro, einen Arch-Abkömmling. Mein Hauptkritikpunkt hier ist, dass man mal sein Benutzerpasswort und mal das root-Passwort eingeben muss, um administrative Aufgaben zu erledigen. Genau das nervt mich auch bei openSUSE zusätzlich zur – im Vergleich zu anderen Distributionen – elendig langen Boot-Zeit.

Interessant ist in diesem Zusammenhang auch KaOS. Es ist kein Arch-Abkömmling, nutzt jedoch auch pacman als Paketverwaltungssoftware. Hier setzt man von vornherein ganz auf KDE Plasma 5/Qt 5 und hat nur wenige Pakete im Repository, die ein anderes Toolkit nutzen. Bekannte Größen, wie GIMP, inkscape, Firefox usw. mal außen vor gelassen. Chakra, in diesem Fall tatsächlich auf Arch basierend, wenn auch geforkt, verfolgt einen ganz ähnlichen Ansatz.

Und die Moral …

Das war jetzt mal ein kleiner Durchgang durch ein paar Distributionen, die KDE anbieten. Mal als eine Option unter vielen, mal als Primär-Desktop. Mein Dilemma bleibt: Ich kenne mich mit Fedora so gut aus, dass es mir schwer fällt, längerfristig zu einer anderen Distribution zu wechseln, auch wenn die Integration hier besser sein könnte. Andererseits, weiß ich auch, an welchen Stellschrauben ich drehen muss um Plasma bei Fedora deutlich zu verbessern. Ich würde mir nur wünschen, dass mehr davon einfach schon in der Standardkonfiguration so eingestellt wäre. Vielleicht sollte ich mal wieder ein paar Feature Request einstellen …

KDE Plasma und Fedora

Gefährliche Experimente

Vor ein paar Wochen passierte mir etwas sehr ärgerliches: Durch Unachtsamkeit installierte ich ein Live-System, welches vorher scheinbar korrekt im UEFI-Modus gestartet war im Legacy BIOS-Modus. Wie das passieren kann, weiß wohl nur der Distributor selbst. In Zukunft werde ich mich vor Live-Medien desselben hüten 😉 Wie dem auch sei, dadurch wurde jedenfalls meine ESP beschädigt, sodass keines der installierten Systeme mehr gestartet werden konnte. Glücklicherweise gab es sonst keinen Datenverlust, dafür aber eine Menge Zeitverlust.

Schuld an der Misere war meine Suche nach einer guten KDE-Plasma-Distribution, die ich dann nicht nur in einer VM testen, sondern auf Bare-Metal installieren wollte. Und damit bin ich auch schon beim Thema. Ich finde Fedora als Betriebssystem nach wie vor sehr gut. Mittlerweile ist es für mich ein Musterbeispiel einer guten Desktop-Integration. Aber der Standard-Desktop ist eben die GNOME-Shell. Und daran ist auch nichts verkehrt. Ich finde es sehr gut, wenn der Desktop nicht nur wie ein Modul oder ein Aufsatz auf das Betriebssystem wirkt, sondern sich wirklich tief verzahnt und untrennbar zum System gehört.

Hier kommt also das Dilemma: Fedora ist das beste Betriebsystem und KDE Plasma ist der beste Desktop. Alles natürlich aus meiner ganz persönlichen aktuellen Sicht, also bitte keinen Flamewar. Aber wie gehe ich damit um, dass das beste Betriebssystem und der beste Desktop eben nicht am besten zusammenpassen? Ich kann natürlich Fedora weiterhin mit GNOME (was ich auch sehr gut finde!) verwenden und eine andere Distribution daneben installieren, die KDE besser integriert.

Manjaro KDE

Und tatsächlich habe ich seit dem oben erwähnten Crash bislang nur Manjaro KDE installiert. Fedora ist noch gar nicht wieder auf der Platte gelandet. Zu meiner Freude funktioniert Manjaro KDE auch sehr gut. KDE Plasma ist, von ein paar Kleinigkeiten abgesehen, sehr gut integriert und fühlt sich wirklich wie das Betriebssystem an. Allerdings stört mich der Mischmasch, wenn es darum geht Administratorrechte zu erlangen. sudo im Terminal nimmt mein Benutzerkennwort entgegen, ganz so, wie ich es von Fedora (und Debian/Ubuntu) gewohnt bin. Octopi jedoch, das grafische pacman-Frontend, verlangt für sämtliche Aktionen das root-Kennwort. Warum diese Inkonsistenz? Solche „Kleinigkeiten“ sorgen dann wieder dafür, dass ich Fedora vermisse, wo zumindest diese Basis-Dinge einwandfrei funktionieren.

Oder doch Fedora KDE?

Aber so ist es eigentlich jedes mal, wenn ich mal etwas neben Fedora ausprobiere: Irgendwann kehre ich reumütig wieder zurück und sehe ein, dass Fedora zwar nicht immer bugfrei ist aber zumindest so funktioniert, wie ich es von einem modernen Desktop-Betriebssystem erwarte. Mag auch am Gewöhnungseffekt liegen, der sich mittlerweile eingestellt hat, so dass man unweigerlich alles mit dem Bekannten vergleicht und das neue oder andere meist nicht gut dabei wegkommt. Da verstehe ich auch die Windows-Benutzer, die die Arbeitsweise von Linux-Systemen befremdlich finden. Oder ist es dort einfach das Stockholm-Syndrom? 😉

Also werde ich vermutlich in der nächsten Zeit einen neuen Versuch mit dem KDE-Spin von Fedora starten. Oder vielleicht mit Kannolo, einer von GTK-Abhängigkeiten befreiten Version von Fedora mit Plasma-Desktop. Ich habe ja sonst nichts zu tun …

CentOS – Fedora mit LTS

CentOS steht für Community Enterprise Operating System und ist eine Linux-Distribution, die aus den frei verfügbaren Quellen des Red Hat Enterprise Linux erzeugt wird. Das heißt, CentOS ist vollständig binärkompatibel mit RHEL, kostet aber im Gegensatz zu RHEL nichts. Man bezahlt bei RHEL ja auch in erster Linie den Support, den man damit bei CentOS in der Form dann eben nicht hat. Stattdessen hilft die Community bei Problemen und das funktioniert offenbar auch gut genug, denn CentOS ist hinter den Platzhirschen Ubuntu und Debian mit 20,4 % die am dritthäufigsten eingesetzte Linux-Distribution auf Web-Servern. RHEL selbst ist auf dem vierten Platz, kommt aber nur noch auf 3,5 %.

Man könnte meinen, die Leute von Red Hat hätten ein Problem damit, dass da jemand einfach ihr Werk unter eigenem Namen anbietet aber dem ist nicht so. Stattdessen hat man sich mittlerweile sogar zusammengeschlossen und Red Hat hat einige CentOS Entwickler eingestellt. Wikipedia weiß dazu mehr.

Ausdauernd

Bei Fedora erscheint alle halbe Jahre eine neue Version, während die jeweils vorherige noch bis einen Monat nach Erscheinen der übernächsten Version weitergepflegt wird. Man ist also gezwungen, mindestens einmal im Jahr ein Upgrade vorzunehmen (Ich mache das natürlich alle halbe Jahre, ist doch klar! 😉 ). Jede RHEL/CentOS Haupversion bekommt jedoch ganze 10 Jahre den vollen Support, während neue Versionen rund alle 3,5 Jahre erscheinen. Zum jetzigen Zeitpunkt wird sogar CentOS 5 noch supportet, wenn auch nicht mehr ganz so lange. Das nenne ich mal Long Term Support!

Ausprobiert

Angeregt durch eine Meldung bei Heise über die frisch freigegebene Version 7.3 dieses RHEL-Klons habe ich mir die Live-ISO mit GNOME heruntergeladen und mal spaßeshalber in einer VM installiert. Das aktuelle Red Hat Enterprise Linux 7.3 und damit auch CentOS basiert auf einem Mix aus Fedora 19 und 20 hat also in der Basis einen Softwarestand von Mitte 2014. Mittlerweile sind aber etliche Komponenten erneuert worden. Unter anderem wurde sogar der GNOME-Desktop von der frühen Version 3.4 auf 3.14 aktualisiert. Man ist damit desktopseitig zumindest auf dem Stand vom aktuellen Debian Jessie (8).

Ich muss schon sagen: man fühlt sich während der Installation und auch nachher im System ganz wie zu Hause, wenn man Fedora gewohnt ist. Sicher, die Software ist nicht ganz so frisch wie bei Fedora aber dafür sollte alles stabiler und sicherer sein. Ob das mit der Stabilität wirklich so ist, kann man aber natürlich erst nach längerer Benutzung sagen.

Beim Paketmanagement muss man sich ein wenig umstellen oder besser gesagt darauf zurückbesinnen, wie es vor Fedora 22 war. CentOS nutzt nämlich noch YUM und nicht DNF. Wobei die Benutzung größtenteils dieselbe ist, abgesehen von den drei Buchstaben im Befehlsnamen. Ehrlich gesagt mag ich den Namen YUM auch lieber als DNF. Das spricht sich flüssiger. Eine Silbe statt drei. Aber das ist eine persönliche Sache und unwichtig, denn DNF selbst ist schneller und hat mehr Features als YUM. Insbesondere das Entfernen mitinstallierter Abhängigkeiten funktioniert bei DNF deutlich zuverlässiger als noch bei YUM.

Ausgezeichnet

Was das RPMFusion Repository für Fedora ist, ist EPEL für CentOS. Weitere Goodies, speziell für den Einsatz auf dem Desktop gibt es im Nux-Desktop Repository. Unter anderem das für mich so wichtige FreeType mit aktiviertem Subpixel-Rendering (Yay!) und die Multimedia-Komponenten. Klar, was in den Zusatzrepositories liegt bekommt nicht dieselbe Stabilitätsgarantie wie Software aus dem Hauptrepository aber beim Test funktioniert bislang alles tadellos. Dadurch ist CentOS auch ein idealer Kandidat für den Rechner meiner Frau. Aktuell nutzt sie Linux Mint, welches sich aber ab und an etwas zickig verhält. Hatte es ihr mal installiert, weil ich mir dadurch ein ruhiges Leben erhoffte. Hat ja super geklappt…

Jetzt habe ich zumindest die Chance ihr ein wartungsarmes System zu installieren und meinen Haushalt Ubuntufrei zu machen. Hat was!

YouTube: Ich bin dabei!

Ihr habt es gemerkt: Ich mache jetzt auch Videos über Linux auf dem Desktop.

Warum auf einmal Videos? Weil ich gemerkt habe, dass es viel einfacher ist, etwas in einem Screencast zu zeigen, als alles haarklein aufzuschreiben und die passenden Screenshots zu machen. Artikel wie die bisherigen wird es natürlich in Zukunft auch weiter geben. Manches kann man eben nicht so gut in Videos verpacken und außerdem sind Videos nicht so einfach durchsuchbar. Terminalbefehle oder Texte lassen sich auch nicht aus Videos kopieren. Ich denke dieses Blog und der linuxrelated-Kanal auf YouTube werden sich prima ergänzen.

Ich stehe noch ganz am Anfang, was die Erstellung und Bearbeitung von Videos betrifft. Daher ist das erste Video, in dem es um den Fedora MediaWriter geht natürlich lange nicht perfekt (das werden die Videos sowieso nie sein). Aber ich lerne dazu und bin dabei einen Workflow zu finden. Dann werden hoffentlich noch einige andere Videos folgen. Aktuell bin ich noch dabei mein Intro zu animieren und nach der passenden Hintergrundmusik zu suchen.

Fedora

Warum gerade Videos zu Fedora? Ich habe YouTube durchsucht und festgestellt, dass es kaum Videos in deutscher Sprache zu Fedora gibt, während Ubuntu allgegenwärtig scheint. Ubuntu ist ein großartiges Betriebssystem, das steht außer Frage. Aber Fedora ist es auch und, wie ich meine, völlig zu unrecht in Deutschland zu wenig bekannt. Daher habe ich im ersten Video auch ein Alleinstellungsmerkmal gegenüber anderen Linux-Distros beleuchtet. Was man nicht vergessen darf, ist die Tatsache, dass der Schöpfer des Linux-Kernels, Linus Torvalds selbst, Fedora nutzt. Man befindet sich also in bester Gesellschaft.

Fedora gilt heute immer noch als kompliziert und nicht für den Anfänger geeignet. Aber das ist einfach nicht mehr wahr. Auch wenn Fedora Workstation mit dem GNOME-Desktop als System für Softwareentwickler beworben wird, heißt das noch lange nicht, dass es für andere, normale Dinge nicht geeignet ist. Das besondere Augenmerk auf Softwareentwicklung ist eher etwas, was noch oben drauf kommt. Das wird leider oft missverstanden. Vielleicht helfen die Videos, mal einen anderen Blick auf Fedora zu bekommen.

openSUSE

Und dann noch openSUSE? Ja, openSUSE (damals noch SuSE Linux) ist die Distribution, die mich zu Linux brachte, dank der wirklich hervorragenden Dokumentation in der Box. Außerdem hat sie ihren Ursprung in Deutschland. Aber das wichtigste für mich ist die wirklich gute KDE Plasma-Implementierung. Fedora glänzt, wenn es um GNOME geht, während zu openSUSE für mich persönlich KDE Plasma gehört. Das geht natürlich auch umgekehrt und das Fedora mit KDE auch ganz reizend funktioniert habe ich mit der Artikelserie hier gezeigt. Aber der letzte Schliff fehlt einfach doch oft.

So, und nun schaut Euch mein erstes Video an. Vielleicht auch einfach nur um zu hören, welche Stimme zu den Zeilen gehört, die Ihr jetzt gerade lest 🙂

In diesem Sinne, bis zum nächsten Mal! Egal ob geschrieben oder gefilmt.

Fedora 25

Fedora 25 ist nach den üblichen Verschiebungen am 22. November erschienen. Endlich! Jemand wie ich wartet aber meist nicht auf die offizielle Freigabe sondern installiert schon mal die Beta-Version um zu schauen ob noch grobe Schnitzer drin sind. Die ist zwar selbstverständlich nicht für den produktiven Einsatz gedacht, man bekommt aber schon mal einen Einblick in die Neuerungen, die einen erwarten.

Nachdem ich bei Fedora 24 eigentlich hauptsächlich den KDE Plasma-Desktop genutzt habe, ist bei dieser Version wieder GNOME, der Standard-Desktop der Fedora Workstation dran. Da ich Fedora 24 mit GNOME schon testweise in einer separaten Partition installiert hatte, habe ich hier einfach mal das Upgrade gestartet und auf eine Neuinstallation verzichtet, wie ich es sonst meist mache. Dank der guten Anleitung im Fedora Magazine lief die Prozedur auch wie am Schnürchen.

Ich hatte es an anderer Stelle schon erwähnt: Während Fedora mit den alternativen Desktops je nach Engagement der Maintainer sehr gut funktioniert, hat man doch nur beim GNOME-Desktop wirklich das Gefühl ein komplett rundes Gesamtpaket zu bekommen. KDE-Plasma bspw. wirkt wie ein Aufsatz auf das Betriebssystem, während Fedora Workstation mit GNOME einfach das Betriebssystem ist, so gut ist spielt alles zusammen. Wirklich verwunderlich ist das natürlich nicht, schließlich wird die Entwicklung des GNOME-Desktops auch von Red Hat gesponsert. Wenn man also Fedora Workstation testet und bewertet, bewertet man damit immer auch den GNOME-Desktop.

Alles in allem bin ich mit der neuen Version sehr zufrieden. Ein solides Update, das jedem empfohlen werden kann, der eine ältere Version einsetzt. Es sagt sich immer sehr leicht, wenn vieles neuer und moderner ist aber Fedora 25 ist vermutlich wirklich das beste Release bisher. Und ich bin von Anfang an dabei! 25 klingt ja auch irgendwie nach Jubiläum, das muss einfach gut sein. Ein paar Tweaks hier und da, ähnlich wie ich es schon für den KDE Plasma Desktop beschrieben hatte und es wird perfekt.

Also stellt Euch darauf ein, dass in der nächsten Zeit ein paar Artikel rund um Fedora Workstation und GNOME hier auftauchen. Ich kann nur empfehlen, Fedora zumindest mal in einer VM auszuprobieren. Ihr werdet begeistert sein, von einem Desktop, der funktional und schön ist, ohne dabei aufdringlich zu sein. Er tritt einfach zur Seite und lässt Euch arbeiten ist aber da, wenn man ihn braucht, wenn Ihr versteht, was ich meine. 😉

Multimedia

Ein gutes Betriebssystem ist ein Allrounder. Auf dem System, mit dem ich programmiere, möchte ich nebenbei auch noch Musik hören oder in einer entspannten Pause einen schönen Film anschauen. Nun ist es so, dass man dafür Software benötigt. Zum einen die Codecs und zum anderen die Abspielprogramme. Freie Formate, wie Ogg Vorbis und FLAC funktionieren von Haus aus aber schon bei MP3 ist Schluss mit Lustig.

Wo ist das Problem? Von einem derart umfangreichen Repository, wie Fedora es hat, erwarte ich doch, das alles enthalten ist und die notwendigen Dinge bestenfalls schon vorinstalliert sind. Aber leider ist das nicht so und der Grund sind Softwarepatente auf bestimmte Algorithmen und Mechanismen in Multimedia-Codecs und natürlich kommen da auch Lizenzen ins Spiel, für die man zahlen muss (Das würde ein Linuxer ja nie tun! ;-). Und da Software-Patente gerade in den USA ein großes Thema sind, kann Red Hat diese Codecs nicht ohne weiteres ausliefern. Das gleiche hatten wir auch beim Thema Font-Rendering. Und ebenso wie dort, hilft uns auch hier das RPM Fusion Repository weiter. Falls Ihr es noch nicht eingebunden habt, holt es ganz schnell nach:

Terminal (Konsole) öffnen und folgenden Befehl ausführen:

sudo dnf install --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Die Installation der beiden Pakete bestätigen und schon sollte (fast) alles da sein, was wir im offiziellen Repository vermissen.

Codecs

Die Voraussetzungen sind geschaffen, jetzt müssen die Bibliotheken und Codecs selbst noch installiert werden. Das besorgt der folgende Befehl:

sudo dnf install gstreamer1-plugins-base gstreamer1-plugins-good gstreamer1-plugins-ugly gstreamer1-plugins-bad-free gstreamer1-plugins-bad-freeworld gstreamer1-plugins-bad-free-extras ffmpeg

Ihr seht, dass ein ganzer Haufen Pakete (samt Abhängigkeiten) installiert wird. Insbesondere die, die mit -bad oder -ugly enden, enthalten die patentbehafteten Codecs.

Player

Die Codecs hätten wir damit installiert, fehlt nur noch ein guter Player. Während bei KDE für Musik meist Amarok verwendet wird, fehlt ein gescheiter Video-Player (den mitgelieferten Dragon-Player habe ich nie zufriedenstellend in Betrieb nehmen können). Ein sehr empfehlenswerter Allrounder ist VLC, den Ihr wahrscheinlich schon von Windows kennt (wer hat den nicht installiert?).

sudo dnf install vlc

DVD

Jetzt haben wir einige Codecs installiert und fast sämtliche gängigen Videoformate damit abgedeckt. Nur DVDs können wir immer noch nicht abspielen, denn es fehlt die Bibliothek libdvdcss manchmal auch libdvdcss2 genannt. Hier ist die Situation nochmal komplizierter, wer dazu mehr wissen möchte, sei auf den Artikel in der deutschen Wikipedia verwiesen.

Aber natürlich kommen wir auch da ran. Dafür binden wir das negativo17 Multimedia-Repository ein und installieren das entsprechende Paket. Man sollte normalerweise nicht wahllos Repositories hinzufügen aber diese beiden sind quasi renommiert. Ich nutze sie auch und kann sie bedenkenlos empfehlen. Wer einen Nvidia Grafikchip hat wird negativo17 wegen des angebotenen Treibers auch schätzen.

sudo dnf config-manager --add-repo=http://negativo17.org/repos/fedora-handbrake.repo
sudo dnf install libdvdcss

Jetzt können wir VLC auch für die Wiedergabe von DVDs nutzen. Wer es rechtlich aber ganz wasserdicht haben möchte, kann sich natürlich auch lizenzierte Codecs oder Player kaufen und damit nebenbei auch noch die Firma Fluendo unterstützen, die seit Jahren schon Multimedia-Software für Linux (und andere Systeme) anbietet.

Damit sollten wir ein System haben, welches jeglichen Multimedia-Ansprüchen genügt. Viel Erfolg beim Ausprobieren.

Plasma und GTK-Apps

Einheit in der Vielfalt

Wer den KDE Plasma Desktop installiert nutzt normalerweise auch die Tools, die dieser mitbringt, bzw. das, was in den KDE Applications enthalten ist. Damit ist ein gutes Zusammenspiel von Desktop und Apps garantiert, weil alles auf dem gleichen Toolkit bzw. Framework fußt. So haben dann auch alle Apps ein einheitliches Aussehen und verhalten sich bei Standardaufgaben auch ähnlich. Der Öffnen/Speichern-Dialog ist gleich, die Einstellungsdialoge sind nach dem gleichen Muster aufgebaut usw.

Nun gibt es aber auch Software, die eben nicht mit Qt, dem Toolkit, welches KDE Plasma zugrunde liegt, entwickelt wurde. Der weitaus größte Teil dieser Software nutzt GTK+ als Toolkit. Bekannte Beispiele sind GIMP, Inkscape, darktable, RawTherapee, Mozilla Firefox, Google Chrome und einige mehr.

Diese Applikationen wirken in der Standardeinstellung bei Fedora KDE wie Fremdkörper, da sie sich nicht in das Look & Feel einfügen.

Hier mal zwei Screenshots zum Vergleich. Es handelt sich hier um den Einstellungsdialog von GIMP, einmal in der Standardeinstellung:

Und in der an KDE Plasma angepassten Darstellung:

So ist ein GTK-Programm vom Aussehen zumindest schon kaum mehr von einem Qt-Programm zu unterscheiden. Dass sich ein GTK-Programm an manchen Stellen noch anders „anfühlt“ und auch die Standard-Dialoge anders aussehen, lässt sich natürlich nicht abstellen.

Wie die Programme aussehen wird durch Themes geregelt. Das Standard-Theme bei Plasma (Qt) ist Breeze, während GNOME (GTK) Adwaita verwendet. Selbst wenn GNOME nicht installiert ist, wird dieser Theme für die GTK-Apps verwendet. Alles, was wir nun tun müssen, ist, dafür zu sorgen, dass auch für GTK-Apps das Breeze-Theme verwendet wird. Themes werden immer für ein bestimmtes Toolkit entwickelt und lassen sich natürlich nicht bei einem anderen anwenden aber man kann zumindest auf Basis anderer Toolkits Themes entwickeln, die genauso oder ähnlich aussehen. Ein solches Theme gibt es auch für Breeze, es ist nur leider nicht standardmäßig installiert. Das können wir einfach nachholen:

sudo dnf install breeze-gtk

Dann stellt Ihr sicher, dass dieser Theme auch für die GTK-Apps benutzt wird. Öffnet die Systemeinstellungen und dann unter Erscheinungsbild das Icon „Anwendungsstil“. Hier wählt Ihr den dritten Punkt „GNOME Anwendungsstil (GTK)“ und macht die Einstellungen, wie im Screenshot zu sehen.

Tooltips

Es gibt noch ein Problem mit Tooltips in GTK-Anwendungen. Und zwar sind diese im Breeze-Theme schlecht lesbar. Aber auch dafür gibt es eine Lösung: In den Systemeinstellungen wechselt Ihr zu „Farbe“. Unter dem Reiter Optionen deaktiviert Ihr einfach „Farben auf Nicht-Qt-Programme anwenden“. Dann sind auch die Tooltips bei GIMP wieder lesbar.

An solcherlei Punkten merkt man leider, dass die Distributoren mehr tun könnten, was die Integration des KDE-Desktops ins Betriebssystem betrifft. Und das ist leider nicht nur bei Fedora so. Eine gute Vorkonfiguration erspart dem neuen Benutzer viel Arbeit und gibt gleich ein besseres Bild ab. Aber zum Glück ist es nichts, was man nicht doch noch nachträglich einstellen könnte.

Vielleicht habt Ihr ja auch noch Tipps und Tricks, wie man den Plasma-Desktop weiter tweaken kann. Ansonsten hoffe ich, dass dieser Artikel jemandem weiterhilft.

Schriftdarstellung optimieren

Die Schriftdarstellung bei Betriebssystemen ist ein Thema, mit dem ich mich schon seit Jahren beschäftige. Auch Artikel hier im Blog zeugen davon. Es ist aber auch ein hoch-subjektives Thema. Manche installieren ein Betriebssystem und scheren sich nicht darum, wie die Schrift aussieht. Mir jedoch ist noch keine Linux-Distribution begegnet, bei der für mich in der Standardeinstellung alles optimal war. Dabei sitze ich – selbst auf der Arbeit – stundenlang vor einem Linux-Desktop. Da muss man es doch den Augen so angenehm wie möglich machen.

Am gefälligsten wirkt die Darstellung der Schrift wohl bei Ubuntu und den vielen Derivaten. Dort ist das Subpixel-Rendering (mit einigen Patches von Canonical) in der FreeType-Bibliothek enthalten und auch standardmäßig aktiviert. Bei Fedora und einigen anderen Distributionen ist das nicht so und das hat damit zu tun, dass Microsoft in den USA einige Patente auf die Technologie angemeldet hat. Da nun Red Hat auch eine amerikanische Firma ist, kann man die Funktion also nicht ohne weiteres ausliefern. Glücklicherweise ist es nicht schwierig, Subpixel-Rendering trotzdem unter Fedora zu aktivieren.

Da ich zu faul bin, nochmal vergleichende Screenshots zu machen verweise ich auf einen anderen interessanten Artikel in einem sehr empfehlenswerten Blog zu Linux. Es geht zwar eigentlich um eine Eigenart in GIMP aber dort könnt Ihr auch ganz anschaulich unterschiedliche Rendering-Algorithmen sehen. Ansonsten gibt es auch einen Vergleich im weiter oben verlinkten Artikel in diesem Blog.

FreeType in a free world

Das in den Repositories von Fedora enthaltene FreeType-Paket wird ohne aktiviertes Subpixel-Rendering kompiliert. Es hilft also erstmal auch keine Konfiguration um es zu aktivieren. Wir brauchen dazu ein Paket, wo die Unterstützung einkompiliert wurde. An dieser Stelle kommt RPM Fusion ins Spiel, das ist ein semi-offizielles Zusatz-Repopsitory für Betriebssysteme von Red Hat, also Fedora, CentOS und auch Red Hat Enterprise Linux selbst. Pakete, bei denen aus patentrechtlichen Gründen, Funktionen ausgeklammert werden müssen, stehen hier mit dem vollen Umfang zur Verfügung. Sie heißen dann genau wie die Standardpakete aber mit dem Zusatz „-freeworld“ und kommen sich damit nicht mit den Standardpaketen ins Gehege. Natürlich gibt es auch viele weitere Pakete, die Fedora gar nicht ausliefern darf. Dazu zählen insbesondere Multimedia-Codecs.

Um hier nicht alles nochmal aufschreiben zu müssen, verweise ich einfach mal auf den bereits bestehenden Artikel, der beschreibt, wie ihr RPM Fusion in Fedora einbindet. Dem könnt Ihr ganz einfach folgen. Da wir es hier aber mit KDE Plasma zu tun haben, lassen wir beim zweiten Befehl logischerweise das gnome-tweak-tool weg, da KDE seinen eigenen Einstellungsdialog dafür hat. So bleibt nur das freetype-freeworld Paket zu installieren:

sudo dnf install freetype-freeworld

Jetzt könnt Ihr dem Artikel weiter folgen und die Datei .fonts.conf im Homeverzeichnis mit dem angegebenen Inhalt anlegen. Eigentlich sollte damit alles erledigt sein. Sicherheitshalber machen wir noch eine Einstellung in der Schriftartenkonfiguration, damit es auch wirklich jedes Programm mitbekommt. Zu folgendem Dialog kommt Ihr, indem Ihr im Anwendungsmenü Systemeinstellungen aufruft und dann auf Schriftart.

Hier setzt Ihr „Kantenglättung verwenden:“ auf „Aktiviert“ und wendet die Einstellungen an.

Machen wir’s hübscher

Ihr seht im Screenshot auch, dass ich nicht Fedoras Standardschriftart verwende, sondern Noto Sans. Das ist der eigentliche Standardfont von KDE Plasma 5. Dieser wird unter Fedora nicht standardmäßig eingestellt, weil er nicht den vollen Zeichensatz bei allen wichtigen Sprachen unterstützt. Das ist uns aber egal, denn für die meisten Sprachen, vor allem Deutsch, funktioniert alles bestens. Wenn Ihr die Schriftart auch nutzen möchtet, müsst ihr das entsprechende Paket erst installieren.

sudo dnf install google-noto-sans-fonts

Jetzt müsst Ihr allerdings die Schriftarteinstellung nochmal aufrufen, sonst weiß der Dialog nichts von den soeben installierten Schriften. Dann könnt Ihr der Einfachheit halber den Button „Alle Schriftarten anpassen …“ klicken und die Einstellung wie im folgenden Screenshot machen:

Der Font für „Feste Breite“ bleibt davon unberührt und müsste gesondert eingestellt werden. Aber der kann auch ruhig so bleiben. Damit die Einstellungen auch wirklich komplett übernommen werden, empfehle ich, Euch einmal neu anzumelden.

Die Fonts von Microsoft

Es gibt noch einen weiteren Schritt, den Ihr optional ausführen könnt, damit die Schrift auf Webseiten so aussieht, wie ihr es von Windows her gewohnt seid: Die wichtigsten Schriftarten von Microsoft, die sogenannten Core Web Fonts, stehen frei zur Verfügung und können daher auch unter Linux genutzt werden. Wenn Ihr das wollt sind sie nur diese beiden Befehle entfernt:

sudo dnf install cabextract
sudo rpm -i https://downloads.sourceforge.net/project/mscorefonts2/rpms/msttcore-fonts-installer-2.6-1.noarch.rpm

Voila! So ist auch im Web alles wie gehabt. Es bleibt zu betonen, dass dieser Schritt nicht zwingend notwendig ist um eine schöne Darstellung auf Webseiten zu bekommen. Bei allen Linux-Distributionen werden Schriftarten ausgeliefert, die die gleichen Metriken haben, wie die von Microsoft, die Liberation Fonts. So bleibt das Layout von Webseiten zumindest auf beiden Systemen gleich auch wenn sich die Schriftarten leicht unterscheiden.

Das wäre fürs Erste alles, was ich zu Schriftarten sagen kann. Nochmal: Die Schriftarten und das Rendering sind ein stückweit Geschmacksache und was ich hier beschreibe ist mein persönlicher Workflow beim Einrichten von Fedora KDE. Es steht Euch natürlich frei, andere Einstellungen zu machen. Ich zeige nur, was möglich ist. Da ich mich z. T. auf einen anderen Artikel bezogen habe ist vielleicht etwas unklar oder unvollständig geblieben. Schreibt mir Anregungen in die Kommentare. Und wie immer: Viel Erfolg!

Nachsorge – Teil 1

Updates

Als erstes gilt es, noch fehlende Updates zu installieren um das System auch sicherheitstechnisch auf den neuesten Stand zu bringen. Vermutlich ist Euch schon ein kleines Popup in der rechten unteren Ecke über dem Tray aufgefallen, welches Euch die bereitstehenden Updates ankündigt. Um diese einzuspielen klickt ihr einfach auf das dazugehörende Icon (im Screenshot mit dem blauen Balken) und wählt „Install updates“.

Ihr könnt natürlich auch Updates machen, wenn das Icon nicht zu sehen ist. Der beste Weg dafür ist eigentlich das Terminal (heißt „Konsole“ bei KDE), denn da sieht man auch direkt was dabei passiert. Das Update wird angestoßen, indem Ihr folgenden Befehl ausführt:

sudo dnf update

Wichtig: Die darauffolgende Abfrage benötigt das Passwort des aktuellen Benutzers.

sudo

Kleiner Exkurs: Vielleicht erinnert Ihr Euch noch an die Option „Diesen Anwender als Administrator festlegen“ während der Installation. Damit haben wir den neu angelegten Benutzer in die Gruppe der Administratoren aufgenommen. Wir können beliebige andere Benutzer in diese Gruppe aufnehmen und jeder könnte sich mit seinem eigenen Kennwort für die Administrationsaufgaben authentifizieren und müsste das Root-Kennwort nicht kennen, welches, wie schon gesagt, nur noch in seltenen Fällen benötigt wird. sudo steht übrigens für „superuser do“, also „Führe als Administrator aus“.

Warum denn überhaupt noch ein Kennwort, wenn man doch zu den Administratoren gehört? Na, was kann passieren, wenn der Rechner mal unbeobachtet ist und dummerweise gerade nicht gesperrt ist? Eben! Weil man die Freiheit hat, könnte man aber tatsächlich die Passwort-Abfrage deaktivieren, wovon ich jedoch mit Nachdruck abraten würde. Als kleine Erleichterung merkt sich das Terminal für eine bestimmte Zeit, dass man sich bereits als Administrator ausgewiesen hat, sodass für nachfolgende Befehle mit sudo kein Passwort benötigt wird. Schließt man das Terminalfenster vor Ablauf dieser Zeit, ist die Authentifizierung natürlich auch abgelaufen. In einem neuen Fenster geht alles wieder von vorne los. Auch in grafischen Administrationswerkzeugen wird meistens das eigene Kennwort benötigt.

dnf

DNF ist das Paketmanagement bei Fedora und der Nachfolger von YUM. Warum man nicht einfach den Namen YUM beibehalten hat erschließt sich mir bis heute nicht. DNF ist schneller, ressourcensparender und löst Paketabhängigkeiten besser auf. Aber der Name ist einfach sperriger als YUM. Aber sei’s drum, wichtig ist was drin ist und nicht was draufsteht, gell?

Ein Paketmanager ermöglicht das Installieren, Aktualisieren und Deinstallieren von Softwarepaketen unter Berücksichtigung der Abhängigkeiten. KDE Plasma selbst ist beispielsweise in viele kleinere Pakete aufgeteilt und benötigt zum Betrieb seinerseits bestimmte Systemkomponenten, die bei einem GNOME-Desktop nicht installiert werden. Alle diese Probleme und einiges mehr löst der Paketmanager DNF. Für weitere Informationen gibt es die gute und umfangreiche Dokumentation oder Wikipedia.

update

Und was es mit dem dritten Wort „update“ im Befehl auf sich hat brauche ich wohl nicht zu erklären, denn die Prozedur habt Ihr ja soeben durch. Es wird einfach für alle installierten Pakete, ob System oder Anwendersoftware überprüft ob es Aktualisierungen gibt, die dann installiert werden.

Sprachenunterstützung

Kommen wir nun zum nächsten Fall, wo wir DNF benötigen: Das Nachinstallieren der deutschen Sprachpakete für dem Desktop und die Applikationen (Ich hatte schon einen Artikel dazu geschrieben, wie man das grafische Werkzeug dafür nutzt). Um die ISO nicht ganz groß werden zu lassen befindet sich im Live-System nur eine ganz rudimentäre Unterstützung der deutschen Sprache. Die restlichen Sprachpakete kann man mit einem einzigen Befehl hinzufügen:

sudo dnf langinstall de

Unter anderem werden damit auch die deutschen Manual-Pages installiert, mit denen man sich Hilfen zu Befehlen anzeigen lassen kann. Das ist sehr nützlich, wenn man häufiger mit dem Terminal zu tun hat.

Weiter demnächst in Teil 2. Bis dahin: viel Erfolg!