Friday, 12 May 2006

Bad Choices

I was reading an interesting critique of the KDE Phonon framework and its comments. Without taking sides in that particular debate (although adding a layer of abstraction over complex frameworks that themselves are basically the same sort of abstraction over other components gives me a very queasy feeling), I do feel like ranting about comments like this:

It also lets the user choose whatever he or she wants. If a user likes Xine more than GStreamer, he or she can choose to use it.


ALERT! Most "users" have no idea what a multimedia framework IS. They don't know which one they're using, or which one they should be using. Pretty much everyone just wants something that works out of the box. If the user is ever forced to understand multimedia frameworks and choose one, just to get things to work, then something has gone catastrophically wrong.

I sometimes hear the slogan "Free software" (or "Linux") "is all about choice" used to defend this kind of diversity. That is a very misleading statement. Free software gives you all kinds of choices about what you can do with code, but a lot of those choices are bad ones. Sharing code has many advantages over forking or duplicating --- mainly avoiding wastage of development resources, but also simplifying deployment and support, and avoiding the need to pile on abstraction layers like Phonon which have their own costs. You shouldn't fork or duplicate unless you have a very good reason. Interestingly, we see very few forking decisions, and those we see seem to have good reasons behind them. Sadly, we see a lot of duplication decisions and mostly their justifications don't convince me.

[It could be that there are actually a lot of forking decisions but forks get resolved quickly (by all but one of the forks dying or merging back), while duplications don't. I wonder...]

This is particularly important when dealing with libraries and frameworks which other components depend on. If we have five MP3 players, that's not a terribly big deal. But if we have five GUI toolkits, then every GUI app has to choose one of those toolkits which encourages the creation of four clones of that app, i.e. more fragmentation.

Anyway, offering users a choice of which largely-equivalent desktop to use, or which multimedia framework to use, or which of five dozen crappy text editors to use*, isn't doing anyone any good compared to what could have been if those developers had pooled their efforts. It's far too late for the KDE/GNOME breach to ever be healed, but I still wish for consolidation in other areas of effort.

[* I have yet to find one Linux text editor with all the features I want. If the authors of some of the dozens of text editors out there had instead contributed to an existing editor, I think I'd have a better chance.]


Monday, 8 May 2006

DVD Madness

Apple and the "entertainment industry", you really clock my goat.

In the USA we bought a number of DVDs. We moved back to New Zealand and would like to buy some more DVDs, and also borrow some from friends. The region code control on our iMac's DVD drive prevents this; we have to choose to activate it for region 1 (USA and Canada) or region 4 (Australia, New Zealand, Mexico, the Caribbean, and South America) and you are only allowed to switch a few times.

What's really annoying is that these artificial constraints on what customers can do with their property don't actually achieve the goal for which they were designed --- to allow DVDs to be released to different markets at different times. In New Zealand (and as far as I know, every other country outside North America) all DVD players you buy in shops have been modified to ignore the region system, and are openly advertised as "multizone". (We don't have a DMCA here so I believe that such modification, done by non-contractually-bound third parties, is legal). If the purpose of the region system was to prevent DVDs released first in the USA making their way to other markets "early", that's evaporated.

Well, there is one class of drives that's not pre-modded: DVD drives in computers. But it's easy to find and download firmware and/or software hacks to get around those. In particular, DVD-playing software such as VLC and the Xine/mplayer stack can actually just crack the region scheme cryptography in real time. That's how I played DVDs in my Linux PC back in New York.

But it turns out that one group has been singled out by Apple and the DVD industry for punishment: owners of late-model Mac hardware. Newer Macs include Matshita drives that are apparently exceptionally difficult to mod, and for which no modded firmware is available. Furthermore these drives forbid access to the raw DVD data if there is a region mismatch, so the VLC and Xine/mplayer approach doesn't work. Foiled!

I could go out and buy a multizone do-everything DVD player from a local mall for 80 NZD (about 50 USD). But then I'd have to buy a TV to plug it into. And then I'd have to buy some furniture to put the TV on. And I'd have to start making and enforcing rules about our children's access to it. That's not appealing, although we may end up going that way.

I could buy an external DVD drive for my Mac and mod its firmware, but I can't find one under 300 NZD.

I could borrow a PC and rip all my DVDs onto blank disks or a portable hard drive, but that's a pain and would potentially lead to copyright violation, something I really want to avoid.

So, Apple and the entertainment industry, consider me one extremely dissatisfied customer. The Mac's been fun but I don't think I'll buy one again.


Friday, 5 May 2006

Assorted Thoughts

As a vehement opponent of monopolies, I am glad to see that the New Zealand government is taking a hard line against our local telecommunications monopoly. Yay!

The news from Iran gets increasingly more depressing. I'm amazed nuclear weapon technology has been contained as well as it has for the last sixty years ... just think, nuclear weapons are nearly as old as television and older than general-purpose computers. But the nuclearization of India, Pakistan, North Korean, and now --- seemingly inevitably --- Iran may indicate that we're reaching a tipping point. I just can't see a good future for a world of loose nukes. New Zealand may be one of the best places to be, but that's not saying much. Christians, start your prayers.

I've been fixing random Mozilla bugs lately, mostly regressions plus a few security/stability issues. I've also been spending a lot of time reviewing Darin's event/thread rewrite. It's great stuff which will simplify our code, fix a lot of bugs, and seems to improve performance.

Over the last few months I've also reviewed a lot of SVG fixes --- the SVG issues that I highlighted in February are largely fixed! A lot of the remaining performance issues are lower-level problems with cairo and platform-specific rendering code.

Now that SVG is getting cleaned up, I'm hopeful that Brian Birtles and the rest of the SVG crew will be able to look at updating and landing Brian's SMIL animation patch without much more delay.

I'm trying to finally land a patch which will unify all documents into a single view manager hierarchy. This will let you do things like have the browser stack translucent XUL elements over content windows. Every time I try to land it, we encounter performance problems, and my attempt tonight did too, so I backed it out. I did gather some data so hopefully I'll be able to figure out what the problem is and get it right.

I've started working on pulling plugin windows up to the top-level window. We should be able to do it in a way that also lets us compute visibility information for plugin windows, so you can have a DIV with a solid background actually render on top of the plugin window --- by clipping a hole in the window where the DIV needds to appear. It's not hard in theory but as usual the devil is in the details, getting reasonable performance and dealing with fallout from touching the fragile, platform-specific plugin handling code.

I've installed SuSE Linux Enterprise Desktop 10 (hope I got that right!) on my desktop and laptop. It's very slick. Xgl and compiz look fantastic on my laptop, and work flawlessly with my ATI graphics hardware, but I've had some problems with my desktop's NVidia setup ... this is ironic because NVidia has usually been considered reliable and ATI the problem child of Linux graphics drivers. I have to say that due to some combination of Xgl, compiz, the fonts, the default theme, and my laptop's high-density screen, my laptop now has the sexiest-looking graphical environment that I've ever used (and I'm writing this on an iMac at home). I wonder what more Windows Vista will offer that required Microsoft to dictate massive changes to their graphics stack and onerous hardware requirements, not to mention spend so much time developing the thing.

One thing that I really like about compiz that you don't see in the demos is that it grays out windows that aren't responding to events (a lovely effect, it makes the window a little darker and turns it black-and-white). This is a real usability win; you know that the application is not going to be responsive, so you don't keep clicking on it in hope, and there's no uncertainty about "maybe it didn't work because I clicked in the wrong place". Even better, you can see when it becomes usable again without having to periodically click on it to check.

One effect is still missing ... applications that crash just disappear abruptly. Abrupt shutdown should make the application's window explode in a realistic particle simulation.

Another Mozilla thing I'm planning to work on soon is getting the new textframe code into the tree so we can get people working on improving it in multiple directions. Before I do that I want to simplify the way textframes and inline reflow handle some corner cases, which I'll talk about in another blog post.

Update: By popular demand, I've made a screenshot. Because a great deal of the sexiness is the animation, you really need a video, something I can't be bothered doing (and which would probably get me booted off weblogs.mozillazine.org). All you can see here is the obligatory cube in action, plus window drop shadows and translucent window borders. Because the cube sides are lit, the actual desktop is considerably brighter than you see here.

Here's another showing the desktop in normal mode. Here I've stopped the OpenOffice process to demonstrate the grayed-out effect.