LibH pronounced dead, need for a new leadership

[Robert Watson]

On Sat, 22 May 2004, The Anarcat wrote:

<snip>
> That is why I CC'd core. Hear our call! FreeBSD needs a new installer! 
> Let's wake this daemon! 
</snip>

I think most FreeBSD developers recognize that FreeBSD has gone from a
relative leader in the pack in install usability and management to lagging
behind, simply by virtue of having (as jkh pointed out) something that was
just sufficient to keep working with incremental tweaks.  I think there's
also a lot of agreement that Something Must Be Done, but that it (as
usual) comes down to a few hard questions:

- How to build a new installer/management environment without bumping into
  extensive second system syndrome.  There's a nasty temptation to build
  from scratch and try to make it all-singing and all-dancing.

- How to get buy-in for the project while its in progress, as well as to
  build interest and development support.  It's a non-trivial task.

- How to find resources to work on it that are sustained at a high level
  for long enough.  Again, a non-trivial task.

I agree that software reuse is a big part of the answer -- it's clear we
have been unable to muster what was needed so far, in part because the
FreeBSD Project hasn't become a haven for GUI and user interface types. 
We provide a well-defined layer that happens to be a few layers below what
those people tend to be interested in :-).

I would suggest some serious scoping is in order for whoever decides to
take on the task.  First, I'd suggest avoiding all-singing and
all-dancing, since it requires a lot of infrastructure investment.  Here
are some things not to do:

- GUI installers are cool, but they're a lot of investment.  Maybe we
  should eschew it and just go for a decent text interface to get the base
  system installed.  Libdialog was half decent when it was first
  integrated into the installer, but I think everyone recognized the state
  of the art has moved on a bit.  Don't design precluding it, but don't
  try to create an optimal architecture for a GUI if the resources aren't
  there to follow through, it will just become an obstacle. 

- Don't try to solve the package management problem.  I know it's hard not
  to, since one of the failings of our current install model is that we
  don't have a decent package management solution.  However I think you'll
  find a lot of successful systems don't have a decent package management
  solution for the core of the OS, albeit perhaps a smaller core than we
  have.  Start out building something that just works with tarballs.

- Do focus on the ordering and procedure of the install process:
  investigate the requirements for a two-phase process (boot the install
  media, splat, boot from the hard disk and finish up).  Part of the
  complexity in sysinstall is attempting to provide a normal runtime
  environment for package install when the configuration is arguably not
  normal, so chroot(), libraries, etc, get involved.  Splitting into two
  distinct environments may help with this, as well as allow the
  post-splat phase to take advantage of more tools and capabilities that
  today sysinstall can't use (such as a full X install, GUI or third party
  libraries, etc).

- Likewise, do focus on how the new installer will build up a description
  of an installation to perform before committing, which is something
  syinstall doesn't address well (resulting in the incremental changes
  just making it worse). 

- Do answer the question of how the install mechanism fits into the
  FreeBSD development environment.  Remember that the FreeBSD Project is
  unlikely to want to import vast quantities of libraries and scripting
  languages into the base source tree.  Can we identify a model by which
  the installer becomes an external build and package from the 'src' tree? 

Grabbing someone else's solution is certainly possible, but it doesn't
necessarily make all of the above easier.  Frankly, my temptation, if I
were going to try and run such a project, would be to spit out a prototype
system that isn't integrated into 'src' as a relative fait accompli over a
period of 4-6 months, and then say "Hey, it works!".  I'd add some
abstraction for the base component installing process, but I'd focus more
on the installation model and trying to move away from libdialog.  Much of
the nastiness of sysinstall comes out of libdialog offering a poor event
model and state mechanism.

You might consider appealing on a FreeBSD user's list or two looking for
application developers interested in helping.  You want FreeBSD developers
involved, but I'm not sure they are reliable for this sort of work: for
one thing, it's pretty far from their areas of expertise so if they lead
the charge, you'll get the common results of that (second system syndrome
and burnout :-).  You might want to talk to Scott Long, since I know he's
also given this issue some thought...

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research