Vor langer Zeit hatte ich mir mal ein Barebone Shuttle XS35 zugelegt. Absolut Lautlos (ohne Lüfter und mit SSD) und einer nvidia-Grafikkarte mit HDMI, sollte dies so eine Art Medienserver für den Fernseher werden. Allerdings hatte ich das Ding nie wirklich fertig installiert. Zum Beispiel funktionierte Sound über HDMI noch nicht. Daher kam das Gerät kaum zum Einsatz. Und so schlummerte darauf seit dem ein vor sich hin rostendes Debian Testing. Ich hatte das damals installiert, weil ich mir auf dem Gerät keine Release-Upgrades geben wollte. Und Debian Testing ist dafür gut geeignet: Es bietet Rolling Release und fast ähnlich aktuelle Software wie ein frisches Ubuntu. Aber nun war es Zeit  – wenn die Frau schon mal Freitags abend weggeht – für eine Generalüberholung, und zwar gleich mit Ubuntu 15.10. Wie das klappte und was es zu beachten gibt, erfahrt ihr hier. Weiter lesen »

Vor ein paar Tagen habe ich mein Ubuntu – besser gesagt Kubuntu – noch schnell abends auf 13.10 aktualisiert, aber mal wieder zwischendurch vergessen, was ich beim letzten Update machen musste, um meinen elenden USB-Drucker zu reaktiveren… ist ja auch schon ein halbes Jahr her.

Zum Update selbst kann ich berichten, dass in meinem Fall (Lenovo Carbon X1) alles glatt lief. Zumindest, nachdem ich einige alte Kernel entfernt hatte. Die initiale 12.10 hat einfach zu wenig Platz für /boot angelegt, gerade einmal 229 MB. Was toll ist: Nach dem Suspend-to-Ram ist nun das WLAN noch schneller, eigentlich sofort wieder da. Das fetzt. Ob das Update überall so einfach ist, steht in den Sternen. Kubuntu hat ja einige Änderungen vom Ubuntu-Core nicht übernommen. Mir fiel auf, das viele boost-Bibliotheken entfernt worden sind. Das waren doch so einige.

Auf jeden Fall wird mein nächster Drucker netzwerkfähig sein, das steht schon mal fest. 🙂

Seit dem ich von Debian Testing auf Ubuntu, genauer gesagt Kubuntu, wechselte, war für mich die Computerei mit Linux in etwas ruhigeres Fahrwasser geraten. Statt dem Rolling Release von Debian, bei dem täglich mit neuen Paketen rechnen konnte, tauchte bei Kubuntu die gleiche Menge an Updates eher pro Woche auf und enthielt in der Regel nur keine Bugfixes. Nun stand mit der Erscheinung von Ubuntu’s neuer Version 13.04 namens Raring Ringtail allerdings das erste größere System-Upgrade bevor. Hier mein kleiner Erfahrungsbericht zum Update.

Weiter lesen »

Ich freue mich gerade auf die demnächst zu erwartenden Ergebnisse der aktuellen Entwicklung ksmcon. Kmscon ist ein Terminal–Emulator im Userspace. Terminals sind diese komischen Eingabebildschirme (“Konsole“), die per Strg+Alt+F1 bis F7 außerhalb des X-Systems liegen. Braucht eigentlich niemand mehr.

Das tolle daran sind aber zwei Dinge. Das erste schöne ist die Möglichkeit des Emulators, mit verschiedenen Fonts und mit Hardware-Beschleunigung zu arbeiten. Man könnte dort also direkt Japanisch (!) schreiben. Das erinnert mich an meine ersten japanischen Schreibprogramme unter DOS, die habe ich damals noch in Turbo Pascal verbrochen. Zum anderen finde ich aber toll, dass der Emulator im Userspace liegt. Das steht für mich für ein gutes, modulares Design und eine höhere Sicherheit durch bessere Kapselung vom Kernel-Code.

Denn insgesamt habe ich aktuell das Gefühl, der Kernel könnte eine kleine Verschlankung benötigen. Wenn ich die ChangeLogs auf kernel.org lese, habe ich den Eindruck, dass sich die meisten Änderungen auf Treiber beziehen. Dabei wäre es m.E. schön, wenn man einen “Kern”-Kernel hätte, also einen sehr schlanken und stabilen Code ohne spezielle Geräte-Treiber für Gadgets. Der Code dieses Kernels wäre nicht ganz so häufig Änderungen unterlegen und man müsste ihn auch bei Treiber-Updates nicht immer neu kompilieren. Dazu könnte man die Treiber-Module in einen separaten Source–Pack oder gar verschiedene Packs auslagern, die man nur bei Bedarf kompilieren oder aktualisieren müsste.

Als ich im März 2010 meine LPIC-1-Prüfung abgelegt habe, war ich mir nicht sicher, ob ich die beiden notwendigen Teilprüfungen an einem Tag ablegen durfte. Ich schrieb daher eine Mail an das LPI – das Institut, welches die Prüfungen hoheitlich verwaltet.

