From owner-freebsd-chat Tue Sep 30 21:37:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA15361 for chat-outgoing; Tue, 30 Sep 1997 21:37:31 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [206.246.122.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA15352 for ; Tue, 30 Sep 1997 21:37:22 -0700 (PDT) Received: from Journey2.mat.net (journey2.mat.net [206.246.122.116]) by earth.mat.net (8.8.7/8.6.12) with SMTP id AAA26479; Wed, 1 Oct 1997 00:36:14 -0400 (EDT) Date: Wed, 1 Oct 1997 00:36:13 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: "Jordan K. Hubbard" cc: Mike Smith , Peter Korsten , chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) In-Reply-To: <11391.875672994@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 30 Sep 1997, Jordan K. Hubbard wrote: > > So, now that I've gone and summarized what I feel to be the only > possibly UI options, which one do I think would be best for us? How > the hell should I know? What I do know is that all 3 of these > approaches have one thing in common: They all need to bang on your > system's configuration. > > Think about it. :-) > > We need to step away from the interface question for a bit and > just focus on creating mechanisms for solving the following > problems: > > o Proper installation *with audit trail* of all software > on the system - this requires the merging of "packages" > and "distributions" into a common distribution package. OK. You mean this (I guess, from above) that this includes the ports packages. One shortcoming of ports is that the packages aren't aware of the sensitivities involved in upgrading from one version to a newer version of a package. port A, when going from version A.1 to A.2, simply writes a new package, A.2, right besides A.1. A later pkg_delete of A.1 will wipe out A.2's functionality. Do you have any other complaints on our present packaging mechanism? I'm going to start archiving this info, just on this thread. > > o Proper abstraction of the system's configuration metadata > along with authentication mechanisms flexible enough to allow > for individual permissions on the data. Your UI, be it web or > Tk based, would simply be one of many potential clients of > such a configuration server. > > o Creation of an installation and configuration *framework* > vs the monolithic utility we have now. Such a framework would > allow vendors to drop their own installation procedures into > the system for more seamless integration of their various tools > and also allow us to extend "setup" more modularly as time and > enthusiasm allow. Setting up samba or apache or any such > fancy utility should involve little more than running its > installation "applet" inside the installer's framework, > said framework providing a rich library of methods for > querying the user for specific information, doing > authentication, talking to the configuration server, etc. Seems like you're asking for the package tools to be able to do the pkg install, then automatically run specified scripts/programs that the writer installed in place in the package, to do the setup. Right? That's all I see here, and not a big stretch. > Any of these 3 problems can not only be solved in a UI-neutral > fashion, they *should* be since it leaves the door open for us to > follow whatever the next trend is in 3D interfaces or something ("Oh > man, what do you mean I can't just walk through FreeBSD's install with > my TurboVR goggles and my dataglove? Everyone else's installer does! > You guys are lame!" :-). OK, I agree. In fact, it should be ininitally capable of operating with no gui whatsover, right? Then the gui can be added in later? I don't think the core functionality of getting the partitions built, and the base downloaded/installed, can be done in a package mode. I would want that still to be a bootstrapping type thing. Disagree? I'm not saying that the same things done in initial install would be left uncovered later. I would want bootstrapping operations to cover partitioning, but I'd still want a partitioning script available later, for changes. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+-----------------------------------------------