Thinking about a new mini-distro
 

This is mostly dreaming at this stage, but I have been considering the possibility of creating a new minimal Linux distribution. Obviously, there are a million mini-distros out there already, but most of them seem targeted towards minimal space requirements, rather than minimal memory and CPU requirements. What I would like to have is:

• A fairly recent kernel (2.4.20 or so) with essential hardware support built-in, but everything else modular. Optimized for constrained memory use.
• KDrive TinyX with an easy, lightweight window manager
• Applications that would be of interest to non-geeks, predominantly: a lightweight browser, image viewer, word processor, maybe a few games.
• Idiot-proof installer. Installs via CD or a few floppies.
• Runs on a 486 with minimal RAM. 8MB would be good, 4MB would be even better.

The idea is to have a simple distribution that my grandmother could install, and which could help put all those old obsolete machines to use for someone who isn't going to use it for much besides email anyway.

There is already the 2-disk X distribution, which is close but not quite. I do not know if it's feasible to run an X server, window manager, and applications on only 4MB of RAM, but I would think that a highly optimized kernel with a very small memory footprint, combined with TinyX and an almost total lack of any other running services (even syslog would be nigh unnecessary) could make it possible.

Anyone have ideas? My main concern right now is getting the kernel small enough. Using the usual menuconfig/xconfig kernel interface, I was only able to get a kernel down to around 590K compressed. According to this, it's possible to get it down to 370K uncompressed, but they don't say how. Maybe that's using older kernels, or hacking about in the source code. Pointers here would be helpful!

Also, one possibility is to use uClibc instead of glibc, which promises to greatly reduce space requirements, and might also reduce memory requirements.

Something like this would also be good for embedded devices, if it worked. Linux is all about choices, and I think that's part of the reason that most distributions are so bloated; they all come with multiple alternatives for a lot of applications. Narrowing those alternatives could significantly reduce installation size, not to mention memory requirements.

Can it be done?

"Something like this would also be good for embedded devices, if it worked. "
Embedded devices use Embedded Linux. One of the ways that embedded Linux saves space is to use Busy Box. Busy Box is a small, simplified implementation of the standard command line utilities. You might take a look at Busy Box.

"My main concern right now is getting the kernel small enough."

Aside from Embedded Linux the best small kernel around is tomsrtbt. You might take a look at how Tom sets up tomsrtbt to get some ideas for miniaturization.

"Idiot-proof installer. Installs via CD or a few floppies."

Or you could possibly make the CD be the installed operating system. Take a look at Knoppix or LifeBoat (see my signature).

"Runs on a 486 with minimal RAM. 8MB would be good, 4MB would be even better."

At these memory sizes you would probably have to forgo a GUI.

"Can it be done?"

You have a trade off between size and available functions. You can create a very small system but how much it would have in the way of useful functions is the question.

___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeBo...home.page.html

Steve Stites

I will check out tomsrtbt for some ideas on kernel optimization. I've also found this page about designing a minimal real-time embedded system which seems to have some good info.

How much difference would it make to use an older kernel, such as 2.0.x or 2.2.x? Obviously there won't be advanced support for newer hardware and such, but that is not a problem because most 486's don't have much new hardware in them :) I could probably save some space there.

I think for now I will concentrate on getting a bootable system onto my 486 laptop, and see if I can get X to run acceptably. I've already succeeded in getting the KDrive TinyX server to run, but it begins to choke once a window manager is started, since the memory runs out and it has to use the swapfile. Displaying an xterm takes about 10 minutes. Heh. But from what I can tell, KDrive itself is less than 1MB; the kernel uses up most of what is left, and I don't have much else running, so I think the key lies in getting the kernel to be small. I've had a stock mini-distro (muLinux) with X running on a similar laptop with only 16MB of RAM, and it performed quite well, considering that distro also comes standard with a web server and probably a dozen other programs that don't need to be running (not to mention it uses the standard xfree86 server, rather than the KDrive one).

That's a good idea about using a LiveCD like Knoppix does. I do know about Busybox, mostly because it's what my Zaurus uses :) it will be a definite advantage, as well.

Any other suggestions are also welcome. I will be hacking...

"That's a good idea about using a LiveCD like Knoppix does."

If you want to create a LiveCD then take a look at LifeBoat. LifeBoat is a script to create bootable CDs for use as a rescue CD. If you need a script to create a LiveCD then LifeBoat has already done about two thirds of the work for you.


___________________________________
Be prepared. Create a LifeBoat CD.
http://users.rcn.com/srstites/LifeBo...home.page.html

Steve Stites

http://linuxdocs.tuxfamily.org/artic...id_article=112

This is a page presenting 6 knoppix-based distribution. I know it is in french, but just click on the links called "Lien vers le site" (link to the site) to go to the websites of these distros.

Where is also menuetOS, which has a real guy, and runs from a diskette.

Thanks for the links!

At the moment I'm focusing on reducing the kernel's memory footprint. The 2.4.20 kernel that's already on my 4MB laptop appears to be eating up quite a bit of RAM. The boot-time message shows:

Memory: 2516k/4288k available (925k kernel code, 1384k reserved, 168k data, 56k init, 0k highmem)

With only 2.5M available to run everything other than the kernel, it disappears pretty fast. With any luck, I can reduce that 925k number to something more like 300k :) If anyone knows of ways to reduce the amount of reserved memory, please let me know. I saw one suggestion of using a boot parameter of 'mem=xxx' where xxx is less than the amount of RAM actually available, but I tried that and the thing simply wouldn't boot. Probably not enough space to uncompress the kernel, since that's where it stalled. Not sure what the 168k of data is being used for, but with any luck I can shrink that as well. The init memory of course is freed after booting.

I've downloaded and compiled a 2.2.25 kernel which uses around 390K compressed - a 200K reduction from the 2.4.20 kernel. I've also been looking into lowing some limits on things like max number of TTYs, IDE devices, and so on. Lowering the number of TTYs from 64 to 1 should make a difference; I don't know how much impact a reduction in other things like max number of open files, max child processes etc. will make, but I'll probably tinker with those too. (I just gotta get it onto a floppy now - my main box's floppy drive has apparently kicked the bucket, with lots of I/O errors).

My Toshiba's BIOS is apparently also shadowing 190K of ROM into main RAM. Disappointingly, there is no way to disable it. Must be required for the thing to work.

I found a great walkthrough for creating a 1- or 2-floppy boot/root set. It uses uClibc and BusyBox; the root filesystem with busybox, mke2fs, and e2fsck, takes up around 920K, and the kernel (2.4.18 is used) comes to around 400K with most features turned off. Busybox itself is about 218K, and some of its capabilities could be disabled to save more space. I wasn't able to get the 2.2.25 kernel to work with uClibc compilation, but there is some more potential there if I can make them cooperate.

After booting, my available RAM is at about 2.9MB, which is 400K more than I had before! I did not experiment with limiting the number of consoles and such, so I hope to be able to gain a little more by doing that. I seem to recall that the KDrive X server uses about 900K of space, so it is not likely that I will be able to fit it on the same root floppy with everything else; a bit of cleverness, though, should give me a 2-floppy set with the capability to partition and format a hard disk, and install busybox and KDrive.