• Abstract and Figures
• Public Full-text

I am not clueless or Myths and misconceptions about the design of GoboLinux Hisham H. Muhammad April 11, 2017 “Those who do not understand Unix are doomed to reinvent it, poorly.” – Henry Spencer, 1987 This week we had another release of GoboLinux, and again a number of people, even if indirectly, called me “clueless” for coming up with such a structure for a Linux distribution, for a number of reasons. None of those reasons was new; I heard all of them many times. This article is an attempt to sum them up, and explain why I chose the design decisions I made, hopefully clearing any pending misconceptions. I don’t have illusion this will prevent them keep happening, but at least I’ll have a text to point people to. This article ranges from common misconceptions from those who have never used GoboLinux, to well-intentioned but poorly-thought-out ideas that keep coming from time to time to the GoboLinux mailing list, often causing long debates. I’ll be separating the points in sections and they are meant to be self-contained, so feel free to skip directly to the ones that interest you, if you don’t feel like reading the whole thing. “There is a reason why things are the way they are” This is something I hear constantly, often followed by an explanation about the difference between /, /usr and /usr/local, and/or /bin and /sbin. I do understand the difference1. If I did away with this three-level distinction, is because I believe there are other ways to approach the problems this distinction tries to solve. In a GoboLinux system, the argument for having separate /usr and /usr/local trees in order to separate programs shipped by the distribution and compiled by the user clearly does not hold. Each program is naturally separated, and this was the prime intention of creating GoboLinux in the first place. The historical reason why Unix systems have some of its tree directly at the root partition (/bin, /lib, /sbin) as opposed to having it under /usr, is because this way you can boot in 1For those who always wondered (and those who want to check if I really understand the difference), the three main trees divide, respectively, files that need to be available in the root partition for single-user rescue mode, program files managed by the distribution, and programs added separately by the site admin (this dis- tinction varies on different Unices, but this is mainly how it works on Linux distributions, read on for more). Regular programs go in /bin, and programs intended for the superuser in /sbin. 1 a bare-bones single-user rescue mode using those files only, in order to fix problems in the /usr tree. This is arcane. When I need to rescue my system, I can use a fully-featured live CD that runs a complete Linux distribution with a graphical desktop, that allows me to browse the web and search for the solution to my problem, and use all of the features of a regular system to fix it. I understand the rationale for having a bare-bones rescue mode decades ago, but we have a better solution in our hands now. The distinction between bin and sbin makes no sense, in the present context. Historical evolution led to crazy arbitrary distinctions, like ping and traceroute lying in different directories (I fail to see how can they be of distinct “program classes”, by any measure). Unix systems have a permissions system. If one wants only the superuser to be able to run a command, then chmod 700 it. I suspect the separation could have been conceived to reduce the number of programs in the $PATH of regular users. In today’s Linux systems, having 400 or 500 programs in your $PATH, does not make any difference. There is one last argument, however, that is still valid for Linux systems to day: parti- tioning and remote mounting. Those two are really different shades of the same color, with remote mounting being, to my eyes, the most valid concern of those two. I’ve seen argu- ments about this among the lines of “hard drives today are cheap, and you’ll most likely have all software installed locally anyway, for performance”. I agree with this, but I also understand the ones who’d like to maintain things centralized for administrative purposes. But imposing additional complexity on the overall system because of one particular sce- nario is usually not a good thing, and even then, the traditional Unix solution is not general enough: what if you have three or four application servers? You’ll mount one at /usr, one at /opt, and then what? There goes the traditional Unix tree. In fact, in most of the larger Unix networks I had contact with, particular needs of the site configuration led to non-standard directories added to the Unix tree. Fortunately, like with the live CD, we have nowadays a technological advancement that serves as a real solution to the problem: union mounts, also known as overlay filesystems. The idea is that you can mount several partitions in the same directory. This way, the semantics of /Programs as “the collection of all programs available in the system” is retained, indepen- dently of the physical location of the actual data. File systems are all about abstraction (we don’t refer to files based on their track, sector and cylinder address), this progresses a step further. Overlay filesystems are very flexible: the sysadmin, for example, can overlay site- specific settings for an application on top of the defaults exported over NFS. Unfortunately, it is not in widespread use, for reasons beyond by understanding. The Plan 9 operating system has it as one of its basic filesystem operations: the bind command (in Plan 9, for example, you don’t need a $PATH variable, because all directories containing executables are “bound” in a single directory). There is an implementation of an overlay filesystem for Linux: ovlfs. The alleged user-friendliness of longer names Many, many people, when they stumble upon GoboLinux, look at the long, descriptive di- rectory names and say “Look! They changed the Linux directory names by making them longer and descriptive to make the system friendly!”. There is some people who say this as if this were a good thing, and some people who say this as if this were a bad thing. Both are wrong. There is a number of reasons why the names in GoboLinux are the way they are, and 2 none of them is “to attract new users who are scared by /etc and the like”. The number one reason is: to not conflict with the Unix namespace. And when I say Unix namespace I actually mean the Linux namespace, which is not a very well settled thing. This is not like a set of reserved keywords from a programming language that says not to use if, while, repeat, etc. as variable names and the rest is okay. You never know what directories, files and programs will show up tomorrow, so the best I could do was to pick names that were very unlikely to be ever used. Others did that before me, and that worked, so I followed their example: NeXT and Mac OS X had to make their own directories coexist with Unix directories, so they capitalized the names, and while they were at it, they used full words instead of abbreviations. The abbreviations were a sign of the times from the origins of Unix. Dennis Ritchie once said that if he could go back in time and change only one thing in Unix, he’d rename the creat system call to create. The one thing that reassures me that my decision was right is that, when we started with GoboLinux, back in the days of Linux 2.4.something, someone asked me “why didn’t you pick /sys instead of /System? That would be easier to type”. You can guess what would have happened, now that the kernel guys reserved /sys for their own use. In fact, the concerns on typing-friendliness always comes up in discussions about the GoboLinux tree. To that, I can only respond that, in a properly configured shell like the one that comes by default with GoboLinux, typing /Programs takes the exact same number of keystrokes as typing /usr: slash, lowercase p, Tab. One could also ask: but why change the directories, for starters? Why not simply use the regular directory tree and make it behave like GoboLinux? Yes, I suspect it could be possible, but from an operating system design standpoint, I don’t like the idea. I am not comfortable with the concept of a system where well-known directories have different semantics to those that most people expect. AtheOS, for example, has this problem. You see a /usr directory, but that is no /usr. In AtheOS, it behaves more like /opt, but unexplicably keeping the name that historically stood for “user” and then was turned into a backronym for Unix System Resources. Even if Kurt Skauen called it /opt, it would still be strange; those are not “optional packages”. The GoboLinux directories, too, have different semantics from the Unix directories. /Pro- grams is the collection of all programs available in the system, where each subdirectory contains all files from a given program (the distinction of a program package is up to the developers of each project; the various tools from CoreUtils form a single program). Each subdirectory in /System/Links contains a view (in the database sense of the term) of each file class from the programs collection: libraries, executables, headers, and so on2.

Load more

  9

Copy Link