onli blogging

Vor nun fast 2 Wochen habe ich den aktuellen Stand unserer Entwicklungsbemühungen für ein moderneres Serendipity 2.0 vorgestellt. Mir ist es wichtig, dass der Entwicklung möglichst einfach gefolgt werden kann. Die Commitliste ist dafür nur begrenzt geeignet, deswegen werde ich jetzt einfach öfter mal vorstellen, was ich inzwischen getan habe. Immer gilt: Wenig davon ist unumstößlich.

Datumseingabe

Die Datumseingabe im Eintragseditor ist ein Textfeld, das nur funktioniert, weil es vorgefüllt wird. Ansonsten ist es ein normales Textfeld und der Nutzer müsste ein valides Datumsformat erraten. Das Vorfüllen mitsamt dem Button zum Setzen auf die aktuelle Zeit ist eine solide Lösung.

HTML5 bietet eine andere Lösung an: Ein datetime-local Eingabefeld:

Das zu nutzen führt jedoch gleich zu zwei Problemen: Das smartygenerierte Datumsformat zum Vorfüllen des Eingabefeldes muss anders werden, unlesbarer (von YYYY-MM-DD HH:MM zu YYYY-MM-DDTHH:MM) und es wird derzeit von Firefox und mobilen Browsern nicht unterstützt. Für solche Browser wäre das also ein Rückschritt, sie würden das neue Datumsformat in einem normalen Texteingabefeld sehen (alle anderen nicht!). Deswegen brauchte es ein Fallback in der serendipity_editor.js.tpl:

if($entryEditor.size() > 0) {
    $('#serendipityNewTimestamp').val($('#serendipityNewTimestamp').val().replace("T", " "));
}

Durch das Entfernen des T wird das Datumsformat wieder lesbar in Browsern, die datetime-local nicht unterstützen. Bei allen anderen hat der Code keinen Effekt, weil es kein valides Format for datetime-local ist.

Ich hätte lieber ein Polyfill genutzt, aber fand kein funktionierendes - genau genommen fand ich nur ein echtes Polyfill, das jedoch jquery-UI benötigt, und eine JS-Alternative, die jedoch in FF bei mir nicht solide funktioniert.

serendipity_define.js.php

Die serendipity_define.js.php liegt im Hauptverzeichnis und scheint nur eine Funktion zu haben: Die Javascript-Variable xhtml zu setzen. Die Variable wird nicht mehr benötigt und der ganze Mechanismus ist in meinen Augen durch die serendipity_editor.js.tpl, die klarere Strukturierung des Admin-Javascripts und den neuen JS-Hook (siehe unten) gut ersetzt. Sollte ich mich da täuschen, wäre hier und jetzt ein guter Moment mir das mitzuteilen. Fürs Erste habe ich die Datei und ihre Einbindung entfernt.

JS-Hook

Für CSS gibt es einen Plugin-Hook, über den Plugins ihr CSS der vom Kern generierten serendipity.css hinzufügen können. Das macht es für Pluginautoren wesentlich einfacher, CSS-Code auszugeben und führt dazu, dass er weniger häufig einfach stumpf ins HTML geschmissen oder über mehrere Dateien verteilt wird (was zu mehreren GET-Requests beim Seitenaufbau führt). Für Javascript gab es noch keinen solchen Mechanismus, er wäre aber durchaus genauso nützlich. Deswegen habe ich einen Hook namens js zum Kern hinzugefügt, der eine serendipity.js mit dem gesammelten Code aller ihn nutzenden Plugins erzeugt. Ich denke, es wäre auch überlegenswert, den Code des Adminbackends darin zu bündeln. Eventuell fehlt hier noch Logik, um parallel zum CSS eine serendipity_admin.js mit nur dem Code das Backends zu erzeugen, das würde ich hinzufügen wenn es sich als nötig erweisen sollte.

Layout.php Überbleibsel und API-Stabilität

Vor meiner Zeit mit s9y gab es eine layout.php, die wohl statt der Smarty-Templates zur HTML-Codegenerierung genutzt wurde. Es gibt immer noch ein Template im Kern, das eine solche nutzt, das Template newspaper. Die Überbleibsel im Kern zur Unterstützung dieser layout.php habe ich nun entfernt - ich glaube nichtmal, dass diese Methode noch einwandfrei funktionierte, aber selbst wenn ist das einer der alten Zöpfe, die ich für eine bessere Wartbarkeit des aktuellen Kerns gerne los wäre.

In diesem Zusammenhang habe ich die Parameter der generate_plugins-Funktion verändert, nämlich den zweiten Parameter $tag entfernt, der keinen Effekt mehr hatte. Das führt dazu, dass fast alle Aufrufe dieser Methode (zwei im Kern) verändert werden müssen, weil sich ja die Reihenfolge der Parameter danach ändert (PHP kennt nativ keine named parameter). Dagegen hat Garvin zurecht protestiert, und ich habe (in meinen Augen ebenso zurecht) für diese Änderung argumentiert. Das ist kein Streit, sondern eine berechtigte Diskussion um die Frage, ob solche Änderungen im Kern für Nutzer, die ggf gegen den Kern ihre eigene PHP-Seite geschrieben haben, zumutbar und ob sie nötig sind. Ich würde das immer noch bejahen, was aber nicht heißt, dass ich Garvin überzeugt habe. Aber wenn mir jemand mitteilen will, wieviel Mehrarbeit eine solche Änderung für ihn bedeuten würde - ich will sowas noch bei ein paar Funktionen machen - wäre wieder hier und jetzt ein guter Moment.

Das absurde am NSA-Abhörskandal ist, dass nichts davon neu ist. Wir wussten schon lange, dass die NSA allen Internettraffic versucht abzuhören, dass sie Zugriff auf die Server von Facebook und Google haben, dass keiner der US-Dienste sicher ist. Und auch, dass deutsche Firmen keine echte Alternative sind - wenn die USA an Daten will, dann kriegt sie die.

Aber es zu wissen und es wirklich zu wissen ist noch einmal ein Unterschied. Wenn offen darüber geschrieben wird, wenn Deutsche an der Grenze ganz offiziell wegen privaten Facebooknachrichten abgewiesen werden, ist eine neue Stufe erreicht.

Ich hatte vor kurzem schonmal die Erkenntnis, dass meine Daten auf Googles Servern nicht sicher sind, auch wenn es da um den sicheren Fortbestand der Daten ging, nicht ums Ausspionieren. Tatsächlich dachte ich irgendwo schon, dass ein mächtiger Konzern wie Google es verhindern könnte, und mit seiner Hackervergangenheit auch wollen würde, den amerikanischen Geheimdiensten direkten Zugriff auf ihre Server zu geben. Zumindest, solange kein Verdacht besteht, ich oder jemand in meinem Umkreis würde gegen die USA Waffen erheben wollen. Letzter Glaube an das Funktionieren des Systems.

Natürlich sind es nicht nur die Server. Was unverschlüsselt durch die Leitung geht ist öffentlich, dass predigen ja nicht nur SSL-Verfechter seit Jahren. Berichte, welche Probleme die NSA damit hat, all den aufgezeichneten Internettraffic auszuwerten, standen schon vor Jahren in so untergründigen Magazinen wie dem Spiegel. Inklusive Details wie den verschiedenen Datenspeicherarten, dem hierarchischen System von Daten mit direktem Zugriff (=Festplatten) und Daten für später (=Bandlaufwerke und Zeug) und den daraus folgenden Analyseproblemen.

Selbst zu hosten und zu verschlüsseln scheint der einzige Weg, eine halbwegs sichere Existenz aufzubauen - und nein, nicht Internet-Existenz, die Auswirkungen reichen weiter. Ich überlege nur, wie weit man gehen muss. Mail als Beispiel, denn Mail ist für mich der Kernpunkt der Internetexistenz: Ein Mailhosting bei einem anderen deutschen Anbieter ist doch genauso unsicher. Wenn zu PRISM Beteuerungen kommen, dass es keinesfalls gegen US-Bürger gerichtet ist, nur gegen alle anderen, ist doch der logische nächste Schritt, dass nicht nur die US-Gigantenfirmen Ziel der Datensammlung sind, sondern gerade ausländische Hosterfirmen das Primärziel amerikanischer Hackingattacken sein dürften.

Nein, was man absichern kann, muss abgesichert werden. Das braucht eine gewisse Infrastruktur. Dazu gehört die eigene Mailadresse (malte@paskuda.biz). Dazu gehört auch die Software, um Mail von einem beliebigen Mailserver abzuholen (Roundcube derzeit, obwohl das mit gmail nicht in akzeptabler Geschwindigkeit funktioniert. Eventuell muss ich da schon wegen PGP und sicherem Datentransport zu meinem Computer doch zu Thunderbird zurück - kennt jemand gute Alternativen?). Doch der Kern davon muss der auf einem verschlüsselten Heimserver laufende Mailserver sein. Die Hardware dafür hätte ich mit dem Pogo, was fehlt ist die statische IP. Was meine Kommunikationskosten durchaus erheblich erhöhen dürfte.

Gehen wir weiter. Instant-Messaging betrachte ich als gelöstes Problem, der Jabber-Account existiert und das OTR-Plugin in Pidgin ist aktiviert.

Der Blog hier läuft auf seinem eigenen Server, das ist schonmal ein Schritt besser als ein Bloganbieter wie Wordpress.com. Nächster Schritt wäre das Ausliefern über https.

Mailhosting ist nur der eine Angriffspunkt,der andere ist die Mailübermittlung selbst, die muss verschlüsselt werden. Also muss der PGP/GPG-Key erstellt und verteilt werden.

Und dann ist da noch das Handy. Völlig klar, dass dies ein Angriffspunkt ist, Stallman predigt das seit Jahren. Wie ich damit umgehen soll weiß ich noch nicht. Festnetztelefon? Als ob das nicht abgehört werden würde. Vielleicht eine per Telefonnummer erreichbare Skype-Alternative.

Generell wird es wohl Zeit, sich mit den Crypto-Anarchisten mal näher zu befassen.

Für Serendipity 2.0 wurde einiges geplant. Was ist der aktuelle Stand?

Zusammenfassend: Das HTML im Backend ist modernisiert, das Javascript ist zu jQuery portiert und dabei aufgeräumt worden, und es gibt ein neues Admin-Design.

Vorab: Alles, was ich im Folgenden zeige, ist vorläufig. Nicht alles ist abgesprochen mit den anderen, nicht alles wird so kommen, viel kann noch dazukommen. Sowohl funktional als auch auf Designseite.

Das Adminbackend ist von Ian und mir smartifiziert worden. Vorher war das HTML und Javascript in den PHP-Dateien enthalten und wurde von dort ausgegeben, wenn eine Seite aufgerufen wurde. Jetzt macht das PHP seine Aufgabe und stellt die Daten den Smarty-Templates zur Verfügung, die sich dann um die Präsentation kümmern. Wir haben sogar einen neuen Mechanismus, um Javascript-Dateien des Designs per Smarty generieren zu lassen, um dort ebenfalls direkt auf die Daten des PHP zugreifen zu können.

Das heißt: Während in 1.7 das Adminbackend aus den PHP-Dateien in include/admin/ generiert wurde, war der Frontend-Part zwischenzeitlich in include/admin/tpl/ und ist jetzt in templates/templatename/admin/.

Das alles erleichtert uns die Aufgabe, das Admin-Backend zu modernisieren - HTML5, jQuery und allgemeine Verbesserungen. Das wird im Rahmen des hervorragenden 2k11-Designs von Yellowled gebündelt, der auf der Designseite auch im Backend den Großteil der Arbeit gemacht hat. Dieses 2k11-Design soll bulletproof als Default-Design ersetzen und ist auch schon als solches gesetzt.

Die genutzten Smarty-Templates sind jetzt Teil des Designs, nicht mehr Teil des Kerns. Das ermöglicht es theoretisch, sehr unterschiedliche Adminbackends zu designen. Aber auch der Installer gibt jetzt sein HTML per Smarty-Template des Designs aus (wodurch die serendipity_admin.php um 200 Zeilen schrumpfen konnte).

Von den Code-Änderungen sieht man als Nutzer natürlich wenig, sie führen vor allem zu besser wartbaren Code. Aber was man durchaus wahrnimmt ist das 2k11-Adminbackend:

Ich fand es beeindruckend, wie deutlich anders das Backend alleine durch die Verbesserungen beim HTML und die andere Farbgebung wirkt. Mir gefiel der Effekt sehr gut.

Ansonsten ist es bisher größtenteils das alte Backend. Wir kommen jetzt erst an den Punkt, an dem wir grundlegendere Änderungen ausprobieren können, wie beispielsweise eine andere Navigationsstruktur. Ein paar Änderungen boten sich direkt an. So wurden die Einstellungen des Designs auf eine eigene Seite verfrachtet:

Und in der Mediendatenbank gibt es eine Reihe von Änderungen, wie ein Anzeigen der Informationen per Overlay und Buttons zum Filtern nach Dateityp:

Generell wurden die Filter versteckt, auch in der Eintragsliste:

Soviel zum Backend.

Ein Serendipity 2.0 könnte auch Änderungen auf anderer Ebene bringen, inklusive neuer Funktionen. Gleichzeitig soll natürlich nicht alles umgeschmissen werden und als altes System ist der Großteil dessen, was man sich vorstellen kann, schon umgesetzt. Ich werde mich aber sicher noch am Caching probieren und ein Autospeichern des Editors per localStorage implementieren. Was sich noch ändern wird ist die Auswahl mitglieferter Plugins, beispielweise ist der Kalender inzwischen ein Relikt einer vergangenen Blogzeit. Aber in der Richtung ist noch nichts großes passiert, daher kann ich da auch nichts zeigen.

Yellowled wollte den aktuellen Stand auch vorstellen - er kann sicher viel mehr zu den Details des Admindesign sagen als ich - das würde ich dann hier verlinken.

Marks Shuttleworth hat den Bug #1 geschlossen. Bug #1 war eine grobe Zielsetzung des Ubuntu-Projektes, die Erklärung des Ziels, Microsofts Monopol als vorinstalliertes Betriebssystem auf Computern zu brechen.

Marks Kommentar zu der Schließung ist beachtlich, weil das Problem nicht wirklich gelöst ist. Es sei eine Lösung durch eine Verschiebung der Marktsituation entstanden. Er verweist auf die Marktsituation unter Einbeziehung von Smartphones und Tablets, dernach Microsoft kein Monopol mehr hat, nichtmal die Mehrheit der Geräte kontrolliert.

In meinen Augen ist das eine unangemessene Verschiebung des Schlachtfeldes, ohne dass der Kampf gewonnen wäre. Geht man heute in einen Elektroladen, sei es Media-Markt oder ein kleinerer, ist immer noch auf der Mehrzahl der Geräte Windows vorinstalliert. Gibt es überhaupt eine Alternative, sind es die genauso proprietären Apple-Produkte. Der einzige Lichtblick ist Android auf Tablets und Smartphones, die aber immer noch mit geschlossener Firmware und Treibern gekoppelt sind und die sich nicht eignen dafür, das Wissen der Menschheit oder auch nur normalen Code zu produzieren. Es sind fast reine Unterhaltungsgeräte - dort Android zu haben ist toll, aber es genügt nicht.

Auf den Servern sieht es besser aus, aber die waren nie Teil des Ziels, denn schon zu Beginn des Ubuntu-Projekts war Linux dort am Gewinnen.

Was mir nicht gefällt ist nicht nur, dass das eigentliche Problem nicht gelöst wurde. Es ist das Marketingsprech, das Shuttleworth benutzt:

For Ubuntu, our goal remains to deliver fantastic experiences: for developers, for people building out production infrastructure, and for end-users on a range of devices.

Dieses "Wir liefern Erfahrungen" ist Unsinn. Software kann das nicht. Erfahrungen machen Menschen mit Dingen, auch mit Software, aber Software ist immer nur das Werkzeug dafür. So sprechen Marketingleute, die ihre Produkte aufwerten wollen, die dann eben nicht nur eine Aufgabe toll erledigen würden, sondern zusätzlich "Great Experiences" böten.

Das gekoppelt mit dem eigentlichen Problem irttiert mich sehr. Der Sieg wäre es gewesen, wenn Dell großen Erfolg mit seiner Ubuntu-Reihe gehabt hätte. Wenn in vielen Ländern Linux, und sei es Ubuntu, in den Computern der Elektroläden vorinstalliert wäre. Wenn Spiele standardmäßig für Linux erscheinen. All das ist noch nicht erreicht und wäre immer noch relevant, egal wie viele Smartphonenutzer herumlaufen.

Tatsächlich sind wir auf dem Weg zur Erfüllung des Ziels, und Ubuntu leistet einen großen Beitrag. Aber jetzt dieses erklärte Ziel aufzugeben passt zu gut in die Wandlung des Ubuntu-Projekts weg von einem Community-gestützten Betriebssystem für PCs, in Braun, mit Trommelstartupsound und sympathisch-bescheuerten Namen wie Dapper Drake, hin zu einem glattgeschliffenem lila Apple-kopierenden Unity-Ubuntu, dessen erklärtes Ziel nicht der Sieg freier Software, sondern der Aufbau einer profitablen eigenen Nische ist.

Ubuntu ist pragmatisch geworden, und dazu passen keine großen Ziele.

Ich muss etwas weiter ausholen.

Der heilige Gral des Webentwicklers ist das "passive income"-Projekt. Irgendwie eine Webseite bauen, die es schafft, ohne große weitere Pflege Einnahmen zu generieren, wie auch immer. Dafür gibt es eine Reihe von Ansätzen, manche sind schöner als andere. Mein Hardwareempfehler war von Anfang an immer auch halb so ein Projekt - klar, mir ging es auch darum, das bauen zu können und zu testen wie, aber schlussendlich war das Ziel, die Seite in einen Zustand zu bringen, in dem man mit ihr zumindest ein bisschen was verdienen könnte. Die Beispiellinks unten fand ich dafür ziemlich perfekt, weil sie tatsächlich ein Feature sind, das ich einfach so haben wollte, und mir dann später klar wurde, dass man da Referral-Links draus machen könnte. Und auch, weil sie in einem Tool funktionieren könnten, das nicht weiter erweitert wird, sondern sich auf Cpu und Gpu beschränkt, nachdem ich an der Integration von Mainboards gescheitert bin.

Funktioniert hat das bisher nicht. Und mir ist nicht ganz klar, woran genau das liegt. Vielleicht ist die Idee doch nicht so gut. Oder natürlich die Ausführung - das aber kann viel bedeuten. Ist das Design zu abschreckend, oder funktioniert die Seite schlicht auf zu vielen Browsern nicht, oder übersehe ich defekte Funktionen? Oder - die für mich irgendwo angenehmste Möglichkeit, aber auch am schwierigsten zu behebende Situation - ist die Seite schlicht zu unbekannt, und wird nicht von denen gefunden, die sie brauchen würden?

Man müsste das eigentlich Schritt für Schritt angehen. Ordentlich durchtesten, ob die Seite überhaupt für Menschen funktioniert, die sie nicht gebaut haben, wäre der erste Schritt. Dazu gehört, welchen Eindruck sie auf Besucher macht.

Das wollte ich durch Criticue erreichen. Man stellt seine Seite ein, bewertet und kritisiert andere Seiten, wobei man ein Bild von ihnen sieht und sie zusätzlich auch direkt aufrufen kann, und kriegt im Gegenzug ebenfalls Rückmeldung. Bin ich bei Hackernews drüber gestolpert, weil ich wohl gerade so etwas suchte, fiel es mir auf.

Direkt getestet, die Seite reingestellt, Bewertungen abgegeben, Rückmeldungen abgewartet…und sie fielen nicht gut aus. Aber mit einer blöden Mischung. Denn zum einen waren die Bewertungen des Designs sehr negativ, was ich erstmal schlucken musste, zum anderen war die Qualität der Bewertungen aber auch größtenteils schlecht. Was soll ich mit der fünften Erkenntnis anfangen, dass die Seite nunmal nicht in deutsch ist? Ist das ein Grund, alles andere zu ignorieren? Und ja, das ist schlicht, das festzustellen alleine hilft mir genau wie?

Ich bekam so nur vermittelt, dass die Seite in den Augen mancher der Kritiksuchenden dort scheiße ist, aber nicht, wie man sie verbessern könnte.

Natürlich stimmt das so nicht ganz. Es war auch hilfreiche Rückmeldung dabei. Und wenn ich mir alte Versionen der Seite angucke, war die auch nochmal weniger hübsch als jetzt (derzeit gefällt sie mir persönlich gut, vll zu gut, ich bin natürlich total voreingenommen), sodass ein "Sieht nicht gut aus" seine Berechtigung hatte und grundlegendes Kapitulieren vor der Seite ja auch eine starke Rückmeldung ist, die mich daher zu Änderungen brachte. Auf die Idee mit den Pfeilen kam ich erst danach, das schränkte ihren Nutzen zudem ein. Trotzdem: Der rare wirklich gute Hinweis wie "Der Graph zeigt zwar Zahlen, aber keine Legende, so wird absolut nicht klar was das ist", woraufhin ich ihn komplett umbaute und per Overlay erklärte, war die Ausnahme.

Jetzt ist aber auch Criticue das Projekt von jemanden, der in Mails sogar ganz vernünftig wirkte, und entwickelt sich weiter. Der Flow beim Bewerten ist viel besser als am Anfang, das Design etwas angepasst, Bewertungen können erkauft statt ertauscht werden (->"passive" income), aber das wichtigste: Man kann den Testern eine Botschaft mit auf den Weg geben. Die Funktion hab ich erst ignoriert, bis mir klar wurde, dass sie helfen könnte. Bei mir lautet die Botschaft jetzt so:

Ignore that it is in german please. I am looking for specific hints to improve the design. Also, please visit the page, there are interactive elements.

Und schwupps, die erste Bewertung danach:

1. You need a proper logo. Really! Logos come cheap this way and you can have a really decent one in $30-$60 range. 2. Use web fonts (e.g. Google WebFonts or typekit.com). 3. "Beispiel" content inside the frames is not aligned right. Work on that.

Und hey, das ist gut. Ich weiß zwar nicht, ob ich ein Logo kaufen will, aber ich verstehe, dass es sinnvoll sein könnte. Ich nutze zwar bereits eine Web Font (Lato), aber ich sehe das als Vorschlag, zumindest stellenweise eine etwas ausgeprägtere Schriftart zu benutzen. Kann man drüber nachdenken. Und dass der Inhalt der Beispielboxen nicht ordentlich ausgerichtet ist, ist mir noch gar nicht aufgefallen. Bin zwar nicht sicher, ob es technisch stimmt, aber ich sehe, wie man drauf kommen könnte.

Hilfreiches Feedback, konkret, so wie ich mir das vorgestellt habe. Solches, wie ich es bei den anderen Seiten immer auch ohne Hinweis versuchte zu geben.

Um den Bogen zurück zu schlagen: Ob Erfolg oder nicht, das schöne an so Projekten ist, dass man in jedem Fall Zeug lernt. Und manchmal sind das eben so triviale Dinge wie "Geb deinen Testern ein paar Worte mit auf den Weg".

E4rat beschleunigt zwar das Booten ein bisschen, verhindert aber, dass plymouth dabei seine Grafiken zeigt. Das hat mich zuerst nicht gestört, da plymouth aus irgendwelchen Gründen schon vorher auf das hässliche Standard-Logo zurückgefallen war, aber ist ja kein Dauerzustand. Um plymouth zu reparieren, muss die Option plymouth:force-splash zu den Kernel-Optionen hinzugefügt werden.

Also /etc/default/grub editieren, GRUB_CMDLINE_LINUX_DEFAULT um plymouth:force-splash ergänzen und dann sudo update-grub ausführen. Beim nächsten Reboot läuft plymouth wieder. (via)

Ubuntu Brainstorm war im Kerngedanke ein großartiges Projekt. Die Ideen all der Nutzer anzuzapfen, die täglich Ubuntu benutzen, und durch ein Wahlsystem die Ideen gefiltert an die Entwickler weiterzugeben, ist Participatory Design in Reinform. Es ist aber auch die kleine Form des PD, bei dem die Nutzer als Experten ihrer spezifischen Softwarenutzung gesehen werden, aber abgesehen von diesem ersten Input nicht weiter an der Ausgestaltung ihrer Idee beteiligt sind.

Ubuntu Brainstorm war eine faire Abmachung: Ihr Nutzer gebt uns Entwickler Ideen, und dafür kreisen wir Entwickler ab und an über diese Ideensammlung und implementieren manche der Ideen.

Jono Bacon tut nun so, als sei das untypisch für Open Source. Das funktionierende Modell sei, dass der Nutzer möglichst weit beteiligt ist, am besten selbst Mockups und Patches bereitstellt und so die Integration seiner Idee vorantreibt. In dem Artikel zur Brainstorm-Abschaltung schreibt Bacon auch klar, dass das alternative Modell bei Ubuntu nicht funktionierte. Die Ideen wurden von den Entwicklern ignoriert, und weil die Existenz des Brainstorms die soziale Erwartung hervorgerufen habe, dass die Ideen auch umgesetzt würden (wie überraschend), sei das für die Nutzer frustrierend und insgesamt schädlich gewesen. Er schreibt das so:

Some time ago the Technical Board took a work item to try to solve this problem by regularly curating the most popular items in brainstorm with a commentary around technical feasibility, but the members of the TB unfortunately didn’t have time to fulfill this. As such, brainstorm turned into a big list of random ideas, ranging from the sublime to the ridiculous, and largely ignored by the Ubuntu development process.

...

In other words, just because an idea is popular doesn’t necessarily mean it is interesting enough for a developer to want to implement it. Secondly, brainstorm started to garner an unrealistic social expectation that popular ideas would be automatically added to the TODO list of prominent Ubuntu developers, which was never the case.

Das dürfte auch stimmen, seine Schilderung unterschlägt allerdings, dass das Brainstorm-Tool genau für diese nun als unrealistisch bezeichnete Erwartung da war und genau so angekündigt wurde: Als Möglichkeit normaler Nutzer, ihre Ideen einzubringen, über sie abstimmen zu lassen und gute und machbare Ideen von Entwicklern umsetzen zu lassen. So stand das damals beispielsweise in der Ankündigung:

The development team can now take the pulse on the most pressing user issues and propose the ideas as topics at the Ubuntu Development Summits and ultimately as specifications. Ubuntu development is in turn driven by detailed specifications written up in the wiki and tracked as blueprints in Launchpad

Es ist kein Wunder, dass die Nutzung des Tools zurückging, wenn Ideen von den Entwicklern eben nicht aufgegriffen wurden.

Es gibt natürlich Projekte, die nach Bacons vermeintlichem Ideal funktionieren, und es gibt einige wenige Nutzer, die sich tatsächlich so einbringen können. Doch im Großen ist das illusorisch und absurd. Ein Nutzer mit einer guten Ideen muss in einem in meinen Augen idealen Projekt nicht wissen, wie sie umsetzbar ist, er muss ganz sicher keine Mockups designen, er muss nur einen Entwickler finden, der in der Idee Potential sieht und sie für umsetzbar hält. Und bereit ist, das dafür notwendige zu tun. Und genau für diesen ersten Schritt des Nutzers versprach Ubuntu Brainstorm Hilfe - das gleichzeitig auch noch mit verschiedenen Mitteln dabei helfen sollte, Ideen der Nutzer zu strukturieren und sie in eine spezifikationsähnliche Form zu bringen.

Es ist nun nicht so, dass es keine Projekte gibt, die tatsächlich so nutzergetrieben funktionieren. Serendipity z.B. wird seit Jahren so weiterentwickelt. Das Spamblock-Bayes-Plugin kam genau so zustande: Ein Nutzer schlug die Idee vor, kleinerChemiker baute ein entsprechendes Plugin, ich brachte es zum Laufen, vervollständigte es und pflege es seitdem gelegentlich. Und Serendipity ist keine Ausnahme mit diesem Entwicklungsmodell (bei dem natürlich auch die Entwickler eigene Ideen einbringen und eine Beziehung zu der Idee haben müssen), ich sehe so etwas immer wieder. Es ist ab einem gewissen Entwicklungsstadium meinem Eindruck nach eher die Norm als die Ausnahme, dass neue Features aus Nutzerideen entstehen.

Natürlich steht ein solches PD-Tool auch in einem größeren Zusammenhang: In einem Projekt, das ganz bewusst eben nicht PD betreibt, sondern im Großen nur die Ideen der Entwicklung und Projektleitung umsetzt, hat ein solches Tool keinen Wert. Ich sage das ohne Wertung, es geht nicht darum, was Unity, Mir oder Ubuntu Phone taugen. Es geht darum, dass diese Entwicklung des Ubuntu-Projekts nicht aus der Nutzerschaft kam, sondern von oben - und ohne jegliche Einflussmöglichkeit, sogar mit explizit geäußerter Nicht-Beeinflussbarkeit - festgelegt wurde.

Es ist also völlig richtig von Ubuntu, Brainstorm abzuschalten. Es ist etwas schade für mich, weil ich immer mal wieder darauf als Beispiel für PD verwies. Aber es ist für die Nutzer gut, wenn sie nicht länger getäuscht werden, sondern klar ist: Einfach eine gute Idee an die Entwickler weiterzugeben reicht nicht, um sie umsetzen zu lassen, muss vom Nutzer schon mehr kommen. Es heißt auch: Ubuntu hat keine Entwickler, die immer wieder auf den Brainstorm schauen und daraus Ideen umsetzen. Weder gibt es dafür Freiwillige, noch will Canoncial jemanden dafür bezahlen. Diese Art der Nutzerbeteiligung, diese Form von Participatory Design, wird nicht umgesetzt. Die Abmachung gilt nicht mehr.

Diesen Umstand muss man nicht gut finden.

Hackernews ist eine meiner Haupt-Nachrichtenquellen, aber die Seite an sich ist weder hübsch noch funktionsreich. Und auch wenn eine Beschränkung auf Kernfunktionen sinnvoll sein kann, gibt es eine Reihe von fehlenden Funktionen, die ich zu den notwendigen dazuzähle. Die von mir genutzten Erweiterungen:

Alternatives Design

Dieses Design habe ich schonmal vorgestellt. Inzwischen hab ich es ein paarmal überarbeitet, Bugs gefixt, und mich daran gewöhnt. Würde behaupten, dass es sich für mich bewährt hat. Am besten Stylish für die Installation nutzen.

Kommentarbenachrichtigungen per Mail

Tatsächlich bin ich nicht mehr nur stummer Leser, meine eigenen Submissions wurden nicht völlig ignoriert und ab und an kommentiere ich. Um Antworten auf die eigenen Kommentare mitzubekommen und nicht unhöflicherweise zu ignorieren, ist HN Notify großartig. Man bekommt jeweils eine Email mit dem Kommentar zugesandt.

Subdomains anzeigen

Bei einigen Domains mach HN das nun selbst, aber nicht bei allen - Mit dieser Chrome-Erweiterung/diesem userscript (ich hab die Erweiterung irgendwo anders installiert) wird immer die volle Domain angezeigt, wodurch man manchmal schneller mitbekommt, welcher Art der Artikel ist. War besonders wichtig für Google+-Posts, bei denen früher nur google.com als Ursprungs-URL angezeigt wurde. Dieser spezielle Fall ist nun von HN gelöst, aber ähnliche Fälle gibt es immer wieder.

Upvotes farbig symbolisieren

Artikel mit den meisten Upvotes sind nicht automatisch die mit der besten Platzierung. Im Hintergrund werkelt ein Algorithmus, der zum einen das Karma des Nutzers einberechnet und illegitime Upvotes aussortiert, aber vor allem den Artikeln ein immer stärker werdendes Gewicht zuordnet, sodass alte Artikel mit der Zeit von der Startseite verschwinden. Diese Erweiterung zeigt einen sich je nach Anzahl der Upvotes von gelb nach rot verfärbenden Balken an, wodurch diese Information viel schneller aufgenommen werden kann und zusammen mit der Platzierung auf der Seite das Gewicht und damit das Alter des Artikels gezeigt wird. Die neueste der von mir genutzten Modifikationen, muss sich erst noch bewähren, finde ich aber bisher sehr hübsch. Und passt nicht schlecht zu meinem Design.

Zuerst ein Hinweis auf einen Bug, auf den hier. Zur Vermeidung nach dem Upgrade auf 1.7 einfach in der Konfiguration die Option "URL zum Blog" nachtragen, oder die Einstellungen bis 1.7.1 nächste Woche komplett nicht anfassen. Hat mir fast Spaß gemacht, den erst halb zu fixen, nur um dann mit meinem Patch selbst in den Bug zu rennen und im Bus auf die Lösung des Problems zu kommen. Wer während meines Nachdenkens mein Gesicht gelesen hätte, hätte mich wahrscheinlich für etwas sonderbar gehalten.

Ansonsten ist 1.7 genau wie in der Releaseankündigung beschrieben in erster Linie ein Release, das notwendig wurde, weil die weiteren Änderungen von PHP 5.x Änderungen bei Serendipity notwendig machten, größtenteils der Pointerkram. Interessanter sind die neuen Funktionen und Anpassungen:

Smarty 3 ist an so viel Stellen schöner zu schreiben als die Vorgängerversion, dass ich schon eine Weile nur noch Smarty 3-Templates produziere. Schon das neue foreach alleine wäre das Upgrade wert.

Mir besonders wichtig ist die "stable archives"-Option. Google weniger unnötige Änderungen zuzumuten und von Google kommende Leser besser finden zu lassen, was sie suchen, hat mich sofort überzeugt und setzte ich deswegen besonders gerne um. Habe auch noch keine Blogsoftware bewusst wahrgenommen, die das ebenfalls richtig macht.

Und dass Dateien ohne Dateiendungen von der Mediendatenbank jetzt korrekt erkannt werden dürfte für mich hilfreich sein.

Alles in allem ein kleines Release, das sich aber auf jeden Fall lohnt. Der Autoupdater hat übrigens bei mir einwandfrei funktioniert.

Mein PC ist nicht alt, aber die genutzte Festplatte schon. Daher rechne ich gar nicht mit einem wirklich schnellen Ubuntu-Start, und tatsächlich habe ich den auch nicht. Doch e4rat hilft ein bisschen: Vorher dauerte der Bootprozess bis zum Start von X 55 Sekunden, nach Durchlaufen der Anleitung sind es 45. Nicht schlecht.

Anleitung in kurz:

ureadahead deinstallieren

sudo apt-get remove ureadahead

e4rat herunterladen und installieren:

sudo dpkg -i Downloads/e4rat_0.2.3_i386.deb

Dann

init=/sbin/e4rat-collect 

zur '"linux ..."-Zeile in der /boot/grub/grub.cfg hinzufügen, neustarten. init=/sbin/e4rat-collect wieder entfernen

Schließlich die Festplatte umfragmentieren lassen: Starten in der Wiederherstellungskonsole (oder 'single' zum normalen Booteintrag anfügen) und

e4rat-realloc /var/lib/e4rat/startup.log

solange ausführen, bis die Meldung kommt, dass keine Verbesserungen mehr möglich seien.

In die /etc/default/grub dann noch

init=/sbin/e4rat-preload

zur GRUB_CMDLINE_LINUX_DEFAULT hinzufügen und mit einem

sudo update-grub

Grub aktualisieren

Nachtrag: Man beachte Anaximanders Kommentar , das sollte manchmal wiederholt werden.

Wenn die Festplatte kaputt geht, ist hoffentlich noch ein Backup auf einer anderen Platte. Wenn die Wohnung abbrennt, sind beide Platten kaputt und alle Daten weg. So gesehen sollten ins Internet ausgelagerte Daten eigentlich sicherer vor Verlust sein - Daten in der Cloud werden redundant in verschiedenen Rechenzentrums gespeichert, um durch Unfälle verloren zu gehen muss viel passieren.

Doch was schützt vor Fehler und Willkür des Cloudbetreibers? Nichts. Zahlt man nichts für den Dienst - und selbst wenn, was ändert das groß an der Machtverteilung - sind die Daten nicht unter eigener Kontrolle. Kein origineller Gedanke, nichts neues, aber aus gegebenem Anlass: Alle meine +1 sind weg. Ich bin nicht bei Google+ angemeldet, aber +1 wurden und werden trotzdem auf der Google-Profilseite gesammelt, nur ist da jetzt eben nur noch eines, das neue.

