Reading the second half of these mailings got me thinking.  Thinking of ways
to detect what CAN be done, and what CAN'T -- based entirely on the hardware
at boot.  I think that we might come to a middle ground to get something
working.  Here's my thought process right now, with hopefully ample samples
to example my angle (that was fun to say).

It's based on two principles.  First is the CPU class.  If it's a 486 or
586, run a pure dialog(3) interface.  If it's a slow 686 (and the fudge
factor to define slow is based on Xorg's *recommended* CPU specs + the
software installation CPU/RAM needs), run the dialog(3) interface.  If it's
a fast 686, default to a X environment.

Second (which ties into the first) is the hardware that was probed during
boot-time.  If a /dev entry (or even some sysctl) exists for a pci/agp/pci-e
device, it can run a graphical installer.  If it finds none of the graphical
adapters, and sees serial ports, enable the dialog(3) as well.  I feel like
some pseudo-code might help paint the picture more.

text-mode_install = graphic-mode_install = false
if (CPUCLASS<=586 || CPUSPEED<=(Xorg-suggested-minimums+install
requirements)) {
  set text-mode_install true
} else {
  set graphic-mode_install true
if (found(VGA-graphics) && graphic-mode_install) {
  exec xinstall
} else {
  # enable console installer
  exec sysinstall

I seem to find this very logical and can't (yet) see any flaws with doing
this.  sysinstall is built, we'd just need to maintain it and create the
x-based installer.  Run it with a minimalist (twm?) startup so we don't
waste time booting.

I've also thought about the concept of a web-ui installer, even if it's run
from the local machine.  The benefit of a webui installer is that you can
give the disk to someone, tell them to put it up on a publically available
IP address and just sit back and let it run.  but I ramble on....

And also brainstorming now has brought me another idea about installing base
with the concerns Jordan Hubbard wrote in 2000 mentioned in this thread.
Again based on the hardware probed (this one being the amount of RAM in the
box, in contrast to the amount of disk space needed to install on disk),
create a in-ram disk as the staging area when you write to disk.  The other
idea is to use dump/restore instead of tar files.

It is possible to have a 3GHz machine with 256MB ram as a valid combination,
but when bin distribution is about 128MB in size, and kernel distribution is
128MB in size, and blindly running an X install -- not wise.

Last idea is to do similar to what Ubuntu (used to) do.  Provide a X-based
installer CD and a console-based installer CD.

I'd be happy to provide feedback; these were brainstorming ideas and would
really like to see progress move toward a more eye-candy installer.

_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to