Und schon gestern erhielt ich erstaunlicherweise die Antwort! Ein Blick in den Header der Mail verriet mir, dass hier ein hoch-professioneller Support-Prozess dank OTRS im Gange ist.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Ihre E-Mail mit folgendem Inhalt ist bei uns eingegangen:
 
---------------------------------------------------------
 
Hallo,
ist es möglich, beim Chemnitzer Linuxtag
beide Prüfungen, 101 und 102, am selben Tag
abzulegen (10:30 und 12:30)?
Vielen Dank
Mathias Lieber
 
---------------------------------------------------------
 
Wir werden Ihre Anfrage in Kürze bearbeiten.
 
Viele Grüße,
 
Customer Support LPI CE

Ihre E-Mail mit folgendem Inhalt ist bei uns eingegangen:

---------------------------------------------------------

Hallo,
ist es möglich, beim Chemnitzer Linuxtag
beide Prüfungen, 101 und 102, am selben Tag
abzulegen (10:30 und 12:30)?
Vielen Dank
Mathias Lieber

---------------------------------------------------------

Wir werden Ihre Anfrage in Kürze bearbeiten.

Viele Grüße,

Customer Support LPI CE

Seit Jahren wird an einem neuen ardour gebastelt, nun endlich soll es bald fertig sein! Am Mittwoch erschien die Version 3.0 Beta 4a, die angeblich die letzte Vorab-Version sein soll. Immerhin ist ardour 3.0 ab jetzt im “Feature Freeze”-Modus.

Bisher konnte man sich per SVN die neue 3.0-Serie auschecken und kompilieren, was auch oft problemlos klappte. Ich denke, es wird auch nach dem offiziellen Release eine Weile dauern, bis die ersten Distributionen das neue ardour reinpacken werden. Das Dateiformat ist glaube ich inkompatibel mit älteren Versionen geworden, vielleicht wäre es gut, beide Versionen parallel anzubieten.

Ich habe letztens bei einer Diskussion mit Kollegen gehört, dass Subversion ab Version 1.7 (10/2011) nicht mehr diese häßlichen verstreuten .svn-Verzeichnisse benötigt. Das ist doch mal was! Was war das nur für ein Krampf… Die Info ist auch Anlass, um zu schauen, was sich sonst noch geändert hat.

Natürlich ist das neue zentrale .svn-Metadata-Verzeichnis bereits für sich eine große Sache. Aber auch die interne Struktur der Metadaten hat sich verändert: Komprimierte Ablage von Daten (hat git auch), Hashes auf Datei-Inhalte (hat git auch), damit auch die Verwendung von Referenzen bei gleichem Inhalt (hat git auch) und in der nächsten Version soll es wohl auch Stashes (temporäre Änderungs-Speicher) unterstützen – das hat git bereits.

Dann gibt es noch ein Feature namens Merge-Infos, die sich verbessert haben sollen. Hatte ich nie benutzt, ich weiß also nicht, was diese Merge-Infos bringen. Vom Namen her wüsste ich aber ungefährt, dass ich mir bei Git einen diff der beiden Vorgänger-Versionen zum Merge-Commit anschauen könnte, um eine “Info” über einen “Merge” zu bekommen. Und, das klingt auch toll: In-Memory-Caching auf SVN-Server-Seite. Das klingt tatsächlich schwer bei git umsetzbar, schließlich kann man das git-Protokoll oder http benutzen, muss aber nicht, und über ssh doch gehts auch. In der letzten Situation würde der In-Memory-Cache nicht ziehen, höchtens aufwändig zu invalidieren sein.

Noch ein Feature heißt “Optimierte Netzwerkübertragung”, vorrangig durch Komprimierung. Hier habe das Gefühl, das müsste git bereits so umsetzen, denn die Daten werden ja im Repo bereits komprimiert abgelegt, ganze ungeänderte Subtrees werden nur als Referenz von Revision zu Revision übernommen und wer mal auf einen aufwändigen Übertragungsprozess geschaut hat, sieht auch, wie vor der Übertragung ermittelt wird, welche Daten tatsächlich über den Äther müssen.

Also alles in allem habe ich den Eindruck, Subversion wird immer gitter. Ketzerische Frage meinerseits folglich: Warum traut sich das Subversion-Team nicht, SVN einfach wegzuwerfen und ihre Fähigkeiten im Git-Team einzubringen? Das wäre doch mal der berühmte Sprung über den Schatten. Oder braucht man tatsächlich zwei (inkompatible) Versionskontrollsysteme, von denen das eine die Fähigkeiten des anderen Stück für Stück nachprogrammiert?

Manche Sachen nerven, aber wenn es nicht allzu nervt, geht man eine Lösung nie an: Wenn man CIFS-Freigaben gemountet hat, sollten diese natürlich beendet (umount) werden, bevor die Netzwerkverbindung abgebaut wird. Dazu kennt Debian verschiedene Kill-Scripte in /etc/rc6.d/ beziehungsweise /etc/rc0.d/. Das Problem an der Stelle ist, dass in den reboot- oder shutdown-Modus per init erst gewechselt wird, wenn KDE sich fertig abgemeldet hat. Dann ist allerdings auch unter Umständen die per NetworkManager aufgebaute WLAN-Verbindung im Eimer.

