> If the Hurd philosophy wants to ignore /usr, why not to > ignore /sbin, too.
I think they are really entirely separate issues. (That doesn't mean that keeping /sbin is therefore inherently right, but it means that the rationale for the /usr -> / symlink does not say anything about the /sbin issue.) The / vs /usr distinction is purely about storage and low-level issues that not only does a non-administrator user never think about at all, but that even the administrator of the system doesn't usually think about in normal operation (i.e. you think about how to set it up when installing the system and you think about what it means when you are rebooting and fsck'ing and restoring backups and so forth, but it's usually irrelevant to life once the system is up multiuser). Thus we have concluded that having the distinction visible in normal use (i.e. /usr/bin != /bin) is more hassle than benefit to anyone, and intend to instead provide (eventually) better ways to accomplish the useful aspect of the distinction, i.e. let the administrator specify where things are stored and what gets fsck'd when, etc., in a way conveniently independent from the names by which those things are accessed in normal use. Conversely, the /bin vs /sbin distinction is purely about avoiding inconvenience and/or confusion for the normal user. The sole thing accomplished by putting some things in /sbin rather than /bin is that if you don't put /sbin in your path, you won't see those things. I myself, probably like most people on this list, rarely notice the distinction since I do have /sbin (and /usr/sbin, on non-Hurd systems) in my path. But the idea is that the average user won't have /sbin or /usr/sbin in their path, and so the programs in those directories can have simple names for the convenience of those who do use them, without an average user either accidentally running one because it has a simple name they confused with something else, or getting a lot of confusing possibilities in a command completion list. > AFAIK /sbin is used for binaries intended for the super-user, and under > Hurd, using translators, the distiction root-normal_user seems not to be > the same of other unix implementations. I am not sure exactly what you are referring to, but I will guess. In the Hurd any user can set up translators (filesystems) and control them, which you might think of in the context of traditional Unix systems has a "superuser" kind of thing to do. The Hurd programs for these things are settrans and fsysopts (among others), which are akin to Unix mount. We put these programs in /bin, while Unix systems put mount in /sbin. But note that on most current Unix systems (if things are configured appropriately), normal users often can use mount (for removable media devices and such). The reason for putting mount in /sbin is perhaps historical (it was certainly the case when /sbin was originally split out of /bin that /sbin/mount was something only root could run), but I like to think instead that it fits my definition of the intended distinction: mount is a hairy systems command, and a naive user would be confused by trying to use it or running it accidentally. Conversely, in the Hurd we intend using translators to become a very common thing that a relatively naive user might know about and want to use frequently--so settrans, fsysopts, et al are in /bin. The things that we do put in /sbin on the Hurd are for the same reason: we expect that the average user will not use them and might be confused by encountering them. For example, mkfs and fsck and so forth are in /sbin. Anyone can use these, on a file or on a device they have permissions for. It's not that we expect only root to use these, but that we expect anyone who wanted to use them to probably know enough about the system to be root (or at least enough more than the average user that they can handle putting /sbin in their path). This is the same on Unix and Linux as on the Hurd. There are many other programs in /sbin (or /usr/sbin) on Unix/Linux that any non-root user might well run. I don't think there is any fundamental distinction here between the Hurd and other systems. Nor is there any great distinction (as yet) for most purposes to the way the Hurd treats privilege vis a vis root and such compared to Unix systems. It is true that we have more flexible underlying mechanisms for choosing what criteria to apply to control privilege for any particular thing, and we have a more flexible higher-level protocol for acquiring, holding and presenting privilege (multiple uids). But the servers we have now all mostly use the traditional root privilege concept. Many things are controlled by the permissions set on individual file nodes (devices, whatever), which is also true on Unix and Linux. > Leaving /sbin would make the filesystem structure simpler, too. Perhaps. On the other hand, it would make the contents of /bin more complex as a whole. The filesystem structure is unavoidably going to be complex, but not everyone has to think about all of it. /bin is the fundamental interface for all command-line users, so everyone has to see it.
