[nycbug-talk] why /var?

[Bob Ippolito]

On Feb 18, 2005, at 5:13 PM, Jay wrote:

> On Fri, 18 Feb 2005 16:31:21 -0500, Bob Ippolito <bob at redivi.com> 
> wrote:
>
>> "bin" really means "executable".
>>
>> As for the mail spool, the idea is that it's supposed to be persistent
>> until it's ready to go out.  You should be able to wipe /tmp on reboot
>> (if not more often) without any adverse effects, that wouldn't be true
>> if the mail spool was there.  Just because it's volatile doesn't mean
>> it's temporary..
>
> That's exactly the point.  "bin" doesn't mean executable, per se; it's
> short for "binary".  It's used to mean "executable" because "binary"
> and "executable" were interchangeable.  Your program had to be a
> compiled binary to run.  In many cases that's still true, but it's
> becoming less true by the day, particularly on things like large web
> servers: think how much code in cgi-bin is likely to be perl or python
> scripts.  The name, however, has stuck around, and will continue to
> stick around because it's what people are used to.  /exec would me
> more descriptive, though, or OS X's "/Applications", or even Windows
> "C:\Program Files".  I'm not adovcating a change; I'm just pointing
> out that you can't trust the partition labels to adequately describe
> the content.

Well, shared libraries and the kernel also clearly fit the original 
meaning of "bin" (as you describe it).  The intention has always been 
executable..  I wouldn't be surprised if bin was chosen because it was 
easy to type, most UNIX terms are pretty optimal on a QWERTY keyboard.  
Perhaps it's just finger memory, but I find "bin" a lot easier to type 
than "exe" or "exec".

The big difference between UNIX naming and NeXT / Windows naming 
schemes is that in the these worlds you keep your application and 
everything (static) having to do with that application in *one* place.

On NeXT based systems /Applications is very different than /usr/bin.  
Effectively, each application bundle is its own "/usr/local" tree.  You 
find names like "Resources" instead of "share", "Frameworks" instead of 
"lib", and <PlatformName> (i.e. "MacOS") instead of "bin".  It's 
basically turtles all the way down in the NeXT case; Frameworks are 
also equivalent to a subset of the "/usr/local" tree.  The root of the 
framework is "lib", "Headers" is "include" and "Resources" is "share".

Windows is mostly similar to this (applications+static resources have 
their own tree), except that there is no standard schema for how that 
tree should look, and a lot of Windows applications misbehave and toss 
some stuff into the Windows equivalent of "/usr/lib".  You really don't 
see that on NeXT or Mac OS X, unless the developer is really naive or 
lazy.

> I'm not advocating moving the mail spool to /tmp, either.  Clearly
> that would be disasterous.  but if we're talking about truth in
> advertising, spools aren't "variable" data like logs, or databases, or
> /var/run files that serve to save, record, or report particular
> system, data, or harware states.  Spools are a place to temporarily
> store data until confirmation is recieved that they've been handled
> appropriately.  "Persistent unil [I'm done with it]" sounds like a
> temp file to me.  A potentially long-lived temp fiels, but still a
> temp file.

Temporary files are intended to go away as soon as the controlling 
process does or sooner.

Clearly, a mail spool is a database.  Just because its usage pattern 
tries to ensure that the database shouldn't contain many items at a 
given time doesn't make the database itself temporary.

> Again, I'm not objecting to the naming scheme, just saying that we
> need to take the labels with a grain of salt (or two).

Likewise -- maybe we should upgrade that grain to a dash? :)

-bob