Drawing graphics on terminal

[Jordan K Hubbard]

On Wednesday, June 18, 2003, at 03:01 AM, Paul Robinson wrote:

> I hate sysinstall. I had some spare time and was
> going to start on something when Jordan piped up with libh. I'm not 
> sure if
> libh was the right way to go anyway - it just prettied up sysinstall 
> and
> made it more confusing to a novice user.

Hmmm.  That is an interesting statement given that libh has not made 
any attempt so far to "pretty up sysinstall" or has really provided 
anything in the way of an installer so far.  The first and foremost 
goal of libh was to provide a set of "base primitives" which would deal 
with various architectural issues common to any installer effort, 
issues such as:

1.  Providing a user interface abstraction layer so the same installer 
(whatever it ended up looking like) could end up running on X displays 
or serial consoles.

2. Providing reversible upgrades and a central software registration 
database so that the artificial distinction between things added via 
ports and things added via "the base install" could finally be removed.

3. Adding the notion of flexible security policies so that the 
administrator could choose how and where various packages were 
installed on the system, prohibiting "rogue packages" from splatting 
themselves just anywhere.

These are just three of the challenges libh has taken on and by no 
means an exhaustive list.  Nowhere, however, is any intention of 
"making sysinstall more pretty" or even following in sysinstall's 
footsteps in any way.

If you've seen any UI's for libh to date, they've been essentially 
mock-ups who's sole purpose was to demonstrate the various capabilities 
of the UI abstraction layer.   Most discussions around the various 
approaches to actual system installation have focused on how NOT to 
present UI to the user and to streamline the process for users who just 
don't care about the details and want to answer, at most, a question or 
two up-front about whether or not the installer should take over all 
disk space on the system or just the unpartitioned space and what sort 
of role the system is expected to play (desktop, server, etc).  After 
that, the installer is expected to simply DTRT.

If people want to discuss installation from the perspective of 
'mechanism', I think they'd do better to focus on just how to break it 
into two parts:  The installation bootstrap, which would be designed to 
be very small and largely do little more than find some larger media 
somewhere (CD, network, ...) establish where the system's boot 
partition is going to be and copy the 2nd stage install into it.  Then 
you can reboot off the hard drive and get much fancier with a VGA16 X 
server or ncurses based installer which uses as much of the UI 
capabilities as are available depending on what the person doing the 
install is sitting in front of.

--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer