Date: Sat, 6 Feb 1999 01:16:17 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: archie@whistle.com (Archie Cobbs) Cc: dcs@newsguy.com, tlambert@primenet.com, dhw@whistle.com, freebsd-hackers@FreeBSD.ORG Subject: Re: more modular rc/init/uninit system... Message-ID: <199902060116.SAA22700@usr02.primenet.com> In-Reply-To: <199902050308.TAA31969@bubba.whistle.com> from "Archie Cobbs" at Feb 4, 99 07:08:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 1) Links? That's awful. Configuration information should be put in a > > > > FILE. > > > > > > Uh, we await your diffs to phkmalloc. Be sure to run them by Poul > > > so he can reject them. 8-). > > > > I claim that's different, though not so confidently. The problem > > with the "links" above is that the configuration information is the > > *directory*, not the link by itself (as I have the vague impression > > is the case you mention). > > The main reason a symlink is used is for speed, since almost > every substantial program calls malloc(). > > Symlinks are much faster to read than opening a file and reading > its contents. Note that I was referring explicitly to his blanket statement. The use of links in the rc.d case is to multiply services into different run levels (should be states). The use of the symlink in the phkmalloc case is an abuse of links to implement what are, effectively, "immediate files". Note that I condone this abuse, since something that lets you do bad things also lets you do clever things (like this). In the rc.d case, the complaint is general raised to fend off an increase in complexity. The people who want to increase the complexity want to do so so they can do clever things. The people who want to keep the status quo are the people who don't want to do those things, and so the change looks like change for change's sake. That's their perspective, and you have to respect that until you can wear them down. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902060116.SAA22700>