And for *ubuntu the requirements are almost the same:
Low-spec computers (Xubuntu)
If your system has less than 192 MB of system memory, use the Alternate Installation CD. (not live)
Recommended minimum requirements
256 MB of system memory (RAM)

Maybe python is not the best idea, but it’s the right one for “today” computers

Kind regards

* http://docs.fedoraproject.org/release-notes/f8/iso/en_US/sn-ArchSpecific.html#sn-ArchSpecific-x86-hw

However, I don’t think the memory is mainly “wasted” with Python… In my experience:
- Python is less memory-hungry than Perl (seen when trying to write a very simple passive Jabber bot that should run on a 64MB machine - the Python version used ~half the memory as the Perl one, according to `top`)
- quite a lot of memory is used by the Gnome panel applets, even if they are written in C
- generally, if I look at memory usage on a Hardy LiveCD desktop, most memory is used by the panel and nautilus - and IIRC there are no Python processes in the top ones
- finally, who would actually like to write C code when there’s Python available? C’mon, at least use C++ Seriously, IMHO it’s way more work to write the same app in C or C++ instead of Python or Perl, and the associated costs are not really visible on a recent machine.

So I suppose any serious memory saving will have to happen in Gnome (GTK?) libs first.

Since the beginning of my Linux experience, I’ve run only the lightest window managers and desktops (xfce is the lightest available nowadays). My work with VR/AR/VRML always demanded more out of the hardware than it had, so doing things in X with a minimum of interference was quite important.

The reason for the question above: if you’re wanting to re-claim the RAM, just launch your X session from the commandline with ’startx’. GDM pre-loads 2.3 tons (metric) of stuff with it. While much of it will load anyway if you’re using a desktop system, it will at least minimize the impact after the swap-fest gets you graphical.

And I’ll agree - Python is not the panacea everyone feels it is. It’s great for doing “proof of concept” implementations, but it’s just *thick*. Lingers on the stack longer than chocolate chip cookies on my love handles…

-pax-

There are some items you seem to forget:

-) The whole “lowlevel” userland tools are bloated, not only in implementation, but also in design. (hal, dbus, …) Not that it does not provide a nice user experience, but fact is that it’s quite a bit of code and memory usage that some years ago would have been handled by simple commands (sudo’ed) or simple shell scripts.

-) GNOME is not that bad on “old” hardware, depending upon your value of old.
On my 3 yrs old laptop, I have to admit that Ubuntu/GNOME is not really slower than my old Debian/ion3 setup.

-) And picking on the real issues here, I’d say these are not Python apps:

1594 pts/6 S 10:11 24 1 73558 50912 2.4 gwenview

3939 ? Sl 0:33 55 227 125916 38380 1.8 gnome-terminal

6248 ? Sl 1:07 458 816 113043 39100 1.9 pidgin

6220 ? Sl 0:22 88 1177 128266 54204 2.6 nautilus –no-default-window –sm-client-id default2

5865 tty7 Rs+ 237:48 47 1607 382536 40652 1.9 /usr/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth vt7

6257 ? Sl 2:16 112 405 175174 53892 2.6 /usr/bin/liferea-bin

6272 ? Sl 2:16 742 115 148640 64676 3.1 evolution

25932 tty2 Sl 24:44 23 35 1301800 143224 7.0 /usr/lib/jvm/java-6-openjdk/jre/bin/java -Xmx1024M -Djava.library.path=.:/usr/lib/jni:/usr/lib -classpath Azureus2.jar:/usr/lib/java/swt.jar:/usr/share/java/Azureus2.jar: org.gudy.azureus2.ui.swt.Main %f

Hmm, guess with nowadays evolution you wouldn’t be able to develop on a 128MB RAM box.