LevelsOfDetail

I guess this is a sequel to my previous posts about running Feisty on my X60.

Except there isn't really much to write about. Things worked mostly out of the box. The only recommendation I'd have is to tweak the font settings (System > Preferences > Appearance) so that you use subpixel rendering and full hinting. It looks like Ubuntu finally included the subpixel rendering patches that everyone who cared was already using anyways, so you can get pretty good results with a simple configuration change.

It's still not perfect.. especially for fonts that don't have good hints (and Arial still looks like crap), but it has pretty much gotten to the "good enough" level for normal use for me. One big improvement is that the text, when viewed off angle on my X60 screen don't look nearly as crappy as they used to. The degrade pretty much along the same lines as XP.

Compiz worked out of the box, and I didn't have to set any drivers or anything. I had to explicitly enable the wireless driver, but after doing so, it's been working fine. Suspend and resume seem to work ok. I've had one issue in mabe 20-30 cycles.

Docking and undocking still doesn't work out of the box, but it seems like there might be hope for this one. I'll have to work on it later.

HDAPS, the harddrive protection system seems to exist in a half-baked state. "hdapsd" the daemon that monitors the hdaps output and parks the hard drive has a package in the repository, but the default kernel seems to lack the patch that actually allows this to work. Here's the bug that talks about this. On the bright side, it looks like people are actually working to include a real patch that has a chance of getting upstreamed, so maybe by the time Hardy comes around, it'll work.

Overall, a pretty good improvement, though I hear lots of users are running into upgrade issues. Since I didn't really use Feisty on this machine much, I did a clean install, and things seemed to work as about as well you could expect.

Ok, here's my first post using the MT4 interface.. Upgrade seems to have gone mostly fine.. except where did my categories go? I hope I didn't lose them..

Nevermind, the interface just looks different.. Ah, progress.

Update: beware the templating changes.. apparently MT4 templates are way different from MT3 ones, and blindly picking a new MT4 style in the style chooser will lead to very weird results. Here's a post about how you might actually go about upgrading your template.

Finally found some.

These are the standard "core fonts" like 6x13 that come with any X11 distribution, converted over into .FON and .TTF files so that they can be used in Windows. Particularly useful if you want to make your PuTTy really look like an xterm.

With Gvim, one can finally use the whole color space (not just 16-colors) to do nice code syntax highlighting and such.

Unfortunately, actually developing a good colorscheme is pretty difficult and tedious. That's where this page comes in. It lets you browse a bunch of canned color scheme files, rendered against some sample code. See one you like? click the link, download the .vim file into your ~/.vim/colors directory (create it if you don't have one), then in a gvim session, issue the command :colorscheme foo where foo is the name of the file you just downloaded, minus the .vim extension.

One quick note, sometimes these files are DOS formatted, and unix gvim doesn't seem to like them. To fix this, open the file in vim, and then issue the command :set fileformat=unix, and you should be good to go.

My personal favorite is 'camo'. It's a nice dark brown look that doesn't have any obnoxious neon colors.

Time again for my periodic trolling around the net for "Linux on the Desktop" articles.

In this episode, I refer you to this Infoworld article, which talks about why Linux desktop hasn't succeeded yet. The author, Randal Kennedy, claims that because of the development structure of Linux (how distributions serve as aggregation points), when a problem arises, it is difficult to figure out who is accountable, and users are often forced to fix things themselves.

Although many of Kennedy's posts are somewhat uninformed and purposefully inflammatory, here is some merit to this particular argument, but I think I can expand on it a bit more. I think the real problem is that, essentially, each distribution is a fork. While the underlying source code may be mostly similar among distributions releases around the same time, there are enough technical differences between distros (which compiler? which libc? which gnome? which kernel?) such that for all QA and testing purposes, these are different entities. As any software developer knows, having more "products" proportionally, and sometimes geometrically, increases the QA "matrix", i.e. all the possible scenarios that need to be tested.

So here we have an ever increasing community of Linux users that can all help each other out. The more people there are, the less testing a distributor should have to do right? All the testing gets spread out among the users, right? The users submit bugs and sometimes even fixes, and the collective effort ensures the overall quality of the product, right?

Well, sort of. The twist is that because distros are essentially creating unrelated products, the more distros there are, the more QA work that is needed. More generally, while free software allows for an infinite matrix of possibilities, this also means that there are an infinite number of scenarios that need testing.

At the end of the day, it's not clear to me that open source software, developed by many, but also "forked by many", and thus tested in very inconsistent ways, can produce the same quality as commercial software, which is developed by smaller groups, but also more focused and tested well. You can think about it as the ratio between the possible configurations of your software and the amount of testing resources you have. It's not clear that the ratio is any better for open source software developed by the community as it is for a single company developing a commercial product.

Just because Ubuntu or Fedora comes along and says "we're going to make something that just works," doesn't mean it's gonna happen. Sure that's obvious, promises are just promises. But I think that even the core approach that they're taking -- being selective about packages and applying distro-specific patches to smooth out the rough edges -- is insufficient.

The real way to produce better quality free software is to avoid as much as possible the multiplication of testing scenarios. What does that mean? It means getting rid of unnecessary choices. It means eliminating meaningless differences. It means a lot more cooperation between Fedora and Ubuntu, and whatever Gnome-based distro that comes next, to make sure that all the common parts they use are built in the same way and tested in the same way. Does it really make sense for Fedora and Ubuntu to have different kernels? From an end-user perspective, of course not. Same could be said for the version of gcc, or the version of glibc, or the version of gnome or kde. What it really means is that these distros should look more similar than they are different, especially if the differences are not providing any clear value.

Sure, there are scheduling issues and such. Distros pick versions of software that are available when they release. But from a user perspective (and even I would argue from the developer perspective *) version differences for software that was released within the same year are usually not that big. Either distros should coordinate when they release their software, or they should coordinate which versions of software they decide to include in their time-based releases.

The sad part is, it is the very open nature of Linux that makes me pessimistic that any kind of consolidation will happen. It requires an immense amount of discipline to keep yourself from adding an incremental new feature that breaks compatibility or increases the testing load significantly. Few FOSS projects have such "self control".

At the end of the day, it may just be that someone like Ubuntu will create such a following that it, by itself, can realize the scale needed to make community based wide testing coverage possible. But as evidenced by many of the small problems that exist even in the latest Gutsy release, we're not anywhere close yet.

* by this I mean that to a developer, a new distro releasing with slightly older components is a reasonable trade off, if it means that it reduces the amount of variation that the developer needs to support between distros.

I'm sure nobody cares about this. I'm just writing it down because it took me way too long to figure it out.

I've had my new PC for about a year and a bit now, and I've never been able to resume from S3 sleep using the keyboard. I originally thought it was an X64 problem. I briefly used a PS/2 keyboard which had a dedicated wake up button, and that worked, so I figured there must be some way to do this.

BIOS settings:

• Standby Mode: S3 only
• Plug'n'Play OS: Yes
• USB Legacy Emulation: Disabled

Not really sure even if all of these actually matter. The first one definitely does.. setting this to Auto causes WinXP to do weird things (namely refuse to shutdown any time you have the "allow this devices to wake the computer" checkbox checked for any USB device).

Finally, the most important part is to add a registry key described in this Microsoft KB article. This tells XP that it's ok for it to enter S3 even if you have a USB device that's set to wake up the system. Why is this needed? Well according to the article, older bioses and devices were too crappy that this feature didn't work well. Going into S3 would sometimes kill the power altogether, or result in other undesirable side effects. They're solution was to say, "if you want to wake from a usb device, then you only get S1".

Well it turns out that without this special flag, and a BIOS that is set only to support S3, the device manager stops even showing you the "Power Management" tab for each USB device's properties screen. This is the part that the KB article doesn't tell you, and that had me stumped for a long time.

For posterity, here is a .reg file that you can use to add this key to your registry.

Found this as I was reading about the supposed Comcast Bittorrent shaping controversy. A quick guide to enabling protocol encryption in the most common bittorrent clients, so that the upstream shapers can't inspect packets to find bittorrent traffic.

I'm pretty sure I understand almost everything there is to understand in terms of font configuration on Linux. While configuration is a mess (qt settings, xft settings, xrdb settings, fontconfig settings, gnome settings), the even more frustrating part is that even if you understand all this settings, the result you can get out of it is still not that great.

It turns out MS has put a huge amount of time into making fonts look good on low-res displays. This comes in the form of TrueType hinting, as well as the ClearType rendering method. While the most recent Ubuntu release has both of these partially implemented, the output still does not match the quality found on XP or Vista. (and XP is how many years old?)

But if you step back a bit, you just realize that this is a really hard problem. The fact that there is a whole interpreter infrastructure just to help you render fonts on low-DPI displays is evidence of this.

But how did things end up this way? I tend to think that it's because of MS's emphasis on backwards compatibility, and the fact that their original API's were not resolution independent. In combination, this means that even on a brand spanking new computer, if you run old code and at the same time try to set the DPI really high, you get bad results.

But the real point I'm trying to make is that support for high-DPI gui's might be a way competitors can displace Microsoft on the desktop. Both Apple and Linux have a smaller set of legacy apps, and also have better architectures for possibly supporting DPI scaling, even for older apps. While new Windows technologies like WPF have DPI-scaling built in, as long as commonly used apps aren't ported over, the DPI problem will continue to exist on the Windows desktop. Apple could conceivably transition most of their own programs over in a few releases. Linux might take a bit longer, but the core pieces are already there (automatic layout of GUI's and technologies such as SVG that enable the smooth scaling of bitmaps and the like). In fact, I'd wager that even today, you can probably get a better experience on Linux using a 200 DPI display then you could on windows, just due to the extra configurability.

Supporting high DPI displays also gets around one of Linux's main problems. When the resolution increases, technologies like TrueType hinting and ClearType become irrelevant. Font rendering becomes relatively simple and -- at a high enough DPI -- better than anything ClearType can produce at lower DPI's. This could be an area where Linux's flexibility could lead it to bring a much awaited technology to masses, faster than Windows can, and in the process win over a few converts.

Of course, given the way things go, Apple will probably get there first.

So I've been playing around with the Firefox 3.0 Beta 1 download today. But I'm somewhat concerned by what I can only describe is a regression in font rendering. Here's an image to illustrate.

On the left is Firefox 2 on my Ubuntu system. On the right is Firefox 3 beta 1. In both cases, I use the autohinter with slight hinting, and the font you actually see is Droid Sans. You can notice, however, that the the image on the right exhibits more color fringing than that on the left. In particular, look at the vertical stems of letters like 'h' and 'i'. The right image shows a much more salient blue fringe.

I double checked to see if maybe the FF beta comes with its own copy of freetype or pango or cairo, but it looks like it's linking the system copies. That means it's somehow using LCD filtering, but specifying a different color filter? Anyhow, here's to hoping that it doesn't make it into the final release. Or that I'm just missing something.

Update: Looks like someone beat me to reporting it.