One of the principles I follow in computing is order. I like when my documents have date tags in their names and they’re properly arranged in directories. Moreover, I appreciate the power of ‘_’ and ‘-‘ in file naming to allow better sorting. As an extension of that thought, order was one of the major incentives that brought me to FreeBSD.
Oddly enough, order is an intrinsic feature of Unix, which has been passed down to the BSD descendants, but not really to GNU/Linux. In fact, there is an old chaos vs order argument, well elaborated in the FreeBSD Handbook and a blog written by an experienced Unix administrator. Linux was always only the kernel, containing the basic set of tools to let the operating system talk to the hardware, though without utilities for user-defined tasks (the userland). Richard Stallman was one of the first to shape the Linux universe into something resembling an operating system. However, since only the kernel is truly monolithic, we now have hundreds of Linux distributions and loosely connected tool-sets (the GNU project and more).
Due to the fact that Linux and GNU derived applications are common to all of the open-source operating systems, FreeBSD on the outside is no different than Gentoo, Debian or Fedora. Of course, provided that the desktop environment is configured identically. Where the differences finally become noticeable, is system administration.
To start with, GNU/Linux operating systems use ‘sd*’ labels for IDE, SATA and USB hard drives (all located in /dev/, of course). Because the labeling process is dynamic, one can sometimes find their hard drive to have a different label when an external USB drive is attached or isn’t (Schroedinger drives?), or in the instance of performing a fresh install from a USB thumb drive. FreeBSD defines such labels much more clearly and internal IDE/SATA hard drives are always labeled ‘ada*’ or ‘ad*’, while USB drives (dongles or normal external drives) are always labeled ‘da*’. No confusion possible. Going further, FreeBSD employs disk slices as an important feature of hard drive partitioning. That way partitions or whole drives can exist as slices. This added dimension is of immense importance for RAID setups, a hallmark feature of FreeBSD. Also, contrary to GNU/Linux ‘sr*’, a CD-ROM/DVD-ROM is always ‘cd*’. Makes sense, does it not?
Another point is the directory organization. On Unix-like operating systems binaries can be found in /bin, /sbin, /usr/bin, /usr/sbin, etc. For FreeBSD this holds true, but only in respect to integral parts of the operating system. The FreeBSD base system is the monolithic core, unlike the Linux kernel for GNU/Linux distributions. Everything that doesn’t belong to the base exists in /usr/local, naturally following its original organization into /etc, /bin, etc. This is perhaps the most vital feature of FreeBSD. It saves a lot of headaches and allows swift cleanups when matters get out of hand.
Somewhat connected to directory organization we have the central Unix paradigm of do one thing and do it well. What I oftentimes find absolutely annoying in GNU/Linux is the redundancy of key system tools, such as those for network configuration. One would (and should!) be more than sufficient. FreeBSD does exactly that! Networks are configured via ifconfig, period. One tool per job, but connected in such a (Unix) way that an output from one tool can be efficiently piped into a multitude of others.
Last but not least, an intrinsic part of the BSD world is documentation. An undocumented pigeon may as well be a wolf in sheep’s skin, unless we can read its man pigeon manual page or find the appropriate reference in a handbook. The Arch Linux, Fedora and Gentoo projects clearly show how absolutely mandatory it is to have good documentation. Read the manual (RTM) should be treated as a blessing, a promise of comprehension, not as a hex one uses to drive evil spirits and trolls away! OpenBSD (though FreeBSD also) is king in terms of documentation. No patch/update/you-name-it may be released if it is not properly (clearly) documented.
Thus, I conclude my musings. Somewhat naively, thinking that maybe in the future GNU/Linux will learn that order is in fact good and makes both work and leisure more enjoyable.