In meinem letzten Beitrag bin ich nicht dazu gekommen die Bootzeit von Karmic zu analysieren. In den Medien hieß es ja, es solle sehr viel schneller starten. Ich mache leider genau die gegenteilige Erfahrung.

Vergleicht man die Bootzeiten von Intrepid, Jaunty und Karmic, so sieht man dass Jaunty rund 15 Sekunden schneller als Intrepid war, Karmic allerdings um einiges Langsamer ist.

Man muss natürlich auch dazu sagen, dass diese Zeiten nicht vergleichbar sind. Mein neues Karmic System ist verschlüsselt und beim Desktop wird der Instant Messenger und der Musikspieler mit gestartet, was zuvor nicht der Fall war.

Würde ich die 15 Sekunden Überhang wegen der Festplattenverschlüsselung abziehen und noch großzügig weitere 15 Sekunden wegen den Programmen im Autostart so bin ich immer noch mit Jaunty gleich auf, also keinerlei Verbesserung.

Die Zeiten für die Kernel Initialisierung, also der Zeitpunkt an dem der tatsächliche Bootchart anfängt haben sich durch die Bank verschlechtert, von 2 auf fast 4 Sekunden. Was ist da schief gelaufen?

Auch die Verschlüsselung hat sich mit meinem heutigen Update um 2 Sekunden verschlechtert. Es lastet eine CPU voll aus für eine Sekunde, lastet danach die Festplatte für drei Sekunden voll aus um danach noch eine Sekunde nichts zu tun bevor es mir bestätigt, dass mein Kennwort richtig war und dann mit dem Startvorgang fortfährt. Vor dem heutigen Update hat es nur drei Sekunden gedauert, was auch schon unakzeptabel war. Da ist also auch einiges schief gelaufen.

Man sieht auch sehr deutlich den bereits erwähnten Overhead mit couchdb. Das kann man wirklich nur noch als FAIL bezeichnen.

Auch sind Lücken drinnen in denen der Rechner einfach nichts macht, die sich auf vier Sekunden summieren. FAIL.

Ich frage mich echt wie Ubuntu das gesetzte Ziel von zehn Sekunden zum nächsten Release erfüllen will. Dieses Ziel ist auch nur auf einer bestimmten Referenzplattform gesetzt die mit SSD bestückt ist, somit also null IO Overhead aufweist. Ich befürchte aber, dass Leute mit langsamen Laptopfestplatten in die Röhre schauen werden dabei. Sehr schade.

Bereits vor einiger Zeit hatte ich ein kleines Review zum neuen Ubuntu, genannt Karmic Koala verfasst. Schon damals war ich mit dem neuesten Stand der Dinge nicht wirklich glücklich. Heute einen Tag vor der offiziellen Veröffentlichung habe ich mein System wieder auf den neuesten Stand gebracht. Leider hat sich seither kaum was verbessert. Nur ein Problem, welches mich beim booten geplagt hatte wurde beseitigt.

Ich muss an dieser Stelle auch Kritik an Ubuntu üben denn so kann es einfach nicht mehr weiter gehen. Es werden immer mehr unnütze Funktionen hinzugefügt, die das System unnötig ausbremsen. Neuerdings ist Couchdb dazugekommen welches es ermöglichen soll Einstellungen und persönliche Dokumente mit einem Server und damit anderen Desktops abzugleichen. Auch wenn man diesen Dienst nicht nutzen will wird er trotzdem beim hochfahren gestartet und schluckt Systemressourcen. Das schlimme daran: Der Dienst ist in einer exotischen Sprache namens Erlang geschrieben und benötigt aus welchen Gründen auch immer XULRunner. Somit läuft ein weiterer Systemdienst mit einer interpretierten Sprache und verbraucht dementsprechend mehr als 10M Speicher. Beim starten fragt es irgendwelche Sachen von XULRunner ab wodurch dieser beim booten gestartet wird, was eine Menge ausmacht, denn XULRunner ist eine riesige Applikation.

Ubuntu sollte endlich Abstand davon nehmen Systemdienste in Python, Perl, Erlang oder sonst irgendwas zu implementieren. Da könnten sie ja gleich anfangen alles in Java oder C# zu machen. Ubuntu sollte mehr investieren um das System so leichtgewichtig wie möglich zu halten und unnötige Funktionen vermeiden.

Gnome an sich macht in diese Richtung schon vieles. Veraltete Bibliotheken werden über Bord geworfen um die Anwendungen abzuspecken. Außerdem wird HAL langsam aber sicher durch Udev ersetzt. Ubuntu hat zwar das Ziel HAL über Bord zu werfen auch verfolgt aber dennoch werden bei mir zehn oder mehr HAL Prozesse beim hochfahren gestartet und bleiben danach im Speicher. Dies ist doch eine gute Möglichkeit Startzeit zu verkürzen und Speicher nicht unnötig zu verbrauchen.

Ähnlich den Bootzeit Meilensteinen sollte Ubuntu auch für den Speicherverbrauch klare Meilensteine und messbare Ziele definieren. Ein fertig gestartetes System mit allen Systemdiensten die in der Standardinstallation dabei sind sollte nicht mehr als z.b. 170M für die 32bit und 250M für die 64bit Version verbrauchen. Dies natürlich auf einem genormten Referenzsystem, denn die Hardware macht bezüglich Grafik einiges aus.

Lange haben ich und einige Freunde auf Windows 7 gewartet. Vor kurzem dann ist es im eAcademy erschienen und ich habe mir eine kostenlose Studentenlizenz gegönnt :)

Und ich muss sagen: Ich bin positiv überrascht. Die Installation war einfach und schnell. Mit Ausnahme von Touchpad und Grafikkarte wurden alle Gerätetreiber direkt über das Windows Update installiert. Das WLAN hatte selbst schon während der Installation funktioniert. Das System selbst fühlt sich recht schnell an, verbraucht in der 32bit Version nur um die 500M. Nachdem ich einige Dienste deaktiviert hatte änderte sich daran nicht sehr viel, der Verbrauch liegt immer noch bei rund 500 oder etwas darunter. Also bleiben mehr Ressourcen für speicherhungrige Spiele über. Bionic Commando läuft zumindest recht brauchbar, auch wenn es ein wenig ruckelt. Die Startzeit ist auch zufriedenstellend. Ich war außerdem sehr überrascht als ich sah, dass das System nur knappe 10G auf der Festplatte belegt. Inklusive 2G Swap und 1,5G Suspend Dateien.

Man kann also zu recht sagen: Windows 7 ist das bessere Vista so wie es von Anfang an hätte sein sollen.

Neben Windows 7 habe ich auch die neueste Alpha Version von Ubuntu, genannt Karmic Koala ausprobiert. Bisher bin ich leider etwas enttäuscht muss ich ehrlich zugeben. Anders als in einer virtuellen Umgebung verbraucht das System nicht um die 200 sondern etwas über 300M Speicher. Auch von den Anstrengungen zur Verkürzung der Bootzeit merke ich sehr wenig. Ich habe diesmal Autologin aktiviert, welches etwas Zeit spart aber mir scheint dass das neue xSplash diesen Gewinn wieder zunichte macht. Große bahnbrechende Änderungen sehe ich bisher nicht, es wurde wohl vor allem im Hintergrund sehr viel aufgeräumt. Eigentlich hätte ich gehofft das die vielen Aufräumungsarbeiten in Gnome etwas Speicher gespart hätten aber bisher merke ich davon nichts.

Ein neues Programm für den Umgang mit Festplatten und Partitionen ist enthalten. Damit kann man einfach Partitionen verwalten, auch mit RAID und Verschlüsselung. Negativ fällt mir dabei auf, dass sich das Programm bei jedem Start darüber beschwert dass meine Festplatte defekte Sektoren hätte. Da mir das bisher noch nie aufgefallen ist würde ich meinen dass es sich um Fehlalarm handelt. Diese Meldung ist allerdings sehr nervig, genau wie die Meldung beim Herunterfahren dass noch Programme laufen würden, die ich allerdings schon seit langem beendet hatte. Da muss eindeutig noch nachgebessert werden.

