[pri.gnhlug@iadonisi.to: Dialup with RH72]

[david at thekramers.net (David Kramer)]

On Tue, 26 Feb 2002 jkinz at ultranet.com wrote:

> At 08:54 AM 2/26/2002 -0500, Paul Iadonisi wrote:
>> Lots of good questions and smart stuff
> 
> Paul - I think your last idea - that a lot more work needs to be done is
> the problem and it isn't limited to RedHat.  Ideally, (hah!), the system would
> auto-configure itself into exactly what is needed after asking the user/installer
> a few simple questions. 


There is at least one person on the list who has thought about, as a 
commercial venture, developing a new distro that is designed to be easy to 
install and use.  To date, every "newbie" linux distro has been a horrible 
clusterf*ck that crashed and burned because it wasn't done right.  I 
believe there is a market for this if it *can* be done right with few 
enough resources so as to still make money.

>And a major part of the  problem  is  the  difficulty  of  doing  the
>required  testing.  I've written lots of my own config thingies; as a
>long-time tcl/tk hacker, this is easy. But to make a generally-useful
>config  tool, I'd need access to systems where I could do the obvious
>testing. 

This is a big problem, but if you're talking about writing something 
specifically for a particular distro, very little should affect your 
application's setup on different platforms except for device names, which 
can be derived from some common sense and knowledge of those platforms.

> How many questions, and what level of technicality would be appropriate
> to ask a "newbie" ?
> 
> Look at how well the "configure" scripts determin what needs to be done
> to build the same package on many systems.
> 
> This problem is more complex but a similar approach, packaged in a GUI
> would, after much effort, solve much of the problem.  

Here is the key to this in my eyes:  Programs like Yast, linuxconf, rpm,
and Windows installers like Wise run into problems mostly because they
depend on databases holding the current state of the software and OS
config on the box, and that database may not necessarily match reality.  
The key to the success of ./configure, and the key to success of a newbie
application or distro, is that it must look at the actual config files and
verify things as best as it can.  get rid of the database.

When ./configure wants to know if your box has "install" or "nm" or "gcc", 
it doesn't say "well, this is Red Hat 7.0 so it must be in this 
directory", it tries to find the file.  Likewise, if you're writing a 
program to make configuring Apache easier, every time it is run it should 
first rediscover, without any prior knowledge from the previous run, where 
apache's conf files are located and where the main DocumentRoot is.  

Two more big benefits of working on the real text config files is that
more advanced users can edit the config files directly without screwing up
the GUI, and that you can have multiple GUI's with different features or
varying levels of "newbieness" to do the same thing.

Note that all of this is hard, but doing things the right way the first 
time usually is.  But it's worth it in the long run.

-------------------------------------------------------------------
DDDD   David Kramer                   http://thekramers.net
DK KD
DKK D  If Bill Gates had a dime for every time a Windows box 
DK KD  crashed...
DDDD                           ...,Oh wait, he already does.