BusyBox: A Swiss Army Knife for Linux
BusyBox is most useful on a system without a set of regular Linux utility programs, but you'll probably be exploring it on a standard Linux system. Because of this, you should use the PREFIX variable when installing BusyBox. The installation process creates symbolic links for all the utilities that BusyBox supports. This allows you to enter ls instead of busybox ls. Suppose you had begun working with BusyBox in the /tmp directory (such that a directory called /tmp/busybox-0.45 was created by the tar command). Then, if you want to create symbolic links in the same area, use this command:
make PREFIX=/tmp/busybox-0.45 install
The /tmp/busybox-0.45 directory will then contain subdirectories named bin, sbin and usr, each with symbolic links to /bin/busybox. You'll also need to copy the busybox binary to /bin before using these symbolic links:
cp /tmp/busybox-0.45/busybox /binNow you're ready to explore the symbolic links in your BusyBox subdirectories. For example, change to the bin directory:
cd /tmp/busybox-0.45/binThen use the ls symbolic link with the --help option:
./ls --helpYou see the same help text as indicated previously. This shows you that BusyBox is being used instead of the standard ls command on your Linux system.
BusyBox uses the GNU C library, or glibc, which can add substantially to the space requirements of an embedded system or boot disk. You might consider looking at alternate C libraries to save space. Examples include minix libc and newlibc. Another example that looks promising but doesn't yet support the full functionality of BusyBox is the uC-libc project from Rt-Control (see http://www.uclinux.org/). The maintainer of BusyBox, Erik Andersen, is currently working to enhance this mini C library so that it can be used to reduce the total size requirements for BusyBox.
The description of BusyBox so far is straightforward, but doesn't capture all that the program offers. Returning to the source code you un-tarred when you compiled BusyBox, load the file busybox.def.h into a text editor:
cd /tmp/busybox-0.45 vi busybox.def.h
The first part of this file (about the first 100 lines) contains #define statements for each utility capability that will be included in BusyBox. If you don't want to include the capabilities of one of these utilities, simply comment out that line. For example, if you don't need sed in the system you are using BusyBox on, comment out the line for sed using two forward slashes, like this:
//#define BB_SEDCommenting out a few of the larger utilities greatly reduces the size of the final busybox binary. For example, removing five complex programs (init, tar, sfdisk, gzip and gunzip) reduces the size of the busybox binary from 260KB to 155KB.
The second part of the busybox.def.h file (after a few explanatory comments) contains #define statements that activate or disable various features of BusyBox. Some of these features are intended to save memory, such as eliminating the use of the /proc file system, reducing the amount of on-line help provided and eliminating the use of regular expressions. Other #defines are specific to features of a single command. For example, you can eliminate the ability to create new tar files with the tar features of BusyBox. Unless you really need to shave off a couple more KB in the size of BusyBox, you shouldn't need to alter the #define options in the second section of the busybox.def.h file.
Embedded versions of Linux such as Lineo's Embedix may be the most obvious use of BusyBox, but you might come up with many other uses. For example, if you need to create an initrd file to boot up a system with unusual hardware, you can use BusyBox functionality to add the basic system utilities with a single easy-to-manage binary. Or, you might use BusyBox as part of a boot diskette or single-disk version of Linux, as the Linux Router Project and the Debian boot floppies.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide