From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 2 00:39:48 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CA1116A4CE; Thu, 2 Dec 2004 00:39:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8B2343D49; Thu, 2 Dec 2004 00:39:47 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iB20hSLB063844; Wed, 1 Dec 2004 17:43:29 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41AE6460.6040603@freebsd.org> Date: Wed, 01 Dec 2004 17:40:00 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <41AE3F80.1000506@freebsd.org> <20041202002939.GA2834@ns1.xcllnt.net> In-Reply-To: <20041202002939.GA2834@ns1.xcllnt.net> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: hackers@freebsd.org cc: "current@freebsd.org" Subject: Re: My project wish-list for the next 12 months X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2004 00:39:48 -0000 Marcel Moolenaar wrote: > On Wed, Dec 01, 2004 at 03:02:40PM -0700, Scott Long wrote: > >>1. Keyboard multiplexer. > > > I actually fail to stop thinking about a complete syscons and pcvt > replacement. You know, the one and only console implementation that > makes all others obsolete. Big plans, little time, yada yada yada... > > >>2. New installer. > > > It may actually be interesting to see if we can make an expert > system for this. When I think about implementing an installer (alas > I've been doing that), I'm not so much interested in how things are > packaged, or how it looks but rather what needs to be done, when and > how all these actions relate and interact with each other. This is > especially tricky when actions are triggered by the current > configuration of the machine onto which one tries to install. Knowing > all the possible activities and their dependencies should help > establish a control flow through the installation process in such a > way that users get asked only those questions that are relevent and > also when it matters. One puts a UI on top of this to get a nice > looking installer. At least, that's how I look at it... > Yeah, I've had many similar thoughts. The hard part of a new installer, or any complex UI application, is the framework that ties events and actions together. The easy part is writing the modules on top of that that do the discrete actions. While I see quite a few rough edges in the upper layers of the DF installer, it seems like quite a bit of work is going into the framework, and that's why I'm actually so interested in it. Scott