Table of Contents:
To the main page.
If you use Windows, you're not usually faced with the question of what window manager or file manager or shell programs you want to use. You typically use what comes with Windows and any customization is basically done on screen colors and default fonts. On the other hand, Linux gives you tons of choices for options like these. Personally, I'm not thrilled with either extreme. I'll go through some options for low resource systems on Linux or FreeBSD (which cuts down choices) and I'll even mention a few extra options for Windows which most Windows users probably have not tried. Picking the right window and file managers on a low resource POSIX system can make a huge difference in responsiveness of the machine.
Linux and BSD have several Desktop options such as Gnome, KDE, Unity, XFCE. By their nature, most Desktop systems are resource intensive. The only one I recommend for a low resource system is LXDE-qt (Lightweight X11 Desktop Environment). If you have any doubts on how your favorite Desktop stacks up against LXDE-qt, then just try them both on a machine with only 64 MB of RAM. You'll see a huge difference. One really nice thing about LXDE-qt is that you can pick and choose just the pieces you want for your system and don't need to install all of LXDE-qt to get the benefits of the programs that are a part of it. It's designed to use Openbox, but many of the lightweight tools will work well in a variety of window managers. I particularly like lxtask. It's similar to the Windows task manager. You can kill applications with it. If you're tired of a dockable app that's running, use this tool to stop the program. It also shows RAM usage. The lxappearance program lets you edit the look and feel of programs. (The original LXDE version worked with GTK+ 2 based programs, but the LXDE-qt versions should work with Qt based programs.) The lxterminal program makes a good replacement for xterm. Even if it's not what you decide to use as your main terminal program, it's a nice backup terminal program to have around just in case settings get messed up with the terminal program you use most often. I did recently hear about a security issue with vte based terminals (which includes lxterminal). However, it's only an issue in certain cases. There are other interesting lightweight programs as well. You can run the LXDE-qt programs you want as needed and leave out the ones you don't need.
The original LXDE project is being replaced by LXDE-Qt. LXDE-qt is a combination of LXDE goals such as small separate components and the RazortQt project. The LXDE project was GTK+ based, but Razor being Qt based requires a switch of LXDE to the Qt toolkit. The new project may be a little less lightweight than the original, but there are several gains from combining the projects and switching to Qt.
The only other lightweight desktop project I've run across is Equinox Desktop Environment (EDE). It's FLTK based.
If you want a small desktop style program to run with Fluxbox (or another window manager), you may want to check out fxdesktop. It makes use of the Fox Toolkit library. I managed to build it on one of my systems with no issues, but to run it, you need to open a terminal in your window manager of choice and type the following:
export "FOX_DESKTOP_WM=fluxbox" fxdesktop
If you're not using fluxbox, substitute your window manager. I don't like much on my screen, but this makes an interesting addition.
Personally, I don't use any of the popular Desktop choices out there. I customize the software I use for the desktop myself. I'll list some of my favorites below.
If you're going to do anything GUI based on Linux or FreeBSD, you'll usually have an X server running. There are X servers for Windows that run natively (like Xming) or with Cygwin, but I don't really know of that many Windows users that bother to run one. I also have the X libraries and server building and compiling natively with MinGW and msys on my own system. Once you have an X server set up, you can pick a window manager for it. I have currently switched to jwm. I'm working on a utility to change some of the options for this window manager including switching looks/themes. If you have a theme you've created for jwm that you'd like to be a part of the theme collection for this utility, please contact me. I'd love to add some more themes to the collection and would be happy to list your name as the author of the theme. The settings/theme must be licensed under some sort of Open Source license for distribution with the utility program.
My first impressions of jwm when seeing it in lightweight distributions wasn't too positive. It looked too much like Windows and I wanted a nice empty screen more like Openbox. However, I decided Openbox was still a bit too heavy for my needs, especially since it requires some of the GTK+ libraries to build. I decided to look for a window manager with less dependencies and after trying quite a few, my search ended with jwm. It's easy to build. The configuration file is in XML, which is something I prefer. There aren't as many settings as there are for window managers like Openbox. However, the settings available can do a lot. Of all the window managers I've tried, it's the easiest to customize. Compared to Fluxbox and Openbox on my older laptop, jwm takes up less memory and resources. It also feels more responsive on older machines.
When I first started searching for a lightweight window manager, the one that seemed to be the most often mentioned was Fluxbox. It comes with a lot of low resource distributions. The more I looked at Fluxbox, the more I liked it. It's highly customizable through files in your home directory under the hidden .fluxbox subdirectory. You can change the menus, add shortcut keys or pass configuration information when calling a program.
I started experimenting with Openbox which is another Blackbox derivative. I really had trouble deciding between Fluxbox and Openbox. Both allow you to set up the menu to call other window managers in order to switch to them. So, you can easily switch back and forth between Fluxbox and Openbox. I find editing Fluxbox configuration files less error-prone than Openbox ones. However, Openbox seems to adhere more to standards including using XML for configuration settings. Openbox lets you switch between applications using the alt-tab key by default, but does not include a panel that lists all the open applications (for clicking to activate). You can use any third party panel software you like with Openbox though. There are two key differences between these window managers for me. Openbox does a better job of drawing the menu on my machine. It works better with mouse and key press combinations and the screen seems to redraw more cleanly after the menu is dismissed. Fluxbox takes less memory on my machine. I've read from some sources that Openbox is more lightweight, but my tests using conky, lxtask and other programs to check RAM in use (on Linux and FreeBSD) show Fluxbox uses about 1 megabyte less on my lowest resource machine. If you need to add a panel program and other custom applications to Openbox, it can take up even more.
Of the other lightweight window managers I've read about and experimented with, another promising option appears to be dwm. It's a tiling Window manager (although it also has floating and monocle modes). You can change the default settings straight in the C code, which is nice for a programmer. There are also several examples of customized versions of dwm available online. One strange thing I've noticed with dwm on FreeBSD happens when I run it with conky. Conky indicates I'm using up a lot of memory. It may be the combination of dwm with conky. I don't see the issue when I use top to display system information instead of conky. Typically, dwm uses less memory than Fluxbox or Openbox.
Windows users shouldn't feel completely left out when it comes to window managers. There are ports of dwm to Windows. One, bug.n, uses autohotkey and works very nicely.
If you want the screen to redraw cleanly using either Openbox or Fluxbox, you need another program to help you out. You can use xsetroot or hsetroot to redraw a color background. Both window managers usually recognize if you have either of these installed. Feh is a popular lightweight program for drawing custom graphics backgrounds on a desktop (main window). Fluxbox supports it and Openbox can be scripted to use it as well in place of xsetroot or hsetroot. I've also noticed some people using nitrogen for background setting/redrawing tasks. Another nice thing about jwm is that you don't need a separate helper program to redraw the screen. It's all built in. However, if you want to use another program to draw your desktop (like xfireworks, feh or hsetroot), you can turn off this option.
If you're going to run Openbox, check out the obconf program to configure colors and other basic settings. LXDE-qt also offers LXAppearance, another configuration program, which includes some integration with obconf for certain builds. Most POSIX distributions offer pre-packaged theme additions for certain window managers. For instance, there's an openbox-themes package that works with Openbox. You can use the themes in conjunction with obconf or LXAppearance. You can create your own Openbox themes from scratch or customize and install themes with the obtheme program. As I mentioned, I'm working on a jwm theme program. There are also some jwm tools that come with Puppy Linux.
Several window managers including Openbox can use the FreeDesktop standards to help generate menus based on programs you've installed. There are also tools to help edit menus in Openbox. Since most of the menu programs for various lightweight managers are interpreted programs, I typically find it easier and less resource intensive just to use a text editor to edit a menu configuration file directly. On Debian, if you install their menu package and make sure the proper entries are added, Openbox's pipe menu system can automatically update a section of the menus under the Debian menu entry when you install packages on your system. In $XDG_CONFIG_DIRS/openbox/menu.xml, make sure there's an entry for:
<menu id="Debian" />
In $XDG_CONFIG_DIRS/openbox/rc.xml, you'll need the following entries and the lines need to be uncommented if there were comment marks disabling the code:
Window managers that let you map keyboard shortcuts can be set to bring up specific applications when you click a shortcut. For instance, I've configured my window manager to bring up a screenshot program to take a snapshot of my desktop when I press PrintScreen. You can use any screenshot program. I happen to like using graphicsmagick at present. It can also be used in conjunction with photocrop so you can specify what portion of your screen to capture. Another nice trick with window managers that support keyboard shortcuts is the ability to toggle hiding and showing of all open applications using a key combination like Window - D.
Since Openbox didn't have its own panel, I was using Tint 2. It also offers support for applications that minimize and appear as tray icons. Realizing I could display tray icons similar to Windows on my POSIX systems, I was left wondering what applications supported this functionality and decided to do a search. One of the first programs I ran across with this capability was volumeicon. It's a substitute for the speaker icon usually found in the tray on Windows. It can let you raise or lower volume or bring up a mixer such as alsamixergui. I've recently found an FLTK based volume icon program. Stardict on Windows has tray support, so it was no surprise to find that similar functionality works on POSIX systems. I also use Sylpheed on Windows and it has tray support. I eventually found vmg (Virtual Magnifying Glass) which puts a magnifying glass icon in one's tray and can be called up to magnify areas of a screen. I'm still looking for a program (with a tray icon) that can provide the same funcitonality as the Windows task manager but do so on Linux. With jwm, I no longer need a separate program and I can turn the panel on or off based on a setting in .jwmrc. It also has a swallow feature that can turn applications into something that can appear in the tray. I'm currently looking into some lighter weight tray options that don't require larger GUI libraries or other compilers (besides C/C++) to build them.
Window managers such as Fluxbox and Openbox have built in support for dockable apps. It's far easier to find dockable apps than it is to find applications with tray support. There's even a dockapps.org web site that collects and catalogs quite a lot of them. Of course, you can run dockable apps on any system, they just don't have tray support with any window manager. I've even run some dockable apps like wmfishtime in Windows.
For Windows users, I found some great utilities for anyone who liked Windows XP and can't quite get used to Vista or Windows 7. Check out the Windows Classic Shell project at Sourceforge. It doesn't attempt to replace your Windows shell. It does offer user friendly tools such as a menu alternative and file manager and browser improvements. I highly recommend it.
I really don't use file managers much. I tend to prefer typing commands to get around or copying files from the command line both on Windows and Linux. There are two places where I find a file manager may come in handy though. When running multimedia files such as music or graphics, I like to be able to navigate to a directory with those files, click on them and have them play or display with a particular program based on their file extensions. I also like to be able to compare two directories and copy files from one to another to get them in sync. A tool like dirmatch (DOS) or wmatch (Windows) works well, but with POSIX systems, I've yet to find a good replacement for these programs. A nice two pane file manager with a copy command may help fill this gap.
Some of the file manager options I've looked at are Worker, Xfe, mc and vifm. Worker takes a while to get the hang of, but is highly customizable. Using the afvs library, you can add the ability to look into compressed files. It doesn't support .tlz format (tar with lzma compression) yet though and I haven't been able to contact the person maintaining the library to check into adding support in some way. Xfe will seem very familiar if you're used to working with Windows Explorer on the Windows platform. It uses the Fox Toolkit libraries, so you'll need that installed if you want Xfe working. I had trouble compiling some of the later versions, but .99 built. Some Linux repositories do have later versions working though. I've tried the package with Debian Squeeze and the version they distribute just doesn't let you move the program around properly. Xfe will let you customize your view so you can have two panes or a directory tree and a listing of your files. Fox Toolkit also comes with a cross platform file manager called PathFinder. Midnight Commander (mc) works on Linux, plus there's a port to Windows. There's even been a patch to view .tlz files made for it. A similar alternative, vifm, may not have all the features of mc, but it does scroll easier when trying to compare two directories in two different panes. It also attempts to make key commands work similar to commands in vi. When it comes to alternatives that would run using the GTK+ 2 GUI libraries, I found more than one that could handle a two pane display, including emelfm2 and Gentoo (not to be confused with the Linux operating system also by that name) which is very similar to Worker. The emelfm2 program is supposed to be highly customizable. I wasn't too thrilled with it when I first looked at it, but the more I experiment with it the more I like it. It's useful for launching applications to play or display a directory of files based on their file extensions.
Another interesting option adds functionality to the shell program rather than creating a separate file manager. The scrolling of the two panes works much better than the file managers I've tried and it's highly customizable, but doesn't appear easy to set up. If you're curious check out bash_commander which is an extension to the standard bash shell. It certainly looks promising.
If you prefer to see and click on icons to launch applications, I'm finding gpe-appmgr a nice alternative to the Windows file system for that particular purpose. There are some other programs that display icons and launch applications including one that's a part of LXDE. However, gpe-appmgr is the most polished solution I've tried to date.
I've yet to find a file manager that does everything I want. If you have other suggestions that can handle the two types of tasks I need, they would also be appreciated. I have been looking into using a menu, like dmenu or 9menu in combination with a script to display all files of a certain type in a directory and launch applications related to them. Openbox also supports scriptable menus and provides another option. I'm still searching for a good, cross platform compatible menu tool. I can also get a decent directory difference listing using scripts and diffh with some other tools (on Windows or Linux). However, that only shows directory differences. It doesn't allow for easy copying of files from one directory to the next. One would still need to go back to the file manager, a menu program scripted to copy files or use the command line copy and/or move commands to put two directories in sync after finding the differences between them. I also noticed, it's hard to view the output on diffh without a decent browser. So far, Opera is the most lightweight browser I've found that does a good job of displaying the output. DPlus may be a decent lighter option as well. Firefox and IE also work fine, but take more resources. I've yet to check chromium and uzbl on some systems, but they could offer some more possibilities. Another option for a low resource system might be to use a decent HTML to Postscript converter and view the differences with ghostscript instead of a browser.
DeLi came with rxvt, mxrvt (similar to aterm or rxvt but multi-tabbed) and xterm. I checked a web site that compared terminal programs and the ones it most recommended for low memory machines were rxvt, wterm and eterm. It also mentioned that xterm can be among the slowest terminal programs. I started using the rxvt program after that. You can customize the look of it further via the command line and through settings in certain files. When I read that some terminal programs let you run multiple instances and share resources, I thought that would be just the thing for a low resource machine. Some of the terminal programs that fit in that category are sakura (which might also have some extra support for cut and paste), lxterminal and rxvt-unicode. As I mentioned before, I recently read about a security bug with vte based terminals. This would affect programs like sakura and lxterminal. Upon reading further, rxvt-unicode was purported to use the least as far as libraries to get it up and running. The rxvt-unicode terminal program does not use vte. One can choose between dependencies such as cairo or libafterimage for screen related functions. My latest terminal program of choice is now rxvt-unicode. Run urxvtd -q -f -o once and then any time you need a terminal, run urxvtc. You can use very similar command line settings for rxvt and urxvtc to customize the look and feel. I added options to my menus to call urxvtc with customized command line parameters. That lets me set up colors, scroll bar appearance and text buffering size however I prefer. You can further customize functionality of rxvt-unicode using Perl scripts. I use a Perl script to add customized cut and paste functionality through xclip (or xsel). If autocutsel is running in the background, it automatically synchronizes cut buffers (used by the terminal program) with the clipboard. Am hoping to further customize the script to create keyboard shortcuts for cut and paste those of us who prefer the keyboard to the mouse.
While Windows users don't usually have to worry about working with terminal programs, it's useful for people who like to work with a keyboard to have a good command line interface. If you'd like some options to the standard Windows command prompt, check out msys available from the mingw compiler project at Sourceforge and Powershell available from the Microsoft web site. You can even run DOS commands in Dosbox (both on Windows and Linux) if you prefer working in DOS. Djgpp has a DOS version of Bash available too. If you want Bash for Windows without msys, check out winbash. It's an older version of Bash than the DOS version, but it still has the basic functionality of Bash. There are a couple of versions of winbash around, but I found one that would build with MinGW. If you really want a terminal program for Windows, check out Console 2, ConsoleZ, ConEmu
I ran across a nice command line menu tool at the same site where you'll find dwm. It's called dmenu. It took me a while to figure out how to use it, but you can check the script files that come with it for some good examples that can give you a jump start. It looks like a good alternative to the Fluxbox or Openbox menu system. It integrates very well with dwm (which it was designed for) and could be useful with any lightweight window managers that don't offer a comfortable, built-in menu system solution. I was even able to create a menu with dmenu that called other dmenu listings displaying application names for each category of programs I wanted to run. If you like using a command line over a mouse, this a good option. I tried several other menu programs, but the only other one that looked promising to me was 9menu which was part of the Plan9 project. Some of the other projects for Plan9 could certainly be worth checking out as well. Both dmenu and 9menu need X Windows to function. Another option might be ratmenu. For a console mode menu that would work outside of X Windows, I've been using lynxui with some appropriate shell scripts. The bonus is that the same menus will work within X Windows with dplusui as well.
One thing terminal programs don't seem to handle well is cut and paste especially between themselves and other types of applications. It's difficult to move information between a terminal program, such as urxvt, and any other program, such as my favorite text editor SciTE. When I started experimenting with this, I had hoped to set the Fluxbox keymapping to call some buffer program on Control-C and Control-V keys, but that didn't work out too well. I did finally find a solution, not the one I wanted, but a workable one. Ran across mention that Puppy Linux had solved the buffer issue between applications (edit menu and mouse highlighting) and terminals (mouse highlighting) using a program called autocutsel. I tried several buffer clipping programs, but autocutsel really does want I need. It synchronizes the cut buffers (used by most terminal programs) with the clipboard. You can call it to from your init file before starting Fluxbox or Openbox and let it run in the background. I also found the program xclipboard very handy to use along with autocutsel for cutting and pasting. I had some Perl scripts working with urxvt to add support for cutting and pasting via mouse. When I updated my version of urxvt during a system update, it stopped using them. At one point, I was considering writing Perl scripts to add keyboard support for standard CUA compliant cut/copy/paste options. It's possible but would require a lot more coding than simple using the mouse. I'm currently looking into some other interesting options that might involve more framebuffer applications.
At one point, I tried a live CD with Tinyme (a Unity based distro) on one of my machines. It had a version of drakconf, the Mandrake Control Center. I really liked this option. A graphical control center is just the thing someone switching from Windows could use, especially when trying to trouble-shoot how much hardware isn't working with Linux. Drakconf uses Perl scripts with some C routines and I considered converting it to run on other versions of Linux and possibly FreeBSD. I found out AntiX had a control center as well, but used shell scripts, gtkdialog and some programs from its repositories to implement it. Rather than porting one of these options, I decided the easiest way to get the equivalent of a control center working on various distributions quickly was to choose various readily available applications that already did pieces of the job. These programs could be combined either through a standard menu system (like the jwm, Fluxbox or Openbox menus or dmenu or 9menu or ratmenu) or using some scripts and a ui program. So, that just left choosing which programs to include as part of my computer's control center.
I really want to mention flsynclient. I often use a touchpad in place of a mouse for ergonomic reasons. flsynclient is a FLTK front-end to a configuration tool for touchpads that use synaptics drivers. It's really nicely done. It looks a lot like a configuration tool you might find on Windows. I have it working currently on my FreeBSD machine.
For hardware information, there are several options. I like the program hardinfo. It gives a nice overview of what hardware your operating system thinks is connected. For Windows users, it's similar to the Device Manager, devmgmt.msc. Some other options to show hardware information are xosview and x86info which also have versions for FreeBSD and saidar, xsysinfo and sysstat. I'm currently looking into options that make use of lighter GUI toolkits.
I was having some difficulties assigning user groups from the command line. So, I looked for some tools to handle user and group management. The only tool I could find in the user management category was usermode. It helps you change your password, default shell, etc. Looks like it was initially created for Fedora, but it works on other Linux distributions too. I did eventually run across a Python script that uses GTK+ 2 mentioned at an Arch Linux forum. It's called luser.py. It provides a nice graphical interface for adding and removing users from groups. I intend to keep looking for lightweight solutions and would prefer to find something that doesn't require an interpreter just to run.
For screen resolution, there are programs like xrandr, lxrandr (from LXDE), grandr and wmressel. For Internet connection status with modems, there's pppstatus. For disk usage on POSIX systems, there's xdiskusage, ncdu and du. If you're using Windows, take a look at WinDirStat. There's even a portable version. I have a working port of xdiskusage for Windows now too. For ejecting DVDs and CDs on POSIX systems, there's eject.
One can change the look and feel of their system on at least two levels on POSIX systems, on the window manager level and on the program (GUI library level). As mentioned, I'm working on a window manager theme changer for jwm and Puppy Linux already has one. LXDE offers LXAppearance which you can use to switch themes, icons and fonts. Not sure if it will be ported from GTK to Qt, but some type of alternative is in the works for the LXDE-Qt project. If Openbox is your window manager, you can use obconf to do general customization. The LXDE project has ported it from GTK+ 2 (which is being phased out) to Qt. Obtheme is a Python and GTK+ 2 based application that lets you edit or create your own Openbox themes and highly customize the look and feel of Openbox. GUI libraries such as GTK+ 2 and Qt have configuration programs that also let you customize themes and the look and feel of software built with those libraries. Both switch2 (gtk-theme-switch 2) and gtkchtheme let you change theme preferences for GTK+ 2 on POSIX machines. Don't know how many of these will be ported to GTK+ 3, but it's likely some will if they're not completely replaced by something new. Qtconfig lets you configure QT based applications. FLTK also has some options to switch looks using an environment variable or a flag at the command line. FLTK 1.3.2 comes with two themes built in, plastic and gtk+. I've built my FLTK libraries with patches that add too additional themes created by other developers. These are oxy and gleam. They both offer some nice visual effects. Beyond what's built in to the libraries, there's no further theme support in FLTK 1.3.x unless you add other libraries like the EDE or SPTK libraries. Even with limited theme support some FLTK applications hard-code their look and you won't see a noticeable difference when you switch themes.
I didn't find much in the way of low resource tools for the printer. Distributions like AntiX and Crunchbang make use of system-config-printer a Python script using GTK+ 2 to configure CUPS for printing. Calling system-config-printer-applet --no-tray-icon shows the printer queue. Calling system-config-printer-applet --my-default-printer shows the default printer settings. It's a little more resource intensive than what I wanted and needs a few Gnome dependencies. Another Python and GTK+ 2 program is foomatic-gui which also has several Gnome dependencies. There's xpp, the X Printing Panel, which controls printing options for CUPS. It uses FLTK. Another solution for controlling printing options to CUPS is GtkLP which uses GTK+ 2. It includes a nice printing queue feature. Also, if you're running CUPS, you can access CUPS related information by bringing up http://localhost:631/admin in a browser. Most of these work on BSD as well as Linux systems.
There are several font related programs, but most don't look useful for low resource systems. The Font-Manager program at the Google Code site is what I usually see recommended as the best lightweight solution. I've recently found some more lightweight alternatives that don't require GTK+ or Qt. Puppy Linux offers some solutions such as pfont2, pfontview. They're typically script based solutions with a gtkdialog front end. However, pfontview uses an SDL application called sfontview which is enough to give a basic font preview (even if fonts aren't installed yet). I also ran across another SDL based font preview solution called sdl_unifont. I think with these one could come up with a lightweight font manager that didn't require more heavyweight GUI libraries.
One other piece I wanted was a runlevel manager, so I could turn off system applications that I wasn't using and speed up system response time. If the system is designed simply and elegantly enough, you can edit the information in a file by hand with a text editor. However, some Linux distributions, such as those implementing System V type mechanisms, complicate things too much to do this easily. Two good runlevel managers for systems such as Debian that use sysv-rc for their runlevel change mechanism are bum and sysv-rc-conf. Bum uses Perl and GTK+ 2. Sysv-rc-conf uses Perl and Curses, so it runs in console mode. The file-rc system is an alternative boot mechanism for distributions like Debian. One can use rcconf, built using Perl and whiptail or dialog, with it or can edit a single file, /etc/runlevel.conf, in a standard text editor. Windows users have a similar tool to control what applications are running with the System Configuration Utility which can be run from a command prompt by specifying the path and name of the utility,
msconfig or by typing and entering:
If you're a Windows user, you usually don't notice any issues with plug-and-play devices. Worst case scenario, the system can't find a driver and you need to run a search for one. With POSIX systems, being able to hotswap peripherals is a more recent innovation which is still being worked into the operating system. There are three places I've most noticed hotswapping infiltrating Linux systems, with X Windows, with ALSA (the Advanced Linux Sound Architecture) and with mounting drives.
X Windows now handles removable keyboards and mice. With older machines, I found that hotswapping might not work too well and could actually interfere with finding built-in keyboards or touchpads. To turn off hotswapping of devices such as keyboards or mice, I had to add the following to the ServerFlags section of xorg.conf:
Option "AllowEmptyInput" "false" Option "AutoAddDevices" "false"
Some newer audio cards can be connected to machines by USB or sometimes Firewire. There's work being done to handle some of this hardware by projects like FFADO. ALSA has incorporated support for certain removable audio devices. When I attempted to setup my audio device on a Debian system, I had trouble installing and setting up ALSA properly. I searched the web and looked through several documents on ALSA setup, but, unfortunately, many were contradictory or out of date. Unable to figure out which information was still pertinent, I asked on a Debian forum and even asked my local Linux users group. No one seemed knowledgeable about the internals of ALSA and how to properly set it up. Giving up on finding any help or up-to-date documentation, I went to the source and started reading the actual source code in the ALSA packages. I should have done that in the first place. I found out any references to modprobe or modprobe.conf on Debian are dated. ALSA uses udev to set up sound devices. I also found out the hard way that if I installed ALSA before installing udev (which I did), I only got a partial install. I had to install udev and then reinstall ALSA to get sound working.
Many file managers now not only use udev, they also use various libraries on top of it such as HAL or DeviceKit. All these libraries often slow older, low resource systems to a crawl. The old way of working with hard drives was to use the mount and umount commands or to add the devices to /etc/fstab. This becomes problematic when you have several hot swappable devices. You need to know what device a drive is mapped to before you can mount it. You could set up a USB drive to always mount to a certain location in /etc/fstab and mount it when you install the drive. However, what if you need to mount two USB drives or what if one USB drive has multiple partitions. It becomes even more complicated if your hard drives are hot swappable. You can't always assume your USB drive will be ordered just after your hard drive in sequencing if you may have one hard drive one time you boot and two installed the next.
You may think you're running a lightweight system if you personally just use /etc/fstab on your machine, but if the rest of the software installed on your system (such as your file manager) has dependencies on udev or similar related libraries, you've probably slowed down your machine performance more than you realize. The most lightweight option so far if you need hotswap functionality for drives is just using something like udev by itself with no other related libraries. I should mention at this point that there's a Gentoo project called eudev which forks udev. While I can't find eudev in the Debian libraries yet, I've seen it mentioned more than once on the Linux from Scratch list. There's also a repository with a build a Devuan build. One goal of the eudev fork is better compatibility with startup systems other than systemd. Eudev certainly looks like an option worth further exploration if you need hotswapping on your system. With udev (or eudev) you can set up rules to tell it how to recognize your various drives or other USB devices (such as cameras, card readers) and how to mount them automatically. It takes a while to learn the syntax. However, once you do, you can set up rules for any of your hotswappable devices that are supported in Linux. You can use a simple file manager like xfe or emelfm2 or any file manager with no built-in capabilities to mount hotswapped devices if you want to keep your system lightweight. (Some file managers can be built with or without the support. Check the dependencies for the particular build you're using.)
So, then how do you mount the devices easily? If you don't want to learn the syntax and set up your own rules for udev, there are some other options such as various automounter utilities.
For Linux, there's usbmount. It automounts USB drives using udev. I did read that the package was no longer maintained, but it worked fine on Debian Squeeze and Wheezy. With FreeBSD, I use am-utils (Berkeley automounter). This is available on Linux as well. I've also read about autofs. Both am-utils and autofs have the useful feature that they automatically unmount devices if you don't use them for a while. The Arch Linux wiki has a few suggestions for tools with fewer dependencies than those that require HAL including one called uam. It also has examples of integration with a window manager. If you check out the yad (Yet Another Dialog) wiki, you'll see examples of using yad to create a GUI interface for udev for mounting and unmounting flash drives. I'd be very interested to hear from others who are trying to lower resource usage if they've found better options or which of the tools I mentioned worked best for them.
I've been investigating the basics needed to build a Linux machine from scratch. There are quite a few options available including some lightweight ones. I thought it might be worthwhile to look into the various options further and see which were really best for me rather than just following the assumptions someone else made when building a particular distribution. I was pleasantly surprised to find that Debian allows you to change out many of these options and try other solutions. Many other distributions (especially if they're not source based ones) typically make the choices for you.
Starting with the bootloader, there are several options. Some of them include lilo, grub, grub2, syslinux. Slackware uses Lilo. Bedrock Linux uses syslinux. Debian typically uses grub2 out of the box. While grub lets you edit text files for setup, grub2 requires an extra step. Grub2 supports more drives than Lilo and I've found Lilo isn't sufficient to boot the drives on my desktop. So for now, I'm personally happy with using grub 2.
The start up program is the first process initiated, the ancestor of all processes and is typically a daemon that starts up other processes. Init is one of the more commonly known startup programs. However, many distributions are now using or offer systemd which can start services asynchronously. Systems like BSD or Slackware typically use less complicated start up systems and scripts. Older versions of Debian used sysvinit. One of the advantages of sysvinit and one reason that Debian previously used it is that it works well on with a variety of architectures and kernels, so it's rather portable. Debian, by default, now uses systemd (although that could change again). Systemd is not very portable and I've read that it doesn't work with Debian's kFreeBSD kernel (although that may change as well). Devuan is a fork of Debian that attempts to avoid systemd and offer other alternatives. There are several more lightweight startup systems. The one I see mentioned most when the topic of efficiency comes up is runit. There are several other programs/systems that work with it such as svlogd, socklog and ignite. It may not necessarily be easy to install if your distribution doesn't come with it. It can take some setup and some getting used to. Busybox even has a basic init system as a part of it. Since sysvinit comes out the box with Debian, I'm currently using it. However, as mentioned above in the runlevel manager discussion I do like file-rc. It stores information on what process to start in /etc/runlevel.conf which can be edited in a standard text editor. One possible drawback is that not a lot of people are using it and there's no telling how long it will continue to be actively maintained. However, it is currently available in the Debian repository and it's fairly easy to switch between it and another init system.
Let's talk about the main utilities needed to get around at the command line and to build applications from source. These are sometimes referred to as the userland. Most Linux systems use the standard GNU utilities such as coreutils. One thing I don't particularly like about the GNU utilities is that it's very easy to overwrite files when you specify certain types of copy and move commands. Other utilities like Busybox or those one would typically find as part of Windows are more cautious and warn/prompt the user before overwriting. I've also been looking at the source code for some of the GNU utilties and find some parts unnecessarily bloated and complicated. Their support for other platforms (even when someone's willing to supply patches to get things working) hasn't exactly been stellar in my experience. I also prefer more lenient licensing such as MIT or BSD instead of GNU. So, the GNU solution is not my first choice at this point. I began looking for alternatives. One of the first alternatives I ran across was sbase. Reading the rationale behind it, I found it very closely matched what I wanted from my core utilities. When I was reading the Toybox web site, I remember coming across a comment about how starting with standards (such as POSIX) is important, but it didn't do much good if the system wasn't useable. My own goal is not necessarily POSIX compliance, but enough compatible tools that I'm able to build the software I need from source code. By these standards sbase is just too basic. There are several other options to GNU utilities including Busybox, Toybox, Heirloom, Obase, Embutils, Beastiebox, etc. As a cross-platform programmer, I'd prefer a cross-platform solution that doesn't lock me into a particular operating system. Many (although not all) of the projects mentioned are hostile to cross-platform development and porting. Busybox does has a Win32 (MinGW) port, but it's a fork and not part of the official Busybox distribution. Of the various solutions mentioned, Busybox is currently the most complete. I'm currently using it on one of my computers to completely replace the GNU tools and it's more than sufficient for the task.
I would personally prefer a more portable solution that doesn't lock me into a POSIX based operating system. I'm currently working on sysbase alpha. I originally intended to use sbase as its starting point, but am finding it more practical to base it on a mix of early Minix utilities (also used by ELKS) and BSD utilities as well as some original code and the POSIX guidelines for minimal guidance. I don't have a complete replacement yet, but what I do have works well plus it works on Linux, BSD, Windows and DOS. It also fills in some needed gaps. For instance, I've tried various patch programs, but most seem to have issues with carriage return/linefeed combinations. If one is porting code from other systems, it would be nice not to have to worry whether the source and the diff tool were consistent with using just linefeeds instead of carriage returns or a combination of the two. If I use the standard msys find with MinGW and I customize /etc/fstab the way I want it, the msys find fails. Native windows based versions of find or my version work perfectly well.
I've asked on a few project lists if anyone other than me was interested in a GNU alternative to common utilites. Was surprised by the amount of hostility that came up when I asked that question. I am glad that projects like Busybox have still managed to flourish considering the reactions I've read about to the idea of an alternative to GNU tools. Also, the BSD systems appear to be working hard to come up with utilities that do not use GNU licensing. I've attempted to contact a few of their projects to see if they'd be interested in sharing code, but never got a response back. At this point, I really don't need any outside help on project development and coding. I pretty much know what I want in the system and what I don't. However, it would have been nice to share the results with others. Since the responses I've met so far have been so negative, I see no point in making the source code publicly available. Should there be more positive interest in the future, I might revisit that decision. I would certainly welcome hearing from others who are actively looking for more portable alternatives if anyone's out there.
I've been doing quite a bit of searching for alternative build systems and build utilites in conjunction with my LM Bld project. My main requirement with any build tools I use is not to need a lot of dependencies just to get it to work. It would be preferable not to need one or more interpreted languages or a large chain of programs just to be able to build from source. If I'm building C or C++ applications, why is it necessary to install other languages like Perl, Python, Ruby, m4, just to get it to build? All I really should need is a C/C++ compiler. There are several build alternaties out there, but a much smaller amount are popular (typically with very specific groups of developers). Just as there are two large GUI toolkits, there are two main build systems (which incidentally are typically used by these toolkits), GNU autotools and cmake. I am not partial to either of these solutions.
Qt comes with qmake but, for more complicated builds, most Qt developers use cmake. I can get qmake to build from source, but I've had very mixed luck with cmake. I've only recently been able to get the latest version to build. The version before that failed. You can't bootstrap a build of cmake like you can with make. My main issue with both cmake and qmake is that they have a tendency to hard code paths (such as paths to includes, libraries, etc.). I happen to prefer portable apps (as in useable via flash drive or easy to move to other directories). Qmake and cmake just aren't very portable. Also, if I don't build cmake from source, the paths where it's looking for my default includes and libraries are all wrong. Even building from source, I had to patch some of it to get it to look in the right locations. Otherwise, it typically fails at finding libraries like OpenSSL. It still finds libraries in the wrong locations quite often though.
Gnu autotools seems overly complicated. They started with the GNU make program which is okay. However, they added a configure program before the make. The basic idea was to configure a header file with defines that reflected what worked or didn't work on the build system. It's a good idea in theory, but the reality is less spectacular. The concept is theoretically supposed to allow programs to build on any platform. I can't begin to count how many times the configure failed or a program using this system didn't compile. The reality is the configure script is only as good as the developer makes it. If he/she didn't design it to work with options needed on a particular system, it won't work. So, one could create a program that works on systems that may or may not have a fork command. However, the program needs to be coded to provide an option for the fork command and the configure script needs to do something useful with the knowledge that fork is or is not supported on a particular platform. The configure script is a bash script, so bash is required. Another shell such as ash is typically not sufficient for configure to work (especially since it may make use of function calls). The makefiles and even the configure script are autogenerated which should theoretically make it easier to build them. However, I really don't see any added ease of use. One does need autoconf and automake to do so. For those utilities to work, one needs the m4 and Perl interpreters. Then there are more utilities such as libtool which is supposed to help figure out how to link programs on a variety of platforms. Like qmake and cmake, it hardcodes paths of libraries. It also isn't smart enough to handle statically built libraries. There are several alternatives to libtool out there such as jlibtool. However, I've found libtool or an alternative unnecessary.
One can build applications simply by using make and if any system specific defines are needed one can set them up by hand in an include file. One Open Source program I built from source that used this method ended up needing several dozen versions of the include file (one for each platform it supported). One could probably save some file space and maintenance effort by taking a middle ground and prebuilding parts of the include file and auto-generating parts of it if necessary. Make is one of the most popular build tools. However, there are dozens of variants of make. Most were based on an original program but have been modified so much that they can not handle the same syntax as other make variants. As I mentioned, there's GNU make. BSD operating systems have their own version of make that's integral to their ports system. They have a multithreaded make sometimes known as pmake. Some projects like Perl and LibreOffice use dmake. There's even a port of make written in Perl. If one doesn't like the concept behind make and its various forks there are even more alternatives such as jam. However, they're typically not as widely used by most projects. At the moment, I'm using GNU make. It's been ported to a wide number of platforms including DOS. I did have some issues with syntax, but I've managed to find work-arounds to accomplish what I wanted to do. I'm using it with a preprocessor (gpp which offers more functionality than the standard C preprocessor) to handle many of the cross-platform portability issues. Using gpp and make, I can simplify the complexity of building and linking static and dynamic libraries. For instance, with the appropriate commands, I can build dlls on Windows without needing to indicate in the source that a particular function is to be used in a dll rather than a static library. I'm not thrilled with using GNU make. My experience with their support was very negative. They only seem willing to support specific platforms of interest even if patches to fix problems on other platforms are supplied. However, I've yet to find a better alternative. Using gpp and template files to generate a makefile, I can replace the entire build system of a program (whether it originally uses GNU autotools, cmake or some other complicated solution). I've done that with several programs that simply would not build out of the box on a particular platform. However, my original goal was not to have to completely recreate the build system for each piece of software I wanted to compile. I'd be curious to know how various alternative build systems that are used to build several pieces of software from source (such as BSD ports) deal with the issue and whether they use the build tools that are expected by the software or whether they create their own scripts and use their own tools. Most build scripts appear to just run the tools specified by the software.
With GNU autotools and some other build tools, system specific defines are placed in a header file such as config.h. I recently found a library that can be used to replace tools that auto-generate a header file. It's called cDetect. I have to experiment with it more, but it could be useful for complicated builds that require a lot of different defines with values that vary across operating systems.
I've found I don't need utilities like libtool and some of the configure logic is also unnecessary if one uses pkg-config. The pkg-config utility is part of the Free Desktop specification. Rather than each piece of software providing its own scripts to query about version, include and library paths, they can provide a pc file in a specific format and use pkg-config to do the inquiry. It can also provide information about dependencies (such as their include and library paths and if they require dependency libraries). The standard pkg-config tool most systems use is the GNU version. It is a nuisance to build from source and has a circular dependency with glib (part of the GTK+ libraries). I prefer pkgconf. It's a drop in replacement for pkg-config with more lenient licensing and no circular dependencies.
If you'd like to contact me with any suggestions for applications or settings or any updates to information on this page or my other Open Source related pages or any other tips on working with Open Source, I'd be interested in hearing from you. If you have questions of your own and are using Linux or a BSD system, I do recommend you check any forums there may be for the distribution you're running. Also, check your favorite search engines if you need more help. Please do share any suggestions for light or useful applications if you have any. I'll be updating these pages to share with interested readers as I learn more information.
To the main page.