Doing it for the kids, man [LWN.net]

Doing it for the kids, man

Posted Oct 27, 2006 20:35 UTC (Fri) by Tara_Li (subscriber, #26706)
Parent article: Doing it for the kids, man: Children's laptop inspires open source projects (LinuxWorld)

Thank heavens! I've been hoping for something to bring the developers back down to Earth in their development. I've been talking with friends for years about sitting kernel, X, and Gnome/KDE devels down at P2-500s with 128MB of RAM and a shared ISDN line for a year, making them live with seriously useable, but disregarded, hardware. I'll admit the distros are at fault to some degree as well - developing their tools in a constantly changing choice of language of choice - m4, Perl, Python, Ruby, Java - I'm waiting for someone to announce that their distro will use brainfsck or shakespeare as their choice of language for building GUI tools, and that they're completely abandoning command-line shells.

Seriously - let's consider that DOS and Lotus 1-2-3 would run *NICELY* in the on-chip cache of most current microprocessors!

(Log in to post comments)

Doing it for the kids, man

Posted Oct 27, 2006 22:53 UTC (Fri) by dcoutts (subscriber, #5387) [Link]

There's no particular reason that using nicer languages should need lots more memory or cpu power - at least if you stick to compiled implementations.

For example, Linspire now use Haskell for their OS tools. (They moved to Haskell from OCaml.)

There are good reasons of course, like much lower bug counts than you typically get from untyped string-munging languages like bash, perl etc that are often used for OS 'scripts'.

Doing it for the kids, man

Posted Oct 28, 2006 5:20 UTC (Sat) by Tara_Li (subscriber, #26706) [Link]

My point as regards to the languages was more that you end up with a multiplicity of languages required for a minimal installation. As it stands with Red Hat and Fedora - you pretty much *HAVE* to install Perl and Python both. And Java is starting to make a showing. Soon we'll have Mono required, and who knows what else.

Let's get some simplification going on - so that if I have Avahi turned off, and Kerberos - the libraries never even get *LOADED* on my aps. I mean, really - why does my CPU Freq monitor applet on the Gnome panel require access to Avahi, libasound (there's no way to configure it to beep when the CPU freq changes that *I've* been able to find), libesd, libcrypto, libkrb5, and a whole crapload of similar stuff - sure, it's all shared - but I can't figure out which of my aps might be using it, especially the Kerberos crap.

Sometimes, I wonder if I might not be better off actually statically building all of the aps on my system.

Doing it for the kids, man

Posted Oct 28, 2006 18:46 UTC (Sat) by dberkholz (subscriber, #23346) [Link]

You could use a source-based distribution that lets you avoid all those unneeded dependencies, such as Gentoo..

Doing it for the kids, man

Posted Oct 28, 2006 22:54 UTC (Sat) by nix (subscriber, #2304) [Link]

Definitely don't link statically! As it is, those libraries interfacing to
things you don't use have only one copy in memory across all apps, and
even *that* is probably not paged in if you're not using it. Compile it
statically, and you'll have functions from those libraries scattered among
functions that *are* being used, *and* duplicated in every user. It's
hugely more expensive.

Doing it for the kids, man

Posted Nov 2, 2006 5:31 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

Unfortunately, we don't have a good tool for reporting memory usage. The ones that we have don't properly show the benefits of shared libraries, so people don't see the benefits of dynamic linking.

Doing it for the kids, man

Posted Oct 30, 2006 10:12 UTC (Mon) by eru (subscriber, #2753) [Link]

There's no particular reason that using nicer languages should need lots more memory or cpu power - at least if you stick to compiled implementations.

Or not even compiled, just well-written. In the early days of PC:s interpreted languages were actually very common despte the slow machines, because they allowed software development faster (compiling with floppy disks or old slow HD:s was painfully time-consuming) and they also required less disk space (no need to store intermediate objs or the final exe). The interpreters themselves were typically carefully crafted in assembler, or at least their core parts were (the rest was often in libraries written in the interpreted langauge itself).

Doing it for the kids, man

Posted Nov 2, 2006 11:01 UTC (Thu) by lysse (subscriber, #3190) [Link]

Hmm. Are you perhaps thinking of Forth here? :) More interestingly (and quite off-topic, but trips down memory lane are fun), are there any other languages you're referring to?

Doing it for the kids, man

Posted Nov 17, 2006 13:47 UTC (Fri) by eru (subscriber, #2753) [Link]

are there any other languages you're referring to?

Various dialects of BASIC. Don't laugh. It used to be a very common way of implementing real microcomputer and minicomputer apps (which typically were much simpler in those days than now, so the inherent deficiencies in the language design did not matter so much).

Doing it for the kids, man

Posted Oct 28, 2006 22:51 UTC (Sat) by nix (subscriber, #2304) [Link]

X is actually trim enough to run on machines a fraction the size of that.
If you install the kdrive X server, well, that thing is meant to run on
*handhelds*.

What bloats X up a lot is applications storing vast amounts of pixmap crud
inside it for not much reason (gecko is a *major* culprit here). The RSS
counts are rendered even more inaccurate lot of the allegedly `resident'
memory is actually mmap()ed video card memory, i.e., not your precious
general-purpose physical RAM at all.

(You may find the `xrestop' program useful for tracking down hogs. My
biggest hog right now is Konqueror, with 11Mb of pixmap memory used, but
then it *does* have thirty tabs open.)

Doing it for the kids, man

Posted Oct 29, 2006 19:51 UTC (Sun) by Tara_Li (subscriber, #26706) [Link]

It's starting to sound like the one tool Linux *desperately* needs is a *REAL* way to sort out memory usage - what's swapped out, what's memory mapped in from some device, what belongs to what program or library, which programs are sharing which pieces from which libraries, and stuff like that. It doesn't seem to be a simple problem, considering how many different answers you get from ps, pmap, xrestop, and one I can't remember right now that uses a kernel module to tag memory allocations...

It might help settle arguments about who's actually leaking memory.

Doing it for the kids, man

Posted Oct 30, 2006 9:15 UTC (Mon) by job (subscriber, #670) [Link]

Indeed. Qt and GTK are really bad too. There was an article on LWN some years ago where someone had tracked what these libraries actually do with the X protocol, and there was lots and lots of redundance. That's why X latency over long links has become worse over the years. Qt is said to have improved with v4 but I haven't looked into it myself.