[Gllug] ObNaive: Why don't Linux systems get package database rot? Or do they?

[Nix]

On Mon, 11 Sep 2006, Christopher Currie yowled:
> It struck me that with the use of large and frequently updated binary 
> databases for system-wide package management on Linux distros (or at least on 
> some, e.g. /var/lib/rpm/packages), there must be some risk of similar errors 
> and degradation which might corrupt package installation and hence, 
> eventually, the system. Or isn't there?

Yeah. The binary database you should be most worried about is called
`the filesystem'.


Being less facetious, the problem isn't with binary databases per se: as
long as they have decent tools to access them (as filesystems do), and
have decent recovery tools, you'll always need them at some level. The
problems with the Windows registry are multifold, and none are directly
related to its binary nature.

Firstly, it is *opaque*. Its format is poorly documented outside
Microsoft, and should something go wrong with it recovery is exceedingly
difficult. Compare to filesystems: ext3 has everything from fsck to
debug2fs to dd to (if all else fails) screaming on l-k, then bzipping it
up and emailing it to Ted Ts'o :) (this works extremely well in my
experience: the tytso.ko module can solve problems that no other OS
facility I've ever seen can. Of course its latency is rather bad
compared to most kernel modules, but, hell, it only has one Conscious
Processing Unit and I hear it has to spend over a third of the time down
for routine maintenance. ;) )

Secondly, while the registry's supposed to be accessed only via the
registry APIs, in practice in the past many programs have accessed it
directly, with the results you'd expect. (Again you don't see this with
filesystems!)

Thirdly, it's got poor affordability (in common with much of the rest of
Windows). There are very limited tools to access it in any sensible way,
and its format is extremely impoverished (there's no equivalent of
comments, for instance, so you can't decently document your changes, and
as for keeping the thing in version control, forget it). It's hard to
even tell what permissions are attached to a key... compare to gconf,
with multiple backends, a (third-party) FUSE module to turn it into a
filesystem, and, if not comments, at least *documentation* for every
key.

But gconf shares the next failing, which is that applications tend to
install keys and never remove them again. Of course this doesn't
normally cause system config errors, but it can slow things down.
Eating disk space isn't so important these days, the registry uses
hardly any of a modern disk, but it *does* interact badly with MS's
awful roaming profiles kludge, making logins take forever if your
registry is large (hey, guys, what about Samba-shared home directories?
Oops, no can do).

The major cause of windows rot that I know of is the absence of anything
comparable to LD_LIBRARY_PATH, /etc/ld.so.conf, symbol versioning, or
decent shared library versioning, combined with the Windows world's
propensity to ship copies of critical DLLs with everything you can think
of and install them over the top of what's already there. Generally old
DLLs don't get installed over old ones, but what *does* happen is that
API compatibility isn't maintained well, so that the new DLLs may well
include changes in semantics which break the older apps... and because
it's all closed-source and has no decent diagnostic tools (outside the
MSDN CD) you can't tell why. I had OS/2 rot once: OS/2 had exactly the
same failing from exactly the same source.

I'm glad I'm away from that mess.

-- 
`In typical emacs fashion, it is both absurdly ornate and
 still not really what one wanted.' --- jdev
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug