Kernel ABI and why it matters

Kernel ABI is the exported binary interface provided by the kernel, and accompanying modules. Most Linux distributions have a way of tracking this ABI to detect when the kernel's exported interfaces have changed, and thus, modules compiled for it may be in need of recompiling. Usually this results in the incrementing if an ABI number (on Ubuntu, it would be the "-2-" in 2.6.24-2-generic).

There are many extremes on how this ABI is handled, from taking expensive measures to ensure it doesn't change in a released distribution, to just not caring at all (not tracking it will be an idiotic extreme I wont even cover).

In Ubuntu's case, we fall somewhere in the middle. We track it, and bump the ABI fairly reliably if _anything_ in our kernel ABI changes. We also try not to bump it in released kernels too often (security updates being an exception), but we don't put much effort into preventing it, or guaranteeing a subset of symbols will never change over the lifetime of a product.

The general consensus has been (at least for me, I can't speak for Canonical on this point) is that the only things that cared about ABI bumps were proprietary and/or third party drivers. For open-source third-party drivers, we've recently been pushing the use of DKMS. For proprietary drivers, I've been all for letting the vendors deal with keeping up with us.

However, kABI has more ramifications than just proprietary modules. Many certifications are based on the kABI it is running under (think Oracle, VMware, etc). When we bump the kABI, we in affect force a minimal recertification. This isn't good for an enterprise Linux distribution.

So it seems that things will change. For Ubuntu to be considered in certain installations, kABI will need to have strict guidelines and criteria. We'll need to justify post-release kABI bumps and do more work to rewrite security patches to avoid changing the kABI.

A bit of preparation for this has already taken place in Intrepid's kernel (based on 2.6.26). A new kABI checker has been implemented. This checker has always been there, and it runs at build time, but has been very basic and dumb. Now, it has much finer grain checks, and will be expanded to support white/black lists in which we will only bump the kABI if it affects major parts of the kernel (no more kABI bumps for appletalk, sorry guys).

You wont notice much when this happens. You probably wouldn't have known if I hadn't told you. Rest assured that it wont adversely affect our range of hardware support. Perhaps it will mean you have to do less compiling for DKMS packages on your system :)

Keeping the last successfully booted kernel

It's always been possible to boot to an older kernel on Ubuntu if a new kernel didn't work. However it was never possible to boot to the last kernel that was known to work, nor was there ever a guarantee that there would be an old kernel around.

Let's say someone installs Intrepid 8.10 Alpha 1 with kernel 2.6.26-2-generic. After installing (which presumably went well), they upgrade and get a new 2.6.26-2-generic kernel (remember, newer kernels don't always bump the "2" ABI). Upon rebooting, they discover this new kernel doesn't work for them. What now? There is no longer an older kernel to boot to.

Enter "last-good-boot". A new mechanism now in development that will save away the kernel+initrd+modules for the last time your system booted successfully.

It will add this as an entry in grub for visibility.

Currently there are packages in a PPA:

deb http://ppa.launchpad.net/ben-collins/ubuntu intrepid main
deb-src http://ppa.launchpad.net/ben-collins/ubuntu intrepid main

It includes the module-init-tools and grub changes needed to test. After installing these packages, you will need to reboot in order to get your first last-good-boot.

Feedback welcome.

Video conversion for PS3

So I was messing around with my PS3 this week. I decided I wanted to finally take advantage of it as a media center, since my laptop is getting too full with movies, home videos and photos.

Much to my dismay, there's a whole lot of people asking how to use Linux to convert videos for the PS3, and not a lot of success out there. Finally, after several days of trial and error, I've gotten it down pretty good, encoding all of my home videos and movies to h264 format.

First off, I did replace the weak 20Gig drive in my PS3. It's actually quite easy. The drive in the PS3 is a standard SATA laptop type drive. If you want to backup your current drive, simply go under Settings->System Settings->Backup Utility and use a decent size flash/pen drive to do it (I was able to back mine up onto a 4Gig USB pen drive). After the backup is done, open the side (you're responsible for this if it breaks your system, not me), and change out the drive with your new one, and power up. It will ask if you want to format it, choose "Yes" of course. Then use the same utility to restore your data (saved games and such).

