> Heck, I think XClock is challenged to run in 20MB today.
Assuming you mean the 'xclock' binary you'd find in Xorg installations, it seems to use about 8MB of RES memory. But keep in mind that it drags in a bunch of libraries (objdump shows Xaw, Xmu, Xt, X11, Xrender, Xft, xkbfile and the math and C libraries as direct dependencies) and those drag their own (ldd shows 26 libraries) and all of that stuff add to the memory overhead for their own purposes even if at the end xclock didn't use them. Chances are an xclock reimplementation that talked the X11 protocol directly, used only the minimum functionality needed to display the clock lines and was statically linked to some minimal C library without any external dependencies would use much less memory.
Though even that would probably feel as too much memory since a lot of the memory used by a program in a Linux system relies a lot on what is already there - including the hardware and kernel drivers.
(which is also why these articles comparing memory usage between various desktops tend to make zero sense as they measure the entire system memory usage, the largest part of which is outside the control of the desktop environment in the first place and in most cases will vary between different computers even with the same distro)
Wmaker and Emacs? You did a custom kernel build right?
For being something to brag against, you used XEmacs, I guess. Or X-compiled Emacs, in order to be a "big" accomplishment. UXTerm+Emacs under the CLI was "big", but
manageable; the X build (even the Athena or Lucid one) wasn't a light thing at all.
Assuming you mean the 'xclock' binary you'd find in Xorg installations, it seems to use about 8MB of RES memory. But keep in mind that it drags in a bunch of libraries (objdump shows Xaw, Xmu, Xt, X11, Xrender, Xft, xkbfile and the math and C libraries as direct dependencies) and those drag their own (ldd shows 26 libraries) and all of that stuff add to the memory overhead for their own purposes even if at the end xclock didn't use them. Chances are an xclock reimplementation that talked the X11 protocol directly, used only the minimum functionality needed to display the clock lines and was statically linked to some minimal C library without any external dependencies would use much less memory.
Though even that would probably feel as too much memory since a lot of the memory used by a program in a Linux system relies a lot on what is already there - including the hardware and kernel drivers.
(which is also why these articles comparing memory usage between various desktops tend to make zero sense as they measure the entire system memory usage, the largest part of which is outside the control of the desktop environment in the first place and in most cases will vary between different computers even with the same distro)