Flutterby™! : Random notes on lightweight Linux/Un*x

Next unread comment / Catchup all unread comments User Account Info | Logout | XML/Pilot/etc versions | Long version (with comments) | Weblog archives | Site Map | | Browse Topics

Random notes on lightweight Linux/Un*x

2010-07-12 13:14:58.32437-07 by Dan Lyke 5 comments

This morning on Twitter, Columbine was whining about having to compile Emacs for a machine, wondering why Linux distributions even bothered with X (let alone those bloated overblown things like KDE and Gnome), and pondering that it was ludicrous to learn vi because it was better to copy the file off, edit it, then copy it back on rather than resort to that bit of antiquity.

(I'm paraphrasing.)

So since I'm actually starting to get some new readers, I figure we'd scare 'em off with an intro to "how to build a lightweight Un*x system". I've done this with Linux on a bunch of different platforms, but I'm gonna try to stay conceptual.

First thing you need is a boot loader. Intel based people have seen "lilo" and "grub", Atmel based systems use U-boot. The point of the boot loader is to locate a kernel and read it into memory, then call the kernel. Sometimes the kernel is stored on disk, sometimes in flash or other read-only memory, sometimes on a network to be accessed via "tftp" or a similar protocol.

Since the boot loader loads the kernel, that'd be the next stage. In my case this has been Linux, but I'm staying high level and the various BSD kernels and what-have-you are similar. So the boot loader gets the kernel into memory, and calls it.

The kernel then initializes whatever hardware's been compiled in to it (those of you looking for fast boot times, this is a reason to use modules: they haven't been loaded yet), and then mounts "the root filesystem" read-only, and executes "/sbin/init" as user "0" (abstractly, the kernel itself knows nothing of user names, just numbers).

If you just want the kernel and the root filesystem read-only, "/sbin/init" can be any application you want it to be. You could, at this point, link it to emacs. Of course that binary needs to only use shared libraries on the root filesystem, but it can be anything.

But usually this is a program that sets up additional filesystems, possibly remounts the root filesystem read-write, sets up network interfaces (this gets tricky if your root filesystem is on a network...), and then offers the user the chance to login.

If you're building a lightweight Un*x like system, I highly recommend BusyBox rather than the full-on GNU POSIX environment. BusyBox is just enough "init" and the standard POSIX environment to be useful, with various options to pare it down or build it up a bit, without the overhead of knowing too much about things like locales and character sets and languages and all of that crap.

And if you're building this environment from scratch for an unfamiliar platform (ie: you're cross-compiling and don't yet have a compiler that can run on a machine you've got and build for the new machine), I also recommend buildroot, a set of tools to download and compile lightweight Linux environments that can range from "give me a boot loader, a kernel, and, optionally, a login prompt" to X and all sorts of additional stuff.

But if you're a geek who likes to play around, I also recommend starting with something like my now 7 year old instructions on building a CompactFlash based embedded Linux install to bring a machine up from scratch, without all those funky package managers and what-have-you. There's a lot of beauty and elegance in the design of the Un*x like kernels and the way the layers get added as the system comes up that's worth stopping and appreciating, if you've the background to do so.

[ related topics: Embedded Devices Shoes Robotics broadband Free Software Embedded Devices - Linux Graphic Design Interactive Drama Hardware Hackery Software Engineering Archival Nature and environment Open Source Invention and Design Law ]

comments in ascending chronological order (reverse):

#Comment Re: made: 2010-07-12 15:26:13.28661-07 by: spc476

I won't claim to be the only person left doing this (but definitely in a very small minority) but I do use X to run programs on one computer and display the windows on another (my girlfriend has OpenOffice installed on her Linux box, I don't; I'm now working with a company that keeps sending me stuff as Word documents, and wants invoices as Excel spreadsheets. It's not worth it to me to install OpenOffice on my system when it's already installed on a machine I have access to). I do not, however, run Gnome or KDE as my window manager—I personally don't need all the bells and whistles for my environment and I use something lightweight (well, compared to Gnome or KDE—when it first came out it was rather heavy).

vi is … well, vi. I hated every minute using it, but stuck with it because at the time, it was that, or destroy my wrists and slow the machine down using emacs. Now, I find I can make editing changes faster with vi than with any other editor, although I still use something other than vi when writing new material (be it text or code).

#Comment Re: made: 2010-07-12 18:56:29.680633-07 by: Dan Lyke

I should add that buildroot also takes care of building the cross-compilation environment. Building the GCC toolchain is... not to mince words... a bitch, and buildroot makes it much easier.

And yeah, I have trouble typing "sudo emacs", my fingers tend towards "sudo vi". I know enough to get around, do basic copy and paste operations, because I have had to do cat > /etc/... before, and vi beats the hell out of that...

#Comment Re: made: 2010-07-13 03:45:58.474224-07 by: meuon

I can use just enough "vi" to be functional, but honestly, moded editors are an archaic pain. Systems often also have nano or pico as well. A system at home runs Notepad++ via Wine just so I can see things as some others do (Nancy is learning HTML and CSS the hard way and doing well). But I'm still using "joe" for just about everything.

Yeah spc476, I still enable SSH X forwarding and run X programs (often over insane distances/delays) via remote. That makes 2.

#Comment Re: made: 2010-07-13 05:04:58.012393-07 by: DaveP

...which brings memories of using rvi. Y'know how vi originally just sat on top of ed? A local guy split vi into two pieces, one of which ran on your local machine, and sent ed commands over the wire to edit a file on another machine. Surprisingly useful back in the days of 300 baud modems...

Nowadays, vim --remote will get you much the same functionality.

#Comment Re: made: 2010-07-14 09:08:04.850577-07 by: other_todd

You might be interested to know that I spent two days of trying to wrangle either packages or source compilations on that machine, finally grinding to a halt on PHP - two different package distributions plain wouldn't work and I couldn't get source to compile after trying fifty things for hours. Drove me to despair and/or gin yesterday evening.

This morning, told my boss the travails, he said, "Let's just go get a Linux box." I said "External hosting okay?" He said, "Knock yourself out. Two days of this is not a productive use of your time." So after lunch I expect to go to my favorite hosting provider, press three buttons on their control panel, and have a working installation of all the things I need.

I love my boss.