Johannes Truschnigg jun.
- Geburtsdatum: 28. 08. 1985
- Herkunft: Bezirk Leoben, Österreich
- Formale Bildung: Matura (Realgymnasium)
- Familienstand: in zarten Händen
- Beschäftigung: Student, Universitätstutor, Systemadministrator
- Nichtraucher: ja
- Grundwehrdienst abgeleistet: ja
- Führerscheininhaber: ja
- Besondere Interessen: Freie Software, GNU/Linux, UNIX-artige Systeme, Skriptprogrammiersprachen, Systemoptimierung
Eintrag von 2008-08-22
▶ Blog-Update: Atom-Feed + Archiv!
Gestern und heute habe ich wieder etwas an meiner selbstgebastelten Blog-Software, die ich einem spontanen Anflug von Kreativität shellblog getauft habe, weitergearbeitet. Die Früchte dieser Arbeit sind bisher:
Ich habe bei der Implementation der neuen Features natürlich auf Standardkonformität und Fehlerfreiheit geachtet, kann aber dennoch nicht definitiv versprechen, dass bereits alles reibungslos arbeitet und funktioniert. Sollten in den nächsten Wochen keine groben Schnitzer ans Licht kommen, werde ich diese momentan zum Einsatz kommende Version gerne auch der Öffentlichkeit zur Verfügung stellen.
direkter Link ▲Eintrag von 2008-08-20
▶ Internetzugang via UMTS - so geht's unter GNU/Linux
Nach meinem mit meiner bezaubernden Freundin auf Kreta verbrachten Sommerurlaub bin ich gestern kurzerhand im Online-Shop von drei einkaufen gegangen: der 3Data-Tarif mit 3GB inkludiertem Transfervolumen pro Monat ist es geworden. Die beigepackte Hardware, ein Huawei E160G (da die USB ID vor dem Kauf trotz intensiver Recherche nirgendwo im Web zu finden war, will ich sie hier für die Ewigkeit festhalten: 12d1:1003 - in /var/lib/misc/usb.ids vom heutigen Tag ist diese ID als Huawei Technologies Co., Ltd. E220 HSDPA Modem / E270 HSDPA/HSUPA Modem gelistet), erwies sich als erstaunlich kooperativ unter Kubuntu 8.04.1 auf tagesaktuellem Patchlevel (Ubuntu Linux Kernel 2.6.24-19-generic): schon kurz nach dem Einstecken waren drei zusätzliche, unterschiedliche Gerätefamilien präsent: ein CD-ROM-Laufwerk (das auf einem im Stick verlöteten Festspeicher die Windows- und OS X-Treibersoftware enthält), ein USB-Mass-Storage-Gerät (das vermutlich den im Stick integrierten miniSD-Slot ansprechbar macht, wenn er denn mit einer Karte bestückt ist), sowie ein emuliertes, althergebrachtes Modem, das als neue serielle Schnittstelle - hier /dev/ttyUSB0 - im System auftaucht.
Die Einwahl in das Providernetz erfolgt, wie Analogmodem-Veteranen kaum überraschen dürfte, mittels pppd. Zur komfortableren Nutzung empfiehlt sich ein Frontend dafür; auf der CLI habe ich wvdial herangezogen, graphisch verwende ich das extra für meine Zwecke erdachte Programm UMTSmon, welches sich mit meinem Modem auf Anhieb prächtig verstand. Sehr angenehm: der Source-Tarball enthält auch gleich eine Binary für x86-Systeme, die auf vielen gängigen Distributionen mit libusb- und Qt3-Support lauffähig ist - so spart man sich oftmals das manuelle Kompilieren des Quellcodes. UMTSmon kann auch einige eher spezielle Mangementfunktionen übernehmen, wie z.B. das Deaktivieren der PIN-Abfrage oder das Verwalten der SMS-Nachrichten auf der SIM-Karte im Modem.
Abschließend kann man guten Gewissens sagen, dass UMTS unter GNU/Linux eine mittlerweile reibungsfreie Angelegenheit ist, an die man sich ohne Furcht heranwagen kann. Ich jedenfalls surfe, administriere und chatte seit gestern ziemlich begeistert von meinem kleinen Datenstick aus in und mit aller Welt - mit Datenraten von bis zu 250KByte/s (downstream) hier im 10. Wiener Gemeindebezirk. Einen kurzen Bericht über die Verbindungsqualität entlang der Südbahn und in ländlicheren Gebieten der Steiermark liefere ich beizeiten noch nach.
direkter Link ▲Eintrag von 2008-07-17
▶ Neue Blogsoftware, in Eigenregie
Ursprünglich hatte ich für mein Blog ja geplant, die von mir sehr gelobte Blog-Software blosxom zu verwenden und ggf. an meine Bedürfnisse anzupassen - nach einigen wenigen Stunden Beschäftigung mit dem Quellcode habe ich es allerdings aufgegeben. Zu unsauber, zu hackish, zu schlecht dokumentiert; schade!
Die für mich relevanten Funktionen von blosxom habe ich kurzerhand gestern Nacht reimplementiert, und die eine oder andere nützliche Erweiterung steht auch schon auf der Todo-Liste. Ich habe dabei auf Rückwärtskompatibilität mit blosxom geachtet, d. h. "alte" Permalink-URIs sollten auch jetzt noch wie gewohnt funktionieren.
Ist dem in manchen Fällen wider Erwarten nicht so, bitte ich darum, mit mir in Kontakt zu treten.
Herzlichen Dank!
Eintrag von 2008-07-15
▶ Kurztipp: Linux SoftRAID Resync beschleunigen
Gerade eben habe ich begonnen, CentOS 5.2 auf einen neuen Server zu installieren, wobei eine RAID1-Konfiguration mithilfe von md, dem RAID-Backend des Linux-Kernels, zum Einsatz kommt. Ein solches RAID-Array wird, je nach RAID-Level, beim Erstellen durch den Treiber synchronisiert - sodass sichergestellt ist, dass alle Volumes genau die Daten enthalten, die sie auch enthalten sollen.
Diesen Vorgang nennt man Resync bzw. Rebuild - und er kann ganz schön lange dauern: das von mir erstellte 950GB-Volume, das eine LVM2-Volume Group aufnehmen sollte, hätte mit der ursprünglichen Resync-Geschwindigkeit von etwa 800kb/s fast eineinhalb Tage gedauert, was mir natürlich inakzeptabel schien.
Nach kurzem Umsehen im unter /sys gemounteten sysfs war auch schnell klar, wo der Hund begraben lag: Die maximale Geschwindigkeit, mit der der Resync stattfinden durfte, war auf 1MByte/s beschränkt. Mit einem Plattensetup, das gut und gerne 110MByte/s sequentiell zu schreiben vermag, ist das natürlich unvernünftig. Mit einem schnellen
# for array in /sys/block/md*/md/sync_speed_max;
> do echo 1000000 > "${array}";
> done
war die Limitation (für alle im System aktiven md-Arrays) aufgehoben, und nach deutlich weniger als drei Stunden konnte man sich über das konsistente Array freuen.
So soll es sein.
Eintrag von 2008-07-04
▶ Kurztipp: IO-Bottlenecks aufspüren mit iotop
Auf modernen Mehrkernsystemen ist es oftmals nicht die Rechenleistung der CPU, sondern das schwächelnde Disk-Subsystem (die Festplatte(n) also), die den täglichen Betrieb eines Computers unter anspruchsvollen Bedingungen zur Diashow verkommen lassen können: trotz DMA und fortschrittlichen Bussystemen kann es nach wie vor zu massiven Latenzen kommen, wenn große Datenmengen auf ein Blockdevice geschrieben, oder von einem solchen gelesen werden müssen.
Dabei ist es nicht immer leicht, empirische Daten darüber zu bekommen, was genau im System denn nun der Übeltäter und Schuldige ist, das die armen Magnetscheiben so schnell rotieren lässt. Während man mit Tools zum Monitoring der Prozessorauslastung meist vertraut ist (top oder das hübschere htop sind hierfür die üblichen Verdächtigen), so ist das Gegenstück für das Storage-Subsystem, iotop, weit weniger geläufig.
iotop stützt sich dabei aufeinige, mit Version 2.6.25 noch als experimentell gekennzeichnete Features des Linux-Kernels: um das entsprechende Kernel-Backend zu schaffen, muss man Linux mit Support für "per-task storage I/O accounting" (TASKSTATS=Y, TASK_XACCT=Y, TASK_IO_ACCOUNTING=y) bauen. Dadurch taucht in den Prozessdatenstrukturen ein neuer Bereich auf, der das Input/Output-Verhalten des Prozesses festhält; einsehbar unter /proc/$PID/io. iotop klingt sich in das netlink-Socket ein, das diese Daten ebenfalls bereitstellt, und gibt diese in top-ähnlicher Manier sortiert und "live" aus. Die Ausgabe darf man sich ungefähr so vorstellen:
PID USER DISK READ DISK WRITE SWAPIN IO COMMAND 2828 colo 0 B/s 38.82 K/s 0.00 % 0.00 % ktorrent 2841 colo 0 B/s 3.88 K/s 0.00 % 0.00 % konversationdirekter Link ▲
Eintrag von 2008-06-23
▶ Kurztipp: Lüfter regeln mit fancontrol
Beim Basteln am HTPC-System meiner Eltern vergangenes Wochenende war ich mit dem Problem konfrontiert, dass der verbaute CPU-Kühler, ein Artic Cooling 64LP, für meinen Geschmack deutlich zu laut drehende Lüfter aufweist. Eigentlich wollte ich das Gerät schon für knapp 25 Euro gegen einen hoffentlich leiseres des Mitbewerbs tauschen, habe aber dann doch evaluiert, ob es nicht auch eine Möglichkeit gibt, den ziemlich primitiven "QFan"-Drehzahlkontrollroutinen des verwendeten ASUS-Mainboards unter die Arme zu greifen. Und ja, tatsächlich:
Das Programmpaket lm_sensors bringt nicht nur die altbekannten Komponenten zum Überwachden der Temperatursensoren im System mit, sondern auch die Fähigkeit, sogenannte PWM-Fans zu regeln. Nachdem das Programm sensors_detect mir die Verwendeung der Module "k8temp" und "it87" nahegelegt hatte, war das Setup-Utility pwmconfig auch schon in der Lage, die Spannung des Hauptlüfters zu regeln, und diesen nahezu lautlos zu schalten.
Das Konfigurationsfile /etc/fancontrol wurde netterweise gleich automagisch durch das oben angeführte Programm generiert, und alsbald ich die für mein Motherboard notwendigen Module zum automatischen Laden während des Systemstarts vermerkt hatte, musste ich nur noch das (bei Gentoo mit lm_sensors ausgelieferte) Initscript /etc/init.d/fancontrol starten (und in die gewuenschten Runlevels eintragen), um den nervigsten Lüfter im System fortan nur noch bei CPU-Temperaturen über 60°C wahrnehmen zu können.
Wer lieber ohne Initscript arbeitet, kann auch einfach via Aufruf des Programms fancontrol das entsprechende Konfigurationsfile nutzen, um die Geräuschkulisse in PC-Nähe nahezu nach Belieben zu gestalten.
direkter Link ▲© 2007-2008 Johannes Truschnigg | Design by Andreas Viklund (modified) | valid xhmtl & css