Vista Aiding Linux Desktop, Strategist Says (eWeek)

Vista Aiding Linux Desktop, Strategist Says (eWeek)

Posted Aug 10, 2007 9:55 UTC (Fri) by nix (subscriber, #2304)
In reply to: Vista Aiding Linux Desktop, Strategist Says (eWeek) by drag
Parent article: Vista Aiding Linux Desktop, Strategist Says (eWeek)

One big example is how Linux uses ~/.filename and ~/.directorynames to store user preferences vs. Windows with it's registry. The Windows registry is fast as it's a pretty much always going to be in memory and is a tight little binary database, with Linux starting applications have to go and check the possible locations of dozens of little text files as they start up.. This is a huge penalty against Linux performance-wise as seek times on harddrives are dreadfull and is a chronic problem for slow starting applications (pay attention to disk I/O vs memory usage vs cpu usage when you start up a big application after a fresh reboot).

Sort of. This is never going to be true for big applications (the time taken to page in the app is going to swamp everything else, especially if you haven't prelinked so everything must be relocated too); and small apps generally pull in few enough config files that it doesn't take long and on subsequent runs they'll all be in the cache.

But there are some small apps which look for a huge number of config files in numerous places, many of which don't exist, so you end up with the short negative dentry caching slowing you down again. The thing to do for these apps is what KDE does: read in all plausible config files and write out a cache optimized for rapid reading speed (so one file, or a very few), then keep an inotify watch on the config file directories for as long as the cache exists so that if the config files are changed you can wipe and recreate the cache: then the apps' config-file readers read that cache instead.

(This is pretty much what the `ksycoca' component of KDE does. Unlike the registry, because the cache is transient and its sources are inotify-watched, you can pretty much always ignore the existence of the cache: it's not a fragile all-your-data-belong-to-us binary horror like the Windows registry. Plus we don't have to reinvent all the filesystem permissions and security stuff inside the registry like Windows does.)

Another approach (roughly that used by GNOME) is to read in the config files into a process which then tells interested apps what the value of configuration keys (or whatever) are. This eliminates the need for cache invalidation but adds the need for an IPC protocol and a nastier failure mode (if the inotify-watcher dies, nothing goes immediately wrong and the worst that happens is that configuration updates aren't detected until the cache is manually removed: if the configuration-state-storer dies, nobody can get at *any* configuration, changed or not, until it's restarted).

Of course it is *possible* to smash your Unix desktop in ways that require massive wizardry to recover: but you need to work at it (everyone has horror stories: my personal trial by fire was the time when a remove-obsolete-links script of mine didn't notice that * is left unchanged when it matches nothing, and, well, it ended up removing the contents of a client's /usr/bin/). On a Windows box you don't need to do anything special :(

(Regarding the 'easy customization' stuff: I agree so strongly that I use Emacs. :) I switched from GNOME to KDE when GNOME 2 came out entirely because GNOME's configurability plunged and I was no longer able to make it work the way I wanted to...)

---

(Log in to post comments)