Date: Tue, 24 Oct 2000 20:24:58 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-current@FreeBSD.ORG Subject: Re: new rc.network6 and rc.firewall6 Message-ID: <20001024202458.K25237@speedy.gsinet> In-Reply-To: <Pine.LNX.4.10.10010241612080.32319-100000@inet.ssc.nsu.ru>; from danfe@inet.ssc.nsu.ru on Tue, Oct 24, 2000 at 04:14:36PM %2B0700 References: <200010240903.CAA13916@usr01.primenet.com> <Pine.LNX.4.10.10010241612080.32319-100000@inet.ssc.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 24, 2000 at 16:14 +0700, Alexey Dokuchaev wrote:
> On Tue, 24 Oct 2000, Terry Lambert wrote:
>
> > > Well, would not be this stepping aside from BSD startup
> > > sequence, which we all know and love? Having dozens of
> > > small files instead of pair of big ones always frustrates
> > > me when I have to work with linux.
> >
> > Install a binary package that needs to be started when the
> > system is booted and needs to be shutdown when the system is
> > shutdown.
>
> That's what /usr/local/etc/rc.d/ was for for years! Put all
> your application-specific scripts there, but leave base-system
> monotilithic startup alone :-)
What if I don't employ bind but use something else (djbdns or
homebrew software) instead? Where do I put those in into the
startup sequence? When /usr/local/etc/rc.d/*.sh are run it could
be too late since on the way there a few services died due to DNS
errors.
What about other "essential" services like foreign file systems
("unnatural" things like coda?) or mail transfer agents likely to
be used / needed before other things happen but not available in
the base? What if I want to load some UPS daemon quite early?
How do I implement hardcoded ARP tables short after NIC setup and
right before services' startup? What about other hacks one had
to introduce into /etc/rc*? Think of the ipf "workaround" in PR
20202. It could have been as easy as adding one more file or
replacing the ipfw counterpart. At the moment it is about having
someone stuff the code into some other environment. Without easy
moving around in case it's wrongly placed (think of 30 lines
deleted and 30 lines added - without the chance to easily see if
they're still the same and just have moved - against one line
deleted and one line added - more obviously documenting a moved
invocation).
Plugging (dropping) in just another script and have it register
its sequence number somewhere (or replacing an existing one) is
always easier than modifying a huge pile of code.
And think about undoing those additions (insertions) upon
removal: deleting a single file is really trivial compared to
identifying and removing a chunk in a big file. And changing
your mind about what to do and how to do it for a certain service
won't interfere with all the other stuff.
I don't like thinking back of the situation, where I had to start
a (usually not running) NFS server and a NFS client for remote
installworlds. Eyeballing nested rc scripts, comparing them
against the rc.conf settings and typing all those by hand and not
missing something is really not what you want to have when you
actually have other worries to take care of. And then again -
how do I kill this damned special daemon in a clear way? Of
course every one of them has a way and if you're lucky it's only
five ways for seven services, but that's still too much of a
complexity for a simple human mind with its given restrictions.
Think of the run-parts layout in the cronjob directories and the
advantages are (should be) really obvious. The "clutter" with
the symlinks in Linux come from the notion of having runlevels,
BTW. For BSD (simple straight bootup, endless run and simple
straight shutdown, with a little change sometimes as new services
are needed or not needed any longer) there should either be no
links and a sequence description or just one pile of "numbered
links" besides the "basename'd, plain working" scripts.
BTW: When I wouldn't like those many single files I would
honestly think about combining all the source code into one or at
most two files. :) What are all those header files good for if
not for causing the preprocessor to parse them over and over for
no real gain after the first time? This analogy might
demonstrate best what modularity is able to gain, and that
devoting processing power for tedious routine jobs can free human
resources for other jobs at a more abstract level (i.e. closer to
solving "the real" problem instead of unnecessarily fiddling with
boring details and introducing dull new errors).
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001024202458.K25237>