Software: OK, one of my current UNIX pet peeves, perfectly illustrated
by the new RPMs for KDE
3.2.
: jm 1015...; sudo rpm -Uvh *.rpm
Password:
error: Failed dependencies:
libiw.so.26 is needed by kdenetwork-3.2.0-0.1
I don't have a wireless card in this machine.
WHY does kdenetwork
, a network configuration applet, link with
a shared library component of the wireless-tools
package? Why is this
not simply a shell script, or even an optional binary command? Have the
UNIX desktop environments forgotten all about the UNIX way in their rush
to implement 'components'? To quote Doug McIlroy
:
This is the Unix philosophy. Write programs that do one thing and do it
well. Write programs to work together. Write programs to handle text
streams, because that is a universal interface.
(my emphasis added.)
Hint: if you don't intend to call some third-party code over and over
again several times a second -- in other words, so that performance is
essential -- you do not need to link against it as a shared library.
Calling it as a command, with fork and exec, will work just fine and
avoids this kind of 'DLL hell'.
A related issue is how this emphasis on binary or component ABIs impacts
scriptability and plugins. Ever since Netscape came up with their
plugins, we've had this new model that third-party application
extensibility meant linking shared libraries into the app (with ABI
issues), or calling out to components over distributed-object transports
like CORBA or MCOP (with API issues), instead of the traditional 'helper
app' model.
As a result, generally, when I install a new version of Mozilla, I have to
try and remember what plugins I had in the last one, track them down,
download the latest version to work around ABI changes, and hope they work
in this version of the browser.
Inevitably, they don't -- I haven't found a working Java plugin in over a
year. On the other hand, I can always click on a .ram
link to
listen to a RealAudio stream, because it doesn't really matter if
the browser and realplayer were built with different compilers in
the 'helper app' case.
In addition, and paradoxically, scriptability is becoming less of an
option in the modern UNIX GUI apps. Let's say I want to be able to do the kind of thing
Windows has had for years with it's 'Send To' menu; put a simple shell
script into an 'actions' directory, and it'll appear in the right-click
context menu, so that I can right-click on a file and select 'Run
frobnicator' to frobnicate it. (Similar is possible from MS Internet
Explorer.)
Is it possible in Firebird? Not a hope. But you can write an extension
-- 100KB of undocumented Javascript. Great.
In fairness, the file managers have the right idea -- GNOME's Nautilus does support
this nicely, and
so does Konqueror. But there's an ongoing tendency to adopt the ABI
dynamic-linking model, or the distributed-object model, in
places where it's just not necessary, and a simple UNIX pipe or command
API -- the 'helper app' model -- would work beautifully.
hmm. </rant> ;)
ADORABLE KITTENS TALK ABOUT POLITICS
Funny: Best commentary I've read all week: ADORABLE KITTENS TALK ABOUT POLITICS: