Date: Sat, 1 Jun 2002 01:29:48 +0200 From: "Daniel Blankensteiner" <db@traceroute.dk> To: "Terry Lambert" <tlambert2@mindspring.com> Cc: <freebsd-arch@freebsd.org> Subject: Re: FreeBSD daemon configurations redesign Message-ID: <024201c208fb$0df8ae10$6800a8c0@rafter> References: <F67gL6wxvw0IDT8zAJ90000d078@hotmail.com> <00c601c2082d$bc531ff0$6800a8c0@rafter> <3CF6B300.145E0CD9@mindspring.com> <011201c20832$34404750$6800a8c0@rafter> <3CF6CC39.BFC0A232@mindspring.com> <011001c20885$6dc3db60$6800a8c0@rafter> <3CF7E342.C351A12E@mindspring.com> <01bf01c208ec$b11a7380$6800a8c0@rafter> <3CF7FE67.868D4EF9@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Terry Lambert" <tlambert2@mindspring.com> > I will share with you "Lessons I have learned about doing business > using Open Source: Lesson #31": > > There are three ways to view this: > > o System-centric > o Service-centric > o User-centric > > Right now, things are (mostly) system-centric. In your example of > adding a user and establishing permissions, you have a problem which > is user-centric. Then you propose a solution which is service-centric. > This doesn't make a lot of sense. > > When you are trying to create a user-centric model (e.g. the InterJet > was such a model), then the best possible world is to implement a > user-centric parameter store. > > When you have to live in the world of attempting to leverage existing > source code, then you have to accept some limitations that come with > that existing source code. > > This was a lesson that some of our UI people never learned, and so > they tried to change some basic underlying paradigms. Yes, it's > possible to do what they wanted (though, probably not wise, if you > get right down to it), but the cost would be to not be able to use > the exisiting code out there for leverage: the job would have to be > done "from scratch"... and there are litterally hundreds of thousands > of man years of effort in software like DNS and sendmail, etc., that > it would be a shame to have to duplicate. UI? > Most companies that try to base products on Open Source really fail > to learn this lesson: sometimes you have to bend to the software, > rather than attempt to bend the software to your will. Then, of > course, the companies themselves fail. > > The best compromise for a user-centric administrative view is to > leave the configuration file layouts and formats alone, and put > your own database out there. Then derive the configuration data > for the software -- in its native format -- from the contents of > your magic user-centric database. > > There are a couple of interesting problems you end up needing to > solve when you take this approach, but they are ultimatrely > soluable. > > I think you are much better off trying to build something like > this (if you are smart, it will probably be based on LDAP), than > you are in trying to change every piece of software out there to > fit a paradigm that is specific to FreeBSD, and will lose you the > third party maintenance that makes the current model valuable: > it offloads maintenance onto third parties. LDAP? Ok, I did not know it all had to be rewritten from scratch. I thought you just had to rewrite where the daemons store it's confil files. Making an interface to all these config files (like you said), is maybe a better idea. I would like to design this, but I don't think my code will be good enogh for FreeBSD? br db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?024201c208fb$0df8ae10$6800a8c0>