Date: Wed, 22 Jan 1997 12:42:31 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Warner Losh <imp@village.org> Cc: John Fieber <jfieber@indiana.edu>, Larry Lee <lclee@primenet.com>, chat@freefall.freebsd.org, config@FreeBSD.ORG Subject: Re: Commerical applications Message-ID: <25361.853965751@time.cdrom.com> In-Reply-To: Your message of "Wed, 22 Jan 1997 13:28:16 MST." <E0vn9HM-00027s-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> : practice their craft. Since we can't count on an X server being > : present (either due to configuration hassles, non-support for a given > : card or other hardware issues), > > The SVGA or VGA drivers will run on almost all hardware. Maybe not > optimally, or at 1600x1200, but the X server can be made to run in > that small a footprint. You're forgetting serial consoles and machines with monochrome adaptors so funky that I doubt any reasonable X would run on them (don't laugh, I think freefall has one of these cards in it - it's a server machine with no need of a good gfx card). This is not to say that you have to bend over backwards to support such machines, simply that some alternative needs to be supplied if we're talking about something as critical as installation and basic configuration being drawn under the umbrella of this new system. > Having done this stuff before, you really want to have a good set of > meta data so that you can drive EVERYTHING in your > build/configuration/etc world by that meta data. How you drive it > isn't too interesting, since you can easily write something that groks > X and another something that groks curses. Generally it is hard to > write something that gorks both. Oh, I agree. That's made almost mandatory by the widely divergent nature of the underlying configuration files anyway. If I make a DNS auto-configurator, for example, you can bet that I don't want to put the code for groking named's configuration files into the configuration tool itself - that would be nightmarish. Rather, I write a single CLI based tool which implements an argument set from hell for frobbing DNS. Then everything else fronts for that tool and insulates the users from its devilish argument syntax. Even there, there's a fair bit of work just to be done in defining a CLI tool for every type of service you want an abstract interface for, but now that I think of it, perhaps that's not a bad place to start at all. We could put aside our GUI selection problems for the time being and just pile in on writing little `pw'-like tools for all the stuff we want to bring into the first version of the system. Once critical mass has been achieved there, I suspect that the front-end folks would start coming out of the woodwork and, in the short term, I could write some libdialog based stuff to handle our immediate proof-of-concept needs. What do people think? If this idea sounds promising, we could move on to the next step by making a list of all the configurators (I like that name :) we need to write and try to come up with some consistent standards for argument naming (e.g. all configurators accept ``--help'' for describing themselves, ``--fake'' to only pretend to do whatever it is they do, etc.). I'd be happy to help here. Jordan P.S. Is it time for us to move this over solely to config? I'm not sure if this is -chat material anymore.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25361.853965751>