Date: Wed, 22 Jan 1997 13:28:16 -0700 From: Warner Losh <imp@village.org> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: John Fieber <jfieber@indiana.edu>, Larry Lee <lclee@primenet.com>, chat@freefall.freebsd.org, config@freebsd.org Subject: Re: Commerical applications Message-ID: <E0vn9HM-00027s-00@rover.village.org> In-Reply-To: Your message of "Wed, 22 Jan 1997 11:53:55 PST." <25086.853962835@time.cdrom.com> References: <25086.853962835@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <25086.853962835@time.cdrom.com> "Jordan K. Hubbard" writes: : However, we still suffer from a bad case of "tools gap", where there : is really no reasonable framework for allowing the UI people to easily : 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. : I also don't think that design is really the issue here since I'm : pretty sure that we all basically know what we need and Windows, for : better or for worse, has already shown us much of the way. We need a : hardware configuration tool for configuring, creating and installing : kernels. We need a user configuration tool for adding, deleting and : otherwise managing user accounts and groups. We need a login : configuration tool for setting desktop preferences, login defaults, : quotas, etc. We need a network configuration tool for managing : interfaces, DNS, routing, IP aliases, etc. We need a network services : tool for turning services like telnet, rlogin, ssh, etc on and off and : configuring their individual settings. We need a printer setup and : queue management tool. I could go on, and these are just the work of : about 2 minutes thought - if I really put my mind to it, I could : probably list another 3 or 4 major categories in which we have no : configuration coverage at all. :-) All you need is a framework for describing what needs to be changed. The actual GUI from that point is fairly easy to do... : However, there's just a lot of work there, plain and simple. We don't : even have the tools for writing all those nice looking configuration : screens yet, and we need to get that situation taken care of before : any progress will ever be made in this area. That's true. 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. Hacking out custom interfaces for each screen you want will likely doom this project to failure, or at least taking a really really long time. I just wish I had more time to devote to all of this. Sounds like a lot of fun. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vn9HM-00027s-00>