[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A project to provide a nicer GUI for installing debian ?



On Sat, Jul 04, 1998 at 08:09:44PM +0200, Brederlow wrote:
> > There was a couple messages about live filesystems and other exotic and
> > non-traditional methods of running Debian on -user.  I'm investigating a Zip
> > disk-based super-rescue disk and will be happy to share my experience found
> > with building that with a project to do the same kind of thing for a CD-ROM. 
> > It's a little harder since one is a RW media with enough space but not lots
> > of it and the other is media with lots of space and none of it writable.
> 
> On a zip you can install a normal Linux system. 100 MB are enough for
> a client or rescue system.

It's enough at least for a rather full-featured client to show off the power
of Linux.  I wouldn't want to go randomly deleting things though.  The big
deal I'm making about the Zip is that I don't want the user to have to FIND
the device their Zip is on.  A script could and should be able to identify
the Zip drive and not ask you to put in /dev/sdX4...


> > This would cost about 100 megs to have all the X servers installed I
> > suspect.  Do we really want that much?  Maybe we should consider a 2.2.x
> 
> I had a System on a zip with 3 X severs. After deleting unwanted stuff 
> I got it down to 30 MB on a zip or a 13 MB gz file. If one is carefull 
> what to include one doesn't even need the 100 MB.

That's a big issue.  You don't want them to have to download a big fileset. 
I'm working on that too, but the result looks like you'll probably use a
standard FAT Zip disk and unzip or untar a fileset on to them.  (I intend to
provide both avenues) The Zip install will probably be a profile for a zip
disk installation that would include a package that I'm gonna use to make
the zip rescue..  Something to find and boot off a Zip drive from either
that Zip (SCSI and eventially IDE models), a DOS batch file (all models), or
a boot disk (all models)..

The point is simplification for the user, especially the NEW user.


> > solution and build it around GGI?  Libggi can already run many places
> > including the newest 2.1.x kernels' fbcon (which broke the kernels nicely,
> > but of course will be fixed..)  Under GGI you'd need one X server and the
> > config of the whole thing is lots easier.
> 
> How much hardware is supported by ggi and in what resolutions?

Various and expanding and various and expanding.  =>  But even this is only
a question that needs asking of the kgi and I think the kgi-fbcon targets. 
GGI has svgalib and X targets too.


> Since a live filesystem would be only possible on CD's (100 MB are to
> much to download just for installation) or as a rescue System build by 
> a Package its only possible to provide it as a second choice. It
> should not replace the normal bootdisks, at least not until its down
> to say 10 disks or so.
> 
> One could provide a minimal console live filesystem for installation
> similar to the current one and an alternative big live filesystem with 
> X. That would of cause mean that we need a gui that can run on console 
> and X. (Exactly what is developed for the Dragon tools currently).

There'd be no reason to have two filesystems.  Just use the one with X for
both and ask the user what they want.  However, I don't want to take up 1--
megs or so on a CD to have an X-able installation.  Again, that's why I
suggest seeing what GGI can offer.  It'll support most of the hardware X
does by the time slink is released and then would be a really smart move to
look at it.

Most certainly the text-based config option is a must.

Attachment: pgpkZ87FgjMEt.pgp
Description: PGP signature


Reply to: