On Sat, Apr 25, 2009 at 05:45:49PM -0600, Tim Judd wrote: > 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.
As long as you have sufficient RAM (and you don't actually need all that much of it) running X on an older CPU should not be much of a problem. (Unless X.org has bloated really badly over the last couple of years.) > > 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. That logic will often do the wrong thing for servers. They are the most common case where people want to install using a serial console, but typically do have a (fairly simple) graphical adapter and could run a graphical installer perfectly well. That does not necessarily mean that the person doing the install wants to do it. Better would be to check (somehow) for the presence of a keyboard and a screen. If those are not present forget about X. If they are present then the user at least has a possibility of using X. Also keep in mind that there are graphical adapters/screen combinations where X will not work correctly without first tweaking configuration files. Things have improved greatly here in recent years, but it is still not perfect. Text mode is still a good deal more compatible with all kinds of weird hardware. > > 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. I fail to see what the point of an X-based install would be - other than pure eye-candy, which does not seem very important for something like an installer which is used so rarely. -- <Insert your favourite quote here.> Erik Trulsson ertr1...@student.uu.se _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"