Drawing graphics on terminal

Paul Robinson paul at iconoplex.co.uk
Thu Jun 19 07:15:02 PDT 2003


On Wed, Jun 18, 2003 at 12:12:15PM -0700, Jordan K Hubbard wrote:

I was wondering when Jordan was going to come and beat me up... :-)

> 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:

OK, I remember seeing you announce libh. I'm not going to go back through
the archives, but it was around the same time you made a posting saying you
were really getting into package management. At the time three things were
going on in my life:

1. I wanted to work on the installer and help get rid of sysinstall

2. I needed to find a job

It took me 12 months to get #2 out of the way. In the mean time, I kept a 
distant eye on libh, but didn't get involved because I didn't have anywhere 
near enough time to give you code, or even come up with good arguments as to 
what I thought were valid points. As a result, my view of libh was limited, 
but looked at first (especially from the brief notes and screen shots I saw) 
as not a great deal more than replicating sysintstall with another 
interface. I stand corrected. Sorry to cause offence.
 
> 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.

This, I remember, was a big part of libh. In my opinion things need to go 
further that that though. It's not just whether it's on a serial console or 
in pretty graphical SVGA mode, or in X, there's a big issue here about 
abstracting the process to the user's view of the world. libh was never 
going to get that going early on...
 
> 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.

That's package management. In fact, it's SCM, policy control and package 
management. It's one of the few areas MS does actually handle relatively 
well (compared to *nix), but I think whacking it into an installer is the 
wrong place. I know what you're saying though.
 
> 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.

That's a huge issue. In fact, that's bigger than I really like to think 
about. Especially if you want users to be able to handle /usr/ports as well 
as pkg_add...
 
> 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.

I should repharse my statement too "functionally equivalent in the advanced
user context view", but that sounds like shit. So I'll just say sorry for 
the confusion - I didn't mean "just prettying up sysinstall" as an insult to 
the work you and others have put in.
 
> 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.   

Yeah, the screen shots do look like a drop-in replacement for sysinstall 
with knobs on. It take a little digging to find out more...

> 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.

And that work will almost certainly get stolen wholesale and moved into the 
next installer project. :-)
 
> 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.

Hmmmm. See what you're saying. It would be easier, but ultimately, it's not 
a huge issue to give a comfortable UI in the space of a floppy. Perhaps I'm 
going mad, but last time I looked at this, it didn't seem to be a problem. 

Anyway, I vote for now that this correspondance is closed. if somebody sets 
up another mailing list for the purposes of making FreeBSD a friendly, 
cuddly, desktop wonder-land, maybe discussions there can go on, but until 
some code appears, let's shut the hell up. :-)

-- 
Paul Robinson


More information about the freebsd-hackers mailing list