Date: Sun, 23 Jun 1996 23:22:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mrm@MARMOT.Mole.ORG (M.R.Murphy) Cc: alk@Think.COM, terry@lambert.org, hackers@freefall.freebsd.org, phk@FreeBSD.org Subject: Re: cvs commit: src/etc/mtree BSD.usr.dist Message-ID: <199606240622.XAA27174@phaeton.artisoft.com> In-Reply-To: <199606231559.IAA06629@meerkat.mole.org> from "M.R.Murphy" at Jun 23, 96 08:59:09 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I'd go further; /bin/sh is evil, as are any other scripting systems > > where it's possible to have the data embedded in the script instead > > of operated on by a tool. The only reason I don't call for its > > removal is that the installation and the system startup (incorrectly) > > depend on it, and /bin/csh is more evil. As the default system shell, > > it has to be there, but that makes it no less annoying. Look at > > the /etc/rc* mess that /bin/sh has gotten us into because it was > > more convenient than Doing Things The Right Way. 8-(. > > Not using scripting languages makes the system behave exactly as the > developers intended and makes it more difficult for consumers to modify > the system to meet their own needs. If that's the goal, go for it. Actually, making it easy to change the intent is the goal... both for the developers, AND for the end users. I'm not suggesting duct taping over the switches that we don't want user flipping, I'm suggesting that the switch panel should be seperated from that machine it is controlling. (Now that we are firmly in downtown analogyville 8-)). > System startup does not incorrectly depend upon a scripted shell. It > is _designed_ to used a scripted shell. It's not just an accident > or matter of expediency. That it is /bin/sh is immaterial. I'll agree > that /bin/csh is inappropriate, but a working /bin/sh or Plan 9 rc > is just fine. It's the one place you can justify it. It's harder to justify with an rc.local file if both the developer and the end user is allowed to change the file contents. If the developer, you want to stomp on it when you upgrade. If the end user, you want to leave it alone (and thus prevent further changes by the developer). There needs to be some kind of implied locking. The easiest method would be to go to rc.d style seperated startup, to let you drop in and out tasks for startup from a defined startup order. Barring that, the next easiest would be to seperate the data that the rc file uses to determine its behaviour from the rc file (and /etc/sysconfig is born). The problem is that users can go in and modify this thing to localize behaviour or to add local behaviour (which they have to do to replace system components based on function, because we don't do the rc.d thing). Then when you go to upgrade, the upgrade complexity increases into unmanageability. Can we agree with the statement: o Be it resolved that future work will be done on FreeBSD, such that upgrades are designated as expected events, and thus we should not engage in behaviours which screw the ability to upgrade. ? > Implementation of policy for seldom invoked activity > in editable script is a Fine Thing Indeed. > > > Is /etc/rc kludged a wee tad? Sure. If I feel like replacing it with > a System V like init.d driven startup, that's my choice. So is installing > a System V like init and inittab. > > "Doing Things The Right Way" is, of course, a matter of perspective. 8-). Or one of not substituting activity for action? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606240622.XAA27174>