On Mon, May 20, 2002 at 03:09:04PM -0500, Jeff Licquia wrote: > On Mon, 2002-05-20 at 06:51, Michael Stone wrote: > > No, please don't, because your examples are misguided. I don't believe > > that I've heard any serious suggestion that hurd should be forced to > > have a /proc. > > Wouldn't that be a "gratuitous difference" between Linux and HURD? > (And BSD?). No. That's an architectural difference. This is a different issue than having differing policies for common components. OTOH, if hurd creates a clone of linux /proc, it should probably go in /proc--putting a resource with the same characteristics in a different location *would* be a gratuitous difference. > Arguments for /proc are exactly like arguments for /hurd, with one > difference: Linux has had political pull and historic precedent to get > its exceptions canonized; HURD, as an unreleased OS, has not. That is correct; the bar to adding things to hurd which do not comply with existing standards *should* be higher--because compatability is not an issue. That is not to say that no accomodations will be made for hurd, but it is reasonable to have a high standard for adding new items when the cost of redefining those items is low. We would likewise expect that new additions to the linux side of the house would comply with our existing standards. In the specific case of /proc, moving it would break compatability with a large installed base, as well as all other linux distributions, so there would have to be a very compelling reason to do so. In the specific case of the bsd loader, moving it would break compatability with a large installed base of other bsd installations, so there would have to be a very compelling reason to do so. In the case of /hurd there is no installed base to worry about, so moving it wouldn't really cost that much. That is not to say that it *should* be moved, but that it is *not* unreasonable to ask the question. For that matter, discussions *have* come up about moving or redefining linux /proc--such discussions are a normal, healthy part of a free software project. > So, the proper question is not whether there is a technical reason to > change the Linux-biased standard. Now you're engaging in gratuitous FUD with the very term "linux-biased standard." You don't even have the curtesy to state what standard is so allegedly biased. If your allegation of bias is directed toward fhs and is based on its inclusion of /proc in the linux section of the operating-system-specific annex, well, I'm not sure I can help you overcome your own biases. (Hint: the fact that there is a linux-specific section hardly precludes the inclusion of a hurd-specific section at such time as one is written and offered for inclusion.) > Rather, we should ask whether we will allow the HURD to develop > without artificial non-technical pressures from "legacy" systems, No. We will expect hurd to conform to some existing standards. That's part and parcel with joining an existing organization. Note that hurd already accepts pressure from "legacy" standards like POSIX. This does not preclude us from examing our standards to see what compromises or enhancements may/should be made. > and perhaps allow our definition of "what is Debian" to be altered to > accomodate the new ideas it brings. FUD. FUD. FUD. Instead of the hand-wringing, could you provide some concrete examples of cases where the Debian organization has forced hurd to abandon a technical enhancement, so we could discuss some factual material? -- Mike Stone
Attachment:
pgp4pKIliCqpf.pgp
Description: PGP signature