Eines meiner Ziele als ich den Laptop neu aufgesetzt hatte war es, das System von vorn bis hinten komplett zu verschlüsseln. Dies hat mir leider einen Tag Arbeit zu nichte gemacht. Denn für die Truecrypt System Verschlüsselung unter Windows ist es zwingend notwendig, Windows auf der ersten Partition zu installieren. Nachdem ich also ein zweites mal alles installiert hatte wurde die Windows System Partition verschlüsselt. Der Vorgang selbst ich recht einfach, aber mit dem Ergebnis bin ich nicht ganz zufrieden.

Will ich Windows starten, so gebe ich in dem Zuerst erscheinenden Truecrypt Bootloader mein Passwort ein und werde danach zu Grub umgeleitet wo ich dann Windows auswählen muss.

Will ich Linux starten so überspringe ich den Truecrypt Loader und Lade dann über Grub Linux. Erst danach gebe ich mein Passwort ein.

Einfacher wäre es sicherlich wenn zuerst Grub erscheint und danach die jeweilige Passworteingabe mit anschließendem Systemstart. In einigen Foren habe ich gelesen, dass der Truecrypt Loader sich über ein Defektes System beschwert sobald man wieder Grub in den MBR schreibt und von Grub aus den TC Loader startet. Also lass ich es lieber vorerst.

Was mich an der ganzen Sache extrem anpisst ist die Tatsache, dass ich in Linux meine Windows Partition nicht einbinden kann. TC beschwert sich zunächst über die Tatsache, dass die Systemverschlüsselung grundsätzlich verschieden ist zur Partitionsverschlüsselung. Wähle ich explizit Systemverschlüsselung so erzählt es mir irgendwelche wilden Geschichten über ASCII und Englische Tastaturen was in meinem Fall aber kaum ein Problem darstellen sollte.

Warum auch immer, ich komme aus dem Linux heraus nicht auf die Windows Partition. Sehr ärgerlich. Ich hatte zwar die Linux Partition mit 30G etwas größer bemessen um mehr Quellcode und Object-Dateien unterbringen zu können, aber für meine Musik- oder Filmsammlung reicht dies nicht aus. Mal sehn was sich da noch machen lässt, vielleicht muss ich doch etwas mit Tastaturlayout spielen.

Es fällt mir immer wieder auf wenn ich unter Linux mit Truecrypt arbeite, das es mein gesamtes System verlangsamt oder zum Teil sogar unbenutzbar macht.

Wenn dies auftritt sehe ich im Systemmonitor einen Haufen pdflush Prozesse. pdflush ist ein Kernel Prozess, der dafür sorgt dass "dirty" pages geschrieben werden.

Ich vermute dass folgendes passiert: Truecrypt erstellt eine memory-mapped Datei, wodurch dieser Datei einige Pages zugeordnet werden. Es schreibt dann in diese pages neuen Inhalt rein. Dadurch wird die noch nicht existierende Page auf der Festplatte und die Im Hauptspeicher unsynchron, "dirty". Sie muss also demnächst auf die Festplatte geschrieben werden um wieder synchron zu sein. Dieses "flush" kann nach gewissen Kriterien erfolgen. Entweder in gewissen Zeitabständen (vgl. /proc/sys/vm/dirty_writeback_centisecs = 500 = alle 5 Sekunden) oder eben wenn der Speicher voll ist. Ich denke das bei mir vor allem die zweite Regel zieht. Der Speicher ist voll mit unsynchronen cached pages. Nun muss jedes einzelne Programm, welches neuen Speicher verwenden will darauf warten bis genügend pages geschrieben worden sind und somit genug Speicher frei ist.

Dadurch kommt es zu einer Wartezeit zwischen dem Moment in dem ich ein Programm anspreche und dem, dass das Programm reagiert. Es muss erst auf die Festplatte warten bis es selbst neuen Speicher verwenden darf.

Zum Teil sind diese Wartezeiten aber dermaßen groß, dass ich sogar ein anderes Problem vermute. Ich vermute das noch andere Truecrypt Prozesse in der Warteschleife sind um auf neuen Speicher schreiben zu dürfen, und diese sind scheinbar dran noch bevor mein Programm, dass tatsächlich echten Speicher haben will, diesen bekommt. Die Wartezeit bis Programme reagieren erhöht sich somit noch mehr.

