The best lack all conviction, while the worst are full of passionate intensity

Man, I'm growing truly distressed by the farrago -- the melange -- the, dare I say it, I do dare! gallimaufry -- the widening gyre for sure -- into which my Linux desktop has descended over 2009's first half. The pulseaudio debacle just got worse and worse, until I finally purged all traces of it a month ago; ALSA is once more directly brokering applications and my Intel HDA and/or Fubar II USB DAC (through M-AUDIO Studiophile AV 40's) with panache and elan, with the added benefit of IceWeasel+crappy flash no longer wrecking mplayer/mpd (my original reason for throwing PulseAudio into the mix). Now xfce 4.6 emerges, xfce of course being the "lightweight response to gnome/kde" and having served me well for several years now, and what the holy hell is this:
xfce4-settings-helper --display :0.0 --sm-client-id 29afe6488-185e-4359-a60d-9529c7c05642
xfwm4 --sm-client-id 203c6cff5-bbfe-4d1d-9d1c-3228cb4e24f0 --display :0.0
/usr/bin/xfdesktop --sm-client-id 11d81ba305000121438424100000173320018 --display :0.0
xfce4-panel --sm-client-id 28775a015-d9f0-4ded-bdee-1cac6a52936e
/usr/lib/xfce4-screenshooter/xfce4/panel-plugins/xfce4-screenshooter-plugin socket_id 14680099 name screenshooter id 11925955890 display_name Screenshot size 42 screen_position 9
/usr/lib/xfce4-netload-plugin/xfce4/panel-plugins/xfce4-netload-plugin socket_id 14680100 name netload id 11812997820 display_name Network Monitor size 42 screen_position 9
/usr/lib/xfce4-netload-plugin/xfce4/panel-plugins/xfce4-netload-plugin socket_id 14680101 name netload id 12062092340 display_name Network Monitor size 42 screen_position 9
/usr/lib/xfce4-xfapplet-plugin/xfce4/panel-plugins/xfce4-xfapplet-plugin socket_id 14680102 name xfapplet id 12232614662 display_name XfApplet size 42 screen_position 9
/usr/lib/xfce4-timer-plugin/xfce4/panel-plugins/xfce4-timer socket_id 14680108 name xfce4-timer id 12297861572 display_name Xfce4 Timer size 42 screen_position 9
Does this seem fundamentally ridiculous to anyone else (in particular, those are some abominable command lines)? So, xfce obviously does the whole process-per-panel-element thing because:
  1. Sloppy coders imply undefined behavior, and you'd have the whole panel needing to restart every time xfce4-netvisor dropped core due to a device rename
  2. As a corollary, sloppy coders imply bloated loading times (often due to poor use of libraries -- be sure to read Ulrich Drepper's whitepaper, as linked to from that entry), so restarts of the panel in toto couldn't be transparent
  3. Sloppy coders imply blocking and excessive use of global resources (blocking, after all, being misuse of thread-level time resources), and sucking all of this crap into one process would lead to Cartesian products of interactions -- only through reducing interactions to structured implications can debugging hell be avoided. I doubt Dijkstra finds much readership among GUI coders
But that's fine, because hey, if these were system programmers they'd be doing systems programming rather than mucking about in xorg wastelands.

Now, I must break here to commend the efforts of Keith Packard, Carl Worth, and everyone else out there hacking on DRM, GEM, and i915 -- I love y'all, and everything there is awesome (well, KMS broke my workstation with Debian's last xserver-xorg-intel release, but ya gotta spend money to make money). But these are not the people hacking on xfce4, to which we return...

How many processes do you need to implement a config file? I'd have thought 0, but xfce is running no less than 3: xfconfd, xfsettingsd, xfce4-settings-helper. What, between xfconfd and xfsettingsd, do they need help with? Why is the configuration system so bloated and obtuse that this is all necessary? I run hour-long compiles without the benefit of gcc-settingsd, gmakeconfd, ld.so-environment-manager and two baseball players to be named later. If things can't be processed on each process startup, throw a processed data structure into freakin' POSIX.1-2001 shared memory and throw a process-shared semaphore atop that sunnabitch. There's a reason why these capabilities exist, for chrissakes!

This is made all the worse by xfce applications being, aside from a semi-substantial core (xfce4-terminal, I salute you!), underfeatured and generally shitty, and thus GNOME applications being thrown into the mix anyway. I today realized my xfce4 laptop needed gnome-system-monitor -- nothing fancy, a few panels showing CPU/mem/swap etc, nothing WindowMaker hasn't had a dockette (or whatever the hell WindowMaker calls the ass-esque abominations it renders for people working on SPARCStations in university printing labs around the nation) for since 1986 or so. This required installation of ONE-HUNDRED AND THIRTY MEGABYTES (it sounds like a fucking Soviet nuclear yield) of GNOME asstrash including evolution-data-server (more useless processes, hurrah!) and something called "policykit-gnome" which promises to integrate my capability-delegating experience with ponies and sugar cookies. The upshot is the addition of:
/usr/lib/gnome-applets/multiload-applet-2 --oaf-activate-iid=OAFIID:GNOME_MultiLoadApplet_Factory --oaf-ior-fd=18
/usr/lib/bonobo-activation/bonobo-activation-server --ac-activate --ior-output-fd=18
That would be the addition of 5 processes for 1 additional applet, which furthermore is shown to be polling-intensive by the magic of powertop(8). Oh wait -- xfce added a lovely xfapplet process to handle the no doubt complex and intensive management of this applet, so 6.

If someone brought this to me at work, I'd have them officially fired and, on my own time, flayed.

Regarding this blog, the lack of threaded comments has really got me down, as bad tools will tend to do. I might migrate the effort to LiveJournal. On the plus side, I've been editing my wiki a lot; go check out http://dank.qemfd.net for some good old-fashioned computational fun.