Software and hardware annotations 2007 August

This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.

[file this blog page at: digg del.icio.us Technorati]

070830 Thu The .desktop file format

Unluckily I had to have a look at the specification for .desktop files which because of the Microsoft cultural hegemony laughably parrots that of MS-DOS .ini files, and I felt the usual outrage and sadness. It may be worthwhile to show how a less moronic format might have been like, by using the example in that page:

[Desktop Entry]
Version=1.0
Type=Application
Name=Foo Viewer
Comment=The best viewer for Foo objects available!
TryExec=fooview
Exec=fooview %F
Icon=fooview.png
MimeType=image/x-foo;
X-KDE-Library=libfooview
X-KDE-FactoryName=fooviewfactory
X-KDE-ServiceType=FooService

What's wrong with this ridiculous layout? Well, mostly that is not good for processing with pipelines of UNIX-style commands, in other words that it is not tabular, and never mind the presence of gratuitous spaces. Consider an alternative:

entry:1.0:application:image/x-foo:fooview:fooview $F:fooview.png:Foo Viewer:The best viewer for Foo

with perhaps lines of this shape to express the KDE-specific stuff:

entryext:1.0:application:image/x-foo:fooview:KDE:libfooview:fooviewfactory:FooService

My alternative version is briefer, easier to process in a pipeline, easy to sort (the order of fields has been chosen somewhat advisedly), easy to parse. Enough said.

070819b Sun Translucency in KDE 3.5

I have been upgrading piecemeal my Fedora 5 installation to version 7 (and encountering a number of RPM package mishaps, as that is not really support, but still), and the slightly newer version of the KDE in it, and as an experiment I enabled the translucency options, which I have always regarded as a bit pointless (I still yearn for greyscale high DPI portrait monitors) and so far my impressions are a bit mixed. The advantages seem to be:

Translucency for unfocused windows makes them less attention grabbing.
Translucency for windows being moved allows them to be positioned better.
I do not use click-to-focus and auto-raise for windows, precisely because I like the ability to keep the window that has focus (partially) under one that does not (for example when the top window has a list of files and the focused window under it has a shell. In this common case, that the unfocused window on top be translucent helps a bit.
Even shadows help slightly as a visual cue.

But there are also some significant disadvantages:

When a window becomes translucent it also becomes significantly dimmer; this sort of helps with making unfocused windows less noticeable, but it is a different effect from translucency, and they should be independent. There should be some at least partial compensation for that in the compositing manager.
The desktop becomes much slower (in particular switching virtual desktops is a lot slower) due to much higher CPU usage by the X server, even with cards with full RENDER and Composite extension acceleration; but the card I am using is an NVIDIA 6800LE and there is a known issue with the GNU/Linux NVIDIA drivers and speed of rendering antialiased characters, which uses the RENDER extension, so perhaps it is just that. However CPU usage is very high even for operations on the active window, which is 100% opaque, which suggests some less optimal coding of compositing.
Sometimes when a subwindow has focus (for example a menu) the main window is regarded as having lost focus and becomes distractingly translucent (and dimmer).
Loss of focus triggers transparency and the dimming immediately, which can be somewhat distracting when one moves around the cursor. This does not happen with click-to-focus.

So there are are some intrinsic points about translucency, and some that seem instead to be particular to the implementation I use and fixable. Overall I am going to try and keep translucency enabled for a while more, but so far the advantages do not seem particularly compelling to me, and the disadvantages are significant, in particular if one does not use click-to-focus.

070819 Sun Another advantage of eSATA

Well, I have about 1-2 months of draft blog entries pending somewhere, but have been inordinately busy at work. However here is a small note: from an informative discussion of eSATA hotswap under MS Windows there is a good point as to an advantage eSATA has that even FireWire 800 does not:

Also the "Turn off hard disks" setting in the Power Schemes functions.

In other words, power management works for external SATA as well as for internal SATA. As to the hotswap topic, it sort of mostly works under GNU Linux too, if one can remove and then reinsert the relevant SATA HA driver module. The hotswap discussion above makes indirectly a good point as to the difference between eSATA and SATA hot swapping:

Why Windows totally hangs up after the drive is powered?
It is confirmed to happen when the internal hard drive and the drive are sharing the same power cable. Looks like the internal hard drive restarts and reinitializes if the power becomes unstable, and therefore Windows totally hangs up accessing it. This can be resolved by connecting individual power cable to the drive which is being powered.

Now that should not happen because when a drive starts it draws a lot more power than during normal operation but this should not cause trouble on the other lines sharing the same rail. Anyhow eSATA is designed to avoid these issues by using an external power supply. Conversely there are quite a few systems where regular internal SATA connectors and Berg power connectors are exposed externally, and that's a much less good idea.