Slashdot Mirror

I have to say, I've made pretty damn small minimal installs using buildroot.

Linux can be configured to run in 2MB of RAM and 2MB of flash or less. It can run in 4MB RAM with a full network stack, busybox, and several hundred K remaining for apps.

There is no other full featured free unix like kernel which can do that. Certainly none of the free BSDs.

I'll take the bait. Care to show a reference to running a modern Linux kernel w/ 2 MB RAM, or 4 MB RAM with busybox, on i386 or ARM? Busybox can do wonders for storage requirements (e.g. for NAND FLASH), but it doesn't help with RAM at all! I found 8 MB to be difficult enough (!), last I tried ulibc and busybox on i386.

Just as a point of discussion, generic NetBSD is smaller than generic Linux (e.g. Debian) on the ARM platforms I've been using. A line from top shows the latest (NetBSD 5.1.2) kernel RAM footprint on ARM9: about 1.2 MB, with numerous filesystems, NFS, networking, USB support, etc. built in. This includes all kernel modules.

    PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
        0 root 125 0 0K 1240K schedule 0:00 0.00% 0.00% [system]

Running 1 instance of httpd, sshd, and two user processes, minus 1.5 MB of buffers/cache, it's using 5.5 MB of RAM right now. Tightened up, it might boot in 4 MB but I haven't tried. Do note that this is with the standard (Net)BSD libc, all completely generic, 'out-of-the-box'.

Amazing work has been done to cram Linux into small places, but I think it's somewhat disingenuous to say that no BSD is close. I'd say NetBSD provides a rather interesting starting point.

I will second both points of this. Using buildroot for multiple types of boards/chips. buildroot helps in creating a reproducible toolchain, kernel, apps, and filesystem images. You can add your own application (The main thing to run) as a custom package.
http://buildroot.uclibc.org/

The Atmel at91sam9 series runs fine. Both in graphical and non-graphical environment. I use this for quick proto type testing/dev:
http://www.mini-box.com/pico-SAM9G45-X
(however, I add NAND Flash for os/apps)

As others have stated, Angstrom is also good for building the OS/applications. The build system takes a little bit more care to setup than buildroot.
http://www.angstrom-distribution.org/

If your machine can boot from a SD card, you can build a bootable linux system
well under 2GB, including qt and multimedia, using this project:

http://buildroot.uclibc.org/

I have already used it for a mini2440 with 64Mbytes of ram and a Smagung
S3C2440 micrcontroller with a 926T arm core. Buildroot is self contained
and lets you configure everything from the kernel up to the applications
you want in your system. It is conceived precisely for those small systems with
small amounts of ram and a framebuffer instead of a graphics processor.
Usefull for other architectures like mips, powerpc, i386, avr32, etc.

Nice to see someone actually caring about removing bloat from software after VB, Java, .NET and the
corporate culture behind them literally destroyed any incentive in producing optimized code, nearly
killing the demand for skilled programmers capable of writing such code.

Also, for those working with smaller systems this is a godsend.

It's been done before, depends what you need from the library : http://www.fefe.de/dietlibc/, http://www.uclibc.org/, etc (but these are clearly targetted at embedded systems).

That being said, dependency hell is the main reason Linux cannot get ahead of Windows or Mac for the masses - the abstraction layer may not be as optimisable as on Linux, but you can distribute small binaries and be _sure_ they work out of the box with no issues.

I have done a few embedded systems using the Linux and uClinux Kernel. A couple of things to note:

Embedded tends to avoid glibc in favor of uClibc (www.uclibc.org). It is not full featured but it is a lot smaller.

When selecting a version of GCC and kernel, look at who has already has a running system for your board. You probably don't want to go through the effort to get gcc-4.2.x cross compiling and building your system if somebody already has 4.1.x doing the job.

I would take a look at buildroot http://buildroot.uclibc.org/ and see what options they have out of the box. As an engineer it is easy to want to pick the newest, most feature full version, least bugs version available and call it the "best". Remember though that one of the features is the cost and time to get it running. Your boss will not be impressed if you spend two weeks getting the newest kernel running on the board because it has fixes to sub-systems you don't use; when you could have used older kernel and had it running in an hour.

