Micro Core with 16 MB of RAM

[tinypoodle]

technosaurus,

most interesting info indeed 

Looking at the output of 'ps' of OpenWRT running on my router I notice '/sbin/hotplug2 --override --persistent --max-children'
http://code.google.com/p/hotplug2/

[curaga]

Another - replace busybox with a cutdown version and don't use shared glibc for it- use static uclibc... using shared glibc for busybox is a complete waste of resources as soon as /sbin/init runs.  If you don't believe me run top with glibc shared... remaster and rerun top with a static uclibc build (you can get recent prebuilt versions from impactlinux.com/aboriginal)  ... the difference in ram usage exceeds the difference in size at the first run of any busybox app and since they are both in ram ...

Does this take into account the kernel-level sharing of library pages?
There are other apps linked to glibc, such as udev.

To go even further, rebuild any busybox applets that run daemonized as individual static uclibc binaries - use allnoconfig and then select only that applet. (aboriginal has a cross compiler for this too) ... or just don't run those daemons. *logd, getty, udev...(aboriginal uses oneit instead of init)

You mention two parts here - uclibc using less ram than glibc, and separation of daemons. Why the separation?

Busybox with one applet would start faster, without the applet name lookup, but lose in size due to the binary sharing. RAM use when separated should be ~the same, if not, that would be a bug.

there is a new method since 2.6.32 called devtmpfs which is a better, more simplified version of the former devfs (problems with its original incarnation are a big reason the likes of hal and udev even exist) ... the new implementation is only ~300 lines of kernel code, but is supposed to significantly speed up the boot process compared to udev  (this may not be as significant when compared to distros that have a partial static implementation of /dev though)

We took a look in the 3.x development cycle. It proved not to gain much at all, indeed due to our existing static dir.

<rambling>
.... I really wish they (kernel devs) would pick a name and stick to it though -- ramzswap (ore whatever it was called) is now zram - which conflicts with the naming of a very fast and cheap (to make ... maybe not necessarily to license) alternative cache/ram technology - so it will likely change again.
</rambling>

I understand the rename ramzswap -> zram, since it's no longer limited to swap.

[tinypoodle]

Another - replace busybox with a cutdown version and don't use shared glibc for it- use static uclibc... using shared glibc for busybox is a complete waste of resources as soon as /sbin/init runs.  If you don't believe me run top with glibc shared... remaster and rerun top with a static uclibc build (you can get recent prebuilt versions from impactlinux.com/aboriginal) 

Not sure why one would have to remaster for such.
I downloaded a static uclibc busybox build from that site and ran same applet from both versions side by side for direct comparison, rather impressed by the difference in mem usage.   

[curaga]

Being curious, I did a comparison as well

glibc busybox sleep vs static uclibc busybox sleep from Rob's aboriginal site.

Top did show a difference, but pmap -d showed the glibc sleep using only 32kb more ram. That's small enough to be offset by the library & binary sharing.

[hiro]

How about heirloom.sourceforge.net ?
I'm not completely fond of busybox

[curaga]

All applets combined the size is smaller than glibc

Since glibc has to be loaded anyway, this looks like a loss to me. The ram savings < the ram use increase from unsharable pages of the static uclibc.

If you don't separate them, then each daemon will run in a separate process and use RAM the size of busybox + whatever it needs to be writeable (I did a compromise method and just built daemonized applets as a separate ~80k binary)

No, my understanding is that the kernel shares the binary pages. Not only are they loaded only once, in our case they aren't loaded at all (tmpfs = cache, so busybox is already available without a memory copy).

I tested this by starting four 9.1mb mplayer processes. The ram increase was not 36mb, but 11mb.

The biggest win would be if it could obsolete udev, which it doesn't seem to do at least yet.

True, if the same functionality was possible without a daemon, great. But the kernel devs have taken the stance that device permissions belong in userspace, and udev is a much better solution than hotplug.

[danielibarnes]

Anyone interested in compiling the tinycore binaries statically against ulibc (where possible)  in order to quantify the difference? I am curious. Any significant gain would be of value if functionality were not affected, even if only available as a "remix."

[hiro]

I don't think stali is usable at all.
But I'm interested in a uclibcore.
I think it should support mips, arm, 64 (I'm missing this in tinycore)