onli blogging - Technikzeugs

Die Brainstormabschaffung ist eine Bankrotterklärung

nospam@example.com (onli) — Thu, 16 May 2013 22:41:00 +0200

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 verbessern

nospam@example.com (onli) — Thu, 16 May 2013 15:58:00 +0200

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.

Serendipity 1.7

nospam@example.com (onli) — Tue, 14 May 2013 20:43:00 +0200

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.

Boot beschleunigen: e4rat statt ureadahead

nospam@example.com (onli) — Thu, 09 May 2013 13:05:00 +0200

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 Daten einfach weg sind

nospam@example.com (onli) — Mon, 06 May 2013 19:27:00 +0200

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…

Modmic

nospam@example.com (onli) — Tue, 30 Apr 2013 15:56:00 +0200

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.

Leichte Software - Eine Definition

nospam@example.com (onli) — Tue, 16 Apr 2013 08:03:00 +0200

Martin hat in seinem Blog einen englischsprachigen Artikel What makes a “lightweight” desktop environment lightweight? geschrieben. In ihm kommt er zu dem Schluss, dass das Attribut "leichtgewichtig" willkürlich sei und eigentlich keine Bedeutung habe.

Ich mag den Artikel. Martin tut so, als würde er den Begriff nicht verstehen, und ich glaube, dass er sich da bewusst seiner eigenen instinktiven Deutung des Begriffes widersetzt - und er übersieht völlig die mich sehr erheiternde Ironie darin, wenn ausgerechnet ein KDE-Entwickler mit dem Bild leichter Software nichts anfangen kann (was ich tatsächlich nicht böse meine). Aber zusammen mit seinem Ausschlussverfahren, das ziemlich gut beschreibt, was leichte Software ist (nur zum gegenteiligen Schluss kommt), und den Kommentaren ergibt sich ein gutes Gesamtbild, das in meinen Augen den Begriff wirklich schön zeichnet. Ich nehme das mal und mische es hier mit meiner eigenen Definition.

1. Leichte Software ist subjektiv

Offensichtlich geht es nicht um das Gewicht der Software und nicht um die Größe des Codes. Software mit einem Gewicht zu belegen kann angesichts ihrer inhärenten Gewichtslosigkeit nur ein emotionaler Begriff sein, der eine Brücke schlägt zu Erfahrungen im rl. Und das ist ein guter Anhaltspunkt bei der Deutung des Begriffes. Wenn etwas im echten Leben schwer ist, tragen wir schwer daran, haben Probleme, es zu bewegen, beschleunigt es nicht so schnell wie ein leichteres Objekt mit der gleichen Antriebskraft; alles geeignete Analogien zu unserer jeweiligen subjektiven Erfahrung mit Software.

Martin begab sich auf die Suche einer festen Definition von leichter Software und scheiterte daran, eine solche zu finden. Wenn Software auf der und der Hardware so und so gut läuft, dann ist die Software leichtgewichtig - das wird man seltenst irgendwo lesen. Da es ein Attribut ist, das die Bewertung des Nutzers wiedergibt, ist es für jeden Nutzer eine andere Hardware und eine andere Eigenschaft, die das Attribut rechtfertigt. Das kann der Start der Software selbst sein: Wenn eine Desktopumgebung mehrere Sekunden zum Starten braucht, fühlt sich das nicht schnell, nicht leicht an. Es kann aber auch wesentlich weiter gehen. Es kann sogar technisch versierte Nutzer geben, welche die Abhängigkeiten oder den Code selbst heranziehen - das dürfte die Ausnahme sein, soll hier aber Beispiel dafür sein, wie subjektiv die Klassifikation sein kann.

2. Leichte Software ist effizient

Aber es gibt durchaus offizielle Definitionen der Benutzbarkeit von Software, die mit dem Begriff leichtgewichtiger Software verknüpfbar sind. Nach ihnen hat Martin seiner Beschreibung nach nur nicht gesucht und sie auch nicht zufällig gefunden.

Sie verbirgt sich in Effektivität, Effizenz und Nutzerzufriedenheit, dem Dreiklang der HCI nach DIN ISO 9241.

Effektivität:: Die Möglichkeit, mit dem Werkzeug eine Aufgabe überhaupt zu erledigen.
Effizienz:: Wie schnell und wie einfach die Aufgabe zu erledigen ist.
Nutzerzufriedenheit:: Der Begriff erklärt sich selbst, wird von den vorherigen Faktoren beeinflusst, aber nicht alleine von ihnen bestimmt.

Eine Kategorisierung von Software als leicht ist nun eine Einstufung dieser Software in der zweiten Kategorie, Effizenz. Denn vergleicht man zwei verschiedene Programme und hält das eine für leichtgewichtig, das andere aber nicht, impliziert man damit meist, dass beide der gleichen Aufgabe dienen. Effektivität kann es also nicht sein. Und Zufriedenheit ist zuwenig mit der eigentlichen funktionalen Eigenschaft der Software verknüpft, um das zu beschreiben (auch wenn das sicher mit hereinspielt). Es geht also darum, wie einfach und wie schnell etwas zu machen ist. Und klar: Geht etwas mit wenigen Klicks in einer überschaubaren Oberfläche und ohne störende Ruckler, geht es in der Regel effizienter, als sei dem nicht so. Und genau das kann leichte Software sein: Solche, die nicht ruckelt und solche, die eine Aufgabe schnell und einfach erledigen lässt.

