Alle halbe Jahre wieder das gleiche Problem. Vor ein paar Tagen habe ich mich nach ein paar Monaten wieder von Chakra Linux getrennt und gleich den jungen Koala installiert.

Die Installation verlief reibungslos – bis auf ein nerviges Knacken in den Lautsprechern, dass ich mit Hilfe des Forums von ubuntuusers.de leicht beheben konnte. Der Bootvorgang, aber auch vor allem das Herunterfahren, hat sich im Vergleich zu früheren Version was die Geschwindigkeit angeht extrem verbessert. Dafür muss ich an dieser Stelle Lob an die Entwickler aussprechen.

Allerdings gibts auch Negatives zu berichten. Im Allgemeinen bin ich nicht kleinlich und Programme, die mal auf Englisch sind, stören mich nicht weiter. Wenn mein Rechner mit mir zweisprachig reden will, soll er halt. Vielleicht hänge ich mich an diesem einen Beispiel auch zu sehr auf, aber was ist denn hier wieder schiefgelaufen:

Solches Denglisch finde ich extrem nervig und schlechte Publicity ist es zudem. Sehr wahrscheinlich wurde das sogar mehrmals (Upstream und von den Kubuntu-Übersetzern ) ins Deutsche übersetzt. Warum also funktioniert die Lokalisierung mal wieder nicht ordentlich?

Viele von euch kennen wohl den ‘kostenlosen’ TV-Aufnahme-Dienst OnlineTVRecoder. Damit dieser Dienst zumindest nicht illegal ist, werden die Aufnahmen in einem eignen Format verschlüsselt, um sicherzustellen, dass nur derjenige die Aufnahme dekodieren kann, der sie auch „in Auftrag gegeben hat“.

Der offizielle Linux-Dekoder besteht aus einer Binärdatei, die man über die Konsole bedienen kann, und einem scheinbar auf die Schnelle zusammengewürfelten PyGTK-Frontend. Daneben gibt es diverse inoffizielle Shell-Skripte zum Schneiden und das auf GTK basierende Tool „OTR-Verwaltung“, mit dem man nicht nur Dekodieren, sondern die Dateien auch verwalten kann, Schneiden, cutlists erstellen und hochladen, etc., etc.

Solche mächtigen Tools sind zwar schön und gut, aber lohnen sich für mich nicht wirklich, da ich OTR hauptsächlich für ein paar Serien nutze, die nach dem Anschauen gleich wieder ins Nirvana verschwinden. Bleibt also nur der kleine Linux-Dekoder, um mal schnell eine Aufnahme zu dekodieren. Allerdings stört es mich unter KDE zunehmend. Neben der Tatsache, dass GTK-Programme unter einer KDE-Oberfläche trotz diverser Einstellungen schrecklich aussehen, braucht das Programm doch ziemlich lange, bis es bereit ist.

Lange Rede, kurzer Sinn: Entstanden ist ein kleines Frontend für den Dekoder, geschrieben in C++ und Qt. Gleich vorneweg: Es ist weder offiziell, noch hat es in anderer Weise etwas mit OTR zu tun, außer natürlich, dass es deren Dekoder zum Dekodieren benutzt.

Im Moment handelt es sich noch um keine fertige Version. Es werden zwar alle gängigen Features des Dekoders unterstützt, es könnten aber noch Fehler im Programm schlummern. Auch ist es bisher nur auf Englisch. Der Quelltext steht unter der GPLv3, dass heißt, ihr könnt unter deren Auflagen den Quelltext benutzen, wenn ihr wollt. Wahrscheinlich will das aber keiner

Es gibt keine fertigen Pakete, da ich damit noch kaum Erfahrungen habe und der Dekoder meistens eh irgendwo auf dem Desktop oder im Heimatverzeichnis liegt. Ein Paket wäre daher noch übertriebener Aufwand. Das Kompilieren ist allerdings auch nicht tragisch:

