Die letzten Tage waren sehr arbeitsreich/nervenaufreibend: Nachdem mir das Devuan-Testing-System kaputtgegangen war, habe ich noch mal ganz von vorne begonnen. Diesmal mit den dann doch unverzichtbaren zwei weiteren Partitionen für GPT und Secure Boot, deren Fehlen mir erst beim versuchten Zurückspielen eines Images aufgefallen sind, da danach das System nicht bootete. Als Ursache der zerstörten Paketdatenbank konnte ich nicht das "fehlerhafte" Testing, sondern Bleachbit ausmachen. Denn mit diesem wunderbaren Aufräumtool sollte man keinesfalls die Paketdatenbank aufräumen lassen, da sie anschließend kaputt ist. Nachdem mir diese Stolperstrocke klar wurden, konnte ich dann auch ein Devuan 7.0 "Freia" (z.Zt. Testing) installieren und bin ENDLICH wieder arbeitsfähig.
 

Hallo Dr.Tux,

ein Produktiv-System schlank und sauber zu halten, sowie regelmäßiges Housekeeping ist sicher eine gute Idee. Bleachbit scheint dann ja nur bedingt geeignet zu sein.

Welche Bleachbit Funktionen sollte man dann unbedingt meiden bzw. welche Sicherheitsvorkehrungen sollte man vor der Anwendung berücksichtigen?

Um Mis(t)verständnissen vorzubeugen: Bleachbit ist ein tolles Tool, dessen Installation sich lohnt - schon alleine, weil es mehr Müll rausträgt, als es selber durch die Installation auf die Platte bringt. Beim ersten Durchlauf sind es üblicherweise dreistellige Megabytes (unnötige Lokalisierungen in zahlreichen unbenutzten Sprachen, massenweise Temporärzeugs zahlreicher Anwendungen, etc.) die es weg schaufelt.

Dann ist zu unterscheiden zwischen der Benutzung in der Konsole und dem grafischen Einsatz von Bleachbit. Bei letzterem kann man sich die gewünschten Putzteufel zusammenklicken und sogar einen Testlauf machen. In der Konsole werden die Cleaner individuell aufgerufen. bleachbit -l listet sie auf und mit bleachbit -c cleanergruppe.cleanername führt man Diesen aus.

Dann ist zu unterscheiden zwischen der Nutzung von Bleachbit als root und als Normalbenutzer. Hier führt die Auswahl von nur für den Admin zugänglichen Berechtigungen natürlich zu einer entsprechenden Fehlermeldung, so dass man diese Option dann wieder abwählen muss, damit Bleachbit fehlerfrei läuft. Und auch in diesem Kontext kann/muss ich mal wieder auf M*rksbuntu verbal eindreschen, da dieses in der Vergangenheit nicht dazu in der Lage war, die Konfigurationen von root und Benutzer auseinander zu halten. Bei Debian/Devuan hatte ich dieses Problem niemals. Ob dieser Fehler noch bei aktuellen Ubuntu-Versionen besteht, habe ich nicht mehr ausprobiert.

Da root bekanntermaßen NIEMALS die grafische Oberfläche starten soll, kann man Bleachbit vom Nutzer-Desktop aus in einer root-shell via bleachbit & (das & angehängt, um die Anwendung von der Konsole zu lösen, so dass diese wieder geschlossen werden kann, ohne das Programm selber zu beenden) starten (dazu einloggen via su, nicht via su -).

Um deine Frage zu beantworten: Meiner Erfahrung nach sind die Bleachbit-Optionen im Abschnitt APT tabu, da diese dann die Paketdatenbank zerstören. (Abgesehen davon, dass die Paketdatenbank zu löschen sinnfrei ist, da sie nach einem apt update eh neu eingelesen wird - was nach ihrer Zerstörung durch Bleachbit dann aber nicht mehr gelingt!) In der Vergangenheit war das nicht so. Aber derzeit kann ich vor diesen Optionen nur warnen. Alle anderen Optionen des Programms bereiten "sinnvoll" (wer beispielsweise in Firefox die Passwörter löscht und sich dann beschwert, dass sie weg sind, dem/der ist nicht zu helfen) eingesetzt, bereiten keine Probleme. Mit dem Gesagten im Hinterkopf empfehle ich Bleachbit daher weiterhin!

Ganz in Experimentierlaune habe ich das heute noch weiter getrieben:

Da ich hier ja noch eine "Apfelkitsche" rumliegen habe, wollte ich diese x86-Architektur dann endlich auch mal mit einem "ordentlichen" Betriebssystem bestücken. Zunächst hatte ich mal wieder Laune auf das gute alte  KDE Trinity ( WP ) - die Älteren erinnern sich. Da ich aber nach all den Jahren mit dem sehr puristischen Fluxbox ( LC , UU , WP ) inzwischen gar keine Lust mehr auf die "großen" Desktopumgebungen habe, habe ich mir dann doch wieder ein schlankes System aufgesetzt - was eh zu dem doch nicht gerade leistungsstarken Klappcomputer ganz gut passt und den Vorteil hat, dass ich die Konfiguration einfach rüberkopieren konnte und nur minimal anpassen musste, so dass ich in nur wenigen Stunden einen quasi voll lauffähigen weiteren Rechner habe.

Somit zeigt sich, dass es für diese Hardware noch nicht einmal eine "speziell angepasste" Distribution wie Linux Mint braucht. Selbst ein normales Debian oder Devuan läuft nahezu problemlos auf der Kiste. Die bisher einzig auffälligen Probleme sind, dass der Konsolenton beep bisher stumm bleibt und die eingebaute Kamera des Rechners nicht funktioniert (was sich durch eine USB-Kamera leicht ausgleichen lässt). Eine via USB hergestellte Ethernet-Verbindung wurde selbst vom Textinstaller sofort erkannt (im Gegensatz zum "Originalbetriebssystem"  - die Installation von WLAN habe ich nicht ausprobiert) Ob der Ton im Videochat übertragen wird, kann ich alleine natürlich nicht feststellen.  Ein USB-Hub ist somit unbedingt geboten. Ach ja: Das Touchpad scheint den Rechtsklick nicht zu erkennen und natürlich habe ich eine "richtige" Tastatur angeschlossen, um dieses Gemurkse über fingerbrechende Tastenkombinationen zu vermeiden (@, €, |, ^, ~ usw. sind auf der Originaltastatur eine echte "Herausforderung" )

Als nächste Baustelle steht die Installation des MacMini für einen schlanken Homeserver an - natürlich als reines Konsolensystem ohne grafische Oberfläche.

Und dann gibt es da die Dinge, die mich einfach sprachlos machen: Auch ohne den Einsatz von Bleachbit ist mir die Paketdatenbank reproduzierbar gecrasht. Nachdem ich zum dritten Mal in Folge das Image zurück geschrieben hatte, konnte ich die Fehlerursache finden: Ich versuche, das auf der Systempartition liegende Verzeichnis /tmp auf die Datenpartition zu verschieben und dorthin einen symbolischen Link zu setzen, da ich der Meinung bin, dass Temporärdaten nichts auf der Systempartition zu suchen haben. Also: ln -s ZIEL /tmp . Und genau nachdem ich dies erledigt habe, fliegt mir reproduzierbar ohne einen erkennbaren Zusammenhang die Paketdatenbank um die Ohren. Fällt euch dazu was ein?

Ich habe mich jetzt einen Tag lang mit dem Mac Mini
auseinandergesetzt. Unter großen Mühen habe ich auf die alte Büxe (von
2005) ein 32 Bit Devuan Oldstable bekommen, welches ich noch nicht mal
sichern kann, weil das DVD-Laufwerk fratze ist. Überhaupt dahin zu
kommen, auf diese "Gurke" ein System installieren zu können, hat Stunden
gedauert. Der Macbook Air ist ja schon ziemlich speziell. Aber diese
Kiste ist der Horror. Zunächst muss man mit einem Tool (siehe bei Option
2 ) die ISOs modifizieren, damit die überhaupt booten. Vorher gibt's nur
eine nichtssagende Fehlermeldung. Von USB bootet der gar nicht. Insgesamt kann ich die Kiste
eigentlich nur noch entsorgen.

Sprich: Für das Anwendungsszenario Homeserver/Fileserver werde ich mir
was anderes ausdenken müssen.

Mit einem linuxifizierten Air struntzen zu können, macht ja noch Spaß.
Aber insgesamt ist mein Bedarf zm Thema Apple echt gedeckt und deren
Produkte sind in meinem Ansehen nicht gerade gestiegen ...

Ein ordentlicher PC auf dem ich der Chef bin mit einem
selbstinstallierten Linux, das sagt mir immer noch am meisten zu.

