Stranger Than Usual

Hui... irgendein Paketupdate hat ganz schön die Dependencies in meinem System zerrüttet. Ich kann einen ganzen Haufen (z.T. ziemlich großer) Pakete neu bauen. Das kann dauern...

Edit: Ok, spezialisiert: Es ist libxcb-xlib, und es sind 115 Pakete.
Edit: Ok, revdep-rebuild musste nicht gemacht werden, ein kleines Skript und ein paar andere Änderungen haben es gebracht.

Soo... Ich habe endlich zum freien Radeon-Treiber gewechselt.
Was mich dazu getrieben hat, habe ich schon mehr lang als breit in diesem Blog beschrieben.
Ergebnis: Die Performance ist deutlich besser, als ich sie in Erinnerung hatte, Compiz läuft damit flüssig, auch wenn es bei Spielen wie Tuxracer schon so stark ruckelt, dass es unspielbar wird. Gut, vielleicht ist ds ja anders, wenn ich nicht Compiz im Hintergrund laufen habe.
Der große Vorteil der Treiber ist vor allem: Er wird noch weiterentwickelt, und zwar frei. Das heißt erstens, dass selbst dann noch Hoffnung besteht, wenn sich alle jetztigen Programmierer von dem Projekt verabschieden sollten und zweitens, dass es mit der Performance noch besser wird.

Ich werde jetzt übrigens erst einmal alle Updates nachholen, die ich aufgrund der alten Treiber verschoben habe, sprich: Kernelupdates. Damit funktionieren dann vielleicht auch andere Dinge besser.

PS: Während bei mir die Update bisher reibungslos verliefen, ist der Applefreak noch nicht zu seinem Update gekommen: Amazon hat es offensichtlich nicht geschafft, Snow Leopard in ausreichenden Mengen anzuschaffen, so kommt seine Bestellung erst nächste Woche an.

Heute ist es angekommen: Das MSI-Wind-Netbook.
Vorinstalliert war SuSE. Sah recht gut aus, es war auch eine ordentliche Vorauswahl an Programmen installiert, eigentlich hätte es sofort losgehen können.
Aber ich bin ja erstens Geek und zweitens Perfektionist. Mit SuSE habe ich schlechte Erfahrungen gemacht was den Paketmanager sowie die von mir gewünschte absolute Kontrolle über das System anging.
Also habe ich Debian drauf installiert. Momentan richte ich die Kiste ein und installiere die wichtigsten Programme darauf.
Warum Debian, wo die, die mein Blog verfolgen doch wissen, dass ich normalerweise gentoo einsetze?
Nun, da gentoo eine quellbasierte Distribution ist, dauert Installieren von Software immer recht lange. Besonders, wenn es eine kleine Kiste mit gerade einmal einem Kern mit 1,6GHz ist. Gut, ich habe auch schonmal auf Kisten mit nem 1,2GHz-Prozessor gentoo installiert (oh, und natürlich auf einem alten G3), aber für ein System, dass ich täglich benutze und auf dem ich vermutlich viel installieren werde, ist mir das irgendwie zu lahm.
SuSE fiel dabei natürlich raus (s.o.), mit Ubuntu stehe ich auf Kriegspfad (wie bei SuSE, nur das Ubunut wenigstens eine ordentliche Paketverwaltung hat), also fiel die Wahl auf Debian. Ist sehr weit verbreitet, viele andere Distributionen bauen darauf auf, kurz: man sollte es kennen. Und wie kann man es besser kennen lernen, als es täglich zu benutzen?

Oh-Oh... meine kürzlichen Erfolge, was Wake On Lan angeht wurde kurze Zeit später von einem anderen Ereignis überschattet: Offensichtlich wollte eine Festplatte nicht mehr so wirklich.
Symptom: Schreibrate 0,1 MB/s, Leserate normal.
Da die Leserate normal war, dachte ich mir, dass es sicherlich nicht falsch ist, erst einmal ein Backup zu machen. So, jetzt kann die Platte von mir aus auch komplett den Bach runter gehen, das System ist sicher.
Aber vielleicht ist sie ja garnicht kurz vor dem Verrecken, sondern es ist nur ein einmaliger Fehler (ersteres würde mich aber nicht wundern, immerhin ist die Platte schon >5 Jahre alt).
Also auf der Kiste ein anderes System gebootet und von dort aus das Dateisystem mit fsck geprüft. Partition für Partition. Fehler gefunden und behoben... nur stürzt der komplette Rechner (!) bei der letzten Partition immer ab. Warum? Keine Ahnung, Linux sollte so etwas nicht tun. Bei Gelegenheit werde ich mal nachforschen, woran das liegen könnte.
Was passiert, wenn man einfach mal die Abstürze verursachende Partition neu formatiert? Gedacht, getan, das Backup aufgespielt, die Schreibrate war zufriedenstellend.
Aaaaber... man könnte ja noch mal zur Sicherheit die Platte checken. Dank dieses Howtos mal ein wenig Festplattencheck gemacht und irgendwelche Fehler gefunden. Bin gerade dabei herauszufinden, welche, und wie kritisch die Lage ist. Bis ich das weiß, werde ich keine Aussagen mehr machen.

PS: Ich habe mit jetzt ein Netbook bestellt - das ewige Schleppen mit diesem Laptop ist doch irgendwie nervig...

Ich glaube das einfach nicht...
Ich habe lange Zeit folgendes Problem mit Wake On Lan unter Gentoo-Linux gehabt:
Die Kiste reagierte nicht auf Magic-Pakete, wenn sie vorher ordentlich heruntergefahren wurde. Wurde sie nur bis ins BIOS hinein gebootet und dann abgewürgt, funktionierte alles prima.
Nach einer Suche im Netz bin ich irgendwann auf diesen Thread hier gestoßen. Bei diesem Benutzer hatte sich nach ordentlichem herunterfahren die Mac-Adresse seines Rechners vedreht, d.h. was vorher links war, war nachher rechts.
Aus Verzweiflung habe ich einfach mal ausprobiert, ob bei mir auch dieser absurde Fehler auftritt, und siehe da: mit der verdrehten Mac-Adresse kann ich die Kiste per WoL einschalten.
Klasse... wenn ich herausgefunden habe warum das so ist, sage ich Bescheid.

Hng... Warum bringt es ati einfach nicht fertig, seine Treiber für den 2.6.29-Kernel zum Laufen zu bringen? Gestern freute ich mich, als ich feststellt, dass endlich der neue Treiber raus ist, aber nach der Installation lief:
nichts. Nicht einmal der Treiber lies sich laden. Murmelte irgendwas von "Cannot allocate Memory" und verabschiedete sich. Gut, es waren auch nur etwas über 2700MB frei...
Fglrx, also eben dieser Treiber von ati ist eine Würgerei. Nach endlosen Versuchen bin ich dann wieder auf die Vorgängerversion zurückgestiegen, die ich irgendwann mal mithilfe eines Patches installiert habe. Frustrierenderweise muss ich gerade daran denken, dass es mich eine halbe Ewigkeit gekostet hat, die Reste dieses Treibers vor der Aktualisierung des Systems zu entfernen, da der installer wirklich das ganze System infiltriert. Jetzt lebe ich erst einmal noch mit dieser unausgegorenen Lösung, die zudem noch haufenweise Fehlermeldungen auswirft (naja, die sieht man ja nur, wenn man an der richtigen Stelle nachschaut :/).
Diese Proprietären Ati-Treiber machen mich fertig.

Aber hey - wenigstens fährt mein System jetzt wieder sauber herunter: Problem war: Alsasound ließ sich nicht beenden. Die Module lassen sich nicht unloaden. Workaround: Alsasound sagen, dass es die Module dann eben nicht unloaden soll: in der Datei /etc/conf.d/alsasound folgenden Eintrag machen:
UNLOAD_ON_STOP="no"

Edit: Ich wundere mich gerade ein wenig... Laut der offiziellen Ati-Seite gibt es noch gar keinen Treiber der Version 9.6...
Edit 2: Ok, man kann ihn auf der offiziellen Seite nicht herunterladen. Aber er existiert...

267 Upgrades auf meiner alten Kiste... da lässt man die mal ein paar Monate links liegen, und dann das.
Jetzt wird die Kiste vermutlich die ganze Nacht durchrechnen :(

Eigentlich ist es ja ne tolle Sache: Der Xorg-Server findet jetzt in den meisten Fällen von selbst heraus, welche Treiber er für welche Hardware laden muss, riesige xorg.conf-Dateien gehören der Vergangenheit an.
Wenn man gerade einen neuen X-Server aufsetzt, ist das ganz toll.
Wenn man einen schon vorhandenen X-Server aktualisert, ist es eine Katastrophe.
Als erstes geht entweder nichts mehr, oder zumindest kein Eingabegerät mehr. Bei meinem ersten Versuch habe ich nach einer kurzen, verzweifelten Suche im Netz einfach Xorg ohne Hal-unterstützung kompiliert und so weiter gemacht, wie bisher... Jetzt wollte ich aber auch mal die ganze Sache auf den Stand der Technik bringen.
Im Prinzip ganz leicht... xorg.conf löschen... halt! Der fglrx-Treiber braucht noch einen Eintrag...
Ok... xorg neu gestartet... hmm... englisches Tastaturlayout... an sich kein Problem, aber wo kann ich das in dieser ganzen Geschichte umstellen?
Ah... eine XML-Datei, die Hal erklärt, wie es mit der Tastaur umzugehen hat...
Vergleich: Der Befehl für ein deutsches TastaurLayout:
vorher: Option "XkbLayout" "de"
nachher: <merge key="input.xkb.layout" type="string">de</merge>
Man sieht also: Ein merklicher Overhead...

Naja, mittlerweile Funktioniert alles wieder, und ich kann mich an das setzen, was ich eigentlich noch machen wollte.

Updates, updates, udates... momentane Uptime 1d 11h 45m.
Für einen Server wäre das nichts... aber für einen Laptop, bei dem zudem noch die Hibernate-Funktion Ärger macht, ist das ganz ordentlich.
Ach ja: Das Update lief verhältnismäßig reibungslos.

...und ich habe mir letztens Stress gemacht, als ich Kommandozeilenparameter selbst geparsed habe.
Dabei gibt es dafür doch eine ganz einfache Funktion, die in unistd.h deklariert ist. Ich sollte mir häufiger mal Quellcodes von anderen Programmen anschauen, da findet man solche Sachen heraus... schneller als mit einer Suche im Internet.