Die +1 hab ich genutzt, um die Linkliste hier rechts im Blog zu befüllen und im gesamten war das inzwischen ein recht volles Archiv meiner Meinung nach wichtiger Artikel, ein Blick aufs Zeitgeschehen quasi aus meiner Perspektive und mit relativ vielen Erinnerungen verknüpft, was damals von mir dazu gedacht wurde.

Temporärer Fehler? Gelöschte Daten? Keine Ahnung, aber dass nur ein einziges auftaucht riecht nach gelöschten Daten. Und ich bin völlig machtlos - keine echte Supportoption auf der Seite (Feedback geben != Support), die Einstellungen führen zu einer Fehlerseite (schon immer, wohl weil kein Google+-Nutzer).

Trotz allem, das sind nichtmal wichtige Daten. Alle Emails gelöscht, das wäre schlimm (immerhin hab ich ein nicht zu altes Offline-Backup, trotzdem wäre viel weg), Account gesperrt, das wäre katastrophal. Es wird Zeit, die wirklich wichtigen Dinge wie die Email-Adresse selbst zu besitzen. Vielleicht kann man die ja anfangs auf die Google-Mail umleiten. Wenn Mailserver nur nicht so fürchterlich wären, dann könnte man das gleich ganz selbst hosten - und würde die Daten wahrscheinlich durch einen Festplattenfehler im dann einzigen Rechenzentrum verlieren…

An der Uni habe ich Zugang zu einem 3D-Drucker. Herausgekommen ist das hier:

Es ist ein Halter für ein Ansteck-Mikrofon, der seitlich an den Kopfhörer geklebt wird. Hintergrund ist, dass ich der Empfehlung des hifi-forums gefolgt bin und statt eines Headsets einen Kopfhörer samt Ansteckmikrofon gekauft habe. Im Grunde war das auch eine gute Idee, besonders der Kopfhörer ist wirklich besser als deutlich teurere Headsets. Aber das Anstecken des Mikrofons hat mich irgendwann genervt, vor allem nachdem der Plastikhalter abgebrochen ist.

Der Prototyp ist zusammengeklebt. Natürlich habe ich zuerst wesentlich kompliziertere Lösungen mit Steckverbindungen und Gelenken gebaut, so richtig haben die aber bisher noch nicht funktioniert. Wie einfach die Lösung jetzt ist sieht man vielleicht besser am CAD-Modell:

Wings3D hat sich für mich als absoluten CAD-Anfänger als gutes Werkzeug erwiesen, um unter Ubuntu das Modell zu erstellen. Blender war mir von Anfang an zu kompliziert und zu störrisch für diese eigentlich einfache Aufgabe. Bei Google Sketchup wurde mir nicht klar, ob die kostenlose Version des Programms alles nötige kann. Freecads Oberfläche blieb für mich völlig undurchschaubar.

Mit Wings3D dagegen kamen recht schnell erste Modelle zustande. Die Basisblöcke können per Rechtsklick eingefügt und einfach durch den Raum geschoben werden. Das Manipulieren der Linien, Flächen und Punkte wurde mir sofort klar. Außerdem das einzige Programm, dessen Kamerasteuerung intuitiv funktioniert. Böse Stolperfalle jedoch ist die "Hole"-Funktion zum Einfügen von Löchern in Objekte: Die blendet Vektoren nur aus, aber entfernt sie nicht, was bei späterer Manipulation des Objekts unspeicherbare Modelle produziert. Dass man sie nicht wirklich nutzen soll findet man im Forum, dass stattdessen die "Intrude"- und "Inset"-Funktionen, angewandt gleichzeitig auf die gegenüberliegenden gleichgroßen Seiten eines Modells, die Aufgabe erledigen, war schon schwerer herauszufinden.

Beeinflusst vom AntLion-Modmic.

Download: modmic-simple.stl

Perfekte Reaktionen: Erst in den Drachen hineinspringen, dann herausspringen, mit Zhonyas Karthus Angriffe überleben und dann auch noch seiner Ulti ausweichen. Ich finde, das ist ein gutes Beispiel dafür, warum man ein Spiel wie LoL immer und immer wieder spielen kann und was man dabei im Kleinen lernt.

Das Video des Vortrags, dessen Zusammenschrieb ich bereits verlinkte. Jeffrey Linn erklärt die Bemühungen Riots, den negativen Einfluss von pöbelnden Spielern auf die anderen zu verringern. Ziemlich interessant, Zahlen zu den auch selbst gespürten gewaltigen Auswirkungen dieser Experimente zu sehen.

Nachtrag zu Lügen der Spielehersteller: Wenn Spielehersteller mit ihren Lügen auffliegen, müssen sie ja auch damit umgehen. Rock, Paper, Shotgun zeigt in einem Artikel über Maxis und SimCity, wie die das bei ihrer Lüge über die vermeintliche Berechnung von Zeug in der Cloud und dem damit angeblich notwendigen Always-On-Modus machten:

EA and Maxis simply ignored all those emails. Sites may have received a, “We’re waiting for a response,” from their regional PRs, but that was it. And so if you’re running GamePow.com, and you’ve decided you can’t run RPS’s anonymously sourced story without giving EA a response, ta-da – no story on GamePow. And EA knows that.