supergarv

Irgendwann diese Woche hat mich Absynth auf den SaaS APS-Service hingewiesen. Dieser Paketstandard ermöglicht es Hostern und damit den Kunden wohl (in der Theorie) relativ einfach, Web-Software zu installieren. Auch von Serendipity gibt es ein derartiges APS-Paket, auch wenn mir unbekannt ist, wer dieses Paket herstellt.

Da das Paket veraltet ist, wollte ich gerne meine Hilfe beim Paket-Maintainer anbieten, Serendipity hier sinnvoll zu unterstützen. Da 1&1 als Deutscher Internet-Dienstleister scheinbar mit federführend bei den Paketen zu sein scheint, und auch Serendipity anbietet, habe ich die Vermutung dass dort vielleicht das APS-Paket erstellt wurde. Daher habe ich eine E-Mail an 1&1 geschrieben. Schon auf der Homepage war es nicht wirklich möglich, eine zuständige Mailadresse dafür zu finden, und ich habe die globale info@einsundeins.de genommen, und dort nett nachgefragt wo man mir denn helfen kann.

Überraschenderweise erhielt ich heute die Antwort:

Sehr geehrter Herr Hiking [sic],

vielen Dank für Ihre Nachricht.

Wir bitten Sie Ihre Anfrage schriftlich einzureichen unter folgender
Adresse: ...

Das kann ja wohl nicht mein Ernst sein. Ein Internet-Dienstleister, bei dem ich meine Anfrage SCHRIFTLICH richten soll? Am liebsten wohl noch mit Einschreibe-Rückbrief und persönlicher Übergabe? Spaß beiseite. Das intern an die richtige Adresse weiterzureichen oder gar die E-Mail im Hause auszudrucken und an einen Postverteiler weiterzugeben kann ja wohl nicht so schwer sein. Ich werde hier nicht anfangen und deshalb zur Post gehen, Porto bezahlen, Briefumschläge kaufen etc. Dann ist die Sache wohl eher an Bürokratie gescheitert.

Etwas ähnliches habe ich als E-Mail Antwort geschrieben, ich vermute allerdings eher, dass sowas nicht auf Gehör stößt. Arbeitet einer meiner Leser bei 1&1 und mag mir beim Vitamin-B-Weg behilflich sein, dass Serendipity-Anliegen auf Gehör zu stoßen?

UPDATE 14:00 Uhr, auf meine Mail antwortete man:

Sehr geehrter Herr Hicking,

vielen Dank für Ihre Nachricht.

Ihr Angebot kann nur intern weitergeleitet werden. Dieses erfolgt am
besten schriftlich.

Wir bitten um Verständnis für unsere Entscheidung.

Also bei mir in der Firma habe ich eine E-Mail-Adresse, so dass ich auch intere Mitteilungen erhalten kann.

UPDATE 18:00 Uhr, jetzt hat sich dann doch der rumänische Produktmanager bei mir gemeldet. Perfekt, und ich danke Kris' und Cruiser's Bitamin-B - was auch immer da jetzt ausschlaggebend war.

Am Wochenende habe ich die Zeit mal genutzt, um ein Kernel-Update des etwas riechenden 2.6.17 auf 2.6.27 zu machen, ausgelöst durch ein udev-Update von Debian Etch.

Das ganze Vorhaben ging eigentlich halbwegs gut: Die alte .config vom alten System in die neu entpackten Kernelsourcen reinkopiert, ein make oldconfig und einige Stunden Konfigurationsoptionen lesen später konnte ich mit make-kpkg buildpackage modules modules_config modules_image --revision 20081019 --verbose das Kompilieren eines .deb-Pakets auslösen.

Das wurde dann per dpkg -i ... installiert, danach noch grub für den neuen Kernel eingerichtet, neugebootet - und die Kernel Panic angestarrt.

Grund dafür war, dass ich beim kompilieren wohl nicht den richtigen HDD-Treiber in den Kernel kompiliert hatte. Also Reboot mit dem alten Kernel (den ich glücklicherweise noch hatte) und nochmal neu kompiliert, diesmal mit allem was mir nach SATA und PIIX aussah. Der Reboot lief etwas besser, diesmal wurde mir gesagt ich müsse einen korrekten boot=-String beim Booten angeben. Mit /dev/sda2 wie vorher klappte es nicht, dmesg sagte mir es stünde nur zur Verfügung. Nun gut, mit boot=/dev/hdb2 klappte dann alles, auch wenn ich dann einige fstab's anpassen durfte.

Später fiel mir dann auf, dass die I/O-Werte des Systems alles andere als rosig waren. Dateien zu kopieren dauerte Ewigkeiten, und ein kurzes Konsulat mit Andy und dem Herrn Linuxtigger war ich aufgeklärt: Da hat sich wohl der alte Generic IDE Treiber das SATA-Interface geschnappt und libata keine Luft zum Atmen gelassen.

Also den Kernel nochmal neu konfiguriert: EIDE-Kram überall raus, und nur das neue SATA-PIIX-Interface (libata) aktiviert, Kernel neu kompiliert, Paket installiert, Kernel-Optionszeile angepasst und rebootet: Et voila, alles war schneller.

Soviel also zu den Dingen, die mich so nebenher beschäftigen.

1. Superschnell.


2. Die Tabverwaltung rockt megamäßig. So ist das viel konsequenter. Me Likey.


3. JavaScript ist zügig, scheint bisher kompatibel zu allen meinen Tests. Auch Rendern der Seiten sieht verhältnismäßig gut aus, wie von Safari gewohnt.


4. Drag and Drop von Tab-Reitern ist spaßig.


5. Das lightweight Interface gefällt mir gut, auch die Farbgebung. Weniger das Taskleisten-Symbol.


6. Derzeit Windows-Only builds verfügbar? Fail.


7. Mir fehlen Optionen in dem Browser, ich will Optionen! Man kann scheinbar noch nichtmal die Rechtschreibkorrektur in Textareas ausschalten.


8. Chrome hat scheinbar dieselbe fehlerhafte Input-Autospeicherung wie Firefox3: In einigen Applikationen werden Felder mit Username/Passwort vorausgefüllt, wo es keinen Sinn macht. Serendipity inklusive.


9. Überall resizable Textareas, das macht Sinn.


10. Die Suchfunktion innerhalb einer Seite ist praktisch. Trotzdem fehlt mir das "Type ahead" von Firefox


11. Firebug und LiveHTTPHeader fehlen mir gewaltig. Ich bin gespannt, was Chrome/WebKit in Sachen Plugins so zulässt.


12. Der Task-Manager ist cool, aber ich hätte mir Speicheraufteilung nach Javascript-Dateien z.B. gewünscht. Auch scheint mir der Memory-Footprint pro Tab eher zu groß zu sein.


13. Schön, dass Ctrl-K und Ctrl-L wie in Firefox funktionieren.


14. Die Popup-Verwaltung pro Tab ist optimal. Auch liebe ich, dass ein amoklaufendes javascript alert() Fenster keine Auswirkungen auf andere Tabs mehr haben sollte. In der jetzigen Beta ist das aber leider dennoch immer der Fall, alerts sind modal.

Hauptsächlich die Textarea-Syntaxhighlighting-Sache macht mich gerade fuchsig und ist der Hauptgrund, warum ich's wohl erstmal nicht produktiv einsetzen werde. Auch die Auto-Completion von Input-Feldern ist fatal.

Naja, erstmal googlen ob man es nicht ausgeschaltet kriegt.

Update: Ich sammle erstmal an Punkten, bevor ich die derzeit schon überlaufene Discussion-Liste noch weiter aufblähe. Größte Kritik: Textarea-Syntaxhighlighting, Falsches Auto-Remember, modale Alerts, fehlendes LiveHTTPHeader.

Heute ist also das großartige neue Ubiquity-Mozilla-Spielzeug released worden.

Die Kernidee davon ist eigentlich schon alt und wurde stellenweise für den Flock-Mozilla-Clon schon umgesetzt. Die Idee ist also nichts neues, und sogar schon Bestandteil urig alter Science-Fiction-Träumereien.

