Re: Proposal: A config file for runlevels (DRAFT)
On Thu, 2 Jan 1997, Lars Wirzenius wrote:
> This is a simple risk analysis.
Try a risk comparism instead: how much more risk does the new scheme
introduce? Answer: there is a marginally higher risk. Because the
information was collected from 6 files into one (I view the
rc.d-directories as files because they only contain links). But that isn't
worth mentioning.
Every other risk of the new config-file has it's equivalent in the tools
to manipulate the directories (which I view as files because
they only contain names of links). An unexpirienced maintainer and the
"rm -f /etc/init.d/S20*" corrupts your system. Without a chance for easy
recovery. <ironic> Oh, how risky this is. </ironic>.
Maybe he messes around with the new file manually and deletes a bunch of
entries - but he does not _more_ harm than he would do to the links. Even
better, there is a fallback copy of the new config file available - try
that with a bunch of several hundred links (you can use "tar" but i't not
very handy if it comes to compare the old setup with a new one).
There is even a syntax coded into the link-names:
S99xdm
corresponds to
99 0,1,6 2,3,4,5 xdm
So _both_ methods have a syntax which is susceptible for errors. And as I
said earlier the more complicated syntax may be more prone for errors
because it's not understood that well.
_What_ is riskier is the fact that my "rc" is brandnew and "untested".
On the other hand, it's a fairly simple implementation (lowers the
likeliness of bugs). But hey, even the Linux kernel (= most important
piece) has bugs and people don't mind testing it.
> That doesn't mean we shouldn't work on making it easier to edit
> runlevel information. We should. But the tool should change
> the links, not modify a text file.
You only move the problem around by using a tool to modify the links.
What about errors in such a program? It is as risky as a tool to edit a
"textfile".
> BTW, do you already have a working tool, or should I take a
> look at Red Hat? InfoMagic kindly sent me their 6-disk package
> again, and I've been meaning to look at RH anyway.
No, I didn't look at RedHat. Because they hide everything behind a GUI
which is quite useless if you are logged in remotely.
And personally I prefer to re-structure a system to make it easier
_before_ thinking about a GUI. This way the GUI becomes much more
transparent (read: the things are so easy you could also do them by hand)
and you don't need the "learning" mode which is a quite popular
suggestions for admintools (in learning mode the GUI prints every command
it executes so the sysadmin can learn how to do it himself).
In contrast, I was already flamed because one of my shell-scripts looked
like one from RedHat: "a real pain to maintain manually".
I'm really concerned about the RedHat-hype I see in Debian-devel. In my
opinion the strength of Debian was it's independence from current trends
(think of 0.93R6 being "a.out"). Debian still exists, though.
Instead, Debian was always a forum for new ideas - RedHat can "steal" the
ideas, but not the forum. If we drop the forum, we can only run behind the
standards RedHat dictates.
-Winfried
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: