Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



One thing that you underscore is that these config utilities use a separate database, which is 
different from the actual configurations files, which are usually ASCII. 
The problem is that duplicate databases (or the same information duplicated in separate 
databases) are a real problem. Why the distro people keep coming up with solutions like linuxconf 
or YaST is beyond me, because it violates the basic principles of data integrity. 

I like YaST because it is simple and straightforward, in contrast to Linuxconf. 

I would think that a set of tools with a common look and feel (both character cell and graphical) 
but which operate on the actual text files would be preferential. These tools could maintain backup 
copies either in a code management system (like RCS). 

Also, this problem is not just unique to Linux, it is also a problem in commercial Unix systems. Try 
using SAM in HP-UX :-). 
On 26 Feb 2002 at 11:24, David Kramer wrote:

> 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.
> 
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://www.blu.org/mailman/listinfo/discuss

Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org