Date: Wed, 7 Mar 2001 07:41:13 -0800 From: Robert Clark <res03db2@gte.net> To: Mike Meyer <mwm@mired.org> Cc: 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: <20010307074113.A47638@darkstar.gte.net> In-Reply-To: <15013.64644.204157.422558@guru.mired.org>; from mwm@mired.org on Wed, Mar 07, 2001 at 03:16:52AM -0600 References: <200103062353.QAA02845@usr05.primenet.com> <3AA5DB60.86A5C03D@softweyr.com> <15013.64644.204157.422558@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the feedback. 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. If that API happened to allow a choice of either flat files, or some kind of database, that would be fine with me. > > > > I would argue that human recovery is not a useful scenario, even > > > in the absence of a backup. > > Which flies in the face of every system recovery ever attempted, including > > the one I got to do last week. Even if you just finished a full backup > > of the system when it crashed/got killed, some files may be out of date. > > Ted listed some conditions that make human recovery an unlikely > scenario, and it's also clearly possible to have a system where > everything lives in one or more binary config files. Doing so makes > human recovery less likely, and hence makes recovering from a problem > both longer and more painful. That makes it an inferior solution. > 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. Maybe something like this is desirable, maybe its inplausible, but still I wonder. > That said, I don't think there's anything wrong with binary files per > se. For anything that's potentially part of bringing a system to the > point of being able to do restores, you need statically linked tools > that live on / to view and edit those files, and those tools need to > be very robust in the face of possible corruption, or you need a very > robust repair mechanism. > > Text files trivially meet the first two criteria (cat and ed), and for > the last one they allow the most flexible file repair tools avaible to > be used for both scanning and repair. Since going to binary files is > going to cost something for all three of those points, it's got to > have some serious bennies attached to it. Like making "ls -l" a couple > of orders of magnitude faster. > > <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?20010307074113.A47638>