Eigene Seiten in Serendipitys Adminbereich
Nachtrag 1: Es ist ein leichtes, eigene Seiten per Plugin zu bauen. Insbesondere im Adminbereich, worum es im Folgenden gehen wird. Eigene Seiten befüllen zu können ermöglicht es, alles mögliche umzusetzen.
Link einsetzen
Zuerst wird der Link gesetzt. Den kann man direkt in das Adminmenü integrieren. Es muss zuerst das Event 'backend_sidebar_entries' registriert werden und dort der Code ausgegeben werden. Hier als Beispiel für dbclean:
case 'backend_sidebar_entries': echo '<li class="serendipitySideBarMenuLink serendipitySideBarMenuEntryLinks"> <a href="?serendipity[adminModule]=event_display&serendipity[adminAction]=dbclean"> ' .PLUGIN_EVENT_DBCLEAN_NAME .' </a> </li>'; return true; break;
Menü anzeigen
Nun wird also im Menü direkt auf dbclean verwiesen. Also muss das Event, ebenfalls vorher registriert, gefangen werden, wenn diese Seite aufgerufen wird:
case 'backend_sidebar_entries_event_display_dbclean': $this->displayMenu(); return true; break;
Das wars schon. Die Funktion displayMenu() kann nun den gesamten Code der Seite ausgeben - mittels eines Plugins wurde der Adminbereich erweitert.
Duke Nukem Forever
Darüber immer noch zu lesen...
Wired veröffentlichte einen Hintergrundartikel zu dem Spiel, das nie erschien (via):
The staff developed a running joke: If a new title comes out, don’t let George see it. When the influential shoot-’em-up Half-Life debuted in 1998, it opened with a famously interactive narrative sequence in which the player begins his workday in a laboratory, overhearing a coworker’s conversation that slowly sets a mood of dread. The day after Broussard played it, an employee told me, the cofounder walked into the office saying, “Oh my God, we have to have that in Duke Nukem Forever.”
Eine ziemliche Horrorvorstellung. Es ist genau die Situation, die man bei Softwareprojekten vermeiden soll. Laut dem Artikel steckte die Entwicklung genau so fest, wie es von außen wahrgenommen wurde. Dann es nicht ändern zu können - diese Außenwahrnehmung muss man doch auch dort wahrgenommen haben - das ist eine der Situationen, in der ich nie sein will.
Betrachtung: Absolute Linux
Ich hatte mich verpflichtet, Absolute Linux 13.0.6 zu testen. Wie mein Fazit lautet? Ich weiß es nicht, was mir auch das Vorwort schwer macht.
Fokus der Distribution ist der Desktop, sie ist angepasst auf die Anforderungen des Entwicklers Paul Sherman. Dabei soll sie leichtgewichtig sein, kontrollierbar und den Nutzer nicht stören. Das Changelog geht bis auf 2006 und Slackware 11 zurück.
Hintergrund: Aktuell und Altmodisch
Absolute Linux ist ein Abkömmling bzw eine Modifikation von Slackware. Sie bringt moderne Software mit: Firefox liegt in Version 3.5.6 vor, OpenOffice in 3.1.1, der Kernel allerdings ist 2.6.29.6 (aktuell: 2.6.32.3). Noch altbackener ist das Root-Prinzip, was absurderweise dazu führt, dass der Entwickler selbst laut Eigenaussage immer den Root-Account nutzt - da ist Ubuntu mit sudo deutlich weiter.
Grundsätzlich bin ich nicht tief genug eingestiegen, um viel zum technischen Hintergrund des Systems sagen zu können.
Oberfläche: So kann IceWM auch sein (?)
Zugegeben, es war ein ausschlaggebender Faktor: Die Oberfläche ist weder Gnome oder KDE noch eine andere Desktopumgebung, sondern der Fenstermanager IceWM ergänzt um ein paar Programme. Das sieht durchaus odentlich aus, mit PcManFM als Dateimanager, dem netten Standarddesign (man vergleiche mit IceWMs gruseligen eigenen Standard), Symbolen auf dem Desktop und automatisch eingebundenen Medien.
Die Konfigurationswerkzeuge einer Desktopumgebung werden durch ein "Control Center" ansatzweise ersetzt, dessen eigentlicher Aufbau auch durchaus gelungen ist.
Der Blick auf die Konfiguration führt zu meinem großen Kritikpunkt: Die Möglichkeiten IceWMs werden nicht genutzt. Nichtmal ein "Senden an Arbeitsfläche x" erscheint in den Fenstermenüs, konsequenterweise auch keine Arbeitsflächenanzeige (gut, die braucht man nicht unbedingt) und auch kein Netzwerk- oder CPU-Monitor. Da ich IceWM auch unter Ubuntu nutze weiß ich, dass hier eine Schmalspurversion dieses Fenstermanagers geboten wird, einfach nur durch die Standardkonfiguration. Wenigstens eine vergleichsweise hübsche.
Das "Control Center" ist nicht nur eine Verlinkung bekannter Programme wie htop. Mit dabei sind auch scheinbar speziell für absolute geschriebene Programme, manche finden sich auch im Hauptmenü. Deren Qualität schwankt: Das addUser-Programm beispielsweise erledigt seine Aufgabe schnell, ist übersichtlich und sieht ordentlich aus. Der "File Finder" dagegen ist optisch fragwürdig, hat eine ungewohnte Anordnung und sucht nicht bei einem Durck auf Enter, wie es aber Standard wäre.
Laut Wikipedia hat Slackware nur wenige grafische Hilfsprogramme, was den Eigenbau erklärt, was ja auch wirklich nicht verwerflich ist, im Gegenteil. Aber da man den Helfern eben doch anmerkt, "selbstgemachte" Programme statt professioneller Software zu sein, wie sie eine Desktopumgebung wie Gnome mitbringt, fühlt sich absolute für mich doch sehr nach "Bastelei" an. Sehr ungewohnt, wenn man Ubuntu gewöhnt ist.
Fazitversuch
Absolute Linux war kein Reinfall. Es ist aber auch nicht so, dass ich den Drang verspüre, von Ubuntu wegzuwechseln, und das obwohl meine Oberfläche bei Ubuntu nur ein unwichtiges Nebenpaket ist und bei absolute die Hauptoberfläche. Die Installation verlief problemlos, die Dokumentation war zutreffend, und es gab keine Probleme. Aber ich gehe nicht konform mit den Änderungen an den Standardeinstellungen von IceWM, sodass der Vorteil seiner standardmäßigen Nutzung sich aufhebt. Wichtiger noch und wohl das eigentliche Fazit: Der Schritt weg von sudo/apt wäre zu groß und das root-Konzept überzeugt mich nicht.
Reisewetter?
Daisy soll mehr Vorteil als Nachteil sein: aufgrund der Warnungen seien die Autobahnen frei, und so schlimm sei der Schnee nicht. Zumindest sieht das mein Fahrer so, wobei die Fahrt hierher die Teststrecke ist und gerade stattfindet. Ich bin mir noch nicht ganz so sicher, ob eine Reise heute eine gute Idee ist.
Wir werden sehen, wie und ob wir ankommen. Wenn wir auch wieder zurückkommen, wird es wohl auch mal Zeit, den ungeplanten Blogurlaub zu beenden.
Bash: Fehlermeldungen ausgeben
Fehlermeldungen aus vorhandenen Programmen umzuleiten geht mit 2>, das findet man auch recht einfach im Netz. Doch wie gibt man so eine Fehlermeldung auf stderr überhaupt aus? Vielleicht ist das zum einen zu einfach und zum anderen etwas, mit dem sich der typische Nutzer nicht herumschlägt. Es geht so:
echo "Errormessage" >&2
bc und Zeilenlänge
Alleine mit der Bash zu rechnen ist wenig erfolgsversprechend, wenn es um große Zahlen geht. Als Alternative bc zu verwenden liegt nahe:
$(echo "2+$phi" | bc -l)
Aber auch hier kann es passieren, dass die Länge zum Problem wird.
onli@Fallout:~$ bc bc 1.06.94 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. ibase=10;obase=2;1356167449339747132412412413 10001100001110010111010000010111101110011010100111000010101001000011\ 01010100100000111111101
Der \ wird auch dann ausgegeben, wenn bc mit einer pipe gefüttert wird, natürlich kann man damit dann nicht mehr rechnen.
Ein
export BC_LINE_LENGTH=0
verhindert dieses Verhalten.
local ist unwichtig
Wer den Fehler entdeckt, wird der Aussage im Titel garantiert zustimmen.
#!/bin/bash getPrim() { local prim=$RANDOM until isPrim $prim;do prim=$RANDOM done echo $prim } isPrim() { local prim=$1 local i=2 while [[ $i -lt $prim ]];do if [ $(($prim % $i)) == 0 ];then notprim=true break fi let i++ done if [ "$notprim" == true ];then return 1 else return 0 fi }