Date: Wed, 1 Oct 1997 00:36:13 -0400 (EDT) From: Chuck Robey <chuckr@glue.umd.edu> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: Mike Smith <mike@smith.net.au>, Peter Korsten <peter@grendel.IAEhv.nl>, chat@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <Pine.BSF.3.96.971001002405.289D-100000@Journey2.mat.net> In-Reply-To: <11391.875672994@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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!
----------------------------+-----------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.971001002405.289D-100000>