Newer is not necessarily better

I'm still getting acclimated to the changes in Gnome 3. So far, some things that initially irritated me ended up being easy to get used to. Others, still bug me on a daily basis. I still want to take more time to collect my thoughts on the matter, but one thing really stood out today: Gnome System Settings has some rather drastic feature regressions compared to the system-config-* applications that Fedora used to ship.

Let me start at the beginning: I have an HP OfficeJet 4500 printer on my network. When I first reformatted my machine and set up printing, I had no troubles getting the System Settings -> Printers panel to find my printer on the network and print pages for me. Everything seemed peachy. Today, I needed to scan something but neither Simple Scan nor the GIMP would recognize the scanner on the printer. This struck me as really odd, since I remember everything just working when I set it up in Fedora 14. Long story short, the System Settings application always chooses the wrong driver when you add a network printer, landing on the dnssd drive and not having any options for you to switch which driver is used. The driver you actually want is the hplip driver that is already installed with Fedora.

The simplest solution to the problem turned out to be launching system-config-printer (the Printing application in Applications menu). It's a much more featureful and easier to use configuration application. I quickly had the driver switched and everything is working great, but what a waste of my evening trying to solve this.

Next time I need to change something, I think I'll start with the appropriate system-config application and go from there.

Upgrading to a new you

Yesterday I updated my primary desktop from Fedora 14 to Fedora 16. I didn't have much time to get anywhere beyond completing the install and the initial set of updates before it was time for bed. So far the best way I can describe the experience would be to say I have found the switch Gnome Shell rather jarring. Trying to interact with systemd also feels like fumbling my way through a foreign language so far.

It's only be a little while so I'm going to give this a chance to grow on me, but I wanted to start documenting my user experience as best I can.

How I do upgrades

Sadly, I have not allocated the time to upgrade from F12 to F13. However, I attended the somewhat belated Toronto Fedora 13 Release Party hosted at the York University campus. Mostly this was a chance to catch up with some of the Toronto Fedora folks that I had met last year at FUDCon Toronto but I hadn't talked to in a while due an extremely busy personal life since the turn of the calendar.

I also got talking with Tom Fitzsimmons about version-to-version upgrades of Fedora. He does pre-upgrade every time because he likes his stable environment. Andrew Overholt had just done a DVD upgrade to his laptop. We got discussing the merits of keeping all of your existing install versus starting fresh with a clean wipe. I hadn't quite realized how novel my approach seemed to be, so I figured I would share.

On my main desktop, I have a 200 GB hard drive partitioned thusly: 200 MB for /boot, 2048 MB for swap, the rest is an LVM partition. In the LVM Volume Group, I've got a 20 GB LV for my root partition and a 40 GB LV for my home directory. Various other LV's are created usually for virtual machines.

When I want to install a new version of Fedora, I create a pair of new blank LV's for my root and home partitions. These are side-by-side with my existing active pair. I then download the DVD iso, burn it, and reboot into the installer. When I get to the storage section of the installer, I select manual partitioning. It automatically detects my existing LVM partition and lets me manipulate it. I let the installer obliterate my /boot (I find it is unhappy if I do not let it own /boot) and point it to format the blank LV's. From there, I proceed as normal with a fresh install. I really should figure out a better way to do the package list, but I typically pre-select most of the stuff I know I'm going to want. Once the install completes, I reboot. I now have a fresh install, and my old install is still available for reference purposes to grab configurations, customizations, and home directory preferences. I copy over everything I want to save from the old install, then leave it around dormant just in case I have forgotten something. If/when I get to the next upgrade without using the old install, I can reclaim the space for the upgrade. In a pinch, I can also rescue boot into the old install.

For me, I mostly end up with the best of both worlds. On the one hand, I get all the bells, whistles, and default configuration of a fresh install. On the other hand, I also get an easy migration path to get my old data onto my shiny new install. This is clearly a little bit more work than either pre-upgrade or a clean wipe, but I find it worthwhile.

Does anyone else use a similar procedure?

Can we all agree that Spring isn't that lightweight?

Sorry Planet, this is merely tangentially Linuxy. I promise the next post will be more Linux & Fedora related, although that may not be for a few weeks.

So I've been working on a simple little Java web app as a learning tool for myself. The stack I'm using is Stripes 1.5.3 (a great little web framework that I'd like to package for Fedora), Spring 3.0.2, Hibernate 3.5.1 with Apache Derby in Tomcat 6. The reason I'm using this stack, rather than something like Glassfish or a JBoss 6 milestone, is for the express purpose to try out the new releases of Spring and Hibernate. The additional experience with the two frameworks is helpful as well. I'm actually using Hibernate as a JPA2 provider rather than native Hibernate.

Anyways, the refrain I've often heard about Spring is that it's "sooo much lighter weight than Java EE". Now, this was most assuredly true back in the dark days of EJB2 and J2EE 1.3/1.4. The world has since moved on to Java EE 6 which looks very spiffy and developer friendly with EJB 3.1, CDI and JPA. Back to Spring, from a developer's point of view, managing the 31 jars I needed just to get a single crud page working is a little involved and practically all of it came from Spring's dependencies. I needed 10 separate org.springframework jars plus their dependencies for a relatively trivial web application. The winner was of course the esoteric error messages explaining to me why it couldn't autowire something (missing configuration item for the transaction handling, which led to missing jar dependency to enable that feature). That Java EE App Server that bundles all the stuff I need? Yes please!

P.S. Yes, I know of Maven, but I wanted to keep the scope creep to a minimum for this project.

Future FUDCon Hackfest Request

I blame Mel Chua for any and all noise that results here. I'm a long time Fedora user, a Software Developer in the real world, and FUDCon just happens to be in Toronto this year. This was obviously too good an opportunity to pass up, so I ended up meeting a ton of awesome Fedora people, attended some neat sessions, committed my first patch, and ended up signing up for Planet as well (hopefully this worked). I also made the mistake of talking too much in IRC and getting roped into more stuff.

So the pertinent IRC discussion was about Packaging. Yaakov and Rex ran a good intro to Packaging during the Saturday sessions, but Mel mentioned in IRC on Sunday the idea of a packaging hackfest at future FUDCons. As a user that wants to learn to package, I have to say that I think this is an outstanding idea. Even after going through the packaging session, I'm mostly aware that there's a ton of documentation that I need to read before I really attempt much packaging on my own. Sitting down with a proven packager or two and going through the creation of a bunch packages to get used to the workflow. On the other side, the proven packagers can get some practice going through package reviews.

Now, obviously the packages aren't all going to get reviewed on the same day, they may not even be up to snuff to ever get included in Fedora, but certainly the experience would vastly accelerate the learning curve to end up as a productive packager. Mel mentioned this in IRC, and I wholeheartedly agree that it would be great to make packaging something that new people look at and go "holy cow, my 1st package was such a great experience that I want to do a 2nd one."

Now there's a couple obvious needs to pull this off at a future FUDCon:

1. You absolutely need patient, experienced packagers to attend this hackfest and mentor the packager candidates.
2. You need a list of relatively low-hanging fruit to package up during the hackfest. Fonts was one suggestion of an 'easy' package that provides lots of candidates without too much complexity to deal with. Another idea was to work as a group towards some kind of packaging goal (e.g. all of the components and dependencies for Zikula)
3. Find homes for these nascent packagers within the existing packaging community so they don't fall off the radar after FUDCon

I'll be looking for this at the next FUDCon, attending for sure if I haven't figured out this packaging thing on my own by then.