Modern FreeBSD Installer?

[Polytropon]

On Sat, 25 Apr 2009 17:45:49 -0600, Tim Judd <tajudd at gmail.com> wrote:
> If it's
> a fast 686, default to a X environment.

I would always encourage using a text mode dialog FIRST. Such
as

	Your system is able to run the graphical installer.
	Do you want to launch it, or do you want to work with
	the text mode installer indead?

		[ text mode ]		[ graphical mode ]

Note that not everybody with sufficient hardware would also
want to use the GUI installer. Well... I won't... :-)

CPU power is not the only criteria for running a GUI installer.
But you already got into detail and took this into mind.



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

Then the problem of how to support these graphical adapters
could arise. You know that X has often problems autodetecting
stuff correct, even stuff that worked fine with XFree86 doesn't
always work with X.org. So problems are not only "too new"
things, but "too old" things, too.



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

A window manager? Why use a window manager? It's possible to run X
without any window manager, and in this case, it makes sense, 
because there are no windows to be managed. It's only one program
running - the installer.

Of course, we're just talking about an installer, aren't we? It's
not about a full-featured live system where you can use Firefox
while doing the install. :-)



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

I'm not sure I understood this correctly... Do you suggest
something like running a (minimalistic) web server from the
machine where FreeBSD is about to be installed, and then
have either a HTTP connection from localhost or from a
distant machine (where someone else can do the install)?



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

Well, dump & restore is my preferred method of "cloning" from
a "master workstation". But I'm not sure it can be used for
custom installation where the amount of what to install may
vary, and it is determined by the person who installs...



> 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 think that is too much. You'll always want the CD
you haven't got at hand at the moment. :-)



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

Well, then I'd suggest you prove why eye-candy is needed
at all in the first place. :-)

As Wojciech mentioned in one of his replies, I'd welcome
new functionalities - instead of the same functionalities
in an "X enclosure" that makes everything slower. :-)

For example, if you get the sources from the install disc,
sysinstall could provide a step to update them right away,
letting you select the update server and then run csup to
bring them up to date.

Just an idea.

One of many possible ideas. :-)


-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...