Re: Goals for 1.3?
> It's simply not adequate to create static data on the fly. Who changes his
> configuration more than twice a year?
A decade or so ago someone thought exactly this way. He decided that
configuration files were not changed often, but they are parsed all of
the time. Thus he set his first priority at making them fast to parse,
and made ease of configuration a lower priority. The result was the
sendmail configuration file language. When I met that programmer years
later, he was _still_ apologizing for inflicting that disaster on us.
> If you are really concerned, we could put the default values into the
> original shell-script and source the modified file only if it exist.
> This should reduce the number of "little files" to somewhat below 20
> (organised in a hierarchy).
Well, that would help, but 20 little shell fragments is still more than
I'd like.
There's also the problem of what to do during system configuration, when
you may have a limited tool set. For example, say you have to bring up the
network before you can retrieve the rest of the system. Providing a consistent
interface to configuring many variables means that it would be easy to create
a shell-and-dialog tool that would edit them in limited space. The alternative
will be a number of tools all of which perform the same job but have built-in
knowledge about the particular variables they are setting - so say 20
shell-and-dialog programs rather than one.
Bruce
--
Bruce Perens K6BP Bruce@Pixar.com
Finger bruce@master.Debian.org for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3
--
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: