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.

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.

Server konfigurieren ist keine einfache Angelegenheit. Soweit klar. Allerdings kann es doch immer wieder überraschend sein wie schwer es manchmal sein kann.

Dieser Server lief lange Zeit mit SuSE 10.2 -- verhältnismäßig alt, es ist schwer irgendetwas neues zu installieren und die alte Administrationssoftware für unsere Webkunden war auch nicht das wahre. Ein Update kam nicht in Frage, niemand im Team hat die Erfahrung mit SuSE im generellen und die Konfiguration war vom Anbieter voreingestellt.

LVM ist eine großartige Sache. Dynamische Volumes lassen sich jederzeit nach Bedarf vergrößern. Nie mehr raten, wie viel Platz für was nötig ist, einfach die Partitionen mitwachsen lassen.

Klingt alles nach einer netten Angelegenheit, warum also nicht für die neue USB-Festplatte verwenden? An sich eine Gute Idee. Falsch gemacht steht man allerdings schnell ratlos da.

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.

#514416 erledigt -- unfreeze vorhanden. Heißt aber auch, dass ich jetzt erstmal genug davon habe, freie Bilder, Sounds zu suchen.

Nebenbei habe ich dann auch die ein oder andere Quelle zur Freedesktop Games Team Resourcen Liste hinzugefügt. Was wohl hier noch eine gute Möglichkeit wäre, ist die Zusammenarbeit/Zusammenlegung mit Freegamedev.

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.

Open Game Art is a newly started site for exchanging free Artwork. While one can easily get the impression that there are loads of such sites around, Open Game Art is one of the very few that actually is done right.

As a Member of the Debian Games Team and the Unknown Horizons Project I was way too often in the need for good artwork searching around the web. I've also already reported once about my trouble.

There are quite some sites like Free Sounds around offering free artwork -- but only free as in beer as the saying goes, not as in speech which of course is really unhelpfull for FOSS projects. And even most of the sites that have free content often only tell you the license on some special pice of arts details page.

Open Game Art is quite different from that. All the license you may choose as a contributor are free (both in Debian and in FSF terms) and the license is available through a search filter so you can find stuff that fits you project's licensing policy. This list, and that's another thing I really like about that site, is the availability of choice among common licenses including, next to the copyleft class of licenses a fair share of more liberal licenses like my personal favourite, the zlib License.

And because such a site is just as good as it's amount and quality of data I've started sharing some recordings. I'm currently really new to audio recording so I guess it'll take some time for me to become really good. I'm considering putting some of my experiences and stuff I've learned here.

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.

Having my primary working Computer, a Lenovo Thinkpad, going into repair at the end of December I finally got up to ordering on of those TouchBook ARM based netbooks I was looking at for some time. After some processing time it finally got shipped in April and arrived here last Monday, time to write up my first impressions.

Some words about the Hardware. The TouchBook ships with a so called "Beagle Board" featuring a OMAP3 Processor, ARM Cortex A8 running at 600MHz, 512MiB of RAM and a 8GiB SD Card for storage. It has a 8.9" touch screen and comes with USB and Bluetooth Sticks for wireless connectivity. The Display part contains all the needed Hardware and is detachable from the bottom that is just a keyboard sitting on the secondary Battery. You can open the Top to get at 4 intern USBs (3 USB-A and one Mini-USB) where 2 of these spots are occupied already for wireless networking and Bluetooth.

First experience

The TouchBook comes with an US Power Adaptor only so when I got the device I was running for some tiny Adaptor to get the plug into a normal EU Power Outlet (it's incredibly hard to get one for this Direction while it's easy to get some travelling stuff to plug EU Hardware into various different Outlets!).

When I finally booted it the first thing you'll notice is the touch interface for the bootloader. That's quite a difference to all-text-based old grub! The shipped SD Card offers 3 Operating Systems, one custom Linux that might well be interesting to the average User, a Ubuntu Karmic that really OK for a Debianoid Hacker- both running a XFCE Desktop - and a Android that is really slow and doesn't seem to be good at anything. Needless to say I sticked with the Ubuntu for now.

What to not expect

Well this is a 600MHz CPU with half a Gig of RAM running of a SD Card. So don't expect it to be good at anything that can profit from today's High-End Hardware.

The good Points

First of all, I have to admit that the touch screen is a neat interface, way superior to the Touchpad Area you'll normally find on a Notebook - at least if you use the stylus. It's quite different from the inside-the-keyboard trackball the thinkpads have of course.

The Website claims 10h of Battery life and while I've emptied the battery much faster under certain workloads (e.g. Playing cards) it does hold that promise with emacs fired up in org-mode, IRCing on a server over SSH and the mandatory wireless working. Same for a always-on on campus day which just works.

Again putting the screen on the keyboard the wrong way 'round will give you a touchscreen tablet with the keyboard out of your way, an ideal configuration for playing. And I have to admit playing games like gtkballs or aisle riot real fun. So much fun actually I'm currently thinking on whether it would be feasible to get openpandora working on it.

What I'm really missing

There are two Properties that are really lacking from the device which would make it (in my personal opinion at least) a whole lot better: A simple Ethernet controller I could use to go online when sitting in the server room doing some maintenance without taking my WRT with me and some slot to store the stylus when not using it where it's easy to get out (currently I'm having it in my wallet).

Then there's something (maybe a Kernel Bug): The Wireless is unable to find any new Access Point after disconnecting from some and walking out of reach from that. Force-unloading the kernel module and waiting 30 minutes worked for me multiple times but that's purely inacceptable.

Finally there are some minor glitches. The shiny red cover just gets dirty every time you touch the thing and the Keyboard is really small (what a surprise on a 9" device) and has some of the special Keys (like the Home key) located at unusual spots (Page-Up/Down only available through the FN modifier). Shift and End at the right side are also labeled opposite from their actual function (at least on Ubuntu).

The last ugliness is the top part battery only charging when the device is running, which means you"ll have the TouchBook running all night to get the battery charged and the Battery Monitor not working at all (at least in the current version of the operating systems).

Where to go now

I've not yet come around to really play with the operating system (apart from installing wicd, urxvt-unicode and awesome getting the most needed of my working environment). As I'm a Debian Developer I'll definitely need a Debian running on it (although I was told it'll be slow with software compiled for armv4te) and, as it needs to be running all night anyway, I'll try out gentoo pending another SD Card for experiments.

Secondly there's currently no useable conforming Common Lisp Implementation in Debian for armel as far as I can tell. As arm was already working it shouldn't be that hard, let's see if I can change that but feel free to join me!

Final Notes

I was thinking of some mobile-ish note-taking device and remote ssh terminal for University which the device clearly can do even for 10h away from any power plug while being some non-standard non-x86 device to toy on (It's actually my second armel next to the sheeva plug mounted on my window board.

As a final Remark: This blogpost was written on the TouchBook hacking some markdown into emacs while traveling by train to Erlangen where I study on Sunday Night after having read some chapters of Cory Doctorow's Little Brother on my E-Slick E-Book reader and finished later in my Room.

Maybe I'll find some time to write a review for this device as well one day!