Penultimate Reality

Anyone who reads a lot of blogs needs a good way to keep track of it all. Back in the day, people (including me) would keep ridiculously long lists of bookmarks and meticulously check them one-by-one. Needless to say, this wasn’t exactly a recipe for extreme efficiency. Up until a few days ago, I’d used the excellent reader Liferea, which is available at least for Unix-like systems. Liferea had some bad interactions with Java on my system, causing it to crash on certain feeds unless I did some plugin shuffling to keep Liferea from using Firefox’s plugins.

When migrating my data from my desktop to my new machine, I decided to look at other solutions, and the one that came up was Google Reader. I’d briefly tried it before, but for whatever reason, didn’t get into it immediately. But after using it for a couple of days now, I can’t see what I ever didn’t like. I tend to skim certain feeds less than read them, and Google’s interface makes this incredibly easy, while allowing me to control exactly which entries are marked as read. In addition, by leveraging the power of an already functioning browser, instead of integrating Gecko (Firefox’s engine) into an application like Liferea does, it avoids some of the plugin troubles I’d been having.

I haven’t found much to complain about yet, though I do have a couple of wishlist features. First, I’d like to be able to set default sort options, so I don’t have to set it manually on every new feed. (I like to read from oldest to newest.) Maybe I just haven’t found the option, but I did look fairly exhaustively I thought. The second thing is that I’d like it to detect duplicate entries. For example, with many of the “Planet” aggregators, like Planet GNOME, it actually aggregates a number of these feeds. If you also read one of them separately, you’ll be subjected to the same entries twice. Liferea did this detection to a certain degree, and it’d be nice to see the same feature in Google Reader. It doesn’t come up too often with my feed set, but it’d be a nice addition.

Overall, if you’ve got a performant machine that can handle JavaScript-based web applications, look into Google Reader. One of the biggest advantages (as I’ve written about before) is to be able to recall your data from any machine in the world. On the other hand, if your machine’s old and can barely run a web browser without running out of RAM or something, you might want to stick with your current reader application.

After doing a little research, it seems like I can avoid the bad interaction with gnome-screensaver after all. By disabling the “Unredirect Fullscreen Windows” option, gnome-screensaver works properly. I’m not sure what effects this option has, however. I enabled it because the documentation made it sound important for using full-screen games or such, but I haven’t seen any adverse effects of disabling it. Maybe I was just suffering from over-eager option setting. I sometimes do that…

Of course, this still leaves the problem that I have to direct Beryl to “reload window manager” after logging in before it actually uses Beryl over Metacity, despite Beryl being selected as the window manager. Time for more research, I suppose…

However many months ago, when the video showing Xgl and Compiz was released, I remember being somewhat impressed by the demonstrated visual effects. Although many of them serve little to no actual purpose, I am an eye candy sort of person, and so are a lot of others. However, Xgl wasn’t about to run very effectively on the computer I had at the time, so the whole thing went to the farthest depths of my mind.

More recently, now that I have a much more modern machine, I thought back to the whole thing. Finding out now that at some point, a fork of Compiz called Beryl was now the most active part of the wholoe community, I chose to give it a try.

Installing it was quite easy, and in mere minutes, I had the effects up and running. I must say, they look pretty nice, other than a few glitches. (For instance, after you stop moving a window, it takes a second for the fonts to de-blur. Maybe this is a quirk of my particular hardware configuration, though. I am using NVIDIA’s drivers, which seems to be less stable than the Xgl and AIGLX solutions.) In particular, I found the cube to be very exciting. I’m not someone who uses virtual desktops very often, for no particular reason other than it’s the way I’ve always operated. But the eye candy-ness of it all makes it somewhat more attractive.

That said, I won’t yet be making Beryl my primary window manager. No, I don’t think it’s too much a drag on my system or anything. Simply put, it seems to interact poorly with gnome-screensaver. Normally, I have my screen set to lock automatically. In this case, the keyboard would sort of lock up, and I’d be unable to type in my password to the dialog. When I went ahead and disabled locking, it instead froze after blanking the screen, leaving me unable to get the screensaver to go away, even by manually killing gnome-screensaver from a console. I’m not sure if this is a bug in Beryl, my hardware configuration, or gnome-screensaver itself, but it’ll need to be fixed before I can consider making Beryl my default. And that’s a shame, because the alt-tab replacement was something I would actually get some practical use out of, along with whatever other features I haven’t yet discovered.

Yes, folks, I’ve finally had the opportunity to use Windows Vista. Of course, since there are several different editions, it may help to know that in particular, I used Windows Vista Business. In the grand scheme of things, Business seems to be the best version for power users who don’t want to shell out the extra cash for Ultimate. I assume that’s most people, unless you’re just that in love with Windows. Anyway, I do have a few impressions of the whole thing right now, though it may take a few weeks of use before I know lots of details.

(more…)

Yesterday, I wrote about how GNOME 2.18 was released recently without a real major headline feature. There were several smaller improvements, and it got me thinking about how there are two extremes in the software world when it comes to releasing new versions of software: releasing based on a fixed schedule, and releasing based on a fixed set of features.

GNOME epitomizes the fixed schedule release paradigm, making releases every six months, regardless of how many notable features are included. At the other end of the spectrum, we have projects like phpBB, which release purely based on a predetermined set of features (though this set of features isn’t necessarily cast in stone), paying no attention to the date of the release at all (resulting in possibly more than five years between major releases).

So which paradigm is better? The biggest problem with the time-based release is that certain features may be incomplete or unready for general release, pushing them back another cycle. This results in the scenario where a release may have no really significant improvements. Another problem can be that there isn’t a plan for what features will be included, instead opting to release whatever the myriad developers have put together. That said, one can easily set feature goals for a given cycle.

Feature-based releases aren’t all roses either. While the focus is definitely a list of particular features, unforeseen circumstances, such as personal problems or implementation difficulties, can result in a new release taking years. In this timeframe, support for a project can dwindle, with users jumping to more current alternatives. It’s for this reason that taking a pure time or feature-based approach is not a very good approach at all.

In my own projects, I’d probably focus more on features, with an unspecified goal to make a major release every 3-12 months, depending on the scope of the changes. The question at the end of the day is whether or not I’d be able to stick to that plan. I suppose I’ll find out whenever I make one of my releasable projects a primary focus. Until then, all I can do is ponder.

Just a few days ago, as I’m sure many of you are aware, GNOME 2.18 was released. It was somewhat interesting for me since it was the first release since 2.6 that I didn’t follow obsessively. Instead of aggressively installing betas and release candidates (that almost always caused crashes of various types), I simply avoided the development cycle altogether, and noticed the release came a lot faster in my mind. I haven’t yet installed the beast, since I’m waiting for it to be included in ~x86 in Gentoo, but if the release notes are any indication, I’m not going to be very impressed.

Maybe I’m just romantically remembering a past that wasn’t as glamorous as it really was, but it seemed that previous releases had new features, new applications, and other interesting developments. This time around, the release notes start out with rather vague improvements, like “personal security”, perhaps a warning in itself. If there were groundbreaking improvements, you’d think they’d at least be mentioned specifically. Next we find out there are a couple of new games. Well, that’s an improvement, I guess.

Next we finally get to the list of actual improvements. The killer GNOME 2.18 feature that was deemed worthy of the first bullet point?

Tomboy, the note-taking applet, helps you to keep better track of your most important notes by pinning them, making sure they will always easier to find.

Now, Tomboy’s a great application and I use it daily, but seriously? This is the top improvement? Maybe the editing was just bad. Continuing down the list, we finally do see some real improvements, but nothing stands out. I’ll just have to wait and see if I notice anything different when I finally upgrade.

This is perhaps the biggest problem I notice with some of these decentralized projects. A lot of small changes but no real direction. The same problem plagues Gentoo to a certain degree, and even KDE’s minor releases aren’t terribly exciting. Oh well, maybe KDE4 or GNOME 3.0 (if it ever even gets off the ground) will show some real innovation. Until then, I’ll just continue using my “functional” desktop.

Recently I’ve been playing with Ruby for my simpler programming needs, and have been considering using the popular framework Ruby on Rails. In the process of looking for interesting documentation, I came across Why’s (Poignant) Guide to Ruby, perhaps one of the most interesting books on programming I’ve ever read.

Now, it’s merely a guide to Ruby, and not Rails in particular, but it remains interesting just the same. The content is available online, which makes it really easy to get started. I was impressed by the first chapter, which managed to mix strange humor, talking foxes, chunky bacon, and a good dose of actual Ruby programming lessons all into a neat little package.

The next few chapters start to get a little more abstract, perhaps, and by the fifth chapter, I was left wondering whether or not I was still learning any Ruby. Each chapter essentially has a different story used to explain the chapter’s concepts, but when it comes to the fifth chapter, all I can remember is the exploits of Paij-ree and Dr. Cham. I have no idea what (if any) actual Ruby I learned, and by then, the book started to seem more rambling than insightful. I’m not sure I’ll read any additional available chapters, but I’m open to good reasons why I should, keeping in mind that at this point, it would be entirely for entertainment value, as I’m pretty well-set Ruby-wise.

It’s definitely a trend, as evidenced by many of the applications Google has been putting out recently: browser-based applications are on the rise. With examples ranging from mail applications like Gmail to entire spreadsheets, people seem enamored with the idea of using all their primary applications via the browser. Businesses and other web site operators also love the idea, since it keeps users at the site more often, viewing that all-important advertising. And truth be told, the idea isn’t necessarily a bad one.

Perhaps the biggest advantage is being able to access your data from anywhere in the world on any machine with internet access and a modern web browser. For people without notebook computers or with large amounts of data, this can be an incredible asset increasing productivity anywhere they might be. That said, I can’t help but notice some of the inherent problems, at least with the situation today.

In my experience, dedicated e-mail clients like Mozilla Thunderbird far exceed Gmail in both speed and capabilities. Some people may disagree, and if Google ever adds a true threaded view to Gmail, it may be worth another look, but I don’t know. I also tried out Google’s spreadsheet, and while it seems very nice, it lacked a couple of things I use in my daily spreadsheets. Perhaps the biggest problem with any of these applications is that they don’t work too well on older machines with limited processors. Making these web applications respond as quickly (or more quickly) than local applications is going to be an important key to making web-based applications the force the powers that be want them to be. But like it or not, these applications are here to stay, and will almost certainly become a more important aspect of our daily lives in the coming years.

As any music fan with a large collection knows, managing that collection can be somewhat difficult. Inevitably, the user who wants to listen to his entire collection ends up using a generic shuffle method in his media player of choice. This isn’t too bad, but let’s face it, you like some tracks far more than others and would like to hear them relatively more often. A brain-dead completely random shuffle system simply doesn’t cut it.

That’s where IMMS steps in. Originally developed as a plugin for XMMS, it has now developed into a more general system for various media players (though as of this writing, the only provided plugins are for XMMS, the now-defunct BMP, and Audacious).

IMMS does a few things for your listening experience:

• Based on whether or not you skip a song, whether or not you manually choose a song (as opposed to it being automatically selected), and some potentially more esoteric data like X idleness, it over time automatically calculates ratings for your music. It’ll take a long time to get any useful data, but it works reasonably well.
• Using these ratings along with other information like song similarity and correlation (how often two songs are played together), it automatically chooses songs that you’re more likely to want to listen to. It also has other heuristics to ensure that new songs are more likely to be played and that songs that haven’t been played in a while also get a fair shake.

There are still a couple of disadvantages. First, if you skip a song before the system selects the next song (which takes about ten seconds on my machine), it’ll think you manually jumped to whatever’s next, so you better take it slowly. Second, the number of media players is limited. There has been some murmurs of plugins for XMMS2, Rhythmbox, but nothing’s come of it yet. (Technically, I’ve written a very buggy interface to XMMS2, but it was pre-collections and tends to need to be restarted often. I’m not even sure it still works with current releases of XMMS2, but I’ll provide it upon request.)

Note to media player authors: manual ratings aren’t cool. If I have thousands of tracks, I really don’t want to spend the time rating them manually. Even if I did, this information should be able to be deduced, and they’ll end up being far more accurate than any manual rating I do. Though comparing every pair of tracks and determining which I prefer might provide an interesting statistical exercise…

Yet another year of the Google Summer of Code is upon us. Just yesterday, the list of mentoring “organizations” (many of them are not actual organizations in any traditional sense) for this year was released. From reading around on places like Planet GNOME, it’s apparent that some projects that I would have thought made good choices were not accepted into the program. Nonetheless, the list this year contains numerous different projects spanning a wide variety of areas.

Personally, there are a few projects that I’m interested to see what happens with. The number to list is too large, but some that strike me immediately are git, XMMS2, and gaim. I can only hope things go better than they did last year, though. A lot of good work was done last year, and there were some very successful projects. However, some of the ones that I was most interested in upon reading the accepted projects list vanished into thin air over the summer, and that turned out to be quite disappointing, because some students had some really neat ideas.

So, if any SoC applicants happen to be reading this, please don’t vanish (medical, family, and other similar problems excepted). If the project you take on seems too big, don’t hesitate to ask your mentors for help, especially with the design phase. As a developer myself, I know how difficult getting started on a project can be, but once you do manage to get past that initial design phase and get a good base built, you’ll find that the project moves along much more smoothly. This goes for everyone, not just SoC students. Second, if you don’t get accepted to SoC or are ineligible to apply, don’t let that stop you from contributing to a project you find interesting. Open-source projects are almost always looking for more talented and passionate developers, and Google SoC or not, you can still make great contributions.