Book recommendation

[Tim]

Tim:
>> Webmin, and things like it, need maintaining as rapidly as everything
>> that it can control.  If one of them develops differently, webmin will
>> still be trying to configure it the old way.
>> 
>> That was one of the serious drawbacks with with Linuxconf.  After a
>> while, it was configuring things wrong.

Craig White:
> seems to be a rather unfair comparison of both breadth and frequency of
> maintenance. I never saw linuxconf in an unbroken state.

The comment about webmin is just "in principle."  It's made from a
rather obvious point of view that such utilities can only be designed to
configure other things based on what's known about them.  Those other
things will change over time, necessitating a change in the controlling
program *after* the fact.

But LinuxConf *was* *widely* recognised for *stuffing things up*,
leading to it being dropped from Red Hat Linux releases, at least.

> For what it is...it's really a great product. What it isn't is a
> substitute for understanding how to maintain your daemons yourself.

That's another big part of the issue:  Instead of learning to control
what you're trying to control, you're learning to adjust some other
program.  Apart from going about it in a roundabout manner, such
third-party controls are often rather limited in functionality, compared
to what you can do by directly writing the configuration files,
yourself.

I've certainly seen that sort of thing for third-party tools that allow
one to configure Samba or Apache (not being able to do everything that
you might want to).

-- 
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.