Worum es bei Ubiquity eigentlich geht? Um Vernetzung und "Wunscherkennung". Der Browser soll anhand von natürlicher Sprache in der Lage sein, dass zu tun, was der Computerbenutzer will:

Such mir mal die schnellste Bahnverbindung zwischen Köln und Bonn, aber bitte unter Berücksichtigung der Ferienzeit und der aktuellen Baumaßnahmen.

Das klingt toll, hilfreich und faszinierend zugleich. Flock hat dieses Konzept noch eher ohne "Wunscherkennung" eingeleitet, indem es unterschiedliche Web 2.0 Systeme unter einer Haube vereint und schnellen Zugriff bietet.

Ubiquity treibt's jetzt eine Stufe weiter und fängt mit dem Parsing von natürlicher Sprache an, zumindest in Grundzügen. So kann man Stichwörter miteinander verketten, "this" und markierte Textstellen im Browser referenzieren. Ein Demo-Video zeigt so anschaulich, wie man eine Googlemap in eine Mail einbindet und einen Gedanken schnell zu Twitter schickt.

Meine Gedanken dazu: Schön, aber nicht zu verwirklichen.

Ein großes Problem von Serendipitys Statische Seiten-Plugin war seit jeher, dass die redaktionelle Erstellung einer statischen Seite auf einem doch relativ hässlichen Interface basierte:



Da in letzter Zeit die Stimmen laut danach wurden, dieses Interface etwas zu entstauben, habe ich Anfang der Woche ein paar kleine Bauarbeiten an dem Plugin vorgenommen und bereits ins offizielle Plugin-Archiv (staticpage.zip) überführt.

Technisch sind die Änderungen eher klein und unaufwändig gewesen (2 Stunden Lebenszeit) - aber die Auswirkungen sind enorm:

Als ich vor gut 5 Jahren angefangen habe, Serendipity weiterzuentwickeln, entstand dass hauptsächlich aus dem Wunsch heraus, weil ich meine eigene Blogging- und CMS-Wünsche erfüllt sehen wollte.

Seither war für mich die Weiterentwicklung von Serendipity immer stark auf meine Wünsche abgerichtet, oder auf die der Benutzer dieses Forums. Das hat bisher alles meiner Meinung sehr gut geklappt, die neuen Features der letzten Jahre waren eigentlich immer sehr nah an euch Usern.

Dennoch führt das dazu, dass Serendipity nicht unbedingt eine vorgeschriebene Feature-Agenda hat.

Die Differenzierung zu anderen Blogsystemen ist mir relativ wichtig: Serendipity ist und soll kein WordPress-Klon sein, sondern seine eigene (kleinere) Marktlücke füllen: Ein schlankes Basissystem mit guter Erweiterbarkeit, möglichst sicherer und bugfreier Codebasis und vor allem Worfklows und Benutzungsschemata "nahe am Benutzer". Ein "bottom-up" Entwicklungsprozess ist mir bei Serendipity wichtig, ich möchte als Entwickler keine Features aufdrücken.

Für die nächste Serendipity 1.4 Version fehlen mir noch ein paar sinnvolle Neuerungen, und daher möchte ich bei euch Benutzern anfragen, was die Dinge sind die ihr am meisten vermisst, oder wo ihr den größten Handlungsbedarf seht. Denn daran würde ich dann gerne basteln.

Bitte schreibt mir eure Ideen und Wünsche für die Zukunft von Serendipity. Dieser Eintrag steht auch im offiziellen Serendipity-Forum, und kann dort leicht kommentiert werden.

Seit längerer Zeit habe ich immer mal auf einen günstigen Zeitpunkt gehofft, mir das Buch PHP-Sicherheit zu kaufen. Bisher scheiterte das eigentlich nur immer an meiner aufgestauten Leseliste, an Zeitmangel oder daran, dass eine neue Auflage kurz bevor stand.

Wie es das Glück so wollte, habe ich zur nun erschienenen dritten Auflage ein Rezensionsexemplar erhalten.

Die dritte Auflage des Buches "PHP-Sicherheit" trägt nach wie vor zu Recht einen schlagkräftigen Namen. Allein das Inhaltsverzeichnis liest sich wie eine Offenbarung aller Schlüsselwörter, die man im Zusammenhang mit "Security" jemals gehört haben sollte.

Heute früh habe ich mich gewundert, wo denn meine tägliche Portion Spam bleibt.

Mein privater Linux-Rechner ruft hier brav periodisch die Mails vom Webserver ab, und zwar mittels fetchmail.

Der fing gestern gegen 16 Uhr an, Mails einfach stur abzuweisen:



Erst nach längerer Recherche kam ich darauf, dass mein Exim-MTA folgende Eintragung hatte:



Der ORDB.org-Server meldete jedoch schon seit 2006, dass er nicht mehr benutzt werden will. Das habe ich einfach mal überlesen, und seit gestern wies er die Mails wohl hart ab. Nach Deaktivierung kam dann wieder alles rein, aber die Mails von gestern Nacht sind im Nirvana verpufft.

Die Moral von der Geschicht: Rejection Blacklists ab und zu mal auf Funktionsfähigkeit testen. Mehr Details auf heise, deren Nachricht für mich leider 4 Stunden zu spät kam.

Schon lange kein Web-Entwickler-Content mehr hier, dem kann Abhilfe geschaffen werden.

Ich habe daheim einen kleinen Linux-Server, der mir als Mail+Fileserver, Router und Spielwiese dient. Eigentlich ist es ein Single-User-System, weshalb ich wenig Aufwand dazu betreibe das Permission-System von Linux vollständig aufzudröseln und einzusetzen.

Wie auch immer, dort habe ich gelegentlich Dateien, die ich anderen Personen oder Freunden über FTP bereitstellen möchte. Dafür läuft bei mir ProFTPD, und über angelegte Linux-User kommen die Personen direkt in ihr Homedir. Da die Dateien für sie aber meist tief verschachtelt in meiner eigenen Filesystem-Hierarchie liegen, habe ich bisher immer nur einen symbolische Verzeichnislink im Homedir der User angelegt um auf meine Dateien zu verweisen.

Bis ich heute dann nebenbei bemerkte, dass das bei ProFTPD ein kapitales Problem eröffnet: Die FTP-User kommen auch aus ihrem homedir heraus auf jede andere Hierarchie des Servers. Und da liegt ja dann doch ab und an irgendwas, was man eigentlich nicht anbieten möchte (Geheimdienstakten, Terrorpläne und meine Nacktfotos).

Nachdem ich in der proftpd.conf die Zeile DefaultRoot ~ eingefügt hatte, war die Sache Geschichte. Jeder User kommt aus seinem Homedir nun nicht mehr raus. Aber dafür halt auch nicht in die symlink-Verzeichnisse rein - auch doof.

Ein kurzes Googeln hat mir die Lösung offenbart: Anstelle von Symlinks einfach self-mounts benutzen:

mount --bind /usr/development/downloads /home/guest/download

Somit wird quasi ein auf dem Server existierendes Verzeichnis nochmals im User-Verzeichnis gemounted, und der User kann trotz chroot drauf zugreifen.

Wie man jetzt in meinem Blog auf der linken Seite erkennen kann, ist das von mir geschriebene offzielle Serendipity-Handbuch seit kurzem vorbestellbar.

Rund 700 Seiten liegen dem Verlag derzeit zur Korrektur und Verfeinerung vor, prall gefüllt mit ausführlichen Beschreibungen von allem, was mit Serendipity zu tun hat.

Viel Herzblut und Freizeit ist in das Buch geflossen, und ich hoffe damit sehr, den Nutzern endlich eine vollständige Dokumentation in die Hand geben zu können. Gleichermaßen ist es auch für Neulinge zum System gedacht, da alle Aspekte des Systems beschrieben werden.

Wer jetzt vorbestellt, kann dafür sorgen, dass das Buch etwas zügiger erscheint - und ihr es auch direkt in den Händen halten könnt. Der derzeitige Veröffentlichungstermin ist für Mai 2008 angepeilt. Vorbestellungen werden sowohl über Amazon, OpenSourcePress als auch bei jeder Bücherei angenommen.