From owner-freebsd-ports Thu Sep 21 14:02:50 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28834 for ports-outgoing; Thu, 21 Sep 1995 14:02:50 -0700 Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA28815 ; Thu, 21 Sep 1995 14:02:41 -0700 From: patl@asimov.volant.org Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id OAA10507; Thu, 21 Sep 1995 14:01:27 -0700 Received: by asimov.volant.org (5.x/SMI-SVR4) id AA22801; Thu, 21 Sep 1995 14:06:54 -0700 Date: Thu, 21 Sep 1995 14:06:54 -0700 Message-Id: <9509212106.AA22801@asimov.volant.org> To: chuckr@eng.umd.edu, gryphon@healer.com, kelly@fsl.noaa.gov Subject: Re: ports startup scripts Cc: asami@cs.berkeley.edu, hackers@freebsd.org, julian@ref.tfs.com, ports@freebsd.org, terry@lambert.org X-Sun-Charset: US-ASCII Sender: owner-ports@freebsd.org Precedence: bulk |> Pat writes: |> > Coranth Gryphon wrote: |> > +> When are you going to start a daemon in more than one place? |> > +> Or set a global environment variable, then change it later? |> > +> |> > +> Define it as "Run Level N" includes all "Run Level 0..N-1". Simple. |> |> > If it really were that simple, why didn't SVr4 do it that way? |> |> You're asking why an OS that I think has a lousy implementation |> of run levels didn't do it right in the first place? :-) |> |> Answer: I don't know why they didn't do it right. That doesn't |> stop us from doing it right, does it? Perhaps I was being too subtle. I meant to point out that it might -NOT- be as simple as it looks at first glance. We should find out why they did it the way they did before we reject it. And we should investigate any existing variations. (Does Solaris 2.4 do it the same way as SVr4? Does HP-UX? Does...) |> > But differences just because "we aren't System V" only hurt us. We |> |> Granted. But keeping it identical just because they did like that is |> just as bad. Takes the best parts, the ideas that work. Keep anything |> that does not make a difference the same (to satisfy the "no gratuitous |> changes" camp), but be willing to change what we don't like for our sake. Right. |> > don't want people refusing to run FreeBSD because it is too different |> > from the other unixes, (without significant advantage) do we? |> |> Then keep it only BSD and stop trying to System-V-ize it. Nope, won't work. That just means that other unixes will continue to evolve away from us, and increase the degree of differences. |> > +> 8-10 unix flavors that I work with. So which one are you going |> > +> to clone? |> |> >We have two reasonable choices: |> > 1. Whichever one we feel is technically superior. |> > 2. The one with the biggest market presence (Solaris2). |> |> Neither. Build our own implementation, the way FreeBSD wants it, |> that conforms to the basic framework. Right. I was responding within the implicit assumption that we were going to clone something. I should have made it clear that cloning wasn't the only (or possibly even the best) solution. |> If I want to use Solaris, I'll use Solaris. I don't want FreeBSD |> to just become a cheap Solaris clone. Worse things could happen. But I agree - FreeBSD shouldn't become a cheap -anything- clone. On the other hand, Solaris has done a lot of things pretty well, and a lot of unix users are familiar with it. If their solutions fit our problems, and we can't come up with a significantly better solution, it is reasonable to consider copying the Solaris solution. |> > The current /usr/share/skel is a fine location. |> |> Except when you want to change default dot files. Then have |> to redo it after each install. That's a major problem with our install process. One of the nice things about the Solaris pkg_add system is that the package can have per-file actions for how to deal with files that have changed since the previous install. (The most common choices are: 1. Rename the changed version and install the new one. 2. Install the new one under a different name. 3. Just leave the old one in place. But the install script can do anything you like.) -Pat