Date: Tue, 26 Nov 1996 22:05:26 -0600 (CST) From: Joe Greco <jgreco@brasil.moneng.mei.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: jgreco@brasil.moneng.mei.com, peter@taronga.com, bmk@fta.com, brantk@atlas.com, hackers@FreeBSD.org Subject: Re: Replacing sendmail Message-ID: <199611270405.WAA18185@brasil.moneng.mei.com> In-Reply-To: <14277.849052278@time.cdrom.com> from "Jordan K. Hubbard" at Nov 26, 96 03:51:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > CONFIGURATION of packages is a problem as well. I am not sure that it > > is wise to try to solve both problems with the same tool, but am certainly > > willing to discuss it if you believe that it is (I will tell you now: I have > > a preconceived notion that it is not a good idea). > > Well, I think we are all talking about much the same thing here, > simply with different jargon, so the ultimate design will probably > come down more to what the initial proof-of-concept looks like at this > stage than any long thread which debates the more etherial concepts of > configuration management. > > However, just in closing, I'd like to also note that we should stay > focused on the fact that this is *not* being designed for hackers, > this is being designed for end-users, and the end users have become > conditioned by Windows & Macintosh machines to think in terms of > services rather than MTAs or packages or even UNIX subsystems. > Ultimately, the user doesn't want to think about "sendmail" or > "qmail", they want to think about "small mail agent" or "big mail > agent" (just to draw a very simplistic point of division - I'd expect > the real dividing line to be somewhat more complex). They don't want > to know about lpr and optional filters, they want to say "I have a > printer, here's what kind it is, do the rest please!" > > This is what makes me think that any framework will end up drawing > lines around things grouped by function, not by placement. > > The traditional UNIX die-hards will also never accept a complete > decoupling of things like sendmail, so it's probably also not > practical to hope that you can "packagify" everything at the actual > implementation level - there will be a significant amount of > transparent bridge work going on in any real-life system which gets > developed. I suspect this is partially true. Nobody is preventing the tool(s) being discussed from being used as building blocks for a grand scheme of "Windoze style system management" - it is just that it is very hard to build a complex bridge unless you have the concept of steel beams and rivets available to you, etc. However, you are also going to find that there are those of us who are definitely "UNIX die-hards", but we just do not have the time in a day to do all the things we would like to. Tools help. And they help a lot. Given a framework, it would be twice as easy to track the latest Sendmail or BIND release because it would simply mean building a port, without excessive "extra" effort. I am sure you agree that the "make; make install" required by a port is a LOT easier than the procedure to manually download, untar, configure, compile, maybe tweak and recompile, and then install a software package such as Sendmail. And if I had an easy method to disable unnecessary setuid programs (granted it can be done by hand, it is just more time) I might tend to do it on more boxes. I am very much into making my own life easier when I can... if it was not for the ports system, I probably would not install many of the "standard add-on" ports that I do to every box I set up. The ports system does not give me any new capability that I did not have before, but it makes it SO EASY. :-) ... JG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611270405.WAA18185>