Also, keep in mind with this board, Ram and Flash cost money. If you are building a large number, the smaller kernel and flash disk are better from the cost/unit. If you are building a small number, the cost to cut you image down in size probably is not worth it.

I have done a few embedded systems using the Linux and uClinux Kernel. A couple of things to note:

Embedded tends to avoid glibc in favor of uClibc (www.uclibc.org). It is not full featured but it is a lot smaller.

When selecting a version of GCC and kernel, look at who has already has a running system for your board. You probably don't want to go through the effort to get gcc-4.2.x cross compiling and building your system if somebody already has 4.1.x doing the job.

I would take a look at buildroot http://buildroot.uclibc.org/ and see what options they have out of the box. As an engineer it is easy to want to pick the newest, most feature full version, least bugs version available and call it the "best". Remember though that one of the features is the cost and time to get it running. Your boss will not be impressed if you spend two weeks getting the newest kernel running on the board because it has fixes to sub-systems you don't use; when you could have used older kernel and had it running in an hour.

Also, keep in mind with this board, Ram and Flash cost money. If you are building a large number, the smaller kernel and flash disk are better from the cost/unit. If you are building a small number, the cost to cut you image down in size probably is not worth it.

Let's have multiple forks of glibc then!

You mean like uClibc, klibc, dietlibc, etc?

And the kernel!

You mean like all those various kernel patches people use? Or maybe the BSDs vs Darwin vs Linux vs Solaris?

and coreutils!

You mean like BusyBox?

A foolish consistency is the hobgoblin of little minds.

have you figured out how to compile a program (even Hello World) and statically link it against a Free implementation of the C++ standard library so that the executable is smaller than 200 KiB?

How about: uclibc? ~100K for the whole library. I assume, you use the embedded c-library newlib in the kit as C-library. So a comparison to an embedded c++ library would be appropriate.

G++-iostream is optimised for performance on standard computers and includes support for locales. Hardly something, which I'd expect to perform well in a space constrained environment.

I recommend Gumstix for beginners.
It uses U-Boot and the whole uClibc BusyBox Buildroot stack for development.
It is rather slick to work with. They even added support for the rt patch not too long ago which was a big bonus for me.
I've been working with it for about a year now and I have to say it's really the best solution for embedded Linux beginners.

I recommend Gumstix for beginners.
It uses U-Boot and the whole uClibc BusyBox Buildroot stack for development.
It is rather slick to work with. They even added support for the rt patch not too long ago which was a big bonus for me.
I've been working with it for about a year now and I have to say it's really the best solution for embedded Linux beginners.

On point 2, you're incorrect. There is no LGPL 3 and you're interpretation doesn't match that of people creating libraries... see http://www.uclibc.org/FAQ.html#licensing for example. Your best bet would be to look through this list for a Linux compatible, BSD licenced library: http://www.uclibc.org/other_libs.html

On point 2, you're incorrect. There is no LGPL 3 and you're interpretation doesn't match that of people creating libraries... see http://www.uclibc.org/FAQ.html#licensing for example. Your best bet would be to look through this list for a Linux compatible, BSD licenced library: http://www.uclibc.org/other_libs.html

On an embedded system, you probably don't need anything running but the kernel, udev, and your application. You don't need most of your libraries; it's going to be more efficient to statically link everything. You don't need bash. You don't need Python. You don't need a package manager.

You don't *technically* need anything else, but for development it can be IMMENSELY useful to have a shell and a base set of utils. Busybox will get you everything you need in a multicall binary under 1MB (dynamically linked to glibc).

Things can be even smaller using uclibc instead of glibc, but unless you are building an EXTREMELY low end embedded device and can't spare an extra 1-2MB or so (or 1/2 that with a compressed filesystem like cramfs) it may not be worth the extra hassle trying to build a uclibc toolchain (and potentially deal with uclibc issues with other utils/libs you may use).

