I am sure that most of you already saw (or at least heard about) how Watson from IBM competed on the TV quiz show Jeopardy. The software runs on supercomputer which consists of 10 racks of IBM POWER 750 servers (making it a cluster of 90 servers, each having 32 cores with 4 hardware threads) . The much lesser known fact is that this machine is using SUSE Linux Enterprise as its operating system. Except Linux it can also run on AIX and IBM i, but IBM has chosen SLES (probably because it has the best performance on IBM POWER7 among these options), which makes it even more cool! I wonder why Novell marketing isn’t using this great success story more!
Update: I just found this - it seems that Novell IS promoting this great success story afterall! Cool!
For those who didn’t watch the videos I include here all parts together so you can see them now (and you should!).
Last week we had a Hackweek at Novell. I decided to do something rather unusual for me - to hack a device. I bought one of these nifty LiveView devices made by Sony Ericsson, which are basically an intelligent watch that can connect to your mobile phone using Bluetooth. Unfortunately, it turned out to be rather unusable with Android devices (lots of Bluetooth disconnects), but supposedly a firmware update is on its way. After I saw that, I was somehow disappointed but I thought there must be a way how to reverse engineer a protocol and try to connect the device to my computer. I started to look around on the Internet and found a great blog by Andrew de Quincey. What was even more cool was that Andrew already did most of the job and wrote some code in Python. All I had to do is to wrap it into classes to make it more general and thus customizable. So what’s next? My dream is to create a custom open-source firmware and flash the device. I hope I can achieve this with help of hardware wizards from our Prague hackerspace. The source code is available from gitorious as usual. Do you think that Hackweek lasted only until Friday for me? Well, not really, keep reading … :-)
When I was last time in Germany, Leinir told me about an event called Global Game Jam. I liked its idea very much - 48-hour game coding marathon. I was amused when a couple of days later (just one day before the event took place) my friends Split, Lokiman and Frem told me about the Prague chapter called Game Jam Prague and invited me to join them. We decided to go there under the name they already used for a couple of their projects - Hyperbolic Magnetism aka @hypmag.
The event started on Friday evening. When we arrived, the place was already full of other teams preparing their stuff. This was very different from other (mostly open-source related) events I attend where I usually know at least a few people. Here, I knew no one except my team! :-) At around 6pm we were given a topic that should be somehow present in our game - Extinction. I was very surprised that we were able to brainstorm over 15 ideas in less than half an hour. Later we discarded most of them (because they were too obvious or too complex) and we ended up with two.
We agreed that for idea one to be successful we would need to create nice graphics and because none of us was confident enough, we decided to pick the another one where simple graphics would suffice. So we started to work on a game with the working title “Nations”. The idea was really simple: you have a couple of nations, represented by triangles (people) moving inside the circle (border). Each nation expands in time and when the circles start to overlap, triangles inside the intersection start to fight together. Moreover, if the nation is big enough, it starts to produce A-bombs which are then launched at other nations. Your task is to maintain balance between the nations, so none of them is completely destroyed. This is achieved by applying positive or negative force on some places of the game area. Positive force causes affected triangles to reproduce more, negative force causes the affected triangles to disappear. We implemented basic behaviour of the game mechanics and went to sleep on Saturday morning.
We met again on Saturday evening and we coded and tweaked and coded and tweaked … It was a long way, but at some point (I guess it must have been something around Sunday 4AM) we realised we want to change the whole game logic completely. How about we had only two types of nations - green controlled by the user and cyan ones by AI? What if player could decide to split the nation into two halves or join two nations into a bigger one? Bigger nation of course produces A-bombs faster, but is also easier to target. We replaced most of the code and I started to work on an AI, which suddenly became necessary. We worked until Sunday noon when we were finally satisfied with the result. In the meanwhile Split composed a great music track and we quickly hacked game menu, intro screen and other cosmetic stuff. That’s how it looked in the end:
I’ll attach the gameplay video to give you even better idea how the game is played:
At the end of the event all contestants judged the produced games and the first three places were announced - check the list for all other games and the result. The first team also got a very nice pacman-themed cake (which was also very tasty, thanks for sharing!). Although we didn’t make it into the Top 3, I think it was a great success for us. We tried something completely new and we also met a lot of interesting people (one of them being Antonin, author of the legendary TotalFinder). I also hope that we’d be able to finish the game and publish it into Apple App Store (and probably later into Android Market).
Finally I present you the photo of amazing Hyperbolic Magnetism shortly after we submitted our game at the end of the 48-hour session. :-)
What a cool and productive week! But let me start from the beginning …
A couple of months ago we decided to start a hackerspace in Prague called brmlab. Most of the members deal with hardware, but there are also couple of software guys like me. At the end of November we were contacted by Tomeu and he asked if they can organize GNOME Python Hackfest in our hackerspace. I was more than delighted about the idea, so we agreed and started to plan things. In the end we had 9 FOSS hackers working on GNOME and Python and I think they enjoyed their time in Prague. Hackerspace is a great concept, because these folks didn’t have to spend extra money on renting some place and our members had opportunity to meet foreign FOSS developers and try exotic hardware like OLPC XO-1.
This meeting was immediately followed by Bretzn hackfest organized by Frank. The main focus of it was implementing some of the things we agreed on previous meeting from the KDE/Qt perspective and porting MeeGo Garage to openSUSE. During it I was mainly dealing with appdata.xml format we described in the AppStream meeting - I created an XML schema so we can validate it and also developed a proof-of-concept generator of this piece of metadata in Python. (git repo) Hope we can get it in createrepo and dpkg-scan* utilities soon.
I would like to thank GNOME Foundation and Collabora for sponsoring the GNOME Python Hackfest, Novell for sponsoring the Bretzn Hackfest and Canonical, Debian, Mageia, Novell and Red Hat for sending their people to AppInstaller Meeting! It’s really nice and encouraging to see folks from various companies working on one common goal.
When ready take out the cake and let it cool down.
Put chocolate icing on the top and add some openSUSE magic.
#Oh no, wait!
There are some ingredients missing in our kitchen, ahem, I meant Factory. Currently we only have NetBeans and today I learned from Michal that it will be probably dropped as well, because some of its parts started to depend on Eclipse.
So my question is: is there anyone from our great openSUSE community who is willing to help with Java packaging? We have various related packages (Eclipse, IntelliJ Idea + their dependencies like Groovy or Maven) spread around various places in the Build Service (e.g. home:lkundrak:IDEA, Java:eclipse:Devel), but we would like to have them fixed and pushed to our devel project for Factory - Java:packages. This is the first and necessary step for including these tools into you beloved distribution. Some of the packages are probably obsolete so it might be better to get inspiration directly at our Fedora friends (you can use this package list and a little helper script to peek how do they do it). If you are interested in this, please do so! We will try to help you on opensuse-java mailing list or #opensuse-java IRC channel on Freenode.
Oh, I almost forgot one thing. The most active Java packager will get an openSUSE coffee cake done by yours truly and the openSUSE Boosters! :-)
For those of you who haven’t met pkg-config yet a short introduction from its project page:
“pkg-config is a helper tool used when compiling applications and libraries. It helps you insert the correct compiler options on the command line so an application can use gcc -o test test.c pkg-config --libs --cflags glib-2.0 for instance, rather than hard-coding values on where to find glib (or other libraries). It is language-agnostic, so it can be used for defining the location of documentation tools, for instance.”
More and more projects are using pkg-config already, but there is still a very high number of projects that don’t. This post tries to describe why using pkg-config is a good idea.
We try to build software packages for all major Linux distributions in the Build Service. Unfortunately there are lots differences in package names. Let’s take a look at KDE 4 development library for example:
Confusing, right? When I want to build a KDE application in the Build Service for all these distributions I have to use conditionals, which clutters the spec file. What’s even worse is that I have to actually find out these names, which is not always an easy task.
RPM has a nice feature: if a file /usr/lib/pkgconfig/foo.pc or /usr/share/pkgconfig/foo.pc exists in the package, rpmbuild adds a pkgconfig(foo) provides symbol. But what does that mean effectively?
We don’t have to require a particular package name in the list of build requirements. We just specify pkgconfig symbol instead. Once we have replaced all of these … Crash, boom, bang - cross-distro packaging made easy! What’s even more great is that it would be possible to write tools that are able to auto-generate build requirements in the spec files by simple detection of pkgconfig symbols in configure, qmake, cmake, whatever build scripts.
The most packaging headaches are caused by libraries, but often we use some utilities during the build as well. Fortunately, they tend to have the same name across distributions - e.g. desktop-file-utils, so it probably does not make sense to use pkgconfig everywhere.
I talked with lots of people at the openSUSE Conference and all are in favor of pkg-config usage. I would like to encourage everyone in the FOSS community to include pkgconfig files in their releases and even help others doing so! For example, the distribution package maintainers could create these files and send them to upstream. I will try to push a new rpmlint check into openSUSE, which will print warning (if the package contains a library without pkgconfig file) and a link how to add a proper one to the package.