Mageia Linux ( WP ) - einer von mehreren Nachfahren des legendären, aber leider abgewickelten Mandrake Linux (also rpm -basiert, WP ) - wurde gerade von der Community in der Version 10 veröffentlicht ( Linux Magazin , linuxnews ). Somit ist diese Upstream-Distro relativ nahe dran am aktuellen Softwarestand. Spannend an dieser Distribution ist neben der ziemlichen Einsteigerfreundlichkeit das distributionseigene "Mageia-Kontrollzentrum", welches die Konfiguration/Administration auch für Mausschubser handhabbar macht sowie die Besonderheit, dass sie als eine der wenigen Hauptdistributionen weiterhin (mit gesteigerten Anforderungen) für 32-Bit-Rechner angeboten wird. Mit den schlanken Desktopumgebungen wie LXDE etc. ist das sicher eine attraktive Option. Unterststützung für X.org und Wayland wird gleichermaßen geboten. Wer also mal in die rpm-Welt eintauchen will, findet hier eine spannende Distribution, die somit auch eine Alternative zu Linux Mint sein könnte.

Wer Lust auf mehr hat, kann mit "Cauldron" die Entwicklerversion installieren, die allerdings (so wie sie schreiben) "... dein Haus abbrennen oder deine Katze töten ..." kann. Dementsprechende Vorsicht ist also dringend geboten!

Seit kurzem ist ein neuer Mini-Installer für Devuan Unstable verfügbar. Der letzte war total veraltet und außerdem so kaputt ("Unstable" halt), dass er noch nicht mal die Festplatte erkannte - was einer Installation abträglich ist.  Seit letzten Monat gibt es eine überarbeitete Version des Mini-Installers, die ich testen wollte. Trotz Fehlermeldungen bekam ich ein lauffähig System auf die Platte. Allerdings war dies nicht Unstable, sondern Testing! Wie immer habe ich zunächst alles abgewählt und ein nacktes System ohne X-Server installiert und mir diesen mitsamt dem fenstermanager Fluxbox nachinstalliert. Am Ende bekam ich ein grundlegend lauffähiges System auf die Platte. Weiter habe ich das Experiment nicht geführt, da ich nur überprüfen wollte, ob es grundlegend gelingt.

Als nächstes Experiment habe ich mich an der neuen Mageia 10 versucht (Beschreibung siehe weiter oben). Und auch hier habe ich keine Standardinstallation durchgeführt, sondern ein vollverschlüsseltes Mageia mit dem Fenstermanager Fluxbox installiert. Nachdem ich am Textinstaller verzweifelt bin, habe ich dann doch den ähnlich aussehenden grafischen Installer genommen und dann ein rudimentäres System auf die Platte bekommen.

In den letzten Tagen wurde wieder einmal viel Staub aufgewirbelt mit der Ankündigung, dass Tuxedo OS von der Ubuntu-Basis auf Debian Testing wechselt. Generell ist das zu begrüßen und nachvollziehbar, dass der Anbieter keinen Bock mehr auf das Gemurkse von Canonical hat. Allerdings lohnt es sich mal wieder, hier die Details zu beachten. Zum Verständnis der Situation ist es vonnöten, die verschiedenen Debian-Zweige zu kennen ( fosstopia ). Inzwischen sickern genauere Informationen zu diesem ambitionierten Vorhaben durch ( GNU/Linux.ch , linuxnews , die Originalnachricht von Tuxedo ). Die Kommunikationsstrategie ist hervorragend und es ist zu hoffen, dass sich das Unternehmen mit diesem Vorhaben nicht übernimmt - vor allem in der Zeit des Übergangs zu einem neuen Debian Stable-Release, bei der es konzeptbedingt in Debian Testing "knallt", wenn schlagartig die Paketbasis des entstehenden Folge-Releases nach Testing rutscht. Ob hieraus dann nur ein "sicherheitsgepatchtes Repository" oder gar eine eigene Distribution wird (die auch auf Nicht-Tuxedo-Rechnern interessant sein könnte), das wird sich zeigen. Ob hier Debian Unstable die bessere Basis wäre, das kann man sicher kontrovers diskutieren, da Debian Sid sicher nicht für JedeN geeignet ist. Die Probleme der Bugfixes und des kontinuierlicheren Paketflusses würde diese Entscheidung jedenfalls besser lösen. Und weitergedacht könnte Tuxedo OS hier gleich auf Siduction ( WP ) setzen, um das ganze Betriebssystem hinreichend "stabil" und "anwenderInnenfreundlich" zu gestalten. Oder (wenn schon ein Wechsel der Basis angestrebt wird) über'n Horizont geblickt, beispielsweise auf openSUSE Tumbleweed oder Slowroll zu setzen, um hier ein "stabiles Rolling" hinzubekommen - was dann aber bedeuten würde, sich neben der prinzipiellen Arbeitserleichterung wiederum mit den Eigenheiten von SUSE herumschlagen zu müssen. Ob der Wechsel vom eigenwilligen Canonical zum eigenwilligen SUSE dann eine funktionelle Verbesserung wäre, das könnte dann ein weiteres Streitthema sein.