So, now on to the encoding part. This ended up being extremely easy, but there was a lot of missing information I had to figure out. First, you will need the avidemux program. On my Ubuntu 8.04 system, this was available from the universe repository (apt-get, synaptics will find it by default).

Start avidemux and open your video. Go to the Auto menu and select "PSP (H.264)", use the 720x480 video mode when the dialog box pops up. This isn't it though. Next, select "Configure" under the Video section, change the encoding to "2 Pass - Bitrate" mode. Close the configure dialog. Click the "Format" dropdown, and change it to MP4.

That's it, now click save, and let it process. You will get nice, compact, high quality video suitable for your PS3.

WAIT. This is the part that I have yet to find. When transfering your video to your PS3, you will need to follow some key steps, else the PS3 wont "see" it on your USB device. Your USB device should be fat32 formatted. On the device, create a directory called "VIDEO" (all caps, no quotes). This is where you will copy your video files to. This part took me awhile to figure out. If you have videos you want to group together (an "Album" in PS3 speak), create a subdirectory in "VIDEOS" (e.g. "VIDEOS/Action Movies/") and place your videos there. You can then copy this entire "Album" together.

Well, that's it. Hope I saved you a lot of time and frustration.

Give me a funky ass bass line...

Started my bass lessons a few weeks ago. I've had my bass rig since November, and have just been strumming on it, practicing fretting, plucking and muting techniques. Finally learning some songs now. First song is Black Dog by Led Zeppling, and now I'm picking up Bulls on Parade by Rage Against The Machine. Lots of fun. My teacher is kick ass, so that makes it a lot easier.

How to play freerolls

So in my quest to duplicate Chris Ferguson's feat, I've been playing a lot of freerolls. It's been awhile since I've played so many, and I've had a few thoughts on changing my game plan to accommodate the craziness involved in these types of tournaments.

The main thing about freerolls is that they're freerolls. This means people have no recourse for losing. Many players believe they need to build their stack very quickly. This is wrong in many ways. In general, there is little to gain from building up a quick stack. If you tighten up after building it up quick, the blinds will grow too quickly for you to make use of those chips you just got. If you continue your reign of terror (playing big pots aggressively with weak hands) players at the table will catch on and use you to build their own stack. Yes, you may suck out on AA every once in awhile with 95s, but that doesn't mean you should make it your game plan.

So, here's some things I've been doing. We'll start of with how to play when the big blind is less than 150.

• Don't raise with anything other than AA, KK, and AKs. The normal reason for raising with other hands is to reduce the field and protect your hand. You can't do this on a loose freeroll. Almost any ace is going to see a flop.


• Limp a lot with mediocre hands. If you can see a flop cheap with things like J8s and K9s, then do it. Be prepared to dump them with a weak flop, but play them hard if you flop a monster. You will get payed off.


• Be prepared to fold your big hands when there is too much action. If you are sitting pre-flop with QQ and 5 people have gone all-in, and it costs you all your chips (or most) to make the call, you are better off folding. Sure, you are still going to win around 30% of the time, but that's not enough to make it worth it. Likely, you will lose. Even if you win, those chips wont be worth the risk you took to get them.


• Be patient. The all-in-junkies will be gone soon.


• Don't limp to someone who is pushing in every hand if you aren't willing to call.


• Take advantage of the action players. If you see someone making a move at every pot, trap them with your big hands, and monster flops.


• Don't bluff. This includes huge semi-bluffs (open-ended straight-flush draws for example). Most times you will get called and have to hit your outs. I would only suggest semi-bluffs where you think you have 12 or more outs and are short stacked and needing the chips badly. Sometimes you can try a minimum raise on the flop against a single tight player to see a cheap river, but most of these players will call and bet on the turn

So, now you've made it to the bigger blinds. You've outlasted the jokers, now on to the poker. Usually at this point, the field is already down to less than a third of where it started. But that's way off from payday. However now that you have gotten deeper into the tournament, normal game plan starts paying off. Closer to the money (or prize) makes people less likely to take risks. The big stacks, however will be calling with mediocre hands to try and eliminate the short stacks (e.g. calling an all-in with A5o).

Hope this helps! Good luck, and see you at the tables.