Die erste Folge des renovierten und frisch umbenannten CRE-Podcasts von Tim Pritlove ist draußen! Darauf habe ich schon ein ganzes Weilchen gewartet, es geht nämlich mit dem Interview los, das Tim mit mir über unsere Arbeit an der Radiosternwarte geführt hat: CRE 186 - Astropeiler

Meine Überarbeitung ist fast abgeschlossen, und seit einigen Wochen läuft http://www.astropeiler.de unter Drupal.  Es fehlen noch einige Kleinigkeiten, und natürlich kann man am Inhalt immer weiter arbeiten, aber an sich ist die Seite und damit meine erste Webseite mit professionellen Anforderungen fertig.

Ich muss aber zugeben, dass ich den anfänglichen Aufwand für die Änderungen unterschätzt habe. Falls jemand mal eine solche mittelgroße Webseite auf ein CMS umziehen will (oder im Rahmen eines Hiwijobs muss), habe ich hier mal Dinge notiert, die ich bei dieser Aktion gelernt habe.

Welches CMS soll ich nehmen?

Diese Frage steht beim Umzug ja ganz am Anfang und frisst gleich nach dem Projektstart viel Zeit. Kaum ein CMS hat eine wirklich ehrliche, umfassende Selbstbewertung auf seiner Webseite, so dass man ums Ausprobieren kaum herumkommt. Eine gewisse Hilfe sind dabei Livedemos, aber Testinstallationen auf dem eigenen Webspace sind unerlässlich.

Mein Fazit zu dieser Frage: Jedes CMS macht irgendwann irgendwie Stress. Es ist deshalb nicht so wichtig, ein CMS zu finden, das "out of the box" optimal für die Aufgabe geeignet ist. Es sollte vielmehr ein großes, schon lange aktives System mit einer soliden Community, die Updates und Sicherheitsüberprüfungen sicherstellt, sein. So ein System hat wahrscheinlich noch einige Jahre vor sich, und bei großen Systemen ist es einfach, Unterstützung und Literatur zu bekommen.

Welcher Hoster?

Für eher kleine Seiten ist ein Hostingvertrag (statt eines eigenen Servers) meistens ausreichend. Ich finde es mittlerweile sehr wichtig, per ssh direkten Zugang auf den Rechner zu bekommen. Daneben sind IMAP-Mailkonten mit ausreichend Speicherplatz sinnvoll, vor allem, wenn mehrere Leute das System nutzen wollen. Viele CMS verlangen derzeit eine PHP-Installation, die nicht im sog. safe mode läuft. Das schränkt den Markt schon recht stark ein -- nach einigem Suchen habe ich mich, wie für meine privaten Seiten, für TMKIS entschieden.

Wer etwas größeres vor hat, findet bei Isotopp einen nützlichen Artikel über die Auslegung von Datenbankservern.

Testseite aufsetzen

Damit man nicht alle Änderungen "live" ausprobieren muss, sollte man eine möglichst identische Seite unter einer anderen URL erstellen, dort experimentieren und die ausgetesteten Änderungen dann auf die "richtige" Seite übertragen.

Layout gut planen

Das Layout sollte man sich (auch wenn das als Aushilfe schwer sein kann) nicht von einem Grafiker vorgeben lassen, sondern von der logischen Seitenstruktur ausgehend ein möglichst "robustes" Layout erstellen. Wichtige Punkte (neben der selbstverständlichen Forderung nach validem HTML und CSS):

• Bei der Änderung von Schriftgrößen sollten Texte nicht ineinanderlaufen.
• Breite Bilder "sprengen" CSS-Boxen. Hier muss man evtl. auf Tabellenlayouts zurückgreifen.
• "Graceful degradation" ist wirklich wichtig. Je nach Art der Seite sollte man auch auf mobilen Browsern und mit Textbrowsern testen.

Es scheint "da draußen" in der kalten, gnadenlosen Arbeitswelt üblich zu sein, sich über die frisch aus der warmen, kuscheligen Uni entsprungenen Informatiker lustig zu machen, "die nicht mal nen Webserver ins Netz hängen können". Die meisten mitlesenden Informatikstudenten werden jetzt denken "...und das ist auch gut so, für solche Sachen gibt's schließlich Fachinformatiker!", ob man das aber später mal seinen Vorgesetzten so einfach vermitteln kann, steht auf einem anderen Blatt.

Bei den Arbeiten an der EDV des Astropeilers "darf" ich gerade, nebenbei und meist auf dem unbequemen Weg, einiges von diesem Administratorenwissen lernen. Die letzten drei interessanten Sachen schreib ich mir lieber mal hier auf, das will ich nicht nochmal per trial and error rausfinden müssen:

• Man kann Standard- und Nonstandard-Patchpanel im Netz mischen. Dabei verwendet man auf beiden Seiten die aufgedruckten Farbreihenfolgen: Auf einer EIA 586A (und nein, dieses ... tolle Schema sieht eben kein paarweises Auflegen vor) und auf der anderen das im Patchpanel aufgedruckte. Den Rest erledigt die Leitungsführung auf den Platinen der Patchpanels.
• Man will Redundanz haben, wenn Rechner ununterbrochen durchlaufen. Bei der Stromversorgung (die unbedingt gegen Über- und Unterspannungen schützen muss und über eine gute USV laufen sollte), bei den Platten und eigentlich auch auf Rechnerebene -- wenn das nicht alles so teuer wäre...
• Wenn's aufs Geld ankommt, geben uralte Systeme der 350 MHz-Generation brauchbare, stromsparende Server ab. Wenn diese Server aber auch noch Plattenplatz brauchen, macht alles, was keine SATAII-Anschlüsse hat, eigentlich keinen Spaß.

Zum Thema Storage habe ich gestern auf Slashdot noch eine interessante Diskussion gefunden. Man stelle sich also hier die üblichen Hinweise ("Slashdot, irgendwelche dahergelaufenen Typen, nicht verlässlich,...") vor und schaue sich dann "Does ZFS obsolete expensive NAS/SANs?" an. Interessante Ideen, die ich für mich mitgenommen habe:

• Für low-budget-Anwendungen, bei denen die Daten nicht unersetzlich sind und die auch mal downtime verkraften, ist ein OpenSolaris-Server mit vielen SATAII-Platten und ZFS vermutlich eine günstige und leistungsstarke Lösung.
• Hardware-RAID ist gar nicht unbedingt so toll: Wenn der Controller kaputtgeht, kann man die Daten mit anderen Controllern nicht wiederherstellen.
• Software-RAID ist gar nicht unbedingt so schlecht: Serverprozessoren sind heute schnell und langweilen sich oft. Außerdem ist es sehr flexibel.
• Mit so was hier bekommt man für wenig Geld, aber mechanisch sauber bis zu 5 Platten in 3 Einbauschächte.

Linkdump: Wie kriegt man eine "richtige" Kamera unter einem Unix dazu, Webcam zu spielen?

• Kleiner, vermutlich etwas veralteter Softwareüberblick: Framegrabbing Applications
• Weimarer Wiki zu Webcams
• Blogbeitrag zu einem Server mit Brooktree-basiertem S-Video Capturing
• Wiki-Seite zu einer steuerbaren Webcam auf einem Unix-Rechner der TFH Berlin
• Zu BT878-basierten Video-Capture-Karten

Bei der EDV im Astropeiler muss gespart werden, denn das Geld ist in der Erhaltung der Technik besser angelegt. Also habe ich in den letzten Tagen einige Experimente mit Linux auf (sehr) schwachen Rechnern gemacht. Der Testrechner ist eine Maschine, wie man sie heute geschenkt bekommt: ein Pentium III 500 MHz mit nur 64 MB RAM, 8 GB Festplatte und einer ATI XPert 98. Für ein aktuelles Linux also ziemlich schwach auf der Brust, dafür braucht er auch nur 50 W unter Vollast.

Es ist sehr einfach, mit Hilfe etwa von IceWM oder auf Basis von DSL eine schlanke und schnelle grafische Oberfläche für einen Linux-Rechner einzurichten. Dabei ist es aber für unerfahrene Nutzer schwierig, etwa mit angeschlossenen USB-Sticks oder Kameras zu arbeiten -- mounten, was ist das?

Heute habe ich deshalb mal versucht, ein aktuelles KDE zu installieren. Dabei bekommt man eine gute Geräteverwaltung mit schönem Frontend und (im Gegensatz zum aktuellen XUbuntu-System) eine komplett eingedeutschte Oberfläche ohne weiteren Aufwand.

KDE

Quelle: Ubuntu Dapper Alternate CD. Im Bootmenü "Einen Server installieren" auswählen, das ergibt ein schlankes, rein textbasiertes Basissystem. Einige wenige überflüssige Pakete (mdadmin, lvm, pcmciautils und so weiter) sind dann zwar dabei, das stört aber (abgesehen von der Startzeit) kaum. Dann:

• kdebase
• xserver-xorg
• xinit
• xfonts-base

Optional noch

• kde-i18n-de

für deutsche Sprachunterstützung. Weil alle mögliche als dependency mit installiert wird, belegt dieses Paket unterm Strich aber 134 MB auf der Platte und dürfte damit für sehr kleine Platten keine Alternative sein.

Für grafischen login: in /etc/inittab die Zeile id:2:initdefault: auf Runlevel 5 umbiegen. Ab sofort startet der Rechner bis in Runlevel 5 und zeigt den kdm an.

Erster Login: in kdepersonalizer (wird i.d.R. automatisch gestartet) visuelle Effekte auf Minimum setzen. Virtuelle Arbeitsflächen könnte man ggf. auch ausmachen und den Pager einsparen. Klipper kann man auch deaktivieren. Ansonsten: Startsound und Anmeldebildschirm aus.

Konqueror und Opera kommen als Browser in Frage. Beide fühlen sich anfangs unglaublich träge an, aber wenn erst mal die richtigen Seiten im Speicher liegen, kann man damit arbeiten. Opera fühlt sich wieder mal etwas schneller als alle anderen an.

XFCE

XFCE (bei Ubuntu vorkonfiguriert als xubuntu-desktop zu habe) wird oft als schlanke GNOME-Alternative bezeichnet. Auf dem Testsystem habe ich es mal installiert, für die geplante Verwendung ist es trotzdem nicht ideal: Die Übersetzung der Oberfläche ist lückenhaft, und gerade bei Ubuntu ist das Paket mit vielen (für diesen Zweck) unnötigen Abhängigkeiten belastet.

Obwohl XFCE messbar weniger Speicher als KDE braucht, fühlt es sich nicht schneller an. Weil einige der am Peiler benötigten Programme sowieso auf KDE aufbauen, habe ich den Ansatz mit XFCE nicht weiter verfolgt.

Ergebnis

Wenn man sogar einen so alten Rechner mit so wenig Speicher dazu bringen kann, KDE auszuführen, werde ich es im Peiler wohl einsetzen. So gut wie alle Rechner, an die man heute so rankommt, dürften leistungsstärker als die Testmaschine sein :-)

Den ersten Tag des neuen Semesters habe ich bei tollem Wetter mit ganz langweiligen Sachen verbracht: Kehren. Schippen. Blätter wegbringen. Und es war richtig entspannend.

An den letzten beiden Märztagen musste eine angefangene Seminararbeit zur Induktionslosen Induktion, einer Methode der automatisierten Programmverifikation, fertig werden. Es wurde gegen Ende des Semesters etwas knapp, und ich habe mal wieder gemerkt, dass ich meine Textproduktionstechnik verbessern muss: Eine Stunde Paper lesen, um daraus dann einen halben Absatz zu basteln, dauert (zu) lang...

Nach zwei Tagen, die ich fast ununterbrochen am Schreibtisch verbracht hatte, wollte ich heute ganz was anderes machen. In der Tradition von Gaius Faulus habe ich mich also am Radioteleskop hingestellt und Wege gefegt... Nicht gerade interessant. Aber bei so einem tollen Wetter auch mal ganz nett.

Am 17. September wurde das ehemalige Radioteleskop auf dem Stockert, einem "besseren Hügel" in der Nähe von Bad Münstereifel, 50. Der betreuende Verein hat deshalb einen Tag der offenen Tür auf die Beine gestellt, zu dem ich mich (mit bedrohlich kreischender Lichtmaschine) dann doch nochmal getraut habe: An solchen Tagen muss ein Auto einfach funktionieren!

Der "Astropeiler", wie das Teleskop in der Umgebung genannt wird, war das Radioteleskop der Uni Bonn und wurde (daher "Peiler") auch von der Bundeswehr für Versuche im Bereich der Radartechnik genutzt. Ich hatte mich seit einem Tipp von einem Amateurfunkhändler letzten Herbst für das Projekt des FAS interessiert, die Anlagen (neben dem 25 m - Teleskop auch noch eine "kleine" 10 m - Anlage) für die Nutzung durch Amateure zugänglich zu machen.

Am Sonntag war das Wetter wieder trüb, aber die faszinierende melancholische Stimmung, die bei meinem letzten Besuch durch den Nebel und die Ruhe auf der Hügelkuppe mitten im Wald unter den großen, stillen Teleskopen herrschte, fehlte diesmal - da störten die vielen Leute und die Blaskapelle doch etwas...

Aber auch diesmal war wieder EME-Betrieb auf 10 GHz, und ich muss sagen, so gefällt mir Contestbetrieb ;-) Es ist einfach beeindruckend, zu hören, wie die eigenen Morsezeichen vom Mond reflektiert werden und als Echo zurückkommen... Und mit den Antennen, die auf dem Stockert vorhanden sind, lassen sich natürlich auch richtig schwache Signale verarbeiten. Leider kann die große "Schüssel" im Moment nicht genutzt werden, aber auch der 10 m - Spiegel liefert tolle Ergebnisse auf diesen hohen Frequenzen.
Abhängig davon, wie es mit den Finanzen für den Verein weitergeht, werde ich nächstes Jahr vielleicht doch noch dazu kommen, an dieser Anlage mitzuarbeiten.