2008-05-30 digital life Nun habe ich doch geforked Hintergründe Seit eineinhalb Jahren verwende ich den dynamic window manager (dwm) [0]. Damals hat der Fund dieses Projekts meine lange Suche nach einem passenden Window-Manager beendet. Erstaunlich ist da- bei, dass ich innerhalb ein paar Tagen, vollkommen davon überzeugt war, dass dwm der letzte Window-Manager sein würde, den ich verwende. So ist es noch immer (fast). Anselm R. Garbe hat mit dwm nur vier Monate vorher begonnen, be- vor ich auf ihn gestoßen bin. Seit damals lese ich die Mail- ingliste und verfolge so die Entwicklung. Natürlich verwende ich ihn seither auch ausschließlich. Da dwm zum personalisieren ist, habe ich ihn natürlich auch an meine Bedürfnisse angepasst. Üblich ist es, seine Änderungen als Patches zu veröffentlichen. Dies habe ich natürlich auch getan. (dwm-meillo [1]) dwm ist schon seit mindestens Version 2.1 (November 2006, als ich begonnen habe) zu 80% Funktions-komplett. Seit damals wird eingentlich nur noch an den sonstigen Features rumdiskutiert/- probiert und der Code hin und her refactored. Ich habe schrittweise auf Version 4.4.1 und schließlich 4.9 up- gegraded. Dabei sind meine Anpassungen immer die gleichen gewesen -- ich musste sie lediglich unterschiedlich implemen- tieren. Falls man die neuen Features nicht nutzt und nicht aktiv mi- tentwickelt, muss man eigentlich gar nicht upgraden. Jedes Release ist stabil. Ich habe vor allem aus spontaner Lust und um nicht allzu sehr zu veralten upgegraded. Die Version 4.9 war dabei eher enttäuschend. Zwar wurde mein Patch kleiner, jedoch fühlte sich der Window-Manager zunehmend groß, komplex und inkonsistent an. Früher zeichnete sich dwm durch genau gegensätzliche Eingenschaften aus. Um es klar zu machen: dwm-4.9 ist immer noch klein, simpel und konzeptionell klasse. Nur seine eigenen früheren Versionen sind noch besser. Inzwischen wurde dieser Trend zu Featuritis, Bloat und Inkon- sistenz auf der Mailingliste diskutiert und es wurde allgemein der Wunsch laut, zur Einfachheit zurückzukehren. Release 5.0 soll diesen Schritt zeigen. Ich bin schon seit einiger Zeit der Meinung, dass dwm "fertig" ist, und weiteres Rumarbeiten ihn nicht besser macht. Man muss wissen, wann etwas fertig ist -- dieses Wissen ist eine der wichtigsten Fähigkeiten für Künstler, und es passt auch hier. Anselm kündigt zwar schon länger an, dass er dwm ein Stück auf die Seite legen will, um sich stärker um `st', seinen Terminal- Emulator, zu kümmern. (`st' wird von der Community bereits heiß erwartet.) Leider schafft es Anselm wohl nicht, genau dies zu tun. Ich hoffe dies ändert sich bald ... es wäre für alle das beste. Ich habe mir mal gesagt, dass ich versuchen will, meinen Patch möglichst klein zu halten. Ich strebe also an, mit so wenig Änderungen wie nötig, die von mir gewünschte Funktionalität bei dwm zu erzeugen. (Nur Shortcuts werde ich großzügig anpassen/entfernen.) So wollte ich es einfach machen, meinen Patch auf neue Versionen anzupassen. Vor einigen Tagen erst habe ich diese Vorgehensweise Azerty (ein Internetbekannter) erklärt. Ich habe ihm auch gesagt, dass ich in dwm die perfekte Basis für einen Window-Manager sehe. Ob es nun dwm selbst, oder ein Fork auf seiner Basis (vor allem konzep- tuell) ist, ist dabei nicht von Bedeutung. An dieser Ansicht hat sich seit meinem ersten Kontakt bis jetzt nichts geändert ... ich ich glaube, dass dies auch die nächste Zeit so bleiben wird. Was sich (ausgelöst durch dwm-4.9) geändert hat, ist meine Bewer- tung der beiden Wege. (Was ein schlechtes Release doch für Auswirkungen haben kann!!) Nachdem mich das Thema in den letzten Tagen nicht losgelassen hatte, war es Gestern Nacht so weit: Eigentlich wollte ich einen Film schauen (Alfred Hitchcock: "The man who knew too much" von 1934), aber nach vielleicht 20 Minuten packte es mich dann doch. Ich war mit Gedanken sowieso nicht recht beim Film. So beendete ich diesen, wechselte in die Shell, kopierte die Codebasis von dwm-4.4.1 (die gefiel mir ganz gut) und begann zu hacken. Etwa drei Stunden später (gegen halb eins), hatte ich den Code durchgeackert, angepasst und um gut ein Viertel gekürzt. Es gibt jetzt nur noch zwei Workspaces - einen für getaggte Fenster, den anderen für ungetaggte. Damit müsste das Konzept in etwa dem von dem Experiment `2wm' entsprechen. (Ich habe 2wm allerdings nie selbst getestet.) Das Ergebnis ist schon brauchbar und fühlt sich klasse an! Aber es gibt noch einiges zu tun. Dazu gehört, den Code komplett ver- standen und umfassend meinem Konzept angepasst zu haben, denn bisher sind die meisten Änderungen eher punktuell. Weshalb habe ich überhaupt geforked? Bis jetzt habe ich einen Patch maintained, und das ist die Vorgehensweise, die in Freier Software üblich sein sollte. Durch sie bleibt die Arbeitskraft der Community weiterhin gebündelt und doch kann jeder die Viel- falt haben, die er sich wünscht. Forken, also von einem bes- timmten Codestand abzuspalten und in eine andere Richtung weiter entwickeln, teilt die Community und damit die Leistungsfähigkeit (im Allgemeinen). Abgeschwächt werden kann ein Fork durch gegen- seitigen Ideen- und Codeaustausch zwischen den beiden Ästen. So fließen zum Beispiel manche Lösungskonzepte von `awesome' (ein "besserer" dwm) und `xmonad' (ein dwm in haskell) in dwm zurück. Bisher war mein Ziel, den dwm mit möglichst wenig Aufwand an meine Bedürfnisse anzupassen. Nun ist es so, dass ich dwm nicht upgraden muss (und eher auch nicht will). Damit wird das Argu- ment des einfacheren Upgrades (durch den kleinen Patch) wertlos. Wenn ich aber sowieso auf einer bestimmten Version bleibe, dann kann ich auch mehr Aufwand (der mir Vergnügen bereitet) inves- tieren, um die Anpassung besser zu machen. Der Knackpunkt ist die Frage, ob es einen Unterschied macht, ob intern allerlei Zeug ist, das ich nicht brauche und das man von außen kaum bemerkt; oder ob das Konzept intern ebenfalls der äußeren Form entspricht. Für den User ist das wohl kein Unterschied. Für mich als Pro- grammierer ist es aber einer ... ein Unterschied im Gefühl, das ich bei der Benutzung habe. Ich werde zukünftig abseits des Weges von dwm an meinem Fork (basierend auf dwm-4.4.1) weiter entwickeln (falls überhaupt). Die dwm-Entwicklung werde ich natürlich trotzdem weiter verfol- gen, denn ich sehe meinen Fork immer noch als einen dwm-Window- Manager an. (Ob ich ihn immer noch "dwm-meillo" (symbosisierend für die dwm-Abstammung), oder "aewl" (ein neuer Name für ein neues Program) nennen werde, habe ich noch nicht entschieden.) dwm ist mehr als ein Window-Manager. Es ist ein suckless-Projekt [2], es ist eine Community, ein Entwicklungskonzept, ein erfol- greiches Experiment ... und nicht zuletzt ist es "Anselms Window Manager"! Ich spreche Anselm meinen vollen Respekt aus -- danke für dwm, die suckless-Community und alles was du bei mir und dem Rest der Welt bewirkt hast. Entschuldige auch, dass ich dwm forke ... aber sei beruhigt, es wird keine großen Auswirkungen haben, denn soweit mir bekannt ist, hat niemand außer mir selbst Interesse an meinem dwm-meillo. :-) [0] http://dwm.suckless.org [1] http://prog.marmaro.de/dwm-meillo [2] http://suckless.org http://marmaro.de/apov/ markus schnalke