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

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



Joseph Carter <knghtbrd@earthlink.net> writes:

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

If you use a bootdisk with a ram filesystem, put a script like below
into /etc/rcS.d/S00zipfind.sh

ZIP=""

while [ x$zip = x ]; do
  for device in sda4 sdb4 sdc4 sdd4 sde4 sdf4; do
    mount /dev/$device /zip
    if [ -e /zip/<file used to mark this zip as rescue zip> ]; then
      ZIP=$device
    else
      umount /dev/$device
  done
  echo Please insert the rescue zip and press return
  read
done

If you want to have root on the zip, root=/dev/zip

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

I had a look at the e2compr patches and they might be helpfull
there. One could have a loopback filesystem on the zip in its
compressed form. No need to uncompress it and no hassle with people
getting that wrong. :)

e2compr can use lzw, gzip or bzip(2) for compression/uncompression. A
small/slow system could be made with bzip2, a slightly bigger/faster
one with gzip.

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

There no difference between scsi zip and parallel I think. Both use
the 4th partition by default. (parallel zips are recognised as /dev/sdx4)

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

For the m68k I made it come down to inserting the CD into an Amiga,
clicking at the icon, waiting and saying yes to "Do you want to run
the demo mode?". Thats simplicity. :)

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

The problem is the size. For people with modems the small console
setup would be fine. For people with 10 MBit ethernet at university
or people with the CD a 150 MB live filesystem (40 MB compressed)
wouldn't mean much hassle (The numbers are from an m68k installation
of everything that is preselected in dselect).

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

Yep.

May the Source be with you.
			Mrvn


--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: