Published: 27 April, 2011 - 10:13
According to Notch, Minecraft is moving to an Android-like model for its mods development. You will be able to sign up for free, accept a license, and get access to the complete source code via SVN (one can tell these aren't F/OSS people... SVN, seriously?) to develop mods.

After some internal discussion and general anxiety, we’ve arrived at a plan for supporting mods. It’s still a bit vague and the details might change after we’ve run it by our lawyers, but here’s what we want to do:

  • Let players sign up as “mod developers”. This will cost money (edit: no longer costs money!), and will require you agreeing to a license deal (you only need one per mod team).
  • Mod developers can download the source code from our SVN repository. As soon as we commit a change, it will be available to all mod developers, unobfuscated and uncensored.
  • Mod developers get a unique certificate for signing their mods. This means players can see who made what mod and choose to trust individual developers. The cost of signing up makes sure only serious developers have access to this certificate.

The rules of the license deal will contain:

  • Mods must only be playable by people who have bought Minecraft
  • You can’t sell your mods or make money off them unless you’ve got a separate license deal with us
  • The mods must not be malicious (obviously)
  • We retain the right to use your mod idea and implement it ourselves in Minecraft. This is to prevent the situation where we have to avoid adding a feature just because there’s a mod out there that does something similar. It’s also great for dealing with bug fixes provided by the community.

Arguably, this is only one step away from properly open sourcing the game. I hope Minecraft will take that step one of these days, it undoubtedly has made Mojang millions already.

Published: 21 April, 2011 - 09:26
I've come across an interesting proof-of-concept attack on the official Minecraft server software. It seems like they were using a slightly amateurish way of managing connections to the server that doesn't scale very well and isn't DDoS-proof at all.

When it comes to networking, thread-per-connection is often considered to be Baby's First Concurrency Model: It's obvious, and works for very, very small things, but never scales very far and is quite painful to work with. There are many other ways to do networking, and properly describing them all would go beyond the scope of this writeup, but I will mention that they generally are based on the concept of multiplexing: syscalls like select() or poll() are used to list a set of connections and figure out which ones are ready to read from or write to, without extra userspace overhead.

Well, the [Minecraft] server is thread-per-connection, so it was figured that it would be a good idea to just pass the incoming socket directly to readUTF() and friends, in blocking mode. What this effectively means is that the thread containing the socket will block and yield control as needed, until enough bytes have come in to satisfy readUTF() and relenquish control back to the server. Imagine what happens if we were to give readUTF() a relatively large size, say, 65535, and then very slowly send characters down the wire to the server. The server cannot really do much about it since readUTF() is a library function; it has to wait until readUTF() has finished reading the string. This means that a malicious client could completely tie up a thread by doing this "slow trickle" of data. If enough threads are tied up, then the server will be unable to handle new requests because of resource exhaustion.

The moral of the story is, again: Don't use thread-per-connection. In Java, use NIO or MINA. There are reasonable ways to do networking in every language; let's start using some of them.

Admittedly, this seems like a bit of attention grab from the guy posting this since he's working on his own Minecraft server implementation, but it seems like Notch has work to do. This is bad. Of course, it would've been much better if this guy had disclosed the vulnerability responsibly (which I doubt he did do). Even better, if Minecraft was open source, I'm sure something like this in the code would've surfaced a long time ago and would have been fixed by now.

Published: 25 March, 2011 - 17:18
Minecraft on Fedora 15

As most of you will probably know by know, I'm a huge fan of Minecraft which isn't open source but probably the best game available on Linux today. The game runs really well on Linux but you need to take care in some respects when installing it. Since I get asked this a lot whenever I talk about Minecraft on the podcast, I thought I would write a quick howto and explain the installation of the game on Fedora. The basis for this tutorial is Fedora 15 (which is currently in alpha status) but it should work on Fedora 14 as well.

First, we need to install Oracle's version of the Java virtual machine since Fedora ships with the OpenJDK version which isn't recommended and has problems with running Minecraft.

  • Download the RPM from Oracle
  • Install it: # chmod +x jre-6u24-linux-i586-rpm.bin && ./jre-6u24-linux-i586-rpm.bin
  • Tell your system to use Oracle's Java by default (if the OpenJDK version of Java isn't present on your system, you may skip this step): # alternatives --config java In the dialogue that comes up, make sure that the OpenJDK package is not selected. Choose the other one instead and confirm your selection.
  • To make sure you have the correct version of Java installed, run: $ java -version You should get something like: [fabsh@serenity ~]$ java -version
    java version "1.6.0_24"
    Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
    Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)

Next, we can install the game itself.

  • Go to the Minecraft download section and get the Minecraft.jar file (listed under the "Linux / Other" heading); save it under the name Minecraft.jar in a directory of your choice.
  • In that same directory, create a document called minecraft.sh with your favourite text editor and put the following content in it:

    #! /bin/bash
    killall ibus-daemon
    java -Xmx1024M -Xms512M -cp Minecraft.jar net.minecraft.LauncherFrame
    ibus-daemon --xim -r &

  • Make that file executable: $ chmod +x minecraft.sh

And that's it. If you are wondering why we are killing ibus-daemon before running Minecraft, that is due to a bug that would otherwise prevent any key presses from registering in the game — this step wasn't necessary on F14 but something obviously changed with F15. Anyway, you may now run the game by invoking $ ./minecraft.sh or by creating a shortcut to that script and executing it that way.

Published: 24 March, 2011 - 20:01
I usually get whinged at for complaining too much about things not working in Linux but today I want to thank somebody explicitely for making my life a lot easier. Thanks to Chris Bagwell for doing amazing work in improving support for the Wacom Bamboo tablets in the Linux kernel. Because of Chris, my Wacom Bamboo CTL-460 now works perfectly in Fedora 15. It's now actually plug and play which makes earlier workarounds unnecessary. This makes the design work I do a lot easier, especially since Fedora updates the kernel so much, and should help a lot of other people too. Chris, if you read this: the Fedora Design Team thanks you!
Published: 6 March, 2011 - 18:32

Minecraft Adventures Cover ArtEven though I've been saying that I'm not really into video generally, Sixgun Productions has just started the first foray into the world of video content. As many of you will know, I've really gotten into the game Minecraft lately and I've started to toy around with recording some gameplay and putting it on YouTube. For this purpose I have created the Sixgun TV project and uploaded a few test videos. I liked doing that so much that I have decided to start a regular series which I've called Minecraft Adventures. This is somewhat inspired by Yogscast, but there won't be a storyline involved — it's just me playing. At some point I might get other people involved in a multiplayer setting but for now I've been playing singleplayer in my own, freshly-generated world.

I hope you'll check out the new show, even if you don't play Minecraft (yet) and enjoy it as much as I enjoy playing. If people have any suggestions, as always, feel free to tell my what you like and what doesn't work but please keep in mind that I'm still very much experimenting with the format and the techniques of doing the show. Let's see if video turns out to be as successful for us as audio is...

Published: 9 February, 2011 - 10:46

While we have members of the Fedora community underhandedly criticising each other, I thought it would be important to point out a few things on the recent discussions about Fedora and if the project has an identity crisis as a distribution.

Granted, I haven't been aboard long, but one thing has been obvious to me from the start: As benevolent as Red Hat is as a corporate sponsor, its involvement creates a big point of friction in the Fedora community. We are all working together, but there are two camps within the project. There are volunteer contributors like me (these make up the bulk of the community) and then there are people getting paid in one capacity or another by Red Hat who also work on the project. In my opinion, this dichotomy isn't as pronounced as it is over at the Ubuntu project, where Canonical takes a much more hands-on approach in the direction and governing of the community, but it is still an important factor within Fedora. Máirín's assertion that we all make Fedora is theoretically correct but practically it is as misleading as saying that the slaves have build the great pyramids — yes, they technically did, but while they died of malnutrition with bloody hands others reaped the benefits of their work. It is true that all contributors make and shape Fedora to some extent but the general direction of the project is very much set by Red Hat. Now, people at the company will dispute this, but I think we all know that it is true. Seven of the twelve members of the current Fedora Board work for Red Hat, one of them is the Project Leader and Chairman of the Board, of course. Don't get me wrong, I am not saying it's bad that Red Hat is steering Fedora to a big extent. Red Hat is a great company and I strongly believe they are one of the good guys plus they also sponsor the project and keep it going. Getting control in return for that only seems fair to me, but in order to have a healthy relationship within the community we all have to admit that this is the case. What worries me is a tendency to pronounce our Red Hat colleagues as "people just like us" when in fact, they often have a lot more insight into the project and what's going on, if only by the virtue of the fact that they work in the same building as all the other movers and shakers in Fedora Land. Having said that, it surely helps that the current FPL wasn't working at Red Hat before he took the role and is even now working from home.

It often feels to me that the community contributors are pulling Fedora in one direction and Red Hat is pulling it in another. This is to be expected of course and it isn't the whole story as there also seem to be divisions within what Red Hat wants to do with the project (consider Lennart Poettering trying to introduce a cutting-edge init system that could potentially break everything for everyone while on the other hand people like Máirín have a goal of making Fedora stable and usable for everyone who just wants to get into Linux). A lot of these ideas just don't mesh and saying that they do will not make it so. I strongly believe we have to decide where we want to go: Do we want to be a power user, freedom-focused distro for developers that gives everyone access to the newest tools immediately or do we want to be the most stable, end-user friendly distro we can be and beat Ubuntu at their own game? I don't believe being both is possible, even for something as awesome as a completely community-developed Linux distro. If we try to be both, we will fail at both and end up being even more mediocre than some people already see us as. Of course, a mission statement that says our target audience is "everyone who voluntarily switches to Linux, preferably contributors" doesn't help in deciding this. Based on that, we are trying to be the better Ubuntu and I don't believe Freedom and Features First fit into that. Not to mention that the "let's do a better Ubuntu"-space is pretty occupied by Mint, which to be honest, is pretty hard to beat where it's at.

I believe Fedora needs to find it's place in the distro world. I also believe the dev-centric, power user space is one where we can kick ass and do what Red Hat wants us to do to further it's goals. But whatever we do, we need to re-define our target audience. Target audience means you can't be afraid to exclude people. To have a useful target audience, you need to exclude people. All the best brands and products have a clearly defined set of people they are targeted at and especially when you have strong principles like software freedom, you can't target everyone. We need to be realistic about this or we will fail and become obscure and unimportant.

If you have comments about this post, please share them in this identi.ca conversation. I am very interested in discussing this topic.

Published: 9 November, 2010 - 10:52

Just a quick update to my earlier article on getting the Wacom Bamboo CTL-460 working in Fedora: I have tested the tablet with F14 now and while it's still not automatically detected, at least the udev rules part of the procedure I detailed earlier is now obsolete. Here is what I had to do to get the Bamboo to play ball in Fedora 14:

  1. Install the prerequisites: # yum install gcc gcc-c++ kernel-headers kernel-devel libXi-devel libX11-devel xorg-x11-proto-devel xorg-x11-server-devel tk-devel tcl-devel ncurses-devel xorg-x11-drv-wacom-devel libXrandr-devel
  2. Download the newest driver from Sourceforge. At the time of writing that was linuxwacom-0.8.8-10. Untar the archive: $ tar -xf linuxwacom-0.8.8-10.tar.bz2
  3. Change into the directory via $ cd linuxwacom-0.8.8-10 and configure the package: $ ./configure --enable-wacom
  4. Compile the kernel module: # make
  5. Find your current kernel version by running $ uname -r and change into the directory with the module you just compiled: $ cd src/2.6.30/ (note that this doesn't necessarily correspond to your actual kernel version)
  6. Copy the kernel module into the right directory so that the running kernel is able to use it (replace <KERNELVERSION> with the actual version that you found out by using the uname command earlier): # cp wacom.ko /lib/modules/<KERNELVERSION>/kernel/drivers/input/tablet/
  7. Do a # modprobe wacom and a # depmod -a and plug in your tablet. It should work right away now!

You still need to repeat steps 6 & 7 every time you do a kernel update (so keep the wacom.ko file around somewhere in your home directory) but this at least cuts the initial steps nearly in half.

Published: 10 September, 2010 - 19:24

I recently got a Wacom Bamboo CTL-460 for my birthday from my most awesome girlfriend, something I wanted for a long time and a great present for an aspiring designer-type like me. Upon unwrapping and plugging it into Fedora 13, I discovered the device is recognised by the kernel and seems ready but does not work at all. Not that this would scare a proper Linux geek and after a quick google I found a bug report in Bugzilla and a very useful blogpost that helped me set this thing up and start drawing. It looks like this is mostly a problem with the Wacom driver in the F13 kernel and you have to compile and insert a newer version (sounds a lot more scary than it actually is) to get this nifty gadget working. As soon as the newer kernels get the right version of the Wacom driver this shouldn't be necessary anymore, though. Maybe the one in Fedora 14 will already fix this, I'll have to experiment with that at some point. Here's what I did to get my tablet working the same night:

  1. I installed the following packages: # yum install gcc gcc-c++ kernel-headers kernel-devel libXi-devel libX11-devel xorg-x11-proto-devel xorg x11-server-devel tk-devel tcl-devel ncurses-devel xorg-x11-drv-wacom-devel libXrandr-devel
  2. Then I downloaded version 0.8.6-2 of the linuxwacom driver from Sourceforge and unpacked it in my home directory with $ tar -xf linuxwacom-0.8.6-2.tar.bz2
  3. After that, I changed into the directory I just created via $ cd linuxwacom-0.8.6-2 and configure the package: $ ./configure --enable-wacom
  4. Now we can compile the kernel module: # make
  5. I then needed to find my current kernel version by running $ uname -r and changed into the directory with the module I just compiled: $ cd src/2.6.30/ (note that this doesn't necessarily correspond to your actual kernel version)
  6. We can then copy the kernel module into the right directory so that the running kernel is able to use it (replace <KERNELVERSION> with the actual version that you found out by using the uname command earlier): # cp wacom.ko /lib/modules/<KERNELVERSION>/kernel/drivers/input/tablet/
  7. At this point I did a # modprobe wacom after which most guides said that the tablet should start working which it didn't, I went ahead and did # depmod -a anyway
  8. So it turns out you also need a udev rule for this thing to work properly, so I removed the tablet from my laptop, plugged it back in and ran # lshal -m — out of that output I picked the string that looked like "usb_device_56a_d1_noserial" for the next step
  9. I now ran # lshal -u usb_device_56a_d1_noserial (you might need to modify this line based on the readout of the previous command) and used the "linux.sysfs_path" from the ensuing output for the next step
  10. Now we invoke udevadm info with whatever path we received, for example: # udevadm info -a -p /devices/pci0000:00/0000:00:0b.0/usb2/2-4/
  11. The output of this can be used to create an udev rule for the device, we are interested in the KERNEL, SUBSYSTEM, DRIVER and ATTR{idProduct} values — my rules file looks like this:

    KERNEL=="2-1.2", SUBSYSTEM=="usb", DRIVER=="usb", ATTR{idProduct}=="00d4", SYMLINK+="input/wacom-touch"

  12. Now create a rules file of your own and copy this data into it (modify where necessary based on the output you get for your device): # nano /etc/udev/rules.d/60-wacom.rules
  13. After a reboot, the kernel should pick up the new module and the device properly and you should be able to use the Bamboo as soon as you plug it in

I hope this is helpful. The Bamboo is a neat little tool and I've been using it nonstop since I got it. The only downside to this method is you have to repeat steps 1 - 7 whenever a kernel update gets applied on the system.