The problem with Ubuntu, however, is that with the frenzied pace of development and the releases being churned almost twice yearly, I am quite certain that most of the bugs reported for this release will be ignored or will be prioritized “Low”, meaning they are kept for “later” (read: never). While this is an issue with even slow-moving projects, I am (or at least, was) quite impressed with the way Ubuntu maintained quality till Hardy Heron. Most of the packages “Just worked” post installation, with a few hiccups here and there. Hardware, drivers and graphics did remain a concern, but that is something we have to live with for a while, given the low interest of manufacturers for providing Linux drivers.

Anyway, back to the point: The current pace of development for Ubuntu guarantees a lot of loose ends in newer releases. In contrast the Debian community goes for “release when ready” philosophy. However, they suffer from delays and more delays in releases, leading people to believe that Ubuntu is the right way.

Which brings the question, what, really, is “the right way”? Most will consider a “middle way out” but that is easier said than done. Granting developers’ request for more time on the basis of an incomplete feature or a yet-to-fix bug list will eventually lead to a heavily-delayed release. On the other hand, having a strict deadline means that you are ready to compromise on the quality of the release. While this matches the “release early, release often” philosophy^*, there’s a slight disconnect when it comes to having a product eager to replace Microsoft Windows, as is described in… Bug #1 for Ubuntu.

Microsoft has a majority market share in the new desktop PC marketplace. This is a bug, which Ubuntu is designed to fix.

Back to the point (again), Paul Graham also corrects the general perspective for “release early”:

By “release early” I don’t mean you should release something full of bugs, but that you should release something minimal. Users hate bugs, but they don’t seem to mind a minimal version 1, if there’s more coming soon.

So far, I don’t see any awesome release philosophy with a strong way to maintain the pace, while maintaining the quality. All we can do, maybe, is to have an in-between release to just “fix more and add less”. This is where developers may find themselves in bug-fixing mode, instead of their favourite “building that cool app”, but its all for the greater good, no?

The major problem was with my ATI drivers. Never a good thing to mix ATI with Linux, I have learnt. But maybe the lesson came a bit too late as my Motherboard I bought a year ago has got the RadeonExpress 1250 onboard graphic card which is already in “Legacy” mode!

The downside is that the newest generation of the driver doesn’t support any of the “older” ATI chipsets, which at this point include the R300 through R500 chipsets.

The proprietary ATI fglrx driver won’t support the new kernel. Need to make do with the open source drivers. Fortunately, they are a good fit for 2D graphics with a good resolution. Bye bye, Compiz, for the time being.

Having settled with the “basic” look and feel, I also find some problems cropping up in the package repositories. A guide for installing the good old Tomcat server makes a pretty frank statement before proceeding with the installation procedure:

If you are running Ubuntu and want to use the Tomcat servlet container, you should not use the version from the repositories as it just doesn’t work correctly. Instead you’ll need to use the manual installation process that I’m outlining here.

This is probably not unique to Jaunty, but nonetheless, the general trend now is that I do read a bit online before installing anything from the repository. Be it Amarok, the version 2 of which isn’t very well received, or Tomcat, or Eclipse.

Wine, which was working wonderfully in Hardy, seems to be broken for some reason in Jaunty. All I get is 2 seconds of screen flicker, whenever I try to load any program. Need to google on this a bit more in detail. But a quick search points in the direction of my graphics card (again!).

I am left wondering why I upgraded at all. Maybe it was the faith that with Ubuntu, newer version numbers always mean more happiness.

It’s not that Ubuntu has let us down. Although a lot of posts are floating about regarding Ubuntu pre-release testing being inadequate, there is actually too much on the plate to test with. A multitude of hardware chips, file systems, desktop environments, applications, each with their different versions, is a pretty daunting task. I just hope that every once in a while there is a release in which the dev folks take a step back and look at how usable the OS is, and whether it “Just Works”

Your blog, like your email or your Facebook profile, is your online identity. Yes, that’s why we have an authentication system, but sending plaintext passwords to the server isn’t a great default setting. Well, going for a security certificate for something as basic as a blog will be too farfetched, but the nice CHAP protocol is good enough for all our secure login needs. And it is available as a WordPress plugin thanks to redsend.org. Yay!

So there you go. Not a single line of code written, and your wordpress login is secure, even when you go wireless. That wasn’t so hard!

The other security feature that we need is protection from comment spam. This is a more commonly known problem, as you can “see” your blog being misused, unlike in the situation explained above. There are a hell lot of spam protection plugins available. You can either go for a strong Captcha system like MyCaptcha, or prefer to go easy on people kind enough to comment on your post and filter out spam automatically, using Akismet or Defensio. I prefer the latter method and it has been pretty accurate till now.

That’s it. Your wordpress installation is secure from all the bad guys. Well, most of ‘em, anyway. There’s nothing like investing five more minutes after the five-minute install for a bit of security. Blog safe!

Yet, it’s never too late to thank anyone. (Adapted from V for Vendetta: It’s never too late to apologize)

Akismet has shown how we do not always require captchas to curb bot-generated random spam. But it is not ideal for big websites, mainly because

• Its a program after all. There’s every chance that it can make mistakes.
• Genuine comments suppressed by Akismet are not that bad for a website. But spam comments for enlarging body parts to impress her, which pass through Akismet and shine with a glow right below an article don’t look good at all.
• There’s that tiny increase on server load everytime a comment has to be analyzed by Akismet. And if this hardly-visited and never-linked blog (as of today) has fought with 1000 spam comments, we all can imagine what the battle will be for a website which gets “slashdotted” or “dugg” every few seconds.

• Captchas are irritating.
• Captchas are irritating.
• Captchas are irritating.

That’s three good reasons right there, the last one being most important . While I have enough server power, I will try to minimise the hassle of looking through bleak bent text with a mashed grid or circles or airspray.