From owner-freebsd-chat Mon Sep 1 23:29:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA18871 for chat-outgoing; Mon, 1 Sep 1997 23:29:16 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA18863 for ; Mon, 1 Sep 1997 23:29:13 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id XAA19968; Mon, 1 Sep 1997 23:28:53 -0700 (PDT) To: John Fieber cc: Mike Smith , Peter Korsten , freebsd-chat@freebsd.org Subject: Re: sysinstall (was Re: Conclusion to "NT vs. Unix" debate) In-reply-to: Your message of "Mon, 01 Sep 1997 23:37:01 CDT." Date: Mon, 01 Sep 1997 23:28:53 -0700 Message-ID: <19964.873181733@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-chat@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Obviously if the change results in taking a differnt branch > through the install process, eg changing from a CDROM install to > a network install, you will have to proceed through screen at a > time from at least the branch point on. That's one of the reasons I'd want to express the install in terms of functional blocks which can be arranged, rearranged and viewed as a list of things to do, those already performed marked in some way. This would allow the more advanced users to drop into "create your own installation sequence" mode, where you could "drag" the following items off of a palette for a truly custom installation sequence: disks-partition disks-label media-select ftp://ftp.freebsd.org/pub/FreeBSD dist-select interactive install-commit dist-select des eBones media-select ftp://ftp.internat.freebsd.org/pub/FreeBSD install-commit media-select CDROM dist-select extras install-commit This contrived example aimed at installing the base OS from ftp.freebsd.org and the not-for-export bits from ftp.internat.freebsd.org. Far more creative combinations would, of course, be possible. > Lacking a visualization of the tree, a linear model with forward > and back would be more consistent with what a user experiences, > particularly if they don't make mistakes that cause different > branches to be traversed. I think even the linear model should allow visualization of planned or already performed operations. It would make it a lot more evident what was going on, for one thing, and hopefully eventually lead to novice users becoming more advanced ones over time. Jordan