dropping the 10MT code that keeps atlanta blowing up -- with recursions that're phat like ham bone, and bounds that're tight like gnat booty. opinions expressed herein are mine, or at least not those of the Georgia Institute of Technology.

2009-07-05

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:

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:

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

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

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:

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.

'bout it 'bout it

We're gonna talk about computers, and the code that moves the bits around, and the networks those bits shimmy on down. We're gonna be relentlessly esoteric and -- as 2Live were Nasty before us, so shall we be Technical, meaning as Technical as we Want to Be.
We're gonna swear. A lot. We will celebrate free release of textbooks as electronic documents, and heap scorn upon the mottled, blotched dyingbody of for-profit scientific publishing, because fuck paying $180 for a book with 115 pages. We will unceasingly reference the rap of our adolescence, because that never grows tiring for us or our audience. We will seek, strive, find and not yield. We will hold it down; we will move on up. We will remain forthrightly contrarian regarding shit-eating Apple and their wretched fans. So let it be written. So let it be done.