Ich bin mir nicht sehr sicher, ob ich den Sachverhalt richtig verstanden oder geschildert habe. Ich frage mich allerdings, ob ich den Speicherverbrauch für caches irgendwie regeln kann, so dass Programmen immer ein gewisser Speicher zur Verfügung steht, ohne dass sie darauf warten müssen bis cached pages auf die Festplatte geschrieben werden. Gibt es denn so eine Einstellung?

Anstatt das udev Problem zu lösen, ist Scott James Remnant damit beschäftigt über Versionskontrollsysteme zu fluchen.

Er trifft es sehr gut, wenn er sagt, dass er solche Systeme gar nicht benutzen will. Aber es ist ein nötiges Übel wenn man Software entwickelt.

Er nennt eine Liste von Aktionen, für die ein Softwareentwickler ein Versionskontrollsystem braucht. Je mehr überflüssige Kommandos es gibt oder je mehr zusätzliche Parameter man den Kommandos mitgeben muss, umso höher steigt der Hass Index für das jeweilige System.

Ganz besonders verhasst ist für ihn das Kommando add. Er will nicht jede neue Datei einzeln hinzufügen müssen. Ich muss auch sagen, dass dafür ein Kommandozeilen System auch wenig Benutzerfreundlich ist, wenn man jeden Dateinamen einzeln eintippen muss. Dafür ein GUI nützlicher.

Ich persönlich habe sehr viele Dateien im Ordner der Versionskontrolle, die ich nicht versionieren will, von daher bin ich persönlich dafür ein add Kommando zu haben.

Folgende Aktionen nennt er als relevant: get, commit, push, pull, review, merge, log, diff und show.

Wenn ich mir seine Erläuterungen durchlese, merke ich, das Mercurial auf seiner Hass Liste eigentlich nicht sehr weit oben sein dürfte, denn für die genannten Aktionen stehen einfache und intuitive Kommandos zur Verfügung.

Get - Eine Kopie eines Quellcodes erstellen, um daran Veränderungen vorzunehmen. hg clone http://hg.mozilla.org/mozilla-central

Commit - Die aktuellen Änderungen speichern. hg commit -m"Kommentar". Falls nicht jede Datei einzeln hinzugefügt werden sollte, benutzt man hg commit -A -m"Kommentar", das ist nicht wirklich viel Aufwand.

Push - Die eigene Kopie des Quellcodes veröffentlichen. Das ist leider ein komplizierteres Thema. Ein hg push funktioniert nur, falls bereits ein Server installiert ist. hg clone ./ ssh://swatinem.de/var/www/hg/bla schiebt die Änderungen auf einen entfernten Server. Dennoch braucht man dafür leider einen konfigurierten Apache. hg serve erstellt temporär einen eigenen Webserver. Nun muss man allerdings die eigene IP benutzen um an die Daten zu kommen.

Pull - Das ist ein einfaches hg pull -u. Leider wird es komplizierter, sobald man selbst Änderungen seit dem letzten pull gemacht hat. Dann wird ein hg pull && hg merge daraus.

Review - Ein hg incoming listet die Änderungskommentare auf. hg incoming -p zeigt auch die Änderungen selbst an.

Merge - das selbe wie Pull eigentlich.

Log - hg log oder hg glog

Diff - hg diff

Show - hg export tip, wobei tip immer die aktuellste Version ist. Oder eben eine andere Version.

Ganz einfach ist Mercurial nun auch wieder nicht. Aber ich schätze mal, dass man gut damit zurecht kommen kann.

Ich benutze Mercurial leider in einem komplizierteren Szenario. Ich arbeite mit Patches, die ich zwischendurch ändern, aufsplitten und zusammenführen will. Außerdem will ich die Patches immer aktuell haben. Mercurial Queues, mq, macht es mir da nur bedingt einfach. Vor allem die Aufgabe Patches aktuell zu halten ist ein sehr komplizierter Prozess und sorgt immer wieder für Ärger.