Live from Austin!

I’ve been happily running Debian on my ThinkPad for over a year, probably the longest time I’ve ever kept a single OS on the thing. Or rather, I had been until Saturday. Saturday is when I decided to update my X.org.

I’d had some problems with X.org before. Debian Testing upgraded to X.org 7.0, and it turned out the ATI FireGL T2 drivers in that were broken. So, no fancy new X.org 7 for me until 7.1, I thought, which was a shame because the new ATI drivers in 7.x provide full hardware acceleration, including 3D.

Still, updates were to be had, so I went ahead with what I expected to be a routine point release upgrade of 6.9. However, it turned out that the packaging of X.org has been rearranged, along with the system directories.

Result: no X.

I tried running the autoconfig, which has always worked in the past. It didn’t work, couldn’t find the perfectly ordinary USB mouse either. I upgraded everything else via apt-get upgrade and rebooted, and discovered a ton of errors now appeared during boot. I spent an hour or so dicking around before coming to the conclusion that the system was hosed in a way which would probably require some kind of reinstallation.

This isn’t my first moment of dissatisfaction with Debian. PAM was broken for months, I’m not sure if it has even been fixed yet. Sound stopped working a couple of months ago. It seems as if somehow along the way ‘testing’ has become ‘unstable’. Perhaps it’s because of the pressure to speed up the release cycle–but then, I don’t see any new stable releases on the horizon.

So, it was time to weigh options. Debian Testing had just burned me badly, so that was out. I could stick with Debian, reinstall Sarge, and live with no accelerated graphics until the next Debian release, which could be years away. I could try the IBM Linux image, which is based on a well-known commercial Linux distribution that I’m not a big fan of. Or, I could try something else.

The new distribution all the cool kids are running is Ubuntu, so I downloaded and burned a CD and booted it. All the ThinkPad hardware worked first time, including Bluetooth, ATI graphics with 3D acceleration, sound, and ACPI power control. So, it looked as though Ubuntu would give me the Debian base I liked, with the advantage of a release schedule measured in months rather than years, and accelerated graphics.

However, Ubuntu is based on GNOME, and I’ve been a KDE user in recent years. There’s a KDE-based Ubuntu variant (Kubuntu), and also one that runs the XFce windowing environment (Xubuntu). I tried all three.

GNOME is nice and simple in appearance, but it’s a terrible RAM hog. KDE has chronic optionitis, but has lots of handy programs; but I thought about the programs I run all the time, and realized that only one is actually built for KDE–the others are all GTK-based.

Then I tried XFce, which is GTK-based, and noted that I could run XFce and Firefox together and use less RAM than just the KDE desktop. So, XFce was ahead. When I noticed that XFce showed file sizes correctly but GNOME didn’t, the deal was sealed.

Next problem was to back up all my user data. I went on a cleaning out spree, burnt a DVD of old stuff I hope never to need again, and shrunk everything down to under 30GB. I used rsync to back it all up to our MP3 and e-mail server temporarily.

Then, I decided to be daring, and used resize_reiserfs and GNOME partition editor to make space for a new root partition, turning the old partition into /home. This allowed me to install Xubuntu without wiping my home directory.

I just finished confirming that I can get the VPN working, so I don’t have to go into the office in the morning. I’ll get Eclipse and all the other work stuff going again tomorrow.

J2EE specifies Enterprise Java Beans for handling data, where the data and the client accessing it may or may not be on the same system. Entity beans are used to encapsulate the data in the database—instead of accessing the database directly, you create an entity bean to do it for you. That way the client can use the entity bean and not need to know about SQL.

However, the person writing the entity bean doesn’t really want to have to know about SQL either. That database stuff makes writing an entity bean a pain, so container-managed persistence was introduced. This allows you to let the EJB container (part of your J2EE server) handle the messy database stuff for you, and you don’t have to know any SQL at all.

Of course, SQL allows you to do a lot of useful things, such as querying databases in complex ways. It turned out that doing those things by fiddling around with container-managed entity beans was a real pain in the ass. So in EJB 2.0, Sun added EJB QL, the Enterprise JavaBean Query Language. It’s just like SQL, only slightly different, and not as powerful.

Of course, performance was getting pretty crappy by this point, so to improve things, EJB QL can be compiled into SQL.

So to summarize, here’s the old ugly way of doing things:

• Client program connects to database server.
• Client program sends SQL query to database server.
• Client program gets back data from database server.

Now here’s the new, improved way of doing things:

• Client program connects to J2EE server.
• J2EE server instantiates entity bean.
• Entity bean opens connection to database.
• Client program sends EJB QL query to J2EE server.
• Entity bean compiles EJB QL into SQL.
• Entity bean sends SQL query to database.
• Entity bean gets back data from database.
• Entity bean passes back data to J2EE server.
• Client program gets back data from J2EE server.

Obviously this is a big improvement. What’s more, because of the use of EJB, all of the J2EE entity bean stuff can be placed on a separate machine from the client and the database server. In fact, for performance reasons you’d be well advised to do so.

So, before: client system, database server. After: same client system, huge $20,000 server running $50,000 of J2EE application server software, same database server. Now your client software can send queries that look just like SQL, and get back results exactly as if they came from a database server—but instead, they’re coming from a box with that wonderful Java technology.