Stats

It does not work in a PC with 64MB or less of RAM and no swap file/partition, in the situation where there is also a tmpfs requiring some of that RAM. Even big apps like Xorg and SeaMonkey can run in that much RAM, but not depmod.

Anyway, I'm starting to grumble again, so moving on. I found a solution. I downloaded Busybox 1.14.2, which has the 'depmod' applet.

I tested on my 64MB IBM Aptiva, and it works. No need for any workaround that I had previously implemented. It just works.

So, I have implemented a permanent solution for all Woof builds. This Busybox 'depmod' applet now replaces that "full" depmod in all future Woof builds. Hey, this makes a change, I'm usually going the other way!

Note, I tested 'modprobe' and 'modinfo' from module-init-tools and they are happy with the 'modules.*' files that the Busybox 'depmod' has created.

You might wonder why not go all the way and use 'modprobe', 'modinfo' and 'insmod' from Busybox. Well, on previous tests, the Busybox modprobe did not work properly -- does not handle aliases as the passed parameter -- but then, the last I tested was Busybox 1.8.2.

Posted on 3 Jul 2009, 20:11

Comments:

Posted on 3 Jul 2009, 8:10 by dogoneBusyboxMight this be a good time to examine TinyCore 2.1? It employs Busybox (with GNU as an option) and is a very "dial-able" 11MB. TC could provide some valuable points of reference.

Posted on 3 Jul 2009, 20:25 by BarryKRe: TinycorePuppy is the size it is for very good reasons.

Of course you can take things out until you get down to a similar size to TinyCore.

In the case of dialup, TinyCore would be missing lots of kernel drivers for the software modems. Like the Intel 536/537 and the Conexant HSF that I have in the latest 415/416 builds -- together they occupy about 3.5MB uncompressed. The others would add up to quite a bit, and some have firmware tarballs, also included in Puppy.

I could go on. You will find the same story with multimedia, printing, networking, etc., etc.

In the case of Busybox, Puppy has a long history of refinement, originally using Busybox almost exclusively, gradually replacing with the "full" utilities where it was necessary. Today there is a blend that is optimum. Going back to "all Busybox" would be a very bad move.

Ditto, I gave up on uClib a long time ago. There were some early puppies built with uClibc. There were also a lot of packages that wouldn't compile, which as far as I'm aware is still the case.

So, you can fire up TinyCore and admire it's small size, but any assessment would be superficial until you have used it very heavily, on a wide range of hardware, and for a long time and encountered all of the issues that I have mentioned above.

Posted on 3 Jul 2009, 22:59 by dogoneTiny Core vs PuppyUnderstood and agreed. My interest in Tiny Core 2.1 is driven less by it's size than by it's package management. Packages are .tgz and mounted on loop devices at boot with little delay (TC boots here in ten seconds). "Extensions" are maintained in a single external directory and can be either loaded at boot or afterwards (../optional). Un-install involves simply deleting the .tgz. I am especially impressed with TC's terrific "Application Browser".

So no, let's not strip Puppy down to 11MB. Let's do take heed of TC's clever design. It does somethings differently and very well. "Why did they do it that way?"

Posted on 4 Jul 2009, 10:25 by kirkre TC vs puppy Fast boot is again a result of poor hardware support (few kernel modules), sparse packages and no Xorg. Puppy has goals of being small and efficient and to just work. Those two goals are in many ways in conflict. So compromises have to be made, personally I like puppy a bit bigger (more towards the just works goal) but others like it more toward small and efficient goal. Bigger is a slower boot, smaller is a faster boot. At least with a CD/frugal/USB install. With a full install it doesn't matter that much, puppy will boot in under 15 sec on newish hardware.

ttuuxxx made a new build for Puppy 4.3.2 using latest Woof (date sept4,2010). This build has problems loading initramfs modules using modprobe, seems like the modprobe applet used by rc.sysinit script donīt append these initrd modules to the dependency files.

The modules are loaded by initrd at boot but after the switch_root process, the initiramfs files copied to main system canīt be used by modprobe. The depmode-FULL do the work-.