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 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]
Name=Foo Viewer
Comment=The best viewer for Foo objects available!
Exec=fooview %F
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:
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: But there are also some significant disadvantages: 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.