Re: A bin for every program and every program in the bin. Oh--except...
On Wed, 22 May 2002, Joshua Judson Rosen wrote:
> On Wed, May 22, 2002 at 07:58:18PM +0200, Emile van Bergen wrote:
> >
> > Unix has something very similar: the ability to pass down an open
> > file descriptor. But nobody's arguing that Debian should have all
> > its programs that are essentially only useful as filters [or
> > WHATEVER], removed from /bin.
>
> Well, of course nobody's arguing that, because it's already been done ;)
To some extent, perhaps. But the general philosophy is still that
packages, whether that's nmap, xapm, fvwm2(!) or playmidi, put their
executables in /usr/bin.
You could consider /usr/X11R6/bin and /usr/bin/games as well-meant but
somewhat half-hearted attempts at categorization of user programs, but
let's be honest, that hasn't come very far beyond the these historic
Unix directories.
> > But while we're sticking to the FHS' *spirit* of {/,/usr}/bin as a
> > gathering place of *all* executables that can be useful to users,
> > regardless of primary intended use, regardless of execution environment,
> > whether that's as a shell command....
>
> I gather from your comments that (on Debian GNU/Linux) `find /usr
> -type f -not -path '/usr/bin/*' -perm +111' should not result in
> anywhere near as many lines of output as it does....
Perhaps not. Or perhaps it should, but then /usr/bin should be
*drastically* reduced.
But I honestly ask the question. If /usr/games is such a great concept,
then why doesn't Debian have *much* more of these directories? For
compilers, window managers, editors, whatnot?
Whatever the answer, apparently we don't apply categories as a rule, and
apparently the *general* rule is still that binaries go in (/usr)/bin,
whatever the kind of package they are from, and /usr/games and
/usr/X11R6/bin the exception.
> > You could just as well argue that program that are primarily intended to
> > be ran from cron should be put somewhere other than /bin, even though a
> > user explicitly specifies himself that the program must be run on his
> > own behalf, and even though the program follows normal exec()-style
> > executable semantics.
>
> Yes, like, say..., all of the graphics-display programs associated
> with xscreensaver, for example ;)
Yes, but if x-window-managers and x-terminal-emulators go in /usr/bin,
then even /usr/X11R6/bin only seems a place where X11-dependent binaries
'commonly' go.
> Oh, and then there are all of those things `games/'....
>
> > And naturally, that's nonsense.
>
> OK..., if you say so :)
I'm only arguing against the 'intended use'-type of criteria, not
against categorization of binaries in general (although I indeed think
one should either drop it or adopt it radically, but that aside).
I think one cannot defend /hurd based on the argument that binaries that
are most useful in a specific execution environment set up by a parent
program must be in a separate directory. Because then you should want
/filters too, and people don't seem to. That's what I was saying.
The argument brought up by Lars Weber, that storing translators in a
directory other than a dedicated one, would make it hard for that other
directory to be translated differently later on, is then indeed a much
better one IMHO.
In that case I'd advocate /trans, *just* in case someone starts to
implement true userspace filesystems in Linux or *BSD, and finishes
before the Hurd does, because then /hurd would be quite confusing.
Who knows. Implementing userspace device drivers seems almost as
attractive on Mach/OSKit as it is on Linux (sorry for the rant, but it
hasn't happened ever since the Hurd was started), so let's allow the
possibility open that a Linux or BSD-based solution achieves Hurd's
other goals (a user-based filesystem and filesystem-based services in a
free OS), before the Hurd itself does.
Don't say that that hasn't happened before. ;-)
I'll shut up now, though.
Cheers,
Emile.
--
E-Advies / Emile van Bergen | e-advies@evbergen.xs4all.nl
tel. +31 (0)70 3906153 | http://www.e-advies.info
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: