Wandering Thoughts archives

Two different usage patterns

Recently, for my version of recently, a shell history meme has been going around various places. Thinking about the meme and what it would look like for me has led me to thinking about two different usage patterns in Unix graphical environments; I will call these persistent and disposable.

People who follow the persistent pattern like long-lived, multi-purpose contexts; for example, they are inclined to leave a terminal window or a shell session active for a long time, and over its lifetime such a shell will wind up doing many unrelated things. By contrast, people who follow the disposable pattern have short-lived, single-purpose contexts; for example, if they need to do a new thing they open a new terminal window, do the thing, and then close it.

This difference matters because it changes what you care about. If you're a persistent pattern person you probably don't care too much about how long a new shell session takes to start, because you do it rarely, but you probably do care a lot about good shell history because you have a lot of it. If you're a disposable pattern person it's the other way around; you care a lot about fast program startup, but not so much about history.

Most of the time I am strongly a disposable pattern person (as I put it once, 'one window, one purpose'), to the point where I not infrequently close one window and open up an identical new one just because the new one will be used for a different job. This does mean that I don't really have anything to say on the shell history meme, because I throw away my shell histories when I exit my shells.

(A one window, one purpose approach doesn't necessarily mean no persistent programs; sometimes the best way to get fast disposable windows is to keep a program around. I have a fair amount of infrastructure designed to make getting new windows fast and easy, so that I'm encouraged to throw away old ones.)

The not so secret origins of /usr/bin and /usr/sbin (and /sbin)

Once upon a time, Unix was very small and fit entirely in what is now the root filesystem, /; hence, among other things, /bin, which was where commands went. This didn't last very long, and by the time of at least the Third Edition in 1973, there was an additional /usr filesystem with a /usr/bin for 'overflow' programs that didn't fit on the root filesystem any more.

(As I heard the story, the root filesystem was deliberately set up to contain everything you needed to rebuild at least the kernel, in case you booted a kernel that couldn't mount the user filesystem. Hence as late as V7 Unix you could find the C compiler as /bin/cc and so on.)

I'm not sure if very many things migrated from /bin to /usr/bin, or if it was just that after a certain point normal programs stopped being added to /bin. There was probably a mix of both, with the shrinkage driven by pressure to keep the root filesystem small and an ever-increasing set of programs that were necessary to boot the system to the point where it could mount /usr.

(Sun was a major contributor to the growth of /bin when they made it possible to have diskless machines, especially with NFS. When you NFS-mount /usr, a whole lot of network programs suddenly need to be on the root filesystem.)

Of course, /usr/bin and /bin continued to grow as people added more and more programs to Unix (and booting got more complicated), which people didn't like. At some point someone noticed that a lot of these commands weren't useful for ordinary users (so much so that their manpages were in an entirely different section of the manual from user commands), and had the good idea of moving them to new directories. Thus were /sbin and /usr/sbin born; the 's' is traditionally said to stand for 'system'.

(I suspect that the sbin directories were introduced by Sun, probably in SunOS 4. Sun has been responsible for a surprisingly large number of the rationalizations and complications of the Unix directory hierarchy over the years.)

Once consequence of this was that a whole bunch of system programs that had been scattered in places like /etc and /usr/lib got rationalized into /usr/sbin and /sbin, which is generally a good thing even if I sometimes still try to run /usr/lib/sendmail by reflex.

(What makes my use of /usr/lib/sendmail even more perverse is that I'm not even trying to run Sendmail. For years typing '/usr/lib/sendmail -bt' was the way I fired up our local mailer's debugging mode, and the reflex still lurks in my fingers.)