Anyway, the nice thing about Busybox is that you port a single package and get huge range of utils. Overall I agree 100% with a previous poster who said the key to rolling your own OS is getting the toolchain working - once you have that, porting is relatively easy (I'm assuming we're talking about non-x86 embedded systems here... with x86 it becomes easier still, as the vast majority of open source development is done on that architecture).

You might want to check out BuildRoot. It's what Gumstix uses for their distributions and it works pretty well.
They have even has the rt patch from Ingo Molnar merged into their standard distribution. Sounds like a Gumstix might
not be a bad way to go now that I think about it. And then you would have some pretty good community support. My $.02 ...

Start working for change then, including using uClibc instead of glibc and avoiding other bloat-ware. Projects are still stuck using many bloated GNU tools but there are in fact replacements for some.

Linus could have chosen some other libc to link the kernel with (just as the person in your example could have chosen to live somewhere other than in the city).

That may be because building an embedded product with Windows Embedded is just slightly above doing triple integrals in your head in terms of startup complexity. Microsoft's official procedure for creating a bootable CompactFlash card with an NTFS file system for Windows Embedded is to run a DOS utility. It must be run in DOS real mode, not a DOS box, which means you need a CF reader with an IDE interface, not a USB one. This was somewhat tough for us, since CF/IDE interfaces are sold by almost nobody these days. For that matter, we don't exactly have a copy of Windows 98 to dig up and install on a system.

The solution I came up with? Hook a USB flash reader up to a Fedora Core box, and use ntfstools to format it. Took all of fifteen seconds.

Unfortunately, we don't have the option of never working with Windows Embedded again, since we work with whatever our clients need us to... but I've developed three products that use embedded Linux (using Buildroot), and all three combined were easier to get off the ground than that Windows monstrosity.

What Stallman calls GNU/Linux is what *some* Linux distributions distribute.

On the embedded side, there are more and more distro which are using replacements for the GNU tookchain and glibc like busybox and uClibc, thus avoiding many of the GNU tools you typically see in a Linux distro.

Stallman's generalization is mostly true, but not always true...

I've been looking for small cheap headless computers for a long time, but they are hard to search. Want to use them as servers. Found Soekris, which does the job, but took a while to set up. Had to figure out how to net boot, cross compile, and work around various limitations. Meanwhile, the distro I used (uwoody from ucLibc) has vanished, so if I want to update, I'll have to start from scratch. Would prefer something easier to set up, and these don't sound like they are any easier. Still, glad to know about Waysmall and BlackDog. Anyone know of others?

I know this was a joke, but just to pretend I don't get the joke: Actually, on an embedded platform (at least one without a lot of storage), a Linux system is probably going to have very little GNU code. An embedded Linux system is likely to use BusyBox for basic Unix-compatible commands like ls and rm, and something like uClibc or dietlibc for its C library, and won't have things like Emacs or a compiler actually on the system. So it's unlikely to have much actual GNU-project code on it, if any.

Ummm... no. Linux, complete with userland, runs just fine on a 386 or embedded device. If you want to squeeze it down more, you can run a cut-down kernel and use a different userland (e.g. uClibc). It's very capable even then.

One feature of uclibc is that it has many, many compilation switches, with the aim of minimising the size of the library. If gentoo can really figure out how to get all this compatible with their USE flags it would be great. But I would be surprised if they are there yet. For example, has anyone got ALSA to compile with gentoo embedded? I've tried and failed.

An alternative to gentoo is to use uclibc's own prebuilt Debian distro, their build-from-scratch buildroot system or their prebuilt root file system, all at the uclibc site.

uclibc is a tiny libc which fits BusyBox very well. A complete linux system (without kernel) can be built using less than 500kbyte with busybox and uclibc.

Not true at all. Check out uClibc and BusyBox. In fact, I may get one of this NSLU2 boxes *just* to hack on it.

It is a common mistake to think you have something faster just because you haven't yet designed in all you'll eventually need or want.

But it's also a mistake to think that all you'll eventually need or want needs to be designed in right now. It's also a mistake to put things at a more deeper layer than they need to be.

Sure the GNU libc is huge. But that's POSIX, and that's where the Hurd will bridge us from.

Funny, I'm pretty darned sure I've seen smaller implementations. Certainly, application compatibility for them isn't perfect -- but it's certainly Good Enough.

You yourself point out that the quick-and-dirty but real solution is often the one that wins in the market. Why, again, hasn't the HURD been kicked out the door with POSIX support only?

I am sorry if following the rules hurts sveasoft's business. Tough. Guess how much money I earn for every device sold based on my code? Zero. I see no reason why other's such as sveasoft should profit where the authors of the code earn nothing. Expecting to earn royalties off of what he received for free and has modified slightly is a poor business model.

Instead, you guys should look at uClibc - a small, fast, and sleek implemention of glibc, that is finding its way into more and more devices every day.

We are talking about an order of magnitude smaller code footprint here people.

If you want the embedded world to jump on to this bandwagon - uClibc is the only way.

[crap. had a less than that i didn't entityize correctly. apologies for screwed up parent post]

If you want to build your own using a prepackaged set of tools, I strongly suggest using buildroot.

My firewalls are all diskless boot machines (they pull their image from a server that's on a private network), so size *does* matter to me. Having the full development environment simply is not an option.

As others have pointed out, having gcc on your firewall isn't going to provide you with a great deal of security. Just another (and a tiny one, at that) hoop to jump through. If they can root your box, then they can upload a compiler (or, more likely, a precompiled binary).

I use buildroot to compile my system. I have to tweak the make scripts, but I can get openssh/iptables and a bootable system compiled in a <6MB image. (it can be made smaller, but I've got logging and other stuff on there).

I also have a modified version of gshield which generates a script that I can edit to use as my firewall.rc. (I don't actually use ghield as the firewall, just capture the commands that it would have executed to create the ruleset at runtime)

Best of luck.

[crap. had a less than that i didn't entityize correctly. apologies for screwed up parent post]

If you want to build your own using a prepackaged set of tools, I strongly suggest using buildroot.

My firewalls are all diskless boot machines (they pull their image from a server that's on a private network), so size *does* matter to me. Having the full development environment simply is not an option.

As others have pointed out, having gcc on your firewall isn't going to provide you with a great deal of security. Just another (and a tiny one, at that) hoop to jump through. If they can root your box, then they can upload a compiler (or, more likely, a precompiled binary).

I use buildroot to compile my system. I have to tweak the make scripts, but I can get openssh/iptables and a bootable system compiled in a <6MB image. (it can be made smaller, but I've got logging and other stuff on there).

I also have a modified version of gshield which generates a script that I can edit to use as my firewall.rc. (I don't actually use ghield as the firewall, just capture the commands that it would have executed to create the ruleset at runtime)

Best of luck.

If you want to build your own using a prepackaged set of tools, I strongly suggest using buildroot.

My firewalls are all diskless boot machines (they pull their image from a server that's on a private network), so size *does* matter to me. Having the full development environment simply is not an option.

As others have pointed out, having gcc on your firewall isn't going to provide you with a great deal of security. Just another (and a tiny one, at that) hoop to jump through. If they can root your box, then they can upload a compiler (or, more likely, a precompiled binary).

I use buildroot to compile my system. I have to tweak the make scripts, but I can get openssh/iptables and a bootable system compiled in a gshield which generates a script that I can edit to use as my firewall.rc. (I don't actually use ghield as the firewall, just capture the commands that it would have executed to create the ruleset at runtime)

Best of luck.

If you want to build your own using a prepackaged set of tools, I strongly suggest using buildroot.

My firewalls are all diskless boot machines (they pull their image from a server that's on a private network), so size *does* matter to me. Having the full development environment simply is not an option.

As others have pointed out, having gcc on your firewall isn't going to provide you with a great deal of security. Just another (and a tiny one, at that) hoop to jump through. If they can root your box, then they can upload a compiler (or, more likely, a precompiled binary).

I use buildroot to compile my system. I have to tweak the make scripts, but I can get openssh/iptables and a bootable system compiled in a gshield which generates a script that I can edit to use as my firewall.rc. (I don't actually use ghield as the firewall, just capture the commands that it would have executed to create the ruleset at runtime)

Best of luck.

uClibc, Dietlibc & Newlib

You might want to notice that Newlib is written and maintained by Redhat.

A libc is not some magical, mystical component of an Operating System. Lots of people have written one; its not that hard, just a lot of work.

"About the only common components you could 99% safely bank on would be Linux, Glibc..." uclibc and dietlibc are two alternatives to using glibc, both of which can be used as part of a Linux based operating system. I will agree that glibc is probably present on greater than 99% of systems using the Linux kernel.

LRP didn't just die. It evolved, or reincarnated. Linux Embedded Appliance Firewall (or LEAF) is the next step. Kernel 2.4 support, several ready distributions for different needs, packaging system, etc..

"LRP is dead" news is more like a bitter cry of an abandoned developer.. If he touts his "next version would've had all these magical abilities", why doesn't he release it? Even a partial implementation would probably attract attention and it could be integrated into other embedded projects.

Linux-on-a-floppy idea is generally just an issue of picking the right components and wrapping it up. I taught a linux-trainee to make an iptables-floppy in one night, just by cut-pasteing parts of a running debian system and compiling a custom kernel.

I'd say that the linux-floppy-culture owns most credit to uClibc and Busybox developers, for making embedded-sized libc and utilities.

I've found slackware tends to be nice to slower hardware. Slack 3.0, for example, is running quite briskly on my 386 now that I upgraded from 3 to 7 Megs of RAM. Plus, I could fit lots of development tools and a minimalist X in 80 megs of HD and 17 megs of swap.

Of course, thanks to glibc, such things are now very tough. But, don't forget, slack used to use BSD libc (which is small and fast!), and guess what still uses it? that's right, *BSD. So if you'll consider more than just linux, don't be afraid to look at NetBSD (which is a little smaller and lighter than FreeBSD.... not sure how OpenBSD compares).

You might also want to test-run Knoppix, since it doesn't even need to be installed (so it can't hurt!).

For window managers, OpenLook VWM, FVWM, Blackbox (probably the best), or mwm. Please don't force them to use twm... they'll never want to look at a computer again!

I agree, with one caveat: efficient code can often be far less elegant than "normal" code. For example, there are plenty of goto statements in the Linux kernel. Using some of the more advanced features of C++ can have an efficiency impact, even if it does result in a simpler, more easily understood architecture.

Kind of forgot about this little issue: endless trade offs. Do you want to spend less time running the program or maintaining it? :-)

Yes, but the libraries can be improved or replaced independently of the applications. I believe there is a tiny libc floating around somewhere, for instance.

You are talking about this, I believe. :-)

Oh, and when I was referring to when I said that libraries can bloat an app, consider a configuration file format in xml. Although it may never need to support anything other than us-ascii, use of an xml parser library would include code for unicode support at the very least, when a custom-written parser would not. Hence the trade-off between a well-understood, mature library, and a new, efficient chunk of code specific to that application. This is the kind of thing that would result in different choices for embedded vs desktop constraints.

*nod* I guess I can honestly admit I would rather see developers use the big XML library when developing for general purpose systems. Primarily because the big library will serve many more applications than a fine-tuned specific one -- as more apps use a library, the total efficiency in the system goes up, even if there is a performance hit on a case-by-case basis. I think this makes my original point moot in a lot of ways. :-)

> What is the weakest specced machine that anyone here is getting productive/useful work with Linux done on?
> Do people use Linux on 468s at 12mhz? P75s? Just curious.

Newer distros assume you have at least some hundred megabytes of disk space, a decent amount of memory and a relatively fast CPU.
To use old hardware efficiently you should look at projects like uClibc or Busybox that are intended for embedded/small devices.

There are many efforts to putting Linux (and other UNIXes) in places with limited amounts of space.

handhelds.org is all about running Linux on ipaqs. Space is a concern, of course, so various things are done. The conversion to Busybox has recently been made, saving almost 2MB of space as I recall.

There's also uClibc. The smallest I've ever seen glibc is about 1.5-2MB. uClibc clocks in at about 200-700kB. That's small. This is used when you just don't have space available, such as on the TuxScreen with only 4MB of bootable flash and on many rescue disks and floppy based Linux systems.

Remember you don't want to cut corners all the time. On your desktop, it's probably best to run the full-blown GNU utilities. They have extra options that, while not commonly used, have obviously proven useful enough times to be included.

However, if you only have 16-64MB to work in, and you want to have lots of other stuff, busybox is a very viable option that I would reccomend if you have trouble fitting stuff in. Don't use it when you've got gigs of hard drive space to play with though.

Cool. This device uses Busybox and uClibc. These are very very cool projects for developing embedded systems. Of course I'm biased (busybox and uClibc maintainer hat on), but I had no idea these folks were building an AP with them. Looks pretty nice. I hope they send me a free one. ;-)

• Client side devices (miniPCI/PC cards, particularly GPRS/802.11 combo cards)
  
• Mesh networking technology
  
• Technology for enabling seamless roaming, by means of cellular and WLAN networks
  
• Additional security features
  
• Integration with innovative antenna technologies
  
• Expansion of the platform beyond the WLAN market

• Processor: Motorola MPC8241 running at 200MHz
  
• RAM: 32MB (default), 64MB, or 128MB of SDRAM
  
• Flash: 8MB (default) or 16MB
  
• 1 x Davicom DM9102AF (tulip-clone) 10/100 Ethernet on RJ45
  
• 1 x miniPCI socket (comes filled with a 802.11b NIC and "AP" software)
  
• miniPCI socket has the pins for V.90 modem and 10/100 Ethernet brought out to a second RJ45
  
• 1 x Smart Card (SIM form-factor)
  
• I2C header
  
• 3.5 x 3.6 in. (smaller than PC/104 form-factor)

• Processor: Motorola MPC8245 running 333MHz
  
• RAM: 1 x SODIMM socket, usable with up to 512MB (off-the-shelf modules)
  
• Flash: up to 32MB
  
• 2 x Davicom DM9102AF (tulip-clone) 10/100 Ethernet on RJ45s
  
• 2 x miniPCI socket
  • first slot comes filled with a 802.11b NIC and "AP" software);
    
  • first miniPCI socket has the pins for V.90 modem and 10/100 Ethernet brought out to a second RJ45
• 1 x full PCI slot (more Ethernet, T1, T3, additional 802.11a/b/g NIC, etc.)
  
• 1 x Smart Card (SIM form-factor)
  
• I2C header
  
• Size: 6.0 x 7.0 in.

• PPCBoot
  
• PowerPC Linux kernel
  
• Busybox
  
• hostap
  
• uClibc (A glibc2 environment is also available)
  
• M.U.S.C.L.E (Movement for the Use of Smart Cards in a Linux Environment)
  
• open1x.org

Another issue, is the poor way that Lineo participated in the open source community. Taking, but not giving back. MontaVista is a better example of an embeded linux company that understands the importance of open source community membership and fiscal responsibility.

I think this is unfair. Lineo were behind Busybox and uClibc, both under GPL. Erik Andersen is the maintainer of these and he was employed by Lineo until being laid off a few months ago.

john

Step one, configure and install the Linux kernel. Step two, configure and install uClibc, step three configure and install BusyBox. Step four, setup the bootloader (depends on architecture). Step five, reboot into a working system...

What I would do is compile a stripped down kernel, use busybox for most system apps, and have your init scripts call the tinyX server and then instead of using a window manager have the startx script start galeon in full screen mode using tabs instead of separate windows for popups. The only difficult part may be getting mozilla or galeon compiled because of the gtk requirements) You could try the Xlib mozilla port perhaps.

For a little bit of info on how I have done a similar project take a look at my linux on a floppy page.