Date: Wed, 7 Mar 2001 03:16:52 -0600 From: Mike Meyer <mwm@mired.org> To: Wes Peters <wes@softweyr.com> Cc: Terry Lambert <tlambert@primenet.com>, rjesup@wgate.com, Mike Meyer <mwm@mired.org>, Matt Dillon <dillon@earth.backplane.com>, Alfred Perlstein <bright@wintelcom.net>, josb@cncdsl.com, chat@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <15013.64644.204157.422558@guru.mired.org> In-Reply-To: <3AA5DB60.86A5C03D@softweyr.com> References: <200103062353.QAA02845@usr05.primenet.com> <3AA5DB60.86A5C03D@softweyr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. 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?15013.64644.204157.422558>