Archiv der Kategorie: Betriebssysteme

Ich richte mir ganz gern das Programm-Menü nach meinen eigenen Vorlieben ein. Unter Windows, als ich das noch benutzte, habe ich das Startmenü immer derart abgeändert, dass ich mir meine eigenen Kategorien erstellte und die Anwendungsprogramme dort hinein sortierte. Unter GNU/Linux gefällt mir die vorgegebene Kategorisierung zwar ganz gut, aber zumindest nachinstallierte Programme, die nicht zum Lieferumfang der Distribution gehören, tragen sich manchmal in Kategorien ein, wo ich sie als ein wenig fehl am Platz empfinde.

Also heißt es, Hand anlegen! Wenn die Distribution keinen Menüeditor mitliefert, kann man zum Beispiel Alacarte installieren. Es gehört zwar zu GNOME 3, läuft aber natürlich auch unter anderen Schreibtisch-Umgebungen.

Cinnamon, das mir als Desktop-Environment sehr gut gefällt, bringt seinen eigenen Menüeditor mit. Er scheint mir auf Alacarte zu basieren; jedenfalls ähnelt er jenem sehr stark. Nur wusste ich letztens nicht mehr, wo er zu finden ist – im Programm-Menü suchte ich ihn vergeblich. Nun, man gelangt zu ihm, indem man einen Rechtsklick auf den Menü-Button vollführt, dann auf Einrichten klickt und anschließend auf Die Menübearbeitung öffnen. Da muss man erst mal drauf kommen … Bei TauSys fand ich den entsprechenden Hinweis. Außerdem wird dort genau erklärt, wie man das Menü editieren kann.

Und jetzt, da ich diesen Artikel schreibe, habe ich gerade entdeckt, dass man auch unter Xfce zum Menüeditor gelangt, indem man per Rechtsklick aufs Whisker-Menü klickt – es handelt sich um MenuLibre, der ein wenig anders als Alacarte aussieht, aber ähnlich zu bedienen ist. Man lernt doch nie aus …

Auf meinem alten Netbook dot-s von Packard-Bell läuft seit Jahren Lubuntu stabil, die Ubuntu-Variante mit LXDE. Und heute wollte ich endlich mal von der installierten Version 16.04 auf die aktuelle 17.04 hochstufen. Ich habe so etwas schon mal gemacht, konnte mich aber nicht mehr erinnern, wie das ging.

In Foren steht manchmal als Antwort auf die Frage, wie man so ein Distributions-Upgrade durchführen könne, das ginge nicht. – Doch, geht. Im Ubuntu-Wiki steht genau, was man machen muss. Dort ist zwar die Rede von einem Upgrade von 16.10 auf 17.04, aber es klappt auch von 16.04 aus, wie in meinem Fall. Natürlich sollte man über eine aktuelle Datensicherung verfügen, wenn man so etwas angeht.

Als ich neulich Debian 9 frisch installiert hatte, wurde mein Root-Passwort, das ich bei der Installation angegeben hatte, später bei der Eingabe im Terminal nicht anerkannt. In Foren ist zu lesen, dass auch andere Benutzer diese Erfahrung gemacht haben – es handelt sich offen­sicht­lich um einen Bug. Da bleibt nur, dieses Passwort, das ja nicht akzeptiert wird, neu zu setzen, was ein wenig aufwändig ist. In dem wikiHow-Artikel In Linux das Root-Passwort ändern wird diese Prozedur sehr gut beschrieben.

Nach meinen Erfahrungen sollte man aber hier nur Zeichen benutzen, die auf amerikanischen und deutschen Tastaturen gleich sind – Sonderzeichen und Umlaute sind also zu vermeiden. Nach dem Einloggen ins System kann man dann übers Terminal zum Superuser wechseln und dort das Passwort noch einmal ändern, indem man ein möglichst sicheres wählt, das aus Buchstaben, Zahlen, Satzzeichen und Sonderzeichen besteht:

$ su
Passwort:
# passwd
Geben Sie ein neues Passwort ein:
Geben Sie das neue Passwort erneut ein:
passwd: Passwort erfolgreich geändert


Zur Erklärung: Das Dollarzeichen deutet an, dass man als Benutzer angemeldet ist; die Raute erscheint, wenn man als Superuser eingeloggt ist. Als Normalbenutzer tippt man also su ein, um sich durch Eingabe des bisherigen Passworte zum Superuser zu machen. Als jener tippt man dann passwd ein und wird zwei Mal aufgefordert, ein neues Passwort zu setzen. Bei Erfolg erscheint dann ein entsprechender Hinweis.