Ein Grund mehr, Netzwerk-Verbindungen nicht im Desktop, sondern in /etc abzufackeln – warum sollte ein gewöhnlicher Nutzer einen Rechner in ein fremdes Netzwerk schleusen dürfen? Viel zu riskant, sagt da der Admin! Auf der anderen Seite nicht ganz so zeitgemäß. Der Trend geht eher zum Zweitrechner, und es gibt wohl mehr Rechner als Root-Accounts auf dieser Welt. Jeder ist also Root, und deshalb darf auch jeder seinen Rechner im Desktop dahin einstöpseln, wovon ihn sowieso nur noch ein beherztes sudo trennt.

Um das nervige Problem zu beenden, habe ich mir heute ein eigenes shutdown-Script geschrieben, welches myshutdown heißt und unter /usr/local/bin liegt. Es umountet also erst alle aktiven CIFS-Drives und beendet dann den Rechner per shutdown -h now. Zugegebenermaßen ein sehr krudes Mittel, weil KDE natürlich auch gern sauber beendet werden möchte, aber man kann es leider nicht allen recht machen.

1
2
3
4
5
6
7
8
9

#!/bin/bash
 
MNT=`mount | grep "type cifs" | cut -d' ' -f 3`
for mntpoint in $MNT
do
        umount $mntpoint
done
 
/sbin/shutdown -h now

#!/bin/bash

MNT=`mount | grep "type cifs" | cut -d' ' -f 3`
for mntpoint in $MNT
do
        umount $mntpoint
done

/sbin/shutdown -h now

Das ganze Script mit chmod a+x,u+s für alle ausführbar machen und wer will, kann das noch in die /etc/sudoers eintragen:

1

nudge   ALL=(ALL) NOPASSWD:/usr/local/bin/myshutdown

nudge   ALL=(ALL) NOPASSWD:/usr/local/bin/myshutdown

Das ganze kann man dann per khotkeys auf das KDE-Standard-Shutdown-Kürzel Strg + Alt + Bild runter mappen. Und schon gehts tierisch schnell ab in den Keller mit dem Rechner. Keine Timeouts beim Abwarten auf ein CIFS-Drive ohne Netzwerk mehr – hier sind 300 Sekunden Timeouts nicht Ungewöhnliches.

Wenn Ubuntu heute über einer absolut “neuen” Idee des Rolling Release brütet, dann kann man als Nutzer von Debian Testing  darüber nur müde lächeln. Rolling Release ist dort einfach Standard. Und zwar nicht, wie im Vorschlag benannt monatlich, sondern ein echtes Rolling Release, ohne Timeboxing. Da gibts jeden Tag frische Software.

Ansonsten kann ich den Vorschlag von Scott Remnant nur begrüßen: Persönlich möchte ich nie wieder ein System benutzen, bei dem ich jedes halbe Jahr um die Gesundheit meines Rechners bangen muss.

Das in Debian Testing enthaltene Libre Office hat heute eine Neuerung erfahren. Die verwendete Versionsnummer wurde von 3.3.2 auf 3.3.3 angehoben. Neue Features sind damit nicht verbunden, eher kleinere Bugfixes. Libre Office benennt in den Release Notes die Version folgendermaßen:

“This is the third update to the stable version of LibreOffice.
It contains only safe code fixes and translation updates, and is considered safe for production use.”

Außerdem verweist das Projekt an dieser Stelle auf Ungereimtheiten mit der Java-Umgebung von Sun (jetzt Oracle). Es wäre daher besser, OpenJDK zu verwenden. Um auf dieses umzustellen, verwendet man am besten update-alternatives:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ sudo update-alternatives --config java
 
Es gibt 4 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen).
 
  Auswahl      Pfad                                      Priorität Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      Auto-Modus
  1            /usr/bin/gij-4.4                           1044      manueller Modus
  2            /usr/bin/gij-4.6                           1046      manueller Modus
* 3            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      manueller Modus
  4            /usr/lib/jvm/java-6-sun/jre/bin/java       63        manueller Modus
 
Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein:

$ sudo update-alternatives --config java

Es gibt 4 Auswahlmöglichkeiten für die Alternative java (welche /usr/bin/java bereitstellen).

  Auswahl      Pfad                                      Priorität Status
------------------------------------------------------------
  0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      Auto-Modus
  1            /usr/bin/gij-4.4                           1044      manueller Modus
  2            /usr/bin/gij-4.6                           1046      manueller Modus
* 3            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      manueller Modus
  4            /usr/lib/jvm/java-6-sun/jre/bin/java       63        manueller Modus

Drücken Sie die Eingabetaste, um die aktuelle Wahl[*] beizubehalten,
oder geben Sie die Auswahlnummer ein:

Sollte das Sternchen anders gesetzt sein, so wählt man hier im Beispiel die 3 und bestätigt das durch Enter. fertig.

Update: Mittlerweile ist die Version 3.3.4 erschienen.