Zunächst muss man, wenn nicht schon getan, die Pakete libqt4-dev und g++ installieren. Vieles davon kann man ggf. nach dem Kompilieren wieder entfernen. Wichtig ist nur, dass man zum Ausführen noch das Paket libqt4-gui installiert hat. Danach in einem Terminal zum Quellen-Ordner wechseln und qmake && make ausführen. Die entstandene Binärdatei „QTRdec“ kopiert man sich in das Verzeichnis des Dekoders und schon kann man frohlockend dekodieren. Nützlich ist es auch sicherlich, die Readme-Datei zu lesen.

Der Quelltext kann hier heruntergeladen werden: http://code.google.com/p/qtrdec/downloads/list

Ich freue mich auf eventuelle Rückmeldungen dazu und hoffe, dass es ein paar Leuten evtl. nutzt.

Lange hat man nichts mehr vom Hoffnungsträger aller Firefox-Nutzer und Qt/KDE-Liebhaber in den Medien gehört, doch scheinbar geht die Entwicklung langsam aber stetig weiter.

Immer mal wieder schaue ich nach, ob aus dem Quelltext eine lauffähige Version herauskommt, und heute ist mein Glückstag, denn diese Revision aus mozilla-central lässt sich tatsächlich durchkompilieren und starten. Leider ist der Feuerfuchs mit Qt-Oberfläche noch überhaupt nicht brauchbar, aber das wird sicher noch. Wer sich selbst ein Kompilat erzeugen will, kann nach dieser Anleitung vorgehen.

Und hier noch einzwei Bildschirmfotos:

Nach Einspielen der Patches gegen den berühmten Harddrive-Killer-Bug ist es sehr ruhig um allerselbigen geworden. Ab und an meldet sich nochmal jemand zu Wort, dass es bei ihm nicht wirkt. Reaktionen darauf gibt es aber kaum. Anfang Januar hatte ich ja über eventuelle Probleme durch die Änderungen der APM-Werte der Festplatten geschrieben – im speziellen bezgl. der Temperatur – dem allerdings auch kaum Beachtung geschenkt, denn da war es ja auch noch kalt.

Die aktuellen Werte lassen mich allerdings aufhorchen:

/dev/sda: TOSHIBA MK1637GSX: 55°C

/dev/sdb: TOSHIBA MK1637GSX: 52°C

Laut dem Datenblatt der Festplatte sollte die Betriebstemperatur 55°C nicht überschreiten. Inwieweit Toshiba da eine Toleranz mit eingerechnet hat, weiß ich nicht und will es auch nicht herausfinden. Testhalber habe ich aber mal bei beiden Festplatten einen APM-Wert von 128 eingestellt und das Resultat nach etwas mehr als 10 Minuten:

/dev/sda: TOSHIBA MK1637GSX: 50°C

/dev/sdb: TOSHIBA MK1637GSX: 48°C

Und nach etwa 30 Minuten:

/dev/sda: TOSHIBA MK1637GSX: 49°C

/dev/sdb: TOSHIBA MK1637GSX: 44°C

Bei der ersten Platte gab es immherin 6°C Abkühlung, bei der zweiten Platte sogar 8°C im quasi Leerlauf. Vielleicht sehe ich die Sache auch zu kritisch, aber bei diesen Werten und ohne die Toleranz zu kennen, bevorzuge ich doch lieber den langsamen Verschleißtod als den plötzlichen Hitzetod.

Wie wohl bekannt ist, nimmt sich Okular zur Darstellung von z.B. PDF-Dateien auch gerne mal etwas mehr Arbeitsspeicher aus dem Topf heraus.

Vor ein paar Tagen durfte ich beobachten, dass es Okular – scheinbar nur bei NVIDIA-Karten – allerdings nicht dabei belässt. So gönnte sich der XOrg-Prozess nach nur 5 Stunden Laufzeit satte 700MB an Arbeitsspeicher, eindeutig zu viel. Es stellte sich dann neben einem Loch in Oxygen, Okular als Übeltäter heraus. Bei einer 200 Seiten starken PDF konnte ich den Speicherverbrauch des XOrg-Prozesses mit jeder Seite im wahrsten Sinne des Wortes hochscrollen.

Der Fehler ist schon länger im KDE Bugtracker gemeldet und in Launchpad erwähnt. Auch wenn es noch keinen Fix gibt, gibt es dennoch Abhilfe: Stellt man das Speichermanagement von Okular von Normal auf Gering, gibt Okular den gebrauchten Speicher nach dem Durchscrollen wieder frei. Das ist zwar CPU-lastiger, dafür schont es den Arbeitsspeicher und lässt den Verbrauch nicht gleich auf mehrere 100MB anwachsen.

KDE wird endlich schön und schnell noch dazu. Mit „Air“ gibt es nun ein wirklich duftes Standard-Thema, dass auch ohne aktiviertes Compositing erstaunlich gut aussieht – keine schwarzen Auffüllungen an den runden Ecken der Fensterdekorationen mehr – keine misslungenen Schatteneffekte durch das fehlende Compositing.

Und angenenehmer Nebeneffekt: Durch das Abschalten des Compositing wird alles nochmal einen großen Tick schneller und reaktionsfreudiger. Einfach schön.

KDE mit Air Theme

Zum Installieren führt man einfach folgende Befehlsfolge aus:

cd ~/.kde/share/apps/desktoptheme/
svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase/runtime/desktoptheme/air

Dazu muss natürlich subversion installiert sein.

Nicht mehr lange, dann endet die Mitzeichnugsfrist für die Petition gegen die Verschleierung von dokumentiertem Kindesmissbrauch und gegen den Aufbau einer Zensurinfrastruktur.

Wer auf Einsicht von Zensursula und Co gehofft hat, wurde bisher beinahe jeden Tag eines Bessern belehrt. Bitte nutzt daher die restliche Zeit und zeichnet mit!

Erzählt auch euren Bekannten, Freunden, Familie, im Verein, am Stammtisch davon und erinnert euch bei der Bundestagswahl daran. Diese maßlose Gier nach Stimmen und Einschränkung der Grundrechte darf nicht einfach folgenlos bleiben.

Und was sagt Speedtest.net über deine Verbindung?

Gestern Abend wollte ich mir die letzte Folge „Neues aus der Anstalt“, die ich verpasst hatte, endlich mal genehmigen. Also geschwind die ZDF Mediathek aufgerufen, die von FlashBlock gesperrte Flash-Navigation, die mir schon bekannt war, aktiviert.

Da ich lange nicht mehr in der Mediathek unterwegs war, forderte mich das System auf Einstellungen, wie zb DSL-Geschwindigkeit, vorzunehmen, die fehlende Befragung nach dem gewünschten Streamformat ließ mich schon stutzig werden. Und der Verdacht bestätigte sich als ich die neueste Folge „Neues aus der Anstalt“ anklickte: Groß blinkte mir das FlashBlock-Symbol entgegen.

Mit dem Fakt, dass man scheinbar auf Flash-Videos umgestellt hatte, konnte ich mich grade so anfreunden. Das Schlimmste an der ganzen Geschichte war allerdings, dass ich das gewünschte Video (und auch jedes andere) nicht anschauen konnte: Stream not found!

Ziemlich enttäuscht hab ich also angefangen etwas in einer bekannten Suchmaschine zu suchen und fand tatsächlich einige verwunderte Foreneinträge zu dem Thema, darunter auch die „Lösung“ des Problems:

Ganz unscheinbar findet sich rechts unten im Mediathek-Fenster ein Link zu einem RSS-Feed (im Bild leider nicht zu sehen). Ob es einen solchen Feed für jeden Beitrag gibt, kann ich nicht sagen, für die oft ausgestrahlten Inhalte aber scheinbar schon. In selbigen RSS-Feeds finden sich Links zu den altbekannten Windows-Media Streams, die man z.B. im VLC anschauen kann.

Das ist zwar auch nicht das Gelbe vom Ei aber immernoch wesentlich besser als Flash-Videos im Browser anschauen zu müssen und nebenbei kann man sich über die neusten Folgen informieren lassen.

Ich bin gegen Netzzensur.

Du auch? Dann mach mit – jede Stimme zählt!