Meinen privaten Computer aktualisierte ich kürzlich von Fedora 25 auf 26. Das ging alles glatt und dauerte nicht allzu lange. Nur hatte ich anschließend keinen Sound mehr, egal ob per ALSA oder per PulseAudio. Denn weder der Audiochip der Hauptplatine noch eine externe USB-Soundkarte wurden mehr erkannt, während unter Fedora 25 alles völlig fehlerfrei geklappt hatte. Einige andere Benutzer hatten das gleiche Problem; aber keine der Lösungen, die ich in ver­schiedenen Foren fand, half mir. Einige andere Probleme, unabhängig von dem Audioproblem, kamen hinzu, was aber wohl eher an mir selbst lag und in diesem Zusammen­­hang hier zu weit führen würde.

Jedenfalls ist es blöd, wenn das Betriebssystem auf einem Computer, an dem man Tonbearbeitung macht, keinen Ton ausgibt. Um nicht noch mehr Stunden mit der Fehlersuche zu verbringen und weil ich auch keine Lust hatte, auf Fedora 25 zurück zu degradieren, schmiss ich nach einiger Überlegung das Betriebssystem vom Rechner runter und installierte Debian 9, womit ich auch sehr glücklich bin.

Ein bisschen vermisse ich das eigentlich liebgewonnene Fedora zwar – aber für den Fall, dass die Sehnsucht zu groß wird, habe ich ja noch Korora, ein Fedora-Derivat, auf einem anderen Computer. Ich habe dort, weil ich einfach die Ursache für das Soundproblem einkreisen wollte, ebenfalls auf Fedora 26 aktualisiert (von Korora gibt es jetzt, Ende Juli 2017, noch keine Version 26). Und die Ausgabe von Klängen funktioniert wunderbar.

So ziehe ich den Schluss, dass die Hardware des einen Computers nicht mit Fedora 26 harmoniert, die des anderen schon. So etwas kommt vor – es kann irgendein bestimmter Chipsatz auf dem Motherboard sein, der mit bestimmter Software einfach nicht zurecht kommt bzw. umgekehrt. Mit dem ASUS-Mainboard des betreffenden Computers hatte ich ja in der Vergangenheit bereits gewisse Probleme – und zwar unter Windows, das auch keinen Sound ausgeben wollte. Nun gut, mit Debian läuft ja alles und die Welt ist wieder in Ordnung.

Es ist jetzt schon etliche Wochen her, dass sich irgendein Update unter Antergos, einem Arch-Derivat, nicht einspielen ließ. Leider habe ich mir die Details nicht notiert. Jedenfalls spielte die Abhängigkeit von einem in Python programmierten Netzwerk-Framework namens Twisted dabei die entscheidende Rolle.

Nach langer Suche fand ich heraus, dass es wohl so ist, dass sich das Arch-Paket, welches dieses Framework bereitstellt, ursprünglich auf Python 2 bezog und twisted hieß, nach Erscheinen von Python 3 aber umbenannt wurde in python2-twisted. In Software-Paketen, die dieses Framework in der alten Python-2-Version einbinden, sollte es also umbenannt werden – hat der Paket-Ersteller das versäumt, kommt es eben zu Problemen wie in meinem Fall.

Bei der Installation des Software-Updates, an das ich mich eben nicht mehr erinnern kann, musste ich das PKGBUILD editieren, indem twisted in python-twisted zu ändern war. Danach klappte die Aktualisierung.

In einem anderen Blogartikel hatte ich kurz beschrieben, dass ich ab und zu Probleme habe, Anwendungen unter Antergos zu aktualisieren. Die dort vorgestellte Lösung brachte aber bei einem erneuten Upgrade-Problem nichts.

Doch andere Leute haben solche Probleme offensichtlich ebenfalls. Und heute fand ich eine für mich wirksame Lösung im Antergos-Forum. Demzufolge muss man die Schlüssel zunächst komplett löschen und dann neu abrufen. Das tat ich, und danach konnte ich endlich alle bisher fehlgeschlagenen Aktualisierungen installieren. Danke an den Forumsmoderator joekamprad für das Veröffentlichen dieses Lösungswegs!

$ sudo rm -fr /etc/pacman.d/gnupg
$ sudo pacman-key --init
$ sudo pacman-key --populate archlinux antergos

