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.
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()orpoll()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 satisfyreadUTF()and relenquish control back to the server. Imagine what happens if we were to givereadUTF()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 sincereadUTF()is a library function; it has to wait untilreadUTF()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.
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.
# chmod +x jre-6u24-linux-i586-rpm.bin && ./jre-6u24-linux-i586-rpm.bin# 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.$ 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.
#! /bin/bash
killall ibus-daemon
java -Xmx1024M -Xms512M -cp Minecraft.jar net.minecraft.LauncherFrame
ibus-daemon --xim -r &
$ chmod +x minecraft.shAnd 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.

Even 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...
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.
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:
# 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$ tar -xf linuxwacom-0.8.8-10.tar.bz2$ cd linuxwacom-0.8.8-10 and configure the package: $ ./configure --enable-wacom# make$ 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)# cp wacom.ko /lib/modules/<KERNELVERSION>/kernel/drivers/input/tablet/# 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.
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:
# 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$ tar -xf linuxwacom-0.8.6-2.tar.bz2$ cd linuxwacom-0.8.6-2 and configure the package: $ ./configure --enable-wacom# make$ 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)<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/# 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 lshal -m — out of that output I picked the string that looked like "usb_device_56a_d1_noserial" for the next step 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# udevadm info -a -p /devices/pci0000:00/0000:00:0b.0/usb2/2-4/
KERNEL=="2-1.2", SUBSYSTEM=="usb", DRIVER=="usb", ATTR{idProduct}=="00d4", SYMLINK+="input/wacom-touch"
# nano /etc/udev/rules.d/60-wacom.rulesI 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.