User Mode Linux As Cheap App Container
As anyone running Linux knows, one of the biggest challenges for a Linux user involves trying to run new software on an older distribution. Many Linux applications (particularly Gnome and KDE apps) have enormous dependencies, and as applications move forward, they come to depend on newer versions of those dependencies. The result is that, on, say, an older Ubuntu installation, running the latest version of your favorite application likely involves compiling and manually installing a dozen or more dependent libraries. It is, to say the least, a huge pain in the ass.
In my particular case, my primary server is running an older flavour of Ubuntu, hosting my MythTV backend software, Apache, Deluge, Calibre, and a few other applications. And recently I decided I wanted to upgrade a few of these applications… enter dependency hell. It quickly became obvious my plan simply wasn’t feasible.
Now, I could’ve just given up, but I was bored, and I like fiddling around with things, and so the first thing that came to mind was a virtual machine of some description, running the latest version of Debian. The most obvious solution was to install VirtualBox, and I briefly considered it, but vbox is a bit of a pain to manage remotely, and it certainly imposes a bit of a load on the host system. Meanwhile, I knew I only wanted to run Debian on this thing, so a full-blown virtualization solution seemed like overkill. And that’s when I recalled a neat little project called User Mode Linux.
UML is an intriguing project. It takes the Linux kernel, and by compiling it to its own architecture, turns the kernel into a standalone executable program. Hand it a disk image containing a root filesystem, and the thing boots up as a nested Linux instance. Voila! Instant, lightweight virtual machine. But how to get the root filesystem populated? Enter Debootstrap.
Debootstrap is beyond cool. Give it an architecture and a distribution server, and it’ll download and install the base components for a Debian-based operating system right into a directory of your choice. So to build a UML disk image, you just need to:
dd if=/dev/zero of=uml.img bs=1 count=1 seek=10G mkfs.ext3 uml.img mount uml.img /mnt -o loop debootstrap debootstrap --arch i386 sid *mnt http:*/http.us.debian.org/debian/
And voila! The system is populated. Now you just need a few tweaks:
- Edit /etc/passwd and blank out the root password (make sure to reset it later!)
- Modify /etc/udev/links.conf to add the UML block devices (see below).
- Add /dev/ubd0 as the root filesystem in fstab.
- Modify inittab, remove the existing VT definitions, and add one as follows: “c0:1235:respawn:/sbin/getty 38400 tty0 linux”
And then unmount the image and boot up as follows (assuming your linux kernel is in the current directory):
./linux mem=64M ubd0s=uml.img eth0=tuntap,,,ip.of.your.vm
And you should be in your VM! Finally, set up the system locale properly (again, see below), and that’s it, you’re ready to install whatever applications you want to run! At minimum, I’d recommend installing openssh-server. Once set up, you can run the image headless with:
./linux mem=64M ubd0s=uml.img eth0=tuntap,,,ip.of.your.vm con=null &
(Note, there are other options for con… you can hook it up to a pty, making it accessible from screen or similar tools. You can attach it to a Linux VT, or a serial port. You can even make it available over telnet.)
Of course, eventually you might want some swap on the thing. Fortunately, that’s just a matter of creating a new disk image, adding:
ubd1=swap.img
to the kernel command-line, and then doing a mkswap and swapon from the image itself (plus the necessary changes to fstab to add the swap on boot).
This configuration has enormous benefits. First and foremost, it allows you to run select, bleeding edge software without having to modify the host system, which is really very nice. Second, because you end up bootstrapping a minimum system by hand, the guest OS ends up very lightweight, so you can run the VM with a minimum of resources. Third, this setup, being very similar to a BSD jail, allows you to sandbox away software that you’d like to isolate from the core system.
Of course, there are solutions which will provide better performance (KVM, XEN, etc). But UML is very simple and straightforward, and for software that isn’t performance sensitive, provides a very nice option.
udev
Just append these links to /etc/udev/links.conf:
M ubd0 b 98 0 M ubd1 b 98 16 M ubd2 b 98 32 M ubd3 b 98 48 M ubd4 b 98 64 M ubd5 b 98 80 M ubd6 b 98 96 M ubd7 b 98 112
locales
apt-get install locales vi /etc/locale.gen - Uncomment "en_US.UTF-8 UTF-8" locale-gen update-locale LANG="en_US.UTF-8"
Hacking the Playbook - Redux
Well, I know I said I was gonna write some posts on the Playbook as I begin developing for it. Unfortunately, there are a number of things which have deeply turned me off of the prospect…
Incomplete APIs
Yes, I understand the device isn’t ready yet. I understand the simulators are in beta, and the SDKs are being completed. But the startling omissions in the current APIs make me seriously wonder about the device and the BB developers:
- No text box control. There’s a text field, but no multi-line control. So much for a note taking application or anything similar.
- No date picker. Seriously. Wow.
- No localization support. This is supposed to be an enterprise-level device, and it doesn’t have a localization API yet??
- No rotation support. Just… unbelievable. This is a tablet, ffs. How can they not have landscape/portrait mode available? Hell, apparently no one has even seen a sample Blackberry app that does portrait mode.
- No webkit engine API. They’re “working on it”, apparently. The device is supposed to be out in a month. I mean, really…
Meanwhile, the simulator doesn’t support things like:
- The camera API
- The multimedia API (you know, the thing that, to quote, is supposed to “differentiate” this device from others on the market).
It’s really quite stunning to me, and makes me wonder what other omissions there are in the application stack.
App World Application Blackholed
I applied for App World three weeks ago. And nothing. Apparently my application is being “reviewed”. Well, I ain’t spending time writing code if I’m not even sure I’ll be able to submit the thing.
Ridiculous App World Fees
Yes, the current submission fees have been waived, but it’ll be $20 per submission to App World once the promotion is over. That means every failed submission, every update, is gonna cost $20. It’s ridiculous.
Unprofessional Webinars
The webinars BB posted were, frankly, terrible. The BB consultant running them is brutal, the material is superficial at best, his delivery is moronic, repetative, and frankly, boring… they’re just bad. Meanwhile, they’re full of glaring holes, bad examples, and don’t get me started on the marketspeak.
Meanwhile, every other question seems to highlight another gap in the SDK or simulator… the number of times I heard “we’re still working on a story for that” was impressive, to say the least.
In Conclusion
Everything I’ve seen suggests this device is half-baked at best. Incomplete APIs, crappy presentations, an application process that seems to have stalled out on me, and a fee structure that seems designed to turn away smaller developers… for a $500 device, it really doesn’t seem to be worth the aggravation.
In The Hopper
Yes, believe it or not, I have a hopper. I never empty the hopper, but the hopper exists, and there are items in it. Usually the hopper is overridden with work concerns, be it actual, day-job work, or the consulting stuff I do on the side. Or it may be overriden by more immediate, viceral concerns: sleeping, eating, and so forth. But given it’s the Christmas season and things are slowing down a bit, it’s possible… just possible… I might be able to work on some items from the hopper.
First on the list? Earn myself a Blackberry PlayBook. They currently have a very simple developer contest: Get an application approved and published in their app store by February first, and you get a free PlayBook. A free $500 tablet? Sounds good to me! I’ve already got the SDK installed (the first SDK released is based on Adobe’s AIR platform), and the simulator up and running, so now I just need to start coding. The current plan is a recipe manager application… ‘course, I just need to decide how to present such an application on a tablet device. Fun!
And the second item? Update savsender to build against the latest devkitarm. And while I’m at it, get the code up on github. This was triggered by an email I received back at the end of October asking for an update, and given how simple the codebase is, it’s a request I should be able to fulfill during my spare time.
So, here’s hoping this is a productive Christmas! Assuming I don’t just sleep my way through it…
Hacking the PlayBook
So, hopefully here begins a series of posts on coding for the Blackberry PlayBook. In this first post, I’ll talk a bit about the PlayBook itself, and the SDK currently available.
The Platform
Unlike previous Blackberry hardware, which has traditionally run their custom embedded Blackberry OS, the PlayBook is the first BB device to run their new OS based on QNX, a realtime Unix variant that’s been around for nearly 30 years, now. My guess, based on various reading, is that Blackberry feels this new platform will scale better on the new embedded hardware that’s hitting the market, particularly the multicore devices everyone is anticipating.
As such, they plan to offer three different SDKs:
- A Java SDK, which I presume will offer compatibility with their existing Java kit on BBOS.
- A native QNX SDK, so you can write bare metal applications, such as games.
- An Adobe AIR SDK.
As of this writing, the AIR SDK is the only platform available, a move that, I suspect, reflects a desire, by Blackberry, to migrate developers to that environment (and more importantly, reflects Adobe’s goal of becoming the application development platform for the mobile space).
The SDK
On Linux, the kit comes as a number of parts:
- Flex Mobile, a cross-platform kit for developing Flex applications running on the AIR runtime.
- Blackberry’s Flex kit, which contains the various Flex libraries needed to build PlayBook applications.
- A simulator, which comes in the form of an ISO which is meant to be coupled with VMWare Player.
Of course, if you live in a Windows or MacOS platform, you also get to take advantage of Flex Builder, but alas, it isn’t available for Linux. That said, since the GUI designer tools in Flex Builder don’t work with the PlayBook GUI elements, it’s utility is far more limited, mainly to providing integrated help, code completion, and so forth, none of which is strictly necessary to developing for the PlayBook.
As for Flex/AIR itself, the language is ECMAScript, which is compiled down to SWF’s, which are then packaged up by the Blackberry toolchain, and can then be installed on the simulator.
Up Next
In my next post, I’ll cover compiling the venerable HelloWorld sample on Linux, and getting it running on the PlayBook; while this is actually quite easy to do with the command-line tools, it took a little bit of hunting around to find the proper incantations to make it happen.
After that, I’ll do a little work to dissect the HelloWorld app and write a bit about my first impressions on the kit.
Interesting Stuff! Stay tuned for more Tales Of Interest!