Nachdem auf der Team-ML der Debian Games Gruppe, in der ich zufällig mitarbeite, die Verwendung von topgit für alle git-verwalteten Pakete vorgeschlagen wurde um quilt-patches zu erzeugen habe ich mich spontan entschlossen mein Paket «xwelltris» zu konvertieren.

Der normale Weg, neue Änderungen einer Website auf den Production-Server zu übertragen führt wohl über (S)FTP oder SCP. Jedenfalls war das bei mir bis vor kurzem so.

Mit der Zeit habe ich dann angefangen, meine Arbeiten am Website Code per Versionsverwaltung zu dokumentieren. Und als dann plötzlich eine Website nicht nur von mir erstellt wurde gibg das Repos natürlich auf den Server. Da lag es dann natürlich nahe, die Serverversion einfach zu «hg clone»n.

Wie man meinem privaten Launchpad PPA ansieht verwende ich selbiges doch recht ausgiebig. Der Nutzen liegt, in meinen Augen, unter anderem darin, bereits vor dem offiziellen Release mit den aktiven Benutzern der Software auf Fehlerzuche gehen zu können.

Solchige Software könnte sonst lediglich in Debians «experimental» landen, würde das ganze aber für mich ausbremsen da mit einfach die Upload-Rechte (noch) fehlen und gerade für kleinere Projekte kann man in einem solchigen experimental-Updload auch Resourcenverschwendung sehen.

Seit gestern Abend habe ich jetzt einen SVN Zugang beim OpenANNO Projekt. OpenANNO ist (wenig verwunderlich) ein OpenSource Strategiespiel, das durch die ANNO Serie inspiriert wurde. Aktuell ist es Teil der vom Debian Games Team, in dem ich mitarbeite, beobachteten Spiele.

Während das Spiel noch in einem Zustand ist, in dem ein Upload ins Debian Archiv nur schwer denkbar ist habe ich mich bereit erklärt erste Pakete zu bauen (Bitte keine Kommentare über die Qualität, es ist mir durchaus bewusst, dass das noch weit von Debian-Standard entfernt ist).

Und es ward Zeit, etwas neues zu lernen. Diesmal LISP. Auf LISP kommt man zum Beispiel, wenn man in Python programmiert, die mächtigkeit der Python Listen erkennt und erfährt, dass es sich dabei um ein Feature handelt, das aus LISP stammt. Auf LISP kommt man auch unweigerlich, wenn man sich für Künstliche Intelligenzen interessiert.

Sogesehen hat LISP jedenfalls das Potentiel meine nächste Programmiersprache zu werden, nachdem Python schon immer mehr mein C++ verdrängt (nicht dass ich letzteres nicht mehr verwende ...). Und mit einem guten Buch kann's dann auch gleich losgehen.

Mein eigenes, kleines OpenSource Projekt, ein Spaceshooter, der -- unter Verwendung von SFML -- in C++ geschrieben ist, hat gestern eine neue Alpha Version veröffentlicht.

Wichtigstes Feature der neuen Version ist die Möglichkeit, das Spiel per Autotools ordnungsgemäß zu installieren. Bisher war leider nur ein Spielen im Source-Tree möglich. Dadurch wird es jetzt auch sinnvoll möglich ein Debian Paket zu bauen -- sollte dies Erfolg haben gibt es dieses demnächst als Download.

Freite Texturen finden kann ja nicht so schwer sein oder? Blender Nation hat ja regelmäßig neue Blogeinträge mit neuen Quellen für freie Texturen, es gibt hunderte Seiten online, ...

Wirklich freie Texturen (frei wie in DFSG zu finden ist aber in wirklichkeit viel schwerer. Denn: Was mache ich mit Texturen, die frei für kommerzielle und nicht-kommerzielle Verwendung sind (ohne weitere Erklärung)? Viele texturseiten bieten die Textur an, schließen aber Weitergabe (mit außnahme von Druckwerken) aus.

Sollte tatsächlich ein OpenSource Künstler auf diese Seite stoßen, bitte gebt uns eure Links ;)

Nachdem ich bereits über TopGIT geschrieben habe wurde diese Seite ziel einiger Google-Suchen nach dem String 'topgit'.

Da dieses Thema scheinbar eine Menge Menschen interessiert und mein Weblog unter dem Top Hits in Google erscheint habe ich dann beschlossen mein Mini-Review aus dem Debian Games Team hierher zu übernehmen. Alle Angaben beruhen auf meinen Vermutungen und erheben weder den Anspruch komplett noch richtig zu sein.

Das Original war in Englisch verfasst daher gibt es hier jetzt eine Übersetzte und überarbeitete Version davon. Wer die Debian Spezifischen Teile lesen will sei auf das Original verwiesen.

Das erste Mini-Review entstand, da ich TopGIT beim Paketieren von XWelltris ausprobiert habe und dann von einigen Menschen im Debian Games Team darum gebeten wurde.

XWelltris selbst ist kein besonders komplexes Paket und hat in Debian aktuell nur 2 Patches die mit TopGIT verwendet werden sollten. Das mitlerweile ebenfalls umgestellte SFML ist da um einiges komplexer.

Wie euch sicher noch bekannt ist, bin ich seit einiger Zeit im OpenAnno Team aktiv. OpenAnno wird wohl bald eine weitere Ergänzung zu der mitunter noch umfangsschwachen Kategorie der freien Strategiespiele darstellen.

Allerdings erwieß sich der Name «Open Anno» in mehrerlei Hinsicht als eher problematisch. Zum einen weil Open Anno zwar durch Sunflowers Anno Serie inspiriert ist, aber keinen Clon erstellen will, sondern ein eigenständiges, unabhängiges Spielkonzept verfolgt. Durch den Namen «Open Anno» wurde somit ein falscher Eindruck des Projektziels verbreitet. Weiterhin wollte das Projekt Markenrechtlichen Problemen aus dem Weg gehen, die durch die Verwendung des Names «Open Anno» entstehen könnten.

Nach einiger Diskusion konnte sich das Projekt auf den Namen «Unknown Horizons» einigen, die Website ist dann acuh gleich auf die neue Domain http://www.unknown-horizons.org/ umgezogen, die Strings im Spiel selbst sind mittlerwile auch weitgehen ausgetauscht.

Bleibt nur noch dem Projekt alles gute zu Wünschen und auf das nächste «Demo Release» Anfang März (Insider Info!) zu warten.

Unbestätigten Insiderinformationen (/me ist Teil des Teams) zufolge steht die Veröffentlichung von Unknown Horizons 2009.0 in wenigen Minuten an.

Nach über 5 Monaten Entwicklung hat das Unknown Horizons Projekt jetzt ein neues Snapshot Release in der Version 2009.0 herausgebracht. Nachdem wir heute Nachmittag Pakete gebaut und den letzten Feinschliff vollendet haben, durfte ich das neue Release im SVN tree des Projekts taggen.

Neben der Namensänderung sind jetzt auch erstmals Graphiken in einer ordentlichen Auflösung dabei, sowie eine deutlich ansprechendere Spielwelt -- keine quadratischen Inseln mehr! -- so dass die Hoffnung bleibt, dass möglichst viele Nutzer Gefallen an dem Spiel finden werden.

Eine weitere, wichtige Neuerung ist der Free Trader. Somit ist es jetzt möglich im Singleplayer Modus (Multiplayer müsste irgendwann implementiert werden) Waren zu kaufen/verkaufen.

Was hat es dann nicht in die neue Version geschafft? Leider eine ganze Menge -- das Release ist nunmal nicht zu Unrecht als Alpha gekennzeichnet. Meine Ziele für die nächste Zeit sind allerdings dann i18n/l10n, was leider von PyChans Fähigkeit abhängt Unicode Zeichen darzustellen, und saubere Installierbarkeit, sodass ich offizielle Debian Pakete bauen kann.

Wer sich für Details interessiert, der sei auf das Changelog verwiesen.

Markdown ist eine wunderbare Möglichkeit, gedanken, technische Vorschläge oder ähnliches schnell in ein halbwegs ordentlich darstellbares Format zu bringen. Das ganze lässt sich statisch in XHTML umwandeln oder per PanDOC in eine vielzahl anderer Formate. Wenn man will, kann man das auch dynamisch den Webserver erledigen lassen.

Genau das geschieht schon seit einiger Zeit auf meinem Scratchboard http://mdn.christoph-egger.org/. Das schöne daran ist die Verwaltung über Versionskontrolle (die Markdown Files werden einfach per hg push auf den Server übertragen und sind dann dort abrufbar.

Aus lauter Langeweile habe ich jetzt den Verwendeten Python Script von mod_python auf mod_wsgi portiert und aufgeräumt, sodass das ganze jetzt veröffentlicht werden kann: WSGI Script, Beispieltemplate

Viel Spass!

Nachdem der Unknopwn Horizons Server in letzter Zeit immer wieder Probleme gezeigt hat, ist das Projekt wenigstens vorübergehend hier einquartiert worden.

Das heißt natürlich, dass dieser Server deutlich höhere Lasten bewältigen muss (Unknown Horizons hat ungefär so viele Besucher, wie die andere Ladung Domains hier). Sieht aber aktuell so aus, als ob wir das bewältigen können.

Um Unknown Horizons weiter zu verbreiten habe ich jetzt ein ohloh.net Projekt angelegt und gleich noch einen Account für mich angelegt.

Ohloh lobt dann auch gleich das Projekt für ein aktives, großes Entwicklerteam und gute Dokumentation, kann also gar nicht so schlecht sein.

Ganz überrascht bin ich auch, wie weit ich es mit meinen bisherigen Projekten bereits geschafft habe ...

TODO: Einträge über NM und Debconf

Gute Nachrichten vorneweg: Debian GNU/kFreeBSD funktioniert bereits halbwegs und ist mehr oder weniger verwendbar. Zumindest für meine Zwecke. Und trotzdem wird mein Notebook vorerst weiter mit Debian GNU/linux betrieben. Ist einfach die stabilere Variante.

Das heißt jetzt natürlich nicht, kFreeBSD einfach zu ignorieren und daher habe ich eine Installation in QEMU laufen. Im folgenden ersteinmal ein paar Screenshots:

Während der X Server weitgehen funktioniert -- neueste Kernel Version vorausgesetzt und mitunter etwas nachhelfen an den HAL fdi Dateien -- ist das mit den Desktops etwas schwieriger. Fluxbox, wie oben zu sehen, funktioniert dabei einwandfre und auch awesome scheint zu funktionieren:

Während ich persönlich mit Fluxbox bisher immer ganz gut zurecht gekommen bin und mir awesome in der QEMU ziemlich gut gefällt (muss ich wohl nochmal auf dem Notebook direkt ausprobieren), ist meine erste Empfehlung an Linux Neulinge normalerweise LXDE. Und da fangen die Probleme an.

Zuerst schon lässt sich lxde, und sogar lxde-core nicht direkt installieren, nicht erfüllbare Abhängigkeiten. Glücklicherweise lässt sich das für lxde-core relativ einfach beheben: für pcmanfm ist der hal build auf nicht-Linux Architekturen (Hurd, BSD) deaktiviert. Schaltet man ihn an, baut das ganze frühlich das pcmanfm Packet.

lxpanel ist etwas komplizierter, lässt sich aber auch beheben. Das Packet hängt zwar für den Bau von libasound2-dev und libiw-dev ab, die (noch) nicht auf kFreeBSD portiert wurden, allerdings erkennt der configure script das automatisch und baut dann halt ohne. Nur das erkennen der BSD Kernels funktioniert nicht ganz, auf GlibC BSDs definiert GCC nämlich __FreeBSD_kernel__ statt __FreeBSD__. Passt man die entsprechende Zeile im Quellcode an funktioniert zumindest der Build. lxmusic müsste ich mir 'mal ansehen, auch hier gibt es unerfüllte Build-Abhängigkeiten.

Auf dem Screenshot ist schon ganz gut eines der Probleme zu sehen: Der Dekorator will irgendwie nicht so recht. Und in Live oder auf einem Video könnte man auch das zweite Phenomen erkenne: Das halbdekorierte Fenster wandert langsam immer weiter den Bildschirm hinunter.

GNOME und/oder KDE konnte ich nicht so einfach testen. Sowohl gnome-core, als auch kde4-minimal wollten sich wegen nicht erfüllter Abhängigkeiten nicht installieren lassen und für GNOME/KDE fehlt mir auch ersteinmal die Motivation etwas tiefer zu graben.

Zu guter letzt bleibt noch zsh. Hier hängt der Build auf den Debian Autobuildern im test Status. Abhilfe schafft ein lokaler Build, für den die Tests auskommentiert sind (leider unterstützt das Packet kein DEB_BUILD_OPTIONS="notest".

Jetzt steht eigentlich die Installation auf echter Hardware an, allerdings braucht der PC, den mir der Lukas freundlicherweise überlassen hat, wohl ersteinmal noch ein BIOS update um mit Linux und/oder BSD Kernels zurechtzukommen.

Für alle, die neugierig geworden sind, gibt es eine Mailing Liste und einen IRC Channel sowie (leider nicht ganz aktuelle Informationen auf Alioth.

As I really liked saying why I think Open Game Art is a good project I decided to start a small serie of well done free (well not only software) projects. This time SFML got to be the one.

SFML is, as the name already tells, a Simple and Fast Multimedia Library written in C++ but providing bindings for a whole bunch of other languages like Python, Ruby, C, D and others. Debian currently provides the original library as well as the C and Python bindings maintained by the Games Team and myself. On a side remark, SFML also uses my favourite License, zlib.

What I really like about SFML is the readable code all through the project. Every time I was unsure what some function does having a look at the actual implementation (and some OpenGL and X11) knowledge turned out to be quite satisfactory. This is, of course, aided by the fact that SFML's development is driven by a single Developer, Laurent Gomila.

On the rather weak points I'm still hoping the to-be-released 2.0 Version of SFML will introduce something like a stable API which it currently lacks (although the API has settled and there are no such huge changes as from 1.2 to 1.3 in recent updates any more). SFML also uses hand-made Makefiles for building (now supporting DESTDIR at least -- in some non-standard way) and has the usual load of embedded libraries which results in it's current load of patches.

For a nice time burner make sure you take a look at the python binding's snake-like clone. It clearly misses some important aspects to form a full game but it's nice nontheless. I have a (not-quite) small SFML based Project myself, a forward ported game from my old DirectX days, however it's unfortunately not yet playable again und rather stalled at the moment due to lack of time.

So much for SFML. If you feel like it feel free to join me on writing about well done pieces of software or just about pieces on how you think it should™ be done and tell us where you found it happening.

I'm all for security and really like encryption (my Notebook's harddrive is encrypted, I've recently got a GPG Smartcard, ...) but sometimes you see big failes where security is atemted but doesn't actually secure anything but only hinders the legitimate user.

Today one of these candidates ate way to much of my time again. I'm currently getting more and more used to GNU Emacs and currently experimenting with emacs-jabber. Therefore copying my jabber accounts over from psi. As with these passwords you never type in I couldn't remember some of my jabber passwords -- no problem psi has to store them so it should be easy to get them, right?

Well actually not. The configuration file (XML) had a password entry but all that was in it was just obviously hex-encoded numbers. These numbers turned out to be be 16bit packages of characters that are XOR-ed against the JID So now you have to read them in in junks of 16bit, XOR them against the JID and get the password.

Time to recapitulate what this security helped. I've written a hacky 10 lines C Program that can reliably retrieve passwords from any config file I might come across. Seems you can do the same in 2 lines of perl. Ergo no security at all was added.

Next question: What did it cost? Needed an hour or so of researching the encryption and trial&error out the right program fragment. For nothing gained at all. Fail.