Heute wollte sich nichts mehr speichern lassen, obwohl auf dem SSD-Laufwerk bzw. in der /home-Partition noch reichlich Platz frei ist. Und, wie ich in einem anderen Beitrag schon einmal beschrieben hatte, lag es auch diesmal wieder an den vom Dateisystem ext4 verwendeten Inodes, die gewisse Informationen über Dateien speichern. Die Anzahl der zur Verfügung stehenden Inodes ist zwar sehr hoch, aber doch begrenzt; und hat man sehr viele kleine temporäre, Cache- und Log-Dateien, dann kann es passieren, dass irgendwann keine Inodes mehr frei sind und somit keine Daten mehr gespeichert werden können. Also löscht man überflüssige Dateien.

Ich habe mich im Terminal als Superuser eingeloggt und das angehäufte Gezumpel gelöscht (im Verzeichnis /tmp befanden sich versteckte Ordner, daher der Punkt vor dem Sternchen):

rm -rv /tmp/.*
rm -rv /var/log/*


Mit dem Befehl rm muss man natürlich sehr vorsichtig umgehen. Setzt man die Pfade nicht richtig, kann es passieren, dass wichtige Dateien und Verzeichnisse auf Nimmerwiedersehen gelöscht werden – nur mit Aufwand könnte man sie unter günstigen Umständen wiederherstellen.

Apricity OS war eine schicke GNU/Linux-Distribution, die auf Arch Linux basierte. Sie konzentrierte sich auf die Generation der mobilen Web- und Cloud-Anwender. Erhältlich war sie in einer Gnome- und in einer Cinnamon-Version. Doch irgendwann gegen Ende 2016 wurde es ruhig um das Projekt, und als ich vor einigen Wochen schauen wollte, ob es eine neue Ausgabe gibt, stellte ich fest, dass die Website tot war. Nun las ich unlängst auf Chip.de, das Projekt sei aus Gründen der Zeitknappheit der Entwickler vor einiger Zeit eingestellt worden. Also wohl nicht allzu lange nach dem Erscheinen der zweiten stabilen Version »11.2016 Birch«.

Es ist aber auch irgendwie ein verrücktes Phänomen, dass ständig neue Distributionen erscheinen. Kritiker bemängeln, dies stifte nur Verwirrung und nütze niemandem. Ich kann diese Meinung verstehen. Zwar habe ich als neugieriger Mensch immer wieder gern Distributionen ausprobiert, die ich noch nicht kannte; doch von den knapp siebzig getesteten empfand ich letztlich nur fünfzehn als tauglich, darunter auch einige, die noch gut auf alter Hardware laufen. Und aus diesem Fundus haben sich am Ende ein paar Favoriten für mich herauskristallisiert, mit denen ich gut klar komme und bei denen ich bleiben werde.

Vor einiger Zeit habe ich mir einen gebrauchten Laserdrucker von HP gekauft, und zwar den HP LaserJet 1080, ein ziemlich altes Modell. Das Gerät war gut erhalten und technisch in einwandfreiem Zustand. Unter Windows gab es keinerlei Probleme – die Treiber wurden automatisch installiert und ich konnte sofort loslegen.

Unter GNU/Linux hatte ich dagegen erhebliche Schwierigkeiten. Zwar stellt Hewlett Packard das Treiberpaket HPLIP kostenlos zur Verfügung, aber ausgerechnet mit meinem Modell funktionieren diese Treiber nicht.

Doch es gibt einen inoffiziellen Treiber, er nennt sich foo2zjs. Damit sollte mein Drucker ans Laufen zu kriegen sein. Und tatsächlich klappten ab und zu die Ausdrucke, beim nächsten Versuch dann aber wieder nicht, egal unter welcher der GNU/Linux-Distributionen, die ich einsetze.

Nun, mein Fehler war: Ich hatte gedacht, ich müsste für meinen Drucker den alternativen Treiber zusätzlich zu dem von HP installieren. Das war falsch. Der Drucker läuft nur, wenn man ihn ausschließlich mit dem freien Treiber betreibt; anders gesagt, ich musste den Drucker von dem HP-Treiber entkoppeln und nur foo2zjs verwenden. Seitdem ich das so gemacht habe, tut der gute alte Drucker auch zuverlässig seinen Dienst.

Unter der Distribution Antergos, einem Arch-Derivat, konnte ich ab irgendeinem Zeitpunkt keine Pakete aus dem AUR mehr installieren. Es erschien im Terminal immer die folgende Fehlermeldung: curl error: Problem with the SSL CA cert (path? access rights?)

Die Lösung habe ich im Antergos-Forum gefunden: Es fehlte ein bestimmtes Paket. Als ich es nachinstalliert hatte, klappten die Installationen wieder wie gewohnt. sudo pacman -S ca-certificates-utils