On 22 May 2002, Alfred M. Szmidt wrote: > * Emile van Bergen writes: > > On Wed, 22 May 2002, Marcus Brinkmann wrote: > >> On Wed, May 22, 2002 at 04:43:44PM +0200, Emile van Bergen wrote: > >> I thank you for your opinion on this, but we really have to move on. > > > You keep trying to blow a smoke screen around the architectural issue. > > I don't understand why. Remember that *you* want something from Debian, > > (the addition of /hurd), not the other way around. *You* are the one > > under the obligation to answer *why* you *need* a separate /hurd > > directory. > > Frankly, right now it is only you who are blowing this nice huge > smoke screen. It is Debian that wants _us_ to remove /hurd, this > directory has existed since a long time, probably longer than Debian > has existed.. If people have this really annoying problem with one > stupid root directory, why did you not speak up sooner?
I don't represent anybody else using or developing Debian, that's one reason. The reason I *did* speak up was that I thought /hurd was getting a bit bluntly forced through Debian's throat as a sort of 'matter of course', using arguments that did not seem to hold under close examination. Considering that Debian rightfully calls itself an OS, the arrogance of overriding one of its standards in such an arrogant way bothered me. But perhaps just me, I don't know (or really care). > I can give you another reason why a special directory for translators > should exist, it makes life easier to see what cute translators the > system has without having to wade through the hell that exists in > /bin. I doubt that you would want to look at a listing of totally > unrelated crap when your looking for a specific translator for a > specific job. Absolutely, I agree. But let's then not repeat Unix' mistakes in the Hurd at all then, and come up with a better way to package and organise binaries than just having a /bin wasteland. I've given some suggestions in an earlier post. > Putting it in /libexec is wrong because users actually use > translators, which is opposite of what /libexec is supposed to do. > > /lib/whatever is also wrong because translators are not libraries, and > typing "settrans -a ~/ftp /lib/whatever/ftpfs / ftp.gnu.org" is quite > annoying in the long run. Both true. That's why I suggested /bin. > So, now you might ask why the directory is called /hurd instead of > /translators or whatever? Do you know what the Hurd means? Hird of Unix > Replacing Daemons. I think that this is an appropriate name for what > exists in /hurd, a bunch of "daemons" that replace the functionality > that Unix has, but as user-space programs. Quite appropriate don't you > think? Yep. But the name is also closely linked to one implementation of the concept. I doubt whether that will always be the only one. > Now that I am almost done with my rant, could you give us a couple of > reasons why this directory should not exist? And why are you not as > upset about /servers or /libexec as you seem to be about /hurd? /servers is a purely proc-like, dynamic thing, that no package contains files for, and I haven't said anything about libexec (though preserving ABI compatibility with real, live, widely used, existing *BSD systems seems like a good argument to keep it). > I really can't understand why people become so upset about one silly > directory. Why can't you just accept the fact that one such > directory exists? It isn't harming anyone. :) I can, and it's not up to me to decide in any case. But I have a lot more trouble accepting false arguments, stated in a bit arrogant, matter of fact way, backed up by little else but tradition and personal authority. I'm mostly trying to provoke a line of thought that may come up with *sound* reasons for Debian to add /hurd (but not other extra directories containing particular types of binaries), or *the* general criteria when you *do* add a different directory to / or /usr, or a *good* way to categorize binaries. That's all. Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153 | http://www.e-advies.info -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
