From list-relay@mailbox1.ucsd.edu Mon May 19 08:17:01 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA15610 for ; Mon, 19 May 1997 08:17:01 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA13623 for ; Mon, 19 May 1997 08:14:22 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA20108 for ; Mon, 19 May 1997 08:09:09 -0700 Received: from sugar-bombs.gnu.ai.mit.edu (sugar-bombs.gnu.ai.mit.edu [128.52.46.18]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id HAA03724 for ; Mon, 19 May 1997 07:29:46 -0700 (PDT) Received: (from thomas@localhost) by sugar-bombs.gnu.ai.mit.edu (8.8.5/8.7.3) id KAA08175; Mon, 19 May 1997 10:29:36 -0400 (EDT) Date: Mon, 19 May 1997 10:29:36 -0400 (EDT) Message-Id: <199705191429.KAA08175@sugar-bombs.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: garrett@qualcomm.com CC: roth@uiuc.edu, t.sippel-dau@ic.ac.uk, garrett@qualcomm.com, fhs-discuss@ucsd.edu In-reply-to: "Garrett D'Amore"'s message of Tue, 13 May 1997 09:45:24 -0700 <199705131645.JAA19020@liferaft.qualcomm.com> Subject: Re: Network daemons: /usr/sbin or /usr/libexec (was: status of new X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Zippy-Says: I invented skydiving in 1989! Xref: rhodium.transmeta.com linux.fhs:1 Status: RO Content-Length: 453 Lines: 15 Date: Tue, 13 May 1997 09:45:24 -0700 From: "Garrett D'Amore" Given your arguments below, I'd prefer to just leave /usr/lib and /usr/sbin alone. While /usr/lib might have gotten "messy", it may cost much more to fix this than its worth. I don't know of any "modern" UNIX that has made an effort to seperate this sort of data. NetBSD, GNU, and others, have all separated this stuff out of /usr/lib. Thomas From list-relay@mailbox2.ucsd.edu Mon May 19 08:18:24 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA15662 for ; Mon, 19 May 1997 08:18:24 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA13659 for ; Mon, 19 May 1997 08:15:53 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA20131 for ; Mon, 19 May 1997 08:10:41 -0700 Received: from sugar-bombs.gnu.ai.mit.edu (sugar-bombs.gnu.ai.mit.edu [128.52.46.18]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id HAA02486 for ; Mon, 19 May 1997 07:18:52 -0700 (PDT) Received: (from thomas@localhost) by sugar-bombs.gnu.ai.mit.edu (8.8.5/8.7.3) id KAA07242; Mon, 19 May 1997 10:18:42 -0400 (EDT) Date: Mon, 19 May 1997 10:18:42 -0400 (EDT) Message-Id: <199705191418.KAA07242@sugar-bombs.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: garrett@qualcomm.com CC: ldeutsch@mail.netshop.net, fhs-discuss@ucsd.edu, garrett@qualcomm.com In-reply-to: "Garrett D'Amore"'s message of Mon, 12 May 1997 11:46:05 -0700 <199705121846.LAA03017@liferaft.qualcomm.com> Subject: Re: Network daemons: /usr/sbin or /usr/libexec (was: status of new X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Zippy-Says: Yow! Did something bad happen or am I in a drive-in movie?? Xref: rhodium.transmeta.com linux.fhs:2 Status: RO Content-Length: 799 Lines: 20 Date: Mon, 12 May 1997 11:46:05 -0700 From: "Garrett D'Amore" As far as I can see, the sole benefit of separating /usr/sbin/ and /usr/libexec is to make roots path smaller. I'm not convinced that this is worth doing, although it may help some "newbie" root admins avoid running programs that they shouldn't. (This didn't used to be a concern, but now with these new commercial distributions showing up everywhere, it becomes more of a concern. My mother-in-law recently got RedHat installed on her machine -- she's learning to use the UNIX shell, and she now has root on her machine -- needless to say I cautioned here not to use root privs!) It speeds up execvp time as well. And, most importantly, it makes completion useful. Thomas From list-relay@mailbox2.ucsd.edu Wed Jul 9 01:04:22 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id BAA05321 for ; Wed, 9 Jul 1997 01:04:20 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id BAA22061 for ; Wed, 9 Jul 1997 01:03:13 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id AAA03916 for ; Wed, 9 Jul 1997 00:50:16 -0700 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id AAA02078 for ; Wed, 9 Jul 1997 00:14:04 -0700 (PDT) Received: by proton id m0wlqwu-0001HjC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 9 Jul 1997 00:14:04 -0700 (PDT) Message-Id: Date: Wed, 9 Jul 1997 00:14:04 -0700 (PDT) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: Decision to remove /usr/libexec X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: ruthenium.transmeta.com linux.fhs:3 Status: RO Content-Length: 743 Lines: 24 -----BEGIN PGP SIGNED MESSAGE----- I have decided to remove the /usr/libexec section from the draft. There was more support for removing it in the straw poll and I am concerned that if added, it would be very difficult to remove or change at a later date. Removing it does not negatively effect other changes in the new standard, it can be added at any time to "restore" the standard to its state before I removed /usr/libexec. - Dan -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBM8M6OqkybebRDjw1AQExFAP/XOxzpye5kKBpgjywXvrVG3z/dVjxK+CJ dWIBWsD8ZOdphXq4YiQD2m/NWOn60paTPHsVqHxqOAbdvqSagRisk18kqB87G3d5 eHYeAGrp7H9U82j9Hn2jsvOjcaxSJyrbCsb1J/ziwEeqXX4UsTsq5RFmkPoIfu4x tMc8Y9E1Mmk= =ey9B -----END PGP SIGNATURE----- From list-relay@mailbox2.ucsd.edu Wed Jul 9 01:13:13 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id BAA05473 for ; Wed, 9 Jul 1997 01:13:11 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id BAA22282 for ; Wed, 9 Jul 1997 01:12:03 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id AAA03968 for ; Wed, 9 Jul 1997 00:59:07 -0700 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id AAA01971 for ; Wed, 9 Jul 1997 00:11:00 -0700 (PDT) Received: by proton id m0wlqtv-0001HjC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 9 Jul 1997 00:10:59 -0700 (PDT) Message-Id: Date: Wed, 9 Jul 1997 00:10:59 -0700 (PDT) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: Results of straw poll regarding /usr/libexec X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: ruthenium.transmeta.com linux.fhs:4 Status: RO Content-Length: 888 Lines: 44 -----BEGIN PGP SIGNED MESSAGE----- Here are the results from the straw poll. > Question 1: > > A. change how it is currently drafted > B leave it as currently drafted > C. either way okay 7 for A 5 for B 3 for C > Question 2: > > If /usr/libexec is changed, I would prefer to: > > A. drop /usr/libexec and stick with /usr/lib for now > B. have a /usr/arch directory for libexec and libdata > C. add /usr/libdata > D. allow libdata to go into /usr/libexec > E. something else (please specify) 8 for A 1 for B 1 for E 2 for C 2 for D 1 for !B - - Dan -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBM8M5gqkybebRDjw1AQFM5QP+PVq07OuEMbZfKzvNcDg5Kc330wFLSiHS H9n0sUDaQGuTJNg+TVg9N5VWtlzxdbdR96IdID38ETPtGrfzPm2Bx2CTrapJhhUk vRBYxeLFCO9m0DL52voUPOS7tvBEVNTb+XZ6FfuzYDYbJyVK73x9n3XC2AYCczlz Ui/L4pdaaqw= =heqw -----END PGP SIGNATURE----- From list-relay@mailbox2.ucsd.edu Wed Jul 9 01:13:13 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id BAA05476 for ; Wed, 9 Jul 1997 01:13:12 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id BAA22286 for ; Wed, 9 Jul 1997 01:12:04 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id AAA03970 for ; Wed, 9 Jul 1997 00:59:07 -0700 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id AAA02911 for ; Wed, 9 Jul 1997 00:39:39 -0700 (PDT) Received: by proton id m0wlrLa-0001HjC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 9 Jul 1997 00:39:34 -0700 (PDT) Message-Id: Date: Wed, 9 Jul 1997 00:39:34 -0700 (PDT) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: FHS 2.0 pre-release available X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: ruthenium.transmeta.com linux.fhs:5 Status: RO Content-Length: 1114 Lines: 38 -----BEGIN PGP SIGNED MESSAGE----- FHS 2.0 is ready to go. A pre-release is now available at: ftp://ftp.pathname.com/pub/pre-fhs-2.0.tar.gz http://www.pathname.com/fhs/pre-fhs-2.0.tar.gz tsx-11 is giving me a "disk full" error message, so the usual location doesn't have this draft. If you have any changes (preferably in the form of patches) to make, please make them before tomorrow evening. The only thing holding up the release is the writing of the announcement, which I plan to do tomorrow evening. Changes since FHS 1.99 draft: /usr/libexec removed /usr/lib restored to state similar to how it was before /usr/libexec /usr/include - out-of-date Linux-specific unnecessary cruft removed /var/cache/man cleanup from Chris Metcalf generic editorial changes Have a good day, - Dan -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBM8NANKkybebRDjw1AQGl8QP8CMlXfsJcIomi5h5xEpbYY3OhS/2xOMXl rL/+KURcDrufKaHRskxDjSW5qHIMM3PcUAP6R7G5VBVCwyZwEM1ixSoRbdWhee/z Aei0P9nx3SJSxGHvksCxXuyAQ+92bxI9QVeG03vNf455+ufDxkEVahsw6ZJEuWxl sNJUh2ch4Wk= =deM3 -----END PGP SIGNATURE----- From list-relay@mailbox2.ucsd.edu Wed Jul 9 10:42:29 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA15910 for ; Wed, 9 Jul 1997 10:42:29 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA30576 for ; Wed, 9 Jul 1997 10:41:22 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA07735 for ; Wed, 9 Jul 1997 10:28:22 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA23817 for ; Wed, 9 Jul 1997 09:54:12 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id MAA02236; Wed, 9 Jul 1997 12:54:06 -0400 (EDT) Date: Wed, 9 Jul 1997 12:54:06 -0400 (EDT) Message-Id: <199707091654.MAA02236@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: fhs-discuss@ucsd.edu In-reply-to: Daniel Quinlan's message of Wed, 9 Jul 1997 00:10:59 -0700 (PDT) Subject: Re: Results of straw poll regarding /usr/libexec X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "Socialism is dead," Tom communicated. Xref: ruthenium.transmeta.com linux.fhs:8 Status: RO Content-Length: 426 Lines: 12 Please make sure the standard notes that it doesn't really address BSD or GNU/Hurd systems at all. Consistently, the advice of the rest of us non-Linux systems is basically ignored. There's nothing wrong with having a Linux-only standard, but don't pretend that it's more than it is. It would be nice to have a standard that BSD and GNU/Hurd can use, but not if we have to take big steps backwards in the process. Thomas From list-relay@mailbox2.ucsd.edu Thu Jul 10 16:00:12 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id QAA01657 for ; Thu, 10 Jul 1997 16:00:11 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id PAA12692 for ; Thu, 10 Jul 1997 15:59:03 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id PAA20795 for ; Thu, 10 Jul 1997 15:45:52 -0700 Received: from freya.van.hookup.net (freya.van.hookup.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id PAA19090 for ; Thu, 10 Jul 1997 15:52:13 -0700 (PDT) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (kamloops-21.netshop.net [207.102.173.118]) by freya.van.hookup.net (8.8.5/1.25) with SMTP id PAA15075 for ; Thu, 10 Jul 1997 15:51:51 -0700 (PDT) Message-Id: <199707102251.PAA15075@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Thu, 10 Jul 1997 15:51:43 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Results of straw poll regarding /usr/libexec Priority: normal In-reply-to: <199707091654.MAA02236@churchy.gnu.ai.mit.edu> References: Daniel Quinlan's message of Wed, 9 Jul 1997 00:10:59 -0700 (PDT) X-mailer: Pegasus Mail for Windows (v2.54) Xref: ruthenium.transmeta.com linux.fhs:11 Status: RO Content-Length: 1430 Lines: 35 Thomas Bushnell ranted: > Please make sure the standard notes that it doesn't really address BSD > [...] > not if we have to take big steps backwards in the process. As the other person who voted for libdata, I'm aghast at the results too. But here you just sound like a sore loser. We cannot ignore a democratic defeat this decisive. I've done some thinking, and I think the problem wasn't antipathy to the GNU libexecdir. It was antipathy to a completely different directory, which happened to share the same name. Unfortunately I recently cleared out my mailbox, but I recall someone complaining that /usr/libexec would "clean out" /usr/sbin rather than /usr/lib. But this problem was introduced by FHS itself, via a very poor choice of examples. # Examples of programs located in /usr/libexec include internet # daemons started by inet; programs started by init such as getty; # and compiler binaries started by the C compiler such as cc1. But none of the above would be placed there in a GNU system. Only "cc1" in principle belongs there, and in practice GCC puts it under /usr/lib (which is erroneous, but has loads of inertia.). The rest are clearly sbin files. How about this replacement: Examples of programs located in /usr/libexec include the "updatedb" subprograms (code, frcode, bigram) and the nameserver zone transfer program (named-xfer). ---- Michael Deutschmann From list-relay@mailbox1.ucsd.edu Thu Jul 10 21:13:32 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id VAA10112 for ; Thu, 10 Jul 1997 21:13:31 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id VAA21910 for ; Thu, 10 Jul 1997 21:12:23 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id UAA23493 for ; Thu, 10 Jul 1997 20:59:10 -0700 Received: from orl.lmco.com (theopolis.orl.mmc.com [141.240.10.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id VAA16000 for ; Thu, 10 Jul 1997 21:10:00 -0700 (PDT) Received: from sunny.orl.lmco.com by orl.lmco.com (SMI-8.6/SMI-SVR4) id AAA24987; Fri, 11 Jul 1997 00:09:57 -0400 Received: from sheri.orl.lmco.com (sheri.orl.mmc.com) by sunny.orl.lmco.com (4.1/GEA Sun server 2.7) id AA03254; Fri, 11 Jul 97 00:09:57 EDT Received: from sheri (localhost.orl.lmco.com) by sheri.orl.lmco.com (4.1/1.34.a) id AA10774; Fri, 11 Jul 97 00:09:55 EDT Message-Id: <9707110409.AA10774@sheri.orl.lmco.com> X-Mailer: exmh version 1.6.7 5/3/96 From: Tom Julien To: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jul 1997 00:09:55 -0400 Sender: tomj@escmail.orl.lmco.com Xref: ruthenium.transmeta.com linux.fhs:12 Status: RO Content-Length: 1006 Lines: 35 Daniel Quinlan writes: [...] >> A. drop /usr/libexec and stick with /usr/lib for now FWIW, this would have been my vote had I been able to enter the poll. However, I'm very interested in trying to accom- modate the BSD and FSF folks in a future version if at all possible. Eric S. Raymond writes: >1. Practically speaking there are only *two* models of rc setup. No point > in making the language more intimidating to developers than necessary. and later: >Owen LeBlanc: [...] >> The setup of command scripts invoked at boot time may resemble >> System V or BSD models. Further specification in this area >> may be added to a future version of this standard. > >I consider this a friendly amendment and endorse it. I'm probably partly to blame for the rc setup wording Eric. With the slight variations on the BSD, SYSIII, and SYSV startups still in existence, I thought Dan's choice of the word "several" was better than "two". Tom Julien From list-relay@mailbox2.ucsd.edu Thu Jul 10 21:24:44 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id VAA10276 for ; Thu, 10 Jul 1997 21:24:44 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id VAA22125 for ; Thu, 10 Jul 1997 21:23:36 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id VAA23603 for ; Thu, 10 Jul 1997 21:10:23 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id VAA03405 for ; Thu, 10 Jul 1997 21:22:11 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id AAA15569; Fri, 11 Jul 1997 00:28:53 -0400 From: "Eric S. Raymond" Message-Id: <199707110428.AAA15569@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: tomj@orl.lmco.com (Tom Julien) Date: Fri, 11 Jul 1997 00:28:53 -0400 (EDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: <9707110409.AA10774@sheri.orl.lmco.com> from "Tom Julien" at Jul 11, 97 00:09:55 am Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: ruthenium.transmeta.com linux.fhs:13 Status: RO Content-Length: 352 Lines: 10 Tom Julien: > I'm probably partly to blame for the rc setup wording Eric. > With the slight variations on the BSD, SYSIII, and SYSV > startups still in existence, I thought Dan's choice of > the word "several" was better than "two". Say *what*? The *SYSIII* setup is still alive? Where? -- Eric S. Raymond From list-relay@mailbox2.ucsd.edu Thu Jul 10 23:17:10 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id XAA12211 for ; Thu, 10 Jul 1997 23:17:10 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id XAA24195 for ; Thu, 10 Jul 1997 23:16:03 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id XAA24554 for ; Thu, 10 Jul 1997 23:02:48 -0700 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id XAA06192 for ; Thu, 10 Jul 1997 23:15:08 -0700 (PDT) Received: by proton id m0wmYyy-0001UAC (Debian Smail-3.2 1996-Jul-4 #2); Thu, 10 Jul 1997 23:15:08 -0700 (PDT) Message-Id: Date: Thu, 10 Jul 1997 23:15:08 -0700 (PDT) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: <199707102251.PAA15075@freya.van.hookup.net> References: <199707091654.MAA02236@churchy.gnu.ai.mit.edu> <199707102251.PAA15075@freya.van.hookup.net> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: ruthenium.transmeta.com linux.fhs:14 Status: RO Content-Length: 1069 Lines: 32 -----BEGIN PGP SIGNED MESSAGE----- ldeutsch@mail.netshop.net writes: > Unfortunately I recently cleared out my mailbox, but I recall someone > complaining that /usr/libexec would "clean out" /usr/sbin rather than > /usr/lib. But this problem was introduced by FHS itself, via a very > poor choice of examples. /usr/sbin has always been a $PATH directory, specifically for system programs run from the command line or shell scripts. "lib" is for library data, hence any new "lib" directory could not affect /usr/sbin. There was no poor choice of examples, only people who didn't read the standard carefully. the rationale for the now-absent /usr/libexec went so far as to say: [...] as internal binaries migrate from /usr/lib to /usr/libexec [...] Dan -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBM8XPaqkybebRDjw1AQHlGQP/VSgIoY7dsRiZ7rWlGOfZjCKxjz1yiGGf BWFdVfiGT91l1uki1AfaQ4uRYLKvKJ37eZ2PjJP0qwRAm3/rkj03fnDdxc2dsX64 J0/4enAtCMueiAo4hBv0/dTE+ApD781TLEc1bsQwQYHFtr4WdvWgy2/Hj91QTl1M FtA5lb6Z/+M= =FksV -----END PGP SIGNATURE----- From list-relay@mailbox2.ucsd.edu Fri Jul 11 10:22:22 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA24102 for ; Fri, 11 Jul 1997 10:22:21 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA02694 for ; Fri, 11 Jul 1997 10:21:14 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA29537 for ; Fri, 11 Jul 1997 10:07:53 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id IAA20525 for ; Fri, 11 Jul 1997 08:18:35 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id IAA23834; Fri, 11 Jul 1997 08:18:05 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199707111518.IAA23834@GndRsh.aac.dev.com> Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: <199707102251.PAA15075@freya.van.hookup.net> from "ldeutsch@mail.netshop.net" at "Jul 10, 97 03:51:43 pm" To: ldeutsch@mail.netshop.net Date: Fri, 11 Jul 1997 08:18:04 -0700 (PDT) Cc: fhs-discuss@ucsd.edu X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:15 Status: RO Content-Length: 1393 Lines: 37 > Thomas Bushnell ranted: > > Please make sure the standard notes that it doesn't really address BSD > > [...] > > not if we have to take big steps backwards in the process. > > As the other person who voted for libdata, I'm aghast at the results > too. But here you just sound like a sore loser. We cannot ignore a > democratic defeat this decisive. This list stopped being democratic quote some time ago, IMHO, basicially we had _several_ very key BSD players on here (Keith are you still listing even??) but basically you beat us to a pulp going over and over and over the same decision cource, so we gave up and stopped sending input (my case), or just walked away quitely (2 other cases I know of). A quote from Thursday, October 5, 1995: >> rgrimes: >> I should not be argueing these points at this time, I did that 3 months >> ago. I don't like to repeat my self or repeat my work, sorry, simiple >> fact of economics of time tell me not to do it. >> > bostic: > Yeah, that pretty much covers it. I try to avoid groups that > do "concensus by exhaustion". Well folks, I was exhausted long ago with respect to putting any effort _into_ the FSH, now I am not even going to read the mail anymore... Good by and good luck! -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From list-relay@mailbox2.ucsd.edu Fri Jul 11 13:42:42 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id NAA29140 for ; Fri, 11 Jul 1997 13:15:13 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id NAA08842 for ; Fri, 11 Jul 1997 13:14:05 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id NAA30826 for ; Fri, 11 Jul 1997 13:00:45 -0700 Received: from orl.lmco.com (theopolis.orl.mmc.com [141.240.10.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id NAA08310 for ; Fri, 11 Jul 1997 13:11:08 -0700 (PDT) Received: from sunny.orl.lmco.com by orl.lmco.com (SMI-8.6/SMI-SVR4) id QAA26448; Fri, 11 Jul 1997 16:11:05 -0400 Received: from sheri.orl.lmco.com (sheri.orl.mmc.com) by sunny.orl.lmco.com (4.1/GEA Sun server 2.7) id AA01805; Fri, 11 Jul 97 16:11:04 EDT Received: from sheri (localhost.orl.lmco.com) by sheri.orl.lmco.com (4.1/1.34.a) id AA13106; Fri, 11 Jul 97 16:11:03 EDT Message-Id: <9707112011.AA13106@sheri.orl.lmco.com> X-Mailer: exmh version 1.6.7 5/3/96 From: Tom Julien To: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Jul 1997 16:11:03 -0400 Sender: tomj@escmail.orl.lmco.com Xref: sodium.transmeta.com linux.fhs:16 Status: RO Content-Length: 1404 Lines: 37 Please don't take the following as any interference with the release of 2.0... Daniel Quinlan writes: >ldeutsch@mail.netshop.net writes: > >> Unfortunately I recently cleared out my mailbox, but I recall someone >> complaining that /usr/libexec would "clean out" /usr/sbin rather than >> /usr/lib. But this problem was introduced by FHS itself, via a very >> poor choice of examples. > >/usr/sbin has always been a $PATH directory, specifically for system >programs run from the command line or shell scripts. "lib" is for >library data, hence any new "lib" directory could not affect /usr/sbin. I think the problem some folks have with /usr/libexec is that it does remove indirectly executed programs from /usr/sbin. Right or wrong, inet daemons, etc. that may have previously existed in such places as /usr/etc now reside in /usr/sbin on many systems. With this, it could be argued that indirectly executed programs probably don't belong in either a "bin" or a "lib" directory (at least by today's definitions). A number of issues wrt libexec were indeed beaten to death two years ago, and I can understand the frustration of BSD and GNU. Is there anything we can discuss that might overcome this stalemate? I don't know if it'll help, but I'd like to recap a few points at a later time, and see if we can at least reach a compromise for the future... Tom Julien From list-relay@mailbox1.ucsd.edu Fri Jul 11 15:22:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id PAA02825 for ; Fri, 11 Jul 1997 15:22:36 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id PAA13046 for ; Fri, 11 Jul 1997 15:21:28 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id PAA31924 for ; Fri, 11 Jul 1997 15:08:08 -0700 Received: from freya.van.hookup.net (freya.van.hookup.net [207.102.129.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id PAA04482 for ; Fri, 11 Jul 1997 15:17:50 -0700 (PDT) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (kamloops-32.netshop.net [207.102.173.131]) by freya.van.hookup.net (8.8.5/1.25) with SMTP id PAA05695 for ; Fri, 11 Jul 1997 15:17:47 -0700 (PDT) Message-Id: <199707112217.PAA05695@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Fri, 11 Jul 1997 15:17:35 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Results of straw poll regarding /usr/libexec Priority: normal In-reply-to: References: <199707102251.PAA15075@freya.van.hookup.net> X-mailer: Pegasus Mail for Windows (v2.54) Xref: sodium.transmeta.com linux.fhs:17 Status: RO Content-Length: 738 Lines: 20 > There was no poor choice of examples, only people who didn't read the > standard carefully. the rationale for the now-absent /usr/libexec > went so far as to say: > > [...] as internal binaries migrate from /usr/lib to /usr/libexec [...] Yes, but the files mentioned in the example were never kept in /usr/lib! (modulo "cc1"). What I am contending, is that: * Some people, like myself, ignored the examples and read the cited line. We rightly voted for a libexec (or arch) that would drain /usr/lib. * Others ignored that line, read the examples, and rightly voted against a libexec that would drain /usr/sbin. Unfortunately, the people who misread the standard `won'. ---- Michael Deutschmann From list-relay@mailbox1.ucsd.edu Sat Jul 12 08:51:49 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA22884 for ; Sat, 12 Jul 1997 08:51:49 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA28132 for ; Sat, 12 Jul 1997 08:50:41 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA04724 for ; Sat, 12 Jul 1997 08:37:13 -0700 Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id IAA02218 for ; Sat, 12 Jul 1997 08:48:28 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.8.5/8.7.3) id IAA24585; Sat, 12 Jul 1997 08:47:57 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199707121547.IAA24585@GndRsh.aac.dev.com> Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: <9707112011.AA13106@sheri.orl.lmco.com> from Tom Julien at "Jul 11, 97 04:11:03 pm" To: tomj@orl.lmco.com (Tom Julien) Date: Sat, 12 Jul 1997 08:47:57 -0700 (PDT) Cc: fhs-discuss@ucsd.edu X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:18 Status: RO Content-Length: 1426 Lines: 35 ... > > I think the problem some folks have with /usr/libexec is that > it does remove indirectly executed programs from /usr/sbin. > Right or wrong, inet daemons, etc. that may have previously > existed in such places as /usr/etc now reside in /usr/sbin > on many systems. With this, it could be argued that indirectly > executed programs probably don't belong in either a "bin" or > a "lib" directory (at least by today's definitions). > > A number of issues wrt libexec were indeed beaten to death > two years ago, and I can understand the frustration of BSD > and GNU. > Is there anything we can discuss that might > overcome this stalemate? I don't know if it'll help, but > I'd like to recap a few points at a later time, and see if > we can at least reach a compromise for the future... Make /usr/libexec a ``may'' exist, and then state ``if'' it exists it shall contain ``blah blah'' and /usr/lib and /usr/sbin shall not contain ``blah blah''. Also perhaps a ``recommendation'' that systems start to migrate over time to this configuration using the rational that was layed out before. Same goes for libdata. This would allow a BSD or GNU system to atleast be ``compliant'' without a major exception in this area. There.. how's that for a compromise... -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From list-relay@mailbox2.ucsd.edu Sun Jul 13 20:02:52 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id SAA27270 for ; Sun, 13 Jul 1997 18:48:33 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id SAA19125 for ; Sun, 13 Jul 1997 18:47:26 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id SAA15093 for ; Sun, 13 Jul 1997 18:33:46 -0700 Received: from wuff.mayn.de (wuff.mayn.de [194.95.209.17]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id SAA22689 for ; Sun, 13 Jul 1997 18:45:16 -0700 (PDT) Received: by wuff.mayn.de via sendmail with stdio id for fhs-discuss@ucsd.edu; Mon, 14 Jul 1997 03:45:09 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #1 built DST-Jun-10) Message-Id: From: bwarken@wuff.mayn.de (Bernd Warken) Subject: Vote for /usr/libexec To: fhs-discuss@ucsd.edu Date: Mon, 14 Jul 1997 03:45:09 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:19 Status: RO Content-Length: 1345 Lines: 38 I followed the discussion on /usr/libexec. Here is my decision: I vote in favor of using /usr/libexec for FHS. Practical reasons: - The idea behind /usr/libexec might be inspiring, e.g. it would be quite straightforward to write a better dialog-based Debian installation tool instead of the mediaeval dselect - shell subroutines for such a project would be optimally suited for /usr/libexec - /usr/libexec will gain more power in the future, when more and more applications will take over Linux rather than system administration - hence within some years it will mentally clean-up /usr/lib rather than /usr/sbin as it might seem to some people today - but even reducing /usr/sbin is helpful for working within the shell: $PATH, file name completion, hash, etc. Strong reasons: - The concept behind /usr/libexec is already a standard for us - for it is heavily used by the GNU autoconfigure scheme, cf. emacs. Thinking the Linux way originated from thinking GNU, so there is no reason to separate the child from its mother. - Free software has always been a superset of existing standards The success of Linus with his free operating system has been based on two concepts: quick decisions with a wise correction scheme and an open heart for all. So my vote is a clear "yes" to /usr/libexec. Bye Bernd Warken (bwarken@mayn.de) From list-relay@mailbox2.ucsd.edu Mon Jul 14 12:05:52 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id MAA28703 for ; Mon, 14 Jul 1997 12:05:51 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id MAA03109 for ; Mon, 14 Jul 1997 12:04:44 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA20860 for ; Mon, 14 Jul 1997 11:50:57 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id KAA28547 for ; Mon, 14 Jul 1997 10:37:31 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id NAA06778; Mon, 14 Jul 1997 13:37:22 -0400 (EDT) Date: Mon, 14 Jul 1997 13:37:22 -0400 (EDT) Message-Id: <199707141737.NAA06778@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: ldeutsch@mail.netshop.net CC: fhs-discuss@ucsd.edu In-reply-to: ldeutsch@mail.netshop.net's message of Thu, 10 Jul 1997 15:51:43 -0800 <199707102251.PAA15075@freya.van.hookup.net> Subject: Re: Results of straw poll regarding /usr/libexec X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "Finish titrating that solution," Tom said in a balanced tone. Xref: sodium.transmeta.com linux.fhs:20 Status: RO Content-Length: 1033 Lines: 27 From: ldeutsch@mail.netshop.net Date: Thu, 10 Jul 1997 15:51:43 -0800 > Please make sure the standard notes that it doesn't really address BSD > [...] > not if we have to take big steps backwards in the process. As the other person who voted for libdata, I'm aghast at the results too. But here you just sound like a sore loser. We cannot ignore a democratic defeat this decisive. This is a standard, not a government. The choice is consistently made to have this standard reflect Linux usage, only, and very conservatively, with no or little understanding of the existing practice of other systems. I'm asking that the standard explicitly reflect its narrow focus. It had been hoped that fsstnd could be of use to many system designers, but I am beginning to despair. The world still need a document that describes the layouts in use by most systems. fsstnd simply is not that now, and if the recent poll determines the future shape of the standard, then fsstnd won't be in the future. Thomas From list-relay@mailbox2.ucsd.edu Mon Jul 14 12:16:25 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id MAA28967 for ; Mon, 14 Jul 1997 12:16:24 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id MAA03457 for ; Mon, 14 Jul 1997 12:15:17 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id MAA20955 for ; Mon, 14 Jul 1997 12:01:30 -0700 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id MAA06568 for ; Mon, 14 Jul 1997 12:13:26 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA18915; Mon, 14 Jul 97 15:12:04 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id PAA26696; Mon, 14 Jul 1997 15:13:08 -0400 Date: Mon, 14 Jul 1997 15:13:08 -0400 Message-Id: <199707141913.PAA26696@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: thomas@gnu.ai.mit.edu Cc: ldeutsch@mail.netshop.net, fhs-discuss@UCSD.EDU In-Reply-To: Thomas Bushnell, n/BSG's message of Mon, 14 Jul 1997 13:37:22 -0400 (EDT), <199707141737.NAA06778@churchy.gnu.ai.mit.edu> Subject: Re: Results of straw poll regarding /usr/libexec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:21 Status: RO Content-Length: 1533 Lines: 33 Date: Mon, 14 Jul 1997 13:37:22 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) The world still need a document that describes the layouts in use by most systems. fsstnd simply is not that now, and if the recent poll determines the future shape of the standard, then fsstnd won't be in the future. I think the real problem is that not everyone had the same goals and expectations of the FSSTND. The FSSTND's original goal was to keep Linux (user-land) programs portable across different Linux distributions. As such, the FSSTND was proscriptive, not descriptive. At least some of the people who wanted to make the FSSTND span multiple OS's had the same goal --- make Unix user-land programs more portable across various free OS's. However, in order to make this work, it required discussion and compromise from all concerned. This was made especially hard because there were often rather philosophical and design differences between in the various camps. Now, Thomas, you've talked about wanting a document which is descriptive, not proscriptive, and that to me strikes at the heart of the problem. It implies that the people who come representing various's are either are not willing (or are not empowered) to make changes to how their OS does things. That is, the expectation is that the OS won't change; the text of the FSSTND instead must change to meet the way THEY do business. With this difference in expectations, I don't see how we could ever come to consensus. - Ted From list-relay@mailbox1.ucsd.edu Mon Jul 14 13:55:12 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id NAA02035 for ; Mon, 14 Jul 1997 13:55:11 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id NAA07333 for ; Mon, 14 Jul 1997 13:53:58 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id NAA21615 for ; Mon, 14 Jul 1997 13:40:10 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id NAA02138 for ; Mon, 14 Jul 1997 13:49:31 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id QAA07542; Mon, 14 Jul 1997 16:49:25 -0400 (EDT) Date: Mon, 14 Jul 1997 16:49:25 -0400 (EDT) Message-Id: <199707142049.QAA07542@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: tytso@mit.edu CC: ldeutsch@mail.netshop.net, fhs-discuss@UCSD.EDU In-reply-to: "Theodore Y. Ts'o"'s message of Mon, 14 Jul 1997 15:13:08 -0400 <199707141913.PAA26696@dcl.MIT.EDU> Subject: Re: Results of straw poll regarding /usr/libexec X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "Don't forget to shut down the computer," Tom said haltingly. Xref: sodium.transmeta.com linux.fhs:22 Status: RO Content-Length: 1004 Lines: 23 Date: Mon, 14 Jul 1997 15:13:08 -0400 From: "Theodore Y. Ts'o" Now, Thomas, you've talked about wanting a document which is descriptive, not proscriptive, and that to me strikes at the heart of the problem. It implies that the people who come representing various's are either are not willing (or are not empowered) to make changes to how their OS does things. That is, the expectation is that the OS won't change; the text of the FSSTND instead must change to meet the way THEY do business. What I want is somewhere in between description and proscription. Neither is right; rather, what we need is a spirit of cooperation and compromise. In general, what I've met with is a very heavy level of conservativism on the part of the Linux folks. Many people already left this list because of that. Reducing functionality is not, however, one of my goals; some changes are ones which reduce functionality. Dropping libexec would be one such change. Thomas From list-relay@mailbox1.ucsd.edu Mon Jul 14 14:12:46 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id OAA02604 for ; Mon, 14 Jul 1997 14:12:45 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id OAA07865 for ; Mon, 14 Jul 1997 14:11:38 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id NAA21711 for ; Mon, 14 Jul 1997 13:57:49 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id OAA03538 for ; Mon, 14 Jul 1997 14:09:33 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id RAA03337; Mon, 14 Jul 1997 17:15:00 -0400 From: "Eric S. Raymond" Message-Id: <199707142115.RAA03337@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: thomas@gnu.ai.mit.edu (Thomas Bushnell n/BSG) Date: Mon, 14 Jul 1997 17:14:59 -0400 (EDT) Cc: ldeutsch@mail.netshop.net, fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu In-Reply-To: <199707141737.NAA06778@churchy.gnu.ai.mit.edu> from "Thomas Bushnell, n/BSG" at Jul 14, 97 01:37:22 pm Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:23 Status: RO Content-Length: 2208 Lines: 46 Thomas Bushnell: > This is a standard, not a government. The choice is consistently made > to have this standard reflect Linux usage, only, and very > conservatively, with no or little understanding of the existing > practice of other systems. > > I'm asking that the standard explicitly reflect its narrow focus. It > had been hoped that fsstnd could be of use to many system designers, > but I am beginning to despair. > > The world still need a document that describes the layouts in use by > most systems. fsstnd simply is not that now, and if the recent poll > determines the future shape of the standard, then fsstnd won't be in > the future. I, too, am concerned about this. As the person who instigated the effort to have the scope of the standard widened to include all free Unixes and to have BSD and HURD people included in the deliberations, I am distressed that they seem to feel they've been shut out and shouted down. This is certainly not the effect *I* intended. But perhaps the situation is not quite as bad as it seems. I know we've moved to /var/mail rather than the traditional Linux /var/spool/mail. Dan, can you name any other specific changes we have made to accomodate BSD or GNU practice? If we in the Linux camp really have completely stepped on everyone else's corns, then I say shame on us. We shouldn't be blindly defending territory -- we should be exerting ourself, going out of our way and (yes) accepting some incompatibility with pre-existing practice in order to build bridges with (especially) the BSD folk. Only in that will the FHS live up to its promise as a standard *everyone* is willing to use, and the interests of the *entire* free-Unix community be fairly served. I'll grant that it's probably too late to do much about this for 2.0. But I'd like to see a list from the BSD people of what their biggest problem issues are with FHS as it stands. And then, by damn, I want to see some effort from this group to meet them halfway! In the medium to long term, accepting a little pain now to make the FHS a truly cross-OS standard is the best way we can serve Linux's own constituency. -- Eric S. Raymond From list-relay@mailbox1.ucsd.edu Mon Jul 14 14:26:43 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id OAA03014 for ; Mon, 14 Jul 1997 14:26:42 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id OAA08376 for ; Mon, 14 Jul 1997 14:25:35 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id OAA21825 for ; Mon, 14 Jul 1997 14:11:46 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id OAA04740 for ; Mon, 14 Jul 1997 14:23:56 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA14064; Mon, 14 Jul 97 17:23:52 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id RAA26769; Mon, 14 Jul 1997 17:23:52 -0400 Date: Mon, 14 Jul 1997 17:23:52 -0400 Message-Id: <199707142123.RAA26769@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: thomas@gnu.ai.mit.edu Cc: ldeutsch@mail.netshop.net, fhs-discuss@UCSD.EDU In-Reply-To: Thomas Bushnell, n/BSG's message of Mon, 14 Jul 1997 16:49:25 -0400 (EDT), <199707142049.QAA07542@churchy.gnu.ai.mit.edu> Subject: Re: Results of straw poll regarding /usr/libexec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:24 Status: RO Content-Length: 1778 Lines: 40 Date: Mon, 14 Jul 1997 16:49:25 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) What I want is somewhere in between description and proscription. Neither is right; rather, what we need is a spirit of cooperation and compromise. In general, what I've met with is a very heavy level of conservativism on the part of the Linux folks. Many people already left this list because of that. Reducing functionality is not, however, one of my goals; some changes are ones which reduce functionality. Dropping libexec would be one such change. Thomas, at the same time that you say the first paragraph, you demonstrate in the very next paragraph that you yourself have certain issues where you're not willing to budge at all. So perhaps this "heavy level of conservatism" isn't all one one side. The bottom line is how much is it worth it to people to make it easy to make Unix programs portable across different OS's, and how much kludge work do you need to do in Makefiles, autoconf, Imakefiles, etc. for each OS's own special idiosyncracies. How much are people willing to bend in order to reach this goal? Perhaps for many people it's not worth it, because we already have tools (like autoconf, Imake, etc.) to solve these very problems. Certainly there are days when I ask myself whether it is worth it to get FreeBSD, Linux, the Hurd, etc. to converge. On the other side of the argument, there are those who argue that while we have tools which deal with these differences, they are still a pain to use, and it is these differences which give Microsoft a heavy advantage over the fractured Unix environments. I expect there's truth in both viewpoints, and it's merely a matter of where your priorities lie. - Ted From list-relay@mailbox1.ucsd.edu Mon Jul 14 15:37:15 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id PAA05702 for ; Mon, 14 Jul 1997 15:37:15 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id PAA11048 for ; Mon, 14 Jul 1997 15:36:07 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id PAA22311 for ; Mon, 14 Jul 1997 15:22:19 -0700 Received: from wauug.erols.com (wauug.erols.com [207.96.122.8]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id PAA09138 for ; Mon, 14 Jul 1997 15:34:24 -0700 (PDT) Received: from localhost (niemi@localhost) by wauug.erols.com (8.8.5/8.8.5) with SMTP id SAA30201 for ; Mon, 14 Jul 1997 18:34:14 -0400 Date: Mon, 14 Jul 1997 18:34:14 -0400 (EDT) From: David C Niemi To: fhs-discuss@UCSD.EDU Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: <199707142115.RAA03337@snark.thyrsus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:25 Status: RO Content-Length: 1449 Lines: 27 It seems to me the whole concept of a straw poll on an issue that touches at all on a BSD-practice vs. Linux-practice discrepancy is probably a bit flawed. Unless you have very similar numbers from each constituency, the whole vote may be determined wholly by the masses and some very important viewpoints from those most impacted by the change may end up not being heard. At a minimum the demographics of the users who voted would have to be watched very carefully. I'm not sure how to accomplish that without a lot more of a formal process, but I might suggest that the BSD and Linux groups separately and informally decide their own "party lines" on the more contentious issues, which can then be reconciled as needed; rather than having anything like a "joint vote" which I don't see as being terribly fair or meaningful. If the two party lines cannot be reconciled, it is time to use the Linux Annex or the BSD Annex to hold those parts which are not really jointly standardized. Getting consensus out of the Linux group will still be quite a challenge as always, but at least this would automate dispute resolution between the two camps to a greater degree. David Niemi@erols.com 703-810-5538 Reston, Virginia, USA --- Most operating systems, sometimes even DOS, separate different --- types of files into different directories. The Windows philosophy: --- Throw everything into C:\WINDOWS and let God sort it out. From list-relay@mailbox2.ucsd.edu Mon Jul 14 17:48:52 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id RAA10426 for ; Mon, 14 Jul 1997 17:48:51 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id RAA14319 for ; Mon, 14 Jul 1997 17:47:43 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id RAA23280 for ; Mon, 14 Jul 1997 17:33:54 -0700 Received: from wwwfw01.qantas.com.au (wwwfw01.qantas.com.au [139.163.82.1]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id RAA01876 for ; Mon, 14 Jul 1997 17:46:02 -0700 (PDT) Received: (from smap@localhost) by wwwfw01.qantas.com.au id KAA24369 (8.8.5/IDA-1.6 for ); Tue, 15 Jul 1997 10:49:37 +1000 (EST) Received: from iissv01.qantas.com.au(139.163.105.35) by wwwfw01.qantas.com.au via smap (V1.3) id ./smaAAAa005wc; Tue Jul 15 10:49:11 1997 Received: from usssv01.qantas.com.au (usssv01.qantas.com.au [139.163.103.29]) by iissv01.qantas.com.au with ESMTP id KAA04975 (8.8.5/IDA-1.6 for ); Tue, 15 Jul 1997 10:40:41 +1000 (CUT) Received: from usssv01.qantas.com.au (localhost [127.0.0.1]) by usssv01.qantas.com.au with ESMTP id KAA13554 (8.7.5/IDA-1.6 for ); Tue, 15 Jul 1997 10:43:05 +1000 (EST) Message-ID: <199707150043.KAA13554@usssv01.qantas.com.au> To: fhs-discuss@UCSD.EDU Subject: Re: Results of straw poll regarding /usr/libexec In-reply-to: Your message of "Mon, 14 Jul 1997 17:23:52 -0400." <199707142123.RAA26769@dcl.MIT.EDU> Date: Tue, 15 Jul 1997 10:43:05 +1000 From: Matthew Hannigan Xref: technetium.transmeta.com linux.fhs:26 Status: RO Content-Length: 861 Lines: 20 "Theodore Y. Ts'o" writes in part > The bottom line is how much is it worth it to people to make it easy to > make Unix programs portable across different OS's, and how much kludge > work do you need to do in Makefiles, autoconf, Imakefiles, etc. for each > OS's own special idiosyncracies. How much are people willing to bend in > order to reach this goal? And which OS's do they want to bend towards most. I think that has something to with it. My personal preference and I presume a lot of others who work with 'commercial' OS's would prefer something like SVR4 with the worst bits avoided. Unless we can got strong (almost identical) layout between all the sort of machines then I don't think there is much point in compromise unless you can rid yourself of almost all autoconf/Makefile pathname considerations. -- -Matt Hannigan From list-relay@mailbox1.ucsd.edu Mon Jul 14 17:50:49 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id RAA10472 for ; Mon, 14 Jul 1997 17:50:49 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id RAA14351 for ; Mon, 14 Jul 1997 17:49:41 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id RAA23301 for ; Mon, 14 Jul 1997 17:35:51 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id RAA16314 for ; Mon, 14 Jul 1997 17:48:20 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA09423; Mon, 14 Jul 97 20:48:14 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id UAA26808; Mon, 14 Jul 1997 20:48:14 -0400 Date: Mon, 14 Jul 1997 20:48:14 -0400 Message-Id: <199707150048.UAA26808@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Eric S. Raymond" Cc: thomas@gnu.ai.mit.edu, ldeutsch@mail.netshop.net, fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu In-Reply-To: Eric S. Raymond's message of Mon, 14 Jul 1997 17:14:59 -0400 (EDT), <199707142115.RAA03337@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: technetium.transmeta.com linux.fhs:27 Status: RO Content-Length: 1259 Lines: 27 From: "Eric S. Raymond" Date: Mon, 14 Jul 1997 17:14:59 -0400 (EDT) If we in the Linux camp really have completely stepped on everyone else's corns, then I say shame on us. We shouldn't be blindly defending territory -- we should be exerting ourself, going out of our way and (yes) accepting some incompatibility with pre-existing practice in order to build bridges with (especially) the BSD folk. Only in that will the FHS live up to its promise as a standard *everyone* is willing to use, and the interests of the *entire* free-Unix community be fairly served. As long as *everybody* from *all* of the OS's are willing to do this, then we have a chance. But if everyone simply wants a standard that blesses the way the currently do things, it's hopeless. The Linux folks have been willing to move on some items; witness /var/mail. But if you go into a negotiation assuming that the Linux folks have to yield on *every* item, then any items where the other side doesn't yield, you will see them as being "recalcitrant". Especially when you're convinced that you're right and the only reason why they aren't falling to the brilliance of your technical argument is stubborness...... - Ted From list-relay@mailbox2.ucsd.edu Mon Jul 14 18:42:31 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id SAA11873 for ; Mon, 14 Jul 1997 18:42:31 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id SAA15901 for ; Mon, 14 Jul 1997 18:41:22 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id SAA23650 for ; Mon, 14 Jul 1997 18:27:33 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id SAA04375 for ; Mon, 14 Jul 1997 18:40:09 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id VAA04725 for fhs-discuss@ucsd.edu; Mon, 14 Jul 1997 21:41:36 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id VAA00442 for ; Mon, 14 Jul 1997 21:25:21 -0400 Message-Id: <199707150125.VAA00442@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Mon, 14 Jul 97 21:25:24 -0400 To: FHS discussion list In-Reply-To: <199707150043.KAA13554@usssv01.qantas.com.au> Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: technetium.transmeta.com linux.fhs:28 Status: RO Content-Length: 615 Lines: 16 In <199707150043.KAA13554@usssv01.qantas.com.au>, on 07/15/97 at 10:43 AM, Matthew Hannigan said: +----- | something to with it. My personal preference and I presume a lot of others | who work with 'commercial' OS's would prefer something like SVR4 with the | worst bits avoided. +--->8 If, that is, you can get some consensus as to which are the "worst bits". -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox1.ucsd.edu Mon Jul 14 18:42:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id SAA11877 for ; Mon, 14 Jul 1997 18:42:35 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id SAA15907 for ; Mon, 14 Jul 1997 18:41:27 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id SAA23655 for ; Mon, 14 Jul 1997 18:27:38 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id SAA18349 for ; Mon, 14 Jul 1997 18:40:14 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id VAA04742 for fhs-discuss@ucsd.edu; Mon, 14 Jul 1997 21:41:42 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id VAA00456 for ; Mon, 14 Jul 1997 21:29:26 -0400 Message-Id: <199707150129.VAA00456@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Mon, 14 Jul 97 21:27:30 -0400 To: FHS discussion list In-Reply-To: <199707150048.UAA26808@dcl.MIT.EDU> Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: technetium.transmeta.com linux.fhs:29 Status: RO Content-Length: 729 Lines: 18 In <199707150048.UAA26808@dcl.MIT.EDU>, on 07/14/97 at 08:48 PM, "Theodore Y. Ts'o" said: +----- | As long as *everybody* from *all* of the OS's are willing to do this, then | we have a chance. But if everyone simply wants a standard that blesses the | way the currently do things, it's hopeless. +--->8 But there will always be those who prefer "their" way. Not to mention those who feel they're all rotten and think FSSTND/FHS is the ideal vehicle to promote an alternative.... -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Mon Jul 14 19:24:03 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id TAA12685 for ; Mon, 14 Jul 1997 19:11:44 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id TAA16418 for ; Mon, 14 Jul 1997 19:10:36 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id SAA23838 for ; Mon, 14 Jul 1997 18:56:47 -0700 Received: from freya.van.hookup.net (freya.van.hookup.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id TAA05494 for ; Mon, 14 Jul 1997 19:09:45 -0700 (PDT) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (kamloops-4.netshop.net [207.102.173.101]) by freya.van.hookup.net (8.8.5/1.25) with SMTP id TAA31736 for ; Mon, 14 Jul 1997 19:09:43 -0700 (PDT) Message-Id: <199707150209.TAA31736@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Mon, 14 Jul 1997 19:09:32 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Proposal for new poll Priority: normal X-mailer: Pegasus Mail for Windows (v2.54) Xref: technetium.transmeta.com linux.fhs:30 Status: RO Content-Length: 806 Lines: 22 I'd like to propose a new poll: 1. Place init/inetd programs in /usr/sbin, subprograms in /usr/lib. 2. Place init/inetd programs in /usr/sbin, subprograms in /usr/libexec. 3. Place init/inetd programs and subprograms in /usr/libexec. I think what happened in the last poll is it was effectively argued (by myself, ironically) that option 3 has a significant technical flaw - whether a daemon is executed by init/inetd or by a shell script can depend on context not known to the packager. People killed libexec because they didn't want to be seen as implicitly endorsing 3 (even if they prefer 2 to 1). If my theory is correct, Option 2 should prove most popular. If I'm wrong and it's only Linux conservatism, Option 1 should win again. ---- Michael Deutschmann From list-relay@mailbox2.ucsd.edu Mon Jul 14 19:52:56 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id TAA13747 for ; Mon, 14 Jul 1997 19:52:55 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id TAA17048 for ; Mon, 14 Jul 1997 19:51:48 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id TAA24093 for ; Mon, 14 Jul 1997 19:37:58 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id TAA07085 for ; Mon, 14 Jul 1997 19:50:35 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id WAA04511; Mon, 14 Jul 1997 22:00:42 -0400 From: "Eric S. Raymond" Message-Id: <199707150200.WAA04511@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: niemi@wauug.erols.com (David C Niemi) Date: Mon, 14 Jul 1997 22:00:42 -0400 (EDT) Cc: fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu In-Reply-To: from "David C Niemi" at Jul 14, 97 06:34:14 pm Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: technetium.transmeta.com linux.fhs:31 Status: RO Content-Length: 1339 Lines: 24 David C. Niemi: > It seems to me the whole concept of a straw poll on an issue that touches > at all on a BSD-practice vs. Linux-practice discrepancy is probably a bit > flawed. Unless you have very similar numbers from each constituency, the > whole vote may be determined wholly by the masses and some very important > viewpoints from those most impacted by the change may end up not being > heard. At a minimum the demographics of the users who voted would have to > be watched very carefully. > > I'm not sure how to accomplish that without a lot more of a formal process, > but I might suggest that the BSD and Linux groups separately and informally > decide their own "party lines" on the more contentious issues, which can > then be reconciled as needed; rather than having anything like a "joint > vote" which I don't see as being terribly fair or meaningful. If the two > party lines cannot be reconciled, it is time to use the Linux Annex or the > BSD Annex to hold those parts which are not really jointly standardized. I agree with this proposal. Perhaps both crews can find acceptable coordinator/ spokespeople. Anybody want to nominate for either camp? My choices would be Ted T'so for Linux and Keith Bostic for BSD, if we can get Keith to be active again. -- Eric S. Raymond From list-relay@mailbox1.ucsd.edu Tue Jul 15 01:51:20 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id BAA21197 for ; Tue, 15 Jul 1997 01:51:20 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id BAA22146 for ; Tue, 15 Jul 1997 01:50:12 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id BAA26191 for ; Tue, 15 Jul 1997 01:36:20 -0700 Received: from wfdutilgw.ml.com (wfdutilf01.ml.com [206.3.74.31]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id BAA00623 for ; Tue, 15 Jul 1997 01:48:33 -0700 (PDT) Received: from ml1.ml.com ([199.201.57.130]) by wfdutilgw.ml.com (8.8.5/8.8.5/MLgw-3.03) with ESMTP id EAA17952; Tue, 15 Jul 1997 04:44:09 -0400 (EDT) Received: from mleu1.euro.ml.com (mleu1.euro.ml.com [131.208.157.89]) by ml1.ml.com (8.8.5/8.8.5/MLml4-2.07) with ESMTP id EAA23838; Tue, 15 Jul 1997 04:47:48 -0400 (EDT) Received: from swype.bolon.uk.ml.com (swype.bolon.uk.ml.com [131.208.231.14]) by mleu1.euro.ml.com (8.7.3/8.7.3/MLdomain-2.02) with SMTP id JAA23894; Tue, 15 Jul 1997 09:48:12 +0100 (BST) Received: from isengard.uk.ml.com by swype.bolon.uk.ml.com (4.1/ML41S-1.03) id AA27180; Tue, 15 Jul 97 09:48:09 BST Received: from isengard.uk.ml.com (localhost [127.0.0.1]) by isengard.uk.ml.com (8.8.5/8.8.5) with ESMTP id JAA07287; Tue, 15 Jul 1997 09:48:08 +0100 Message-Id: <199707150848.JAA07287@isengard.uk.ml.com> To: "Eric S. Raymond" Cc: fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu, niemi@wauug.erols.com (David C Niemi) Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: Your message of "Mon, 14 Jul 1997 22:00:42 EDT." <199707150200.WAA04511@snark.thyrsus.com> Date: Tue, 15 Jul 1997 09:48:07 +0100 From: Tethys Xref: technetium.transmeta.com linux.fhs:32 Status: RO Content-Length: 976 Lines: 21 >I agree with this proposal. Perhaps both crews can find acceptable >coordinator/ spokespeople. Anybody want to nominate for either camp? >My choices would be Ted T'so for Linux and Keith Bostic for BSD, if we >can get Keith to be active again. Yep, I'd agree with that. Because of the Linux origins, I'd expect BSD and HURD people to be vastly outnumbered here. The majority are often wrong, but that democracy for you. As someone once said, democracy is four wolves and a sheep deciding on what's for dinner... Tet -- ``There appear to be few if any technical reasons to move from UNIX to Windows NT. The performance of Linux exceeds that of NT 4.0 and Linux appears to be more reliable.'' -- David Korn, AT&T, author of ksh --------------------+--------------+---------------------------------------- tethys@ml.com | Micro$oft: | Linux, the choice of a GNU generation. tet@astradyne.co.uk | Just say no! | See http://www.uk.linux.org for details From list-relay@mailbox2.ucsd.edu Tue Jul 15 02:24:03 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id CAA21784 for ; Tue, 15 Jul 1997 02:20:22 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id CAA22383 for ; Tue, 15 Jul 1997 02:19:13 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id CAA26346 for ; Tue, 15 Jul 1997 02:05:21 -0700 Received: from yama.mcc.ac.uk (yama.mcc.ac.uk [130.88.203.29]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id CAA19644 for ; Tue, 15 Jul 1997 02:15:54 -0700 (PDT) Received: from afs.mcc.ac.uk (actually cfs2.mcc.ac.uk) by yama.mcc.ac.uk with SMTP (PP); Tue, 15 Jul 1997 10:15:38 +0100 Message-Id: <9817.9707150915@afs.mcc.ac.uk> Subject: Re: Proposal for new poll To: fhs-discuss@ucsd.edu Date: Tue, 15 Jul 1997 10:15:32 +0100 (BST) Reply-To: LeBlanc@mcc.ac.uk From: LeBlanc@mcc.ac.uk X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: technetium.transmeta.com linux.fhs:33 Status: RO Content-Length: 1645 Lines: 35 Michael Deutschmann wrote: > I'd like to propose a new poll: > > 1. Place init/inetd programs in /usr/sbin, subprograms in /usr/lib. > > 2. Place init/inetd programs in /usr/sbin, subprograms in > /usr/libexec. > > 3. Place init/inetd programs and subprograms in > /usr/libexec. I'd like to see a somewhat different option as well. As a linux user, I rather like the idea of /usr/libexec, but I don't want necessarily to see it crammed down people's throats. Is it not possible to recommend the existence of /usr/libexec (since much software source already assumes that it exists), and suggest what might or might not go there. Then, after the standard has been out for a while, we might see how much people make use of the directory. Distributions whose maintainers dislike having executables in /usr/lib, or having internal binaries in /usr/sbin, or whatever, will fill /usr/libexec, and perhaps others will leave it empty. Then the next time the standard is due for revision, we shall see how things stand. I like the notion of /usr/libexec because I think it is a good idea for cleaning up the file system. I dislike the notion of saying that the way (almost) every Linux distribution does things is wrong. We renamed the LFSStnd to the FHS because we wanted to make it apply to, and appeal to, systems other than Linux. This means it can't always be based on Linux practice. It needs to be slightly innovative at times, and rather conservative at times. And, I feel, it need not always speak as if it is entirely certain what decision is best for all time. -- Owen LeBlanc@mcc.ac.uk From list-relay@mailbox2.ucsd.edu Tue Jul 15 08:54:35 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA28921 for ; Tue, 15 Jul 1997 08:54:34 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA27065 for ; Tue, 15 Jul 1997 08:53:26 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA28554 for ; Tue, 15 Jul 1997 08:39:28 -0700 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id IAA02003 for ; Tue, 15 Jul 1997 08:47:46 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA26394; Tue, 15 Jul 97 11:46:26 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id LAA26897; Tue, 15 Jul 1997 11:47:38 -0400 Date: Tue, 15 Jul 1997 11:47:38 -0400 Message-Id: <199707151547.LAA26897@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: ldeutsch@mail.netshop.net Cc: fhs-discuss@ucsd.edu In-Reply-To: ldeutsch@mail.netshop.net's message of Mon, 14 Jul 1997 19:09:32 -0800, <199707150209.TAA31736@freya.van.hookup.net> Subject: Re: Proposal for new poll Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: technetium.transmeta.com linux.fhs:34 Status: RO Content-Length: 1949 Lines: 45 From: ldeutsch@mail.netshop.net Date: Mon, 14 Jul 1997 19:09:32 -0800 1. Place init/inetd programs in /usr/sbin, subprograms in /usr/lib. 2. Place init/inetd programs in /usr/sbin, subprograms in /usr/libexec. 3. Place init/inetd programs and subprograms in /usr/libexec. I'll go along with 2, although with the exception of /usr/lib/sendmail (which *will* require a compatibility symlink, and probably for quite some time), and possibly /usr/lib/cpp (although that's in general not so critical), it really doesn't matter where the init/inetd and subprograms go. As far as I concerned, the most important thing is inter-package interoperability. Most subprograms (like cc1, etc.) are only called by one program, so why force where they go? And consider that for complicated packages, like gcc, you need to somehow package up not just the subprogram but also header files and libraries, some of which are compiler specific. (i.e., everything that's currently stored in /usr/lib/gcc-lib///*. I believe there's no value in trying to legislate how some package such as GCC locates its internal programs, data files, etc. There may be all sorts of considerations (such has cross-compiler support, etc.) that won't be handled by a simplistic rule that we try to put in FSSTND. The big difference is with those programs which export an *interface* to rest of the systems, with the prime examples being /usr/lib/sendmail, /usr/lib/inews, etc. For those, it's fair for us to specify where they should go, and if there is significant historical precedence for them living in other directories, specifying backwards compatibility symlinks is probably a very good idea. But as for where init/inetd and most subprograms go, forgive me but I can't get excited about such things. In fact, there's a large set of these programs where I don't think we should anything about where they go at all. - Ted From list-relay@mailbox2.ucsd.edu Tue Jul 15 08:55:03 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA28934 for ; Tue, 15 Jul 1997 08:55:02 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA27078 for ; Tue, 15 Jul 1997 08:53:54 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA28570 for ; Tue, 15 Jul 1997 08:39:59 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id IAA02271 for ; Tue, 15 Jul 1997 08:51:54 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA06147; Tue, 15 Jul 97 11:51:50 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id LAA26901; Tue, 15 Jul 1997 11:51:45 -0400 Date: Tue, 15 Jul 1997 11:51:45 -0400 Message-Id: <199707151551.LAA26901@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Eric S. Raymond" Cc: niemi@wauug.erols.com, fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu In-Reply-To: Eric S. Raymond's message of Mon, 14 Jul 1997 22:00:42 -0400 (EDT), <199707150200.WAA04511@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: technetium.transmeta.com linux.fhs:35 Status: RO Content-Length: 1265 Lines: 30 From: "Eric S. Raymond" Date: Mon, 14 Jul 1997 22:00:42 -0400 (EDT) I agree with this proposal. Perhaps both crews can find acceptable coordinator/ spokespeople. Anybody want to nominate for either camp? My choices would be Ted T'so for Linux and Keith Bostic for BSD, if we can get Keith to be active again. I'll agree only if we get buy-in from a good number of all of the right camps, which include (on the Linux side): * Linux distributers * A good fraction of the Linux folks on this list For other OS's, we also would need the equivalent buy-in from their approrpiate core communities. Also, I want us to agree in advance about what our goals are, and what the scope of our work should be. I've always been an advocate of the "less is more" school, and that the FSSTND should say the very least needed to assure interoperability between user-land application packages. (After all, that was the original point of the FSSTND.) Others have wanted the FSSTND to also dictate their own personal prejudices about how GCC lays out files for cross-platform use, etc. A lot of the arguments that we have could have been solved much more quickly if we all agreed up-front about the scope of our work. - Ted From list-relay@mailbox1.ucsd.edu Tue Jul 15 10:02:04 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA00861 for ; Tue, 15 Jul 1997 10:02:03 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA28774 for ; Tue, 15 Jul 1997 10:00:56 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA29189 for ; Tue, 15 Jul 1997 09:46:56 -0700 Received: from wfdutilgw.ml.com (wfdutilf01.ml.com [206.3.74.31]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA18313 for ; Tue, 15 Jul 1997 09:57:49 -0700 (PDT) Received: from ml1.ml.com ([199.201.57.130]) by wfdutilgw.ml.com (8.8.5/8.8.5/MLgw-3.03) with ESMTP id MAA26174; Tue, 15 Jul 1997 12:53:42 -0400 (EDT) Received: from mleu1.euro.ml.com (mleu1.euro.ml.com [131.208.157.89]) by ml1.ml.com (8.8.5/8.8.5/MLml4-2.07) with ESMTP id MAA16006; Tue, 15 Jul 1997 12:57:21 -0400 (EDT) Received: from swype.bolon.uk.ml.com (swype.bolon.uk.ml.com [131.208.231.14]) by mleu1.euro.ml.com (8.7.3/8.7.3/MLdomain-2.02) with SMTP id RAA11576; Tue, 15 Jul 1997 17:57:45 +0100 (BST) Received: from isengard.uk.ml.com by swype.bolon.uk.ml.com (4.1/ML41S-1.03) id AA14924; Tue, 15 Jul 97 17:57:44 BST Received: from isengard.uk.ml.com (localhost [127.0.0.1]) by isengard.uk.ml.com (8.8.5/8.8.5) with ESMTP id RAA13348; Tue, 15 Jul 1997 17:55:11 +0100 Message-Id: <199707151655.RAA13348@isengard.uk.ml.com> To: "Theodore Y. Ts'o" Cc: fhs-discuss@ucsd.edu Subject: Re: Proposal for new poll In-Reply-To: Your message of "Tue, 15 Jul 1997 11:47:38 EDT." <199707151547.LAA26897@dcl.MIT.EDU> Date: Tue, 15 Jul 1997 17:55:11 +0100 From: Tethys Xref: technetium.transmeta.com linux.fhs:36 Status: RO Content-Length: 1452 Lines: 32 >As far as I concerned, the most important thing is inter-package >interoperability. Most subprograms (like cc1, etc.) are only called by >one program, so why force where they go? Because otherwise we'll end up with the kind of anarchy that created the original Unix filesystem mess in the first place. >I believe there's no value in trying to legislate how some package such >as GCC locates its internal programs, data files, etc. There may be all >sorts of considerations (such has cross-compiler support, etc.) that >won't be handled by a simplistic rule that we try to put in FSSTND. If a package (such as gcc) wants to nominate /usr/lib/gcc-lib, and manage itself within that subdirectory, I say we should let it. However, what we want to avoid is some apps using a directory under /usr/lib, some under /usr/etc, others Odin only know where... It's here, IMHO, that we should provide guidance. Tet PS. I'd probably still prefer gcc to use /usr/lib{exec,data}, but there you go... -- ``There appear to be few if any technical reasons to move from UNIX to Windows NT. The performance of Linux exceeds that of NT 4.0 and Linux appears to be more reliable.'' -- David Korn, AT&T, author of ksh --------------------+--------------+---------------------------------------- tethys@ml.com | Micro$oft: | Linux, the choice of a GNU generation. tet@astradyne.co.uk | Just say no! | See http://www.uk.linux.org for details From list-relay@mailbox1.ucsd.edu Tue Jul 15 11:17:00 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA03117 for ; Tue, 15 Jul 1997 11:16:36 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA31390 for ; Tue, 15 Jul 1997 11:15:28 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA29810 for ; Tue, 15 Jul 1997 11:01:32 -0700 Received: from orl.lmco.com (theopolis.orl.mmc.com [141.240.10.10]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA23476 for ; Tue, 15 Jul 1997 11:13:17 -0700 (PDT) Received: from sunny.orl.lmco.com by orl.lmco.com (SMI-8.6/SMI-SVR4) id OAA14728; Tue, 15 Jul 1997 14:13:12 -0400 Received: from sheri.orl.lmco.com (sheri.orl.mmc.com) by sunny.orl.lmco.com (4.1/GEA Sun server 2.7) id AA06521; Tue, 15 Jul 97 14:13:10 EDT Received: from sheri (localhost.orl.lmco.com) by sheri.orl.lmco.com (4.1/1.34.a) id AA24535; Tue, 15 Jul 97 14:13:09 EDT Message-Id: <9707151813.AA24535@sheri.orl.lmco.com> X-Mailer: exmh version 1.6.7 5/3/96 From: Tom Julien To: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 14:13:09 -0400 Sender: tomj@escmail.orl.lmco.com Xref: technetium.transmeta.com linux.fhs:37 Status: RO Content-Length: 2231 Lines: 52 "Theodore Y. Ts'o" writes: [...] >At least some of the people who wanted to make the FSSTND span multiple >OS's had the same goal --- make Unix user-land programs more portable >across various free OS's. However, in order to make this work, it >required discussion and compromise from all concerned. This was made >especially hard because there were often rather philosophical and design >differences between in the various camps. [...] >the problem. It implies that the people who come representing various's >are either are not willing (or are not empowered) to make changes to how >their OS does things. That is, the expectation is that the OS won't >change; the text of the FSSTND instead must change to meet the way THEY >do business. > >With this difference in expectations, I don't see how we could ever come >to consensus. For me, this hits the nail on the head -- especially the latter. There are a number of people here that want portability and similarity across as many Unices as possible; not just free, and not just Linux, BSD, or Hurd. While this scope may require some to accept more conservative viewpoints, there should be room enough for everyone. We are going to have to be sensitive to what others have to lose, and what they are capable of changing if we are truly going to cooperate though. Wrt libexec, I think the BSD and GNU position has been clear, but I don't think we're going to get there w/o some sacrifice. With the above scope, and the fact that many commercial systems are now SVR4-like, sacrifices here may be a burden that some don't want to bear. Personally, I'd like to believe that we can reach a compromise. For now, I would like to recommend that we support Dan in releasing 2.0 as it stands, and acknowledge addressing at least the following deficiencies: 1. - indirectly executed programs 2. - host-specific data 3. - shared variable data in 2.1. A lot of new-comers have been introduced to Unix via Linux over the past several years. The new standard, despite any perceived shortcomings, is more representative of the majority of Unices than its predecessor. At a minimum, they can benefit from this release. Tom Julien From list-relay@mailbox2.ucsd.edu Tue Jul 15 11:22:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA03392 for ; Tue, 15 Jul 1997 11:22:35 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA31509 for ; Tue, 15 Jul 1997 11:21:28 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA29857 for ; Tue, 15 Jul 1997 11:07:28 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id LAA13873 for ; Tue, 15 Jul 1997 11:19:56 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id OAA27309 for fhs-discuss@ucsd.edu; Tue, 15 Jul 1997 14:21:24 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id OAA09015 for ; Tue, 15 Jul 1997 14:09:48 -0400 Message-Id: <199707151809.OAA09015@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Tue, 15 Jul 97 14:04:23 -0400 To: FHS discussion list In-Reply-To: <199707151655.RAA13348@isengard.uk.ml.com> Subject: Re: Proposal for new poll X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: technetium.transmeta.com linux.fhs:38 Status: RO Content-Length: 1403 Lines: 29 In <199707151655.RAA13348@isengard.uk.ml.com>, on 07/15/97 at 05:55 PM, Tethys said: +----- | >As far as I concerned, the most important thing is inter-package | >interoperability. Most subprograms (like cc1, etc.) are only called by | >one program, so why force where they go? | Because otherwise we'll end up with the kind of anarchy that created the | original Unix filesystem mess in the first place. +--->8 Best avoided by specifying where they *can't* put their internal files, e.g. directly in /usr/lib or /etc. Beyond that, well, just try to talk the gcc folks into moving things around. Or have another go at the "brick wall" of XFree86. It's not worth the hassle. Nor, IMHO, do you want to take the tack of "some packages are excluded from our scheme because of XXX". Who decides? (Say you choose "size of package" as the "XXX". Expect a lot of argument as to what counts as "big enough".) I'm quite sure someone will come up with arguments why they just "have" to violate whatever strict placement prescription is chosen; by comparison, a placement *pro*scription on key areas such as /usr/lib is less likely to garner such challenges. -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Tue Jul 15 11:58:28 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA04513 for ; Tue, 15 Jul 1997 11:58:28 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA32482 for ; Tue, 15 Jul 1997 11:57:20 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA30201 for ; Tue, 15 Jul 1997 11:43:24 -0700 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA16615 for ; Tue, 15 Jul 1997 11:55:37 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA06979; Tue, 15 Jul 97 14:54:18 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA27215; Tue, 15 Jul 1997 14:55:33 -0400 Date: Tue, 15 Jul 1997 14:55:33 -0400 Message-Id: <199707151855.OAA27215@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Brandon S. Allbery KF8NH" Cc: FHS discussion list In-Reply-To: Brandon S. Allbery KF8NH's message of Tue, 15 Jul 97 14:04:23 -0400, <199707151809.OAA09015@speaker.kf8nh.apk.net> Subject: Re: Proposal for new poll Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: technetium.transmeta.com linux.fhs:39 Status: RO Content-Length: 1833 Lines: 42 From: "Brandon S. Allbery KF8NH" Date: Tue, 15 Jul 97 14:04:23 -0400 Best avoided by specifying where they *can't* put their internal files, e.g. directly in /usr/lib or /etc. Beyond that, well, just try to talk the gcc folks into moving things around. Or have another go at the "brick wall" of XFree86. It's not worth the hassle. I'll make the observation that far too many of these conversations are flaws from the get-go because the people who are trying to convince the developers don't realize that *) The people who are maintaining package X are often doing so for many platforms --- often far more than will ever support FSSTND, including some commercial OS's. *) They often have real-world issues (such as GCC cross platform support) which FSSTND simply don't address. Ignoring those real-world issues don't make them go away. *) People on the FSSTND listen often get caught up in this sense of power that they can dictate terms to everyone else. Nothing could be further from the truth. Worse yet, this arrogance can often cause people to decide that you're just all flakes and they will simply ignore you. Nor, IMHO, do you want to take the tack of "some packages are excluded from our scheme because of XXX". Who decides? (Say you choose "size of package" as the "XXX". Expect a lot of argument as to what counts as "big enough".) I'm quite sure someone will come up with arguments why they just "have" to violate whatever strict placement prescription is chosen; by comparison, a placement *pro*scription on key areas such as /usr/lib is less likely to garner such challenges. You can certainly say this; just don't be shocked or annoyed when maintainers of "big" packages simply ignore you..... - Ted From list-relay@mailbox1.ucsd.edu Tue Jul 15 13:03:24 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id NAA06934 for ; Tue, 15 Jul 1997 13:03:23 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id NAA01528 for ; Tue, 15 Jul 1997 13:02:15 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id MAA30723 for ; Tue, 15 Jul 1997 12:48:17 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id NAA01037 for ; Tue, 15 Jul 1997 13:00:15 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id QAA08773; Tue, 15 Jul 1997 16:07:12 -0400 From: "Eric S. Raymond" Message-Id: <199707152007.QAA08773@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: tytso@mit.edu (Theodore Y. Ts'o) Date: Tue, 15 Jul 1997 16:07:12 -0400 (EDT) Cc: niemi@wauug.erols.com, fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu In-Reply-To: <199707151551.LAA26901@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Jul 15, 97 11:51:45 am Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: technetium.transmeta.com linux.fhs:40 Status: RO Content-Length: 3153 Lines: 73 Ted T'so: > I'll agree only if we get buy-in from a good number of all of the right > camps, which include (on the Linux side): > > * Linux distributers > * A good fraction of the Linux folks on this list > > For other OS's, we also would need the equivalent buy-in from their > approrpiate core communities. First we need to define what the relevant "core communities" are. My choice of faction representatives would be 1 Linux core developer -- Ted T'so 1 Red Hat guy -- Erik Troan 1 Debian guy -- Bruce Perens 1 BSD core developer -- Keith Bostic 1 FreeBSD person -- ?? 1 NetBSD person -- ?? 1 HURD core developer -- Thomas Bushnell 1 list moderator -- Dan Quinlan 1 Linux/BSD bridge builder -- Eric S. Raymond All the people named have a demonstrated capacity to cooperate constructively and avoid extreme positions and pointless territoriality. That's what we need at this point. > Also, I want us to agree in advance about what our goals are, and what > the scope of our work should be. I've always been an advocate of the > "less is more" school, and that the FSSTND should say the very least > needed to assure interoperability between user-land application > packages. (After all, that was the original point of the FSSTND.) I agree with this. And so does Erik Troan, who is the key person for us to be talking with at the most important commercial Linux distributor. I had a long talk with him about FHS today. Erik and I are good friends, and he told me straight up why he isn't on the FHS/FSSTND list any more. Our noise level is too high, and our productivity is too low, because we don't have an agreed on set of goals or a conflict- resolution mechanism that accords with them. Erik fears rejoining the list would be a waste of his time and Red Hat's, unless we can agree on a charter and a decision-making method that avoids extended pissing matches. And lower our noise level. And not take literally years to grind out essentially trivial revisions. I'm good friends with Keith Bostic too, and he's told me he's gone for the same reasons. And you know what? They're both absolutely right. Our present process is not working. The flap over libexec and the bitter (and, I think, largely justified) anger of the few BSD people left is further proof. Erik thinks the FHS list ought to (a) have a formal charter describing its priorities, and (b) become moderated or invitation-only and open only to people who are actual decision-makers for the key communities. I haven't specifically asked Keith about these, but I know how he thinks about stuff likethis, and I would be utterly astonished if he disagreed. I think we ought to consider this pretty damn seriously. There are only about a dozen people who really matter in describing whether FHS is going to be reflected in reality. Erik and Keith are two of them. If we can't re-persuade those two that the FHS activity is worthwhile we might as well pack it up and go home. Dan? Are you listening? -- Eric S. Raymond From list-relay@mailbox1.ucsd.edu Tue Jul 15 13:22:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id NAA07542 for ; Tue, 15 Jul 1997 13:22:35 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id NAA02076 for ; Tue, 15 Jul 1997 13:21:27 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id NAA30865 for ; Tue, 15 Jul 1997 13:07:31 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id NAA02443 for ; Tue, 15 Jul 1997 13:19:51 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id QAA04187 for fhs-discuss@ucsd.edu; Tue, 15 Jul 1997 16:21:21 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id PAA09799 for ; Tue, 15 Jul 1997 15:49:05 -0400 Message-Id: <199707151949.PAA09799@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Tue, 15 Jul 97 15:40:43 -0400 To: FHS discussion list In-Reply-To: <199707151855.OAA27215@dcl.MIT.EDU> Subject: Re: Proposal for new poll X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: technetium.transmeta.com linux.fhs:41 Status: RO Content-Length: 1835 Lines: 35 In <199707151855.OAA27215@dcl.MIT.EDU>, on 07/15/97 at 02:55 PM, "Theodore Y. Ts'o" said: +----- | to what counts as "big enough".) I'm quite sure someone will come | up with arguments why they just "have" to violate whatever strict | placement prescription is chosen; by comparison, a placement | *pro*scription on key areas such as /usr/lib is less likely to | garner such challenges. | You can certainly say this; just don't be shocked or annoyed when | maintainers of "big" packages simply ignore you..... +--->8 Certainly, but they're a bit less likely to come up. Some commercial packages just slap their files straight into /usr/lib, but they'll ignore everyone and do what they d*mned well please anyway. OTOH most package maintainers seem to prefer /usr/lib/ anyway, which is at least marginally better and which I would consider an acceptable compromise under the circumstances. Thus, a statement like "don't put package internal files directly in /usr/lib" is preferable to "don't put package files anywhere in or under /usr/lib", which in turn is preferable to "all package-internal files must be kept under /blabla" ("preferable" in terms of achieving compromise between FHS goals and package maintainers' preferences, that is). This doesn't rule out language along the lines of "when possible, please avoid placing package-internal files somewhere under /usr/lib", BTW. Better a gentle nudge than a sledgehammer, you'll tick off fewer package developers with what they will perceive as "high-handedness" on the part of the FHS developers. -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Tue Jul 15 14:24:25 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id OAA09084 for ; Tue, 15 Jul 1997 14:24:24 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id OAA03466 for ; Tue, 15 Jul 1997 14:23:16 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id OAA31313 for ; Tue, 15 Jul 1997 14:09:20 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id OAA27162 for ; Tue, 15 Jul 1997 14:20:05 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id RAA08187 for fhs-discuss@ucsd.edu; Tue, 15 Jul 1997 17:21:34 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id QAA10255 for ; Tue, 15 Jul 1997 16:52:24 -0400 Message-Id: <199707152052.QAA10255@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Tue, 15 Jul 97 16:49:56 -0400 To: FHS discussion list In-Reply-To: <199707152007.QAA08773@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: technetium.transmeta.com linux.fhs:42 Status: RO Content-Length: 586 Lines: 17 In <199707152007.QAA08773@snark.thyrsus.com>, on 07/15/97 at 04:07 PM, "Eric S. Raymond" said: +----- | 1 BSD core developer -- Keith Bostic | 1 FreeBSD person -- ?? | 1 NetBSD person -- ?? +--->8 Do we also want to talk to BSDI, or is it too early for that? (Or am I stepping on someone's toes?) -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Tue Jul 15 14:45:46 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id OAA09678 for ; Tue, 15 Jul 1997 14:45:45 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id OAA04028 for ; Tue, 15 Jul 1997 14:44:38 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id OAA31446 for ; Tue, 15 Jul 1997 14:30:41 -0700 Received: from not-a-real-site.acsu.buffalo.edu (sc10.dreamscape.com [206.114.183.203]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id OAA29243 for ; Tue, 15 Jul 1997 14:42:30 -0700 (PDT) Message-Id: <199707152142.OAA29243@mailbox2.ucsd.edu> Received: (qmail 258 invoked from network); 15 Jul 1997 21:38:33 -0000 Received: from unknown (HELO acsu.buffalo.edu) (bmbuck@127.0.0.1) by localhost.dreamscape.com with SMTP; 15 Jul 1997 21:38:33 -0000 X-Mailer: exmh version 2.0delta 6/3/97 To: fhs-discuss@UCSD.EDU Reply-To: bmbuck@acsu.buffalo.edu Subject: Re: Results of straw poll regarding /usr/libexec In-reply-to: Your message of "Tue, 15 Jul 1997 16:07:12 EDT." <199707152007.QAA08773@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 17:37:25 -0400 From: Buddha Buck Xref: technetium.transmeta.com linux.fhs:43 Status: RO Content-Length: 2999 Lines: 68 Eric Raymond said: > First we need to define what the relevant "core communities" are. My choice > of faction representatives would be > > 1 Linux core developer -- Ted T'so > 1 Red Hat guy -- Erik Troan > 1 Debian guy -- Bruce Perens > > 1 BSD core developer -- Keith Bostic > 1 FreeBSD person -- ?? > 1 NetBSD person -- ?? > > 1 HURD core developer -- Thomas Bushnell > > 1 list moderator -- Dan Quinlan > 1 Linux/BSD bridge builder -- Eric S. Raymond > > All the people named have a demonstrated capacity to cooperate constructively > and avoid extreme positions and pointless territoriality. That's what we > need at this point. It also seems a bit unbalanced -- perhaps unavoidably so. I am firmly in the Linux faction myself (and a dedicated lurker to this list), but I see 9 representatives, one theoretically neutral (Dan), and the others divided up approximately 3.5/3.5/1 Linux/BSD/HURD. I'm afraid that the HURD's concerns might not be voiced strongly enough, with the lessened representation. > > Erik thinks the FHS list ought to (a) have a formal charter describing its > priorities, and (b) become moderated or invitation-only and open only to > people who are actual decision-makers for the key communities. I haven't > specifically asked Keith about these, but I know how he thinks about stuff > likethis, and I would be utterly astonished if he disagreed. Whatever you do, please don't make it completely closed. At the very least, make it readable to people outside of the decision-makers. I have learned a lot simply by reading the list (and others I subscribe to). I would like to continue reading, if not participating. Perhaps a reasonable possibility, if it can be set up this way, would be to have it moderated, but the key decision-makers automatically approved. If a reasonable, on-charter, comment from a non-decision-maker comes in, it can be posted. Short of that, I'd approve of moderation. Unfortunately, there seems to be no reasonable parliamentary procedure developed yet for discussions via mailing lists. Until one is developed, I'm certain that there will be continuing problems on all lists like we've been having on this one. > I think we ought to consider this pretty damn seriously. There are > only about a dozen people who really matter in describing whether FHS > is going to be reflected in reality. Erik and Keith are two of them. > If we can't re-persuade those two that the FHS activity is worthwhile we > might as well pack it up and go home. > > Dan? Are you listening? > -- > Eric S. Raymond > -- Buddha Buck bmbuck@acsu.buffalo.edu "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From list-relay@mailbox2.ucsd.edu Tue Jul 15 15:31:42 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id PAA10945 for ; Tue, 15 Jul 1997 15:31:41 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id PAA05935 for ; Tue, 15 Jul 1997 15:30:28 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id PAA31915 for ; Tue, 15 Jul 1997 15:16:31 -0700 Received: from bentley.socsci.auc.dk (bentley.socsci.auc.dk [130.225.60.48]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id PAA02761 for ; Tue, 15 Jul 1997 15:29:00 -0700 (PDT) Received: from jaguar.socsci.auc.dk (jaguar.socsci.auc.dk [130.225.60.49]) by bentley.socsci.auc.dk (8.8.5/8.7.1) with ESMTP id AAA30304; Wed, 16 Jul 1997 00:28:53 +0200 Received: (from mkp@localhost) by jaguar.socsci.auc.dk (8.8.5/8.6.12) id AAA21342; Wed, 16 Jul 1997 00:25:16 +0200 To: "Eric S. Raymond" Cc: tytso@mit.edu (Theodore Y. Ts'o), niemi@wauug.erols.com, fhs-discuss@UCSD.EDU, bostic@cs.berkeley.edu Subject: Re: Results of straw poll regarding /usr/libexec References: <199707152007.QAA08773@snark.thyrsus.com> Organization: Computing Dept. 1&2, Aalborg University Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Charset: Latin-1 X-Face: ({%T;F${m<}wr[*K`gT|vs1m&kDfl(^PsxTnmb)FL4!_$=dj|NG~.SNrq-qxsT]}i>DP.("XEmucViR>9iEl?,!C1 2p,ST@1)zEW+Kb'iJ,c6~O`BWjCoY42jmV From: Martin Kasper Petersen Date: 16 Jul 1997 00:25:15 +0200 In-Reply-To: "Eric S. Raymond"'s message of Tue, 15 Jul 1997 16:07:12 -0400 (EDT) Message-ID: X-Mailer: Gnus v5.4.37/XEmacs 19.15 Xref: technetium.transmeta.com linux.fhs:44 Status: RO Content-Length: 3901 Lines: 86 >>>>> "Eric" == Eric S Raymond writes: Hi, Eric> Our noise level is too high, and our productivity is too low, Eric> because we don't have an agreed on set of goals or a conflict- Eric> resolution mechanism that accords with them. I agree with you fully. We have been moving too slowly and achieved too few results. -- I'm not blaming Dan for this: Nobody else did anything to speed up the process either. Here is my personal interpretation of why it all went so wrong: The noise problem has been there all the time the FSSTND has existed (or at least since I joined the list almost three years ago). In the beginning the flame wars was raging between two camps: One camp was primarily concerned about consistency between the Linux distributions, while the other was more progressive and focused on aesthetic rather than practical issues. I have to admit, that I belonged in the latter category then, due to the fact that I was actively developing a new Linux distribution and tried to make it as clean as possible. Portability was not an issue for me. When the concept of a joint standard came up, things had pretty much cooled down and we were actually beginning to see results. Unfortunately some people on this list turned out to be very stubborn and unwilling to compromise. Every time a concensus was reached the subject was brought up again. This made a lot of people -- including myself -- feel like we were wasting our time. When the joint standard became a reality another huge problem showed up: A change in the user community. Most Linux users in the FSSTND-days were traditional Unix-geeks like myself, but suddenly users with less Unix experience appeared on the scene. And they had (and have) quite different needs and wishes for a filesystem hierarchy for their standalone machines. Thankfully the packaging tools for Linux (RPM, dpkg) has matured a lot since then, and I actually do believe that most of the ``end user'' needs can be solved by using these tools and following the current FSSTND/FHS. More attention has to be drawn to the network integration/shareability issues, and that's why we started discussing libexec and libdata in the first place. The *BSD camp is still more network oriented both in user base and tradition and the Linux community needs to gain from this experience. I administer Unix boxen for a living, and I know how hard it can be to manage todays distributions on several machines/architectures. Eric> Erik thinks the FHS list ought to (a) have a formal charter Eric> describing its priorities, and (b) become moderated or Eric> invitation-only and open only to people who are actual Eric> decision-makers for the key communities. I haven't specifically Eric> asked Keith about these, but I know how he thinks about stuff Eric> likethis, and I would be utterly astonished if he disagreed. I think it would be wrong to make it invitation-only. Even though the people you suggested as representatives are very competent in their respective fields, I would consider it a loss to make the list closed for the general public. It would be compromising the openness and freedom of the development of our operating systems. On the other hand, I would consider it feasible to do some level of moderation. Probably not on per-posting basis, but maybe the representative commitee could become an authoritative ``shut-up-you're-out-of-line'' group of moderators? As I mentioned above, the re-opening of settled issues has been one of the primary problems with the ``Consensus-by-exhaustion'' principle. I would suggest, that some kind of ticket system was introduced so that it was possible to say ``Placement of . Discussion opened on . Issue settled on . E-O-D.''. /Martin -- Martin Kasper Petersen BOFH, IC1&2, Aalborg University, DK mailto:mkp@SunSITE.auc.dk http://www.socsci.auc.dk/~mkp/ From list-relay@mailbox2.ucsd.edu Tue Jul 15 16:06:44 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id QAA11787 for ; Tue, 15 Jul 1997 16:01:17 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id QAA06998 for ; Tue, 15 Jul 1997 16:00:09 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id PAA32195 for ; Tue, 15 Jul 1997 15:46:11 -0700 Received: from orl.lmco.com (theopolis.orl.mmc.com [141.240.10.10]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id PAA05266 for ; Tue, 15 Jul 1997 15:58:35 -0700 (PDT) Received: from sunny.orl.lmco.com by orl.lmco.com (SMI-8.6/SMI-SVR4) id SAA26735; Tue, 15 Jul 1997 18:57:28 -0400 Received: from sheri.orl.lmco.com (sheri.orl.mmc.com) by sunny.orl.lmco.com (4.1/GEA Sun server 2.7) id AA09508; Tue, 15 Jul 97 18:57:27 EDT Received: from sheri (localhost.orl.lmco.com) by sheri.orl.lmco.com (4.1/1.34.a) id AA25347; Tue, 15 Jul 97 18:57:25 EDT Message-Id: <9707152257.AA25347@sheri.orl.lmco.com> X-Mailer: exmh version 1.6.7 5/3/96 From: Tom Julien To: "Eric S. Raymond" Cc: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 18:57:25 -0400 Sender: tomj@escmail.orl.lmco.com Xref: technetium.transmeta.com linux.fhs:45 Status: RO Content-Length: 747 Lines: 23 "Eric S. Raymond" writes: >First we need to define what the relevant "core communities" are. My choice >of faction representatives would be > >1 Linux core developer -- Ted T'so >1 Red Hat guy -- Erik Troan >1 Debian guy -- Bruce Perens > >1 BSD core developer -- Keith Bostic >1 FreeBSD person -- ?? >1 NetBSD person -- ?? Don't know if this would interest Jordan Hubbard, but Rod Grimes would certainly be a great candidate for FreeBSD. You may also want to consider someone from OpenBSD. Additionally, I'd like to see a few others like Ted with development interests that span commercial OS's. This would round out the team nicely. Tom Julien From list-relay@mailbox2.ucsd.edu Tue Jul 15 16:56:44 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id QAA13655 for ; Tue, 15 Jul 1997 16:56:43 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id QAA08936 for ; Tue, 15 Jul 1997 16:55:36 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id QAA32568 for ; Tue, 15 Jul 1997 16:41:38 -0700 Received: from freya.van.hookup.net (freya.van.hookup.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id QAA09094 for ; Tue, 15 Jul 1997 16:54:19 -0700 (PDT) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (kamloops-111.netshop.net [207.102.173.214]) by freya.van.hookup.net (8.8.5/1.25) with SMTP id QAA14826 for ; Tue, 15 Jul 1997 16:54:14 -0700 (PDT) Message-Id: <199707152354.QAA14826@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Tue, 15 Jul 1997 16:54:03 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Proposal for new poll Priority: normal In-reply-to: <199707151547.LAA26897@dcl.MIT.EDU> References: ldeutsch@mail.netshop.net's message of Mon, 14 Jul 1997 19:09:32 -0800, <199707150209.TAA31736@freya.van.hookup.net> X-mailer: Pegasus Mail for Windows (v2.54) Xref: technetium.transmeta.com linux.fhs:46 Status: RO Content-Length: 884 Lines: 26 Thedore T'so said: > From: ldeutsch@mail.netshop.net > Date: Mon, 14 Jul 1997 19:09:32 -0800 > > 1. Place init/inetd programs in /usr/sbin, subprograms in /usr/lib. > > 2. Place init/inetd programs in /usr/sbin, subprograms in > /usr/libexec. > > 3. Place init/inetd programs and subprograms in > /usr/libexec. > > I'll go along with 2, although with the exception of /usr/lib/sendmail > (which *will* require a compatibility symlink, and probably for quite > some time), and possibly /usr/lib/cpp (although that's in general not so > critical), it really doesn't matter where the init/inetd and subprograms > go. It looks like my proposed new option has recieved some support. (David Niemi also supported it off-list.) Now the question is, can we officially do the poll over with my option added? ---- Michael Deutschmann From list-relay@mailbox1.ucsd.edu Wed Jul 16 02:38:09 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id CAA27379 for ; Wed, 16 Jul 1997 02:38:09 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id CAA20060 for ; Wed, 16 Jul 1997 02:37:00 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id CAA03767 for ; Wed, 16 Jul 1997 02:22:58 -0700 Received: from wfdutilgw.ml.com (wfdutilf01.ml.com [206.3.74.31]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id CAA07234 for ; Wed, 16 Jul 1997 02:34:37 -0700 (PDT) Received: from ml1.ml.com ([199.201.57.130]) by wfdutilgw.ml.com (8.8.5/8.8.5/MLgw-3.03) with ESMTP id FAA10186; Wed, 16 Jul 1997 05:29:59 -0400 (EDT) Received: from mleu1.euro.ml.com (mleu1.euro.ml.com [131.208.157.89]) by ml1.ml.com (8.8.5/8.8.5/MLml4-2.07) with ESMTP id FAA22714; Wed, 16 Jul 1997 05:33:39 -0400 (EDT) Received: from swype.bolon.uk.ml.com (swype.bolon.uk.ml.com [131.208.231.14]) by mleu1.euro.ml.com (8.7.3/8.7.3/MLdomain-2.02) with SMTP id KAA00676; Wed, 16 Jul 1997 10:34:02 +0100 (BST) Received: from isengard.uk.ml.com by swype.bolon.uk.ml.com (4.1/ML41S-1.03) id AA19946; Wed, 16 Jul 97 10:33:59 BST Received: from isengard.uk.ml.com (localhost [127.0.0.1]) by isengard.uk.ml.com (8.8.5/8.8.5) with ESMTP id KAA19084; Wed, 16 Jul 1997 10:31:27 +0100 Message-Id: <199707160931.KAA19084@isengard.uk.ml.com> To: "Brandon S. Allbery KF8NH" Cc: FHS discussion list Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: Your message of "Tue, 15 Jul 1997 16:49:56 EDT." <199707152052.QAA10255@speaker.kf8nh.apk.net> Date: Wed, 16 Jul 1997 10:31:27 +0100 From: Tethys Xref: sodium.transmeta.com linux.fhs:47 Status: RO Content-Length: 786 Lines: 23 >+----- >| 1 BSD core developer -- Keith Bostic >| 1 FreeBSD person -- ?? >| 1 NetBSD person -- ?? >+--->8 > >Do we also want to talk to BSDI, or is it too early for that? (Or am I >stepping on someone's toes?) Keith Bostic's a BSDI person (unless something's changed since I last looked). Tet -- ``There appear to be few if any technical reasons to move from UNIX to Windows NT. The performance of Linux exceeds that of NT 4.0 and Linux appears to be more reliable.'' -- David Korn, AT&T, author of ksh --------------------+--------------+---------------------------------------- tethys@ml.com | Micro$oft: | Linux, the choice of a GNU generation. tet@astradyne.co.uk | Just say no! | See http://www.uk.linux.org for details From list-relay@mailbox1.ucsd.edu Wed Jul 16 04:30:19 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id EAA00592 for ; Wed, 16 Jul 1997 04:29:48 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id EAA21025 for ; Wed, 16 Jul 1997 04:28:40 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id EAA04438 for ; Wed, 16 Jul 1997 04:14:38 -0700 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id EAA09063 for ; Wed, 16 Jul 1997 04:25:32 -0700 (PDT) Received: by proton id m0woSD5-0002KoC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 16 Jul 1997 04:25:31 -0700 (PDT) Message-Id: Date: Wed, 16 Jul 1997 04:25:31 -0700 (PDT) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: on how to proceed X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: sodium.transmeta.com linux.fhs:48 Status: RO Content-Length: 3544 Lines: 87 -----BEGIN PGP SIGNED MESSAGE----- Before we rush into anything here, let's at least consider a few questions. 1. Do we want to join forces with BSD and/or HURD? 2. Is it possible to have a joint standard with BSD and/or HURD? 3. Is it possible to have a joint standard with BSD and/or HURD without blindly agreeing to everything BSD and/or HURD developers demand? I have seen little effort on the part of BSD and/or HURD developers to compromise with FSSTND or FHS. Their attitude has been negative for nearly the entire span of discussion, and one or two have threatened to leave the mailing list multiple times. Of course, some of their claims are valid. It's also very disruptive to have what has been a fairly productive mailing list get caught up in "the fervor" from time to time. Few people have even asked if a joint standard will really make things better for Linux users. Realistically, it really won't matter that much either way. The concept is more appealing for philosophical and political reasons. Now, here is a general idea of how I would like to proceed: 1. We release FHS 2.0 and note that it hasn't achieved all of the goals originally set, but that it is a significant improvement for Linux, etc. 2. A small group of people (Linux, BSD, and HURD people) go over individual sections of the filesystem to map out the differences and inconsistencies between the operating systems, why they exist, what the side-effects are, and report back to me. They should start with easier directories and get to the harder ones later, if things proceed well. This group will not attempt to resolve differences, just find them in as detailed and well-informed manner as possible. (For example, "HURD and Linux puts this type of binaries in /bin, but BSD doesn't.") I would like to include some system administrators in this group, since they are major customers of the developers. Since this group will not be deciding anything, they stand a decent chance of being productive. 3. After the report, we will discuss how to proceed and I will make a decision on how to proceed, if at all. 4. We do not use the FHS as a vehicle for intersystem discussion. At least, not until there is a more productive and cooperative mood. 5. Improvements on FHS 2.1 will continue separately from the integration effort. Some work remains to be done that does not directly affect the integration issue: rewriting, better examples, fewer inconsistencies, etc. - From my looking at my old mail archives, this approach is closer to how the original FSSTND was drafted. We mapped out the territory, people discussed the options, and so on. "We" was the operative pronoun then. Unfortunately, now it is "them" and "us" most of the time plus a few people who want a joint standard at any cost. At worst, we will have a better idea of the differences between the major free Unix-like systems and we can use that knowledge to improve Linux, BSD, and HURD separately. At best, we will be able to move forward together. - Dan P.S. I had some home-made lavender ice cream with strawberries earlier tonight. It almost hinted of ginger, but was smoother. It was great! -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBM8yvqakybebRDjw1AQFJGQP/YJuvDkMEVlLOLhJq0UvrMeVTqYbalEQb HWHmE72rIeywWw2iuZT8ZDYnZojvoGi0xkT2TFa+ytWSSOs0tUyP3vSBm0gNYVGx i83Elcq3/5V+chR8E+V6HB3dgFTScFYdN3cAaVJ0sumX5T2vqArCgexR8IAJ4cbI hQfaMxUa58E= =xYdM -----END PGP SIGNATURE----- From list-relay@mailbox1.ucsd.edu Wed Jul 16 07:01:59 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id HAA04034 for ; Wed, 16 Jul 1997 07:01:58 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id HAA22195 for ; Wed, 16 Jul 1997 07:00:50 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id GAA05141 for ; Wed, 16 Jul 1997 06:46:47 -0700 Received: from bentley.socsci.auc.dk (bentley.socsci.auc.dk [130.225.60.48]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id GAA12611 for ; Wed, 16 Jul 1997 06:57:42 -0700 (PDT) Received: from jaguar.socsci.auc.dk (jaguar.socsci.auc.dk [130.225.60.49]) by bentley.socsci.auc.dk (8.8.5/8.7.1) with ESMTP id PAA02623; Wed, 16 Jul 1997 15:57:41 +0200 Received: (from mkp@localhost) by jaguar.socsci.auc.dk (8.8.5/8.6.12) id PAA24240; Wed, 16 Jul 1997 15:54:00 +0200 To: quinlan@pathname.com Cc: fhs-discuss@ucsd.edu Subject: Re: on how to proceed References: Organization: Computing Dept. 1&2, Aalborg University Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Charset: Latin-1 X-Face: ({%T;F${m<}wr[*K`gT|vs1m&kDfl(^PsxTnmb)FL4!_$=dj|NG~.SNrq-qxsT]}i>DP.("XEmucViR>9iEl?,!C1 2p,ST@1)zEW+Kb'iJ,c6~O`BWjCoY42jmV From: Martin Kasper Petersen Date: 16 Jul 1997 15:54:00 +0200 In-Reply-To: Daniel Quinlan's message of Wed, 16 Jul 1997 04:25:31 -0700 (PDT) Message-ID: X-Mailer: Gnus v5.4.37/XEmacs 19.15 Xref: sodium.transmeta.com linux.fhs:49 Status: RO Content-Length: 2381 Lines: 62 >>>>> "Daniel" == Daniel Quinlan writes: Hi, Daniel> 1. Do we want to join forces with BSD and/or HURD? Daniel> 2. Is it possible to have a joint standard with BSD and/or Daniel> HURD? Daniel> 3. Is it possible to have a joint standard with BSD and/or Daniel> HURD without blindly agreeing to everything BSD and/or HURD Daniel> developers demand? I think it would be worthwhile to make the filesystem hierarchy as consistent as possible between at least *BSD and Linux, yes. Hurd has a different approach to the whole thing, and is thus harder to incorporate. But that doesn't mean we should ignore the Hurd/Thomas altogether. The concept of a flat structure is not necessarily a bad thing, but it's probably a little too progressive for todays standards. I don't think the consistency should be achieved at any price, however. We might reach a point where neither the Linux nor the BSD camp wants to budge on a given subject. Let's keep the as much as possible in the common descriptions and move inconsistensies/unresolvable issues to the OS-specific appendices (We need somebody to write the *BSD and Hurd sections btw.). Making the core FHS-document a lowest common denominator would help a lot and keep the noise level down. Later on, papers posted by the integration group would hopefully result in material being moved from the appendices to the core standard. I think the whole concept of an integration group is great. Much better than any of the other suggestions made so far. The group could post requests for comments and suggest sound solutions to the list, which would then be open for discussions to the general public. Daniel> 1. We release FHS 2.0 and note that it hasn't achieved all of Daniel> the goals originally set, but that it is a significant Daniel> improvement for Linux, etc. With or without libexec? At the very least, I think it should be marked as ``This directory might be present on some operating systems'' or be mentioned in the BSD/Hurd appendices, if they emerge in time. /Martin Daniel> P.S. I had some home-made lavender ice cream with strawberries Daniel> earlier tonight. It almost hinted of ginger, but was Daniel> smoother. It was great! One of my favorite flavors too :-) -- Martin Kasper Petersen BOFH, IC1&2, Aalborg University, DK mailto:mkp@SunSITE.auc.dk http://www.socsci.auc.dk/~mkp/ From list-relay@mailbox1.ucsd.edu Wed Jul 16 07:23:16 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id HAA04538 for ; Wed, 16 Jul 1997 07:23:15 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id HAA22403 for ; Wed, 16 Jul 1997 07:22:07 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id HAA05266 for ; Wed, 16 Jul 1997 07:07:58 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id HAA14014 for ; Wed, 16 Jul 1997 07:20:21 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id KAA26994 for fhs-discuss@ucsd.edu; Wed, 16 Jul 1997 10:21:47 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id KAA19454 for ; Wed, 16 Jul 1997 10:11:03 -0400 Message-Id: <199707161411.KAA19454@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Wed, 16 Jul 97 10:02:22 -0400 To: FHS discussion list In-Reply-To: Subject: Re: on how to proceed X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: sodium.transmeta.com linux.fhs:50 Status: RO Content-Length: 1251 Lines: 25 In , on 07/16/97 at 04:25 AM, Daniel Quinlan said: +----- | I have seen little effort on the part of BSD and/or HURD developers to | compromise with FSSTND or FHS. Their attitude has been negative for nearly | the entire span of discussion, and one or two have threatened +--->8 This is unfair. Most of the top people from the BSD and HURD camps left long ago, driven off when repeatedly we reached a mutually acceptable position on an issue only for certain *Linux* people to start the same argument over from the very beginning as if it had never been discussed. The list quickly degenerated into ideologues from all camps --- I suspect most of the "moderates" outside the Linux camp, and several from inside it, were too dismayed to participate. (And after the reception they got in the first few months, anyone from outside the Linux community would have to either have a very thick skin or be a certified SOB to be willing to stick around other than as a lurker.) -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Wed Jul 16 07:55:17 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id HAA05312 for ; Wed, 16 Jul 1997 07:55:16 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id HAA22782 for ; Wed, 16 Jul 1997 07:54:08 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id HAA05501 for ; Wed, 16 Jul 1997 07:40:05 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id HAA12255 for ; Wed, 16 Jul 1997 07:50:06 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id TAA10134; Tue, 15 Jul 1997 19:09:32 -0400 From: "Eric S. Raymond" Message-Id: <199707152309.TAA10134@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: bsa@kf8nh.apk.net (Brandon S. Allbery KF8NH) Date: Tue, 15 Jul 1997 19:09:31 -0400 (EDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: <199707152052.QAA10255@speaker.kf8nh.apk.net> from "Brandon S. Allbery KF8NH" at Jul 15, 97 04:49:56 pm Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:51 Status: RO Content-Length: 347 Lines: 14 Brandon: > +----- > | 1 BSD core developer -- Keith Bostic > | 1 FreeBSD person -- ?? > | 1 NetBSD person -- ?? > +--->8 > > Do we also want to talk to BSDI, or is it too early for that? (Or am I > stepping on someone's toes?) Keith *is* a BSDI guy. -- Eric S. Raymond From list-relay@mailbox2.ucsd.edu Wed Jul 16 07:55:24 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id HAA05316 for ; Wed, 16 Jul 1997 07:55:23 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id HAA22786 for ; Wed, 16 Jul 1997 07:54:15 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id HAA05506 for ; Wed, 16 Jul 1997 07:40:12 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id HAA12260 for ; Wed, 16 Jul 1997 07:50:22 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id TAA10158; Tue, 15 Jul 1997 19:13:56 -0400 From: "Eric S. Raymond" Message-Id: <199707152313.TAA10158@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: bmbuck@acsu.buffalo.edu Date: Tue, 15 Jul 1997 19:13:55 -0400 (EDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: <199707152142.OAA29243@mailbox2.ucsd.edu> from "Buddha Buck" at Jul 15, 97 05:37:25 pm Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:52 Status: RO Content-Length: 947 Lines: 21 Buddha Buck: > It also seems a bit unbalanced -- perhaps unavoidably so. I am firmly > in the Linux faction myself (and a dedicated lurker to this list), but > I see 9 representatives, one theoretically neutral (Dan), and the > others divided up approximately 3.5/3.5/1 Linux/BSD/HURD. I'm afraid > that the HURD's concerns might not be voiced strongly enough, with the > lessened representation. I did that deliberately. The HURD is not as important as Linux or BSD. It's more a promise than a production system and has only a tiny constituency (basically just the FSF itself). Sorry, but that's reality. > Perhaps a reasonable possibility, if it can be set up this way, would > be to have it moderated, but the key decision-makers automatically > approved. If a reasonable, on-charter, comment from a > non-decision-maker comes in, it can be posted. Not unreasonable. -- Eric S. Raymond From list-relay@mailbox1.ucsd.edu Wed Jul 16 08:08:18 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA05650 for ; Wed, 16 Jul 1997 08:08:17 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA23046 for ; Wed, 16 Jul 1997 08:07:09 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id HAA05585 for ; Wed, 16 Jul 1997 07:53:06 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id IAA16980 for ; Wed, 16 Jul 1997 08:03:22 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id LAA14210; Wed, 16 Jul 1997 11:10:35 -0400 From: "Eric S. Raymond" Message-Id: <199707161510.LAA14210@snark.thyrsus.com> Subject: Re: on how to proceed To: quinlan@pathname.com Date: Wed, 16 Jul 1997 11:10:35 -0400 (EDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: from "Daniel Quinlan" at Jul 16, 97 04:25:31 am Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:53 Status: RO Content-Length: 2894 Lines: 67 Dan Quinlan: > Before we rush into anything here, let's at least consider a few > questions. > > 1. Do we want to join forces with BSD and/or HURD? We must hang together, or we will all hang separately. As someone else pointed out, the shadow of NT looms. The potential users of Unix don't give a rat's ass for aesthetic hairsplitting about where directories `ought' to live in an ideal design; what they do see that damages us is a squabbling bunch of theologicians who, despite our vaunted technical brilliance, can't even manage basic binary applications portability between our dialects. We've *got* to get our act together to survive. The FHS isn't sufficient, but it is necessary. Instrumentally, I think it's pretty clear that we should be trying to join forces with BSD. It's not clear to me that HURD is or will be very important in terms of number of users, but the FSF still has enough prestige and influence to buy HURD a seat at the table. > 2. Is it possible to have a joint standard with BSD and/or HURD? Yes, if we can manage to keep the assholes on both sides from sabotaging the effort. The people capable of seeing the FHS actually implemented (the people I proposed as a core team list) are not assholes. > 3. Is it possible to have a joint standard with BSD and/or HURD without > blindly agreeing to everything BSD and/or HURD developers demand? > > I have seen little effort on the part of BSD and/or HURD developers to > compromise with FSSTND or FHS. Their attitude has been negative for > nearly the entire span of discussion, and one or two have threatened > to leave the mailing list multiple times. Of course, some of their > claims are valid. I don't buy it. Keith Bostic, who is (face facts) the single most important person to persuade if the BSD world is going to buy in, didn't have a "negative attitude" and split only because the bullshit level got too high. > 1. We release FHS 2.0 and note that it hasn't achieved all of the > goals originally set, but that it is a significant improvement for > Linux, etc. I agree with this. > 2. A small group of people (Linux, BSD, and HURD people) go over > individual sections of the filesystem to map out the differences > and inconsistencies between the operating systems, why they exist, > what the side-effects are, and report back to me. They should > start with easier directories and get to the harder ones later, if > things proceed well. A reasonable first step. > 3. After the report, we will discuss how to proceed and I will make a > decision on how to proceed, if at all. At that point, there have to be changes in our *process* (voting methods representation) or we're not going to avoid the same old wrangling, and we're *not* going to persuade the key people who have split to rejoin. -- Eric S. Raymond From list-relay@mailbox2.ucsd.edu Wed Jul 16 08:08:21 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA05654 for ; Wed, 16 Jul 1997 08:08:20 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA23050 for ; Wed, 16 Jul 1997 08:07:12 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id HAA05590 for ; Wed, 16 Jul 1997 07:53:09 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id IAA12994 for ; Wed, 16 Jul 1997 08:05:13 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id LAA14224; Wed, 16 Jul 1997 11:12:44 -0400 From: "Eric S. Raymond" Message-Id: <199707161512.LAA14224@snark.thyrsus.com> Subject: Re: on how to proceed To: bsa@kf8nh.apk.net (Brandon S. Allbery KF8NH) Date: Wed, 16 Jul 1997 11:12:44 -0400 (EDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: <199707161411.KAA19454@speaker.kf8nh.apk.net> from "Brandon S. Allbery KF8NH" at Jul 16, 97 10:02:22 am Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:54 Status: RO Content-Length: 1158 Lines: 23 Brandon: > Daniel Quinlan said: > | I have seen little effort on the part of BSD and/or HURD developers to > | compromise with FSSTND or FHS. Their attitude has been negative for nearly > | the entire span of discussion, and one or two have threatened > +--->8 > > This is unfair. Most of the top people from the BSD and HURD camps left long > ago, driven off when repeatedly we reached a mutually acceptable position on > an issue only for certain *Linux* people to start the same argument over from > the very beginning as if it had never been discussed. The list quickly > degenerated into ideologues from all camps --- I suspect most of the > "moderates" outside the Linux camp, and several from inside it, were too > dismayed to participate. (And after the reception they got in the first few > months, anyone from outside the Linux community would have to either have a > very thick skin or be a certified SOB to be willing to stick around other > than as a lurker.) Damn straight. Even one of the top people from the *Linux* camp gave up for this reason. -- Eric S. Raymond From list-relay@mailbox2.ucsd.edu Wed Jul 16 08:38:54 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA06473 for ; Wed, 16 Jul 1997 08:38:54 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA23437 for ; Wed, 16 Jul 1997 08:37:46 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA05782 for ; Wed, 16 Jul 1997 08:23:42 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id IAA14643 for ; Wed, 16 Jul 1997 08:35:13 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA16257; Wed, 16 Jul 97 11:35:09 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id LAA29406; Wed, 16 Jul 1997 11:35:08 -0400 Date: Wed, 16 Jul 1997 11:35:08 -0400 Message-Id: <199707161535.LAA29406@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: quinlan@pathname.com Cc: fhs-discuss@ucsd.edu In-Reply-To: Daniel Quinlan's message of Wed, 16 Jul 1997 04:25:31 -0700 (PDT), Subject: Re: on how to proceed Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:55 Status: RO Content-Length: 1182 Lines: 26 Dan, Well said! I agree with your post 100%. One of my concerns, indeed, is that nearly all of the people who have been speaking up lately have been the "joint standard at any cost". It is not clear that this attitude is generally shared either (a) within the general Linux community, (b) within the general star-BSD-star community(ies), and (c) within the Hurd. One of my concerns is that there are a few people in this forum (who happen to mostly be from the Linux community) who are in the "joint standard at any cost". However, it's not at clear that the folks from the BSD and GNU camps share the same attitude. This leads to unbalanced discussions, especially when allocating the amount of inconvenience that one side or the other *will* have to suffer in order migrate towards some common scheme. But before we even start down the path of deciding who gets to bear the pain of change, we need to come to agreement that the pain is worth suffering in the first place. It may not be. Having a group of people trying to explore the lay of the land, so we can see exactly *how* much pain it will be in the first place is certainly a good first step. - Ted From list-relay@mailbox1.ucsd.edu Wed Jul 16 09:03:04 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA07305 for ; Wed, 16 Jul 1997 09:03:04 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA23846 for ; Wed, 16 Jul 1997 09:01:56 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA05971 for ; Wed, 16 Jul 1997 08:47:52 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id JAA20999 for ; Wed, 16 Jul 1997 09:00:30 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA21656; Wed, 16 Jul 97 12:00:17 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id MAA29425; Wed, 16 Jul 1997 12:00:15 -0400 Date: Wed, 16 Jul 1997 12:00:15 -0400 Message-Id: <199707161600.MAA29425@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Eric S. Raymond" Cc: quinlan@pathname.com, fhs-discuss@ucsd.edu In-Reply-To: Eric S. Raymond's message of Wed, 16 Jul 1997 11:10:35 -0400 (EDT), <199707161510.LAA14210@snark.thyrsus.com> Subject: Re: on how to proceed Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:56 Status: RO Content-Length: 1434 Lines: 36 From: "Eric S. Raymond" Date: Wed, 16 Jul 1997 11:10:35 -0400 (EDT) We must hang together, or we will all hang separately. As someone else pointed out, the shadow of NT looms. The potential users of Unix don't give a rat's ass for aesthetic hairsplitting about where directories `ought' to live in an ideal design; what they do see that damages us is a squabbling bunch of theologicians who, despite our vaunted technical brilliance, can't even manage basic binary applications portability between our dialects. Warning! There are a number of blatent leaps of logic above... (1) FHS does not solve the binary application portability problem. (2) It is not at all obvious that having binary application portability would solve the NT problem. (3) 95% of the recent tussles on this list have had *no* bearing on the goal of basic application portability, even if it's source compatibility and not binary compatibility. a) That's what /usr/include/paths.h is for. b) That's what autoconf is for. c) BSD already has a shadow directory tree hack for their Linux emulation mode. (This gives them run-time compatibility, without needing to make any modifications to the binaries.) d) As long as the files are only used by the package itself (example: cc1), it really doesn't matter where it lives for the sake of basic application portability. - Ted From list-relay@mailbox2.ucsd.edu Wed Jul 16 09:42:45 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA08643 for ; Wed, 16 Jul 1997 09:42:44 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA25443 for ; Wed, 16 Jul 1997 09:41:37 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA06367 for ; Wed, 16 Jul 1997 09:27:28 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA19427 for ; Wed, 16 Jul 1997 09:40:20 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id MAA04840; Wed, 16 Jul 1997 12:41:28 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id MAA20619; Wed, 16 Jul 1997 12:23:34 -0400 Message-Id: <199707161623.MAA20619@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Wed, 16 Jul 97 12:18:48 -0400 To: "Eric S. Raymond" In-Reply-To: <199707152309.TAA10134@snark.thyrsus.com> Cc: FHS discussion list Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: sodium.transmeta.com linux.fhs:57 Status: RO Content-Length: 1247 Lines: 27 In <199707152309.TAA10134@snark.thyrsus.com>, on 07/15/97 at 07:09 PM, "Eric S. Raymond" said: +----- | > Do we also want to talk to BSDI, or is it too early for that? (Or am I | > stepping on someone's toes?) | Keith *is* a BSDI guy. +--->8 Shows how much I know about the current state of BSD.... Not to mention how recently I've seen any messages from Keith. I'd like to have him back in FHS if at all possible, he's got rather more experience at this than many (not all!) of the folks involved and I tend to trust his evaluations as being well thought out, even when I disagree with them. (I looked at switching from Linux to *BSD at one point, but (a) I was rather horrified at the (then; haven't had the opportunity to check recently) installation for NetBSD and FreeBSD and (b) I needed something like diald and could find no mention of anything equivalent for *BSD at the time. (b) was the real killer, getting up at 3am to kickstart the newsfeed over PPP isn't my idea of fun.) -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox1.ucsd.edu Wed Jul 16 09:42:59 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA08652 for ; Wed, 16 Jul 1997 09:42:59 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA25461 for ; Wed, 16 Jul 1997 09:41:51 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA06377 for ; Wed, 16 Jul 1997 09:27:47 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA24356 for ; Wed, 16 Jul 1997 09:40:05 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id MAA04858 for fhs-discuss@ucsd.edu; Wed, 16 Jul 1997 12:41:32 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id MAA20651 for ; Wed, 16 Jul 1997 12:35:11 -0400 Message-Id: <199707161635.MAA20651@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Wed, 16 Jul 97 12:29:55 -0400 To: FHS discussion list In-Reply-To: <199707161535.LAA29406@dcl.MIT.EDU> Subject: Re: on how to proceed X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: sodium.transmeta.com linux.fhs:58 Status: RO Content-Length: 968 Lines: 23 In <199707161535.LAA29406@dcl.MIT.EDU>, on 07/16/97 at 11:35 AM, "Theodore Y. Ts'o" said: +----- | One of my concerns is that there are a few people in this forum (who happen | to mostly be from the Linux community) who are in the "joint standard at any | cost". However, it's not at clear that the folks from +--->8 I'm not in favor of "joint standard at any cost". I *am* in favor of a better good-faith attempt than the botched one we had. ---And most of the folks in favor of a balanced approach appear to have bailed within 2 months of that attempt. I hate to say it, but I'm not entirely convinced that the current FHS "working group" is all that representative of the "mainstream" for Linux or anything else. -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Wed Jul 16 09:50:32 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA08874 for ; Wed, 16 Jul 1997 09:50:31 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA25667 for ; Wed, 16 Jul 1997 09:49:23 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA06460 for ; Wed, 16 Jul 1997 09:35:19 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA19996 for ; Wed, 16 Jul 1997 09:48:26 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id MAA16669; Wed, 16 Jul 1997 12:48:16 -0400 (EDT) Date: Wed, 16 Jul 1997 12:48:16 -0400 (EDT) Message-Id: <199707161648.MAA16669@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: quinlan@pathname.com CC: fhs-discuss@ucsd.edu In-reply-to: Daniel Quinlan's message of Wed, 16 Jul 1997 04:25:31 -0700 (PDT) Subject: Re: on how to proceed X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "You pinhead," Tom said pointedly. Xref: sodium.transmeta.com linux.fhs:59 Status: RO Content-Length: 808 Lines: 21 Date: Wed, 16 Jul 1997 04:25:31 -0700 (PDT) From: Daniel Quinlan I have seen little effort on the part of BSD and/or HURD developers to compromise with FSSTND or FHS. Their attitude has been negative for nearly the entire span of discussion, and one or two have threatened to leave the mailing list multiple times. Of course, some of their claims are valid. Most of the issues described are things where FHS is fine. The arrangement of /var, for example, doesn't bother me at all. I'm very positive about nearly all of the document. I am negative about the libexec decision, precisely because 1) This directory makes a useful distinction, in practice, and 2) Few people seemed to have understood what it was about before voicing their opinion. Thomas From list-relay@mailbox1.ucsd.edu Wed Jul 16 09:55:54 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA09054 for ; Wed, 16 Jul 1997 09:55:53 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA25834 for ; Wed, 16 Jul 1997 09:54:45 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA06531 for ; Wed, 16 Jul 1997 09:40:41 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA25464 for ; Wed, 16 Jul 1997 09:53:05 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id MAA16684; Wed, 16 Jul 1997 12:52:41 -0400 (EDT) Date: Wed, 16 Jul 1997 12:52:41 -0400 (EDT) Message-Id: <199707161652.MAA16684@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: esr@snark.thyrsus.com CC: bmbuck@acsu.buffalo.edu, fhs-discuss@ucsd.edu In-reply-to: "Eric S. Raymond"'s message of Tue, 15 Jul 1997 19:13:55 -0400 (EDT) <199707152313.TAA10158@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Zippy-Says: Are we live or on tape? Xref: sodium.transmeta.com linux.fhs:60 Status: RO Content-Length: 364 Lines: 10 From: "Eric S. Raymond" Date: Tue, 15 Jul 1997 19:13:55 -0400 (EDT) I did that deliberately. The HURD is not as important as Linux or BSD. It's more a promise than a production system and has only a tiny constituency (basically just the FSF itself). Sorry, but that's reality. Incidentally, this is no longer true... From list-relay@mailbox1.ucsd.edu Wed Jul 16 10:00:09 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA09278 for ; Wed, 16 Jul 1997 10:00:09 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA25913 for ; Wed, 16 Jul 1997 09:59:01 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA06577 for ; Wed, 16 Jul 1997 09:44:57 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA25919 for ; Wed, 16 Jul 1997 09:58:02 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id NAA14946; Wed, 16 Jul 1997 13:04:58 -0400 From: "Eric S. Raymond" Message-Id: <199707161704.NAA14946@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec To: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) Date: Wed, 16 Jul 1997 13:04:57 -0400 (EDT) Cc: bmbuck@acsu.buffalo.edu, fhs-discuss@ucsd.edu In-Reply-To: <199707161652.MAA16684@churchy.gnu.ai.mit.edu> from "Thomas Bushnell, n/BSG" at Jul 16, 97 12:52:41 pm Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:61 Status: RO Content-Length: 548 Lines: 16 Thomas, replying to me: > I did that deliberately. The HURD is not as important as Linux or > BSD. It's more a promise than a production system and has only a > tiny constituency (basically just the FSF itself). Sorry, but > that's reality. > > Incidentally, this is no longer true... Evidence? I'm not hostile. But given the HURD's long history of being just about to accomplish something without actually getting there, I'd like to see more than just the assertion. -- Eric S. Raymond From list-relay@mailbox2.ucsd.edu Wed Jul 16 10:05:24 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA09451 for ; Wed, 16 Jul 1997 10:05:23 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA26035 for ; Wed, 16 Jul 1997 10:04:15 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA06635 for ; Wed, 16 Jul 1997 09:50:11 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id KAA21101 for ; Wed, 16 Jul 1997 10:03:07 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id NAA16731; Wed, 16 Jul 1997 13:02:57 -0400 (EDT) Date: Wed, 16 Jul 1997 13:02:57 -0400 (EDT) Message-Id: <199707161702.NAA16731@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: esr@snark.thyrsus.com CC: bmbuck@acsu.buffalo.edu, fhs-discuss@ucsd.edu In-reply-to: "Eric S. Raymond"'s message of Wed, 16 Jul 1997 13:04:57 -0400 (EDT) <199707161704.NAA14946@snark.thyrsus.com> Subject: Re: Results of straw poll regarding /usr/libexec X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "I don't WANNA get drunk," Tom wined. Xref: sodium.transmeta.com linux.fhs:62 Status: RO Content-Length: 416 Lines: 11 From: "Eric S. Raymond" Date: Wed, 16 Jul 1997 13:04:57 -0400 (EDT) I'm not hostile. But given the HURD's long history of being just about to accomplish something without actually getting there, I'd like to see more than just the assertion. The 0.2 release has been fetched and used by a lot of people. Sounds like you haven't actually kept up with the state of things... From list-relay@mailbox2.ucsd.edu Wed Jul 16 10:26:20 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA10120 for ; Wed, 16 Jul 1997 10:26:19 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA26815 for ; Wed, 16 Jul 1997 10:25:12 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA06831 for ; Wed, 16 Jul 1997 10:11:07 -0700 Received: from snark.thyrsus.com (locke.ccil.org [205.164.136.88]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id KAA22426 for ; Wed, 16 Jul 1997 10:23:31 -0700 (PDT) Received: (from esr@localhost) by snark.thyrsus.com (8.8.5/8.8.5) id NAA15059; Wed, 16 Jul 1997 13:29:15 -0400 From: "Eric S. Raymond" Message-Id: <199707161729.NAA15059@snark.thyrsus.com> Subject: Re: on how to proceed To: tytso@mit.edu (Theodore Y. Ts'o) Date: Wed, 16 Jul 1997 13:29:15 -0400 (EDT) Cc: quinlan@pathname.com, fhs-discuss@ucsd.edu In-Reply-To: <199707161600.MAA29425@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Jul 16, 97 12:00:15 pm Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy Content-Type: text Xref: sodium.transmeta.com linux.fhs:63 Status: RO Content-Length: 1604 Lines: 33 Ted T'so: > Warning! There are a number of blatent leaps of logic above... You're losing the forest for the trees. I said FHS was not sufficient but *necessary*. Because if we can't even get our act together enough to do FHS across the competing free Unixes, there is no hope we will solve binary portability or any of the other *hard* problems. The need for FHS is primarily political and sociological, not technical. It has less to do with specific problems about where (say) mailbox files live, which can be handled with autoconf and RPM, than it does with whether the Linux and wider Unix community is ever going to stop endlessly squabbling with itself over technical minutiae and behave like it wants to win a market-share battle with *other* operating systems. You, and a lot of other people, need to pull your head out of the bits and bytes and start asking what the hell the failure of the existing FHS process *means*. It's a subcase of a wider problem. If we can't hammer out a solution to this subcase, we won't solve the wider problem either. And that would be bad. Very bad. Because to our opposition, the fact that we can't get our shit together even *politically* -- even in *intention*, let alone technical fact -- is a handle to marginalize us with. And they already have more money and more mind-share than we do. Everybody who defends a Linux-purist or BSD-purist position on this list is effectively bending over, grabbing their ankles, and yelling "Rape me now, Bill Gates!" Is that really what we want? -- Eric S. Raymond From list-relay@mailbox1.ucsd.edu Wed Jul 16 10:49:34 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA11026 for ; Wed, 16 Jul 1997 10:49:33 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA27582 for ; Wed, 16 Jul 1997 10:48:25 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA07125 for ; Wed, 16 Jul 1997 10:34:21 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id KAA00335 for ; Wed, 16 Jul 1997 10:47:19 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA13226; Wed, 16 Jul 97 13:47:12 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id NAA29487; Wed, 16 Jul 1997 13:47:11 -0400 Date: Wed, 16 Jul 1997 13:47:11 -0400 Message-Id: <199707161747.NAA29487@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Eric S. Raymond" Cc: quinlan@pathname.com, fhs-discuss@ucsd.edu In-Reply-To: Eric S. Raymond's message of Wed, 16 Jul 1997 13:29:15 -0400 (EDT), <199707161729.NAA15059@snark.thyrsus.com> Subject: Re: on how to proceed Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:64 Status: RO Content-Length: 1607 Lines: 33 From: "Eric S. Raymond" Date: Wed, 16 Jul 1997 13:29:15 -0400 (EDT) You're losing the forest for the trees. I said FHS was not sufficient but *necessary*. Because if we can't even get our act together enough to do FHS across the competing free Unixes, there is no hope we will solve binary portability or any of the other *hard* problems. I don't know about that.... NetBSD has Linux emulation... good enough to play doom and quake (which means they emulate the sound driver, too!). Linux and NetBSD have IBCS2 emulation working well enough to run SCO Unix binaries, from Xess to some versions of Oracle. Practically, we do have solutions to at least some of the hard problems; that's because those hard problems are technical nature, and have an appropriate motivators in place --- the ability to play Quake; the ability to run Oracle, etc. One of the big problems is that people are ignoring why people work on free Unix operating systems. Most of the people do it because it's fun. Relatively few souls actually get paid for their work. Not everybody works on free Unix systems because they are trying to subvert Bill Gates' dreams of world domination. There are certainly some folks, including some of the more vocal people on linux-fsstnd, who have this as a motivation. But don't make the mistake that everyone shares in your primary motivation the defeat of Billy-boy at all costs. Finally, I'll note that negative motivators --- such as raising the Billy Gates boogeyman --- are generally not as effective as postive motivators. - Ted From list-relay@mailbox1.ucsd.edu Wed Jul 16 10:51:42 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA11108 for ; Wed, 16 Jul 1997 10:51:41 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA27645 for ; Wed, 16 Jul 1997 10:49:25 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA07141 for ; Wed, 16 Jul 1997 10:35:20 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id KAA00433 for ; Wed, 16 Jul 1997 10:48:29 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA13450; Wed, 16 Jul 97 13:48:19 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id NAA29489; Wed, 16 Jul 1997 13:48:18 -0400 Date: Wed, 16 Jul 1997 13:48:18 -0400 Message-Id: <199707161748.NAA29489@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: thomas@gnu.ai.mit.edu Cc: esr@snark.thyrsus.com, bmbuck@acsu.buffalo.edu, fhs-discuss@ucsd.edu In-Reply-To: Thomas Bushnell, n/BSG's message of Wed, 16 Jul 1997 13:02:57 -0400 (EDT), <199707161702.NAA16731@churchy.gnu.ai.mit.edu> Subject: Re: Results of straw poll regarding /usr/libexec Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:65 Status: RO Content-Length: 467 Lines: 14 Date: Wed, 16 Jul 1997 13:02:57 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) The 0.2 release has been fetched and used by a lot of people. Sounds like you haven't actually kept up with the state of things... How many is a lot? What is your estimated user community at this point? (Not just how many people have downloaded it; how many people are currently actively using the Hurd, which is a different question....) - Ted From list-relay@mailbox1.ucsd.edu Wed Jul 16 11:03:06 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA11636 for ; Wed, 16 Jul 1997 11:03:06 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA27994 for ; Wed, 16 Jul 1997 11:01:58 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA07278 for ; Wed, 16 Jul 1997 10:47:53 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id LAA01310 for ; Wed, 16 Jul 1997 11:00:00 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id OAA09322 for fhs-discuss@ucsd.edu; Wed, 16 Jul 1997 14:01:28 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id NAA21195 for ; Wed, 16 Jul 1997 13:32:29 -0400 Message-Id: <199707161732.NAA21195@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Wed, 16 Jul 97 13:26:41 -0400 To: FHS discussion list In-Reply-To: <199707161702.NAA16731@churchy.gnu.ai.mit.edu> Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: sodium.transmeta.com linux.fhs:66 Status: RO Content-Length: 1406 Lines: 29 In <199707161702.NAA16731@churchy.gnu.ai.mit.edu>, on 07/16/97 at 01:02 PM, thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) said: +----- | I'm not hostile. But given the HURD's long history of being just about | to | accomplish something without actually getting there, I'd like to see more | than just the assertion. | The 0.2 release has been fetched and used by a lot of people. Sounds like | you haven't actually kept up with the state of things... +--->8 Sounds like that makes several of us, in several different directions. Now can we try not to make the previous mess look productive by comparison? My own question WRT the HURD is whether its basis is "close enough" to be capable of working with FHS. Some (old) examples seemed to imply it had a fairly different filesystem hierarchy --- if it's too different, trying to merge them in any fashion will accomplish nothing but frustrating everyone involved. Then again, the examples I saw *were* fairly old and I have no idea what it looks like now; they might not have been representative; and (d*mmit!) I don't have any spare systems around any more to toss HURD (or *BSD) onto to see for myself. :-( -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox1.ucsd.edu Wed Jul 16 11:03:16 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA11640 for ; Wed, 16 Jul 1997 11:03:15 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA27998 for ; Wed, 16 Jul 1997 11:02:02 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA07284 for ; Wed, 16 Jul 1997 10:47:58 -0700 Received: from hottub.caldera.com (hottub.caldera.com [207.49.12.15]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA01375 for ; Wed, 16 Jul 1997 11:00:39 -0700 (PDT) Received: (qmail 25149 invoked from smtpd); 16 Jul 1997 17:57:32 -0000 Received: from caldera.com (207.49.12.1) by hottub.caldera.com with SMTP; 16 Jul 1997 17:57:31 -0000 Received: (from tbird@localhost) by caldera.com (8.8.6/8.8.6) id MAA24066; Wed, 16 Jul 1997 12:00:29 -0600 From: Tim Bird Message-Id: <199707161800.MAA24066@caldera.com> Subject: Re: Results of straw poll regarding /usr/libexec To: esr@snark.thyrsus.com (Eric S. Raymond) Date: Wed, 16 Jul 1997 12:00:29 -0600 (MDT) Cc: fhs-discuss@UCSD.EDU In-Reply-To: <199707152007.QAA08773@snark.thyrsus.com> from "Eric S. Raymond" at Jul 15, 97 04:07:12 pm Content-Type: text Xref: sodium.transmeta.com linux.fhs:67 Status: RO Content-Length: 1383 Lines: 36 > > First we need to define what the relevant "core communities" are. My choice > of faction representatives would be > > 1 Linux core developer -- Ted T'so > 1 Red Hat guy -- Erik Troan > 1 Debian guy -- Bruce Perens May I add myself, Tim Bird, as the representative for Caldera. I have not actively participated for some time, but I did re-initiate the discussion of /opt last year which resulted in its inclusion in the current draft. I'm probably not the best person at Caldera to sit on the list, but last year, I was involved in the packaging of several applications for Caldera's Solutions CD, and was interested in the community wisdom for where to place add-on apps. > > Erik and I are good friends, and he told me straight up why he isn't on the > FHS/FSSTND list any more. Our noise level is too high, and our productivity > is too low, because we don't have an agreed on set of goals or a conflict- > resolution mechanism that accords with them. I have continued to lurk, but the noise level is indeed too high. > > Erik fears rejoining the list would be a waste of his time and Red Hat's, > unless we can agree on a charter and a decision-making method that avoids > extended pissing matches. And lower our noise level. And not take > literally years to grind out essentially trivial revisions. Yea, verily. Tim Bird From list-relay@mailbox2.ucsd.edu Wed Jul 16 11:03:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA11662 for ; Wed, 16 Jul 1997 11:03:36 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA28012 for ; Wed, 16 Jul 1997 11:02:28 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA07298 for ; Wed, 16 Jul 1997 10:48:23 -0700 Received: from hottub.caldera.com (hottub.caldera.com [207.49.12.15]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA24862 for ; Wed, 16 Jul 1997 11:01:30 -0700 (PDT) Received: (qmail 25166 invoked from smtpd); 16 Jul 1997 17:58:18 -0000 Received: from caldera.com (207.49.12.1) by hottub.caldera.com with SMTP; 16 Jul 1997 17:58:18 -0000 Received: (from tbird@localhost) by caldera.com (8.8.6/8.8.6) id MAA24099; Wed, 16 Jul 1997 12:01:16 -0600 From: Tim Bird Message-Id: <199707161801.MAA24099@caldera.com> Subject: Re: FHS 2.0 - not the end of the world To: quinlan@pathname.com Date: Wed, 16 Jul 1997 12:01:15 -0600 (MDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: from "Daniel Quinlan" at Jul 15, 97 11:52:01 pm Content-Type: text Xref: sodium.transmeta.com linux.fhs:68 Status: RO Content-Length: 590 Lines: 16 > FHS 2.0 is not the end of the world. Version 2.1 will follow. The > 2.0 release comes closer to what the BSD and HURD people want. > > I agree that many problems still remain to be fixed, but the biggest > problem facing users of the FHS is the lack of a new standard and we > must consider the needs of those users who rely on FHS/FSSTND already. Agreed. > > Finally, FHS is ready to release in a form now that most everyone > agrees is a step forward. More importantly, most everyone agrees that > there are no steps backwards. So it will be released as-is. Thank you. Tim Bird From list-relay@mailbox1.ucsd.edu Wed Jul 16 11:29:42 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA12552 for ; Wed, 16 Jul 1997 11:29:41 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA28845 for ; Wed, 16 Jul 1997 11:28:33 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA07503 for ; Wed, 16 Jul 1997 11:14:29 -0700 Received: from hottub.caldera.com (hottub.caldera.com [207.49.12.15]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA03538 for ; Wed, 16 Jul 1997 11:26:57 -0700 (PDT) Received: (qmail 25674 invoked from smtpd); 16 Jul 1997 18:23:55 -0000 Received: from caldera.com (207.49.12.1) by hottub.caldera.com with SMTP; 16 Jul 1997 18:23:55 -0000 Received: (from tbird@localhost) by caldera.com (8.8.6/8.8.6) id MAA25464; Wed, 16 Jul 1997 12:26:51 -0600 From: Tim Bird Message-Id: <199707161826.MAA25464@caldera.com> Subject: Re: on how to proceed To: quinlan@pathname.com Date: Wed, 16 Jul 1997 12:26:49 -0600 (MDT) Cc: fhs-discuss@ucsd.edu In-Reply-To: from "Daniel Quinlan" at Jul 16, 97 04:25:31 am Content-Type: text Xref: sodium.transmeta.com linux.fhs:69 Status: RO Content-Length: 1593 Lines: 33 > Few people have even asked if a joint standard will really make things > better for Linux users. Realistically, it really won't matter that > much either way. The concept is more appealing for philosophical and > political reasons. "better for Linux users" should of course be taken in appropriate context. Even if Linux users are inconvenienced in the short term by placement gyrations, if it results in more application availability (because cross-development or cross-packaging is easier), then it could be a long term win. I am not interested in coordinating with BSD out of a spirit of brotherly love and nothing else. [...] > At worst, we will have a better idea of the differences between the > major free Unix-like systems and we can use that knowledge to improve I'd be happy if we took a stab at documenting gratuitous differences between major Linux distributions. > Linux, BSD, and HURD separately. At best, we will be able to move > forward together. I very much agree with your 5-point plan, for the reasons you mention here. Having ported a major application to Linux, and packaged it for use on multiple distributions (RedHat, Debian, and Caldera), I would have appreciated a list of file placement policy differences. In the end, I believe the differences between Unices have lead to the prevalent cop-out by major vendors who use the "everything in my own subtree" installation system. I ended up using this system myself because I wasn't fully aware of the policies among different Linux distributions (all of which claim to be FSSTND 1.2 compliant). Tim Bird From list-relay@mailbox1.ucsd.edu Thu Jul 17 08:49:41 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id IAA18450 for ; Thu, 17 Jul 1997 08:49:40 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id IAA20990 for ; Thu, 17 Jul 1997 08:48:32 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id IAA18443 for ; Thu, 17 Jul 1997 08:34:19 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id IAA28229 for ; Thu, 17 Jul 1997 08:44:23 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id LAA20544; Thu, 17 Jul 1997 11:44:13 -0400 (EDT) Date: Thu, 17 Jul 1997 11:44:13 -0400 (EDT) Message-Id: <199707171544.LAA20544@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: bsa@kf8nh.apk.net CC: fhs-discuss@ucsd.edu In-reply-to: "Brandon S. Allbery KF8NH"'s message of Wed, 16 Jul 97 13:26:41 -0400 <199707161732.NAA21195@speaker.kf8nh.apk.net> Subject: Re: Results of straw poll regarding /usr/libexec X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Windows: The first fully modular software disaster. Xref: ruthenium.transmeta.com linux.fhs:70 Status: RO Content-Length: 1059 Lines: 25 From: "Brandon S. Allbery KF8NH" Date: Wed, 16 Jul 97 13:26:41 -0400 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 My own question WRT the HURD is whether its basis is "close enough" to be capable of working with FHS. Some (old) examples seemed to imply it had a fairly different filesystem hierarchy --- if it's too different, trying to merge them in any fashion will accomplish nothing but frustrating everyone involved. Then again, the examples I saw *were* fairly old and I have no idea what it looks like now; they might not have been representative; and (d*mmit!) I don't have any spare systems around any more to toss HURD (or *BSD) onto to see for myself. :-( The hierarchy is just like Unix (and very close to BSD) except that /usr is a symlink to `.'. Everything that you put in /usr, we just put in /. (We have decoupled [in principle] the connection between mount points and where things visibly appear, so the only reason left for a real /usr is not relevant.) Thomas From list-relay@mailbox2.ucsd.edu Thu Jul 17 10:25:07 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA20993 for ; Thu, 17 Jul 1997 10:25:06 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA23803 for ; Thu, 17 Jul 1997 10:23:58 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA19222 for ; Thu, 17 Jul 1997 10:09:44 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id KAA28772 for ; Thu, 17 Jul 1997 10:20:18 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id NAA18935; Thu, 17 Jul 1997 13:21:43 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id NAA00340; Thu, 17 Jul 1997 13:06:08 -0400 Message-Id: <199707171706.NAA00340@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Thu, 17 Jul 97 13:02:09 -0400 To: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) In-Reply-To: <199707171544.LAA20544@churchy.gnu.ai.mit.edu> Cc: FHS discussion list Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29 Content-Type: text Xref: ruthenium.transmeta.com linux.fhs:71 Status: RO Content-Length: 1112 Lines: 22 In <199707171544.LAA20544@churchy.gnu.ai.mit.edu>, on 07/17/97 at 11:44 AM, thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) said: +----- | The hierarchy is just like Unix (and very close to BSD) except that /usr is | a symlink to `.'. Everything that you put in /usr, we just put in /. (We | have decoupled [in principle] the connection between +--->8 Makes sense; might be a little difficult to reconcile a few things, but OTOH that's probably a HURD-specific annex issue "on HURD, all directories placed by this standard in /usr are moved to /". I'm more worried about the idea that since we have enough trouble getting fairly similar systems together (even just the Linux ones!), trying to fit something radically different into the mix would be a nightmare. ("What, /bin? We don't use that, things go in /system/apps/standard and /host/maint." Made-up example... I hope!) -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox2.ucsd.edu Fri Jul 18 10:53:11 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id KAA24977 for ; Fri, 18 Jul 1997 10:53:10 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id KAA22758 for ; Fri, 18 Jul 1997 10:52:02 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id KAA31183 for ; Fri, 18 Jul 1997 10:37:37 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id KAA10206 for ; Fri, 18 Jul 1997 10:46:28 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id NAA24065; Fri, 18 Jul 1997 13:46:11 -0400 (EDT) Date: Fri, 18 Jul 1997 13:46:11 -0400 (EDT) Message-Id: <199707181746.NAA24065@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: ldeutsch@mail.netshop.net CC: fhs-discuss@ucsd.edu In-reply-to: ldeutsch@mail.netshop.net's message of Thu, 17 Jul 1997 20:53:22 -0800 <199707180353.UAA03692@freya.van.hookup.net> Subject: Re: What does GNU think of my /usr/libexec compromise? X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "The printer is using too much toner," Tom said darkly. Xref: ruthenium.transmeta.com linux.fhs:72 Status: RO Content-Length: 1974 Lines: 49 Michael Deutschmann asked me a question, but I think the answer is of more general interest. From: ldeutsch@mail.netshop.net Date: Thu, 17 Jul 1997 20:53:22 -0800 After the defeat of /usr/libexec on FHS, I tried to propose a compromise on the issue: support libexec for subprograms, but leave inetd/init launched programs in /usr/sbin. This is, I'm sorry to say, focusing on the WRONG thing. The reason for having special directories for commands is to arrange for them to be in paths searched by shells. The reason for separating /bin and /sbin is that there are some binaries which are of no interest to non-superusers. Some binaries are of no use on the command line. These binaries do not belong in /bin or /sbin. Whether a binary is of no use on the command line requires judgement, and may change over time as a program acquires new uses or loses old ones. Binaries that do not belong in /bin or /sbin need to be somewhere. Historically, they were placed in /etc and /usr/lib. When /sbin was created, some people unthinkingly moved all the binaries in /etc into /sbin. /libexec exists in order to move non-libraries out of /lib. It does not exist to move some commands out of /sbin. There may be some things in /sbin on some systems which do not belong there. They should be moved OUT. If there is a libexec, they belong there; otherwise, they belong in /lib. The existence of libexec does not change the bounds of sbin at all. But attention to the question of "should this be in root's path?" might cause the motion of some things out of sbin, which is a GOOD thing. "Init launched programs" is not a useful category for any of these distinctions. The question to ask is "is this program usefully placed in root's path?" For some programs launched by init (like, for example, the shell or the hostname command) the answer is "yes". For some programs (like, for instance, getty or in.rlogind) the answer is "no". Thomas From list-relay@mailbox2.ucsd.edu Fri Jul 18 11:39:30 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA26152 for ; Fri, 18 Jul 1997 11:39:29 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA24785 for ; Fri, 18 Jul 1997 11:38:21 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA31586 for ; Fri, 18 Jul 1997 11:23:57 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA13798 for ; Fri, 18 Jul 1997 11:37:03 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA27600; Fri, 18 Jul 97 14:36:53 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA02841; Fri, 18 Jul 1997 14:36:52 -0400 Date: Fri, 18 Jul 1997 14:36:52 -0400 Message-Id: <199707181836.OAA02841@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: thomas@gnu.ai.mit.edu Cc: ldeutsch@mail.netshop.net, fhs-discuss@ucsd.edu In-Reply-To: Thomas Bushnell, n/BSG's message of Fri, 18 Jul 1997 13:46:11 -0400 (EDT), <199707181746.NAA24065@churchy.gnu.ai.mit.edu> Subject: Re: What does GNU think of my /usr/libexec compromise? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: ruthenium.transmeta.com linux.fhs:73 Status: RO Content-Length: 928 Lines: 21 Date: Fri, 18 Jul 1997 13:46:11 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) Some binaries are of no use on the command line. These binaries do not belong in /bin or /sbin. Whether a binary is of no use on the command line requires judgement, and may change over time as a program acquires new uses or loses old ones. That's precisely the problem. Whether or not a program should be on the command-line or not became the subject of great debates, and so it became clear that using this as a criteraia of /sbin vs. /libexec didn't work well. Furthermore, you can't just blithely change this "over time" --- programs that expect /usr/lib/sendmail in a certain place won't be amused if it gets changed to /usr/sbin/sendmail one week, and /usr/libexec/sendmail the next, depending on those who are argueing over whether or not sendmail should be in the superuser's path. - Ted From list-relay@mailbox2.ucsd.edu Fri Jul 18 12:03:07 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id MAA26928 for ; Fri, 18 Jul 1997 12:03:06 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id MAA25501 for ; Fri, 18 Jul 1997 12:01:53 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA31784 for ; Fri, 18 Jul 1997 11:47:29 -0700 Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id MAA15556 for ; Fri, 18 Jul 1997 12:00:29 -0700 (PDT) From: t.sippel-dau@ic.ac.uk Received: from judy.ic.ac.uk [155.198.5.5] by romeo.ic.ac.uk with esmtp (Exim 1.62 #1) id 0wpIG9-0005no-00; Fri, 18 Jul 1997 20:00:10 +0100 Received: from cscmgb.cc.ic.ac.uk (sg1.cc.ic.ac.uk [155.198.63.8]) by judy.ic.ac.uk (8.7.5/8.7.5) with SMTP id TAA24124; Fri, 18 Jul 1997 19:59:40 +0100 (BST) Received: by cscmgb.cc.ic.ac.uk (940816.SGI.8.6.9/4.0) id TAA27832; Fri, 18 Jul 1997 19:59:40 +0100 Message-Id: <199707181859.TAA27832@cscmgb.cc.ic.ac.uk> Subject: Re: Results of straw poll regarding /usr/libexec To: bsa@kf8nh.apk.net (Brandon S. Allbery KF8NH) Date: Fri, 18 Jul 1997 19:59:39 +0100 (bst) Cc: thomas@gnu.ai.mit.edu, fhs-discuss@ucsd.edu In-Reply-To: <199707171706.NAA00340@speaker.kf8nh.apk.net> from "Brandon S. Allbery KF8NH" at Jul 17, 97 01:02:09 pm Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: ruthenium.transmeta.com linux.fhs:74 Status: RO Content-Length: 1369 Lines: 38 Hello, admitting that I voted "anything bu /usr/arch", I think if the lib vs libexec controversity is the only thing that is holding up the FHS, we should accept defeat and just document the divergent thinking. So, to advocate a compromise (and make all of the people extra unhappy, can we formulate along the lines: /usr/lib ... a directory for libraries and shared objects, it has also been used as a general purpose dumping ground for other kind of data files in /usr/lib should gradually be moved out of there into subdirectories of /usr/lib or /usr/libexec it should be clear that such directories must not have names that cause name clashes with libraries, in particular, should not incorporate a period When looking for a file, both /usr/lib and /usr/libexec should be searched, when placing a file, preference should be given to the directory that already exists on the target system. Thomas * email: cmaae47 @ imperial.ac.uk * voice: +44 171 594 7076 (day) * fax: +44 171 584 1560 * snail: Thomas Sippel - Dau * Information Services Manager * Center of Vibration Engineering * Imperial College of Science, Technology and Medicine * Exhibition Road * Kensington SW7 2BX * Great Britain From list-relay@mailbox1.ucsd.edu Fri Jul 18 12:07:07 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id MAA27073 for ; Fri, 18 Jul 1997 12:07:07 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id MAA25608 for ; Fri, 18 Jul 1997 12:05:59 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA31811 for ; Fri, 18 Jul 1997 11:51:34 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id MAA15460 for ; Fri, 18 Jul 1997 12:02:26 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id PAA24185; Fri, 18 Jul 1997 15:02:11 -0400 (EDT) Date: Fri, 18 Jul 1997 15:02:11 -0400 (EDT) Message-Id: <199707181902.PAA24185@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: tytso@mit.edu CC: ldeutsch@mail.netshop.net, fhs-discuss@ucsd.edu In-reply-to: "Theodore Y. Ts'o"'s message of Fri, 18 Jul 1997 14:36:52 -0400 <199707181836.OAA02841@dcl.MIT.EDU> Subject: Re: What does GNU think of my /usr/libexec compromise? X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Windows: Flawed beyond belief. Xref: ruthenium.transmeta.com linux.fhs:75 Status: RO Content-Length: 2354 Lines: 52 Date: Fri, 18 Jul 1997 14:36:52 -0400 From: "Theodore Y. Ts'o" Date: Fri, 18 Jul 1997 13:46:11 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) Some binaries are of no use on the command line. These binaries do not belong in /bin or /sbin. Whether a binary is of no use on the command line requires judgement, and may change over time as a program acquires new uses or loses old ones. That's precisely the problem. Whether or not a program should be on the command-line or not became the subject of great debates, and so it became clear that using this as a criteraia of /sbin vs. /libexec didn't work well. But that IS already the criterion between /sbin and /lib. It IS the criterion, because the only point to putting binaries in different directories is to conveniently accomodate the shell's path search algorithm. It has nothing to do with libexec. If you have no libexec, the difficult question is "should this go in /sbin or in /lib?" If you have libexec, the difficult question is "should this go in /sbin or in /libexec?" The very same difficult question exists no matter what. I expect people will not agree on where everything should go; that's not a real problem, because the standard does NOT need to tell everyone. Example for submission is the GNU coding standards--the standard does not dictate where particular programs go, but rather describe the guidelines that should inform the judgement of the program's author. Furthermore, you can't just blithely change this "over time" --- programs that expect /usr/lib/sendmail in a certain place won't be amused if it gets changed to /usr/sbin/sendmail one week, and /usr/libexec/sendmail the next, depending on those who are argueing over whether or not sendmail should be in the superuser's path. Can anyone think of an example where such a change has, in fact occured? That is, specifically, a change from "not in the shell path" to "in the shell path" or vice-versa. Sendmail was never in the shell path; rmt was only there by accident (because /etc was doing triple duty). Are there any cases where the proper placement in fact changes? I can't think of any; if there are a few, then that's harmless; symlinks are a suitable solution for small cases. Thomas From list-relay@mailbox1.ucsd.edu Fri Jul 18 13:23:53 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id NAA29566 for ; Fri, 18 Jul 1997 13:23:52 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id NAA28171 for ; Fri, 18 Jul 1997 13:22:44 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id NAA32693 for ; Fri, 18 Jul 1997 13:08:21 -0700 Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id NAA21411 for ; Fri, 18 Jul 1997 13:20:42 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id QAA09685 for fhs-discuss@ucsd.edu; Fri, 18 Jul 1997 16:22:05 -0400 (EDT) >Received: from rushlight (rushlight.kf8nh.apk.net [10.9.204.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with SMTP id PAA13339 for ; Fri, 18 Jul 1997 15:41:49 -0400 Message-Id: <199707181941.PAA13339@speaker.kf8nh.apk.net> From: "Brandon S. Allbery KF8NH" Date: Fri, 18 Jul 97 15:33:43 -0400 To: FHS discussion list In-Reply-To: <199707181902.PAA24185@churchy.gnu.ai.mit.edu> Subject: Re: What does GNU think of my /usr/libexec compromise? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.29j Content-Type: text Xref: ruthenium.transmeta.com linux.fhs:76 Status: RO Content-Length: 891 Lines: 22 In <199707181902.PAA24185@churchy.gnu.ai.mit.edu>, on 07/18/97 at 03:02 PM, thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) said: +----- | Can anyone think of an example where such a change has, in fact occured? | That is, specifically, a change from "not in the shell path" to "in the | shell path" or vice-versa. +--->8 /usr/sbin/uucico and /usr/sbin/uuxqt, on Linux, mainly because of FSSTND. Come to think of it, "we" moved sendmail too --- and ISTR one of the early "FSSTND-compliant" distributions not having a compatibility symlink. (To the tune of "Why'd MH break???" I'd made spost the default because post didn't work on non-networked systems.) -- brandon s. allbery [Team OS/2] net.apk.kf8nh@bsa cleveland, ohio mr/2 ice's "rfc guru" :-) FORZA CREW! (you can guess what to do to the address --- and why...) From list-relay@mailbox1.ucsd.edu Fri Jul 18 14:01:03 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id OAA00433 for ; Fri, 18 Jul 1997 14:01:02 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id NAA29134 for ; Fri, 18 Jul 1997 13:59:22 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id NAA00231 for ; Fri, 18 Jul 1997 13:44:55 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id NAA24522 for ; Fri, 18 Jul 1997 13:57:21 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA24141; Fri, 18 Jul 97 16:56:08 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id QAA03877; Fri, 18 Jul 1997 16:56:03 -0400 Date: Fri, 18 Jul 1997 16:56:03 -0400 Message-Id: <199707182056.QAA03877@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: thomas@gnu.ai.mit.edu Cc: ldeutsch@mail.netshop.net, fhs-discuss@ucsd.edu In-Reply-To: Thomas Bushnell, n/BSG's message of Fri, 18 Jul 1997 15:02:11 -0400 (EDT), <199707181902.PAA24185@churchy.gnu.ai.mit.edu> Subject: Re: What does GNU think of my /usr/libexec compromise? Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: ruthenium.transmeta.com linux.fhs:77 Status: RO Content-Length: 1421 Lines: 32 Date: Fri, 18 Jul 1997 15:02:11 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) But that IS already the criterion between /sbin and /lib. It IS the criterion, because the only point to putting binaries in different directories is to conveniently accomodate the shell's path search algorithm. Yes, but traditionally the inetd binaries weren't placed in /usr/lib. And in some cases, some of the inetd binaries could be run by hand, for one reason or another. I expect people will not agree on where everything should go; that's not a real problem, because the standard does NOT need to tell everyone. Example for submission is the GNU coding standards--the standard does not dictate where particular programs go, but rather describe the guidelines that should inform the judgement of the program's author. Well, that's a problem for interoperability. Where the "sendmail" binary is located can't be a matter of opinion --- that's the whole point of the FSSTND standard --- so programs can be able to count on where to find certain binaries in the interest of portability. Again, see my previous messages about differences in goals. It sounds like you're thinking about something like the GNU coding standards, which is not the same the original FSSTND goals. If we're going to make progress, we need to agree on what our goals are going to be. - Ted From list-relay@mailbox2.ucsd.edu Fri Jul 18 18:43:53 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id SAA07881 for ; Fri, 18 Jul 1997 18:43:52 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id SAA04761 for ; Fri, 18 Jul 1997 18:42:44 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id SAA02493 for ; Fri, 18 Jul 1997 18:28:18 -0700 Received: from freya.van.hookup.net (freya.van.hookup.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id SAA09767 for ; Fri, 18 Jul 1997 18:40:32 -0700 (PDT) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (kamloops-15.netshop.net [207.102.173.112]) by freya.van.hookup.net (8.8.6/1.25) with SMTP id SAA16237 for ; Fri, 18 Jul 1997 18:40:30 -0700 (PDT) Message-Id: <199707190140.SAA16237@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Fri, 18 Jul 1997 18:40:14 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: What does GNU think of my /usr/libexec compromise? Priority: normal X-mailer: Pegasus Mail for Windows (v2.54) Xref: ruthenium.transmeta.com linux.fhs:78 Status: RO Content-Length: 909 Lines: 21 This may be drifting into engineering rather than standardization, but... Why not ordain that "inetd" and "init" use the supervisor search path? It does have an advantage other than resolving this little debate. It would be quite useful to specify that all "interpackage" executions, like init calling getty, inetd calling ipop3d, or pine calling sendmail, be done through the path. This would make things more stable, since you could configure such packages to find companion packages regardless of whether they are installed in /usr/sbin or /usr/local/sbin. (or even /opt/sendmail/sbin...) Real "intrapackage" executions, such as "updatedb" calling "frcode", can safely use hard-coded paths instead, since the subprograms will never be reinstalled out of sync with the front-end program. Thus they, and they alone, belong in /usr/libexec. ---- Michael Deutschmann From list-relay@mailbox1.ucsd.edu Fri Jul 18 21:51:37 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id VAA13463 for ; Fri, 18 Jul 1997 21:51:37 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id VAA09415 for ; Fri, 18 Jul 1997 21:50:29 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id VAA03620 for ; Fri, 18 Jul 1997 21:36:02 -0700 Received: from wauug.erols.com (wauug.erols.com [207.96.122.8]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id VAA15021 for ; Fri, 18 Jul 1997 21:48:51 -0700 (PDT) Received: from localhost (niemi@localhost) by wauug.erols.com (8.8.5/8.8.5) with SMTP id AAA04142 for ; Sat, 19 Jul 1997 00:48:50 -0400 Date: Sat, 19 Jul 1997 00:48:50 -0400 (EDT) From: David C Niemi To: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: <199707181859.TAA27832@cscmgb.cc.ic.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:79 Status: RO Content-Length: 553 Lines: 12 Regardless of the exact formulation of the /usr/libexec definition, it still seems quite odd to me to take /usr/libexec out of FHS at "Linux people's" request, when a very large percentage of recent Linux systems (e.g. any modern Red Hat systems) already have /usr/libexec. David Niemi@erols.com 703-810-5538 Reston, Virginia, USA --- Most operating systems, sometimes even DOS, separate different --- types of files into different directories. The Windows philosophy: --- Throw everything into C:\WINDOWS and let God sort it out. From list-relay@mailbox1.ucsd.edu Fri Jul 18 23:37:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id XAA17144 for ; Fri, 18 Jul 1997 23:37:36 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id XAA10565 for ; Fri, 18 Jul 1997 23:36:28 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id XAA04232 for ; Fri, 18 Jul 1997 23:22:00 -0700 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id XAA17136 for ; Fri, 18 Jul 1997 23:26:35 -0700 (PDT) Received: by proton id m0wpSyQ-0002R9C (Debian Smail-3.2 1996-Jul-4 #2); Fri, 18 Jul 1997 23:26:34 -0700 (PDT) Message-Id: Date: Fri, 18 Jul 1997 23:26:34 -0700 (PDT) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: Re: Results of straw poll regarding /usr/libexec In-Reply-To: References: <199707181859.TAA27832@cscmgb.cc.ic.ac.uk> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: sodium.transmeta.com linux.fhs:80 Status: RO Content-Length: 1179 Lines: 35 -----BEGIN PGP SIGNED MESSAGE----- David C Niemi writes: > Regardless of the exact formulation of the /usr/libexec definition, > it still seems quite odd to me to take /usr/libexec out of FHS at > "Linux people's" request, when a very large percentage of recent > Linux systems (e.g. any modern Red Hat systems) already have > /usr/libexec. The complete RedHat 4.1 installation has one subdirectory of /usr/libexec, /usr/libexec/awk. It also has 54 subdirectories of /usr/lib which contain application- specific architecture-specific data. The decision to remove /usr/libexec was not the direct result of voting. There was a straw-poll, not a democratic vote. As editor, I believe there was sufficent reason to postpone the inclusion of /usr/libexec into the next release. I wanted to conduct a straw poll to make sure I wasn't part of a miniscule minority. - Dan -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBM9BeGKkybebRDjw1AQFV1QP+IhzMmhqFYNGOQ29/J/X2ZZMffsOO06Ju VeNg2+CzSNwoLd1nUwg4QSPMW7jcoykcpQaZqhIztd5l8OuqSBA2SHQreGT4MJfm lEJxpPXtZmguGd6e/A41MFTP7OcMDyyqz2UUz8nUm346i4NlY7Fe2agbcKdmEwjT JhIHgnB9H0g= =3I0N -----END PGP SIGNATURE----- From list-relay@mailbox1.ucsd.edu Sun Jul 20 16:20:23 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id QAA05806 for ; Sun, 20 Jul 1997 16:20:23 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id QAA09133 for ; Sun, 20 Jul 1997 16:19:14 -0700 Received: from mailbox1.ucsd.edu (mailbox.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id QAA16391 for ; Sun, 20 Jul 1997 16:04:31 -0700 Received: from muenster.westfalen.de (muenster.westfalen.de [195.52.199.2]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with SMTP id QAA04411 for ; Sun, 20 Jul 1997 16:16:46 -0700 (PDT) Received: from khms.westfalen.de by muenster.westfalen.de via rsmtp with bsmtp id for ; Mon, 21 Jul 1997 01:03:33 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1 built 1996-Nov-13) Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 21 Jul 1997 00:57:05 +0200 Date: 20 Jul 1997 23:39:00 +0200 From: kai@khms.westfalen.de (Kai Henningsen) To: fhs-discuss@UCSD.EDU Message-ID: <6aENAQGUcsB@khms.westfalen.de> In-Reply-To: <199707102251.PAA15075@freya.van.hookup.net> Subject: Re: Results of straw poll regarding /usr/libexec X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <199707102251.PAA15075@freya.van.hookup.net> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Xref: francium.transmeta.com linux.fhs:81 Status: RO Content-Length: 378 Lines: 12 ldeutsch@mail.netshop.net wrote on 10.07.97 in <199707102251.PAA15075@freya.van.hookup.net>: > How about this replacement: > > Examples of programs located in /usr/libexec include the "updatedb" > subprograms (code, frcode, bigram) and the nameserver zone transfer > program (named-xfer). named-xfer is another bad example. It belongs (at least) on the admin $PATH. MfG Kai From list-relay@mailbox2.ucsd.edu Mon Jul 21 09:51:11 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA28327 for ; Mon, 21 Jul 1997 09:51:10 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA20130 for ; Mon, 21 Jul 1997 09:50:02 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA22542 for ; Mon, 21 Jul 1997 09:35:07 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA10319 for ; Mon, 21 Jul 1997 09:47:41 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id MAA10921; Mon, 21 Jul 1997 12:46:56 -0400 (EDT) Date: Mon, 21 Jul 1997 12:46:56 -0400 (EDT) Message-Id: <199707211646.MAA10921@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: ldeutsch@mail.netshop.net CC: fhs-discuss@ucsd.edu In-reply-to: ldeutsch@mail.netshop.net's message of Fri, 18 Jul 1997 18:40:14 -0800 <199707190140.SAA16237@freya.van.hookup.net> Subject: Re: What does GNU think of my /usr/libexec compromise? X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "I'm all out of soda-pop," Tom said effervescently. Xref: technetium.transmeta.com linux.fhs:82 Status: RO Content-Length: 256 Lines: 11 From: ldeutsch@mail.netshop.net Date: Fri, 18 Jul 1997 18:40:14 -0800 Why not ordain that "inetd" and "init" use the supervisor search path? Why not, INSTEAD, have a different path for such things? They are totally different tasks. Thomas From list-relay@mailbox2.ucsd.edu Mon Jul 21 09:51:15 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id JAA28334 for ; Mon, 21 Jul 1997 09:51:15 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id JAA20131 for ; Mon, 21 Jul 1997 09:50:02 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id JAA22541 for ; Mon, 21 Jul 1997 09:35:06 -0700 Received: from churchy.gnu.ai.mit.edu (churchy.gnu.ai.mit.edu [128.52.46.32]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id JAA10040 for ; Mon, 21 Jul 1997 09:45:01 -0700 (PDT) Received: by churchy.gnu.ai.mit.edu (8.8.5/8.6.12GNU) id MAA10911; Mon, 21 Jul 1997 12:43:59 -0400 (EDT) Date: Mon, 21 Jul 1997 12:43:59 -0400 (EDT) Message-Id: <199707211643.MAA10911@churchy.gnu.ai.mit.edu> From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) To: tytso@mit.edu CC: ldeutsch@mail.netshop.net, fhs-discuss@ucsd.edu In-reply-to: "Theodore Y. Ts'o"'s message of Fri, 18 Jul 1997 16:56:03 -0400 <199707182056.QAA03877@dcl.MIT.EDU> Subject: Re: What does GNU think of my /usr/libexec compromise? X-Name-Change: My name used to be `Michael'; now it is `Thomas'. X-Tom-Swiftie: "My feet hurt," Tom said pedantically. Xref: technetium.transmeta.com linux.fhs:83 Status: RO Content-Length: 1055 Lines: 27 Date: Fri, 18 Jul 1997 16:56:03 -0400 From: "Theodore Y. Ts'o" Date: Fri, 18 Jul 1997 15:02:11 -0400 (EDT) From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) But that IS already the criterion between /sbin and /lib. It IS the criterion, because the only point to putting binaries in different directories is to conveniently accomodate the shell's path search algorithm. Yes, but traditionally the inetd binaries weren't placed in /usr/lib. They were placed in /etc, which did double duty, holding both things that belonged in the path and things that didn't. And in some cases, some of the inetd binaries could be run by hand, for one reason or another. The issue is not "can I ever meaningfully run this from the shell?" That's not useful. GNU libc can be run from the shell, too. So can ld.so. But these are not things that you want in the *path*. If the inetd binaries are only run by hand for debugging them, then this does not mean they should be in the path. Thomas From list-relay@mailbox2.ucsd.edu Mon Jul 21 11:42:36 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id LAA04720 for ; Mon, 21 Jul 1997 11:42:35 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id LAA23836 for ; Mon, 21 Jul 1997 11:41:21 -0700 Received: from mailbox2.ucsd.edu (mailbox.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id LAA23593 for ; Mon, 21 Jul 1997 11:26:30 -0700 Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id LAA26735 for ; Mon, 21 Jul 1997 11:38:27 -0700 (PDT) From: t.sippel-dau@ic.ac.uk Received: from judy.ic.ac.uk [155.198.5.5] by romeo.ic.ac.uk with esmtp (Exim 1.62 #1) id 0wqNJP-0001si-02; Mon, 21 Jul 1997 19:35:59 +0100 Received: from cscmgb.cc.ic.ac.uk (sg1.cc.ic.ac.uk [155.198.63.8]) by judy.ic.ac.uk (8.7.5/8.7.5) with SMTP id TAA23319; Mon, 21 Jul 1997 19:35:48 +0100 (BST) Received: by cscmgb.cc.ic.ac.uk (940816.SGI.8.6.9/4.0) id TAA25291; Mon, 21 Jul 1997 19:35:47 +0100 Message-Id: <199707211835.TAA25291@cscmgb.cc.ic.ac.uk> Subject: Re: What does GNU think of my /usr/libexec compromise? To: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) Date: Mon, 21 Jul 1997 19:35:47 +0100 (bst) Cc: ldeutsch@mail.netshop.net, fhs-discuss@ucsd.edu In-Reply-To: <199707211646.MAA10921@churchy.gnu.ai.mit.edu> from "Thomas Bushnell, n/BSG" at Jul 21, 97 12:46:56 pm Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: technetium.transmeta.com linux.fhs:84 Status: RO Content-Length: 757 Lines: 22 The keyboard of Thomas Bushnell, n/BSG emitted at some point in time: > > From: ldeutsch@mail.netshop.net > > Why not ordain that "inetd" and "init" use the supervisor search > path? > > Why not, INSTEAD, have a different path for such things? They are > totally different tasks. init runs *before* a system manager can get a look-in (apart from lilo) and should really be configured with absolute paths. Inetd could well have its own path, and it would make many things easier if it had and used it to find the daemons in mentioned in /etc/inetd.conf. The benefit will be clear to anybody who tried to run tcp wrappers or write a drop-in install script for them. Thomas * email: cmaae47 @ imperial.ac.uk From list-relay@mailbox2.ucsd.edu Thu Jul 24 16:32:35 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.6/8.8.5) with ESMTP id QAA11324 for ; Thu, 24 Jul 1997 16:32:34 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id QAA04086 for ; Thu, 24 Jul 1997 16:31:26 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.5/8.8.5) with ESMTP id QAA25727 for ; Thu, 24 Jul 1997 16:16:05 -0700 Received: from freya.van.hookup.net (freya.van.hookup.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id QAA28446 for ; Thu, 24 Jul 1997 16:28:16 -0700 (PDT) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (kamloops-32.netshop.net [207.102.173.131]) by freya.van.hookup.net (8.8.6/1.25) with SMTP id QAA05991 for ; Thu, 24 Jul 1997 16:28:08 -0700 (PDT) Message-Id: <199707242328.QAA05991@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Thu, 24 Jul 1997 16:27:45 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: What does GNU think of my /usr/libexec compromise? Priority: normal In-reply-to: <199707211646.MAA10921@churchy.gnu.ai.mit.edu> References: ldeutsch@mail.netshop.net's message of Fri, 18 Jul 1997 18:40:14 -0800 <199707190140.SAA16237@freya.van.hookup.net> X-mailer: Pegasus Mail for Windows (v2.54) Xref: sodium.transmeta.com linux.fhs:85 Status: RO Content-Length: 1014 Lines: 27 > From: ldeutsch@mail.netshop.net > Date: Fri, 18 Jul 1997 18:40:14 -0800 > > Why not ordain that "inetd" and "init" use the supervisor search > path? > > Why not, INSTEAD, have a different path for such things? They are > totally different tasks. > > Thomas Because the two types are not disjoint. With SysKLogd, "syslogd" is a shell-launched program. "syslogd -n" is an init-launched program. And the number of programs like this will only increase as time goes on. If they were disjoint, it would make sense to keep such files in a small other directory, for more efficent searching. (And, IMO, such a directory would be distinct from /usr/libexec, which I would reserve for private backends.) But, since they aren't, in practice this path would also need to include the entire supervisor path, so there is little advantage. (even assuming that programmers will cozy to the notion of a third path, which is by no means assured.) ---- Michael Deutschmann From list-relay@mailbox2.ucsd.edu Sun Oct 26 01:46:01 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id BAA22623 for ; Sun, 26 Oct 1997 01:46:00 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id BAA08117 for ; Sun, 26 Oct 1997 01:41:52 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id BAA16958 for ; Sun, 26 Oct 1997 01:35:18 -0800 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id BAA06651 for ; Sun, 26 Oct 1997 01:40:13 -0800 (PST) Received: by proton id m0xPPB8-0008YgC (Debian Smail-3.2 1996-Jul-4 #2); Sun, 26 Oct 1997 01:40:14 -0800 (PST) Message-Id: Date: Sun, 26 Oct 1997 01:40:14 -0800 (PST) From: Daniel Quinlan To: fhs-discuss@ucsd.edu Subject: FHS 2.0 - new filesystem hierarchy standard X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: sodium.transmeta.com linux.fhs:86 Status: RO Content-Length: 2828 Lines: 72 I just sent this announcement thing to the comp.os.linux.announce submission address. I added a RATIONALE for /var/mail, removed the superfluous change of /var/state/cron (now back to /var/spool/cron), and made a few other small changes (removed the trademark section, but left the trademark disclaimer) since the pre 2.0 draft. (Well, maybe some of those changes where in the pre 2.0 draft, but I didn't check.) Well, I guess we should celebrate. :-) BTW, I'm at the USENIX LISA '97 conference in San Diego. If anyone wants to start work on any of the things I promise at the end of the announcement, please do (and let me know). A FAQ for the web site would also be good. I also want to thank the people who started nagging me recently. - Dan -----BEGIN PGP SIGNED MESSAGE----- I am pleased to announce the release of FHS 2.0, a new filesystem hierarchy standard for Linux and other Unix-like operating systems. FHS defines a common arrangement of the many files and directories in Unix-like systems (the filesystem hierarchy) that different developers (primarily Linux ones) have agreed to use. See below for details on retrieving the standard. FHS 2.0 is the direct successor for FSSTND 1.2, which is currently implemented by most major Linux distributions (I've lost track, but the list includes Red Hat, Debian, and others. I am interested in hearing from compliant and non-compliant developers). The name was changed because we didn't like the old one, which was somewhat misleading, difficult to enunciate, and usually spelled wrong. It has been while since FSSTND 1.2, so there have been some significant, but sorely needed changes. Some tweaks and clarifications may be necessary. If so, the FHS group will release a 2.1 version as soon as is feasible. However, we will continue work hard to avoid superfluous changes to the standard. Finally, the FHS is not really directed at end-users. The intended audience are the implementors of Linux and Unix distributions, applications, documentation, etc. Still, many system administrators and users have found the standard a useful resource. The release is available at: ftp://ftp.pathname.com/pub/ ftp://tsx-11.mit.edu/pub/linux/docs/linux-standards/fsstnd/ Finally, supplementary information such as transition notes, a list of changes since 1.2, and an updated hier.7 manual page will be made available at the FHS web site as soon as they are finished. http://www.pathname.com/fhs/ Daniel Quinlan FHS editor -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBNFMN46kybebRDjw1AQEb1QP9FCZWsP7quqZjNZz3sdGrSfNEN5f9HlA9 /n/eAwjC57avcK1Yzu1UDZa0Y+t6EeTnhl5cOpE8hsHRKAFZnN4obK9zHJWg2YQP Ss9qkwDxdUqjvi6iBjZdTsJyFPFziakig5EnIKIExmedz3AvrYe7is+JRrJ5Avtr lvDzKsP3T4I= =cvt5 -----END PGP SIGNATURE----- From list-relay@mailbox2.ucsd.edu Sun Nov 2 23:43:02 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id XAA12113 for ; Sun, 2 Nov 1997 23:43:01 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id XAA11630 for ; Sun, 2 Nov 1997 23:37:05 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id XAA02210 for ; Sun, 2 Nov 1997 23:31:06 -0800 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id XAA28589 for ; Sun, 2 Nov 1997 23:33:25 -0800 (PST) Received: by proton id m0xSH0n-0009ChC (Debian Smail-3.2 1996-Jul-4 #2); Sun, 2 Nov 1997 23:33:25 -0800 (PST) Message-Id: Date: Sun, 2 Nov 1997 23:33:25 -0800 (PST) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: FHS news, listing of changes X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: sodium.transmeta.com linux.fhs:87 Status: RO Content-Length: 2028 Lines: 51 -----BEGIN PGP SIGNED MESSAGE----- Someone has indicated that he is working on a French translation of the FHS. If you're working (or would like to work) on a translation, please get in contact with me to avoid duplicated effort. I also put up a brief listing of changes from FSSTND 1.2 to FHS 2.0 on the web site . I'll fill it out more in the next few days. Suggestions and changes to me at quinlan@pathname.com. Thanks. - - Dan CHANGES FROM FSSTND 1.2 TO FHS 2.0 Before you make any comments on these changes, please read the entire FHS document. Many of these changes are interdependent or are due to factors outside of our control. The rationale for all of these changes is in the FHS document. o Non-technical changes * Abstract rewritten. * Removed list of trademarks, but retained trademark and copyright disclaimer. It was unnecessary and difficult to maintain. * Copying terms changed to be more open and to allow translations without a license. * Most of the introduction restructured and/or rewritten. o Major Structural Changes * Specifications specific to Linux were moved out of the main body into a Linux annex. * "Issues and Rationale" section removed, rationale information now follows most technical sections. o Major Technical Changes (i.e., not all of them) * /opt, /etc/opt, and /var/opt added. * /usr/share added (and many associated changes). * /usr/adm and /usr/preserve compatibility symbolic links removed. * /usr/etc directory removed. * /var/cache added. * /var/lib removed. * /var/state added. -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBNF1+P6kybebRDjw1AQGKywP/TowTNA1ucYWic50RL4xGfgR8TzIdiosg SOboC0zVibL+YUf021hgsJs0deBp5yMq13G/WZneZx2rjU0POw4NgXRXg9EXtfOx 4s3fC6hjCP61WTeu71PLghqEyTIfUvhjnaefLUSW+84MvhUwchqa8xFRfKe9wOAm LUDdulPs17c= =sFGK -----END PGP SIGNATURE----- From list-relay@mailbox1.ucsd.edu Sun Nov 16 01:33:59 1997 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id BAA27351 for ; Sun, 16 Nov 1997 01:33:57 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id BAA32365 for ; Sun, 16 Nov 1997 01:28:01 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id BAA20889 for ; Sun, 16 Nov 1997 01:20:02 -0800 Received: from proton (proton.pathname.com [204.145.147.37]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id BAA16760 for ; Sun, 16 Nov 1997 01:23:58 -0800 (PST) Received: by proton id m0xX0vt-000A1QC (Debian Smail-3.2 1996-Jul-4 #2); Sun, 16 Nov 1997 01:23:57 -0800 (PST) Message-Id: Date: Sun, 16 Nov 1997 01:23:57 -0800 (PST) From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: additions to FHS web site X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@pathname.com Xref: sodium.transmeta.com linux.fhs:88 Status: RO Content-Length: 457 Lines: 14 Howdy, I made some updates to the FHS web site: http://www.pathname.com/fhs/ Most significantly, it now includes an HTML version of FHS 2.0. It was translated using a development version the best troff2html program available, which now includes tbl2html and tree2html (the troff pic directory trees in FHS). No more gifs. :-) I also received some email comments on FHS 2.0 from various people, which I will summarize and forward to the list. - Dan From list-relay@mlist.ucsd.edu Thu Jan 8 14:22:22 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id OAA22015 for ; Thu, 8 Jan 1998 14:22:21 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id OAA02589 for ; Thu, 8 Jan 1998 14:15:56 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id OAA08754 for ; Thu, 8 Jan 1998 14:17:12 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.5/8.6.9) with ESMTP id OAA05410 for ; Thu, 8 Jan 1998 14:13:29 -0800 (PST) Received: from freya.van.hookup.net (ns2.vphos.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id OAA27188 for ; Thu, 8 Jan 1998 14:13:24 -0800 (PST) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (ts1-11.kamloops.wkpowerlink.com [207.194.192.11]) by freya.van.hookup.net (8.8.6/1.25) with SMTP id OAA15547 for ; Thu, 8 Jan 1998 14:13:15 -0800 (PST) Message-Id: <199801082213.OAA15547@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Thu, 8 Jan 1998 14:13:09 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Let's get back to discussing /usr/libexec Priority: normal X-mailer: Pegasus Mail for Windows (v2.54) Xref: sodium.transmeta.com linux.fhs:160 Status: RO Content-Length: 1490 Lines: 30 Now that 2.0 is released and the dust has settled, I think it's time we got /usr/libexec back on track. (For those who joined after Aug '97: /usr/libexec is a directory for applications' internal executables. It is intended to, with /usr/share, eventually remove all non-programming cruft from /usr/lib. It was to appear in 2.0 but was suddenly removed shortly before the release.) Now that we are no longer under pressure, I'd like to refloat my proposal for a solution. That is, libexec is reinstated, but does not claim programs such as inetd-launched daemons, which are left to /usr/sbin. /usr/sbin is for programs that present a public interface to the sysadmin *or* other packages (sendmail, telnetd). /usr/libexec is for programs that are only used inside the package (frcode,pwcat). Also still on the table is Bushnell's definition, which would have /usr/libexec specifically claim all executable files not useful from the command-line, thus covering both classes of file. It has a flaw (ambigous placement of some modern daemons), but is apparently entrenched on BSD distributions. I don't think the latter definition is well supported here, but I could be wrong. (I fomulated my own proposal based on the contention that the `Linux Camp' voted down the original libexec because they objected to the raid on /usr/sbin. However, some say it lost only because the poll caught the BSD representatives offguard.) ---- Michael Deutschmann From list-relay@mlist.ucsd.edu Thu Jan 8 15:43:08 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id PAA25606 for ; Thu, 8 Jan 1998 15:43:07 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id PAA06830 for ; Thu, 8 Jan 1998 15:36:41 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id PAA09676 for ; Thu, 8 Jan 1998 15:38:01 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.5/8.6.9) with ESMTP id PAA08278 for ; Thu, 8 Jan 1998 15:39:07 -0800 (PST) Received: from vega.math.ualberta.ca (vega.math.ualberta.ca [129.128.88.12]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with SMTP id PAA06996 for ; Thu, 8 Jan 1998 15:39:05 -0800 (PST) Received: from sherwood by vega.math.ualberta.ca with smtp (Exim 1.62 #7) id 0xqRUx-00076g-00 (Debian); Thu, 8 Jan 1998 16:36:27 -0700 Date: Thu, 8 Jan 1998 16:36:27 -0700 (MST) From: Sherwood Botsford To: ldeutsch@mail.netshop.net cc: fhs-discuss@ucsd.edu Subject: Re: Let's get back to discussing /usr/libexec In-Reply-To: <199801082213.OAA15547@freya.van.hookup.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:161 Status: RO Content-Length: 2880 Lines: 68 On Thu, 8 Jan 1998 ldeutsch@mail.netshop.net wrote: = Now that 2.0 is released and the dust has settled, I think it's time = we got /usr/libexec back on track. = = (For those who joined after Aug '97: /usr/libexec is a directory for = applications' internal executables. It is intended to, with = /usr/share, eventually remove all non-programming cruft from = /usr/lib. It was to appear in 2.0 but was suddenly removed shortly = before the release.) Umm... If program/subsystems are big enough to need a bunch of additional executables that only they call, they are big enough that they should have their own subtree such as packages in /opt do. Otherwise, if I write a package, mammal that in turn calls cat, rat, and kangaroo, and some guy writes a package called marsupial that calls kangaroo, how do we keep from stomping all over eachother? Also, how do you decide? Some people think that gs is something that only masages files so that GhostView can paint your screen. Others think that it's a usefull tool in it's own right. Ditto sendmail. I suggest that the simplest way would be to put the adjunct programs in the same */bin directory as the calling program is, assuming they are from the same packager. (E.g. a new MUA may still call the default sendmail.) Linux blurs the line between vendor software and add-on software. But they aren't alone. HPUX ships with a vanilla cc that is in /bin but sells an addon ansi-c that installes to /opt. This problem is closely related to the /opt discussion earlier. = = Now that we are no longer under pressure, I'd like to refloat my = proposal for a solution. That is, libexec is reinstated, but does not = claim programs such as inetd-launched daemons, which are left to = /usr/sbin. /usr/sbin is for programs that present a public interface = to the sysadmin *or* other packages (sendmail, telnetd). /usr/libexec = is for programs that are only used inside the package (frcode,pwcat). = = Also still on the table is Bushnell's definition, which would have = /usr/libexec specifically claim all executable files not useful from = the command-line, thus covering both classes of file. It has a flaw = (ambigous placement of some modern daemons), but is apparently = entrenched on BSD distributions. = = I don't think the latter definition is well supported here, but I = could be wrong. (I fomulated my own proposal based on the contention = that the `Linux Camp' voted down the original libexec because they = objected to the raid on /usr/sbin. However, some say it lost only = because the poll caught the BSD representatives offguard.) = = ---- Michael Deutschmann = Sherwood Botsford | email avatar@vega.math.ualberta.ca Sorcerers Apprentice | Office CAB 642B System Administrator | Tel: 403 492 5728 Trouble shooter | Fax: 403 492 6826 From list-relay@mlist.ucsd.edu Thu Jan 8 17:33:24 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id RAA00161 for ; Thu, 8 Jan 1998 17:33:23 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id RAA11553 for ; Thu, 8 Jan 1998 17:26:57 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id RAA10612 for ; Thu, 8 Jan 1998 17:28:16 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.5/8.6.9) with ESMTP id RAA12384 for ; Thu, 8 Jan 1998 17:30:32 -0800 (PST) Received: from interserv1.customcpu.com (interserv1.customcpu.com [198.70.210.35]) by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id RAA21372 for ; Thu, 8 Jan 1998 17:30:30 -0800 (PST) Received: from customcpu.com ([198.70.210.202]) by interserv1.customcpu.com (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-42538U2500L250S0) with ESMTP id AAA109 for ; Thu, 8 Jan 1998 16:36:39 -0900 Message-ID: <34B57DD9.944ABCBB@customcpu.com> Date: Thu, 08 Jan 1998 16:31:07 -0900 From: Fielder George Dowding Reply-To: iceworm@customcpu.com Organization: Iceworm Enterprises X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: fhs-discuss@ucsd.edu Subject: Re: Let's get back to discussing /usr/libexec References: <199801082213.OAA15547@freya.van.hookup.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:162 Status: RO Content-Length: 2684 Lines: 57 ldeutsch@mail.netshop.net wrote: > Now that 2.0 is released and the dust has settled, I think it's time > we got /usr/libexec back on track. > > (For those who joined after Aug '97: /usr/libexec is a directory for > applications' internal executables. It is intended to, with > /usr/share, eventually remove all non-programming cruft from > /usr/lib. It was to appear in 2.0 but was suddenly removed shortly > before the release.) > > Now that we are no longer under pressure, I'd like to refloat my > proposal for a solution. That is, libexec is reinstated, but does not > claim programs such as inetd-launched daemons, which are left to > /usr/sbin. /usr/sbin is for programs that present a public interface > to the sysadmin *or* other packages (sendmail, telnetd). /usr/libexec > is for programs that are only used inside the package (frcode,pwcat). > > Also still on the table is Bushnell's definition, which would have > /usr/libexec specifically claim all executable files not useful from > the command-line, thus covering both classes of file. It has a flaw > (ambigous placement of some modern daemons), but is apparently > entrenched on BSD distributions. > > I don't think the latter definition is well supported here, but I > could be wrong. (I fomulated my own proposal based on the contention > that the `Linux Camp' voted down the original libexec because they > objected to the raid on /usr/sbin. However, some say it lost only > because the poll caught the BSD representatives offguard.) > > ---- Michael Deutschmann I have already posted my horror at discovering this hierarchy in recently (Dec 97) downloaded version of the Slackware distribution, to wit: /usr/libexec/awk/ which contains: grcat and pwcat Both files are executable binaries so according the definition are properly there. What boggles my mind is why they are not in one of the sbin's where the SysAdm would expect to find handy tools to help with system administration chores. There is a second subdirectory, to wit: /usr/libexec/yp/ which contains tools for the NDS (formerly called "yellow pages" but BT has the copyright/trademark or whatever so it can't be used but the name of the subdirectory and some executables still use the letters "yp"). There are eight executable binaries, but my mind is still boggled as to why the need for ./libexec/. ---------- Cheerio! from: iceworm@customcpu.com (personal: fgd@alaska.net) Fielder George Dowding dba Iceworm Enterprises since 1976. Now at the North East edge of Spenard (originally an homestead) near the corner of 36th Avenue and Arctic Boulevard, in Beautiful, Anchorage, Alaska, USA ---------- From list-relay@mlist.ucsd.edu Fri Jan 9 16:15:42 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.7/8.8.5) with ESMTP id QAA09570 for ; Fri, 9 Jan 1998 16:15:40 -0800 (PST) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.5/8.8.4) with ESMTP id QAA21293 for ; Fri, 9 Jan 1998 16:09:15 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.7/8.8.5) with ESMTP id QAA21703 for ; Fri, 9 Jan 1998 16:10:24 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.5/8.6.9) with ESMTP id QAA10336 for ; Fri, 9 Jan 1998 16:10:16 -0800 (PST) Received: from freya.van.hookup.net (ns2.vphos.net [207.102.129.2]) by mailbox2.ucsd.edu (8.8.5/8.6.9) with ESMTP id QAA18118 for ; Fri, 9 Jan 1998 16:10:08 -0800 (PST) From: ldeutsch@mail.netshop.net Received: from aziraphale.talamasca (ts1-29.kamloops.wkpowerlink.com [207.194.192.29]) by freya.van.hookup.net (8.8.6/1.25) with SMTP id QAA05458 for ; Fri, 9 Jan 1998 16:10:05 -0800 (PST) Message-Id: <199801100010.QAA05458@freya.van.hookup.net> Comments: Authenticated sender is To: fhs-discuss@ucsd.edu Date: Fri, 9 Jan 1998 16:10:00 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Let's get back to discussing /usr/libexec Priority: normal References: <199801082213.OAA15547@freya.van.hookup.net> In-reply-to: X-mailer: Pegasus Mail for Windows (v2.54) Xref: sodium.transmeta.com linux.fhs:164 Status: RO Content-Length: 1251 Lines: 33 Sherwood Botsford said: > Umm... > If program/subsystems are big enough to need a bunch of additional > executables that only they call, they are big enough that they should > have their own subtree such as packages in /opt do. GNU findutils isn't very big (IMO), but it has three such files. > Otherwise, if I write a package, mammal that in turn calls cat, rat, > and kangaroo, and some guy writes a package called marsupial that calls > kangaroo, how do we keep from stomping all over eachother? /usr/libexec/mammal/cat /usr/libexec/mammal/rat /usr/libexec/mammal/kangaroo /usr/libexec/marsupial/kangaroo > Also, how do you decide? Some people think that gs is something > that only masages files so that GhostView can paint your screen. > Others think that it's a usefull tool in it's own right. > > Ditto sendmail. Ghostscript is clearly a /usr/bin program, since it is used from the command line by ordinary users. As for sendmail, under my proposal it goes in /usr/sbin because it is intended to be a public interface for any user mail software. It *is* ambigous under Bushnell's definition (although most BSD systems apparently use libexec). That's the flaw I referred to. ---- Michael Deutschmann From list-relay@mlist.ucsd.edu Tue May 5 06:27:27 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id GAA00400 for ; Tue, 5 May 1998 06:27:25 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id GAA22239 for ; Tue, 5 May 1998 06:25:48 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id GAA19001 for ; Tue, 5 May 1998 06:19:16 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id GAA21768 for ; Tue, 5 May 1998 06:04:57 -0700 (PDT) Received: from massu.cenatls.cena.dgac.fr (massu.cenatls.cena.dgac.fr [143.196.1.148]) by mailbox2.ucsd.edu (8.8.8/8.6.9) with ESMTP id GAA17737 for ; Tue, 5 May 1998 06:04:54 -0700 (PDT) Received: from satie.cenatls.cena.dgac.fr (damiano@satie [143.196.1.178]) by massu.cenatls.cena.dgac.fr (8.8.7/8.8.7) with ESMTP id PAA24023 for ; Tue, 5 May 1998 15:04:49 +0200 (MET DST) Received: (from damiano@localhost) by satie.cenatls.cena.dgac.fr (8.8.5/8.8.8) id PAA04933; Tue, 5 May 1998 15:04:48 +0200 Date: Tue, 5 May 1998 15:04:48 +0200 Message-Id: <199805051304.PAA04933@satie.cenatls.cena.dgac.fr> From: Herve DAMIANO MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: where to put files shared among applications X-Mailer: VM 6.22 under 19.15p2 XEmacs Lucid Xref: sodium.transmeta.com linux.fhs:180 Status: RO Content-Length: 1455 Lines: 34 Hi all, This list doesn't seem to be very active, and consequently I don't know if this mailing list is appropriate for my question. By the way, http://www.eg.bucknell.edu/~quinlan/fsstnd is not a valid link and there's nothing about a move of fhs official page in http://sunsite.unc.edu/mdw/linux.html We have a project in our research center where some applications may share binary or ascii data files. We use packages for each application and another one for shared data files. Unfortunately I can't think of well known applications which have the same problem and I don't find in the fhs where to put these files. I first think they could be put in /usr/share but in section 4.5 "/usr/lib ..." I read : "Miscellaneous architecture-independant *application-specific* static files and subdirectories should be placed in /usr/share". Does it mean that a static file not specific to one application can't be placed in /usr/share ? If yes, where to put these files ? If not, Have I to create a subdirectory with data package name in /usr/share ? About files generated at run time but which must remain between several invocations, I find that /var/state seems to be a good choice. But all examples I'v seen on my system in /var/lib show that permissions to write are for root only. Are we compatibe with fhs if we change permissions to allow users to generate these files ? Thanks for your answers -- |Herve Damiano damiano@cenatls.cena.dgac.fr From list-relay@mlist.ucsd.edu Tue May 5 14:34:52 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id OAA23904 for ; Tue, 5 May 1998 14:34:52 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id OAA27562 for ; Tue, 5 May 1998 14:33:15 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id OAA24184 for ; Tue, 5 May 1998 14:26:40 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id NAA07001 for ; Tue, 5 May 1998 13:52:36 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.8.8/8.6.9) with ESMTP id NAA02775 for ; Tue, 5 May 1998 13:52:34 -0700 (PDT) Received: from gold-1.transmeta.com (mailhost.transmeta.com [10.1.1.79]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id NAA27057; Tue, 5 May 1998 13:50:50 -0700 Received: from sodium.transmeta.com (quinlan@sodium.transmeta.com [10.1.1.11]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id NAA22065; Tue, 5 May 1998 13:52:26 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id NAA17967; Tue, 5 May 1998 13:52:26 -0700 To: Herve DAMIANO Cc: fhs-discuss@ucsd.edu Subject: Re: where to put files shared among applications References: <199805051304.PAA04933@satie.cenatls.cena.dgac.fr> From: Daniel Quinlan Date: 05 May 1998 13:52:26 -0700 In-Reply-To: Herve DAMIANO's message of Tue, 5 May 1998 15:04:48 +0200 Message-ID: <6yra28modx.fsf@sodium.transmeta.com> X-Mailer: Gnus v5.3/Emacs 19.34 Xref: sodium.transmeta.com linux.fhs:181 Status: RO Content-Length: 2080 Lines: 51 Herve DAMIANO writes: > By the way, http://www.eg.bucknell.edu/~quinlan/fsstnd is not a > valid link and there's nothing about a move of fhs official page in > http://sunsite.unc.edu/mdw/linux.html Hmm... the official page has been at http://www.pathname.com/fhs/ for almost 1.5 years. Any search engine should turn it up. I'll check Matt's link. > We have a project in our research center where some applications may > share binary or ascii data files. We use packages for each > application and another one for shared data files. > > Unfortunately I can't think of well known applications which have > the same problem and I don't find in the fhs where to put these > files. I first think they could be put in /usr/share but in section > 4.5 "/usr/lib ..." I read : "Miscellaneous architecture-independant > *application-specific* static files and subdirectories should be > placed in /usr/share". > > Does it mean that a static file not specific to one application can't be placed > in /usr/share ? You don't need to be that literal. Using a directory under /usr/share for a suite of applications is okay or some common set of shareable data. For example, /usr/share/locale is used by many unrelated applications. > If yes, where to put these files ? > > If not, Have I to create a subdirectory with data package name in /usr/share ? Yes, I think so. > About files generated at run time but which must remain between > several invocations, I find that /var/state seems to be a good > choice. But all examples I'v seen on my system in /var/lib show that > permissions to write are for root only. Are we compatibe with fhs if > we change permissions to allow users to generate these files ? Yes, FHS does not say anything about permissions, but you probably only want to make specific directories under /var/lib (for FSSTND) or /var/state (for FHS) to be writeable for some group of users. Dan -- Daniel Quinlan (at work) Linux, our last best hope for Unix quinlan@transmeta.com http://www.pathname.com/~quinlan/ From list-relay@mlist.ucsd.edu Wed May 20 18:24:41 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id SAA26739 for ; Wed, 20 May 1998 18:24:40 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id SAA22658 for ; Wed, 20 May 1998 18:22:41 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id SAA23904 for ; Wed, 20 May 1998 18:27:19 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id SAA17502 for ; Wed, 20 May 1998 18:09:09 -0700 (PDT) Received: from Iguanodon.big-orange.net (smtp.mail.big-orange.net [143.179.236.31] (may be forged)) by mailbox2.ucsd.edu (8.8.8/8.6.9) with ESMTP id SAA05736 for ; Wed, 20 May 1998 18:09:05 -0700 (PDT) Received: from Brachiosaurus.big-orange.net ([172.21.0.31]) by Iguanodon.big-orange.net (Netscape Messaging Server 3.52) with ESMTP id AAA41BC for ; Thu, 21 May 1998 03:08:47 +0200 Received: from [127.0.0.1] by Brachiosaurus.big-orange.net (Netscape Messaging Server 3.52) with SMTP id AAA396E for ; Thu, 21 May 1998 03:15:59 +0200 Received: from Lesothosaurus.big-orange.net ([172.21.0.11]) by Brachiosaurus.big-orange.net (Netscape Messaging Server 3.52) with ESMTP id AAA3980 for ; Tue, 5 May 1998 16:40:55 +0200 Received: from mailhost.pi.net ([145.220.3.9]) by Lesothosaurus.big-orange.net (Netscape Messaging Server 3.52) with ESMTP id AAA2AA4 for ; Tue, 5 May 1998 16:32:26 +0200 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by mailhost.pi.net (8.8.3/8.7.1) with ESMTP id QAA23014 for ; Tue, 5 May 1998 16:31:45 +0200 (MET DST) Posted-Date: Tue, 5 May 1998 16:31:45 +0200 (MET DST) Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id GAA21768 for ; Tue, 5 May 1998 06:04:57 -0700 (PDT) Received: from massu.cenatls.cena.dgac.fr (massu.cenatls.cena.dgac.fr [143.196.1.148]) by mailbox2.ucsd.edu (8.8.8/8.6.9) with ESMTP id GAA17737 for ; Tue, 5 May 1998 06:04:54 -0700 (PDT) Received: from satie.cenatls.cena.dgac.fr (damiano@satie [143.196.1.178]) bymassu.cenatls.cena.dgac.fr (8.8.7/8.8.7) with ESMTP id PAA24023 for; Tue, 5 May 1998 15:04:49 +0200 (MET DST) Received: (from damiano@localhost) bysatie.cenatls.cena.dgac.fr (8.8.5/8.8.8) id PAA04933; Tue,5 May 1998 15:04:48 +0200 Date: Tue, 5 May 1998 15:04:48 +0200 Message-Id: <199805051304.PAA04933@satie.cenatls.cena.dgac.fr> From: Herve DAMIANO MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@ucsd.edu Subject: where to put files shared among applications X-Mailer: VM 6.22 under 19.15p2 XEmacs Lucid Xref: sodium.transmeta.com linux.fhs:183 Status: RO Content-Length: 1455 Lines: 34 Hi all, This list doesn't seem to be very active, and consequently I don't know if this mailing list is appropriate for my question. By the way, http://www.eg.bucknell.edu/~quinlan/fsstnd is not a valid link and there's nothing about a move of fhs official page in http://sunsite.unc.edu/mdw/linux.html We have a project in our research center where some applications may share binary or ascii data files. We use packages for each application and another one for shared data files. Unfortunately I can't think of well known applications which have the same problem and I don't find in the fhs where to put these files. I first think they could be put in /usr/share but in section 4.5 "/usr/lib ..." I read : "Miscellaneous architecture-independant *application-specific* static files and subdirectories should be placed in /usr/share". Does it mean that a static file not specific to one application can't be placed in /usr/share ? If yes, where to put these files ? If not, Have I to create a subdirectory with data package name in /usr/share ? About files generated at run time but which must remain between several invocations, I find that /var/state seems to be a good choice. But all examples I'v seen on my system in /var/lib show that permissions to write are for root only. Are we compatibe with fhs if we change permissions to allow users to generate these files ? Thanks for your answers -- |Herve Damiano damiano@cenatls.cena.dgac.fr From list-relay@mlist.ucsd.edu Tue May 26 00:05:44 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id AAA06050 for ; Tue, 26 May 1998 00:05:43 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id AAA11062 for ; Tue, 26 May 1998 00:03:36 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id AAA14669 for ; Tue, 26 May 1998 00:07:29 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id XAA21575 for ; Mon, 25 May 1998 23:54:22 -0700 (PDT) Received: from nemo.polcard.com.pl (NEMO.POLCARD.COM.PL [195.116.107.242]) by mailbox1.ucsd.edu (8.8.8/8.6.9) with SMTP id XAA09912 for ; Mon, 25 May 1998 23:54:05 -0700 (PDT) Received: (qmail 10029 invoked from network); 26 May 1998 06:53:57 -0000 Received: from bravo.polcard.com.pl (192.168.1.22) by intranet.polcard.com.pl with SMTP; 26 May 1998 06:53:57 -0000 Received: by BRAVO.POLCARD.COM.PL with Microsoft Mail id <01BD8884.15AA8800@BRAVO.POLCARD.COM.PL>; Tue, 26 May 1998 08:55:51 +-200 Message-ID: <01BD8884.15AA8800@BRAVO.POLCARD.COM.PL> From: Rafal Pietrak To: "fhs-discuss@UCSD.Edu" Subject: ODP: time to move mtab out of /etc? Date: Tue, 26 May 1998 08:55:49 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by gold-1.transmeta.com id AAA06050 Xref: sodium.transmeta.com linux.fhs:198 Status: RO Content-Length: 1457 Lines: 34 ---------- From: Brandon S. Allbery KF8NH[SMTP:allbery@kf8nh.apk.net] Date: 26 maja 1998 02:04 To: fhs-discuss@UCSD.Edu In message , Daniel Quinlan writes: +----- | Someone also mentioned this to me the other day at BALUG. It does | strike me as odd that we didn't address this in FHS. I know we | discussed it before for FSSTND. +--->8 Odd? /etc/mtab (well, /etc/mnttab on System III and System V pre-R4) is as firmly established as /bin/sh. On the other hand, a symlink to /var/run/mtab is probably okay, as long as all programs are changed to update it in a symlink-friendly manner. NextStep did it more or less like that but they went one step further. They moved the whole /etc away - meaning "it's a configuration directory" and in principle it's private to the host. The layout was like that: / - readonly, possibly a CD or a shared, network volume /private - r/w local to each host (a *very* small partition) /etc -> /private/etc /dev -> /private/dev /tmp -> ... something ... I liked it. Realy. And about the [/var/lock/LCK...] stuff. Wouldn't it be nice if the /proc filesystem provided (similair to /proc/mtab expectations), something like a [/proc/lock/] directory, where a touch - that is open("/proc/lock/", O_CREATE,) - would create an exclusive lock with a PID inside? .... and a remove of that file would kill the process group that owns it .... provided one has the permission. -R From list-relay@mlist.ucsd.edu Tue May 26 04:05:06 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id EAA12658 for ; Tue, 26 May 1998 04:05:05 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id EAA12561 for ; Tue, 26 May 1998 04:03:07 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id EAA16197 for ; Tue, 26 May 1998 04:06:58 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id DAA28381 for ; Tue, 26 May 1998 03:44:11 -0700 (PDT) Received: from mail.ka.inka.de (quechua.inka.de [193.197.84.11]) by mailbox1.ucsd.edu (8.8.8/8.6.9) with SMTP id DAA25829 for ; Tue, 26 May 1998 03:44:05 -0700 (PDT) Received: from uu.inka.de (ms1.ka.inka.de [193.197.84.8]) by mail.ka.inka.de with smtp id 0yeHCc-0000Rs-00; Tue, 26 May 1998 12:43:30 +0200 Received: (aj@dungeon.inka.de) by uu.inka.de (S3.1.29.1) id ; Tue, 26 May 98 12:43 MET DST Received: from aj by dungeon.inka.de with local (Exim 1.92 #1) id 0yeFOx-0000Hz-00 (Debian); Tue, 26 May 1998 10:48:07 +0200 Message-ID: <19980526104807.C905@dungeon.inka.de> Date: Tue, 26 May 1998 10:48:07 +0200 From: Andreas Jellinghaus To: "fhs-discuss@UCSD.Edu" Subject: /usr/etc Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i Xref: sodium.transmeta.com linux.fhs:201 Status: RO Content-Length: 1261 Lines: 30 i didn't found a rationale in fhs, so i ask here. why was /usr/etc removed ? i have many different machines booting nfsroto from one server. my alternatives are - seperate /etc for every host, any try to keep them konsistent. - use one shared /etc, and hack a few programs. the second solution was easier for me, as only 5 files need to be per-host : - init/inittab/rc*.d/ solved by not useing init, and bootign a shell script - fstab the shell script does the mount/umount calls - mtab i'm useing -n paramters with mount/umount - hostname nfsaddrs= give the right ip (hostname doesn't work), and a mix of "host", "grep" and "cut" gets the hostname from the dns server. - XF86Config my "X" is a shell script, that parses /etc/client/Parameters, and creates a XF86Config via cpp from a global one. it also calls the right Xserver. things could be easier with a host specific /etc and a shared /usr/etc. also fhs lists what in /var isn't shareable and that /var/mail should be shareable. what about /var/cache, /var/games, /var/spool ? depending on the app ? is there a recommendation : where to put data files of services, running under their own user id. i'm thinking of web servers, ftp server, database server ... andreas From list-relay@mlist.ucsd.edu Tue May 26 13:29:03 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id NAA01930 for ; Tue, 26 May 1998 13:29:03 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id NAA18447 for ; Tue, 26 May 1998 13:27:04 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id NAA22094 for ; Tue, 26 May 1998 13:30:50 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id NAA11913 for ; Tue, 26 May 1998 13:18:14 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.8.8/8.6.9) with ESMTP id NAA24240 for ; Tue, 26 May 1998 13:18:09 -0700 (PDT) Received: from gold-1.transmeta.com (mailhost.transmeta.com [10.1.1.79]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id NAA18305; Tue, 26 May 1998 13:16:06 -0700 Received: from sodium.transmeta.com (quinlan@sodium.transmeta.com [10.1.1.11]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id NAA01580; Tue, 26 May 1998 13:18:04 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id NAA12118; Tue, 26 May 1998 13:18:03 -0700 To: Andreas Jellinghaus Cc: "fhs-discuss@UCSD.Edu" Subject: Re: /usr/etc References: <19980526104807.C905@dungeon.inka.de> From: Daniel Quinlan Date: 26 May 1998 13:18:03 -0700 In-Reply-To: Andreas Jellinghaus's message of Tue, 26 May 1998 10:48:07 +0200 Message-ID: <6y1ztgdbwk.fsf@sodium.transmeta.com> X-Mailer: Gnus v5.3/Emacs 19.34 Xref: sodium.transmeta.com linux.fhs:203 Status: RO Content-Length: 1130 Lines: 31 Andreas Jellinghaus writes: > i didn't found a rationale in fhs, so i ask here. > why was /usr/etc removed ? 1. It's very difficult to separate local configuration from non-local configuration. 2. Almost nothing was using it, and we did a lack-luster job of specifying /usr/etc. For special cases (such as your own) and site-global configuration, symbolic links and other techniques (such as the ones you mention) do the trick. > things could be easier with a host specific /etc and a shared > /usr/etc. also fhs lists what in /var isn't shareable and that > /var/mail should be shareable. what about /var/cache, /var/games, > /var/spool ? depending on the app ? Depends on the application. Generally, you can assume that it won't be shareable except in certain cases such as /var/mail. > is there a recommendation : where to put data files of services, > running under their own user id. i'm thinking of web servers, ftp > server, database server ... /home/ is a possibility. This may be edging in on the gray region between what we should and should not specify. - Dan From list-relay@mlist.ucsd.edu Tue May 26 14:56:09 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id OAA05736 for ; Tue, 26 May 1998 14:56:08 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id OAA19644 for ; Tue, 26 May 1998 14:54:10 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id OAA23266 for ; Tue, 26 May 1998 14:57:56 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id OAA14088 for ; Tue, 26 May 1998 14:38:39 -0700 (PDT) Received: from wariat.apk.net (wariat.apk.net [192.147.147.1]) by mailbox1.ucsd.edu (8.8.8/8.6.9) with ESMTP id OAA05595 for ; Tue, 26 May 1998 14:38:38 -0700 (PDT) Received: (from uucp@localhost) by wariat.apk.net (8.8.5/8.7.3) id RAA22006 for fhs-discuss@ucsd.edu; Tue, 26 May 1998 17:40:57 -0400 (EDT) >Received: from rushlight.kf8nh.apk.net (localhost [127.0.0.1]) by speaker.kf8nh.apk.net (8.7.6/8.7.3) with ESMTP id RAA23453 for ; Tue, 26 May 1998 17:36:03 -0400 Message-Id: <199805262136.RAA23453@speaker.kf8nh.apk.net> X-Mailer: exmh version 2.0.2 2/24/98 To: fhs-discuss@UCSD.Edu Subject: Re: ODP: time to move mtab out of /etc? In-reply-to: Your message of "Tue, 26 May 1998 08:55:49." <01BD8884.15AA8800@BRAVO.POLCARD.COM.PL> Mime-Version: 1.0 Date: Tue, 26 May 1998 17:36:00 -0300 From: "Brandon S. Allbery KF8NH" Content-Type: text/plain; charset=us-ascii Xref: sodium.transmeta.com linux.fhs:204 Status: RO Content-Length: 839 Lines: 23 In message <01BD8884.15AA8800@BRAVO.POLCARD.COM.PL>, Rafal Pietrak writes: +----- | And about the [/var/lock/LCK...] stuff. Wouldn't it be nice if the /proc = | filesystem provided (similair to /proc/mtab expectations), something = | like a [/proc/lock/] directory, where a touch - that is = +--->8 (Could you lose the quoted-unreadable, please?) I think you'd have to run that one past Linus; if he doesn't think it belongs in the kernel, we'd have little chance of successfully adding it to FHS. I think "process and children" would be better than "process group", BTW. -- brandon s. allbery [team os/2][linux][japh] allbery@kf8nh.apk.net system administrator, ece facilities allbery@ece.cmu.edu carnegie mellon university (bsa@kf8nh is still valid.) (pardon my dust, wolverines has fleas and they're breeding.) From list-relay@mlist.ucsd.edu Wed May 27 06:29:16 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id GAA04991 for ; Wed, 27 May 1998 06:29:15 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id GAA26836 for ; Wed, 27 May 1998 06:26:52 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id GAA30548 for ; Wed, 27 May 1998 06:30:33 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8/8.6.9) with ESMTP id GAA11316 for ; Wed, 27 May 1998 06:17:56 -0700 (PDT) Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox1.ucsd.edu (8.8.8AS/8.6.9) with SMTP id GAA22904 for ; Wed, 27 May 1998 06:17:40 -0700 (PDT) From: t.sippel-dau@ic.ac.uk Received: from oban.cc.ic.ac.uk [155.198.5.28] by romeo.ic.ac.uk with smtp (Exim 1.62 #1) id 0yeg57-0007Ws-00; Wed, 27 May 1998 14:17:25 +0100 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by oban.cc.ic.ac.uk with smtp (Exim 1.90 #1) id 0yeg57-00023r-00; Wed, 27 May 1998 14:17:25 +0100 Received: by cscmgb.cc.ic.ac.uk (940816.SGI.8.6.9/4.0) id OAA24240; Wed, 27 May 1998 14:17:24 +0100 Message-Id: <199805271317.OAA24240@cscmgb.cc.ic.ac.uk> Subject: Re: ODP: time to move mtab out of /etc? To: rafal@polcard.com.pl (Rafal Pietrak) Date: Wed, 27 May 1998 14:17:24 +0100 (bst) Cc: fhs-discuss@ucsd.edu In-Reply-To: <01BD8884.15AA8800@BRAVO.POLCARD.COM.PL> from "Rafal Pietrak" at May 26, 98 08:55:49 am Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:206 Status: RO Content-Length: 1372 Lines: 28 The keyboard of Rafal Pietrak emitted at some point in time: > > And about the [/var/lock/LCK...] stuff. Wouldn't it be nice if the /proc > filesystem provided (similair to /proc/mtab expectations), something > like a [/proc/lock/] directory, where a touch - that is > open("/proc/lock/", O_CREATE,) - would create an exclusive > lock with a PID inside? .... and a remove of that file would kill the > process group that owns it .... provided one has the permission. It is a BAD idea, for the simple reason that "locks" are not machine specific. So putting them into the kernel uses space and makes access to them more awkward if you come from another machine. The fact that the lock files in /var/lock and friends are machine specific (like locking a serial port) does not change the principle. Unix has for a long time argued that the operating system should not provide for "record locks", and provided only a very simple file lock mechanism for its own (/etc/passwd file) use, telling applications to provide their own locking machanism by going to a client-server model. The proponents were heavily flamed for this, until history, in the form of everything moving to networks, proved them right. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk From list-relay@mlist.ucsd.edu Wed Jun 10 18:54:08 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id SAA19567 for ; Wed, 10 Jun 1998 18:54:07 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id SAA24721 for ; Wed, 10 Jun 1998 18:52:06 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id SAA31100 for ; Wed, 10 Jun 1998 18:53:27 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id SAA23686 for ; Wed, 10 Jun 1998 18:46:20 -0700 (PDT) Received: from ns.tsinet.ru (ns.tsinet.ru [195.34.38.1]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id SAA03136 for ; Wed, 10 Jun 1998 18:46:19 -0700 (PDT) for Received: from tsinet.ru (pv@timbuktu.tsinet.ru.38.34.195.in-addr.arpa [195.34.38.33] (may be forged)) by ns.tsinet.ru (8.8.7/8.8.7) with ESMTP id GAA15755 for ; Thu, 11 Jun 1998 06:00:18 +0400 Sender: pv@tsinet.ru Message-ID: <357F37BE.948165EC@tsinet.ru> Date: Thu, 11 Jun 1998 05:49:50 +0400 From: Pavel Korovin X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: fhs-discuss@ucsd.edu Subject: fhs development continues ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:302 Status: RO Content-Length: 613 Lines: 13 I found some words about '/usr/libexec' directory in slides from San Francisco Bay Area Linux Users Group meeting in May 20,1998. But there is no info about '/usr/libexec' in FHS 2.0. Does FHS development continues? Where can I find info about current status of FHS? BTW, FHSv2.0 was released 26.10.97, but it just stays on paper. There is no Linux distribution made in compliance with FHS. Hard work was done, but main Linux distributors still use old FSSTND. Why? I don`t think that porting is too hard; porting Linux to glibc was very hard thing, but RH 5.x & still frozen Debian 2.0 are glibc-based systems. From list-relay@mlist.ucsd.edu Thu Jun 11 06:58:58 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id GAA13405 for ; Thu, 11 Jun 1998 06:58:57 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id GAA29695 for ; Thu, 11 Jun 1998 06:56:57 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id GAA03775 for ; Thu, 11 Jun 1998 06:58:14 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id GAA15849 for ; Thu, 11 Jun 1998 06:52:46 -0700 (PDT) Received: from mail.quoininc.com (quoin-fr-gw.mbo.ma.ultra.net [146.115.17.205]) by mailbox1.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id GAA24501 for ; Thu, 11 Jun 1998 06:52:44 -0700 (PDT) Message-Id: Date: Thu, 11 Jun 1998 09:59:55 -0400 (EDT) From: Jean Pierre LeJacq cc: fhs-discuss@ucsd.edu Subject: Re: fhs development continues ? In-Reply-To: <357F37BE.948165EC@tsinet.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:304 Status: RO Content-Length: 489 Lines: 15 On Thu, 11 Jun 1998, Pavel Korovin wrote: > BTW, FHSv2.0 was released 26.10.97, but it just stays on > paper. There is no Linux distribution made in compliance with > FHS. Hard work was done, but main Linux distributors still use > old FSSTND. Why? I don`t think that porting is too hard; > porting Linux to glibc was very hard thing, but RH 5.x & still > frozen Debian 2.0 are glibc-based systems. Debian is planning on switching to FHS after the next stable release. -- Jean Pierre From list-relay@mlist.ucsd.edu Thu Jun 11 21:01:15 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id VAA20562 for ; Thu, 11 Jun 1998 21:01:14 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id UAA05970 for ; Thu, 11 Jun 1998 20:59:14 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id VAA12559 for ; Thu, 11 Jun 1998 21:00:27 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id UAA20460 for ; Thu, 11 Jun 1998 20:52:24 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id UAA11718 for ; Thu, 11 Jun 1998 20:52:24 -0700 (PDT) Received: from gold-1.transmeta.com (mailhost.transmeta.com [10.1.1.79]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id UAA05898; Thu, 11 Jun 1998 20:50:10 -0700 Received: from sodium.transmeta.com (quinlan@sodium.transmeta.com [10.1.1.11]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id UAA20216; Thu, 11 Jun 1998 20:52:09 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id UAA26423; Thu, 11 Jun 1998 20:52:09 -0700 To: Pavel Korovin Cc: fhs-discuss@ucsd.edu Subject: Re: fhs development continues ? References: <357F37BE.948165EC@tsinet.ru> From: Daniel Quinlan Date: 11 Jun 1998 20:52:09 -0700 In-Reply-To: Pavel Korovin's message of Thu, 11 Jun 1998 05:49:50 +0400 Message-ID: <6ybtrzp992.fsf@sodium.transmeta.com> X-Mailer: Gnus v5.3/Emacs 19.34 Xref: sodium.transmeta.com linux.fhs:305 Status: RO Content-Length: 462 Lines: 12 Pavel Korovin writes: > I found some words about '/usr/libexec' directory in slides from San > Francisco Bay Area Linux Users Group meeting in May 20,1998. But there > is no info about '/usr/libexec' in FHS 2.0. Does FHS development > continues? Where can I find info about current status of FHS? My mistake, there is no /usr/libexec in FHS 2.0. I skipped over that slide in my talk, but forgot to remove it from the PostScript version. - Dan From list-relay@mlist.ucsd.edu Fri Jun 12 08:08:17 1998 Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by gold-1.transmeta.com (8.8.8/8.8.5) with ESMTP id IAA09899 for ; Fri, 12 Jun 1998 08:08:16 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id IAA10289 for ; Fri, 12 Jun 1998 08:06:10 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id IAA17310 for ; Fri, 12 Jun 1998 08:07:18 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id HAA12925 for ; Fri, 12 Jun 1998 07:49:23 -0700 (PDT) Received: from master.debian.org (debian.novare.net [205.229.104.5]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with SMTP id HAA26985 for ; Fri, 12 Jun 1998 07:49:20 -0700 (PDT) Received: (qmail 14245 invoked by uid 2002); 12 Jun 1998 14:49:15 -0000 Message-ID: <19980612094915.A13686@debian.org> Date: Fri, 12 Jun 1998 09:49:15 -0500 From: Fabien Ninoles To: fhs-discuss@UCSD.EDU Subject: Re: fhs development continues ? Reply-To: Fabien Ninoles Mail-Followup-To: fhs-discuss@ucsd.edu References: <357F37BE.948165EC@tsinet.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <357F37BE.948165EC@tsinet.ru>; from Pavel Korovin on Thu, Jun 11, 1998 at 05:49:50AM +0400 Xref: sodium.transmeta.com linux.fhs:308 Status: RO Content-Length: 1310 Lines: 24 On Thu, Jun 11, 1998 at 05:49:50AM +0400, Pavel Korovin wrote: [snip /usr/libexec thing] > BTW, FHSv2.0 was released 26.10.97, but it just stays on paper. There is > no Linux distribution made > in compliance with FHS. Hard work was done, but main Linux distributors > still use old FSSTND. > Why? I don`t think that porting is too hard; porting Linux to glibc was > very hard thing, but > RH 5.x & still frozen Debian 2.0 are glibc-based systems. The main reason for Debian is that glibc is already a big enough goal to deal with. The FSSTND was already implemented in 1.3.1 so we prefer to deal with glibc program [it was need to support other architecture such as sparc I think.] then, as Jean Pierre said, switch to FHS in Debian 2.1. Also, fhs wasn't ready when we decide the goal of 2.0. -- ------------------------------------------------------------------------ Fabien Ninoles Running Debian/GNU Linux E-mail: fab@tzone.org WebPage: http://www.callisto.si.usherb.ca/~94246757 WorkStation [available when connected!]: http://nightbird.tzone.org/ RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70 ------------------------------------------------------------------------ From list-relay@mlist.ucsd.edu Mon Jun 22 11:29:33 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8/8.8.5) with ESMTP id LAA26505 for ; Mon, 22 Jun 1998 11:29:32 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id LAA04492 for ; Mon, 22 Jun 1998 11:26:47 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.8.8/8.8.5) with ESMTP id LAA28515 for ; Mon, 22 Jun 1998 11:27:02 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id LAA10360 for ; Mon, 22 Jun 1998 11:02:47 -0700 (PDT) Received: from albion.glarp.com (ns015.netsavant.com [206.168.221.79]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id LAA21812 for ; Mon, 22 Jun 1998 11:02:32 -0700 (PDT) Received: from albion.glarp.com (502@localhost [127.0.0.1]) by albion.glarp.com (8.8.2/8.8.2) with ESMTP id MAA00360 for ; Mon, 22 Jun 1998 12:00:49 -0600 Message-Id: <199806221800.MAA00360@albion.glarp.com> To: fhs-discuss@UCSD.Edu Subject: FHS proposal for canonical file hierarchy and subsequent revisions Date: Mon, 22 Jun 1998 18:01:05 +0000 From: James Xref: sodium.transmeta.com linux.fhs:309 Status: RO Content-Length: 10937 Lines: 199 Hello fhs-discuss: I'm sending this out to fhs-discuss after trying unsuccessfully to contact Daniel Quinlan. I notice that the current drafts are all older than the current release and that Daniel's website no longer exists. In the summer of '97 I went through some soul-searching regarding filesystem hierarchy after an install script wiped-out part of my filesystem. As a result, I developed my own canonical guidelines for file-naming. Looking through the 1997 October 26 FHS-v2.0, I've noticed similarities and differences that motivate comment, to clarify distinctions which guide the concept of the hierarchy. First, some guiding principles, observations, and interpretations: 1) In the Microsoft world, application packages are distinct and independent. The underlying organizing principle becomes "organize by application package before system function". Distinguish "The Unix Way" from "The Microsoft Way" of filesystem hierarchy. In the Unix world, applications are integrated and interdependent. The underlying organizing principle becomes "organize by system function before application package". 2) Administration of an integrated and interdependent system of files requires that files of a similar function be grouped together. The purpose of a hierarchy is to integrate and separate; the filesystem shouldn't scatter files of similar function or mix files of distinct function. 3) Use only regular files as Configuration Files; never use directory files, where they might serve as lists of files and links, as the configuration mechanism. The purpose of a directory system is to administer file placement, not configure applications. Use explicit application configuration files to configure applications. The occasional digression, linking XF86_SVGA to X for instance, is not the issue. I am aware that the configuration-by-directory technique is relied upon heavily by some - Red Hat's SV style init configuration for example - but it is the _concept_ of where the configuration information should be placed that is pertinent to this hierarchy proposal. 4) UNIX tradition allows replacing long and standard pathname prefixes with aliases, the "null string" being a common alias here. With this observation, traditional UNIX pathnames can be interpreted as properly conforming to various canonical flat filesystem naming conventions before modification. The UNIX pathname rules: remove any pathname prefix not required to make the pathname unique, or modify any pathname prefix required to make the pathname unique. So now, interpreting these principles comes very centrally to interpreting and defining what is meant by the "system function" of a file. in the FHS-v2.0 there is simply "It is possible to define two orthogonal categories of files: sharable vs unsharable and variable vs static." I came to a similar but alternate conclusion, and it is this issue of orthogonal categories that I want to address. I call this a "class centered" approach. On the first dimension, sharable vs unsharable, I concur completely, though I called this dimension "Scope", with "Strategic (Shared)" and "Tactical (Unique)" categories. Yet I want to suggest a third orthogonal dimension, simply "Type", with "Executable Data" and "Resource Data" categories. Furthermore, I want to suggest that this executable vs resource dimension take equal precedence with the shared vs unique dimension, making the variable vs static dimension a "foreground/background" dimension. My reasoning is based upon UNIX tradition, particularly with respect to the dominance of the C language on UNIX systems. What leaps out to me, in both the BSD and SV hierarchies, within both / and /usr/, and within large UNIX application packages such as X11, are, conceptually, but consistently, the following four classes of subdirectory - bin/ lib/ etc/ and include/ - organized like this: Executable Data Resource Data +-----------------------------------------------+ Tactical (Unique) | Server Clients bin/ | Configuration etc/ | +-----------------------------------------------+ Strategic (Shared) | Shared Functions lib/ | Reference include/ | +-----------------------------------------------+ Figure 1 - Class structure component organization I believe the file classes resulting from these categories are ubiquitous in traditional UNIX hierarchies, and most usefully define what is meant by the "system function" of a file for administrative purposes. Within this framework, similar classes of subdirectory can be "next to" each other, at the same level in the hierarchy tree and application distinctions can be made "below" at the next level down in the hierarchy tree. Basically though, making this executable vs resource dimension central to file classification allows more useful, explicit, and consistent description of /usr/lib/, /usr/share/, /usr/etc/, and /var/. Before continuing, let me summarize my view of "depth" in the hierarchy. Where file class represents the "breadth" of the hierarchy, I suggest that "depth" be ordered like this: partition:package:class:server:group:instance First and second level, order by possible Device Partition with respect to Data Accessibility, and then by Package in the sense of a user-level system of files. I mean to suggest a _very_ generalized distinction with "partition:package:". Here, by principle 4, a leading pathname is inferred to interpret a flat filesystem hierarchy. The concept comes down to: Which systems of files warrant being considered a "package" in some larger sense? and How aggressively will principle 4 be applied? Some points: If the distinction is made between "package", a relatively complete group of library, configuration, reference, and program files, X11 say, and "contribution", which primarily extends an exiting package, then the concept of a mountable partition, /usr/ say, can itself be viewed quite consistently as being a kind of UNIX "package" installed into the system and extended occasionally by the addition new commands and libraries. Using principle 4, one might hypothesize /prime/sys/{bin|etc|lib|include}/ and consistently overlay the traditional /home/ftp/{bin|etc|lib|pub}/. In particular, all the top level system subdirectories can be viewed as belonging to some conceptual base Linux OS "package", giving, in part, /prime/sys/bin/, /prime/sys/sbin/, /prime/sys/etc/, /prime/sys/boot/, /prime/sys/lib/, and /prime/sys/dev/. Here, /prime/sys/bin/ and /prime/sys/sbin/ fit a "bin/" class, while /prime/sys/etc/ and /prime/sys/boot/ are both of class "etc/". /prime/sys/lib/ is literally of class "lib/", and /prime/sys/dev/ clearly of class "include/". The hierarchy is flat relative to, say, the usr/ "package", which has consistent usr/bin/, usr/sbin/, usr/lib/, and such. Now, principle 4 will transform /prime/sys/bin/ to simply /bin/ and so on. Any group of files warranting a separate partition is likely to form a system of files recognizable as a "package" in this larger sense, and so "partition:package:" will generally be collapsed. Were, say, multiple operating systems to be stored on the same device partition, as with DOS and UMSDOS Linux, the :package: level would be the dominant distinction from the administrative point of view. I suggest "package" as the general term for this collapsed level. Third level, order by Class with respect to Type - Executable or Resource Data - and by Class with respect to Scope - Tactical or Strategic Data - as described. Some points: Where the variable vs static distinction is clearly fundamental, in practice, any kind of actively variable executable data is unlikely on any UNIX system. Furthermore, whereas some kinds of variable resource data give a sense of being shared, /var/fonts/ say, in practice variable data is always tied by its creation to the specific program creating it and so is unique. I must insist then that /var/, canonically /prime/sys/var/, is of class etc/, representing variable unique resource data. Basically, for these reasons I strongly suggest that the executable vs resource dimension is more fundamental to UNIX filesystem classification than is the static vs variable dimension, and that the executable vs resource dimension take equal precedence next to the shared vs unique dimension to create the class structure of the Filesystem Hierarchy Standard. I propose that the FHS documentation be amended to reflect this. Subsequently, where configuration and reference data have often been placed in /usr/lib/, I suggest there should exist /usr/etc/ to hold configuration data for user level applications in symmetry with /etc/, canonically /sys/etc/, which holds system wide configuration files. Furthermore, _any_ kind of application resource data unique to an application should be placed in /usr/etc/, leaving /usr/lib exclusively to C development, in the same way that /usr/share/ is of class include/ but leaves /usr/include/ exclusively to C development. Fourth level, order by the Server Context generated, in the sense of the top-level Interface/ Language/Interpretor/Environment associated with the file, where the OS kernel is the default generated top-level server environment. Some points: Though any grouping at this level is likely to be with respect to a specific application, /usr/bin/mh/ say, every user-level command ultimately interacts with some other specific program. For instance, X applications run only against an X server, perl scripts against a perl interpreter, shell scripts and commands against the shell, and the shell against the OS itself. I suggest that it is the running context of a file, rather than the purpose of the file itself that is most important to filesystem administration. So, consequently, I would see tmac going to /usr/etc/groff/tmac/ and not to /usr/share/tmac/ because _groff_ is the server context for tmac and tmac is not intended to stand alone. I suggest "server" as the most useful term for this level. Fifth level, order by appropriate Grouping within the data file's Server Context. For instance, groff/tmac/ and groff/font/, or simply /usr/share/terminfo/{a|b|c...}. Sixth, by Instance, remembering principle 4 in practice. Finally, some comments about /var/. Where I believe /var/ represents a level three node of class "etc/", canonically /prime/sys/var/, say, I suggest that subdirectory naming in /var/ should be guided by Server Context, where the file group represents variable server-unique resource data. From this point of view, I suggest that cache and state, as collections, provide no necessary file separation, and that the underlying cache or state subdirectories should be left exposed. For instance: /var/cat/, /var/fonts/, and /var/xdm/. So then, please let me know what you think about my point of view. Thanks, James G. Feeney From list-relay@mlist.ucsd.edu Tue Jun 30 17:13:07 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id RAA05090 for ; Tue, 30 Jun 1998 17:13:07 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id RAA32011 for ; Tue, 30 Jun 1998 17:10:05 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.0/8.9.0) with ESMTP id RAA32165 for ; Tue, 30 Jun 1998 17:09:21 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id RAA11685 for ; Tue, 30 Jun 1998 17:10:37 -0700 (PDT) Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with SMTP id RAA05275 for ; Tue, 30 Jun 1998 17:10:36 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA16437; Tue, 30 Jun 98 20:10:38 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id UAA12732; Tue, 30 Jun 1998 20:10:33 -0400 Date: Tue, 30 Jun 1998 20:10:33 -0400 Message-Id: <199807010010.UAA12732@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Aurelio Hinarejos Cc: FHS In-Reply-To: Aurelio Hinarejos's message of Tue, 30 Jun 1998 22:42:16 +0200, <35994DA8.D50A24CF@acm.org> Subject: Re: Static binaries in /sbin Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:343 Status: RO Content-Length: 1715 Lines: 34 Date: Tue, 30 Jun 1998 22:42:16 +0200 From: Aurelio Hinarejos 1. /sbin should contain the commands and scipts essential to boot and shutdown the system. /etc/init.d and /etc/rc#.d/ should go under /sbin this way: /sbin/init.d and /sbin/rc#.d. /sbin should contain the commands required to bring the system into a state in which the /usr filesystem can be mounted and the boot process continued. Putting /etc/init.d and /etc/rc?.d in /sbin is something which no system I'm aware does. Solaris 2.x most certainly doesn't put his in /sbin, and I don't think any of the other AT&T SVR4 derivitives either. 3. Binaries in /sbin must be statically linked. Since shared libraries may not be available at a critical moment we should be able to properly shutdown the system or at least to execute a static shell in order to fix something. There may be (static) duplicates in /sbin, so /sbin should go, in PATH variables, after /usr/bin and /usr/sbin. This I think needs to be left up to the individual distribution. It's really a philosophical issue. Some people believe in being able to recover the system by using a rescue floppy. Others believe that you should be able to do so by using Unix wizardly skills and patching the filesystem back together by hand. The rescue floppy method does work, and can permit a certain amount of automated, no-Unix-wizard-skills required operations (watch an NT Rescue disk in operation as an example of what you need if you need to support rescue operations when you have a technically clueless sysadmin). So to require that binaries in /sbin must be statically linked is probably not really necessary. - Ted From list-relay@mlist.ucsd.edu Tue Jun 30 17:50:39 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id RAA07900 for ; Tue, 30 Jun 1998 17:50:39 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id RAA32392 for ; Tue, 30 Jun 1998 17:47:36 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.0/8.9.0) with ESMTP id RAA32533 for ; Tue, 30 Jun 1998 17:46:52 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id RAA12290 for ; Tue, 30 Jun 1998 17:47:20 -0700 (PDT) Received: from yorktown.isdn.uiuc.edu (yorktown.isdn.uiuc.edu [192.17.17.78]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id RAA08985 for ; Tue, 30 Jun 1998 17:47:19 -0700 (PDT) Received: (from roth@localhost) by yorktown.isdn.uiuc.edu (8.8.8/8.8.8) id AAA01442; Wed, 1 Jul 1998 00:47:08 GMT Message-ID: <19980630194707.63274@yorktown.isdn.uiuc.edu> Date: Tue, 30 Jun 1998 19:47:07 -0500 From: "Mark D. Roth" To: "Theodore Y. Ts'o" , Aurelio Hinarejos Cc: FHS Subject: Re: Static binaries in /sbin References: <35994DA8.D50A24CF@acm.org> <199807010010.UAA12732@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199807010010.UAA12732@dcl.MIT.EDU>; from Theodore Y. Ts'o on Tue, Jun 30, 1998 at 08:10:33PM -0400 Xref: sodium.transmeta.com linux.fhs:345 Status: RO Content-Length: 1220 Lines: 28 In our last exciting episode, Theodore Y. Ts'o expounded thusly: > Putting /etc/init.d and /etc/rc?.d in /sbin is something which no system > I'm aware does. Solaris 2.x most certainly doesn't put his in /sbin, > and I don't think any of the other AT&T SVR4 derivitives either. HP-UX 10.x puts the init.d and rcN.d directories in /sbin. On one hand, the argument that the rc scripts shouldn't be in /etc makes sense because they're executables rather than datafiles. OTOH, /etc is for system configuration, which is exactly the category which the rc scripts fit into. Personally, I can go either way on the init.d directory, because I can see both sides of the issue; neither placement really bothers me. But the rcN.d directories, which are populated with links to the init.d directory, are IMHO configuration information which just happens to be using the filesystem instead of a text file to store its data. I can't really see moving them to /sbin. So, IMHO, the init.d directory can go to /sbin or stay in /etc as others want, but either way, the rcN.d directories should remain in /etc. -- Mark D. Roth (roth@uiuc.edu) System Administrator, CCSO Workstation Services Group http://www.uiuc.edu/ph/www/roth From list-relay@mlist.ucsd.edu Wed Jul 1 12:03:14 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id MAA29837 for ; Wed, 1 Jul 1998 12:03:14 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id MAA09000 for ; Wed, 1 Jul 1998 12:00:06 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.0/8.9.0) with ESMTP id LAA09287 for ; Wed, 1 Jul 1998 11:59:15 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id LAA29112 for ; Wed, 1 Jul 1998 11:59:25 -0700 (PDT) Received: from mail.ka.inka.de (quechua.inka.de [193.197.84.11]) by mailbox1.ucsd.edu (8.8.8AS/8.6.9) with SMTP id LAA20563 for ; Wed, 1 Jul 1998 11:59:22 -0700 (PDT) Received: from uu.inka.de (ms1.ka.inka.de [193.197.84.8]) by mail.ka.inka.de with smtp id 0yrS68-0005KA-00; Wed, 1 Jul 1998 20:59:16 +0200 Received: (aj@dungeon.inka.de) by uu.inka.de (S3.1.29.1) id ; Wed, 1 Jul 98 20:59 MET DST Received: from aj by dungeon.inka.de with local (Exim 1.92 #1) id 0yrPjd-0000dX-00 (Debian); Wed, 1 Jul 1998 18:27:53 +0200 Message-ID: <19980701182753.C1502@dungeon.inka.de> Date: Wed, 1 Jul 1998 18:27:53 +0200 From: Andreas Jellinghaus To: "Mark D. Roth" , "Theodore Y. Ts'o" , Aurelio Hinarejos Cc: FHS Subject: Re: Static binaries in /sbin References: <35994DA8.D50A24CF@acm.org> <199807010010.UAA12732@dcl.MIT.EDU> <19980630194707.63274@yorktown.isdn.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <19980630194707.63274@yorktown.isdn.uiuc.edu>; from Mark D. Roth on Tue, Jun 30, 1998 at 07:47:07PM -0500 Xref: sodium.transmeta.com linux.fhs:347 Status: RO Content-Length: 489 Lines: 17 if init.d scripts were not modified, /sbin would be a good place for them. but too often i do modify them. so /etc is far better. in any case : the rc*.d symlinks are configuration information, and should be in /etc. some people even use the "file-rc" package, which allows to use a config file in /etc instead of symlinks. > So, IMHO, the init.d directory can go to /sbin or stay in /etc as > others want, but either way, the rcN.d directories should remain in > /etc. andreas From list-relay@mlist.ucsd.edu Wed Jul 1 12:05:07 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id MAA00121 for ; Wed, 1 Jul 1998 12:05:07 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id MAA09038 for ; Wed, 1 Jul 1998 12:02:04 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.0/8.9.0) with ESMTP id MAA09333 for ; Wed, 1 Jul 1998 12:01:13 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id LAA29114 for ; Wed, 1 Jul 1998 11:59:30 -0700 (PDT) Received: from mail.ka.inka.de (quechua.inka.de [193.197.84.11]) by mailbox1.ucsd.edu (8.8.8AS/8.6.9) with SMTP id LAA20567 for ; Wed, 1 Jul 1998 11:59:23 -0700 (PDT) Received: from uu.inka.de (ms1.ka.inka.de [193.197.84.8]) by mail.ka.inka.de with smtp id 0yrS68-0005K6-00; Wed, 1 Jul 1998 20:59:16 +0200 Received: (aj@dungeon.inka.de) by uu.inka.de (S3.1.29.1) id ; Wed, 1 Jul 98 20:59 MET DST Received: from aj by dungeon.inka.de with local (Exim 1.92 #1) id 0yrPgx-0000ap-00 (Debian); Wed, 1 Jul 1998 18:25:07 +0200 Message-ID: <19980701182506.B1502@dungeon.inka.de> Date: Wed, 1 Jul 1998 18:25:06 +0200 From: Andreas Jellinghaus To: "Theodore Y. Ts'o" , Aurelio Hinarejos Cc: FHS Subject: Re: Static binaries in /sbin References: <35994DA8.D50A24CF@acm.org> <199807010010.UAA12732@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199807010010.UAA12732@dcl.MIT.EDU>; from Theodore Y. Ts'o on Tue, Jun 30, 1998 at 08:10:33PM -0400 Xref: sodium.transmeta.com linux.fhs:349 Status: RO Content-Length: 942 Lines: 20 > This I think needs to be left up to the individual distribution. It's > really a philosophical issue. Some people believe in being able to > recover the system by using a rescue floppy. Others believe that you > should be able to do so by using Unix wizardly skills and patching the > filesystem back together by hand. yes. rescue floppies are nice. i can install everything i need in a few min on the swap disk, and in debian we have some unused space on one of the cdroms, so we want to install a live filesystem for rescue operations there (all editors, backup programs, tape programs, network stuff, and whatever you need). but static binaries are nothing i need. they help, if /sbin is ok, but /lib is buggy. i realy see no reason, why something will affect /lib and not /sbin. at least since i'm no longer doing manual stuff there, and useing a package manager, most theings work fine (unless the apckages are evil). andreas From list-relay@mlist.ucsd.edu Fri Jul 3 01:24:34 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id BAA09346 for ; Fri, 3 Jul 1998 01:24:34 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id BAA31443 for ; Fri, 3 Jul 1998 01:21:30 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.0/8.9.0) with ESMTP id BAA31379 for ; Fri, 3 Jul 1998 01:20:25 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id BAA09859 for ; Fri, 3 Jul 1998 01:16:59 -0700 (PDT) Received: from albion.nurealm.net ([199.45.155.18]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id BAA14112 for ; Fri, 3 Jul 1998 01:16:52 -0700 (PDT) Received: from albion.glarp.com (502@local.host [127.0.0.1]) by albion.glarp.com (8.8.2/8.8.2) with ESMTP id CAA00433; Fri, 3 Jul 1998 02:16:50 -0600 Message-Id: <199807030816.CAA00433@albion.glarp.com> To: Aurelio Hinarejos Cc: FHS Subject: Re: Static binaries in /sbin Date: Fri, 03 Jul 1998 08:17:09 +0000 From: James Xref: yamato.transmeta.com linux.fhs:353 Status: RO Content-Length: 1431 Lines: 30 Date: Tue, 30 Jun 1998 22:42:16 +0200 From: Aurelio Hinarejos On 1) I like putting init scripts in /sbin/. I say that scripts are executable files and that they fit my "class:server:group" model as "/sbin/shellscripts/rc.d/", which shortens to /sbin/rc.d/. Since I like to keep configuration data separate from executable data, I put my init scripts in /sbin/rc.d/ and any kind of configuration data in /etc/. On 2) I think this is already the generally accepted rule. That's how we decide what goes in /usr/ and what stays at the top level. On 3) This is probably too severe. In my model, unique and shared executables, /sbin/, /bin/, and /lib/, would all be mounted as a group, so that binaries in /sbin/ will have access to any library in /lib/. Of course, /sbin/ binaries would have to be statically linked to any libs _not_ in /lib/, or, looking at it the other way, any lib used by an /sbin/ binary should go in /lib/, and not in /usr/lib/. As for static duplicates and modifying the path - duplicates are not appropriate. Any executable needed by a user should be in /bin/, not /sbin/. A major point of shared libraries is saving space. If you already have a static executable, there is no purpose to adding a dynamically linked version of the executable. Without duplicates, there is no need to modify the path. Otherwise, works for me. James Feeney From list-relay@mlist.ucsd.edu Mon Aug 3 19:59:00 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id TAA19813 for ; Mon, 3 Aug 1998 19:58:59 -0700 (PDT) Received: from neosilicon.transmeta.com (root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.8.8/8.8.4) with ESMTP id TAA01567 for ; Mon, 3 Aug 1998 19:55:54 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1/8.9.0) with ESMTP id TAA04930 for ; Mon, 3 Aug 1998 19:49:48 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id TAA23705; Mon, 3 Aug 1998 19:53:36 -0700 (PDT) Received: from albion.nurealm.net ([199.45.155.33]) by mailbox1.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id TAA07303 for ; Mon, 3 Aug 1998 19:53:32 -0700 (PDT) Received: from albion.nurealm.net (502@local.host [127.0.0.1]) by albion (8.8.2/8.8.2) with ESMTP id UAA00353 for ; Mon, 3 Aug 1998 20:53:38 -0600 Message-Id: <199808040253.UAA00353@albion> To: fhs-discuss@ucsd.edu Subject: a proposal for an additional function for the FHS Date: Tue, 04 Aug 1998 02:53:57 +0000 From: James Xref: sodium.transmeta.com linux.fhs:419 Status: RO Content-Length: 1312 Lines: 26 Hello fhs-discuss: You know, outside of the religious analysis that I like to engage in, bottom line, I just want to be able to install new software, either from binary or source distributions, and have it all end-up where _I_ want, without a lot of fuss or conversation. Currently, that's not possible for me, and I think it's a bit tedious for other people - unless they adopt a brand loyalty and forsake eclecticism. So, how about we formalize a foundation for a solution? If there were to exist a sufficiently rich description of file location categories, some set larger than any one person would want to use, but large enough to encompass everything people are currently using, then creating a central file location site definition would become possible. Then, every package management program, every configuration script, and every install script could make reference to this single file location site definition, and every file would install where it was expected. End of conversation. Cool, eh? Of course, it all depends upon the existence of some sufficiently general model which would allow everyone to name the distinctions they needed. The FHS could lay this foundation by providing that sufficiently general model of file category descriptions. James G. Feeney From list-relay@mlist.ucsd.edu Fri Sep 25 09:12:22 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id JAA21005 for ; Fri, 25 Sep 1998 09:12:22 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id JAA01930 for ; Fri, 25 Sep 1998 09:09:13 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id IAA25039 for ; Fri, 25 Sep 1998 08:54:46 -0700 Received: from mail.ucsd.edu (ucsd.ucsd.edu [132.239.1.1]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id JAA13523; Fri, 25 Sep 1998 09:07:32 -0700 (PDT) Received: from chopin.ecsoft.co.uk (chopin.digitus.co.uk [193.130.49.9]) by mail.ucsd.edu; id JAA23784 sendmail 8.8.8AS/UCSD8.3 via SMTP Fri, 25 Sep 1998 09:07:28 -0700 (PDT) for Received: from geocities.com by chopin.ecsoft.co.uk (Lotus SMTP MTA SMTP MTA v1.1.04 (495.1 10-24-) with SMTP id 8025668A.0058912Bù; Fri, 25 Sep 1998 17:07:23 +0100 Sender: proski@geocities.com Message-ID: <360BBFDD.EDB3F799@geocities.com> Date: Fri, 25 Sep 1998 17:07:57 +0100 From: Pavel Roskin Organization: ECsoft X-Mailer: Mozilla 4.5b2 [en] (X11; I; Linux 2.0.35 i586) X-Accept-Language: en MIME-Version: 1.0 To: FHS discussion Subject: Where to place application-loadable libraries? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:478 Status: RO Content-Length: 1116 Lines: 28 Hello! My question is about such libraries which are only intended to be dynamically loaded by some specific program. For example some Java implementation may contain some machine-dependent code which may be called from Java programs. Currently Kaffe (see http://www.transvirtual.com/ for details) places machine-independent code to /usr/share/kaffe/ and machine dependent code to /usr/share/kaffe/lib/i386-linux/ Latest seems to be a bit strange. Positive arguments are: 1) All the libraries are placed under /usr/share/kaffe/ 2) It is possible to share /usr/share/ between different machines, because e.g. alpha code will go to /usr/share/kaffe/lib/alpha-linux/ Negative arguments are: 1) Libraries are placed under /usr/share/. If even they are never linked with any program, they are created using "gcc -shared" and "file" command says that they are libraries. 2) We need to create lib under shere 3) gcc uses /usr/lib/gcc-lib for its private libraries and even headers. The same question may also apply to miscelanious plug-ins and databases in machine-dependend format. Thank you in advance, Pavel Roskin. From list-relay@mlist.ucsd.edu Fri Sep 25 10:37:44 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id KAA27367 for ; Fri, 25 Sep 1998 10:37:44 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id KAA03304 for ; Fri, 25 Sep 1998 10:34:35 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id KAA26390 for ; Fri, 25 Sep 1998 10:20:14 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id KAA16591; Fri, 25 Sep 1998 10:34:48 -0700 (PDT) Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox2.ucsd.edu (8.8.8AS/8.6.9) with SMTP id KAA11046 for ; Fri, 25 Sep 1998 10:34:40 -0700 (PDT) From: t.sippel-dau@ic.ac.uk Received: from oban.cc.ic.ac.uk [155.198.5.28] by romeo.ic.ac.uk with smtp (Exim 1.62 #1) id 0zMblO-0001Ka-00; Fri, 25 Sep 1998 18:34:38 +0100 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by oban.cc.ic.ac.uk with esmtp (Exim 1.90 #1) id 0zMblN-0006sF-00; Fri, 25 Sep 1998 18:34:37 +0100 Received: by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id SAA16964; Fri, 25 Sep 1998 18:34:36 +0100 (bst) Message-Id: <199809251734.SAA16964@cscmgb.cc.ic.ac.uk> Subject: Re: Where to place application-loadable libraries? To: pavel_roskin@geocities.com (Pavel Roskin) Date: Fri, 25 Sep 1998 18:34:36 +0100 (bst) Cc: fhs-discuss@ucsd.edu In-Reply-To: <360BBFDD.EDB3F799@geocities.com> from "Pavel Roskin" at Sep 25, 98 05:07:57 pm Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:479 Status: RO Content-Length: 1797 Lines: 43 The keyboard of Pavel Roskin emitted at some point in time: > My question is about such libraries which are only intended to be > dynamically loaded by some specific program. For example some Java > implementation may contain some machine-dependent code which may be > called from Java programs. Currently Kaffe (see > http://www.transvirtual.com/ for details) places machine-independent > code to /usr/share/kaffe/ and machine dependent code to > /usr/share/kaffe/lib/i386-linux/ > Latest seems to be a bit strange. Well, if it is an application, the most suitable place would be /opt/kaffe/generic for the generic and /opt/kaffe/i386-linux for (i386-) linux specific stuff. The application has a full namespace to itself (under /opt/itsownname) If kaffe is installed locally on a machine, /usr/local/kaffe or /usr/local/lib/kaffe come to mind, and if it is to be integrated into the distribution then the distribution integrator will know best. Otherwise, the question is academic if the application is the only program using the libraries. Also, applications coming from a single source can (and by now most do) just work from an XYZHOME variable, and thus can go anywhere. Only when many different people issue software it becomes necessary that a well-known (or easily establishable place is found for the hierarchy) Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk * voice: +44 171 594 7076 (day) * fax: +44 171 584 1560 * snail: Thomas Sippel - Dau * Information Services Manager * Center of Vibration Engineering * Imperial College of Science, Technology and Medicine * Exhibition Road * Kensington SW7 2BX * Great Britain From list-relay@mlist.ucsd.edu Fri Dec 11 04:39:13 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id EAA03766 for ; Fri, 11 Dec 1998 04:39:13 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id EAA21490 for ; Fri, 11 Dec 1998 04:39:06 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id EAA13570 for ; Fri, 11 Dec 1998 04:38:58 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id EAA22601; Fri, 11 Dec 1998 04:28:53 -0800 (PST) Received: from zodiac.irf.se (zodiac.irf.se [192.71.13.221]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id EAA05971 for ; Fri, 11 Dec 1998 04:28:49 -0800 (PST) Received: (from micce@localhost) by zodiac.irf.se (8.8.7/8.8.7) id NAA03624; Fri, 11 Dec 1998 13:28:45 +0100 To: fhs-discuss@ucsd.edu Subject: /var/lib not useful? From: Mikael Hedin Date: 11 Dec 1998 13:28:45 +0100 Message-ID: X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Xref: sodium.transmeta.com linux.fhs:496 Status: RO Content-Length: 430 Lines: 14 I just realised I have nowhere to put my databases and other similar things (eg. cddb entries). I used to live in /var/lib/, but /var/lib is gone and no advice is stated. Where am I supposed to put the files from database-like applications? Regards, Micce -- Mikael Hedin +46 (0)980 79176 Institutet för rymdfysik +46 (0)980 73547 (home) Box 812, 981 28 KIRUNA, Sweden +46 (0)980 79050 (fax) From list-relay@mlist.ucsd.edu Fri Dec 11 05:55:42 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id FAA04765 for ; Fri, 11 Dec 1998 05:55:41 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id FAA21993 for ; Fri, 11 Dec 1998 05:55:40 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id FAA14149 for ; Fri, 11 Dec 1998 05:55:30 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id FAA23873; Fri, 11 Dec 1998 05:51:05 -0800 (PST) Received: from sinbad (user-38ldb2m.dialup.mindspring.com [209.86.172.86]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id FAA26390 for ; Fri, 11 Dec 1998 05:51:03 -0800 (PST) Received: from localhost (rpjday@localhost) by sinbad (8.8.7/8.8.7) with SMTP id JAA14700; Fri, 11 Dec 1998 09:04:08 -0500 X-Authentication-Warning: sinbad: rpjday owned process doing -bs Date: Fri, 11 Dec 1998 09:03:06 -0500 (EST) From: Rob Day X-Sender: rpjday@sinbad To: Mikael Hedin cc: fhs-discuss@ucsd.edu Subject: Re: /var/lib not useful? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:497 Status: RO Content-Length: 597 Lines: 21 On 11 Dec 1998, Mikael Hedin wrote: > I just realised I have nowhere to put my databases and other similar > things (eg. cddb entries). I used to live in /var/lib/, but > /var/lib is gone and no advice is stated. Where am I supposed to put > the files from database-like applications? On page 24 of FHS 2.0, "Previous versions of the FSSTND included a /var/lib hierarchy. For further information, see the section on /var/state." In that section, it states that "An application ... should use a subdirectory of /var/state for its data." Does this match what /var/lib used to do? rday From list-relay@mlist.ucsd.edu Fri Dec 11 06:55:17 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id GAA07098 for ; Fri, 11 Dec 1998 06:55:17 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id GAA22402 for ; Fri, 11 Dec 1998 06:54:53 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id GAA14590 for ; Fri, 11 Dec 1998 06:54:40 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id GAA24518; Fri, 11 Dec 1998 06:47:03 -0800 (PST) Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with SMTP id GAA13351 for ; Fri, 11 Dec 1998 06:47:01 -0800 (PST) From: t.sippel-dau@ic.ac.uk Received: from oban.cc.ic.ac.uk [155.198.5.28] by romeo.ic.ac.uk with smtp (Exim 1.62 #1) id 0zoTqM-00031E-00; Fri, 11 Dec 1998 14:46:58 +0000 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by oban.cc.ic.ac.uk with esmtp (Exim 1.90 #1) id 0zoTqK-0001xd-00; Fri, 11 Dec 1998 14:46:56 +0000 Received: by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id OAA28634; Fri, 11 Dec 1998 14:46:53 GMT Message-Id: <199812111446.OAA28634@cscmgb.cc.ic.ac.uk> Subject: Re: /var/lib not useful? To: micce@irf.se (Mikael Hedin) Date: Fri, 11 Dec 1998 14:46:52 +0000 (gmt) Cc: fhs-discuss@ucsd.edu In-Reply-To: from "Mikael Hedin" at Dec 11, 98 01:28:45 pm Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:498 Status: RO Content-Length: 1283 Lines: 32 The keyboard of Mikael Hedin emitted at some point in time: > > I just realised I have nowhere to put my databases and other similar > things (eg. cddb entries). I used to live in /var/lib/, but > /var/lib is gone and no advice is stated. Where am I supposed to put > the files from database-like applications? If the files are used only by that database, nobody cares, certainly not fhs. If it is a usage intensive database (i.e. you bought the machine for running it), then it should be treated like a user. If it is a service database (news, mail, finger, rhostd, nis, named, ... databases) then it should go somewhere into /var. But if any kind of interface stability is desired, clients should access a service, i.e. talk to a daemon, not just read files thay may not understand after an upgrade. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk * voice: +44 171 594 7076 (day) * fax: +44 171 584 1560 * snail: Thomas Sippel - Dau * Information Services Manager * Center of Vibration Engineering * Imperial College of Science, Technology and Medicine * Exhibition Road * Kensington SW7 2BX * Great Britain From list-relay@mlist.ucsd.edu Fri Dec 11 07:55:25 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id HAA09785 for ; Fri, 11 Dec 1998 07:55:25 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id HAA22965 for ; Fri, 11 Dec 1998 07:55:25 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id HAA15214 for ; Fri, 11 Dec 1998 07:55:15 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id HAA25456; Fri, 11 Dec 1998 07:51:42 -0800 (PST) Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with SMTP id HAA05876 for ; Fri, 11 Dec 1998 07:51:40 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA09616; Fri, 11 Dec 1998 15:51:42 GMT Received: from tamarix.rdg.opengroup.org [192.153.166.189] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Fri Dec 11 15:51 GMT 1998 Received: (from ajosey@localhost) by tamarix.rdg.opengroup.org (8.8.7/8.8.7) id PAA15195 for fhs-discuss@ucsd.edu; Fri, 11 Dec 1998 15:49:15 GMT Date: Fri, 11 Dec 1998 15:49:15 GMT From: Andrew Josey Message-Id: <981211154912.ZM15194@tamarix.rdg.opengroup.org> In-Reply-To: t.sippel-dau@ic.ac.uk's message as of Dec 11, 2:46pm. References: <199812111446.OAA28634@cscmgb.cc.ic.ac.uk> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: fhs-discuss@ucsd.edu Subject: test spec for FHS2.0 aspects of the LSB out for review Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: sodium.transmeta.com linux.fhs:499 Status: RO Content-Length: 187 Lines: 11 For your information. The test specification for the FHS 2.0 portion of the LSB is now out for review. See ftp://ftp.xopen.org/pub/lsb/test/README for more information. regards Andrew From list-relay@mlist.ucsd.edu Fri Dec 11 13:45:55 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id NAA02431 for ; Fri, 11 Dec 1998 13:45:55 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id NAA28358 for ; Fri, 11 Dec 1998 13:45:51 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id NAA20381 for ; Fri, 11 Dec 1998 13:45:44 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id NAA03106; Fri, 11 Dec 1998 13:42:40 -0800 (PST) Received: from mail.ka.inka.de (quechua.inka.de [193.197.84.11]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with SMTP id NAA05359 for ; Fri, 11 Dec 1998 13:42:34 -0800 (PST) Received: from uu.inka.de (ms1.ka.inka.de [193.197.84.8]) by mail.ka.inka.de with smtp id 0zoaKO-0001AP-00; Fri, 11 Dec 1998 22:42:24 +0100 Received: (aj@dungeon.inka.de) by uu.inka.de (S3.1.29.1) id ; Fri, 11 Dec 98 22:42 MET Received: from aj by dungeon.inka.de with local (Exim 2.05 #1) id 0zoaJL-0000KV-00 (Debian); Fri, 11 Dec 1998 22:41:19 +0100 Date: Fri, 11 Dec 1998 22:41:19 +0100 From: Andreas Jellinghaus Cc: fhs-discuss@ucsd.edu Subject: where to put server data Message-ID: <19981211224119.A1245@dungeon.inka.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.17i In-Reply-To: ; from Rob Day on Fri, Dec 11, 1998 at 09:03:06AM -0500 Xref: sodium.transmeta.com linux.fhs:500 Status: RO Content-Length: 715 Lines: 20 what is the right place for server data ? (not spooled data) stuff like www server, ftp server, database server, ... is /home/ a good place, or better /var/state/ ? i'm not looking for historic reasons, rather why one solution could be better than the other. realy, i don't know whats better. of course, if some data grows large, it might get it's own disk, so it will be ... does it make sence to use /var/opt/, if the server software was purchased from third party verndors ? where to put stuff like cvs ? i don't know if there is a need for a standard for such stauff. more important for me is first to get opinions what is good or bad, and why. regards, andreas From list-relay@mlist.ucsd.edu Sun Dec 13 08:36:54 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id IAA29668 for ; Sun, 13 Dec 1998 08:36:53 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id IAA13984 for ; Sun, 13 Dec 1998 08:36:52 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id IAA07281 for ; Sun, 13 Dec 1998 08:36:43 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id IAA08394; Sun, 13 Dec 1998 08:27:35 -0800 (PST) Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with SMTP id IAA00972 for ; Sun, 13 Dec 1998 08:27:34 -0800 (PST) From: t.sippel-dau@ic.ac.uk Received: from oban.cc.ic.ac.uk [155.198.5.28] by romeo.ic.ac.uk with smtp (Exim 1.62 #1) id 0zpEMm-0006YO-00; Sun, 13 Dec 1998 16:27:33 +0000 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by oban.cc.ic.ac.uk with esmtp (Exim 1.90 #1) id 0zpEMl-0003At-00; Sun, 13 Dec 1998 16:27:31 +0000 Received: by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id QAA16570; Sun, 13 Dec 1998 16:27:30 GMT Message-Id: <199812131627.QAA16570@cscmgb.cc.ic.ac.uk> Subject: Re: where to put server data To: aj@dungeon.inka.de (Andreas Jellinghaus) Date: Sun, 13 Dec 1998 16:27:30 +0000 (gmt) Cc: fhs-discuss@ucsd.edu In-Reply-To: <19981211224119.A1245@dungeon.inka.de> from "Andreas Jellinghaus" at Dec 11, 98 10:41:19 pm Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:501 Status: RO Content-Length: 2200 Lines: 59 The keyboard of Andreas Jellinghaus emitted at some point in time: > > what is the right place for server data ? (not spooled data) > stuff like www server, ftp server, database server, ... > is /home/ a good place, or better /var/state/ ? > i'm not looking for historic reasons, rather why one solution > could be better than the other. realy, i don't know whats better. > of course, if some data grows large, it might get it's own disk, > so it will be ... Please define "server data", in particular differentiate between the data that configures the server and the the data the server serves. Some examples: o user's home directories (on a file server) o html files for your web site o quota definition for the user disks o control files for the html server o name database for your domain's name server o usernames and passwords o X-server configuration o X-server fonts o X-server data streams o man pages in html form to be served via a web server o html documentation for packages (like XFree86 Looking through the list, you will have to agree that the best ansewer to your question is: on disk, with backup on tape or cd-rom, and cached in memory but that was surely not the answer you were looking for. > does it make sence to use /var/opt/, if the server software > was purchased from third party verndors ? Maybe, but if you buy afs ("a file server"), then you do not want the data volumes to be in /var/opt/afs, although some of the dynamic state and routing information may have its place there. > i don't know if there is a need for a standard for such stauff. No, there is not, unless you rephrase the question. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk * voice: +44 171 594 7076 (day) * fax: +44 171 584 1560 * snail: Thomas Sippel - Dau * Information Services Manager * Center of Vibration Engineering * Imperial College of Science, Technology and Medicine * Exhibition Road * Kensington SW7 2BX * Great Britain From list-relay@mlist.ucsd.edu Sun Dec 13 12:52:05 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id MAA07223 for ; Sun, 13 Dec 1998 12:52:04 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id MAA16094 for ; Sun, 13 Dec 1998 12:52:00 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id MAA09288 for ; Sun, 13 Dec 1998 12:51:56 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id MAA11648; Sun, 13 Dec 1998 12:47:41 -0800 (PST) Received: from albion.nurealm.net ([199.45.155.33]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id MAA15823 for ; Sun, 13 Dec 1998 12:47:39 -0800 (PST) Received: from albion.nurealm.net (502@local.host [127.0.0.1]) by albion.nurealm.net (8.8.2/8.8.2) with ESMTP id NAA00201; Sun, 13 Dec 1998 13:46:33 -0700 Message-Id: <199812132046.NAA00201@albion.nurealm.net> To: Andreas Jellinghaus Cc: fhs-discuss@ucsd.edu Subject: Re: where to put server data In-reply-to: Your message of "Fri, 11 Dec 1998 22:41:19 +0100." <19981211224119.A1245@dungeon.inka.de> Date: Sun, 13 Dec 1998 20:46:48 +0000 From: James Xref: sodium.transmeta.com linux.fhs:502 Status: RO Content-Length: 1343 Lines: 36 I put my server data in /home/// for practical reasons. Using /home/// is, I think, easier to explain to the new user, who is responsible for installing their own data files. /home//httpd/ /home//ftpd/ /home//httpd/ /home//ftpd/ . . . Now, that only works for servers that will support configurable data locations. Generally, that means virtual servers. Other server data, generally where the server itself, and not the user, is writing the data, are going into /var///. This includes, for instance, mail and database servers. Of course, /var/mail/ and /var/spool/mail/ are traditional. Though /home// would be more application-centric, I am not a proponent of an application-centric approach. Rather, I prefer a function-centric approach to file classification because it promotes an integrated file hierarchy instead of an "ad hoc" hierarchy. Long term, I want to see an integrated application environment on Free Unix; short term, I want to see Free Unix moving in that direction. Without a system environment which supports, or preferably encourages, an integrated application environment, I see a hindrance to that evolution. /var/opt// and /var/state// do not make any distinction which I find useful. James From list-relay@mlist.ucsd.edu Mon Dec 14 04:52:09 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id EAA23629 for ; Mon, 14 Dec 1998 04:52:09 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id EAA21938 for ; Mon, 14 Dec 1998 04:51:50 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id EAA15533 for ; Mon, 14 Dec 1998 04:50:25 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id EAA24674; Mon, 14 Dec 1998 04:44:48 -0800 (PST) Received: from romeo.ic.ac.uk (romeo.ic.ac.uk [155.198.5.9]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with SMTP id EAA24100 for ; Mon, 14 Dec 1998 04:44:45 -0800 (PST) From: t.sippel-dau@ic.ac.uk Received: from oban.cc.ic.ac.uk [155.198.5.28] by romeo.ic.ac.uk with smtp (Exim 1.62 #1) id 0zpXMi-00012v-00; Mon, 14 Dec 1998 12:44:44 +0000 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by oban.cc.ic.ac.uk with esmtp (Exim 1.90 #1) id 0zpXMh-00071i-00; Mon, 14 Dec 1998 12:44:43 +0000 Received: by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id MAA01378; Mon, 14 Dec 1998 12:44:38 GMT Message-Id: <199812141244.MAA01378@cscmgb.cc.ic.ac.uk> Subject: Re: where to put server data To: james@albion.nurealm.net (James) Date: Mon, 14 Dec 1998 12:44:37 +0000 (gmt) Cc: aj@dungeon.inka.de, fhs-discuss@ucsd.edu In-Reply-To: <199812132046.NAA00201@albion.nurealm.net> from "James" at Dec 13, 98 08:46:48 pm Reply-To: t.sippel-dau@ic.ac.uk (Thomas Sippel - Dau) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:504 Status: RO Content-Length: 1976 Lines: 45 The keyboard of James emitted at some point in time: > > I put my server data in /home/// for practical reasons. > Using /home/// is, I think, easier to explain to the new user, > who is responsible for installing their own data files. This discussion is becoming increasingly fruitless. The FHS is concerned with the logical access (i.e. by filename) to data commonly accessed by location rather than by function, in order to simplify administration (and creation) of add-on software for the unix (in particular Linux) system. There has been a considered effort to design out physical concepts, the FHS does not mandate that /usr is a seperate disk or seperate partition, or constrained to one file system. We kept the distinction beween /bin and /usr/bin, did not mandate that /bin is a link to /usr/bin, nor disallow systems to use such a link. We did write it so that /usr *may* be mounted read-only. We did try to eschew mandating link forests, but do not disallow their use. Any database that allows programs to access its data directly is fossilizing itself, there can never be change in the data format without breaking some of the programs that access the data. The most common example are file access permissions, the fact that programs can set them directly has hobbled all kinds of improvements, as people following the afs development will know - although these fossilized permissions do provide a "stable" environment. So if the data is: a) not relevant for system administration and b) not written on tablets of stone then do yourself a favour and include the time, the date and the weather in the filename you use to store it, and provide an easy way to access it. That way nobody will ever use a non-standard access, and nobody will ever ask you where it is stored. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk From list-relay@mlist.ucsd.edu Mon Dec 14 11:49:52 1998 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id LAA11403 for ; Mon, 14 Dec 1998 11:49:52 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id LAA27083 for ; Mon, 14 Dec 1998 11:49:51 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id LAA20543 for ; Mon, 14 Dec 1998 11:49:49 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.8.8AS/8.6.9) with ESMTP id JAA28624; Mon, 14 Dec 1998 09:50:21 -0800 (PST) Received: from zodiac.irf.se (zodiac.irf.se [192.71.13.221]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id JAA19494 for ; Mon, 14 Dec 1998 09:50:19 -0800 (PST) Received: (from micce@localhost) by zodiac.irf.se (8.8.7/8.8.7) id SAA18709; Mon, 14 Dec 1998 18:50:15 +0100 To: Rob Day Cc: fhs-discuss@ucsd.edu Subject: Re: /var/lib not useful? References: From: Mikael Hedin Date: 14 Dec 1998 18:50:15 +0100 In-Reply-To: Rob Day's message of "Fri, 11 Dec 1998 09:03:06 -0500 (EST)" Message-ID: X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Xref: sodium.transmeta.com linux.fhs:505 Status: RO Content-Length: 680 Lines: 21 Rob Day writes: > > In that section, it states that "An application ... should use a > subdirectory of /var/state for its data." > I thought about the "pertains to one specific host". This make it "impossible" to share eg. a cddb tree (a system of files with CD-contents in text format-you could share it between different architectures at a site). But I guess that usage is not a very Good Thing (tm) any way, you should maybe set up a server instead if you want such a thing? /Micce -- Mikael Hedin +46 (0)980 79176 Institutet för rymdfysik +46 (0)980 73547 (home) Box 812, 981 28 KIRUNA, Sweden +46 (0)980 79050 (fax) From list-relay@mlist.ucsd.edu Mon Jan 25 01:14:01 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id BAA16349 for ; Mon, 25 Jan 1999 01:14:00 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id BAA22166 for ; Mon, 25 Jan 1999 01:13:59 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id BAA08200 for ; Mon, 25 Jan 1999 01:13:57 -0800 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id BAA29041; Mon, 25 Jan 1999 01:04:55 -0800 (PST) Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id BAA17063 for ; Mon, 25 Jan 1999 01:04:54 -0800 (PST) Received: from alum.mit.edu (209-122-231-149.s149.tnt4.sbo.erols.com [209.122.231.149]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id EAA19995 for ; Mon, 25 Jan 1999 04:04:53 -0500 (EST) Sender: mstx@erols.com Message-ID: <36AC0095.CB76F077@alum.mit.edu> Date: Mon, 25 Jan 1999 00:26:45 -0500 From: Maciej Stachowiak X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.0.34 i586) MIME-Version: 1.0 To: fhs-discuss@ucsd.edu Subject: /libexec and /usr/libexec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:578 Status: RO Content-Length: 302 Lines: 9 Is there a particular reason that FHS does not standardize /usr/libexec as the proper locations for programs only intended to be run by other programs, instead of (apparently) /usr/lib? Apologies if this issue has been discussed already but I can't find an archive of this list. - Maciej Stachowiak From list-relay@mlist.ucsd.edu Mon Jan 25 12:23:12 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id MAA10615 for ; Mon, 25 Jan 1999 12:23:12 -0800 (PST) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id MAA29665 for ; Mon, 25 Jan 1999 12:23:12 -0800 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id MAA15767 for ; Mon, 25 Jan 1999 12:23:11 -0800 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id MAA10350; Mon, 25 Jan 1999 12:16:34 -0800 (PST) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id MAA21545 for ; Mon, 25 Jan 1999 12:16:33 -0800 (PST) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id MAA29552; Mon, 25 Jan 1999 12:15:13 -0800 Received: from sodium.transmeta.com (quinlan@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id MAA09741; Mon, 25 Jan 1999 12:15:12 -0800 (PST) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id MAA15874; Mon, 25 Jan 1999 12:15:12 -0800 To: Maciej Stachowiak Cc: fhs-discuss@ucsd.edu Subject: Re: /libexec and /usr/libexec References: <36AC0095.CB76F077@alum.mit.edu> From: Daniel Quinlan Date: 25 Jan 1999 12:15:12 -0800 In-Reply-To: Maciej Stachowiak's message of Mon, 25 Jan 1999 00:26:45 -0500 Message-ID: <6y4spfm7n3.fsf@sodium.transmeta.com> X-Mailer: Gnus v5.3/Emacs 19.34 Xref: sodium.transmeta.com linux.fhs:583 Status: RO Content-Length: 557 Lines: 17 Maciej Stachowiak writes: > Is there a particular reason that FHS does not standardize > /usr/libexec as the proper locations for programs only intended > to be run by other programs, instead of (apparently) /usr/lib? > > Apologies if this issue has been discussed already but I can't > find an archive of this list. What's the advantage of /usr/libexec? Also, how exactly does it pay to put executable architecture-specific data (that isn't in any PATH) and non-executable architecture-specific data in different places? - Dan From list-relay@mlist.ucsd.edu Tue May 25 23:03:26 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id XAA14732 for ; Tue, 25 May 1999 23:03:25 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id XAA28999 for ; Tue, 25 May 1999 23:03:25 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id XAA15926 for ; Tue, 25 May 1999 23:03:23 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id WAA10009; Tue, 25 May 1999 22:32:53 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id WAA25790 for ; Tue, 25 May 1999 22:32:52 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id WAA28721 for ; Tue, 25 May 1999 22:32:51 -0700 Received: from sodium.transmeta.com (quinlan@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id WAA14250 for ; Tue, 25 May 1999 22:32:50 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id WAA21819; Tue, 25 May 1999 22:32:50 -0700 Date: Tue, 25 May 1999 22:32:50 -0700 Message-Id: <199905260532.WAA21819@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: fhs-discuss@UCSD.Edu Subject: FHS pre-2.1 draft #1 on web site X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:745 Status: RO Content-Length: 1861 Lines: 45 Surprise. FHS 2.1 will be a much needed update. The reason is not so much for the ideas being discussed on the FHS mailing list recently, but for fixing some basic problems with FHS 2.0. These are problems that developers from various distributions (Caldera, Debian, Red Hat, and SuSE) have requested that FHS 2.1 fix. The major changes are as follows: /var/state is back at /var/lib, but using the /var/state specification. Moving the directory was unnecessary and was a stopping point for distributions. Tweaking the specification a little was okay, but moving it was evidently not. /var/mail is back at /var/spool/mail. Various solutions, such as allowing either with symbolic links have been discussed ad-nauseum on both the FHS and LSB mailing lists. Since nobody (that I'm aware of) has actually used /var/mail in a distribution or application, the best fix is to switch back. Locally, people can use whatever symbolic links they want, as always. Applications and distributions need to reference /var/spool/mail (as they do in reality). A number of editorial changes from Bernd Warken have also been integrated into the draft. I hope I got them all right. Thanks, Bernd. I'm hoping to make at least one or two more fixes prior to FHS 2.1 being released, but they will be the subject of another posting. My plan is that FHS 2.2 will be significantly rewritten. Some parts of the specification are lost causes and should be totally redone. For example, instead of saying: these binaries go into /bin and these other ones go into /usr/bin. We should really say that some small number (like /bin/sh) are fixed in certain locations and the rest may either appear in /bin or /usr/bin (probably using the PATH mechanism to access them). Get it at: http://www.pathname.com/fhs/fhs-2.1-pre-01.tar.gz Dan From list-relay@mlist.ucsd.edu Wed May 26 13:33:46 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id NAA05574 for ; Wed, 26 May 1999 13:33:46 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id NAA05637 for ; Wed, 26 May 1999 13:33:45 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id NAA25365 for ; Wed, 26 May 1999 13:33:44 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id MAA26951; Wed, 26 May 1999 12:56:56 -0700 (PDT) Received: from talamasca.wkpowerlink.com (talamasca.wkpowerlink.com [209.52.243.211]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id MAA19324 for ; Wed, 26 May 1999 12:56:54 -0700 (PDT) Received: from khar-pern.talamasca (ts1-65.kamloops.wkpowerlink.com [207.194.192.65]) by talamasca.wkpowerlink.com (8.8.7/8.8.7) with ESMTP id MAA15845 for ; Wed, 26 May 1999 12:59:06 -0700 Received: from michael by khar-pern.talamasca with local (Exim 2.12 #1) id 10mjnW-0001wf-00 for fhs-discuss@ucsd.edu; Wed, 26 May 1999 12:57:06 -0700 Date: Wed, 26 May 1999 12:57:06 -0700 (PDT) From: Michael Deutschmann To: fhs-discuss@ucsd.edu Subject: /var/state -> /var/lib (Was: FHS pre-2.1) In-Reply-To: <199905260532.WAA21819@sodium.transmeta.com> Message-ID: <%vuET3URHN@khar-pern.talamasca> X-User-Agent: Mana 4.0beta (Linux) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:746 Status: RO Content-Length: 785 Lines: 18 > /var/state is back at /var/lib, but using the /var/state > specification. Moving the directory was unnecessary and was a > stopping point for distributions. Tweaking the specification a > little was okay, but moving it was evidently not. How was that a big problem? In my experience, programs seldom use the directory. Most common needs for variable files are handled by other /var directories (cache, run, lock, log), etc. A few server programs could in theory use this directory, but in practice they ignore the FHS order anyway (ie: Samba, INN). Every file in /var/state on my home box was explicitly moved there by me, and not from "/var/lib" or even by using the autoconf --localstatedir= option. ---- Michael Deutschmann From list-relay@mlist.ucsd.edu Wed May 26 14:51:49 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id OAA08413 for ; Wed, 26 May 1999 14:51:49 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id OAA06808 for ; Wed, 26 May 1999 14:51:48 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id OAA26548 for ; Wed, 26 May 1999 14:51:45 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id OAA29022; Wed, 26 May 1999 14:15:49 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id OAA03664 for ; Wed, 26 May 1999 14:15:47 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id OAA06299; Wed, 26 May 1999 14:15:44 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id OAA07410; Wed, 26 May 1999 14:15:43 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id OAA02002; Wed, 26 May 1999 14:15:43 -0700 Date: Wed, 26 May 1999 14:15:43 -0700 Message-Id: <199905262115.OAA02002@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Deutschmann Cc: fhs-discuss@ucsd.edu Subject: Re: /var/state -> /var/lib (Was: FHS pre-2.1) In-Reply-To: <%vuET3URHN@khar-pern.talamasca> References: <199905260532.WAA21819@sodium.transmeta.com> <%vuET3URHN@khar-pern.talamasca> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:747 Status: RO Content-Length: 475 Lines: 14 Michael Deutschmann writes: > How was [/var/state] a big problem? In my experience, programs > seldom use the directory. Most common needs for variable files are > handled by other /var directories (cache, run, lock, log), etc. The problem was /var/lib/. Moving it was a problem for both rpm and dpkg. Other than that, it was an easy transition, but because of the package manager issue, nobody was doing it. - Dan From list-relay@mlist.ucsd.edu Wed May 26 14:51:59 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id OAA08420 for ; Wed, 26 May 1999 14:51:54 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id OAA06802 for ; Wed, 26 May 1999 14:51:45 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id OAA26543 for ; Wed, 26 May 1999 14:51:43 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id OAA29193; Wed, 26 May 1999 14:24:53 -0700 (PDT) Received: from gwyn.tux.org (gwyn.tux.org [207.96.122.8]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id OAA18256 for ; Wed, 26 May 1999 14:24:51 -0700 (PDT) Received: from localhost (niemi@localhost) by gwyn.tux.org (8.9.1/8.9.1) with ESMTP id RAA12616 for ; Wed, 26 May 1999 17:24:49 -0400 Date: Wed, 26 May 1999 17:24:48 -0400 (EDT) From: David C Niemi To: fhs-discuss@UCSD.Edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905260532.WAA21819@sodium.transmeta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:748 Status: RO Content-Length: 2561 Lines: 54 On Tue, 25 May 1999, Daniel Quinlan wrote: > Surprise. > > FHS 2.1 will be a much needed update. The reason is not so much for > the ideas being discussed on the FHS mailing list recently, but for > fixing some basic problems with FHS 2.0. These are problems that > developers from various distributions (Caldera, Debian, Red Hat, and > SuSE) have requested that FHS 2.1 fix. ... Ugh. What kind of decision making process are we being subjected to? I realize this was never a democracy, but is this just a pointless discussion list, which will be overruled at any time without notice due to private agreements amongst 4 distributors? If so, the FHS decisionmaking process completely lacks transparency, and this list might as well change to an announce list, it will save us all a lot of time. > /var/mail is back at /var/spool/mail. Various solutions, such as > allowing either with symbolic links have been discussed ad-nauseum > on both the FHS and LSB mailing lists. Since nobody (that I'm > aware of) has actually used /var/mail in a distribution or > application, the best fix is to switch back. Locally, people can > use whatever symbolic links they want, as always. Applications and > distributions need to reference /var/spool/mail (as they do in > reality). Ugh again. It might have been good to consult app vendors and non-Linux distributors on this one. Having Linux distributors nix it because no Linux distributors have done /var/mail is circular reasoning at best. The FHS also will lose credibility and horribly frustrate app vendors in the process of flip-flopping on this issue. At a minimum it should be required that /var/mail and /var/spool/mail both work and point to the same place, whilst the long-term direction is debated. IIRC Linux is the only modern OS still using /var/spool/mail, all others have moved to /var/mail some time ago. ... > My plan is that FHS 2.2 will be significantly rewritten. Some parts > of the specification are lost causes and should be totally redone. > For example, instead of saying: these binaries go into /bin and these > other ones go into /usr/bin. We should really say that some small > number (like /bin/sh) are fixed in certain locations and the rest may > either appear in /bin or /usr/bin (probably using the PATH mechanism > to access them). This part sounds OK. ---- David C Niemi ----niemi at tux.org---- Reston VA USA ---- ... as FUD is our witness, we will never go hungry again. Microsoft OEM account manager, 1992. From list-relay@mlist.ucsd.edu Wed May 26 16:00:37 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id QAA12279 for ; Wed, 26 May 1999 16:00:37 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id QAA07993 for ; Wed, 26 May 1999 16:00:36 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id QAA27498 for ; Wed, 26 May 1999 16:00:34 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id PAA00856; Wed, 26 May 1999 15:23:32 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id PAA16154 for ; Wed, 26 May 1999 15:23:29 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id PAA07256; Wed, 26 May 1999 15:23:24 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id PAA09742; Wed, 26 May 1999 15:23:19 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id PAA02586; Wed, 26 May 1999 15:23:18 -0700 To: David C Niemi Cc: fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site References: From: Daniel Quinlan Date: 26 May 1999 15:23:18 -0700 In-Reply-To: David C Niemi's message of Wed, 26 May 1999 17:24:48 -0400 (EDT) Message-ID: <6yg14jbhd5.fsf@sodium.transmeta.com> X-Mailer: Gnus v5.3/Emacs 19.34 Xref: sodium.transmeta.com linux.fhs:753 Status: RO Content-Length: 1721 Lines: 38 David C Niemi writes: > Ugh. What kind of decision making process are we being subjected to? I > realize this was never a democracy, but is this just a pointless discussion > list, which will be overruled at any time without notice due to private > agreements amongst 4 distributors? If so, the FHS decisionmaking process > completely lacks transparency, and this list might as well change to an > announce list, it will save us all a lot of time. Fair objection. The original decision (you can still blame me since I made the final call) to move the mail directory was somewhat controversial here and the straw poll was something like 52%/48%. With the 4 largest distributions *still* on the 48% side, I hope you can see how the decision was made. > IIRC Linux is the only modern OS still using /var/spool/mail, all others > have moved to /var/mail some time ago. Well, it's not an issue today like it was 2 years ago. More significantly, most applications use paths.h, which is *always* modified by distributions to use /var/spool/mail. If we must, we can add a symbolic link at /var/mail, but /var/spool/mail is going to stay the reference directory. I think an example of something that will break (that currently works on any Linux distribution) would be nice before we do that. I could be opened up to the idea of a straw poll on whether we add the /var/mail symbolic link in, but my driving concern is that adding the symbolic link on a non-local basis would lead to more confusion and problems (such as running new applications on older distributions that are missing the link) than a simple reversion. Any thoughts from resident application-developers or distribution-makers? - Dan From list-relay@mlist.ucsd.edu Wed May 26 16:03:16 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id QAA12423 for ; Wed, 26 May 1999 16:03:15 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id QAA08054 for ; Wed, 26 May 1999 16:03:15 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id QAA27539 for ; Wed, 26 May 1999 16:03:13 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id PAA00826; Wed, 26 May 1999 15:22:26 -0700 (PDT) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id PAA28842 for ; Wed, 26 May 1999 15:22:24 -0700 (PDT) Received: from grobbebol.xs4all.nl (grobbebol.xs4all.nl [194.109.14.68]) by smtp1.xs4all.nl (8.8.8/8.8.8) with ESMTP id AAA20955; Thu, 27 May 1999 00:22:18 +0200 (CEST) Received: (from bengel@localhost) by grobbebol.xs4all.nl (8.9.3/8.9.3) id WAA29965; Wed, 26 May 1999 22:06:53 GMT From: "Roeland Th. Jansen" Message-Id: <199905262206.WAA29965@grobbebol.xs4all.nl> Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: from David C Niemi at "May 26, 1999 05:24:48 pm" To: David C Niemi Date: Wed, 26 May 1999 22:06:26 +0000 (GMT) CC: fhs-discuss@ucsd.edu Reply-To: bengel@xs4all.nl X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:754 Status: RO Content-Length: 496 Lines: 14 > IIRC Linux is the only modern OS still using /var/spool/mail, all others > have moved to /var/mail some time ago. this discussion has taken place quite some time ago and the solution is to add symlinks if required. do we really have to go over this again ? -- Grobbebol's Home | Don't give in to spammers. -o) MCSE: Must Consult Someone Experienced | Use your real e-mail address /\ Linux 2.2.9. on an i586/64 MB | on Usenet. _\_v From list-relay@mlist.ucsd.edu Wed May 26 21:24:54 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA24479 for ; Wed, 26 May 1999 21:24:54 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA11716 for ; Wed, 26 May 1999 21:24:53 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id VAA31055 for ; Wed, 26 May 1999 21:24:51 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id UAA07230; Wed, 26 May 1999 20:54:15 -0700 (PDT) Received: from talamasca.wkpowerlink.com (talamasca.wkpowerlink.com [209.52.243.211]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id UAA00267 for ; Wed, 26 May 1999 20:54:15 -0700 (PDT) Received: from khar-pern.talamasca (ts1-17.kamloops.wkpowerlink.com [207.194.192.17]) by talamasca.wkpowerlink.com (8.8.7/8.8.7) with ESMTP id UAA16210 for ; Wed, 26 May 1999 20:56:47 -0700 Received: from michael by khar-pern.talamasca with local (Exim 2.12 #1) id 10mrFv-00029S-00 for fhs-discuss@ucsd.edu; Wed, 26 May 1999 20:54:55 -0700 Date: Wed, 26 May 1999 20:54:55 -0700 (PDT) From: Michael Deutschmann To: fhs-discuss@ucsd.edu Subject: Re: /var/state -> /var/lib (Was: FHS pre-2.1) In-Reply-To: <199905262115.OAA02002@sodium.transmeta.com> Message-ID: <%-vLT3QBIj@khar-pern.talamasca> X-User-Agent: Mana 4.0beta (Linux) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:758 Status: RO Content-Length: 1219 Lines: 31 > > How was [/var/state] a big problem? In my experience, programs > > seldom use the directory. Most common needs for variable files are > > handled by other /var directories (cache, run, lock, log), etc. > > The problem was /var/lib/. Moving it was a problem > for both rpm and dpkg. > > Other than that, it was an easy transition, but because of the package > manager issue, nobody was doing it. Perhaps we should grandfather in those package managers, while moving the other applications over. Using a name that shadows a completely different directory in /usr is really ugly. Besides, it could be argued that package-manager state does transcend other application data, and deserves it's own spot anyways. ---- On a related note, why not merge what's left of /var/state with /var/spool? I've never seen any good reason that "work accumulated to be done later" has a different storage requirement than the state files. Many programs (such as Exim or PPR) with both `spool files' and `non-spool local variable files' take one directory in spool and use it for both. So it's not like spool is pure in the status quo. ---- Michael Deutschmann From list-relay@mlist.ucsd.edu Thu May 27 06:46:47 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id GAA02852 for ; Thu, 27 May 1999 06:46:46 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id GAA16313 for ; Thu, 27 May 1999 06:46:46 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id GAA03303 for ; Thu, 27 May 1999 06:46:43 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id GAA17048; Thu, 27 May 1999 06:26:10 -0700 (PDT) Received: from judy.ic.ac.uk (judy.ic.ac.uk [155.198.5.28]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id GAA13699 for ; Thu, 27 May 1999 06:26:08 -0700 (PDT) Received: from juliet.ic.ac.uk ([155.198.5.4]) by judy.ic.ac.uk with esmtp (Exim 2.12 #1) id 10n0AW-00013r-00; Thu, 27 May 1999 13:25:56 +0000 Received: from sg1.cc.ic.ac.uk ([155.198.63.8] helo=cscmgb.cc.ic.ac.uk) by juliet.ic.ac.uk with esmtp (Exim 2.12 #1) id 10n0AA-0001Uh-00; Thu, 27 May 1999 13:25:34 +0000 Received: from ic.ac.uk by cscmgb.cc.ic.ac.uk (980427.SGI.8.8.8/4.0) id OAA24997; Thu, 27 May 1999 14:25:22 +0100 (bst) Sender: cmaae47@ic.ac.uk Message-ID: <374D4840.821EAFC6@ic.ac.uk> Date: Thu, 27 May 1999 13:27:28 +0000 From: Thomas Sippel - Dau Reply-To: t.sippel-dau@ic.ac.uk Organization: Imperial College of Science, Technology and Medicine X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: quinlan@transmeta.com CC: fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site References: <199905260532.WAA21819@sodium.transmeta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:764 Status: RO Content-Length: 3248 Lines: 83 Daniel Quinlan wrote: > > Surprise. > > The major changes are as follows: > > /var/state is back at /var/lib AFAIR the original paradigm for /var/state was transient application and user specific data that needed to survive reboots, such as vi edit sessions in case of power failure. How that should have impacted on the rpm database is a mystery to me, but there goes. Yes, I know, after installing packages a reboot is easiest to document, even if not strictly speaking necessary. But I would not call editor drop files and installation state the same class of data. > /var/mail is back at /var/spool/mail. Again, fine with me. I always said this heated debate was supine, and I stick with that. > A number of editorial changes from Bernd Warken have also been > integrated into the draft. I hope I got them all right. Thanks, > Bernd. If Bernd has made good on his departure (to avoid being sued for trademark infringement), I can modify his German translation accordingly if he has not withdrawn it. We should put a clarification of the term UNIX in the preamble. > My plan is that FHS 2.2 will be significantly rewritten. Some parts > of the specification are lost causes and should be totally redone. > For example, instead of saying: these binaries go into /bin and these > other ones go into /usr/bin. .... Yes, there is a lot of clutter, special cases and so on in the standard. We should concentrate on: o data files (rather than programs), that are o used by several applications o small in bulk The most difficult to diget part of the FHS as now is the .../man/... specification. Unfortunately, that will lead a lot more work. We have already non-determinate ranks there (i.e. "optional path components"), and having the character set as part of the locale component is certainly debatable. Many EU countries are changing character set to accommodate the Euro symbol, which is next to irrelevant for man pages, but will create a large body of confusion if a new installation of a product does not delete the old man page because it now written in a "different character set". Also, the bit in /usr/share/dict specifying the *English* name for the laguage as a filename will not pass muster for long. Looking forward, the (implicit) stipulation that the file system is expressed in the 7-bit ascii subset will not be good enough for much longer. Once the system has been done in Unicode, can filenames contain o all characters apart from a certain set (that is what the specification is now) o all characters from a certain set (the same set as used now) It should be clear that fairly soon people want to give their files names not expressible in ascii, and will walk away from a systems that does not allow that. Thomas * Why not use metric units and get it right first time, every time ? * * email: cmaae47 @ imperial.ac.uk * voice: +44 171 594 6915 (day) * fax: +44 171 594 6958 * snail: Thomas Sippel - Dau * Linux Services Manager * Imperial College of Science, Technology and Medicine * The Center for Computing Services * Exhibition Road * Kensington SW7 2BX * Great Britain From list-relay@mlist.ucsd.edu Thu May 27 17:26:58 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id RAA05651 for ; Thu, 27 May 1999 17:26:53 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id RAA26043 for ; Thu, 27 May 1999 17:26:52 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id RAA12266 for ; Thu, 27 May 1999 17:26:50 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id QAA29138; Thu, 27 May 1999 16:46:06 -0700 (PDT) Received: from gndrsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id PAA26371 for ; Thu, 27 May 1999 15:59:48 -0700 (PDT) Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.9.3/8.9.3) id PAA24382; Thu, 27 May 1999 15:59:12 -0700 (PDT) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199905272259.PAA24382@gndrsh.aac.dev.com> Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <6yg14jbhd5.fsf@sodium.transmeta.com> from Daniel Quinlan at "May 26, 1999 03:23:18 pm" To: quinlan@transmeta.com (Daniel Quinlan) Date: Thu, 27 May 1999 15:59:12 -0700 (PDT) Cc: niemi@tux.org (David C Niemi), fhs-discuss@UCSD.Edu X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:769 Status: RO Content-Length: 1327 Lines: 28 > David C Niemi writes: > > > Ugh. What kind of decision making process are we being subjected to? I > > realize this was never a democracy, but is this just a pointless discussion > > list, which will be overruled at any time without notice due to private > > agreements amongst 4 distributors? If so, the FHS decisionmaking process > > completely lacks transparency, and this list might as well change to an > > announce list, it will save us all a lot of time. > > Fair objection. The original decision (you can still blame me since I > made the final call) to move the mail directory was somewhat > controversial here and the straw poll was something like 52%/48%. > With the 4 largest distributions *still* on the 48% side, I hope you > can see how the decision was made. The 4 largest distributors seems to have out weighed all the input and discussion that went on 2 years ago when the /var/mail decision was made. You have walfed on _ALL_ of the BSD derived os's :-(. I suspect that this was the last one to finally revert so you might as well revert the name of the standard back to being Linux centric as well. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com From list-relay@mlist.ucsd.edu Thu May 27 18:40:42 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id SAA09512 for ; Thu, 27 May 1999 18:40:42 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id SAA26974 for ; Thu, 27 May 1999 18:40:42 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id SAA13283 for ; Thu, 27 May 1999 18:40:40 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id SAA00751; Thu, 27 May 1999 18:01:51 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id QAA19423 for ; Thu, 27 May 1999 16:58:44 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id QAA25654; Thu, 27 May 1999 16:58:10 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id QAA00680; Thu, 27 May 1999 16:58:09 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id QAA18437; Thu, 27 May 1999 16:58:08 -0700 Date: Thu, 27 May 1999 16:58:08 -0700 Message-Id: <199905272358.QAA18437@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Rodney W. Grimes" Cc: quinlan@transmeta.com (Daniel Quinlan), niemi@tux.org (David C Niemi), fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905272259.PAA24382@gndrsh.aac.dev.com> References: <6yg14jbhd5.fsf@sodium.transmeta.com> <199905272259.PAA24382@gndrsh.aac.dev.com> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:770 Status: RO Content-Length: 1977 Lines: 44 Rodney W Grimes writes: > The 4 largest distributors seems to have out weighed all the input and > discussion that went on 2 years ago when the /var/mail decision was made. > You have walfed on _ALL_ of the BSD derived os's :-(. Yes, but BSD bailed out on us 2 years ago (and several times since then). You only get to bail once. I'd like the FHS to be used by more Unix and Unix-like systems (or distributions), but should I give higher priority to systems currently using FHS 1.2 and working on FHS 2.0, or should I weigh any potential system equally with current systems? We have, however, retained a number of improvements snarfed from the BSD filesystem hierarchy (plus the changes predating FHS 2.0 that went into FSSTND 1.0 to FSSTND 1.2): /usr/share, /var/account, /var/run, more of /var, etc. I should at least, describe the problem cited by distributions in moving from /var/spool/mail to /var/mail. Linux distributions work very hard to do in-place upgrades of systems. Moving the mail spool, which is often a remote partition, or (unfortunately) an NFS mount, is not a trivial task. As I said, I'm open to requiring a /var/mail symbolic link (now or at any time in the future). FHS 2.1 is the same as FSSTND 1.2 for the mail spool specification. FHS 2.0 can be ignored -- because it was (due to these two issues). If someone can come up with a transition plan for moving Linux from /var/spool/mail to /var/mail (even requiring a /var/spool/mail symbolic link for some time) and sell it to the major distributions, I'd love to move to /var/mail since it's what everyone else is doing. > I suspect that this was the last one to finally revert so you might as > well revert the name of the standard back to being Linux centric as well. You may be right. I hope there are ideas in the FHS that other systems may adopt, though. The right solution may be to move /var/mail and /var/spool/mail into OS-specific annexes. - Dan From list-relay@mlist.ucsd.edu Thu May 27 19:39:25 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id TAA11512 for ; Thu, 27 May 1999 19:39:25 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id TAA27562 for ; Thu, 27 May 1999 19:39:24 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id TAA13892 for ; Thu, 27 May 1999 19:39:23 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id TAA02240; Thu, 27 May 1999 19:11:55 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id TAA21202 for ; Thu, 27 May 1999 19:11:54 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id TAA27290; Thu, 27 May 1999 19:11:53 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id TAA10864; Thu, 27 May 1999 19:11:53 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id TAA19823; Thu, 27 May 1999 19:11:52 -0700 Date: Thu, 27 May 1999 19:11:52 -0700 Message-Id: <199905280211.TAA19823@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: quinlan@transmeta.com Cc: "Rodney W. Grimes" , niemi@tux.org (David C Niemi), fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905272358.QAA18437@sodium.transmeta.com> References: <6yg14jbhd5.fsf@sodium.transmeta.com> <199905272259.PAA24382@gndrsh.aac.dev.com> <199905272358.QAA18437@sodium.transmeta.com> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:771 Status: RO Content-Length: 1349 Lines: 32 Daniel Quinlan writes: > Yes, but BSD bailed out on us 2 years ago (and several times since > then). You only get to bail once. I would, however, try to welcome any BSD distribution back into the discussion, but the discussion could not just be between myself and BSD. It must include the people who decide what standards to adopt for Linux (the distributions and developers). I think one of the main mistakes here was not getting BSD and Linux distributions involved *at the same time*. In the hypothetical situation of reinvolvement from BSD quarters, we should also take a more pragmatic tack: 1. Clean up the FHS (move blatant Linux stuff like /var/spool/mail into the annex). 2. Create a BSD annex (written by a BSD developer). 3. See which items we can move out of the Linux annex and BSD annex into the main section (because all parties agree on them). 4. Let everyone evaluate the FHS independently at that point. Adopting an all-or-none approach is pointless. None of that implies an unrealistic commitment from either the Linux or BSD community, and even if nothing is moved out of the annexes, nobody gets hurt. Rodney (or anyone else): if you'd like to help with either item 1 or item 2, please let me know. I don't have the time resources right now to take all of that work on myself. Dan From list-relay@mlist.ucsd.edu Thu May 27 20:00:37 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id UAA11929 for ; Thu, 27 May 1999 20:00:36 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id UAA27746 for ; Thu, 27 May 1999 20:00:36 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id UAA14077 for ; Thu, 27 May 1999 20:00:34 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id TAA02505; Thu, 27 May 1999 19:26:40 -0700 (PDT) Received: from gndrsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id TAA22528 for ; Thu, 27 May 1999 19:26:38 -0700 (PDT) Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.9.3/8.9.3) id TAA24684; Thu, 27 May 1999 19:26:31 -0700 (PDT) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199905280226.TAA24684@gndrsh.aac.dev.com> Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905280211.TAA19823@sodium.transmeta.com> from Daniel Quinlan at "May 27, 1999 07:11:52 pm" To: quinlan@transmeta.com Date: Thu, 27 May 1999 19:26:31 -0700 (PDT) Cc: niemi@tux.org (David C Niemi), fhs-discuss@ucsd.edu X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:772 Status: RO Content-Length: 2542 Lines: 67 > Daniel Quinlan writes: > > > Yes, but BSD bailed out on us 2 years ago (and several times since > > then). You only get to bail once. > > I would, however, try to welcome any BSD distribution back into the > discussion, but the discussion could not just be between myself and BSD. > It must include the people who decide what standards to adopt for Linux > (the distributions and developers). I think one of the main mistakes > here was not getting BSD and Linux distributions involved *at the same > time*. Probably.. but you didn't get the BSD ``distributors'' you got the BSD developers, the folks that write the code, you _HAD_ the people who could have made this happen accross a major portion of the BSD world. But lets just leave that lay in the past and see what we can do with what you layed out below. > > In the hypothetical situation of reinvolvement from BSD quarters, we > should also take a more pragmatic tack: > > 1. Clean up the FHS (move blatant Linux stuff like /var/spool/mail into > the annex). a) Point me at the latest copy and I'll see if I can make a markup pass on the disparity between the current FHS and FreeBSD man 4 hier. > 2. Create a BSD annex (written by a BSD developer). That falls out of me doing a) above. > 3. See which items we can move out of the Linux annex and BSD annex > into the main section (because all parties agree on them). This would require getting at least 1 or two people from each of no less than FreeBSD, NetBSD, OpenBSD, and BSDI. This is going to be tough, but perhaps if we take the finished work of 1) and 2) above to them and show that the FHS has been made neutral on the Linux/BSD plain we might stand a chance of getting them to at least look at it. > 4. Let everyone evaluate the FHS independently at that point. Perhaps 3 and 4 should be reversed :-) > > Adopting an all-or-none approach is pointless. None of that implies an > unrealistic commitment from either the Linux or BSD community, and even > if nothing is moved out of the annexes, nobody gets hurt. Agreed. > > Rodney (or anyone else): if you'd like to help with either item 1 or > item 2, please let me know. I don't have the time resources right now > to take all of that work on myself. If anyone would like to help me get either 1 or 2 done please drop me a note. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com From list-relay@mlist.ucsd.edu Thu May 27 20:17:28 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id UAA12345 for ; Thu, 27 May 1999 20:17:28 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id UAA27903 for ; Thu, 27 May 1999 20:17:28 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id UAA14235 for ; Thu, 27 May 1999 20:17:26 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id TAA03027; Thu, 27 May 1999 19:59:37 -0700 (PDT) Received: from dcl.MIT.EDU (DCL.MIT.EDU [18.172.1.4]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id TAA08226 for ; Thu, 27 May 1999 19:59:37 -0700 (PDT) Received: by dcl.MIT.EDU with sendmail-8.8.8+Sun/1.2, id WAA17330; Thu, 27 May 1999 22:59:31 -0400 (EDT) Date: Thu, 27 May 1999 22:59:31 -0400 (EDT) Message-Id: <199905280259.WAA17330@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: quinlan@transmeta.com CC: "Rodney W. Grimes" , quinlan@transmeta.com, niemi@tux.org, fhs-discuss@ucsd.edu In-reply-to: Daniel Quinlan's message of Thu, 27 May 1999 16:58:08 -0700, <199905272358.QAA18437@sodium.transmeta.com> Subject: Re: FHS pre-2.1 draft #1 on web site Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:773 Status: RO Content-Length: 1967 Lines: 40 Date: Thu, 27 May 1999 16:58:08 -0700 From: Daniel Quinlan I should at least, describe the problem cited by distributions in moving from /var/spool/mail to /var/mail. Linux distributions work very hard to do in-place upgrades of systems. Moving the mail spool, which is often a remote partition, or (unfortunately) an NFS mount, is not a trivial task. As I said, I'm open to requiring a /var/mail symbolic link (now or at any time in the future). FHS 2.1 is the same as FSSTND 1.2 for the mail spool specification. FHS 2.0 can be ignored -- because it was (due to these two issues). Argh. We've been through this *so* many times..... Let's go back to basics. The whole point of the FSSTND or the FHS, is to make it easy for applications to be portable across different distributions and/or operating systems. A compile-time paths.h helps for portability across operating systems, but it doesn't help for binaries compiled on one system and used on other systems, so arguably paths.h is not a complete solution. So, what we need to guarantee is that applications can use /var/mail to access the mail spool. ***Where*** the mail spool really doesn't matter! I can assure you that if I'm running a large pop server with several thousand POP or IMAP servers, I won't be storing the mail on the /var partition. Instead, /var/mail will be a symlink to /u2/mail, and all of the mail will be on a separate 18 gigabyte disk. So telling distributions that they were somehow obligated to make their upgrade procedures move the location of their mail spools was simply stupid, and I've said this before. All we need to do is state that applications must be guaranteed to be able to find the mail spool by lookin in /var/mail. Whether this is done by actually storing the mail directory in /var/mail, or simply making /var/mail a symlink to another distribution should be a local matter. - Ted From list-relay@mlist.ucsd.edu Thu May 27 20:54:23 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id UAA12999 for ; Thu, 27 May 1999 20:54:23 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id UAA28182 for ; Thu, 27 May 1999 20:54:22 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id UAA14496 for ; Thu, 27 May 1999 20:54:20 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id UAA03854; Thu, 27 May 1999 20:26:24 -0700 (PDT) Received: from gndrsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.4]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id TAA04703 for ; Thu, 27 May 1999 19:17:18 -0700 (PDT) Received: (from rgrimes@localhost) by gndrsh.aac.dev.com (8.9.3/8.9.3) id TAA24656; Thu, 27 May 1999 19:17:04 -0700 (PDT) (envelope-from rgrimes) From: "Rodney W. Grimes" Message-Id: <199905280217.TAA24656@gndrsh.aac.dev.com> Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905272358.QAA18437@sodium.transmeta.com> from Daniel Quinlan at "May 27, 1999 04:58:08 pm" To: quinlan@transmeta.com Date: Thu, 27 May 1999 19:17:01 -0700 (PDT) Cc: niemi@tux.org (David C Niemi), fhs-discuss@ucsd.edu X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:775 Status: RO Content-Length: 1542 Lines: 33 > Rodney W Grimes writes: > > > The 4 largest distributors seems to have out weighed all the input and > > discussion that went on 2 years ago when the /var/mail decision was made. > > You have walfed on _ALL_ of the BSD derived os's :-(. > > Yes, but BSD bailed out on us 2 years ago (and several times since > then). You only get to bail once. I was state the more correct assertion that the FHS bailed on BSD, basically a large group of us came in here _BY YOUR REQUEST_ and put a lot of hard work and effort into explaining why things where the way they where, made comprimises and agreed on certail things only to have the FHS accept these changes, move on, then some X months later start one by one wafling on them. You basically ran us off by exahastion as Kirk put it. Well, if you check the subscription list, I've been on the list since that time. And now I just see no reason to even read this thing anymore, you finally exausted the last *BSD person I know of on the list :-(> Ohhh.... and about making changes that are not trivial for ``distributors to support''... well... if standards creation took this into consideration on all issues you would never change a damn thing. IMHO this standard is for them to adhere to, and for the software writters to say how it should be done. But then, thats my bias :-) -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.com From list-relay@mlist.ucsd.edu Thu May 27 20:54:43 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id UAA13005 for ; Thu, 27 May 1999 20:54:43 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id UAA28186 for ; Thu, 27 May 1999 20:54:42 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id UAA14501 for ; Thu, 27 May 1999 20:54:41 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id UAA03966; Thu, 27 May 1999 20:30:21 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id UAA10808 for ; Thu, 27 May 1999 20:30:18 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id UAA27995; Thu, 27 May 1999 20:30:16 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id UAA12476; Thu, 27 May 1999 20:30:15 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id UAA20208; Thu, 27 May 1999 20:30:14 -0700 Date: Thu, 27 May 1999 20:30:14 -0700 Message-Id: <199905280330.UAA20208@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Theodore Y. Ts'o" Cc: quinlan@transmeta.com, "Rodney W. Grimes" , niemi@tux.org, fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905280259.WAA17330@dcl.MIT.EDU> References: <199905272358.QAA18437@sodium.transmeta.com> <199905280259.WAA17330@dcl.MIT.EDU> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:776 Status: RO Content-Length: 1687 Lines: 42 Theodore Y Ts'o writes: > So, what we need to guarantee is that applications can use /var/mail to > access the mail spool. ***Where*** the mail spool really doesn't > matter! I can assure you that if I'm running a large pop server with > several thousand POP or IMAP servers, I won't be storing the mail on the > /var partition. Instead, /var/mail will be a symlink to /u2/mail, and > all of the mail will be on a separate 18 gigabyte disk. *sigh* Your tack is about the same the consensus that fell out of the protracted LSB discussion about this. I know the distributions are happy with /var/spool/mail as in the current pre-draft. I can try to drive the LSB consensus with the distributions. There isn't much point in discussing it here before then. Part of my planned rewrite is to make clear the distinction between where files are "referenced" and "located". We don't care about any more than where programs look for files upwards of 90% of the time. Drafted the other way (short of a complete rewrite), it would be: ------- start of cut text -------------- /var/mail : User mailbox files This hierarchy is where applications should search for user mailbox files stored in the standard Unix mailbox format. This may be a symbolic link to another physical location. BEGIN RATIONALE For Linux, this directory was relocated from /var/spool/mail in order to bring FHS in-line with nearly every other Unix implementation. This change is important for inter-operability. On upgraded Linux systems, this will often be a symbolic link to /var/spool/mail, the previous location of the hierarchy. END RATIONALE ------- end ---------------------------- From list-relay@mlist.ucsd.edu Thu May 27 21:12:21 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA13348 for ; Thu, 27 May 1999 21:12:21 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA28351 for ; Thu, 27 May 1999 21:12:20 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id VAA14652 for ; Thu, 27 May 1999 21:12:18 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id UAA04710; Thu, 27 May 1999 20:50:42 -0700 (PDT) Received: from dcl.MIT.EDU (DCL.MIT.EDU [18.172.1.4]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id UAA12478 for ; Thu, 27 May 1999 20:50:41 -0700 (PDT) Received: by dcl.MIT.EDU with sendmail-8.8.8+Sun/1.2, id XAA17370; Thu, 27 May 1999 23:50:39 -0400 (EDT) Date: Thu, 27 May 1999 23:50:39 -0400 (EDT) Message-Id: <199905280350.XAA17370@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: quinlan@transmeta.com CC: "Theodore Y. Ts'o" , quinlan@transmeta.com, "Rodney W. Grimes" , niemi@tux.org, fhs-discuss@ucsd.edu In-reply-to: Daniel Quinlan's message of Thu, 27 May 1999 20:30:14 -0700, <199905280330.UAA20208@sodium.transmeta.com> Subject: Re: FHS pre-2.1 draft #1 on web site Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:777 Status: RO Content-Length: 1269 Lines: 26 Date: Thu, 27 May 1999 20:30:14 -0700 From: Daniel Quinlan Your tack is about the same the consensus that fell out of the protracted LSB discussion about this. I know the distributions are happy with /var/spool/mail as in the current pre-draft. I can try to drive the LSB consensus with the distributions. There isn't much point in discussing it here before then. So the *real* problem is that the distributions didn't understand the document, or at least the consensus that lead to the decision we came to. That's clear since all of the complaints that you've brought to the table from them focused on the impossibility of moving the location of the mail spool, as opposed to the bother of installing a symlink and changing applications to look in a different directory. Part of my planned rewrite is to make clear the distinction between where files are "referenced" and "located". We don't care about any more than where programs look for files upwards of 90% of the time. I think that rewrite is going to be critically important; a standard is useless if people don't understand what they really need to do to be in compliance with it, and reject it based on their misunderstanding of it. - Ted From list-relay@mlist.ucsd.edu Thu May 27 21:12:33 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA13367 for ; Thu, 27 May 1999 21:12:33 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA28359 for ; Thu, 27 May 1999 21:12:32 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id VAA14661 for ; Thu, 27 May 1999 21:12:31 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id UAA04659; Thu, 27 May 1999 20:48:47 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id UAA28885 for ; Thu, 27 May 1999 20:48:47 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id UAA28143; Thu, 27 May 1999 20:48:45 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id UAA12878; Thu, 27 May 1999 20:48:44 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id UAA20326; Thu, 27 May 1999 20:48:43 -0700 Date: Thu, 27 May 1999 20:48:43 -0700 Message-Id: <199905280348.UAA20326@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Theodore Y. Ts'o" Cc: quinlan@transmeta.com, "Rodney W. Grimes" , niemi@tux.org, fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905280259.WAA17330@dcl.MIT.EDU> References: <199905272358.QAA18437@sodium.transmeta.com> <199905280259.WAA17330@dcl.MIT.EDU> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:778 Status: RO Content-Length: 829 Lines: 21 This is hpa's wording (modified slightly) from the rough consensus on the LSB list. > The mail spool MUST be accessible through /var/mail AND /var/spool/mail, > and spool files MUST take the form . Either /var/mail or > /var/spool/mail, or both, MAY be symbolic links to another directory. > It is RECOMMENDED that /var/mail be the actual directory and > /var/spool/mail be the symbolic link. At some point use of > /var/spool/mail may become deprecated. And (more or less) my current pre-draft (not up on the web site yet). > The mail spool MUST be accessible through /var/mail and spool files MUST > take the form . /var/mail MAY be a symbolic links to another > directory. If either of those can be sold to the major distributions (I'd settle for either!), would everyone here buy into that? - Dan From list-relay@mlist.ucsd.edu Thu May 27 21:14:55 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA13443 for ; Thu, 27 May 1999 21:14:55 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA28372 for ; Thu, 27 May 1999 21:14:54 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id VAA14677 for ; Thu, 27 May 1999 21:14:52 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id UAA04769; Thu, 27 May 1999 20:56:22 -0700 (PDT) Received: from dcl.MIT.EDU (DCL.MIT.EDU [18.172.1.4]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id UAA29546 for ; Thu, 27 May 1999 20:56:21 -0700 (PDT) Received: by dcl.MIT.EDU with sendmail-8.8.8+Sun/1.2, id XAA17375; Thu, 27 May 1999 23:56:18 -0400 (EDT) Date: Thu, 27 May 1999 23:56:18 -0400 (EDT) Message-Id: <199905280356.XAA17375@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Rodney W. Grimes" CC: quinlan@transmeta.com, niemi@tux.org, fhs-discuss@ucsd.edu In-reply-to: Rodney W. Grimes's message of Thu, 27 May 1999 19:17:01 -0700 (PDT), <199905280217.TAA24656@gndrsh.aac.dev.com> Subject: Re: FHS pre-2.1 draft #1 on web site Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:779 Status: RO Content-Length: 1531 Lines: 31 From: "Rodney W. Grimes" Date: Thu, 27 May 1999 19:17:01 -0700 (PDT) I was state the more correct assertion that the FHS bailed on BSD, basically a large group of us came in here _BY YOUR REQUEST_ and put a lot of hard work and effort into explaining why things where the way they where, made comprimises and agreed on certail things only to have the FHS accept these changes, move on, then some X months later start one by one wafling on them. You basically ran us off by exahastion as Kirk put it. I hate to say it, but Rodney's right. I can easily see how they might accuse us of negotiating in bad faith. It's really, really, bad when you negotiate and compromise to reach a mutally agreeable position, only to have someone reopen the argument and demand further compromises, using the original compromised position as the starting point for demanding further concesssions..... I don't think this was done intentionally, but we on this list seem to have an ***extremely*** bad track record of reopening past decisions. /var/mail is only the most recent example of this. Often times it done by someone relatively clueless who hauls out some tired old argument all over again, and people aren't always willing enough to simply say "this has been decided already; we're not going to reopen the discussion". This is not always bad; sometimes situations change and we do need to revisit past decisions. But I think we often try to do this far too often. - Ted From list-relay@mlist.ucsd.edu Thu May 27 21:59:04 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA14055 for ; Thu, 27 May 1999 21:59:03 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA28790 for ; Thu, 27 May 1999 21:59:03 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id VAA15077 for ; Thu, 27 May 1999 21:59:01 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id VAA05390; Thu, 27 May 1999 21:24:25 -0700 (PDT) Received: from dcl.MIT.EDU (DCL.MIT.EDU [18.172.1.4]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id VAA15156 for ; Thu, 27 May 1999 21:24:24 -0700 (PDT) Received: by dcl.MIT.EDU with sendmail-8.8.8+Sun/1.2, id AAA17423; Fri, 28 May 1999 00:24:22 -0400 (EDT) Date: Fri, 28 May 1999 00:24:22 -0400 (EDT) Message-Id: <199905280424.AAA17423@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: quinlan@transmeta.com CC: "Theodore Y. Ts'o" , quinlan@transmeta.com, "Rodney W. Grimes" , niemi@tux.org, fhs-discuss@ucsd.edu In-reply-to: Daniel Quinlan's message of Thu, 27 May 1999 20:48:43 -0700, <199905280348.UAA20326@sodium.transmeta.com> Subject: Re: FHS pre-2.1 draft #1 on web site Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Xref: sodium.transmeta.com linux.fhs:780 Status: RO Content-Length: 541 Lines: 15 Date: Thu, 27 May 1999 20:48:43 -0700 From: Daniel Quinlan > The mail spool MUST be accessible through /var/mail and spool files MUST > take the form . /var/mail MAY be a symbolic links to another > directory. If either of those can be sold to the major distributions (I'd settle for either!), would everyone here buy into that? I certainly would. I prefer the one quoted above over hpa's wording, simply because the one quoted above is less verbose and to the point. - Ted From list-relay@mlist.ucsd.edu Thu May 27 22:09:27 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id WAA14394 for ; Thu, 27 May 1999 22:09:27 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id WAA28893 for ; Thu, 27 May 1999 22:09:26 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id WAA15175 for ; Thu, 27 May 1999 22:09:25 -0700 Received: from mailbox1.ucsd.edu (mailbox1.ucsd.edu [132.239.1.53]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id VAA05351; Thu, 27 May 1999 21:22:01 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox1.ucsd.edu (8.9.1a/8.9.1) with ESMTP id VAA14960 for ; Thu, 27 May 1999 21:21:59 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id VAA28429; Thu, 27 May 1999 21:21:57 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id VAA13512; Thu, 27 May 1999 21:21:56 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id VAA20445; Thu, 27 May 1999 21:21:55 -0700 Date: Thu, 27 May 1999 21:21:55 -0700 Message-Id: <199905280421.VAA20445@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Theodore Y. Ts'o" Cc: quinlan@transmeta.com, "Rodney W. Grimes" , niemi@tux.org, fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905280350.XAA17370@dcl.MIT.EDU> References: <199905280330.UAA20208@sodium.transmeta.com> <199905280350.XAA17370@dcl.MIT.EDU> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:781 Status: RO Content-Length: 2379 Lines: 51 Theodore Y Ts'o writes: > So the *real* problem is that the distributions didn't understand the > document, or at least the consensus that lead to the decision we came > to. That's clear since all of the complaints that you've brought to the > table from them focused on the impossibility of moving the location of > the mail spool, as opposed to the bother of installing a symlink and > changing applications to look in a different directory. Mmm... everything you said is true. Someone noted that they didn't want to modify every mail application (there are many) in their distribution (I think it was someone from Red Hat, but don't hold me to that). hpa's wording would avoid that problem. and in another message: > I don't think this was done intentionally, but we on this list seem > to have an ***extremely*** bad track record of reopening past > decisions. /var/mail is only the most recent example of this. > Often times it done by someone relatively clueless who hauls out > some tired old argument all over again, and people aren't always > willing enough to simply say "this has been decided already; we're > not going to reopen the discussion". I don't think the track record is that bad (with the exception of /var/mail). There have been other protracted debates and issues that come up again and again, but they all settled down after a decision was made. For example, /opt used to be the "discussion that wouldn't die". We finally hashed out a proposal and after the proposal didn't need changing for some months, it went into the standard. Sometimes, it is a directory people want to add. New people can propose that type of change many times, until you make the change. The /conf stuff is a good example. It took a while to end the discussion, but it's dead now. > This is not always bad; sometimes situations change and we do need to > revisit past decisions. But I think we often try to do this far too > often. Hmmm... as it was drafted in FHS 2.0, /var/mail needs to be revisited. Whether we adopt hpa's compromise, my full retraction, or keep it and make sure *everyone* understands, it needed to be revisited and settled. Why? As it was, the distributions that were (mostly) interested in FHS 2.0, were poised to throw out chunks like /var/mail and /var/state and make their own way -- that would be much worse. - Dan From list-relay@mlist.ucsd.edu Sat May 29 13:42:30 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id NAA23760 for ; Sat, 29 May 1999 13:42:29 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id NAA17333 for ; Sat, 29 May 1999 13:42:29 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id NAA03571 for ; Sat, 29 May 1999 13:42:28 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id NAA20105; Sat, 29 May 1999 13:21:36 -0700 (PDT) Received: from zeus.wi.leidenuniv.nl (zeus.wi.leidenuniv.nl [132.229.128.1]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id MAA18252 for ; Sat, 29 May 1999 12:49:09 -0700 (PDT) Received: from lightning.mors.net (root@home047.wi.leidenuniv.nl [132.229.210.175]) by zeus.wi.leidenuniv.nl (8.8.8/8.8.8/WI) with ESMTP id VAA10328 for ; Sat, 29 May 1999 21:49:03 +0200 (MET DST) Received: (from wichert@localhost) by lightning.mors.net (8.9.3/8.9.3/Debian/GNU) id VAA30434 for fhs-discuss@ucsd.edu; Sat, 29 May 1999 21:09:27 +0200 Date: Sat, 29 May 1999 21:09:27 +0200 From: Wichert Akkerman To: fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site Message-ID: <19990529210927.F28334@mors.net> Mail-Followup-To: fhs-discuss@ucsd.edu References: <199905280217.TAA24656@gndrsh.aac.dev.com> <199905280356.XAA17375@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=WK3l2KTTmXPVedZ6; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.4i In-Reply-To: <199905280356.XAA17375@dcl.MIT.EDU>; from Theodore Y. Ts'o on Thu, May 27, 1999 at 11:56:18PM -0400 Xref: sodium.transmeta.com linux.fhs:784 Status: RO Content-Length: 1298 Lines: 40 --WK3l2KTTmXPVedZ6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Previously Theodore Y. Ts'o wrote: > It's really, really, bad when you negotiate and compromise to reach a > mutally agreeable position, only to have someone reopen the argument > and demand further compromises, using the original compromised > position as the starting point for demanding further concesssions..... Perhaps someone should keep a list of all items that were discussed, the outcome of the discussion and a summary of the arguments? Wichert. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D This combination of bytes forms a message written to you by Wichert Akkerma= n. E-Mail: wichert@cs.leidenuniv.nl WWW: http://www.wi.leidenuniv.nl/~wichert/ --WK3l2KTTmXPVedZ6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQB1AwUBN1A7Z6jZR/ntlUftAQHzEQL+PVme4eNoSlMJqQxYpubV3oeuQfteKV/j p2XscAz9suX3OFhGLDUegGmKB4hljiGzcdnolyNECzCFYWkjAjnapM0ZfAh1Q/bT lqzoY7qp/05ppuSy5dui3+IFzvk9lZ0P =JIbe -----END PGP SIGNATURE----- --WK3l2KTTmXPVedZ6-- From list-relay@mlist.ucsd.edu Sat May 29 15:23:14 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id PAA24688 for ; Sat, 29 May 1999 15:23:14 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id PAA17914 for ; Sat, 29 May 1999 15:23:13 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id PAA04212 for ; Sat, 29 May 1999 15:23:12 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id OAA21247; Sat, 29 May 1999 14:52:50 -0700 (PDT) Received: from talamasca.wkpowerlink.com (talamasca.wkpowerlink.com [209.52.243.211]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id OAA24296 for ; Sat, 29 May 1999 14:52:49 -0700 (PDT) Received: from khar-pern.talamasca (ts1-38.kamloops.wkpowerlink.com [207.194.192.38]) by talamasca.wkpowerlink.com (8.8.7/8.8.7) with ESMTP id OAA19415 for ; Sat, 29 May 1999 14:55:22 -0700 Received: from michael by khar-pern.talamasca with local (Exim 2.12 #1) id 10nqpq-0002bi-00 for fhs-discuss@ucsd.edu; Sat, 29 May 1999 14:40:07 -0700 Date: Sat, 29 May 1999 14:40:06 -0700 (PDT) From: Michael Deutschmann To: fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905280356.XAA17375@dcl.MIT.EDU> Message-ID: <%cijT3MlHN@khar-pern.talamasca> X-User-Agent: Mana 4.0beta (Linux) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:785 Status: RO Content-Length: 944 Lines: 18 > I don't think this was done intentionally, but we on this list seem to > have an ***extremely*** bad track record of reopening past decisions. > /var/mail is only the most recent example of this. Often times it done > by someone relatively clueless who hauls out some tired old argument all > over again, and people aren't always willing enough to simply say "this > has been decided already; we're not going to reopen the discussion". Actually the problem may be a simple lack of memory. If we had a solid record of things that have been decided, it might be better. As it is we don't seem to even have a list archive. You have to consider that to people who weren't involved in the original fight, a `brilliant compromise' just looks like brain damage. When a new FHS is published with such a decision, some people originally off list may join up to `put things right'. ---- Michael Deutschmann From list-relay@mlist.ucsd.edu Sat May 29 18:54:21 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id SAA26442 for ; Sat, 29 May 1999 18:54:21 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id SAA19206 for ; Sat, 29 May 1999 18:54:20 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id SAA05566 for ; Sat, 29 May 1999 18:54:19 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id SAA24149; Sat, 29 May 1999 18:29:09 -0700 (PDT) Received: from neon.transmeta.com (neon-best.transmeta.com [206.184.214.10]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id SAA03527 for ; Sat, 29 May 1999 18:29:08 -0700 (PDT) Received: from deepthought.transmeta.com (mailhost.transmeta.com [10.1.1.15]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id SAA19039; Sat, 29 May 1999 18:28:58 -0700 Received: from sodium.transmeta.com (root@sodium.transmeta.com [10.1.27.55]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id SAA26225; Sat, 29 May 1999 18:28:58 -0700 (PDT) Received: (from quinlan@localhost) by sodium.transmeta.com (8.8.4/8.7.3) id SAA32130; Sat, 29 May 1999 18:28:57 -0700 Date: Sat, 29 May 1999 18:28:57 -0700 Message-Id: <199905300128.SAA32130@sodium.transmeta.com> From: Daniel Quinlan MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Michael Deutschmann Cc: fhs-discuss@UCSD.EDU Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <%cijT3MlHN@khar-pern.talamasca> References: <199905280356.XAA17375@dcl.MIT.EDU> <%cijT3MlHN@khar-pern.talamasca> X-Mailer: VM 6.27 under Emacs 19.34.1 Reply-To: quinlan@transmeta.com Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Xref: sodium.transmeta.com linux.fhs:787 Status: RO Content-Length: 962 Lines: 24 Michael Deutschmann writes: > Actually the problem may be a simple lack of memory. If we had a > solid record of things that have been decided, it might be better. > As it is we don't seem to even have a list archive. A list archive is not a problem. I'll get one set up. > You have to consider that to people who weren't involved in the > original fight, a `brilliant compromise' just looks like brain > damage. When a new FHS is published with such a decision, some > people originally off list may join up to `put things right'. Umm... no new version of the FHS has been published. It's a draft and subject to modification. That's why it's called a draft. A new draft will be out today or tomorrow. I'm going to put in the reworked specification for /var/mail. As yet, nobody seems too upset about switching back to /var/lib (while retaining the /var/state specification), so I'll leave that in for now. - Dan From list-relay@mlist.ucsd.edu Mon May 31 00:51:14 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id AAA09942 for ; Mon, 31 May 1999 00:51:13 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id AAA31258 for ; Mon, 31 May 1999 00:51:12 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id AAA18225 for ; Mon, 31 May 1999 00:51:10 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id AAA19705; Mon, 31 May 1999 00:18:22 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with ESMTP id AAA07324 for ; Mon, 31 May 1999 00:18:20 -0700 (PDT) Received: from droopy.imag.fr (droopy.imag.fr [147.171.150.40]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id JAA20545 for ; Mon, 31 May 1999 09:18:21 +0200 (MET DST) Received: from localhost (ykieffer@localhost) by droopy.imag.fr (8.8.7/8.8.5) with SMTP id JAA01621 for ; Mon, 31 May 1999 09:18:17 +0200 (MET DST) Date: Mon, 31 May 1999 09:18:17 +0200 (MET DST) From: Yann Kieffer To: fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site In-Reply-To: <199905280421.VAA20445@sodium.transmeta.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Xref: sodium.transmeta.com linux.fhs:791 Status: RO Content-Length: 523 Lines: 15 On Thu, 27 May 1999, Daniel Quinlan wrote: > Sometimes, it is a directory people want to add. New people can > propose that type of change many times, until you make the change. > The /conf stuff is a good example. It took a while to end the > discussion, but it's dead now. The discussion sure was dead, because it drifted onto a registry-stuff discussion. But I don't really think every side of the problem has been explored, and a good way to state things and calm down spirits (at least mine) has been found. Yann From list-relay@mlist.ucsd.edu Mon May 31 10:05:30 1999 Return-Path: Received: from neon.transmeta.com (neon.transmeta.com [10.1.1.10]) by deepthought.transmeta.com (8.8.8+spamcan/8.8.5) with ESMTP id KAA14235 for ; Mon, 31 May 1999 10:05:30 -0700 (PDT) Received: from neosilicon.transmeta.com (IDENT:root@neosilicon.transmeta.com [206.184.214.14]) by neon.transmeta.com (8.9.1/8.9.1) with ESMTP id KAA02358 for ; Mon, 31 May 1999 10:05:29 -0700 Received: from mlist.ucsd.edu (mlist.ucsd.edu [132.239.1.48]) by neosilicon.transmeta.com (8.9.1a/8.9.1) with ESMTP id KAA22426 for ; Mon, 31 May 1999 10:05:28 -0700 Received: from mailbox2.ucsd.edu (mailbox2.ucsd.edu [132.239.1.54]) by mlist.ucsd.edu (8.9.1a/8.6.9) with ESMTP id JAA27239; Mon, 31 May 1999 09:27:03 -0700 (PDT) Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by mailbox2.ucsd.edu (8.9.1a/8.9.1) with SMTP id IAA26698 for ; Mon, 31 May 1999 08:51:18 -0700 (PDT) Received: by mailgate.rdg.opengroup.org; id AA06260; Mon, 31 May 1999 15:53:35 GMT Received: from slip139-92-25-192.wak.uk.ibm.net [139.92.25.192] by mailgate.rdg.opengroup.org via smtpd V1.32 (99/03/30 12:28:06) for ; Mon May 31 16:53 BST 1999 Received: (from ajosey@localhost) by tamarix.rdg.opengroup.org (8.8.7/8.8.7) id QAA01784 for fhs-discuss@ucsd.edu; Mon, 31 May 1999 16:51:15 +0100 Date: Mon, 31 May 1999 16:51:15 +0100 From: Andrew Josey Message-Id: <990531155112.ZM1783@tamarix.rdg.opengroup.org> In-Reply-To: Wichert Akkerman's message as of May 29, 9:09pm. References: <199905280217.TAA24656@gndrsh.aac.dev.com> <199905280356.XAA17375@dcl.MIT.EDU> <19990529210927.F28334@mors.net> Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Z-Mail (5.0.0 30July97) To: fhs-discuss@ucsd.edu Subject: Re: FHS pre-2.1 draft #1 on web site Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: sodium.transmeta.com linux.fhs:792 Status: RO Content-Length: 425 Lines: 12 On May 29, 9:09pm in "Re: FHS pre-2.1 draf", Wichert Akkerman wrote: > Perhaps someone should keep a list of all items that were discussed, > the outcome of the discussion and a summary of the arguments? > A good idea. The way we are operating the POSIX/UNIX spec revision is to maintain two documents, an issues list and a consent list. We have procedures for requesting items get moved between the two... regards Andrew