There's been a bit of turmoil in the Amarok and KDE communities the past week with Amarok's decision to only support MySQL Embedded in Amarok 2. Jeff Mitchell has written about the Amarok design decisions made.

I'm a little bothered by this, as it forgeos all the "semantic desktop" work that has gone into KDE 4, namely what's provided by the Strigi and Nepomuk libraries. One thing the whole semantic desktop concept entails is that other applications will be able use data another application stored, but without care to what that other application was or how it was stored. For example, I should be able to share the list of all tracks in my music library, how many times I've played tracks, what tracks I think are my favorite, etc across music players. This kind of abstraction is, obviously, good for users, but bad for developers of proprietary software. They don't want you to easily switch between applications that they do not control. Amarok switching to it's own database store is a stab at this kind of desktop interoperability. I've my own thoughts to add, though, that support what the developers are doing...

Amarok is an awesome application. Dare I say, it's a killer application on Linux---on several occasions this past year I've recommended people install Linux just so that they could play with Amarok and see how much better it is compared to what they were using (yes, I'm looking at you, iTunes).

Before Amarok, I used Music Player Daemon (mpd). I stopped using it after a while: the playlist management wasn't very good; it would eat those playlists that I spent a lot of effort to make; the GUIs available at the time were lacking; and it was very slow when working with tens of thousands of songs. Some of this may have changed but I've not been motivated to look back.

Enter Amarok: I switched because the playlist management was so much better. I setup a MySQL server on my workstation to store metadata, as SQLite was much too slow. Amarok backed with MySQL is very fast---I dare others to find a library-based music manager that is faster with the number of songs I've thrown at it.

Balancing desktop interoperability with performance is a delicate balancing act. Interoperability is the hot thing these days---look at how Apple's line of integrated software and hardware continue to sip market share from the Microsoft-powered desktop. But when it comes down to it, performance and other more perceived benefits are going to win out over desktop interoperability. The Amarok developers' decision to go with MySQL embedded is a good one that will hopefully keep people moving to Amarok over proprietary alternatives.

News from a couple days ago: both Microsoft and Nokia are now including the jQuery Javascript framework as part of their development kits. That is: jQuery will be part of Microsoft's ASP.NET AJAX framework and be available for use in applications written for ASP.NET; and jQuery will also be distributed on millions of Nokia phones.

Defacto standards, I believe, are a good way to inform the development of real standards. Standards developed the other way around, at least in the tech industry, have had a habit of taking a very long time to reach end consumers... for example, how many decades has it taken for your average web user to gain access to a fully CSS2-compliant web browser? How many more decades will it take for OASIS's OpenDocument format to supplant Microsoft Word and its *.doc files?

Hopefully, this is the beginning of a path that will lead to jQuery's inclusion into the Javascript language, as well as initiatives that will improve jQuery's performance.

I like the fact that Microsoft and Nokia are not trying to reinvent the wheel, and roll their own Javascript frameworks. Sun did this with Java Server Faces. A frequent lament with JSF is that it's nearly impossible to customize any of the widgets. There is too much complex, custom Javascript, and the adoption of the frameworks used makes figuring out how to work with them difficult.

Also, as others have noted, this is the first time Microsoft itself is distributing an open-source project with one of their products. A sign of things to come?

O'Reilly Radar has an article written by Dale Dougherty, a roundtable set of opinions on whether the war on spam can be won. Rafe Colburn also has his own response.

Rafe's solution is to use GMail. In the Dougherty's article, Paul Vixie mentions that the internet is going to become a "walled garden;" relying on proprietary technology provided from a single company is the same thing in my eyes. There's no way I'm going to advocate a proprietary solution for something as important as my e-mail.

Eric Allman mentions DKIM, which I think is an excellent weapon in the war on spam. I'm not using it however, as it doesn't fit in with the way I use e-mail, and MUA (e-mail client) and MTA (e-mail SMTP server, essentially) is extremely sparse.

My unfortunately ineffective and impractical solution to this problem is use of PGP. Besides identity verification via digital signatures, it is also a generic platform for encrypted digital communication, and provides a distributed, robust trust model. Unfortunately, its learning curve is high, and that is why it's basically been a failure for the past 10 yrs.

Though, lack of user education is why the spam problem keeps getting worse too. It's users who click links in spam e-mail; it's users who allow spammers to take over their machines through their negligence in applying security updates; it's users (sometimes) who allow their identities to be stolen.

Fredico M Quintero pointed out some serious flaws in GNOME's font configuration dialog; the Novell Product Design wiki also describes some problems. In a sentence that fits in with what I believe is GNOME's “simplicity mantra”, GNOME should just get rid of its useless, confusing fonts configuration dialog.

Why does it have a font configuration dialog anyway? Well, unfortunately, GNOME's setting daemon completely ignores several fontconfig settings and instead uses its own settings for things like antialiasing type, whether hinting is used, DPI, etc. You need the font configuration dialog to change these settings, or you have to dig through gconf. Most of this was put in place probably to subvert a broken X setup; instead of implementing these hack-ish workarounds GNOME should instead push to fix X instead.

It's extremely difficult to discern the difference between the different types of antialiasing. GNOME's dialog doesn't let you select arbitrary text, or let you render text in-place so that you can quickly compare between different antialiasing styles and subpixel orderings. These settings, along with DPI, are unlike the rest of the settings in the font configuration dialog because they don't apply immediately. They only affect newly started applications, and the dialog does nothing to alert you of this.

Do users really need to be able to select subpixel ordering from a dialog? There are very few LCD monitors that do not use an RGB subpixel ordering. The very few people who rotate their LCD monitors into portrait mode (including me, see my past article Misery with online reading of PDFs and the need for portrait monitors) would use VRGB. Why not just set RGB subpixel ordering if the user is using an LCD? VRGB if their display is rotated? Again, these are things GNOME could discover by querying X...

Lastly, do users need to change the fonts used by their UI in the first place? The majority of Windows and MacOS X users don't deviate from the defaults at all—why would GNOME users be given a choice through this confusing dialog? GNOME instead should use the fontconfig aliases “Sans”, “Sans Serif”, and “Monospace” rather than letting users choose fonts. A fresh GNOME setup already uses these aliases as the defaults anyway.

Of the settings in the font configuration dialog users may actually want to set, whether to use antialiasing or not is the only one that sticks out to me as needing an option. I think that the dialog could be replaced with a simple, descriptive checkbox somewhere that read “Antialias text” that would toggle all the heuristics I've described above.

India's Ministry of Education has said that India will not take part in the $100 laptop project [The Register]. Quoting the news article:

Education dismissed the laptop as "pedagogically suspect". Education Secretary Sudeep Banerjee said: "We cannot visualise a situation for decades when we can go beyone the pilot stage. We need classrooms and teachers more urgently than fancy tools."

The Playground, as well as many Internet commentators, think this is "fair reasoning." I don't see how--who ever said the laptop would replace teachers or classrooms? How exactly would they do that--is this supposed to make any sense?

Yes, the $100 laptop is a "fancy tool." It is a fancy tool to facilitate a new age of electronic learning. Funds used to purchase these laptops should not be taken away from providing facilities and teachers, but instead on school supplies such as paper, pencils, and textbooks which themselves are generally expensive.

While India and much of the developing world may need more teachers and classrooms, yes, it's a completely different problem that the $100 laptop isn't meant to address. I'm waiting to see if there is valid criticism from India's government in the future.

Lenovo, the company that bought IBM's personal computer division, including the Thinkpad brand, has decided to no longer support Linux on their computer products.

I do not see how the customer benefits from this, because Lenovo is effectively offering its customers less choice. Supporting Linux tends to not cost anything up front and instead affects design decisions, decisions that lead to a better, more high-quality product. It is not as if much was spent on marketing Linux offerings, either.

This move is probably to appease Microsoft, who almost surely offers Lenovo discount Windows licenses for shunning Linux. This will improve Lenovo's bottom line, but will not give the consumer any more quality, any more service or support, and probably no change in price.

Of course, not supporting Linux has never stopped people from trying to run it anyway. But, think of it as a sign of things to come. No longer having any inclination to support Linux means that in the future they can go with completely proprietary components. Proprietary components that won't work in Linux, and are almost universally more unstable and buggy, on Windows and Linux, than their non-proprietary counterparts.

So, I'm calling this the beginning of the end of the ThinkPad's legendary quality. Smart move Lenovo.

Playing around with Ubuntu 6.06, I noticed that in the Software Preferences, that part of the default "Channels" (which are in actuality lines in /etc/apt/sources.list) include those for the Ubuntu's packages' sources.

I'm not sure why these are there by default... How many users actually need to recompile a package when the distribution came with a binary one? In my 5 yrs of using Linux, I've never needed to. Yes, I understand the whole free software and GPL thing, where sources must be available with software. This doesn't mean that new users (a large part of Ubuntu's user base) need to waste bandwidth and disk space on things they will hopefully never need to use.

I don't see the practical use for distributing sources with a distribution. If you do need to compile something to get an install up and running, you may need the source for one single piece of software, and you won't be going to the sources included with the distribution--after all, if their original binary package didn't help, what use is re-creating a binary for the same version? You'll be getting the latest version off the Internet and using that. It probably won't even be by the makers of the distribution, but upstream somewhere. E.g. ditching a vendor kernel for one from kernel.org.

With Ubuntu, I can't really complain much, as one only ends up downloading some relatively small text files. Back in the days when I used Redhat it was a different story: I'd spend a month downloading the latest Redhat ISO image, half of which was source RPMs that as a Linux newbie I had no use for.