From owner-freebsd-hackers  Mon Nov 27 09:40:55 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id JAA16206
          for hackers-outgoing; Mon, 27 Nov 1995 09:40:55 -0800
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA16196
          ; Mon, 27 Nov 1995 09:40:48 -0800
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id JAA02282; Mon, 27 Nov 1995 09:38:20 -0800
To: sos@FreeBSD.ORG
cc: cshenton@apollo.hq.nasa.gov, hackers@FreeBSD.ORG
Subject: Re: Thoughts on the install and on Red Hat Linux. 
In-reply-to: Your message of "Mon, 27 Nov 1995 09:33:46 +0100."
             <199511270833.JAA16295@ra.dkuug.dk> 
Date: Mon, 27 Nov 1995 09:38:20 -0800
Message-ID: <2280.817493900@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> It might be "fancy looking" to have an install process running in X,
> BUT, gentlemen, keep in mind all the hassle we had when we said
> that 4M wasn't enough to boot the install disk !!

I don't think that anyone is talking about *just* having things work
under X.  Consider also that it takes a fair number of setup menus and
dialogs and such to even *get* to where X is set up, I still see
implementing this as a GUI toolchest that works under both
environments.  Yes, some of the early toolkits that attempted to do
this looked pretty klunky and gave the whole idea of "UI transparency"
something of a bad name.  However, this has not been the case with second
generation tkits like C++/Views, zApp or Galaxy.  It never looks quite
as out-and-out *rich* as a balls-to-the-wall Tk app, mind you, but good
enough definitely.

I could also see not doing the entire install using the toolkit.  You
might, in fact, have one path through it where you're in the ncurses
based interface all the time and don't ever see an X server (it might
be impractical - what if you have a next generation video card that's
not even supported?  Soren had this exact experience with the Viper
Pro Video board I gave him for some time! :-).  Another path might
lead straight through the X config dialogs to X and then into a much
*richer* environment.  There are a lot of things we can do as "frills"
once we've established our base minimum for install functionality,
and such frills don't necessarily even have to be part of sysinstall.
It can always run other programs, you know.. :-)

In fact, and I know I'm getting terribly off-topic now but it's as
good a time as any to make the point, I think sysinstall is actually
too monolithic.  Totally violates the UNIX philosophy, in fact!

Rather than a number of useful libraries and programs like `disklabel'
or `fdisk' tarted up to use them, we have almost no libraries (except
for libdisk) and fdisk/disklabel left in their old and klunky state.

sysinstall would do better to become a wrapper & launcher for each
piece as a separate program, or at the very least some sort of
dynamically loadable module!  We could write a very small little
module loader/launcher as well and implement "fdisk" and "disklabel"
as simple mains which load the fdisk and disklabel modules and run
them stand-alone.

But I digress. :-)

Anyway, as to Soren's little libvga library is concerned, well, I
merely remind him that he and I have been talking about this *in
theory* for months now..  I wouldn't mind seeing the proof-of-concept
implmementation. :-)

					Jordan