Drawing graphics on terminal
Jordan K Hubbard
jkh at queasyweasel.com
Wed Jun 18 12:12:18 PDT 2003
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
More information about the freebsd-hackers
mailing list