Date: Wed, 7 Mar 2001 18:04:32 -0600 From: Mike Meyer <mwm@mired.org> To: Robert Clark <res03db2@gte.net> Cc: Mike Meyer <mwm@mired.org>, Wes Peters <wes@softweyr.com>, Terry Lambert <tlambert@primenet.com>, rjesup@wgate.com, Matt Dillon <dillon@earth.backplane.com>, Alfred Perlstein <bright@wintelcom.net>, josb@cncdsl.com, chat@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <15014.52368.698752.617802@guru.mired.org> In-Reply-To: <20010307074113.A47638@darkstar.gte.net> References: <200103062353.QAA02845@usr05.primenet.com> <3AA5DB60.86A5C03D@softweyr.com> <15013.64644.204157.422558@guru.mired.org> <20010307074113.A47638@darkstar.gte.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Clark <res03db2@gte.net> types: > On Wed, Mar 07, 2001 at 03:16:52AM -0600, Mike Meyer wrote: > > Wes Peters <wes@softweyr.com> types: > > > Terry Lambert wrote: > > > > I don't see text files as being any safer than binary, except in > > > > the case of human recovery in the absence of a backup. > > > That was precisely the point. > > I think you've both missed the point. The preference for text files as > > opposed to binary files is not simply that they can be restored to the > > original state (one meaning of "recover") by a knowledgeable human, > > but that the knowledge a human scanning them needs to extract useful > > information (another meaning of "recover") is much lower than for > > binary file formats. > > The point is that text files make it much easier to get a corrupt > > system to the point of being able to restore your backup *without* > > having reinstall the OS or chase down a second boot disk. It's not > > safer - it's just faster to fix. > I did not intend to do away with text files. If an API for dealing > with configuration would lead to different program's configurations > being expressed in the same syntax. Yeah, I'm aware that I'm really replying to Ted, and that the issue of the API and the encoding are orthogonal. But I felt that this point needed to be covered. > If that API happened to allow a choice of either flat files, or some > kind of database, that would be fine with me. Actually, I was thinking that it might make sense for the API to either allow the caller to specify a format, or to autosense it. That way, you could use something like termcap like files where it's appropriate, something like rc.conf where that's appropriate, or even binary if it was appropriate, and the prograns don't need to know about it. > The scenario I'm dealing with, is that I've just recently installed > a newer version of FreeBSD onto one of the HDs in my system. I've put > perhaps a hundred keystrokes towards this install. But if I were to have > to start over, I'd have to do everything from scratch. > > If there were some way to track and keep configuration changes, on a > floppy for exampe, then I could theoretically redo that install by > putting the CD-ROM back in the drive, and using the configuration > changes from the floppy. Actually, I track configuration changes. One of the first things I do on a new system is install a perforce client, and start adding files to the depot. I recently downgraded a system from -current to -stable by reinstalling. Putting my configuration back consisted of "p4 sync -f", then tweaking things where they were different between the two systems. The only thing that was missed was the user cron files. Similarly, I install new systems by integrating the config files from the master system, and use perforce to update the slave systems from the master as needed. That's actually another reason for prefering text files - automated merge tools work *much* better on them! > Maybe something like this is desirable, maybe its inplausible, but > still I wonder. Oh, I'd say it's very desirable. However, unless you're using an external source code control system, it's not clear how useful it is as a backup mechanism. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15014.52368.698752.617802>