The Lessons of the $100 Laptop (eWeek) [LWN.net]

indeed

Posted Apr 5, 2006 16:11 UTC (Wed) by gvy (guest, #11981) [Link] (6 responses)

> We've gotten to the point where we have to completely rethink.

"GNU bloat" is, alas, quite known too, not only "MS bloat". :-(

How much I like and use free software, much has changed since 1998 and now I wonder how slow the desktop and OpenOffice.org is on e.g. cel433/128M compared to how slow StarOffice was on K5-75/48M, IceWM or WindowMaker being not slow at all, even if not wildly snappy...

Fiddling with N770 was rather frustrating, too -- who might need that Gnomopotamus there?

indeedum

Posted Apr 5, 2006 16:44 UTC (Wed) by mepr (guest, #4819) [Link] (5 responses)

I noticed yesterday that my laptop, which had been running for several days had an instance of gaim taking up 108MB, and KNotes, kde's sticky-pad application was taking up 50MB. Now, gaim is clearly having problems properly maintaining its data structures.. when I tried to close it, it hung (although I keep using it because it's IMHO better than the alternatives). But 50MB to have one sticky note on my desktop? How much memory does it really take?
And this, after gnome and kde have both reportedly put a lot of effort into slimming down their environments.

indeedum

Posted Apr 5, 2006 16:53 UTC (Wed) by aleXXX (subscriber, #2742) [Link] (4 responses)

How did you measure the memory usage ?
It's not easy to get useful numbers with current kernels, here's a good
explanation: http://www.kdedevelopers.org/node/1445

Alex

indeedum

Posted Apr 5, 2006 17:14 UTC (Wed) by gravious (guest, #7662) [Link] (3 responses)

I have seen this mentioned so often that I think somebody with a few bob to spare like Redhat or Ubuntu should sponsor a bounty for someone to write a little utility that accurately reports memory usage on an app by app and library by library basis... in fact, give me a couple of grand and I'll have it ready for you by next Tuesday - give or take a release cycle.

indeedum

Posted Apr 5, 2006 17:49 UTC (Wed) by rogerd (guest, #4170) [Link] (1 responses)

Will you take a $100 laptop instead of a couple grand???

indeedum

Posted Aug 13, 2006 9:47 UTC (Sun) by gravious (guest, #7662) [Link]

err, okay... is it one of those cute olpc things with the weird bunny ears?

indeedum

Posted Apr 5, 2006 17:59 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

http://people.redhat.com/berrange/systemtap/bootprobe/
http://people.redhat.com/berrange/olpc/performance/

The Lessons of the $100 Laptop (eWeek)

Posted Apr 5, 2006 18:42 UTC (Wed) by hosiah (guest, #36961) [Link] (18 responses)

Up until yesterday's stunning comments, I thought Negroponte was a pretty savvy guy. Now I'm wondering if he's been borged. I mean, come on, Linux, the system that will fit in a 50 MB CD or a USB drive like in DSL, runs completely in RAM like Puppy, powers everything from servers to cell phones, and even fits on a floppy like in Hal91 and Tom's root/boot is suddenly "too bloated"??? Hey what about BSD, GNU's own HURD, or Open Solaris, then? And all of a sudden Windows is back on the project again. I have yet to see the hardware device that I couldn't cram Linux onto, and that includes 286'ers with 285MB hard drives that were originally running Windows 3.0 - and with room to spare for a well-chosen light-weight GUI or two, even. I smell a rat in the house!

Yes Linux is bloated

Posted Apr 5, 2006 19:04 UTC (Wed) by jmorris42 (guest, #2203) [Link] (14 responses)

> I mean, come on, Linux, the system that will fit in a 50 MB CD

Yes, Linux is becoming very bloated. Don't compare to Microsoft as that is shooting fish in a barrel. Compare Linux to older Linux. Slackware used to ship on floppies, including X. Linksys switched away from Linux in their lowball routers because they could slash RAM and flash in HALF. So yes there is some optimization possible.

I remember running Netscape and The GIMP on a machine with 32MB of ram and being able to tolerate the experience. Firefox alone wouldn't dream of launching on such a machine today. Netscape 1.0 fit on a floppy. Firefox is the 'slimmed down' Mozilla and weighs in at 30MB. Yes it does more, but does it do 20 times more? (Side note, the firefox rpm is actually LARGER than the current mozilla package on my machine.)

I suspect the problem is C++. To compile non-trivial C++ apps requires a big honking box with a boatload of memory so anyone who develops has such a machine. Once they have an oversized box they no longer notice the effects of battery monitors that suck down megabytes and thus don't see a reason to expend effort to reduce their footprint.

C++

Posted Apr 5, 2006 19:57 UTC (Wed) by anLWNreader (guest, #36915) [Link] (11 responses)

No, it's not C++. Try Opera which is also written in it and yet they still pay a little attention to keep it fast. And Firefox is not Linux. Linux is not bloated, the popular desktop softwares that are usually used on it are. But you do have choices, much more so than with Windows.

This is about Linux

Posted Apr 5, 2006 20:56 UTC (Wed) by kl (guest, #36963) [Link] (5 responses)

> Linux is not bloated, the popular desktop softwares that
> are usually used on it are. But you do have choices,
> much more so than with Windows.

Sadly, but I just can't agree with that. For me -- amateur
trying to put Linux on some embedded devices this simply
isn't true anymore.

Linux _used_ to be small, well I think in 2.2-times. 2.4 was
somewhat larger but not to great extent.

On the other hand with 2.6 kernel there is dramatic increase
of code size _and_ decrease in speed. (At least for me.)

Please see this: http://www.denx.de/wiki/Know/Linux24vs26

I mean, I used to run Linux on my Pentium 75 with 64MB of core
memory. Well, I can do this with 2.6 kernel too, but performace
is much worse than with 2.4 kernel.

With every release of 2.6.x kernel I see many interesting features
added to kernel, but they add to code "bload" (and no, they can't
be turned off by some config option).

Userspace have the problems too. GNU Libc is very versalite but
complicated at the same time. Alternatives like uClibc do the job
for embedded devices, but why GNU Libc can't do the same?
And why GLibc is so horribly complicated? This is what I like in
*BSD systems -- they offer good code complication to speed ratio.

This is about Linux

Posted Apr 5, 2006 22:41 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)

Turning off extra stuff is what CONFIG_EMBEDDED is for.

I see a substantial speedup on all but my very smallest (8Mb RAM) machines with 2.6 versus 2.4. I think part of this is the reverse mapping stuff making swapout decisions smarter...

This is about Linux

Posted Apr 5, 2006 23:13 UTC (Wed) by kl (guest, #36963) [Link] (2 responses)

> Turning off extra stuff is what CONFIG_EMBEDDED is for.

Yes, but I just can't find options to disable shared subtrees,
new syscalls, migration patches, scheduler domains and the like.

On the other hand there is work to make kernel smaller -- SLOB
allocator, unexporting symbols, disabling forced inline and similar
things come to mind.

But, from my very subjective point of view kernel _is_ getting
bigger from release to release. This is an issue for those trying
to put as much software as possible into 4MB of flash.

Hopefully we have source so we at least _can_ tailor kernel to our
needs. :)

This is about Linux

Posted Apr 6, 2006 9:35 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Migration and scheduler domains only get compiled in when you're SMP (and I think you need to say you're NUMA, too). I doubt your little tiny embedded body is a NUMA SMP box!

I'm damn glad there's no way to disable syscalls: a faster way to break userspace doesn't easily come to mind (and, yes, so nobody uses e.g. unlinkat() *now*, but upgrade glibc to 2.4 and all of a sudden if you try to remove those 'new' syscalls, coreutils will break. You don't want that.

Equally, disabling subtree sharing, well, it might seem like a good idea, but how much memory does it actually use? Probably cleanups like unexporting symbols and fixing inlining and, hell, just compiling with -Os save a lot more space than disabling that ever would, and it's intrusive enough that trying to disable it without breaking sys_mount() or maintaining piles of duplicate code may just not be worth it.

This is about Linux

Posted Apr 7, 2006 9:59 UTC (Fri) by kl (guest, #36963) [Link]

> Migration and scheduler domains only get compiled in
> when you're SMP (and I think you need to say you're
> NUMA, too). I doubt your little tiny embedded body is
> a NUMA SMP box!

You are right of course. :)

But... in "traditional" embedded systems ASMP is not that
uncommon. It is rather The Way to achieve multiprocessing...
or was not that long time ago.
(ASMP is not SMP, but still MP...)

So forgive me, but for it wasn't that clear to me that there
are no tiny-(a)smp boxes. :]

(My background is rather 8051-like, so very different
from what I see in current embedded market.)

> I'm damn glad there's no way to disable syscalls: a faster
> way to break userspace doesn't easily come to mind (and,
> yes, so nobody uses e.g. unlinkat() *now*, but upgrade
> glibc to 2.4 and all of a sudden if you try to remove those
> 'new' syscalls, coreutils will break. You don't want that.

Yes, I don't, and any server/desktop machine doesn't want that.
On the other hand on embedded systems I don't use GLibc,
coreutils or similar things. I use uClibc, busybox, and the like.
Here, I see point of removing unused features like entirely new,
or entirely old system calls. I have impression that backwards
compatibility doesn't make any sense on these tiny systems,
where every bit counts...

> Equally, disabling subtree sharing, well, it might seem like
> a good idea, but how much memory does it actually use?
> Probably cleanups like unexporting symbols and fixing inlining
> and, hell, just compiling with -Os save a lot more space than
> disabling that ever would, and it's intrusive enough that
> trying to disable it without breaking sys_mount() or
> maintaining piles of duplicate code may just not be worth it.

I understand this perfectly. I'm just trying to point out that
Linux is not always best for _embedded_ systems.
New features added to kernel are often just useless for them.

On the other hand no one wants to implement things like PCI
support every time, so Linux gets choosen. And this is good,
because many people are working to make kernel smaller --
and more often their patches gets merged.

(I'm aware that my english is not without problems too so
I would like to apologize for that.)

This is about Linux

Posted Apr 6, 2006 9:37 UTC (Thu) by nix (subscriber, #2304) [Link]

Oh, and glibc is complicated in large part because it's versatile and because it tries to maintain back-compatibility. uClibc explicitly makes no attempt to do the latter.

(But yes, I agree that glibc is a bit of a mess compared to uClibc...)

C++

Posted Apr 5, 2006 21:48 UTC (Wed) by jmorris42 (guest, #2203) [Link] (4 responses)

> No, it's not C++.

Read what I wrote and stop jerking the knee so much. Try BUILDING opera and I suspect that you would find it, like any C++ codebase, chews ram like crazy while compiling. Which is why all developers require lots of memory. And having gobs of memory means developers don't feel the pain of bloat enough to do anything about it.

> And Firefox is not Linux.

If by Linux you mean the kernel then no, but if by Linux, like this website itself, we are discussing the family of operating systems built from the Linux kernel, the GNU tools, X, one or both of GNOME and KDE and several other major Free/Open components then Firefox is most certainly an important part of it. As is OpenOffice and it is the biggest resource pig of them all.

> Linux is not bloated..

Which is why Linksys found it cheaper to PAY for an OS that could run in half the ram and flash. Dude, I have been on the Penguin train since 1994 and have no plans on getting off anytime soon. That said we must be able to speak honestly of the ugly realities if progress is to be made.

C++

Posted Apr 6, 2006 0:43 UTC (Thu) by beoba (guest, #16942) [Link]

If you're a "big company", you may have a separate build server. Your development box(es) won't necessarily have gobs of ram.

C++

Posted Apr 6, 2006 9:10 UTC (Thu) by gnb (subscriber, #5132) [Link] (2 responses)

>Which is why Linksys found it cheaper to PAY for an OS that could run
in half the ram and flash
No, that's because they were in a hurry (or inept). Other vendors are
shipping comparable Linux-based devices in the flash footprint they
switched to VxWorks to achieve. You have to work harder at it, for
example finding replacements for most of the GNU userland, but these
exist: busybox/uclibc will get you most of the way there.
In fact I think that's the main problem: it's still perfectly feasible
to build a slim Linux-based system, but for most people it isn't worth
the effort of trying to go much below the RAM/Disk/CPU they expect their
target audience to have available.

C++

Posted Apr 6, 2006 15:07 UTC (Thu) by jmorris42 (guest, #2203) [Link] (1 responses)

> You have to work harder at it, for example finding replacements for most of
> the GNU userland, but these exist: busybox/uclibc will get you most of the
> way there.

No, that gets you running in 4MB flash and 16MB RAM, which is what the version I have has under the hood. They were using busybox and uclibc already. The new hardware is 2MB flash and 8MB ram. Even the stripped and all command line environment of OpenWRT won't run on the new hardware.

Even in the earliest days, Linux was a boot and a root disk. Scaling that next notch down would require some effort but I kinda doubt it is really required. At the rate prices keep falling the difference between 2 and 4MB of flash is shrinking really fast. At some point you probably won't even be able to buy the 2MB part anymore. Oh course this attitude is what leads to bloat....

C++

Posted Apr 6, 2006 16:23 UTC (Thu) by gnb (subscriber, #5132) [Link]

I disagree: 2+8 is feasible (just) for a router provided you don't
want to have a bearable login environment as well. Which is miserable for
the developer, but makes no odds to the user. Mind you, this was on an
ARM, which I think has noticeably better code density that the MIPS-based
(?) chip in the Linksys. But you have to prune drastically, the result is
a pain to debug since you no longer have a useable interactive
environment, and I can easily imagine a company deciding it was just less
pain to go for a smaller OS.
>At some point you probably won't even be able to buy the 2MB part
>anymore. Oh course this attitude is what leads to bloat....
Agreed.

Firefox bloat

Posted Apr 6, 2006 7:03 UTC (Thu) by man_ls (guest, #15091) [Link]

Firefox is the 'slimmed down' Mozilla and weighs in at 30MB. Yes it does more, but does it do 20 times more?

Lots more. To be fair you could compare e.g. Navigator 4.X; 4.8 was 11.9 MB gzipped. Compare with Firefox 1.5, which is 5.1 MB uncompressed; for comparison, Opera's installer weighs in at 4.02 MB. Not since the 3.X times had Netscape's browser been this small. I see that as pretty much slimmed down, considering it is a modern browser with Unicode support, CSS...

Yes Linux is bloated

Posted Apr 8, 2006 23:59 UTC (Sat) by Arker (guest, #14205) [Link]

I wouldn't blame it on C++ per se, but definitely there's a situation where many developers are working on machines many times more powerful than older mainframes, so they don't even notice how insanely wasteful and inefficient their coding is. There's even a subset that take *pride* in this, and insult people that try to work with less powerful machines.

The Lessons of the $100 Laptop (eWeek)

Posted Apr 5, 2006 21:10 UTC (Wed) by NAR (subscriber, #1313) [Link]

I have yet to see the hardware device that I couldn't cram Linux onto, and that includes 286'ers with 285MB hard drives that were originally running Windows 3.0

Well, I haven't been able to create a 2.6 kernel that would boot on my 486 with 8 MB RAM, so it's still running with 2.4. It could be my lack of expertise, but unfortunately I wouldn't truss 2.6 on that machine either. I've experienced severe memory leaks in 2.6 kernels (100 MB after about 100 days uptime), but I use the 486 as a router which I don't want to reboot every week/month.

Bye,NAR

The Lessons of the $100 Laptop (eWeek)

Posted Apr 6, 2006 19:10 UTC (Thu) by lysse (guest, #3190) [Link] (1 responses)

"I have yet to see the hardware device that I couldn't cram Linux onto, and that includes 286'ers with 285MB hard drives"

...since Linux requires a 386 or above to run, I sincerely doubt that... (was it a typo?)

The Lessons of the $100 Laptop (eWeek)

Posted Apr 7, 2006 0:44 UTC (Fri) by jd (guest, #26381) [Link]

It's possible - unlikely but possible - that they're referring to the 286 port for Linux. Yes, one did indeed exist. ELKS, I believe. But the size quoted makes me thing they meant a 486.

The first reason being that the MCC distribution would happily fit on a 386SX-16 with 5 megs of RAM - yes, Viglen did weird things and supported non-power-of-2 memory sizes - and could run happily on a 40 megabyte hard drive.

The second reason being that the Linux kernel could - until recently - run in a 2 megabyte machine. Yes, two megabytes. That's it. That's enough to run the kernel, init, a command shell, your basic system daemons, and some small applications.

Even earlier kernels had specific options that could compact pointers and other data structures where you were guaranteed to not need to refer to anything outside of a 16 megabyte window. IIRC, this included swap. Also, IIRC, it was an option that was eliminated because nobody saw the need in maintaining backwards compatibility with devices that small.

As programs are increasingly modular, and I/O is the big performance killer, it's likely that clusters will eventually be massive multi-core CPUs and little or no RAM, as swapping to/from RAM is just too expensive. Better modularity and transporting minimal data structures between cores will be more efficient. Should that ever arise, we'll need that compact pointer option back, because it'll improve performance -and- increase what you can cram into the microbial speck of memory available.

This has not yet occured, but if you plot how CPU development is going (multi-core, multi-threading, cellular designs, on-cpu networking, etc), it is inevitable that main memory will stop being the primary location for programs at some point. It's just not built for massively parallel, high-bandwidth, massively multi-CPU I/O.

When - not if - such a transition occurs, Linux will need to become modular enough that it is possible to shed everything but the absolute essentials for any given install (where the kernel compiler can specify what those absolute essentials are, in minute detail).

No insight

Posted Apr 5, 2006 18:59 UTC (Wed) by anLWNreader (guest, #36915) [Link] (2 responses)

Just an other example of how primitive this gentleman (Negroponte) is. A free laptop for poor children is good for gaming but not for much else without free internet. Internet service needs massive infrastructure which the targeted poor countries lack. And free internet is nice for playing but not much else without knowledge of an international language, either. First things first. And as previously noted, Linux runs fine on $50 phones. That is the market price too, not UN subsidized.

No insight

Posted Apr 5, 2006 20:53 UTC (Wed) by gottlieb (guest, #2240) [Link]

I suspect strongly you didn't attend the talk.

He certainly talked about the internet and the laptops, even when turned off,
function as a router in their wireless mesh network. This affects the power budget for the machine. He mentioned that at some sites they have previously set up using conventional laptops, the first english word the kids learn is "google". So they are definitely aware of the importance of the internet.

His point about newer software being "fat" was entertaining perhaps, but *not* the subject of the talk or project. As he made quite clear, this is an education project, not a laptop project.

I found the talk inspiring.

No insight

Posted Apr 7, 2006 7:52 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> A free laptop for poor children ... $50 phones ... not UN subsidized.

Did anyone say "free"? Did anyone say "subsidy"? The price is $136,
and they expect it to be down to the $50 mark in four years or so. Sure,
it won't be individual "poor children" footing the bill, but the idea is
certainly that the laptops be bought for them by the local education
department or equivalent, as an alternative to spending on other
educational materials -- not by charities.

> ... not for much else without free internet.

I heard the words "network" and "Google" a lot. I didn't hear "free",
but I'm sure someone mentioned "cheap".

Other relevant phrases might be "revolutionary grass-roots mesh network
infrastructure" and "economies of scale".

> .... not much else without knowledge of an international language

We did this to death two months ago: http://lwn.net/Articles/170422/

The Lessons of the $100 Laptop (eWeek)

Posted Apr 6, 2006 11:04 UTC (Thu) by cpm (guest, #3554) [Link] (4 responses)

Step;
1- reinvest war funds into agriculture projects
2- figure out how to spread the available protein to 7 billion folks
3- get a real handle on the concept of peak oil
4- solve the fresh water issues,erosion control/flood control
5- restructure transportation around people, not cars
6- insert favorite cause
7-5000 other causes
5001- cheap laptops

Just a thought.

The Lessons of the $100 Laptop (eWeek)

Posted Apr 6, 2006 11:28 UTC (Thu) by odie (guest, #738) [Link] (3 responses)

Or, step;
1 - Give people all over the world the tools they need to participate
2 - Solve problems together

Which is most likely to get results, having a dozen computer engineers thinking about world hunger and peace, or having them provide good communication tools for a hundred million people a year?

The Lessons of the $100 Laptop (eWeek)

Posted Apr 6, 2006 14:18 UTC (Thu) by cpm (guest, #3554) [Link] (2 responses)

Good question.

I don't know.

The Lessons of the $100 Laptop (eWeek)

Posted Apr 6, 2006 19:19 UTC (Thu) by lysse (guest, #3190) [Link] (1 responses)

Put another way - which is more likely to lead to a solution to the problems of world hunger and conflict: a hundred Western geeks trying to come up with a good global solution; or a dozen computer engineers setting out to develop communications tools that will let a hundred million people share ideas globally that will help them to solve their own little corner of the problem...?

The Lessons of the $100 Laptop (eWeek)

Posted Apr 9, 2006 14:22 UTC (Sun) by grouch (guest, #27289) [Link]

That is as concisely as I've ever seen the point made. Thank you!

The cheap laptop is not proposed as a solution to floods, famine, plagues and war. It's a communications tool for those who have no means to obtain one currently offered with equivalent reach. The ability to communicate quickly and easily can help people "to solve their own little corner of the the problem" by building on solutions others have found rather than solving the same or similar problem from scratch in each remote location. It's a tool that can provide some relief from the effects of isolation. It's not predictable what people will discover or create through its use in swapping ideas.

It's GUI stuff, not the Kernel

Posted Apr 10, 2006 6:31 UTC (Mon) by pengo (guest, #7787) [Link]

From hearing other people involved in the $100 laptop project talk (as well as Gnome people), I believe Negroponte is referring to Gnome (and/or possibly KDE) and desktop applications being bloated, rather than just the kernel itself.

I remember one prominent developer on the project saying in January that Ubuntu live fits on a CD so if it was compressed to half the size it would fit the specs of the $100 laptop.... not realising that live CDs (from Knoppix onwards) already use a compressed filesystem.

The $100 laptop project is quite far along now, it's a bit late to be noticing the bloat now.

Linux kernel bloat...

Posted Apr 14, 2006 16:17 UTC (Fri) by dps (guest, #5725) [Link]

I am have used linux long enough to see serious serious spec sheet inflation. In the 0.99pl13h days X11 was good with 8Mb of RAM and 486DX2/50. Some people where finignf 486DX/33 boxen alright too. The kernel source was 300Kb and combined/root boot floppies supporting everything where possible. Kernel modules did not exist at the time.

Currently 2.6.x kernels with just the hardware required are usually larger than 1440Kb, so do not fit on a standard floppy. There is no way I would sacrifice IP tables at the altar of a smaller kernel, but the evidence of bloat is clear. (In case you are wondering these kernels do /proc/config.gz support and do not do modules.)

Opoenoffice, gnome, X11 and gcc bloat are obviously worse. Instances of firefox's JVM >200Mb, albeit most of it not resident, speaks for itself. IMHO C++ produces slighly larger and slower binaries which consume more memory than a C equivalent.