Linux

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.

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.

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.

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.

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.

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:

1. 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).
2. 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.
3. exec ersetzt execute.
4. Man beachte den zusätzlichen |results|-Zwischenschritt.
5. (Nicht im Code) Postgresql beherrscht kein INSERT OR REPLACE. Stattdessen erst ein UPDATE, dann ein INSERT ausführen.
6. Die Parameterersetzung hat eine andere Syntax: $X statt ? und Übergabe eines einzelnen Arrays statt der einzelnen Argumente.
7. 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.

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

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.

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.

zu

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.

Wenn mich eine Sache an Geany störte, dann ist es das fehlerhafte Copy&Paste-Verhalten: Markierter Text wird aus dem Clipboard gelöscht, sobald der Cursor woanders hin bewegt wird, sodass Einfügen per mittlerer Maustaste anders als in jeder anderen Linuxanwendung nicht richtig funktioniert (ratet mal, in welchem Bugtracker seit 7 Jahren ein entsprechender Bug offen ist? Korrekt, Gnomes, genauer gtk+).

Die Lösung: Das Paket xfce4-clipman installieren und den gleichlautenden Befehl ausführen, am besten in den Autostart packen. Zumindest Geany funktioniert nun richtig, und auch andere defekte Programme sollten das Problem jetzt nicht mehr haben.

Ich programmiere lieber in einem Editor als in einer IDE. Und grundsätzlich darf ein Editor für mich so schlicht wie möglich sein - obwohl ich eine Weile emacs benutzt habe, was mir irgendwann zu kompliziert wurde. Genausowenig halte ich von vim und den absurden Tastaturverrenkungen dort (im Terminal meine Wahl: nano).

Aber Geany hat mich getäuscht und so langsam an einige Funktionen herangeführt, die ein einfacher Editor nicht hat. Beim ersten Ausprobieren gefiel mir Geany, weil es mir editorartig direkt den Text präsentierte - das Pluginsystem und integrierte Terminal konnte ich erst ignorieren, später deaktivieren. Die Tastaturbelegung war mir zugänglich, da standardkonform, und weil ich zu der Zeit gerade Eclipse nutzen musste, war die Funktions- und (inzwischen deaktivierte) Dateiübersicht - als IDE-Feature im vermeintlich schlichten Editor - auch kein Grund zur Verwunderung. Die Oberfläche lässt sich gut anpassen, so sieht meine inzwischen wirklich schlicht aus:

Trotzdem, Geany ist mehr als ein einfacher Editor. Und einige fortgeschrittenere Funktionen haben sich im Laufe der Zeit dann doch als praktisch herausgestellt:

Column select

Mit "Shift + Alt + Pfeiltaste" kann Text spaltenweise markiert werden. Meine Quelle zeigt dafür ein schönes Beispiel: Will man aus einer Liste

/home/abc/*
/home/abc/*

jeweils das /home/\w+/ entfernen, könnte man so den entsprechenden Teil markieren und löschen. Vorausgesetzt die Länge ist immer gleich. Nicht so schön wie die Sublime-Multicursor-Funktion und zugegeben selten benutzt, aber trotzdem gelegentlich praktisch.

Markierung setzen und hinspringen

Relativ oft arbeite ich in einer Datei an mindestens zwei Stellen gleichzeitig. Ist die Datei relativ klein ist das kein Problem, und ich versuche inzwischen wirklich, die LoC möglichst gering zu halten. Doch ist es ein fremdes Projekt oder auch ein älteres Serendipity-Plugin von mir (die Serendipity-Plugin-Struktur führte bei mir zu organisch wachsenden Ein-Datei-Codebasen, so hat die serendipity_event_spamblock_bayes.php immerhin 2000 Zeilen, und das ist bereits die smartifizierte Version), wird das schnell übersichtlich. Jeweils eine Markierung setzen und zwischen denen hin- und herspringen ist eine Funktion, die ich mir gewünscht habe bevor ich sie kannte: Auf den Rand neben der Zeilennummer die Markierung setzen, dann mit "Strg + ," oder "Strg + ." zur nächsten Markierung rauf- bzw runterspringen. Anker für Code, von mir noch zu selten benutzt.

Zeilen duplizieren

Simpel: Ein "Strg+d" (ich hoffe, das ist die Defaultbelegung) fügt unter dem Cursor die Zeile ein, in welcher der Cursor gerade ist. Ist jedoch Text markiert, wird der markierte Text hinter den Cursor kopiert. Der Cursor bleibt jeweils genau da, wo er ist. Eine der simplen Funktionen, die ich unter Eclipse praktisch fand und später vermisste habe, und deren Ausgestaltung unter Geany mir gut gefällt.

Absatz formatieren

Bei Code hat das keinen Effekt, aber ich fand es praktisch als ich an Latex-Dokumenten gearbeitet habe: Mit "Strg+j" wird der momentane Absatz entsprechend der Zeilenlängenvorgabe umgebrochen. Verhindert, immer wieder Enter zu drücken weil die Zeile zu lang wird und das so manuell zu machen.

Suchen- und Ersetzen

Code muss manchmal überarbeitet werden, und Kleinkram wie automatische und codeweite Variablenumbenennung ist eine Stärke klassischer IDEs. Mit dem Suchen- und Ersetzen-Dialog, aufrufbar per "Strg+h", kann Geany das auch, sogar mit Regexpressions, also für wesentlich mehr als nur einfache Variablenumbennungen geeignet. Dateiweise oder in allen geöffneten Dokumenten, schrittweise oder alle auf einmal, und wenn schrittweise, dann in unterschiedlichen Tempi - ich nutze immer noch manchmal sed für sowas, aber Geanys Funktion ist mächtig und nützlich genug, um sed desöfteren zu ersetzen. Und die Änderung schrittweise durchzuführen und so in der GUI prüfen zu können vermeidet Fehler.

Zusätzlich beherrscht Geany eine gut funktionierende Syntaxvervollständigung, die erwähnte Funktionenübersicht erweist sich immer wieder als praktisch, und wenn man wollte, könnte man mit dem Pluginsystem und dem Terminal sicher etwas anfangen. Man kann Geany aber auch als simplen Editor ohne weitere Fähigkeiten nutzen - er lädt schnell genug, um problemlos mal schnell eine Config-Datei anzupassen. Was man über Eclipse nicht gerade sagen kann.

Liebe UU-Planetenleser, hier gibt es nichts zu sehen ;)

Den OSBN-Bloggern und Lesern möchte ich jedoch hiermit Hallo sagen, und testen ob die Feedeinbindung funktioniert.

onli blogging existiert seit Anfang 2008. Ich halte hier Dinge fest, die ich später wiederfinden will und versuche zu teilen, was mich interessiert - also findet sich hier Spielereview neben Codeschnipsel neben Vorstellungen von eigenen Programmen, oder was auch immer gerade meine Aufmerksamkeit fesselt. Nur von Politikthemen halte ich mich inzwischen fern.

In OSBN wird nur der Linux-Feed eingebunden, genauso wie im UU-Planeten, so sollte das thematisch immer passen.

Compton ist ein auf xcompmgr basierender Compositor, der aktiv weiterentwickelt wird und einige nette Features wie automatische Transparenz für inaktive Fenster mitbringt. Damit ist er derzeit die einzige Wahl, will man einen relativ bugfreien Compositor benutzen (der nicht in einem Fenstermanager integriert ist).

Allerdings liegt es nicht in den Quellen, compton muss selbst kompiliert werden.

Was noch fehlt ist Feinschliff. So haben Ubuntus Notify-OSD-Benachrichtigungen einen hässlichen weißen Schatten/Rahmen, genauso Simdock. Doch kann das mit ein paar Konfigurationseinstellungen gefixt werden:

shadow-exclude = [ "n:e:Notification" , "class_g ?= 'Notify-osd'"];

behebt den Schatten der Benachrigungen (via)

shadow-ignore-shaped = true;

half bei Simdock

Edit: Leider funktioniert das nicht zuverlässig, besser bewährt sich ein

wintypes:
{
  dock = { shadow = false; };
};

Hier meine gesamte Konfigurationsdatei ~/.compton.conf (fast identisch zur Beispielkonfiguration):

# Shadow
shadow = true;
no-dnd-shadow = true;
no-dock-shadow = true;
clear-shadow = true;
shadow-radius = 7;
shadow-offset-x = -7;
shadow-offset-y = -7;
# shadow-opacity = 0.7;
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;
shadow-exclude = [ "n:e:Notification" , "class_g ?= 'Notify-osd'"];
# shadow-exclude = "n:e:Notification";
shadow-ignore-shaped = true;

# Opacity
menu-opacity = 0.9;
inactive-opacity = 0.8;
frame-opacity = 0.7;
inactive-opacity-override = false;
alpha-step = 0.06;

# Fading
fading = true;
# fade-delta = 30;
fade-in-step = 0.03;
fade-out-step = 0.03;
# no-fading-openclose = true;

# Other
mark-wmwin-focused = true;
mark-ovredir-focused = true;
use-ewmh-active-win = false;
detect-rounded-corners = true;
detect-client-opacity = true;
refresh-rate = 0;
vsync = "none";
dbe = false;
paint-on-overlay = false;
sw-opti = false;

# Window type settings
wintypes:
{
  tooltip = { fade = true; shadow = false; opacity = 0.75; };
  dock = { shadow = false; };
};

Der Timeout von Grub 2, also dass nach x Sekunden automatisch der Standardeintrag gestartet wird, funktionierte bei mir nicht zuverlässig. Manchmal startete der Timeout einfach nicht. Und tatsächlich hat Grub 2 einen Mechanismus, diesen Autoboot zu deaktivieren, wenn der letzte Boot nicht erfolgreich war - was mittels eines Boot-Skriptes festgestellt wird, über das ich beim Aufräumen gestolpert bin.

Nun ärgerte mich das schon eine Weile, weil jetzt nicht mehr zuverlässig mein Linux gestartet wurde. Ich weiß nicht, ob das am häufigeren Starten von Windows lag oder ob das Skript nicht zuverlässig funktionierte, aber der fehlende Timeout fiel mir erst seit kurzem auf.

Natürlich kann man den Autostart immer ausführen lassen. In der /boot/grub/grub.cfg steht in Zeile 59 dieser Code:

if [ ${recordfail} = 1 ]; then
    set timeout=-1
else
    set timeout=10
fi

Die Abfrage kann ersetzt werden durch:

set timeout=10

Der richtige Ort, um das persistent zu machen, ist wohl die make_timeout-Funktion in /etc/grub.d/00_header.

PS: Wenn ich mir diese "Konfigurationsdatei" so ansehe, die ein einziges Bashskript-Wirrwarr ist, freue ich mich fast auf UEFI und die dadurch ausgelöste Bewegung bei den Booloadern. Grub 2 ist ein Moloch. Warum sollte ein Bootloader keine normale ini/tom/sonstige-einfach-lesbare Konfiguration haben?

Für heute hatte ich einen schönen Vorsatz: Finde einen Ersatz für Simdock, damit du das Projekt aufgeben kannst. Ich bin gescheitert.

Meine Anforderungen an ein Dock sind ziemlich simpel:

• Icons für gestartete Programme und Programmstarter anzeigen
• Diese minimieren können
• Mit Mittelklick neue Instanzen starten
• Einfache Konfiguration (eigentlich nur wichtig: "Im Panel behalten" als Option haben)
• Transparenz unterstützen

Nun ist es natürlich nicht so, dass es kein anderes Programm gäbe, das dem im Grunde gerecht wird. Aber alle scheitern an der Transparenz - bzw am Zusammenspiel mit compton.

Als mögliche Alternative zu Simdock kenne ich diese Programme:

1. Plank
2. Wbar
3. Avant-Window-Navigator
4. Cairo-Dock (Glx-Dock)

Insbesondere Plank ist ein guter Kandidat, Simdock zu ersetzen: Ähnlich schlicht, aktiver entwickelt und mit allen notwendigen und zusätzlich einer Autohide-Funktion. Der einzige Nachteil wäre, dass es keine Pseudotransparenz zu unterstützen scheint. Und ich mag Simdocks Feature, das Programmicon im Dock mit dem Fenstericon zu updaten, was Plank ebenfalls nicht zu können scheint, aber das wäre kein Ausschlusskriterium.

Doch trotzdem funktionieren weder Plank noch die anderen Docks für mich. Wbar ist generell kaputt, die Icons schlieren und es scheint keine Menüs zu haben. Die anderen drei kommen mit compton/xcompmgr nicht zurecht. Hier die Bilder:

Plank

AWN

Cairo-Dock

Sie alle scheitern daran, bei aktiviertem Compositor Transparenz so zu aktivieren, dass der leere Bereich echt transparent ist, bzw bei AWN an der Transparenz des Iconhintergrunds. Dies ist das gleiche Problem, welches ich damals schon hatte und mich überhaupt zum Schrauben am verlassenen Simdock bewegt hat. Damals war es allerdings eine andere Ubuntuversion und andere Hardware, ich habe nicht damit gerechnet, dass das Problem noch existiert.

Hintergrund

Ein Dock muss eigentlich keine echte Transparenz per Compositor unterstützen, da es sowieso nie Fenster hinter sich hat. Die Ausnahme dieser Regel ist die Autohide-Funktion: Wenn das Dock von Vollbild-Fenstern verdrängt wird und vom Bildschirmrand aus über das Vollbild-Fenster fährt, wenn es aktiviert wird. Plank verhält sich so und das ist eigentlich ein schönes Feature.

Ein Dock mit Autohide-Funktion kann also eine Compositor-Funktion gut gebrauchen, ein Dock ohne (wie Simdock) kann probemlos darauf verzichten.

Warum aber ist der schwarze Balken so viel größer als die Docks selbst, was ist der leere Bereich? Ich bin darauf gestoßen, als ich an Simdock gearbeitet habe. Grundsätzlich will ein Dock gerne in Bereiche zeichnen, die erstmal nicht direkt zum Dock gehörig sind. Beispielsweise den Programmnamen in einem Tooltip über den Icons anzeigen oder die Icons nach oben hüpfen lassen, aber ohne den Bereich für sich zu beanspruchen. Ohne in den Code geschaut zu haben gehe ich davon aus, dass Plank und Cairo-Dock sich einen entsprechend großen Bereich als Canvas sichern.

Das wollte ich für Simdock übrigens auch machen, zusätzlich zum bestehenden Fenster mit einer hübschen dafür gedachten Funktion, das hat aber ein wxWidget-Bug verhindert (es hatte schlicht keinen Effekt).

Es scheint nun so, als ob im Zusammenspiel mit AMD-Grafikkartentreibern und xcompmgr/compton die in diesen Docks verwendete Transparenz nicht funktioniert und der von ihnen registrierte Canvasbereich davon ebenfalls betroffen ist.

Simdocks Status

Das soll nicht heißen, dass Simdocks den anderen Docks grundsätzlich überlegen ist - ich bin im Gegenteil überzeugt davon, dass Plank in vielen Fällen eine bessere Wahl ist. Der Vorteil in diesem Fall rührt einfach aus der Beschränkung Simdocks auf Pseudotransparenz - der von Simdock verdeckte Bildschirmhintergrund wird per XServer-Funktion als Bild geholt und hinten eingefügt, was unabhängig vom Compositor zuverlässig zu funktionieren scheint.

Auf Simdocks Seite steht:

• Funktionierende Transparenz
• Menü mit ein paar grundlegenden Einstellungen
• Aktualisierung des Programmicons (wichtig bei Programmen mit Startern, wie Eclipse)
• "Im Starter behalten"-Funktion, zyklisches Minimieren und Öffnen der einzelnen Programmfenster, Instanzenstart per mittlerem Klick

Das sind rein zufällig die grundlegenden Features, die ich gerne in einem Dock hätte.

Gegen Simdock spricht natürlich auch einiges. Zum einen wird es nicht aktiv weiterentwickelt. Ich habe anfangs eingebaut, was ich haben wollte, und danach noch einzelne Bugs gefixt, aber bisher war es das. Zum anderen wird es wenn, dann von mir entwickelt. Das ist von Nachteil, weil ich normalerweise nicht an C++-Programmen arbeite - so gibt es immer noch einen Bug, der manchmal zu Abstürzen führt, der kein mir ersichtliches Schema hat und daher nicht von mir nachstellbar und fixbar ist. Und ich bin durch die nötige Speicherverwaltung schlicht daran gescheitert, Einstellungen on-the-fly übernehmen zu lassen (jemand Lust, mir einen entsprechenden Pull-Request zukommen zu lassen?). Außerdem ist die ganze Library- und Build-Umgebung unter C++ ein für mich schwer durchschaubares Wirrwarr und müsste sicher aufgeräumt werden.

Trotzdem: Für die eigene Desktopumgebung scheint Simdock derzeit meine einzige Wahl zu sein, will ich einen Compositor mit meiner AMD-Grafikkarte nutzen. Oder kennt jemand noch eine von mir übersehene Alternative?