Re: Daemon's Advocate article

[Robert Garrett <rg70@xxxxxxxxxxxxx>]

> Can't agree more. Too many things are just too inappropriate/needlessly
> complex.  Once something stupid becomes part of the OS, it's very hard
> to change it later. Actually forget everything I wrote, afterall worse
> is better!

Much has been said about the ineffectiveness of the FreeBSD installer, 
Matt, this code doesnt work, and prlly never will again.. what are the
chances that we can go ahead and get rid of the old sysinstall 
directory, and libdisk.

Design of a replacement is underway, there are people involved on many 
levels. However it has been my experience that I can talk about, and try 
to share my ideas for what it should be, and this will lead to a 
bikeshed, complete with fairings for the damn bikeshed.

So rather than talk i've been writing design documents, and working with
people to try to get a temporary fix in place. This is just a curses 
based fdisk to attempt to make it easier for someone who may not know 
how to fdisk, disklabel, and newfs there own partitions. To date Emiel 
Kollof is working on that.

Now as to the wording of the questions we need answered, and what 
questions we have to ask, vs what a user might like to tune is a 
different issue. At this point I am pretty comfortable with what I am 
doing in the back end of the configuration management piece of the 
installer. It is very modular, and easily expandable meeting the needs 
of those involved with the package management project, as well as 
installation.

The overall goals of the installer, are broad and sweeping as is 
everything else with dragonfly, this is not somthing that could be 
written in a weekend by anybody. As to the design pieces of this have 
been floating around in my mind for several years. However other pieces 
just hadn't clicked together to form the whole picture of what needs to 
happen.

Now that we are through discussing that yes sysinstall sucks, and yes 
jkh didn't write the most wonderfull UI, and the libraries used are 
pushed to beyond the limits of what they are capable of, lets call it a 
page in history and move on.

The question then becomes what does the new installer need to be.. what 
do I want it to be.. what does someone like my wife who has no clue 
about unix, Hell i'm not sure she could install windows sometimes.. need 
it to be so she can use it.

I am a sysadmin.. I have had the responsibility of running a decent 
number of FreeBSD systems, and found there is no good way of dealing 
with Configuration Management issues, The installer knows how to 
configure things, and it should be able to be used to handle this task 
after installation is complete.. It should also be capable of maintaning 
configurations for more than itself, this to me includes DragonFlyBSD 
systems, Linux, Net, Open, FreeBSD, and hell I could see a cisco module 
being written for the design I have chosen. Basically what I am saying 
is for this task we need a powerfull mechanism, jumpstart capable, with 
highly configurable installs.

My wife, well she wouldn't.. however, what she needs is a pre configured 
, automated install with reasonable defaults, and a friendly way to 
tweak things once everything is up and running. She is actually a lot 
simpler to please than I am. Her whole installation is a preconfigured 
automated install. Which I just so happen to need so I can build 
firewalls, and webservers, and so on.. without intervention from me.

There are several pieces of this whole puzzle..d

The first Matt so graciously provided, that is the live boot cd.
The next thing is we need to handle the disk layout and copy the bare
minimum from the cd, your smallest install.  The user would then reboot 
   into the newly created system. At this point I have to ask them a 
question X or console. Now from here on things are pretty simple..
we install if desired the rest of the base system, cp X and cvsup if so 
desired.. and start tweaking things into a runnable configuration.

the question is what do we want it to look like...
what I am working on can be many things.. and easily..
I can provide a web based interface, console would connect to a thttpd 
server running on localhost via links or another browser..
I can use anygui to provide nice graphical output or curses to handle 
console.. NONE of this matters to the backend..
It isn't dependant on anything.. one python class would need to be 
written to provide that functionality.

so all of you wonderfull people how should we phrase our questions to 
make things easiest for both us, and people new to dfly both enjoy, and 
successfully install this system?

Robert Garrett