From owner-freebsd-current Tue Oct 24 12:16:16 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id DFDEF37B4C5 for ; Tue, 24 Oct 2000 12:16:07 -0700 (PDT) Received: (qmail 5799 invoked by uid 0); 24 Oct 2000 19:16:06 -0000 Received: from p3ee20aa3.dip.t-dialin.net (HELO speedy.gsinet) (62.226.10.163) by mail.gmx.net with SMTP; 24 Oct 2000 19:16:06 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id UAA17044 for freebsd-current@FreeBSD.ORG; Tue, 24 Oct 2000 20:24:58 +0200 Date: Tue, 24 Oct 2000 20:24:58 +0200 From: Gerhard Sittig To: freebsd-current@FreeBSD.ORG Subject: Re: new rc.network6 and rc.firewall6 Message-ID: <20001024202458.K25237@speedy.gsinet> Mail-Followup-To: freebsd-current@FreeBSD.ORG References: <200010240903.CAA13916@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from danfe@inet.ssc.nsu.ru on Tue, Oct 24, 2000 at 04:14:36PM +0700 Organization: System Defenestrators Inc. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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