Date: Sun, 23 May 2004 12:29:18 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: The Anarcat <anarcat@anarcat.ath.cx> Cc: timh@tjhawkins.com Subject: Re: LibH pronounced dead, need for a new leadership Message-ID: <Pine.NEB.3.96L.1040523121543.95236B-100000@fledge.watson.org> In-Reply-To: <20040522204044.GB48382@shall.anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040523121543.95236B-100000>