Nach dem schrecklichen Amoklauf in Winnenden hat die Bundesregierung mal wieder die Allheilslösung parat, wie ich soeben im Radio hören durfte.
Geplant ist laut Radio eine Verschärfung des Waffenrechts in folgenden Punkten:

1. Das Schießen mit großkalibrigen Waffen wird nur noch ab 18 erlaubt sein.
2. Die Ämter dürfen in Zukunft auch unangekündigte Kontrollen bei Waffenbesitzern durchführen.

Zu 1.:  Sehr schön durchdacht, Schießen von großkalibrigen Waffen erst ab 18, ab 18 kann ja nichts mehr passieren und kleinkalibrige Waffen schießen nur mit Wattekugeln!

Zu 2.: Wow! Das heißt, bisher hat das Gesetz keine unangemeldeten Kontrollen vorgesehen? Ich besitze selbst keine erlaubnispflichtigen Waffen aber aus Quellen ist mir bekannt, dass nicht mal angemeldete Kontrollen durchgeführt werden, aber eine Verschärfung wirds schon richten! Ach ja und unangemeldete Waffen, die man vom Opa geerbt hat, existieren ja nicht, die brauch man ja nicht kontrollieren.

Alles in allem ist das mal wieder eine Glanzleistung unserer Bundesregierung – Hut ab!

Endlich ist es soweit. Kaum 4 Tage sind seit dem Release von „Jaunty Jackalope“ vergangen, schon ist die nächste Ubuntu-Iteration „Karmic Koala“ für die Entwickler und Tester freigegeben – und das sogar noch früher als geplant, war doch die Vorbereitung der Toolchain für den 30. April angepeilt.

"Cutest Koala" von Erik K Veland, CC-BY-NC-ND 2.0 US

Bisher sind für Karmic nur sehr grobe Stichworte gefallen, etwa soll u.a. Usplash durch Plymouth ersetzt, die Boot-Zeit noch weiter verbessert werden und das schon länger angekündigte neue Aussehen Einzug halten. Details werden natürlich wie immer erst auf dem Developer Summit besprochen, deswegen sollte man sich als Tester derzeit am besten um übrig gebliebene Bugs kümmern.

Gespannt bin ich jedenfalls auf die Fortsetzung/Vervollständigung des Ports für ARM-Netbooks, die Ende diesen Jahres für unter 200 USD auf den Markt kommen sollen.

In diesem Sinne: Go, Karmic, go!

Achja, fast vergessen: Mir hängt es zum Hals raus, es überall zu lesen, aber wie gewohnt ist Karmic nicht für Produktivsysteme geeignet, obgleich selbige die beste Testumgebung darstellen würden. Um bekannte Bugs zu testen, bietet sich daher VirtualBox o.ä. an.

Und nochwas: Ich hoffe doch sehr, dass sich die Entwickler den Namen „Karmic Koala“ zu Herzen nehmen

Durch einen Blogeintrag auf dem Planeten Ubuntu bin ich eben auf eine kleine Leckerei namens Portable Ubuntu gestoßen. Mit Portable Ubuntu ist es, wie der Name schon sagt, möglich, ein virtuelles Ubuntu auf einem Windows Host laufen zu lassen ohne dabei vorher eine Installation, z.B. einer Virtualisierungssoftware, tätigen zu müssen. Sehr nett, wenn man Linux zb auf einem Betriebsnotebook laufen lassen will, auf dem man nichts installieren darf. Ähnlich dem Nahtlos Modus bei Virtualbox integrieren sich die Ubuntu Elemente in die Windows Oberfläche, sodass man on-the-fly zwischen den Systemen wechseln kann. Im Hintergrund läuft dabei Colinux, ein kleines Virtualisierungstool für Windows ohne viel Schnickschnack.

Portable Ubuntu

Der erste Eindruck ist größtenteils positiv. Auf der Projektseite erhält man ein ca. 400Mb selbstentpackendes Archiv, dass nach dem entpacken etwa 2 GB einnimmt. Leider ist die Doku noch nicht sehr ausführlich, was angesichts des noch sehr jungen Alters des Projekts aber nicht weiter schlimm ist, zwei Klicks auf TrayRun.exe starten dann allerdings ein kleines Tray Icon, mit dem man Ubuntu zum Leben erwecken kann. Nach wenigen Sekunden öffnet sich am oberen Bildschirmrand ein Gnome-Panel und man kann loslegen.

Die Integration von Portable Ubuntu beschränkt sich bisher auf den Nathlos Modus und ein paar Kleinigkeiten wie Copy&Paste Interaktion. Ansonsten arbeiten die Systeme scheinbar getrennt. Das virtuelle Ubuntu verfügt über eine Netzwerkanbindung über NAT und bindet das Laufwerk C des Windows-Systems in den Ordner /mnt ein. Inwieweit man Colinux anderweitig konfigurieren kann, muss ich noch ergründen.

Und zum Schluss noch ein kleines Schmankerl: Im Gegensatz zu vieler anderer Software für Windows verlangt Portable Ubuntu keine Administratorrechte und läuft nur mit Benutzerrechten – so zumindest laut dem Autor des Blogeintrages aus dem Ubuntu Planet. Die Angaben des Taskmanagers scheinen das zu bestätigen.

Update 30.03: Nachdem ich nun ein paar Stunden mit Portable Ubuntu gespielt habe, flaut die Begeisterung auch wieder ab. Zwar scheint alles auf den ersten Blick recht flott zu laufen, leider fängt die virtuelle Maschine sobald ich eine PDF öffne gewaltig das Husten an. Das Scrollen geht dann nur sehr zäh und der Seitenaufbau dauert bald 20s. Sehr schade, die nächsten Releases werde ich mich aber wieder anschauen, evtl tut sich ja in der Richtung etwas.

Immer öfter muss ich staunen wie rasend schnell sich Virtualbox die letzten Tage entwickelt hat. So auch gestern als ich nach einer Möglichkeit suchte, ein Virtualbox Fesplatten-Image in das Vmware Format vmdk zu konvertieren, um die Maschine auf meinem Firmennotebook, das netterweise mit Vmware Workstation ausgestattet ist, laufen zu lassen.
Google zeigte da einen ganzen Haufen von Foreneinträgen, desöfteren fiel da das Stichwort qemu. Ich wollte allerdings vermeiden, mir extra qemu für diese simple Aufgabe zu installieren. Ein Blick in das Handbuch von Virtualbox zeigte auf, dass Virtualbox durchaus in der Lage ist, diverse Konvertierungen mittels VBoxManage clonehd durchzuführen.

Leider ist die ganze Sache noch leicht instabil, oder meine Vmware zu neu, denn erst im 2. Anlauf ließ sich das geklonte Image booten. Aufpassen sollte man zudem, verwendet man Virtualbox Snapshots. Virtualbox baut sich die virtuelle Maschine dann nämlich aus differentiellen vdi-Dateien zusammen und clonehd kann damit noch nicht umgehen.

Mehr als zwei Jahre ist es her, da wurde auf Launchpad ein Bugreport mit dem Titel „High frequency of load/unload cycles on some hard disks may shorten lifetime“ eingereicht, der als „Harddrive-Killer-Bug“ bekannt wurde und für einiges an Aufregung und Verwirrung in der Community gesorgt hat.

Nach dieser langen Zeit scheint nun endlich ein brauchbarer Fix in die proposed-Quellen eingeflossen zu sein, der das Problem umgeht, allerdings auch neue Probleme mitbringt.

Was war passiert?
Zum Verringern des Strombedarfs und zum Schutz gegen Stöße werden die Schreibköpfe vor allem bei Notebookfestplatten bei Nichtgebrauch in eine Parkposition gefahren. Dieser Parkvorgang kann nur endliche Male ausgeführt werden, bei älteren Festplatten liegt die Anzahl bei 300.000, bei neueren 600.000 oder mehr. Wie oft das geschieht hängt zum Einen von den Einstellungen des Herstellers und zum Anderen davon ab, ob das Betriebssystem diese Einstellungen verändert. Im Regelfall lässt das Betriebssystem (ganz gleich ob Linux oder Windows) die Einstellungen wie sie sind, da man davon ausgeht, dass die Hersteller am besten wissen, wie oft ihre Festplatten diesen Parkmodus ausführen sollten. Aus welchen Gründen auch immer setzen viele Hersteller die Werte allerdings nicht sehr durchdacht sondern recht radikal und provozieren damit eine sehr hohe Anzahl von Parkvorgängen in kurzer Zeit, was einen schnellen Tod der Platte zur Folge haben kann. Aufmerksam wurde man auf das Problem durch wiederkehrende nervende Klick-Geräusche der Festplatte, die man beseitigen wollte.
Natürlich sollte man hier nicht in Panik geraten. Wirklich betroffen waren vor allem Heavy-User, die ihr Notebook rund um die Uhr laufen ließen, ohne damit zu arbeiten. Wer sein Notebook nur wenige Stunden am Tag an hat, der dürfte kaum von der verkürzten Lebensdauer der Festplatte gestört werden. Nur Zufall, dass gerade viele Linux-User Heavy-User sind

Schnell kursierten diverse temporäre oder permanente Workarounds durchs Netz, die allesamt die ACPI-Einstellungen mittels hdparm änderten. Doch das reine Deaktivieren der Parkmodi war nicht wirklich eine Lösung. Während des Netzbetriebes mag dies eine brauchbare Lösung sein, im Akkubetrieb, in dem das Notebook also höchstwahrscheinlich in irgendeinerweise bewegt wird, könnte diese Einstellung mehr Schaden anrichten als verhindern. Die Debian-Entwickler patchten dann relativ schnell das Paket acpi-support, welches diverse ACPI-Einstellungen tätigt, was man allerdings aufgrund anderer Konfigurationen des Laptop-Modus und des Einsatzes bzw. der Umstellung auf pm-utils nicht ohne Weiteres in Ubuntu übernehmen konnte. Wahrscheinlich spielte auch die stärkere Erwärmung der Festplatte bei ausgeschaltetem APM bei der Entscheidung den Patch einzuspielen eine Rolle. Schließlich wurde das Workaround aus Debian etwas angepasst übernommen, doch funktionierte die Änderung nur bei den wenigsten, da zwar geprüft wurde, ob der Laptop-Modus die APM-Einstellungen der Festplatte übernimmt, aber nicht, ob dieser auch aktiv ist.

Kürzlich erschien nun eine neue Version (Danke an glasen für den Hinweis) von acpi-support in den proposed-Quellen von Intrepid und Hardy, die laut Changelog den Missstand endlich beheben soll. Und tatsächlich werden die angepassten Einstellungen beim Starten des Notebooks übernommen, leider zumindest unter Hardy noch nicht nach dem Aufwachen aus dem Standby. Dies liegt wiederum daran, dass pm-utils für die Kontrolle der Suspend-Modi zuständig ist. Hier muss man bisher noch selbst Hand anlegen.

Und nun?
Weiter oben schrieb ich von Problemen. Nun, ein Grund dafür, dass man die APM-Einstellungen nicht geändert hatte, war, wie erwähnt, dass man den Herstellern in dieser Hinsicht vertraut hat, zumal jedes Laufwerk unterschiedlich auf die neuen Einstellungen reagieren kann. So wurde berichtet, dass einige Laufwerke nach Setzen der neuen APM-Werte ziemlich heiß wurden, und womöglich dauerhaft Schaden hätten erleiden können.  Ich sehe nicht, inwiefern der Patch daran etwas ändert. Eine Gefahr sehe ich allerdings darin, dass der unbedarfte Anwender die neuen Einstellungen unbemerkt installiert bekommt, sollte das Paket in die update-Repos gelangen, und nicht wie bisher die Einstellungen selbst setzen musste. Hier sollte man also sehr vorsichtig sein.

Um fortgesetzt zu werden …

P.S. Wer nach dem Wiki-Artikel Notebook-Festplatten-Bug gearbeitet hat und das neue Paket testen will, sollte natürlich vorher die getätigten Einstellungen rückgängig machen.