water cooler :: Linux's ever-increasing size...



You know, making a single-floppy Linux is getting pretty tough, nowadays!  This revelation came when I tried making a floppy-based distro (mostly to be used like a typewriter, with little more than vi and support for some common printers).

Okay, I had been looking at various how-tos for making boot floppies, and I noticed that almost none of them even mention a boot/root diskette.  They all seem to break it up into 2 (or even more!).  Looking at various programs, I can see why.  The kernel, itself, has greatly expanded, over time.  True, you can re-compile without the extra features, but even the really core system seems to be expanding.  I gave up on that idea.

I then decided (since I really wanted a bootable floppy) to look at some that had already been made, like muLinux or Tom's root/boot disk.  Even with compressed filesystems, they still had to rely on over-formatted floppy disks.  I read the warnings about what can happen to your floppy drive, doing that, and quickly left.

Programs are getting larger and larger, but that's not the only problem.  Linux does a lot of things (logging, etc.) in the background, that can eat your free space while you're not looking.  Though these things can be prevented (like the read-only filesystem on a live-cd, for example), it sometimes seems like we're trying to fight the system, bending it in ways it was never intended to be bent.

Has there ever been an attempt to, from the ground up, optimize Linux for space-savings?  I'm not referring to just re-compiling, but re-coding.  It would be an interesting for those wiser than me to attempt.

Remember when an entire operating system could fit in 64kB of RAM (Commodore, anyone?)?  Though the new features of the larger system are sometimes nice, it makes it tougher and tougher to make small distros.

I'll give it another try, this weekend, but I think Linux might have finally outgrown the single floppy.
Try an old kernel then. :D
Don't believe those warnings about over formatted floppies :)
I've used Toms for years and never had a problem with the 1.7's  being read on a wide selection of machines.
Indeed I can never think of a time when it didn't work.
You've missed out on a great treat - his rtbt would have easily fulfilled your requirements.
Until mr Knopper came along Toms was the greatest show on earth and made it easy to amaze the earthlings :laugh:

You only need his disk and 20mb of temporary hard disk to unpack it to a loopfile and and rebuild, using the built in scripts.
There is even a tiny print module you can download and build in. Have a browse through the archives on his site.
Really?  From the way they said it on the site, it almost sounded like the risk was much higher.  I'll have to give that a shot, then, because it DID have everything I need! :)

The old kernel idea sounds pretty good, too.  Any idea how old you can go and still support an early PostScript printer?  I'll have to look through the archives and changelogs and see what I can find.

I had also forgotten about the strip command, when compiling.  Does that work on a kernel?  I know some people have problems doing it with libraries...

Well, I'm off to download Tom's and try it out!  Thanks for the advice!
You can't strip a kernel AFAIK, but you can build it with size optimisations like "-Os -fomit-frame-pointer" (that's how I build all software I compile). There's also a tool called UPX, which can compress kernels in the latest beta version.
Next Page...
original here.