Subject: RE: lightweight wms
To: None <netbsd-help@netbsd.org>
From: Richard Rauch <rkr@olib.org>
List: netbsd-help
Date: 01/24/2003 04:04:00
Re. http://mail-index.netbsd.org/netbsd-help/2003/01/08/0005.html

Yeah, this is an old thread.  I saw it while I was catching up on
the mailing lists.  I had an impulse to reply, then told myself,
"No, it's an old thread.  Just read..."  But a couple of people
made some comments about twm being bloated (perhaps not their exact
words), and that reminded me of some old claims about other,
supposedly sleeker, wm's; claims which I'd begun to consider old wives'
tales.

So, I did some tests.  But before I get into that, let me make a
comment about why *I* cringe a bit at KDE: It's not exactly the
size.  Nor do I believe it to be any more usable than twm, say.
(Provided twm is properly configured and you've installed some
packages, such as LyX, and tied them to twm menus.  If the user
*must* have a start-button, set the root window to have a (picture
of a) "start" button on it---or *tile* the background with thousands
of "start" buttons.  (^&)

No, the main problem that I have with KDE and GNOME, both, is primarily
that they are a snakes' nest of dependencies.  If any of them
(including their vast array of required libraries and executables)
develops a security flaw, you may spend a day or two rebuilding.
I think that everyone here has run into that with pkgsrc, so I'll
just say "'nuff said."  (^&

But, all things are relative.  The above is just *my* major objection
to KDE and its ilk.


Okay, the old wive's tale: A few short years ago, I started using NetBSD,
and eventually set up X.  I took the time to learn how to configure twm
before looking at other window managers.  The next window manager that
I looked at, I believe, was ctwm.  It proclaimed, if memory serves, that
it was based on twm but had removed some cruft, reduced the memory footprint,
and added features.  "Sounds like reasonable maintenance," I thought.  Along
came another window manager that I saw, a derivative of ctwm.  It had the
exact same wording.  Then I saw another...

[AT LEAST, that's what I REMEMBER.  I just re-checked the ctwm man-page
after re-installing it, and it makes no such claim that I can see, now.
Still, it's the memory of that claim that got me started here.]

It was at that point that i realized that the claim was probably old,
and while it probably was originally true, it seemed plausible that these
other (generally more featureful) wm's had just carried along ctwm's verbiage
without actually checking on it.  I began to discount the claim as possible,
but not particularly sure.

Not that I cared.  I had a nice twm configuration.  I never got around to
making another wm feel as homey, though I continued to give other wm's a
try from time to time (including desktops like KDE and the GNOME), just
to see what kind of flash and fire was going on.

Then, today, I saw this thread about lightweight window managers and I
thought, "I've got a little time to kill, and I really do wonder if
ctwm's old claim is true..."  So I built every wm (except a few that
wouldn't build) out of pkgsrc.  A few had some annoying "features",
3 would not build.  Some of the ones I expected to be lightweights
(ctwm, fvwm2, blackbox) turned out not to be so lightweight.
There *are* some real flyweights...


Rules of engagement: Except for twm (which is using my own fluffified
.twmrc) and tvtwm (which uses .twmrc), all window managers are run as
they ship from pkgsrc.  No tweaking to them or their configs was done.
Measurements were taken by "SIZE" memory footprint in top.  If a
window manager didn't build for any reason, I didn't fight with it.
(One of *my* gripes is extensive dependancies that cause pkgsrc builds to
be more fragile than I'd like.)

The X server they were run on was a 16-bit, 1400x1050 display.  It is
XFree86 4.2(?) runnong on NetBSD/i386 v1.6.  pkgsrc was recently freshly
downloaded (less than a month ago).

The following 3 wm's did not build:
  fluxbox, metacity, waimea.

NovaWM seems to completely lose the input focus from the keyboard and was
totally useless for me; I had to kill the window manager from another virtual
terminal, and the X server was still "dead" until I killed *it*, too.   I was
able to record the size from another virtual console, though.

The following would "oversize" windows automatically (obviously a deliberate
feature, but I found it annoying, especially when trying to get back to
a normal state for trying the next window manager):
  ion, matchbox, ratpoison

The following KILL the X server on exit (really evil; I run them with
`&' from a shell window; twm I run in the background from .xinitrc).
I consider this a really irritating bug, though it's probably deliberate:
  icewm, olvwm

The following somehow lost or screwed up the input focus for the keyboard,
on exit:
  ion, NovaWM, windowmaker

Two or three had to be exited with "kill" commands, as they offered no
means of exit.  (One required a "kill -9", I recall.)

Finally, the sizes while running represent the total of all "SIZE" values
reported by "top" for processes that either are, or are run by, the wm.
The set of all the "top" outputs runs to just over 32K, so I'm only posting
this summary.  If you're interested in the detailed "top" output, email me.
I make no apologies for poor default configs or for "extra" stuff that gets
run by default.  A wm that adds lots of extra gunk by default is not
practicing a "small" philosophy, IMHO.   How easy or hard it is to remove
the gunk, and how "friendly", BillOS-like, or nifty/slick/stable it is, I
make no evaluation here.  Nor do I attempt to consider the list of dependancies
which may not be reflected in top's SIZE.)

(NOTE: top's man-page says that "SIZE" is the total amount of text, data,
and stack, while "RES" is the amount resident in memory.  How can RES be
larger than SIZE?  Does that have to do with shared libraries?)


   72K  9wm
 1340K  afterstep
  380K  amaterus
  288K  amiwm
  704K  blackbox
  524K  ctwm
 4172K  enlightenment
   76K  evilwm
  184K  flwm
  228K  fvwm
 1224K  fvwm2
  520K  icewm
  252K  ion
   72K  lwm
  172K  matchbox
  432K  novawm
  672K  olvwm
  896K  openbox
  524K  pekwm
  344K  piewm
  204K  pwm
 2172K  qvwm
  112K  ratpoison
  956K  sawfish
  600K  tvtwm
  472K  twm    (464 with default .twmrc, in case you care)
  184K  uwm
 1120K  wmaker
  160K  wm2
  280K  wmx


If you "sort -n" that list, you'll see that twm is about in the middle, though
subjectively I'd put it at the lightweight end of the middleweights.  The
real flyweights are 9wm, lwm, and evilwm (though ratpoison is maybe a
bantam-weight; (^&).

As far as memory leaks and twm go...not sure.  I've got a twm that's been up
for 4 days.  With about a dozen windows of varying sizes, it weighs in at
492K.   Similar config to the one used above.  If it's leaking memory, it
isn't doing it very fast and has a *long* ways to go before it catches
up to blackbox (or the hulking fvwm2).  (^&


All of the above, however, is just to put down a defintion of "size" and
some numbers, since no one ever qualifies or quantifies these things,
it seems.  So, there's a working, de facto  definition: Whatever "top"
says the "SIZE" is.  (^&  (If whoever started this thread wanted some other
measure, such as disk-space, with or without all of the required support
packages...ah, that's for another time.)


-- 
  "I probably don't know what I'm talking about."  --rkr@olib.org