Date: Sat, 24 Feb 2001 18:08:31 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: John Baldwin <jhb@FreeBSD.ORG> Cc: Nate Williams <nate@yogotech.com>, arch@FreeBSD.ORG, josb@cncdsl.com, Alfred Perlstein <bright@wintelcom.net>, Terry Lambert <tlambert@primenet.com>, Randell Jesup <rjesup@wgate.com>, Wes Peters <wes@softweyr.com>, Tony Finch <dot@dotat.at> Subject: Re: DJBDNS vs. BIND Message-ID: <200102250208.f1P28VC10795@earth.backplane.com> References: <XFMail.010224155545.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:>> applications :>> in a single file is (A) a stupid idea, (B) a stupid idea, and most :>> importantly (C) ... a stupid idea. :> :> So, does that mean we should get rid of /etc/rc.conf? : :It's the configuration file for /etc/rc. Just one conceptual program. :) :It doesn't specify configuration information for the programs that rc runs, :just what programs to run. : :-- : :John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ Right. Sometime it's hard to tell whether people are serious or just being annoying when they post stupid 'does that mean' missifs. Assuming the original poster was serious, I will give a serious answer. But even that is somewhat beside the point because there are always exceptions to the rule in any system... the existance of such exceptions in no way justifies their methodology when applied to general principles or to other matters. Context matters. Files such as /etc/spwd.db (aka /etc/master.passwd) hold very specific, *generally* used information. Just because such files are used by almost every program in the system doesn't mean that they are similar to something like the windoz registry. There are many files in the system that are used everywhere that hold very specific, well defined, generally used information. The password file is only one example. /etc/group, /etc/localtime, /etc/resolv.conf, there are dozens of such files. A file such as /etc/rc.conf may apply to many programs, but it's a read-only typically boot-time-only entity. On top of that, while all the /etc/rc* files reference many different programs, all of the programs and defaults with only a very few exceptions are part of the base system. 99.9% of third party programs don't use /etc/rc.conf directly and don't know it even exists, and entries in rc.conf are typically very small single-line entities. This means that even though the parameters specified in /etc/rc.conf may apply to many different programs, it is still a very far cry from what registry-like system is designed to deal with. One can hardly compare /etc/rc.conf against a registry. In contrast, configuration files such as /etc/namedb/named.conf, /etc/ntp.conf, /usr/local/etc/dhcpd.conf, /etc/mail/sendmail.cf, etc are a very different breed. Each of these files contains relatively complex configuration information for a specific subsystem and the rest of the system never needs to touch them. Only ntpd uses ntp.conf. Only dhcpd uses dhcpd.conf. Only sendmail uses sendmail.cf. Furthermore, these files are not 'config and forget' files like rc.conf. In addition to these configuration files, many subsystems require writable persistent store (and typically use /var/db for that). Under UNIX, it is SOP for these files to be independant of each other. A 'registry' in the context of this thread is meant to replace the second type of file... the named.conf's and ntp.conf's of the world, and a registry might very well be used for the first type of file as well.. but that is secondary. So now we have a centralized, human UNreadable database covering so many subsystems that it is constantly being updated and written to by the system. We require a UI and API to access this 'registry', and the result is that we force subsystems that would otherwise never have any visibility into each others physical data store to now have (A) visibility (e.g. it makes it much easier for a third party program to do 'bad' things to the system... like netscape overwriting IE's registry parameters and vise-versa), and (B) potentially effect another subsystem's operational nature by corrupting the repository, or crashing at just the wrong time, or simply be making the registry an incredibly dangerous place to be due to making constant updates to it. One screw up and it isn't just the subsystem that screwed up that blows up, its the entire system. And this isn't even getting into what happens if a registry-bound dataset for a particular system configuration winds up having to be huge .. say a password file with 50000 users in it. The word 'stupid' doesn't even begin to describe it. So not only is a registry nothing like rc.conf, but for the purposes a registry would be intended the only plus side is having a single API for "everything under the sun" configuration elements and the many negative sides include potential scaleability issues, potential "crash and burn the entire system" issues, potential improper use by one program of another program's configuration elements, the necessity (since a registry is by concept a R+W entity) to add additional complexity to maintain the UNIX security model for use, and if I spent another 5 minutes thinking about it I can probably come up with a dozen other downsides. A single registry in the context of general use in FreeBSD to consolidate the configuration data for many unrelated programs is, simply put, an extremely stupid idea. Now, obviously, we are talking about a registry in a specific context... a registry managing UNIX based programs. And, specifically, FreeBSD. Obviously there are other uses for a registry like entity that aren't 'stupid'. There are many other cool uses for a registry like entity... just none when you take it in the context of tring to consolodate all the configuration info used by programs that run under FreeBSD. -Matt 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?200102250208.f1P28VC10795>