Date: Wed, 18 Jun 2003 12:12:15 -0700 From: Jordan K Hubbard <jkh@queasyweasel.com> To: Paul Robinson <paul@iconoplex.co.uk> Cc: freebsd-hackers@freebsd.org Subject: Re: Drawing graphics on terminal Message-ID: <C5FF2C50-A1C0-11D7-AE42-000393BB9222@queasyweasel.com> In-Reply-To: <20030618100125.GP20204@iconoplex.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C5FF2C50-A1C0-11D7-AE42-000393BB9222>