[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Path idea


On Mon, Jan 18, 1999 at 12:50:02PM +0100, Thomas MANGIN wrote:
> All of you have a very strong Unix oriented view of OS (that is normal
> for Hurd devel) but I really have the impression that you dont really
> want to change things.

Yes, your impression is correct. The Unix directory layout may not be
perfect, but it has a long tradition and works fairly well in most cases.

> Whatever you think about the Unix floder organisation (even if logical)
> is a fucking mess. (too much things are cross-linked or split between :
> /sbin, /bin, /usr/bin/, /usr/sbin, /usr/local/bin, ...)
> And the reason is that there are too many application to fit properly in
> one place.

I don't buy both arguments. First, it is not a mess, but an organization.
You can't deny that there is a structure. Your "split" is not a split. If we
assume that we have a real /usr tree (which is not true on the Hurd), the
root /bin does contain only binaries necessary for a minimal system boot for
rescue. Normally, /usr/bin is the directory to use for binaries. Thirdly,
the local tree is for local use by the system administrator. This is
essential, because the Operating System vendor (Debian in this case) can
assume that the sysadmin never touches anthing below /usr/local (except /etc
and /var of course), and the system administrator may safely assume that
installing a package will never chnage the /usr/local tree.

This has good reasons: /usr/local should override settings in /usr.

The clutter is of minor relevance, because a good default PATH solves this.

Too many applications to fit in one place? The Hurd should be able to handle
an arbitrary amount of files in a directory. If not, the number is at least
very high.

> On anothre side, I perfectly understood that to create hurd you have to
> work under Linux but your discution about /usr
> reminds me somehing I saw in inferno OS (a long time ago)
> it was possible to lauch application like this
> > editor/vi
> > wm/start
> I mean extending the PATH already set.
> I had found that a wonderful idea.
>  I know it it is utopia. But I hope to be explained why my point of view
> must be eradicated forever cleary.

I don't quite understand what you propose. It is either of the following:

a) letting the user type "editor/vi" if he wants to start vi.
   This would be highly annoying. It may be reaosnable to stick vi in
section editor, but do you think it is reasonable to expect from the user to
remember the "section" the application is in? Some applications may fit into
several sections, do you want to link the binary in several places?

b) Adding the sections to the path.
   This has the problem that you need to extend the path whenever you use a
new section. Note that there is no common way to define environment
variables for all shells.

In short, I don't see any good reason for splitting the binaries into
sections. Before I continue to explain why I dislike it, you should probably
provide some good points why your idea is worth considering. What does it
gain? What additional functionality will you get?


"Rhubarb is no Egyptian god."        Debian GNU/Linux        finger brinkmd@ 
Marcus Brinkmann                   http://www.debian.org    master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de                        for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       PGP Key ID 36E7CD09

Reply to: