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:
pgpePg5BmhQnF.pgp
Description: PGP signature