Blog
Source Code Formatting, License Flamewars and Build System Issues
Tabs vs. Spaces
One of those never ending issues with source code formatting is the use of tab vs. spaces. People seem to blindly argue for one or the other while not realizing that the best solution is to combine them in a smart way. That is, use tabs for indention and spaces for further alignment:
--->if (some_variable) {
--->--->long_function_name(first_argument,
--->--->...................second_argument);
--->}
This way everyone can set the tabwidth to whatever he likes and the code will still look decent.
License Flamewars
As soon as i finished reading the mail containing a trivial ~10 line patch which was originally licensed under the GPLv3 for an otherwise MIT/X11 licensed program i knew this would result in a _huge_ license flamewar. My opinion on this is pretty clear: whoever writes most of the code should decide it's license. It could be so fucking simple but it seems like people like to waste their time by arguing over the same things over and over. Oh well.
Build System Issues
It turned out that the new dvtm-0.4.1 release has a problem in it's build system which results in a breakage on the debian server infrastructure. I changed an assignment in config.mk from = to += in order to provide an easier way to add extra flags. But because GNU make has a concept of different flavors of variables this doesn't quite work as expected.
The problem is that the behaviour of += depends on the variable type it's applied to. If it's used on a variable which wasn't previously defined it acts just like normal `=': it defines a recursively-expanded variable. This means it's value is referenced and recalculated whenever the variable is accessed. This is most often the case and the world is a happy place. However on the debian build infrastructure it seems like the LDFLAGS variable is predefined somewhere as a simply expanded variable which means it's calculated ones upon definition. My make file is then called recursively and the value is appended again which results in a binary which is linked against both libncurses *and* libncursesw which obviously doesn't work.
I actually prefer simple make files as build system when ever possible because it should be simple, get the job done without to many dirty tricks and don't waste valuable developer time. But it seems like you can shoot yourself in the foot pretty easily with Makefiles, Sigh. And no autohell is not the solution, it's the problem ;)
Package management dependency resolution algorithms
I am playing with the idea of writing my own package management tool which could replace opkg on my ordered Freerunner once it arrives here. The last time i looked at opkg (it was actually still called ipkg then) it's code was rather messy and contained things which i actually wouldn't need. I would also like to have pluggable backends. This would ease experimentation with something like sqlite. An integration with a SCM to provide rollbacks would probably also be interesting although maybe a bit overkill for a mobile device.
Anyway i am interested in the dependency resolution algorithms of existing package managers like apt, yum or smart. Unfortunately google didn't really help me so far and digging through a pile of C++ code in case of apt doesn't sound like too much fun.
As i won't have that much free time in the near feature it should probably also reconsider helping in cleaning up opkg.
We will see what the future brings.
Marc
ciopfs - case insensitive on purpose file system
Some time ago i saw Wine's Google Summer of Code ideas as i know nearly nothing about the Windows pre .NET core APIs and have _zero_ interest in learning it most projects weren't of interest for me. However one idea about a case insensitive filesystem seamed like it would be fun to hack on.
The problem that wine has is that the file system on windows is case insensitive while most POSIX file systems are case sensitive. In order to find a given file by a case insensitive file name wine does currently scan directories a lot and this is actually quite slow. So the idea is to let the file system deal with the whole mess. This would also solve the problem where a user extracts a zip archive over an already existing directory tree and expects that the files will be replaced instead of created with different case.
So i wrote a FUSE based case insensitive file system: ciopfs was born. Unfortunately the wine developers don't seem to be too interested and so it probably won't go anywhere in the near future but it was nonetheless fun to play with FUSE and maybe it will be useful for someone out there.
Marc
SkiFree on Wine
Today i stumbled by accident over SkiFree a game which i played ocasionally as a child during my early PC days.
I tried to run it via wine and it worked as advertised on the homepage.
Nostalgic times come up...
Marc
OpenExpo 2008 in Bern
So i finally found some time to blog about the OpenExpo which i visited last Thursday. To make it short, it was great fun. Highlights were the talk of Alan Cox about practices and processes within the Linux community, while there wasn't really anything new for myself it was nonetheless fun to be there .
OpenMoko
Another interesting presentation was given by Michael Lauer about the current state of OpenMoko. He promised that the Freeruner will be available real soon now(tm) which probably means in 2-3 months. I spent quite a bit of time with the OpenMoko people playing around with the prototypes (this was the first time i have had the oportunity to get my hands on the devices). Tried the gtk+ based gui, Qtopia and an EFL based demo application they were showing. Since Raster is now working for OpenMoko i expect lots of cool stuff in this direction. Asked them why they were using glibc instead of uclibc and the reason is that they don't really care about the space gains because throwing more flash onto the device is cheaper than dealing with glibc incompatibilities. This is understandable from a business point of view but it is nonetheless a bit sad from a technical point of view which i am obviously more interested in. Another topic i asked about was opkg the package manager which is currently ipkg (which is unmaintained) + a few patches which remove a lot of crap and add a few features. I once looked at the ipkg code and i can only warn you it still hurts. So i am not sure if ipkg is a suitable starting point for a sane and lightweight package management system. But again from a business point of view it might be cheaper to improve on what is already there instead of doing it the right way(tm) from scratch. This would actually be a fun project but unfortunately i am a bit busy with other things right now. Another thing i asked was whether they were considering rendering directly to the framebuffer instead of going through X. But they prefer flexibility over raw performance. For example the ability to display application from your phone on your desktop, things like VNC, the fact that you can use applications from different toolkits and reuse existing development knowledge led to this decision. Another thing is that the directfb backend of gtk+ isn't really maintained (at least that's what they told me).
Anyway it is a great project and will buy a Freerunner as soon as it's available.
dvtm packaging
As there were also various people from different linux distributions there i asked about getting dvtm into their package repositories. dvtm is already in Debian, this left Fedora and Gentoo which both had a booth. The Gentoo devs were looking at the package and it's now in the Gentoo Sunrise User Overlay. I have given my mail address to the Fedora guys and hope they will get in touch with me.
Having a few drinks with Alan Cox
When the exposition closed, a few people were going to have a drink so i followed them and ended up with Alan Cox, 3 members of the Ubuntu Swiss Team, 2 Amarok and a Gentoo developer in a nice cafeteria. Topics that came up were i hadn't really something useful to contribute were, differences and similarities between various languages (with Alan as an English and Welsh expert) and computer based creation of modern pop music. It got a bit more interesting for myself when the discusion shifted to different programming languages and their suitability as a teaching tool. People complaining about Sheme, Eiffel, Lisp, Pascal, C++ (yeah Amarok is written in C++, hopefully a suitable subset of it) and so on. Alan doesn't seem to like perl, i should probably have mentioned that the latest 2.6.25-rc kernel requires perl in order to build it, which sucks big time! You now your out with geeks when suddenly someone starts to write code on a the carton saucer to show the beauty of Ruby. Alan showed off a C snippet with a combination of single line (//) and multiline /* */ comments which shows different results depending on the compiler (C vs. C++). I mentioned Fabrice Bellards tinycc compiler and noted that he won the IOCCC two times in a row. Alan agreed that he is a very bright guy but said that Fabrice could win another time with parts of Qemu.
Anyway this is getting way too long, it was great fun and i will almost certainly be there next time. Unfortunately i forgot my digital camera at home so i have no pics to share.
Marc
My list of things which sucked the most during last week
Last week was really awful, below are some things which sucked in no particular order:
- being sick on my birthday
- tacking a math exam while being sick (if i had missed the test, i would have to do a semester test which sucks even more)
- fixing stupid bugs in horrible java code at work (while beeing sick)
- having to deal with stupid MS Office issues at work (while beeing sick)
Ok the last two items actually also hurt when you are healthy. On the plus side i can note: Having a girlfriend who makes sure i get better and don't waste too much time on lwn.net, kerneltrap.org, various mailing list archives or some other geek sites.
Anyway next week can only be better especially as i will be at the OpenExpo in Bern on thursday.
Marc
