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> ;)