3. Was leicht ist, wird relativ zur Hardware definiert

Wenn eine Desktopumgebung dazu führt, dass der Browser nur träge reagiert - dieser aber unter einer anderen annehmbar schnell läuft - ist sie sicher nicht leicht. Dieses Phänomen kann ich wunderbar auf dem Thinkpad R50 mit Unity und E17 beobachten. Während sich unter Unity alles zäh und träge anfühlt, beim Fenstermanagement, beim Aufruf des Dashs und den Hovereffekten des Docks, aber auch beim Surfen im Browser, ist es unter E17 gut erträglich, flüssig sogar, sodass man einwandfrei mit ihm arbeiten kann (ich hatte ihn z.B. auf dem ictf dabei). Offensichtlich ist Unity derart fordernd, dass die Oberfläche langsam gerendert wird und für die eigentliche Aufgabe nicht genug Ressourcen übrig bleiben. Das Gegenteil leichter Software.

4. Leichte Software hat keinen (wahrnehmbaren) bloat

Aber auch, wenn die GUI der Software viele Elemente hat und überladen wirkt, kann das zu dem Nutzereindruck führen, nicht leichtgewichtig zu sein. Das war nebenbei ja schon immer eine Lektion, die KDE nicht lernen wollte. Zum einen, weil leichte Software ein emotionaler Begriff und eine Analogie ist, zum anderen, weil es um die Effizenz beim Ausführen einer Aufgabe geht, ist es nicht alleine Geschwindigkeit der Software - eine Kerbe, in die Martin gerne schlägt, wenn er von Optimierungen für neue Hardware redet. Es geht um die Aufgabe und den Weg dahin, und eine klar steuerbare (noch so ein HCI-Begriff) GUI hilft dem Nutzer dabei, eine Aufgabe effizient zu erledigen.

Es geht hier wohlgemerkt nicht um Konfigurierbarkeit. IceWM und viele andere kleine, leichte Fenstermenager sind stärker konfigurierbar als jede Desktopumgebung. Trotzdem wirken sie leichter, schon weil sie in jeder Hinsicht schneller sind - und auch, weil ihre Konfigurationsmöglichkeiten in Textdateien versteckt sind.

Wobei sich das nicht auf GUIs beschränkt: Die Komplexität der Konfiguration und die Performance des Tools können auch bei Programmen mit Text-UI bewirken, nicht als leichtgewichtig wahrgenommen zu werden. Programmiersprachen sind gar ein völlig eigenes Kapitel.

Zusammenfassend: Leichte Software ist viel und wenig

Viele Programme können leicht wirken und viele Faktoren wirken sich hier aus. Der Eindruck kann sich ergeben, wenn etwas besonders flüssig läuft. Eine gute Energieeffizienz kann helfen, wenn der Nutzer gerade darauf achtet, z.B. weil unter Linux im Gegensatz zu Windows der Lüfter des Laptops nur in Ausnahmefällen zu hören ist oder der Akku länger hält. Wenn Software auf vielen alten System läuft, ist sie leicht, bzw diese ist es, die auf der alten Hardware am besten/schnellsten/flüssigsten läuft - aber nicht solche Software, die sich erstmal an einem 5-minütigen Splashfenster abrackert (übrigens ein Anti-Pattern in der Interfacegestaltung).

Das kann man umdrehen: Wenn ein Programm eine simple, klare Oberfläche mit wenigen Elementen hat, kann dies den Eindruck leichter Software hervorrufen. Verstärkt noch, wenn der Stil der Software schlicht ist - und meinem Eindruck nach insbesondere, wenn die Oberfläche zwar schlicht, aber gleichzeitig hübsch und auch noch responsiv ist. Sind die Hardwareanforderungen gering, ist Software leicht. Erfordert die Software wenig Vorwissen, ist die Software ebenfalls leicht - auch so kann man den Begriff anwenden, wobei hier sich leicht als einfach mit leicht als leichtgewichtig vermengt

Man kann das alles in eine vereinfachende Faustregel als Fazit zusammenpacken: Läuft Software schnell auf alter und neuer Hardware des Nutzers und hat keine Oberfläche, die eine gegenteilige Atmosphäre schafft (z.B. durch langsame Animationen oder der Komplexität des Workflows), dann wird sich beim Nutzer der Eindruck ergeben, dass die Software leichtgewichtig ist.

Ruby/Sinatra-Anwendung auf AppFog laufen lassen

nospam@example.com (onli) — Sat, 13 Apr 2013 08:13:00 +0200

Beim letzten mal war die versuchte Nutzung von Cloudhosting mit Heroku ein Reinfall. Relativ viel Arbeit für ein Scheitern an der Performance. Doch es gibt Alternativen zu Heroku, und AppFog ist eine, die mir sehr gut gefällt.

Auch AppFog unterstützt einen kostenlosen Account, bietet aber wesentlich mehr als Heroku: 2 GB statt 512 MB Ram, 8 Instanzen statt einem Worker und 8 mögliche sogenannte Services, darunter verschiedene Datenbanken. Es gibt auch Einschränkungen, die bei Heroku nicht erwähnt werden: 5 GB Traffic im Monat und ein Maximum von 100 Requests pro Sekunde. Unterschiedlich sind die Datenbanklimits und das Accountmodell: 100 MB bei AppFog gegen 10k Reihen bei Heroku, und AppFogs Ressourcen gelten accountweit, Herokus pro Anwendung. Völlig entfällt die ziemlich kritische Beschränkung, keine Hintergrundthreads laufen lassen zu können.

Wie gesagt, ich halte das AppFog-Angebot für wesentlich besser.

Instanz einrichten

Doch nicht nur das Hosting selbst ist besser, auch die Dokumentation drumrum gefiel mir besser. Sie ist auch schnell zusammengefasst. Statt direkt mit git wird mit einem Tool namens af gearbeitet:

gem install af
af login

Vom Kontrollzentrum kann die Beispielanwendung als .zip heruntergeladen werden. Mit ihr wird auch schnell klar, was sonst noch zu tun ist. Wieder muss eine Gemfile angelegt werden. Meine:

source :rubygems

gem "sinatra"
gem "thin"
gem 'pg'
gem 'json'
gem 'nokogiri'
gem 'rest-client'
gem 'haml

Ein

bundle install

später kann die Anwendung per

af update APPFOG-SERVERNAME

hochgeladen werden. Die app.rb kann mit jeder anderen Datei ersetzt werden, welche Datei ausgeführt werden muss, wird durch das require 'sinatra' erkannt - sehr nett!

Datenbank aktivieren

Da die Anwendung vom letzten mal schon für PostgresSQL angepasst war, blieb das natürlich als Datenbank gesetzt. Die Datenbank kann im Kontrollzentrum als Service aktiviert und dort benannt werden. Dann werden die Einloggdaten als Umgebungsvariable der Anwendung gegeben, und diesmal gibt es tatsächlich ordentlichen Beispielcode (mit dem kleinen Fehler, dass dort im Original :username statt :user steht):

services = JSON.parse(ENV['VCAP_SERVICES'])
postgresql_key = services.keys.select { |svc| svc =~ /postgresql/i }.first
postgresql = services[postgresql_key].first['credentials']
postgresql_conn = {:host => postgresql['hostname'], :port => postgresql['port'], :user => postgresql['user'], :password => postgresql['password'], :dbname => postgresql['name']}
@db = PG.connect(postgresql_conn)

Ansonsten gelten natürlich die gleichen Hinweise wie bei Heroku, wenn von sqlite aus umgestellt werden muss.

Gut funktionierte bei Heroku der Zugriff auf die Datenbank von außen. Auch bei AppFog ist das gut gelöst, wobei ich die Lösung erst finden musste. Das Stichwort ist Tunnelling:

gem install caldecott
af services
af tunnel DATENBANKNAME

Fazit

AppFog hatte natürlich den Vorteil, dass durch den vorherigen Versuch mit Heroku mir ziemlich klar war, wie das alles funktionieren müsste - reduzierte Verwirrung führt schnell zu einem besseren Eindruck. Aber auch ohne diesen Vorteil ist AppFog meiner Meinung nach klar die bessere Wahl:

Wesentlich umfangreicheres kostenloses Angebot...
...mit tatsächlich deutlich besserer Performance.
Klarer strukturierte Dokumentation, inklusive Beispielcode für die Datenbankanbindung (wie kann sowas fehlen?).

Aber der wichtigste Vorteil von AppFog ist, dass meine Anwendung hier funktionierte und auf Heroku nicht. Und das lag höchstwahrscheinlich am Serverstack und damit an Heroku, nicht an der Anwendung selbst (wie erwähnt konnte ich Herokus Analysetool nicht testen). Rsspusher trägt sich bei verschiedenen PuSH- bzw rssCloud-Hubs als Abonnent ein, und dieses Eintragen muss bei beiden Protokollen jedes mal bestätigt werden, indem von dem Hub ein GET an rsspusher geschickt wird, wobei die so gesendete Challenge zurückgegeben werden muss. Das war auf dem Entwicklungsrechner kein Problem, das war auf AppFog kein Problem, aber unter Heroku lief das jedes mal in ein das Zeitlmit von 2 bzw 3 Sekunden, weil die Anfrage laut Log im Heroku-Stack alleine solange hängen blieb. Ich weiß nicht, ob das an dem einzelnen Worker hing (eigentlich ist das kein Grund, ein Worker kann mehrere Anfragen parallel bearbeiten), aber das war definitiv kein guter Eindruck.

Ruby/Sinatra-Anwendung für Heroku anpassen

nospam@example.com (onli) — Sat, 06 Apr 2013 08:58:00 +0200

Heroku ist eine Cloud-Plattform und war eine ganze Weile die einzige mir bekannte Plattform mit einem kostenlosen Tarif (ohne behaupten zu wollen, dass es damals nichts anderes gab). Da mir Ruby und besonders Sinatra sehr gut gefällt und Heroku für Ruby eine Weile der Cloudhoster-Vorzeigekandidat war, wollte ich schon vor einiger Zeit eine Anwendung von mir dort laufen lassen. Damals scheiterte ich - das ganze Ruby-Universum war mir noch zu neu - aber inzwischen habe ich ein anderes Projekt erfolgreich portiert. Man muss allerdings einiges beachten, was genau halte ich hier mal fest.

Alles hier gilt für Ubuntu 12.04.

Heroku einrichten

Herokus Seite ist der einfache Part. Auf https://www.heroku.com/ einen Account anlegen und der Anleitung folgen:

wget -qO- https://toolbelt.heroku.com/install-ubuntu.sh | sh    # Heroku-Tools installieren
heroku login    # einloggen und public ssh-keys hochladen

Nun der rubyspezifische Teil (diese Anleitung). Für die Verwaltung der gems muss eine Datei Gemfile im Anwendungsverzechnis angelegt werden. Der Inhalt:

source :rubygems
gem 'sinatra'
gem 'pg'
# die weiteren genutzten gems

Wer aus der Rails-Welt kommt, kennt das wohl. Die Datei dann auch nutzen:

bundle install

Außerdem fehlt noch die config.ru mit diesem Inhalt:

web: bundle exec rackup config.ru -p $PORT

Damit sind die benötigten Dateien zusammen. Dies alles nun in git festhalten und heruko übergeben:

git init
git add .
git commit -m "init"
heroku create
git push heroku master

Um später Updates an heroku zu sende, diesen Schritt ohne git init und heroku create ausführen

Postgresql installieren

Leider kann heroku nicht die von mir bevorzugte SQL-Datenbank nutzen, sqlite. Stattdessen muss man Postgresql nutzen, was mir eigentlich gar nicht passte - mir sind die nicht-dateibasierten Datenbank zu konfigurationslastig. So ist auch postgresql etwas knifflig einzurichten. Immerhin sollte der Wechsel der Performance der Anwendung gut tun.

Auf Heroku ist die postgresql-Datenbank schnell aktiviert:

heroku addons:add heroku-postgresql:dev

Um aber den Code weiter lokal testen zu können und den Datenbank-Remotezugriff nutzen zu können, muss Postgresql auch lokal installiert werden. Dafür installiert man das Paket postgresql. Die Datenbank muss aber noch konfiguriert werden. Am einfachsten ist dieser Weg:

sudo -u postgres createuser --superuser $USER
sudo -u postgres psql
postgres=# \password $USERNAME    # des Hauptnutzers, unter dem entwickelt wird
postgres=# \q
createdb $USER

Hier wird eine Datenbank so eingerichtet, dass der Hauptnutzer sich mit einem psql in die Datenbank einwählen kann.

Datenbankcode für Postgresql anpassen

Nun muss noch der Code angepasst werden. Wer hier ein ORM nutzt, findet dafür in der Doku Code. Wer wie ich direkt mit SQL-Statements arbeiten will, der hat es etwas schwerer. Funktionierenden Beispielcode fand ich gar nicht.

Zuerst braucht man den Datenbankpfad. Ein

heroku config | grep HEROKU_POSTGRESQL

sollte einen String der Form postgres://USERNAME:PASSWORD@ec2-107-...-213.compute-1.amazonaws.com:5432/d9...rnr zurückgeben. Diesem können nun die Datenbankdaten entnommen werden.

Im Ganzen: Ich habe eine database.rb, vorher ein Wrapper für sqlite. Vorher:

class Database
    def initialize()
        begin
            @@db    # create a singleton - if this class-variable is uninitialized, this will fail and can then be initialized
        rescue
            @@db = SQLite3::Database.new "rssnotifier.db"

            begin
                puts "creating Database"
                @@db.execute "CREATE TABLE IF NOT EXISTS watches(
                     ...
       
                @@db.execute "PRAGMA foreign_keys = ON;"
                @@db.results_as_hash = true
            rescue => error
                puts "error creating tables: #{error}"
            end
        end
    end

def getPages(subscribed)
        begin
            pages = []
            @@db.execute('SELECT DISTINCT url FROM watches WHERE subscribed = ?', subscribed ? 1 : 0) do |row|
                pages.push(Page.new(row["url"]))
            end
            return pages
        rescue => error
            puts "error getting pages: #{error}"
        end
    end

    ...

Umgestellt auf postgresql:

class Database
    def initialize()
         db = URI.parse(ENV['DATABASE_URL'] || 'postgres://USERNAME:PASSWORD@ec2-107-...-213.compute-1.amazonaws.com:5432/d9...rnr')
         @db = PG::Connection.open(:dbname => db.path[1..-1], :user => db.user, :password => db.password, :port => db.port, :host => db.host, :sslmode => 'require')
         #@db = PG::Connection.open(:dbname => 'onli', :user => 'onli', :port => 5433)     # lokaler Zugriff

         begin
              puts "creating Database"
              @db.exec "CREATE TABLE IF NOT EXISTS watches(
                                ....
         rescue => error
                puts "error creating tables: #{error}"
         end
    end

def getPages(subscribed)
        begin
            pages = []
            @db.exec('SELECT DISTINCT url FROM watches WHERE subscribed = $1', [subscribed] ? [1] : [0]) do |results|
                results.each do |row|
                    pages.push(Page.new(row["url"]))
                end
            end
            return pages
        rescue => error
            puts "error getting pages: #{error}"
        end
    end

    ...

Eine Liste der Änderungen:

Kein Singleton für die Verbindung nutzen! Das führte zu ziemlich widerlichen SSL-Fehlern und es dauerte ewig, bis ich darauf kam, dass es daran lag (übrigens kein Heroku-spezifischer Bug).
Die Datenbankkonfiguration wird aus der Datenbankurl geparst (abgeleitet aus der Doku). Da habe ich mir Beispielcode (ohne ActiveRecord) in der Doku und einen schöneren Weg, ohne Parsen des Datenbankpfades, erhofft.
exec ersetzt execute.
Man beachte den zusätzlichen |results|-Zwischenschritt.
(Nicht im Code) Postgresql beherrscht kein INSERT OR REPLACE. Stattdessen erst ein UPDATE, dann ein INSERT ausführen.
Die Parameterersetzung hat eine andere Syntax: $X statt ? und Übergabe eines einzelnen Arrays statt der einzelnen Argumente.
Den Code zum Zugriff auf die lokale Datenbank habe ich der Einfachheit halber hier festgehalten (den muss man nämlich auch erstmal finden). Man beachte den Port, der nicht der Standardport ist!

Die Anpassungen an den SQL-Queries selbst ist nicht zu schlimm, größtenteils scheint sqlite3 eine Submenge von postgresql zu sein. Bei den Datumsfunktionen bin ich dagegen direkt auf Rubycode umgestiegen.

Lohnt das?

Durchaus ein Haufen Aufwand, vor allem ohne diese Anleitung. Für meine Anwendung hat sich das ganze nichtmal gelohnt, heroku war schlicht zu langsam und die mit meiner Anwendung kommunizierenden Dienste liefen immer(!) in Timeouts. Wenn der freie Plan nichtmal zum Testen ohne jegliche Last reicht, ist das kein gutes Zeichen. Um festzustellen, an welcher Stelle die Anwendung hakt, bietet heroku mit New Relic die laut Liste nötigen Daten, ebenfalls mit einem kostenlosen Tarif - aber um den zu aktivieren, wird trotzdem eine Kreditkarte gefordert. Die ich weder besitze noch zu diesem Zeitpunkt angeben wollen würde.

Und so reizvoll die Skalierbarkeit solch einer Cloudplattform auch ist: Die Preise sind heftig. Ein eigener Server hat da echte Vorteile.

Wächst das Internet exponentiell?

nospam@example.com (onli) — Sun, 24 Mar 2013 15:18:00 +0100

Die Telekom will Trafficbegrenzungen für normale DSL-Anschlüsse einführen, so geht es derzeit durch die Medien. Und auf dem Telekom-Blog wird dazu ein Nicht-Dementi veröffentlicht, das nur sagt, dass solche Tarife noch nicht eingeführt wurden, ohne Distanzierung von diesen Plänen. Verwiesen wird dabei auf einen Spiegel-Artikel mit den Worten:

Auf der einen Seite wächst das Datenvolumen exponentiell.

Doch stimmt das? Der Spiegel-Artikel gibt das gar nicht so einfach einfach her.

Definition: Wachstum

Was bedeutet exponentielles Wachstum überhaupt? Bei exponentiellem Wachstum wächst etwas immer stärker, je mehr da ist, um einen festen Prozentsatz. 2^x wäre eine solche Wachstumsfunktion: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 ... Man muss sich klarmachen, dass dies bei großen Werten im realen Leben extrem katastrophal sein kann - z.B. beim Ölverbrauch. Hätten wir einen festen Ölvorrat und wüchse unser Verbrauch exponentiell, stünden wir irgendwann an dem Punkt, an dem am nächsten Tick der gesamte verbliebene Ölvorrat verbraucht würde - genau das macht das Peak-Oil-Szenario so erschreckend.

Lineares Wachstum ist einfacher. Wächst etwas immer um den gleichen Wert, wächst es linear - beispielsweise wenn jemand jeden Tag eine Liegestütze mehr macht.

Polynomiales (kubisches) Wachstum (meine Vermutung: Internetwachstum entspricht eher sowas) sieht exponentiellem Wachstum ähnlich, hat aber nicht diese enorme Steigerung am Ende des Graphen. x³ ist das Beispiel im Graphen: 1, 8, 27, 64, 125, 216, 343, 512. Etwas, das immer mehr immer mehr wird, jedoch später mit immer geringerem prozentualem Wachstum.

Trafficentwicklung des Internets

Der Spiegel-Artikel gibt das exponentielle Wachstum also gar nicht so einfach her. Denn der fasst die Studie so zusammen:

Bis 2016 werde sich das durch die weltweiten Computernetze transportierte Datenvolumen vervierfachen

Eine Vervierfachung ist aber noch nicht exponentielles Wachstum. Exponentielles Wachstum ist irgendwas^x, eine Vervierfachung ist 4*x. Man sieht mein Problem auch schön auf dem (per Cisco-Tool) erstelltem Graph der Trafficprognosedaten:

Die Linie für z.B. Nordamerika sieht linear aus. Ist das im gesamten wirklich exponentielles Wachstum?

Hier noch die Daten des Gesamttraffics aus dem Whitepaper per Wolfram:

Das sind 30.734, 43.441, 54.812, 69.028, 87.331, 110.282 PB per Monat.

Und immerhin: Das Wachstum erhöht sich im Laufe der Zeit. Jährlich wächst der Traffic um 13, 11, 15, 18, 23 PB per Monat. Lineares Wachstum können wir also ausschließen. Aber ist das nun exponentiell oder polynomial?

Sieht man das am Steigungsgraph der Interpolation?

Ich nicht.

Exponentielles Wachstum ist Wachstum um einen festen Prozentsatz. Und prozentual ist das bei den gegebenen Werten Wachstum um 43%, 25%, 27%, 26%, 26%. Das ist also praktisch exponentielles Wachstum, abgesehen von der Abweichung im ersten und zweiten Jahr. Die prozentualen Wachstumswerte als Chart:

Nebenbei: Mathematisch erschlagen

Hier hatte ich zuerst die Interpolation genommen und mir mit großen x angesehen. Aber eine Interpolation per Polynom kann doch nur polynomiales Wachstum zeigen, oder? Und Wolfram kann auch nicht einfach die Fortsetzung dieser Reihe berechnen, was ich einfach mal als Hinweis auf nicht-exponentielles Wachstum nahm.

Man kann auch versuchen, das per Hand zu berechnen. Und vergessen wir dabei einfach mal den Wachstumsabfall - es geht also um das Wachstum 11, 15, 18, 23 der Werte 43, 54, 69, 87, 110.

"Es gibt ein m>1, so dass für n>=n_0 stets (a_n+1)/(a_n) >=m ist, dann liegt exponentielles Wachstum vor (man zeigt leicht a_n>= C m^n)"

54/43 >= m
69/54 >= m
87/69 >= m
110/87 >= m

Ja, ein solches m existiert: Demnach wächst das Internet exponentiell.

"Gibt es M>0 und p mit: für n>=n_0 ist stets a_n>M n^p, dann hat man mindestens polynomiales Wachstum."

Das ist auf deutsch die simple Überlegung: Finden wir ein Polynom, das weniger stark wächst als die gegebenen Werte? Gut, prüfen wir das. Das zu lösende Gleichungssystem:

43 > M * 1^p
54 > M * 2^p
69 > M * 3^p
87 > M *4^p
110 > M * 5^p

Und ja, solche p und M scheinen zu existieren:

"Gibt es M und p mit: für n>=n_0 ist stets a_n<=M n^p, dann hat man höchstens polynomiales Wachstum."

Finden wir ein Polynom, das stärker wächst als die gegebenen Werte?

43 <= M * 1^p
54 <= M * 2^p
69 <= M * 3^p
87 <= M *4^p
110 <= M * 5^p

Und ja, auch solche M und p gibt es: Demnach wächst das Internet nicht exponentiell, sondern polynomial.

Und dadurch wird klar: Diese Formeln sind für echte Folgen, nicht für ein paar Werte, und helfen hier nicht weiter. Sie sagen nur, dass man die Werte sowohl exponentiell als auch polynomial fortsetzen kann.

Trafficentwicklung in Deutschland

Aber es geht in der Diskussion um Volumenbegrenzungen für DSL-Anschlüsse ja gar nicht um das ganze Internet. Es geht um DSL-Anschlüsse in Deutschland, und ohne mobiles Internet, ohne die Internetisierung der Entwicklungsländer, kann das alles ja schon wieder ganz anders aussehen. Oben im Cisco-Graph sah das Wachstum für Deutschland sehr linear aus.

Aber es geht ja ein bisschen genauer.

Aus der Advanced-Version des Cisco-Tools kommen die genauen Daten: Traffic bis 2016 ohne mobiles Internet und nur für Deutschland. Zugunsten der Telekom mische ich Business und Consumer-Segment, auch wenn es bei diesen Tarifen wahrscheinlich nur um Consumer gehen wird (so ganz sicher kann man sich eben nicht sein). Das sieht so aus

Die genauen Werte sind 1196.9, 1748.6, 2175.3, 2744.6, 3370.2, 4040.4. Das Wachstum also 552, 427, 569, 626, 670. Wieder sich steigerndes Wachstum, abgesehen von dem Einbruch auf 2013. So sieht die Ableitung der Interpolationsfunktion aus (interessante Abweichung):

Das ist Wachstum um 46%, 24%, 26%, 22%, 19%. Also: Nein, bei dem Wachstumsabfall am Ende ist das eher kein exponentielles Wachstum, sondern polynomiales.

Als Chart:

Fazit

Zuerst: Ja, die Cisco-Daten sagen aus, dass das Internet insgesamt exponentiell wächst (wenn Internet == Traffic). Nicht jedoch das deutsche Internet ohne Mobilfunk, um das es bei der DSL-Volumenbegrenzungsdiskussion geht. Aber auch das deutsche Internet wächst nicht linear, sondern es wächst der Prognose nach von 26% bis 19% im Jahr, was immer noch gewaltiges Wachstum ist. Das könnte für die Telekom tatsächlich eine Herausforderung sein - um das richtig zu bewerten müsste man die Kapazitäten kennen. Trotzdem deuten die Daten daraufhin, dass sich die Situation für die Telekom im DSL-Bereich in Zukunft eher entspannen wird, wenn das prozentuale Wachstum tatsächlich weiterhin abnimmt. Dementsprechend halte ich den simplen Hinweis auf exponentielles Wachstum des Internets für irreführend.

PS: Danke an Robert und Hartmut für eure Hilfe beim Erstellen des Artikels.

Bash: echo mit Umbrüchen

nospam@example.com (onli) — Sat, 23 Mar 2013 08:32:00 +0100

Weil ich es das nächste mal sicher wieder brauche:

So gibt man einen String in der Originalformatierung aus:

test="abc
def"
echo -e "$test"   
abc
def

Genauso in Backticks:

test2=$(echo -e "$test" | sed 's/[ad]/z/g')
echo -e "$test2"
zbc
zef

Wobei auch die doppelten Anführungszeichen gehen:

test2="$(echo -e "$test" | sed 's/[ad]/z/g')"
echo -e "$test2"
zbc
zef

iCTF 2013 - { netflow: [] }

nospam@example.com (onli) — Sat, 23 Mar 2013 01:58:20 +0100

Ich komme gerade vom iCTF 2013.

Das Szenario war wie folgt: Auf einem isolierten Server liefen eine Reihe von (größtenteils Python-)Diensten, z.B. ein kleines Blogsystem und ein Spiel. Die Teams schreiben Exploits, um über die enthaltenen Sicherheitslücken an die Flaggen (spezielle Strings) zu kommen, führen diese aber nicht selbst aus, sondern übermitteln sie an die Spielleiter, die in einem eigenen Dienst die Exploits dann gegen die Dienste der anderen laufen lassen. Entdeckt ein Team, dass ein anderes gerade auf eine eigene Flagge zugegriffen hat, kann es das melden und so auch dafür Punkte bekommen.

Die Exploits zu finden war durchaus eine Herausforderung. Kurz vor Ende wurde noch ein echtes entdeckt, konnte aber nicht mehr rechtzeitig programmiert werden, ein anderes Exploit funktionierte unerklärlicherweise nicht und ein drittes wurde zwar übermittelt, aber nicht mehr ausgeführt. Das war durchaus schade.

Mich hat die Verteidigung gereizt. Relativ früh bemerkten wir, dass Flaggen aus dem Pseudo-Blogsystem ausgelesen wurden. Das Schema war relativ simpel: Flaggen lagen als Datei in blogsystem/flags, die Artikel des Blogsystems als Datei gespeichert in blogsystem/posts, und die Angreifer schafften es, in die blogsystem/posts.metadata Javascript einzuschleusen, das dann vom (node-)Server ausgeführt wurde und die Flaggen in die posts geschrieben hat. Also schrieb ich ein Bash-Skript, dass sekündlich alle Posts auf Flaggen durchsucht, bei entdeckter Flagge das Änderungsdatum der Datei protokolliert und an meinen Rechner schickte (per netcat). Dort lief dann ein Skript, das aus dem netflow-Protokoll die id desjenigen auslas, der zu dem Zeitpunkt des Angriffs auf den Port des Blogsystems zugegriffen hat. Wegen mechanize erledigten ruby-Skript das Ausfüllen der Formulare, wieder ein Bashskript steuerte die beiden Rubyskripte und nahm die Angriffszeitpunkte entgegen.

Das hat auch ganz gut funktioniert, obwohl es in dem Trubel unwahrscheinlich lang gedauert hat, die Skripte zum Laufen zu kriegen (mein letztes Bash-Skript ist ne Weile her). Oder es hätte ganz gut funktioniert, wenn nicht die ganze Zeit die Infrastruktur ausgefallen wäre. In den letzten Stunden sah das netflow-Log so aus:

{ 
"netflow": [] 
}

Das machte das Schreiben der Skripte nicht einfacher (json mit Bash parsen erfordert grep und sed, und das muss man schon wirklich gegen Livedaten testen) und machte die ganze Bemühungen für die Katz, weil das fertige Skript ohne Angreifer-Log dann ja auch nichts reporten konnte.

Trotzdem kamen aus dieser Ecke, vor dem Zusammenbruch der Infrastruktur, unsere Punkte, und das könnte man das nächste mal sicher noch verbessern (Intrusion-Detection-System verwenden und direkt Wireshark einrichten).

Speicherverbrauch kleiner Fenstermanager unter Precise

nospam@example.com (onli) — Thu, 21 Mar 2013 17:02:00 +0100

Wieder Daten, die nicht von mir sind (Quelle, via).

Die Werte sind klein, aber auch anders errechnet als die von mir damals, denn hier wurde nur der Speicherverbrauch der Fenstermanager selbst angeschaut, nicht des Gesamtsystems.

Für mich ist es interessant zu sehen, wie die Vermutungen und Trends von damals sich bewahrheitet und gehalten haben: XFCE ist immer noch deutlich speicherhungriger als die Alternativen, insbesondere LXDE, was wiederum deutlich größer ist als die echten kleinen Fenstermanager. Und E17 kann mit LXDE mithalten, was schön zu sehen ist - das war bei der letzten Messung nur zu erhoffen.

Die Wehwehchen der Anderen

nospam@example.com (onli) — Fri, 15 Mar 2013 08:44:00 +0100

Unity, Adware, Mir und Rolling Releases - es gab und gibt viel zu diskutieren und zu streiten im Ubuntuland. Vielleicht beruhigt da der Blick über den Tellerrand: Auch andere Distributionen und Projekte hatten in letzter Zeit ihre Probleme, und manche davon waren unschön. Unschön genug, um Mitleid zu haben, und sich darüber zu freuen, dass dieser Kelch bisher an uns vorbeigingen.

Fedora 18: Das Anaconda-Desaster

Vielleicht hätte eine Orientierung an den Qualitätskriterien des Wikigotts Dee das verhindert (na, wie komm ich darauf?), aber so hatte Fedora 18 nach Release wohl mehr als nur kleinere Qualitätsprobleme. So viele, dass sie ein äußerst spaßiges Review provozierten. Marke:

Desktop effects
Did not work, at all. Nothing.

Aber es war der Installer Anaconda, der so richtig missraten zu sein scheint. Unter der Abschnittsüberschrift "Installation - Worst ever" finden sich Fundstücke wie

You enter a world of smartphone-like diarrhea that undermines everything and anything that is sane and safe in this most important of software configuration steps.

Wer das für übertrieben hält - und nun gerade ansetzen will, mich für die Auswahl dieses doch offensichtlich verwerflichen Reviews zu flamen - dem seien die Screenshots und die ausführliche Beschreibung ans Herz gelegt. Von

Confirmation buttons show everywhere, text is spread about, the fonts size and placement is equally chaotic. I could not think of any way to make this any uglier or less friendly.

It gets worse once you hit the installation destination nonsense. You get disks represented visually. That's it. Not by their names. By identical icons with labels that refer to actual disk models. Not /dev/sda or /dev/sdb, which is what you expect. No. You get the manufacturer's model strings. And I happen to have two identical disks. So which is which? I'll give you a hint, the two disks are shown in reverse order, /dev/sdb first, /dev/sda second. What moronity.

bis

Let us not forget bad alignment, fonts and all that. And then, it says below, before continuing to the next step, but there's no next step, no buttons. Look at the lost equity. Look at the stupidity of that whole deal. If software could contract disease, it would be suffering right now from Ebola, AIDS and Typhus, all at the same time.

ist alles dabei und wird alles gezeigt.

Der geneigte Ubuntunutzer mit vagen Wissen durch Hörensagen über Fedora mag sich nun wundern: "Dass Fedora früher Probleme mit dem Installer hatte ist mir neu, woher kommen die Probleme jetzt?" Und tatsächlich ist das eine Situation, die dem kritischen Ubuntunutzer bekannt vorkommen könnte: Er wurde neu designt. Von Designern. Über einen längeren Zeitraum wurde versucht, mit geballter Designpower Anaconda einfacher, sicherer und besser zu machen - insbesondere bei Máirín Duffy habe ich das aus der Ferne von Anfang an verfolgt. Und was auf dem virtuellen Papier noch halbwegs vernünftig klang, wurde mit einer falschen Annahme hier, einer vermeintlichen Erleichterung dort und insbesondere inkonsistenter Umsetzung zu einem weithin gescholtenen Projekt, das wohl sogar das Release verzögert hat.

Java: Die unsichere Sprache

So kritisch Usability-Probleme, Machtspiele und Technologiefragen auch sein mögen - es geht immer noch kritischer. Beispielweise könnte eine Programmiersprache dafür bekannt werden, inhärent unsicher zu sein. Auf dem besten Weg ist Oracles Java-Projekt: Da nutzen Super-kritische Java-Exploits gleich zwei Bugs, und das war nicht der erste in letzter Zeit. Da bekommt selbst eine extra Webseite zum Beantworten der Frage "How Long Is It Since The Last Java Zero Day Was Discovered?" eine echte Daseinsberechtigung.

Die Propagandawirkung wird verschärft durch Oracles Hintergrund. Oracle kaufte Sun, und auch wenn Sun durchaus selbst Probleme mit der Entwicklergemeinde hatte, wurde Java in den letzten Jahren eine weitgenutzte Programmiersprache - insbesondere auch im akademischen Umfeld. Trotz all der Kritik, welche die Sprache durch ihren Boilerplate-Lastigkeit immer wieder abbekommt. Doch Oracle tat einiges dafür, weiteren Wachstumserfolg zu verhindern: Direkt wurde Google für ihre Java-Nutzung in Android verklagt, was ein äußerst interessantes API-Copyright-Urteil gegen Oracle provozierte - und viele abschreckte, Java auch nur in Betracht zu ziehen. Als ob Oracle nicht schon für seine absurde Entscheidung, Solaris proprietär zu machen, verhasst genug wäre.

Die Zero-Days-Exploits jetzt passen da nur zu gut ins Bild des eben auch unfähigen, geldgierigen und unethischen Giganten.

Und sonst?

Welches Projekt hatte noch Ärger? Um ehrlich zu sein, an Streitthemen in der Linuxgemeinde ist in den News fast immer Ubuntu beteiligt. Vielleicht habe ich ja was übersehen? Wenn ja, ab in die Kommentare damit - Ubuntu ist manchmal fürchterlich, aber das wenigstens nicht alleine.

Chrome verbieten, Zoomen zu verbieten

nospam@example.com (onli) — Thu, 14 Mar 2013 08:37:00 +0100

Seiten können mit der CSS-Anweisung

-webkit-text-size-adjust: none

verhindern, dass Texte in Chrome beim Zoomen vergrößert werden. Mir ist nicht ganz klar, warum solch ein offensichtlich Accessibility-feindliches Feature in den Browser kommt. Gutes Beispiel war dieser ansonsten interessante Artikel über Ruby 2.0 (inzwischen wurde die Seite gefixt): Egal wie weit hineingezoomt wurde, der mit 13px definitiv zu kleine Text blieb immer gleich groß - besonders ungut, weil iReader - sonst die beste Lösung für solche Fälle - den Inhalt nicht erkennt.

Wie kommt man auf solchen Unsinn? Wie auch immer, natürlich gibt es eine Lösung - mehrere sogar. Die komfortabelste ist diese Erweiterung, die -webkit-text-size-adjust einfach für alle Elemente auf auto !important setzt (via).