One thing is for certain: Unix is complicated. Linux does it one way, Solaris another, and all the BSDs, yet another. Fortunately there is some logic behind the differences. Some have to do with where the OS came from, and some were design choices, intended to improve usability. In this article we'll talk about a few major differences between the Unix variants, and tell you what you need to know about various differences in command-line utilities.
First, recall that Unix started off in research labs, where two main flavors arose: System V (SysV), and BSD. SysV (five, not "vee") spawned from AT&T Unix's fourth version, SVR4. BSD, from Berkeley, is the competing Unix variant. They both derived from the same Unix from Bell labs, but quickly diverged. Despite POSIX efforts, there are still BSD and SysV systems today, and their functionality still diverges.
Most operating systems are pretty clearly associated with one or the other, and generalized comparisons between BSD vs. SysV usually prove correct.
FreeBSD is the most prominent branch from traditional BSD, followed by NetBSD and OpenBSD. Mac OS X descends from another BSD variant, NEXTSTEP, and remains very BSD-like while borrowing heavily from the FreeBSD userspace. On the SysV side of the house, AIX, IRIX and HP-UX were the main variants. In short: commercial entities focused on SysV, academics focused on BSD.
Linux, however, is an oddball. Linux certainly adopted many SysV methodologies, but these days it is also very BSD-like. Sun's Solaris is also confusing. SunOS started off as BSD, but SunOS 4 was the last BSD version. SunOS 5.x (aka Solaris) is now SysV. The details are much crazier than I've alluded to here, and we probably don't want yet another Unix history lesson. A fun place to start for further reading is the Wikipedia page on Unix Wars.
It has been said that one can tell which system one is using based on two indicators: whether or not the system boots with inittab, and the format of the accounting file. Process accounting isn't really used any longer, and most people don't even know what it's for, so that's mostly moot. The boot system, however, is still critical to understand.
SysV booting means you use inittab. The init program, when run by the kernel, will check /etc/inittab for the initdefault entry, and then boots to the runlevel defined there. Entering a runlevel means that each startup script in the directory will be run in order. Sequentially, and slowly. Sun was so annoyed with this it implemented a mechanism to fire up services in parallel, among other things, with the Service Management Facility (SMF). Ubuntu Linux implemented Upstart, which basically works around the sequential nature of init scripts too.
BSD booting means that init simply runs /etc/rc, and that's all. Well, it used to. Soon BSD systems implemented rc.local, so that software and sysadmins alike could implement changes without fear of harming the critical system startup routines. Then /etc/rc.d/ was implemented, so that each script could live separately, just like SysV init scripts. Traditionally, BSD-style scripts didn't take arguments, because there are no runlevels, and they only run once: on startup. There are still no runlevels in BSD, but the startup scripts generally take "start" and "stop" arguments, to allow sysadmins and package management tools to restart services easily.
The most frustrating and quickest to surface differences between SysV and BSD are in the traditional utilities. Some common commands take very different arguments and even have some very different functionality. This isn't so important if you're in Linux now, as it generally supports both, but once you find yourself in BSD-land, you're up for some confusion.
The first command people usually run into is 'ps.' The arguments differ:
- SysV: ps -elf
- BSD: ps aux
Linux supports both, BSD does not. Often we may want to list all processes owned by a particular user. In BSD, you must run, "ps aux |grep username" but in SysV you can run, "ps -u username." Just plain 'ps' will list your own processes in both flavors.
Another commonly noticed difference is with the 'du' command. Not because some older systems don't support the -h argument to provide human-readable output, but because they display different things.
- SysV: shows the amount available in 512-byte blocks
- BSD: nice output showing size in bytes and percentage used
Printing in BSD is confusing for SysV users, and vice-versa. It isn't as common, since newer OSes support both, but it's noteworthy nonetheless. BSD systems traditionally used lpr, lpq, and lprm to administer print jobs, whereas SysV had lp, lpstat, and cancel. Most systems adopted the BSD style, since lpr-ng (next generation) provided these commands, and CUPS subsequently adopted the BSD variants.
Other programs, such as du, who, ln, tr and more will have slight differences between SysV and BSD. Heck, the differences between the various Unix standards are confusing enough that a single Unix variant may have multiple directories of utilities. Take a look at Solaris's /usr/ucb, /usr/xpg4, and /usr/xpg6 directories. Each standard they support, which has differences from POSIX, is documented and implemented in a separate location. Too bad Linux, as represented by its many distributions, doesn't comply with any standards.
In the end, the differences outlined here are probably the only ones anyone would ever notice. The nuances between du, for example, may be applicable for people writing shell scripts for systems administration procedures. The differences do turn up often enough to be mentionable, but in reality this level of work requires reading manual pages so often that they'd figure it out quickly. User-level utilities are "similar enough" with the exception of ps.
There are so many other differences in system maintenance procedures that those are more frequently focused on. Once the 'ps' hurdle is out of the way, and you understand how the system boots, the main problems are more conceptual, as in "how do I add a user." These vary by OS, and also by distribution of Linux.
Come back next week to learn about the different ways Unix-like operating systems facilitate systems administration tasks.