Slashdot Mirror
Lightest of the Light Linux
An anonymous submitter writes: "This looks kind of interesting for those
who want to run a feather weight Linux on really old hardware."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
There are several small distros designed to run on older hardware. Some, like tomsrtbt and coyote can run directly from a floppy, with no need for even a hard drive. Many of these started life as glorified rescue disks, but with the modular nature of Linux, it's possible, for example, to run a working mail-server on an old 386 with them.
THE GOOD HUMOR MAN CAN ONLY BE PUSHED SO FAR
Bart Simpson on chalkboard in episode 2F18
Great! but as tiny linuxes go, ramf has support for Reiserfs, and a lot of people I know rely on tomsrtbt . Almost all of the information in the IBM page submitted here is already available, but it's really nice to see IBM providing a stable home for this type of information -- while the original linux from scratch server flounders (was it those big bandwidth bills from being /.ed did it in?) and the first cool rescue thing I used, cclinux, has all but disappeared. sigh!
So thanks, IBM. This time.
A lot of the thanks should go to the work by uClibs and Busybox maintainers. Trimming the kernel is important, but the big savings in size is indeed the small footprint of the C libraries and the "combined" busybox binary.
How much space saving? Well, at my work, we initially prototyped some programs that ended up at around 1 MByte, statically linked to glibc. The same program was 120K after statically linking to uclibc, and then 35K after dynamic linking to uclibc.
I know there's various individual efforts out there to re-build Debian around uclibc. Imagine being able to put a full-featured Debian package on a business-card-sized mini-CD's that you can always keep in your wallet!
This is a joke? Delete any of the X11 poop if it somehow got installed, turn off inetd, kill and delete anything that isn't part of the machine's intended use, remove any unnecessary hardware, strip down the kernel ( if necessary ) and boot scripts, patch, use something like radmind to push this out to all of your machines, and then monitor.
This is exactly how I run my servers.
From the FreeBSD handbook:
3.4. What do I need in order to run FreeBSD?
You will need a 386 or better PC, with 5 MB or more of RAM and at least 60 MB of hard disk space. It can run with a low end MDA graphics card but to run X11R6, a VGA or better video card is needed.
http://www.linuxfromscratch.org
Also includes a CowboyNeal load of documentation!
"Delete any of the X11 poop if it somehow got installed"
He should leave it installed unless disk space or security are the issue. Even if he can't afford the ram/cycles to run an X server, he can display apps remotely when he needs to. But really, he should install some more RAM and give the poor disk drive a break.
Here's what you need, straight from the source:
* 386 processor
* 16MB RAM
* 50 megabytes of hard disk space
* 3.5" floppy drive
By the way, that's not the requirements for an old version... That's for version 8.1 with the 2.4.18 kernel... Have fun.
First, ditch KDE and grab a lighter-weight window manager like BlackBox or TWM. Better yet, if possible, ditch X altogether and use the console.
My main network/internet server is a measly ol' IBM Pentium Pro 200MHz. I could upgrade it (I've got several much faster systems gathering dust) - but why?
It handles my light website traffic (a few thousand visits/day) with Apache/PHP/MySQL, and runs Squid, ProFTPd, Qmail, JabberD, and Samba for fileserving to the network... plus whatever I want to do at a console. And it barely breaks a sweat.
whoever said you need alot of computing power for a server is wrong
Not entirely true, but that's close to what I believe.
I had an old P5-233/64M/SCSI system for an office fileserver. Upgraded the SCSI system to UW2 hardware RAID5 and had all manner of problem. Turned out that the TX chipset couldn't handle the newer PCI bus master. There's now a P2-233 in there but the bandwidth utilization graphs seem to indicate that the CPU is still the bottleneck (the LAN isn't saturated, and the sustained disk I/O could bury the LAN several times over). I think samba is having trouble keeping numerous smaller feeds open than one or two big pipes. Oh well. :-)
This question actually comes up every once in a while. The answer from the developers is that AT&T Unix (and therefore BSD) was always 32-bits. Thus the first PC port of BSD was on a 386 (in protected mode). It would be almost impossible to re-write the kernel to 16-bits, unless they were re-writing the OS from scratch.
In Soviet Russia, articles before post read *you*!
MMU-less Linux has been around for a while...
I've seen and worked with companies that built several systems based on it, and it's not a bad way to get Linux-sized flexibility and power in a small, inexpensive package. It was/is straightforward, once one understands system behavior without copy-on-write forking semantics.
A few years ago, a good example of a uClinux implementation was the uCsimm, a 30-pin SIMM sized machine based on the Motorola 68EZ328. 8Mbytes RAM, 2 Mbytes flash, Crystal 8900 (10 Mbit) Ethernet. The 68EZ328 powers all pre-PalmOS-5.0 units. We had a web server with complete CGI capability, as well as several additional communication front-end tools. So I know Linux runs on the 68EZ328, and I've seen references to the Palm H/W in the uClinux kernel code, though I haven't tried it on my Palm...
More recently, uClinux also runs on NetSilicon Net+ARM family processors, http://www.netsilicon.com/
The people who tried to commercialize uClinux (and probably worked on uClibc, though I am less sure of this connection) were Rt-Control, a Canadian company that were subsequently acquired by Lineo: http://www.lineo.com/
I have no relationship with either Lineo or NetSilicon, other than being a (mostly) satisfied customer.
I just don't see how it is feasible to leave dozens of tiny utilities littered all over the root filesystem.
With busybox, you just end up leaving dozens of symlinks littered all over the root filesystem. (bb looks at what the symlink it is called from is named and executes the proper command). From a file-system path search perspective, it is exactly the same thing as a bunch of little binaries. Plus, you get the advantage of easier maintenance, more functionality, better performance, easier drop-in replacement, and less chance of a developer turf-war (the maintainers of 'find' don't ever need to talk to the maintainers of 'grep', etc.).
Actually, Linus once did an interview with Boot magazine. He actually said that he never thought that anybody would be able to port Linux to an MMU-less machine, then was surprised to find that somebody had ported it to a Palm. So there you have it, from the man himself. Linux does run on Palms.
A deep unwavering belief is a sure sign you're missing something...
Glibc is pretty fast. In order to save memory, uclibc makes concessions that potentially hurt speed.
A deep unwavering belief is a sure sign you're missing something...
Though busybox has limited functionality in some of its modules, you can always install the full package alongside busybox and then de-configure those particular particular modules inside busybox. A full bash is nice to have around, but other utilities such as mount or swapon can be provided by busybox. In this case the guy knows that a full-blown distro won't work, so it's either busybox/uclibx or nothing.
Hey, all, just to put this in context, I've been collecting some very old Itronix Mil-Spec laptops recently (one survived being thrown full-strength by me, a 285 pound ex-marine, from seven feet onto worn-out carpet over plywood, and booted up no problem) because I have a fetish for such things. Let's just say I have a thing for durability. The only problem is, the laptops have a "full environmental seal" which means no cd-rom, no internal floppy, no usb ports, etc. They only have a parallel and serial port, a phone jack, and a PCMCIA port protected with a cast aluminum door and a gasket. My weaker ones have eight MB of ram each and are only 486DX2-50's, with a 260MB HDD. My three stronger ones are Pentium 133's with 32MB of ram each, and about a 1.3 GB disk, with monochrome LCDs. Only one has color, but that one's just a 640x480 LCD. I wanted to run Linux, and not some quirky, doofy ancient Linux either. Here's how I got it to work.
/dev/sda4, i.e. the zipdisk). Zipslack booted with only minor difficulties -- I had to tweak a couple of BIOS settings, that's all.
/dev/hda1"
/mnt/hd.
/bin /mnt/hd/bin". Of course, I didn't copy /mnt or /proc. For those, I just mkdir'ed them in the new directory. Once I was satisfied that the entire zipslack system was copied over to the new partition, I edited /mnt/hd/etc/fstab and set up the "/" partition as /dev/hda1 (and set up swap as well, although I wasn't sure I had to do that). Then, I rebooted using the boot disk.
/dev/hda1. I booted into my hard drive's Linux, and ran liloconfig to set up automatic booting with LILO. I ran it in expert mode, and set up only one entry, i.e. that for Linux. Then I set it up to automatically boot into that entry with no delay.
;P
Step 1. I have an external floppy that connects to the PCMCIA slot, and a parallel port zipdrive. So, I downloaded Zipslack (available on the Slackware website) and the companion, fourmeg.zip, which creates a swap file. Zipslack is interesting because it creates a UMSDOS slackware installation on a zipdisk (just unzip it to the zipdisk). This can then be booted from the zipslack boot floppy (boot from the boot floppy, then direct root at
2. Once in Zipslack, I had to set up the Itronix's hard disks for Linux. So, first, I fdisked, and set up most of each disk as a type 83 Linux partition, and the rest as a type 82 Linux swap. I probably gave too much swap; I took a guess for the "big" ones and made it like 88 cylinders; I think it turned out to be better than 128MB (I made it a LOT smaller on my little ones). Next, I formatted the disk: I ran the command:
"mke2fs -L armadillo -c -c -j
This surprised me a little, pleasantly: I knew the two "-c" params would cause it to overwrite the disk with nulls, but it did it FOUR TIMES, which is pretty damn thorough. Once that finished up (it took at least an hour on my old machines) I mounted the disk as type "ext3" on
3. Now, I copied my entire root directory onto the mount point, leaving out the loadlin stuff and files that were obviously DOS related (like the DOS mount directory). I copied each directory using (for example) "cp -a
4. This time, I pointed the root directory at
The result is that my little Linux machines all work perfectly!
On my "big" ones, I put a bunch more stuff in. I put in the development disk set, plus x, xap, most of n, and this coming week I'm adding kde and gnome. On my "little" ones, I've only got 260MB of space, so I'm going to stick with text-mode. I'm toying with the idea of using emacs as an environment for those, IF the e set will fit on 'em of course.
The most expensive of these laptops was 150.00. The cheapest was 25.00. Zipslack was free. Now, is that a great deal or what? Especially considering they're like indestructible little armadillo monsters, right?
Oh, by the way: I'm using Zipslack 8.1 and I'll probably upgrade to 9.0 when it comes out. Gotta love Slackware! Bob RULES!
BTW: my grammar isn't so hot today. It's the Marine Corps Birthday (10 Nov) and the "Marine Corps Drink" is the Rum and Coke, so cut me some slack there (ha! get it? SLACK! I slay me)...
Farewell! It's been a fine buncha years!
I just don't see how it is feasible to leave dozens of tiny utilities littered all over the root filesystem.
/bin/busybox "command" [optional flags] or you can symlink/hardlink it to [command] and run it like the ordinary command.
/bin, not much added elegance.
Busybox works two ways, either
If you do it the first way, busybox "command" you'd have to type the extra letters all the time. You can alias it, but then you'd have to have a support issue with all the users unless you had universal aliases, and thats not optimal.
If you do it the second way, with the symlinks or hardlinks, you still have all the things in
The code in busybox gets complicated. The added elegance in the file system becomes complications in the source code. Any updates to any of the "functions" as busybox calls them, requires an update to essentially all your userland utilities (as expressed in busybox). Lots of updates, lots of testing, because now any change to anytihng in busybox requires you to test everything, because a change in the ls "function" is in the same code that contains your mount command, and your cat, and your rm, etc., and now you need to test all of those as well.
Shared code can go into libraries. That's why libc is usually dynamically linked, shared code should be shared. You get your elegance with asmall executable with much of it's guts in shared libraries. Elegance here causes ugliness there. You pick your battles, you do things the way you want to. That said, busybox is opensource, and all of the gnu utilities are opensource as well. I don't think the busybox folks would mind patches from you or any others that share the view. I personally don't agree, my "elegance" is in smaller utilities with well defined functions, and I would not contribute.
Opps.
0,$s/GB/MB/g
Mind you, it handled the 4GB disk quite well, once linux booted. Of course, it had a bit more ram then.
Democracy isn't about no one telling you what to do. It's about everyone telling you what to do.
Actually, E and IceWM work as fast as any on slow hardware. I spent most of 2001 travelling in Europe and took an ancient P120 laptop with me - I tried various "light-weight" window managers (KDE took 5 mins to start up from the login screen (I timed it!) so it wasn't an option) such as blackbox, IceWM, TWM and FVWM, and as far as I was concerned it was E and IceWM that won the day. (IceWM was extremely impressive, starting in just under 3 secs from login in its 'light' form; E took maybe 10 secs, but was still extremely acceptable)
The interesting thing about both of these WMs though is that they're still being used on current, fast hardware as well - unlike TWM - and are actively being developed (although, I don't know if you could say E is being developed "actively" :)
As long as the bios can see enough information to boot linux, the linux kernal can access any disk, independent of the bios. I have an 80 GByte disk in my pentium 133, and the bios refuses to see it, but has no problem booting since the boot partition is on a smaller 1 Gbyte disk, which then mounts the 80 gigger as /home
Always looking for an excuse to post my personal HOWTO for using uClibc & busybox to make a single floppy linux disk. I also have a few example floppy images here. My firewall is running from a linux floppy right now.
Just in case people are not aware, in addition to the BusyBox and uClibc websites, there is also a #uclibc channel on irc.openprojects.net (irc.freenode.net). I often show up there, and as time permits, I try and help people with their BusyBox and uClibc problems. It makes a nice resource, and helps take the load off of my Inbox a little bit.
:-)
Also, I'd like to stress that we do have mailing lists, and people are encouraged to use them. I get _way_ too much email to answer it all. It bugs me when I get "I was too busy to check the mailing list or the FAQ, and just thought I'd ask you directly" type emails. Sorry, but I just have to ignore such people. Use the mailing lists. Try to catch me on irc if you can. But please don't sent me personal email unless you are also sending donations...
-Erik -- --This message was written using 73% post-consumer electrons--
AT&T Unix (V5, V6, V7) and BSD Unix (2.X) started out as 16-bit operating systems. They weren't ported to 32-bit systems (VAX, 370) until later. Even after they were running on 32-bit machines, there were still releases that supported 16-bit systems. I used to run AT&T System V Unix on an 80286 based computer.
Mea navis aericumbens anguillis abundat
It's based on FreeBSD 3.0-Current and needs only a 386SX, 8MB RAM and boots off a floppy (HDD optional ;)
Join the TWIT army now!
33Mhz, 32Mb and a 250mb HD for my debian web server.
I recently installed Debian on a similar but lower-memory system (8MB) as a web server (yes, I am going to add more memory soon). Aside from a memory-intensive stage where apt-get was merging some package data, it went smoothly but slowly.
The reason I mention this is that I've seen posts where people say they installed a small linux system on a computer with 4mb of memory "a while ago", and posts where someone has recently installed a small linux system on a computer with 16mb of memory or so, but no mention of really low-memory systems. So I figure that I should mention that a reasonably up-to-date distro (Debian) does install on 8mb, though it'll get ugly at one point if you don't have more like 16mb. Also, perhaps the 4mb Laptop How-To is worth mentioning at this point.
which is already set up to run on old hardware, has some really great configuration tools, but really outdated software (2.0.x kernel, libc5, X 3.3.1), such that I shuddered when connecting it to the internet.
Full plate and packing steel! -Minsc
Um, gentoo (1.4 anyway) defaults to gcc 3.2. On my 2GHz P4 with 640MB of RAM, it's already a several day installation (KDE takes a full 8 hours). I really don't want to imagine it on a P133 much less a 386 :)
A deep unwavering belief is a sure sign you're missing something...
ROCK Linux?
;)
ROCK Linux is a distribution-build-kit, with which you can easily create targets, for example a "small" target. Everything is compiled from source, optimized to your wish (gcc{2,3}, glibc{2.2.5,2.3.1},dietlibc...) once you start a build.
The download of the source tar.bz2/gz's is done by a script, too.
We are currently working on integrating uClibc, and already use dietlibc for the "bootdisk"/ "rescue system" target.
maybe worth a look
FAKE
I'm using both FreeBSD and NetBSD on my machines. But as you guessed, FreeBSD needs more ressources than NetBSD. While NetBSD 1.5 runs fine on my 486SX33 /w 8MB RAM (7.8 MB are usable), FreeBSD needs 12MB or more at least for installation. NetBSD even installs with 4MB RAM. I even tried to install it with 3.8 MB RAM usable but that was not possible (fdisk ran out of memory).
As a matter of fact I'm using FreeBSD on my FASTEST machine - mainly because building the ports needs a lot CPU power - and NetBSD on my slowest (it's a good "SpartaniX").
All the other machines (4) in between are Linux, mostly Debian. A 486/DX66, now with 16MB RAM, is running Slackware 8 with X on top.
But it's not true - as stated in the article - that the lastest Slackware needs 12MB RAM. It installed fine with 8 MB RAM.
However, for the slowest of the slow I would suggest NetBSD - it's the least demanding, while I don't think FreeBSD is really great for minimal installs. Compare the defaults. NetBSD has less than half of the programs in [/usr/s]bin compared to FreeBSD. And even less than OpenBSD:
--- censored
Hey, it wouldn't do much, but it's linux, it boots from a 386 without any hard disk, and most of all it doesn't require a keyboard. Obviously, if you want a decent performance you need a P4 2.8 GHz with SCSI RAID (the world could get upset if I don't greet it properly only for a disk failure).
Signatures are for stupids.