Date: Sun, 08 Dec 1996 11:52:51 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: last in -current Message-ID: <5888.850074771@time.cdrom.com> In-Reply-To: Your message of "Sun, 08 Dec 1996 14:11:58 %2B0100." <199612081311.OAA23270@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> I basically like that idea. Do you already have a more detailed > imagination of the delta format (type field etc.)? Yeah, I'll write something up later on this afternoon and post it. I think there's even an old mail somewhere where I went into detail on what the headers would look like. :-) This isn't the first time this whole thing has come up, we just never seem to get beyond the discussion phase. :-( I'll see if I can do something more tangible this time. > > 1. All deltas have a consistent data format, sequence > > numbered, uuencoded, PGP signed and for the benefit of the > > migration tools (and easy sending through email). > > Hmmpf. Kill your government first. As long as we cannot provide PGP > as a binary drop-in, this is a moot point. Erm, no, it's really not. Even though pgp is something of a pain to install on both sides of the Atlantic, it's hardly an impossibility and tools like pgpmail are very popular over here, stupid government or no. Furthermore, even if the tools *ignore* the pgp signature, as they would in the case where no pgp program was found (and it would just print a short warning msg that they should install the pgp program if they want more assurance that what they're doing is legitimate), we still need to provide it for those people who really do care. That way we've also done our bit for security and if someone later ignores the warnings and gets screwed by someone putting a trojan-horsed set of upgrade patches up on a mirror FTP site somewhere (and these things are never a question of *if* so much as *when*), we can just shrug and say "you should have installed pgp, dude, we DID make provisions for this problem!" Right now, the best we can say is "uh, yeah, we don't know security from a rat's sphincter and there aren't even any provisions for verifying that the stuff came from us, sorry!" That doesn't quite sound as good, does it? :-) > I'm not yet convinced that this is always possible. Consider the wtmp > changes. The best you could probably do is keeping the previous wtmp > & Co files around in the reverse delta, but all system activity Yes, that is true, and keeping the old version of the file around (though possibly compressed) would sort of be the "last ditch" reverse delta for cases when nothing more elegant was possible. Better than nothing, as is: > records between the upgrade and the application of the reverse delta > will be lost upon applying the latter. Which at least allows you to go back to a working wtmp file, despite having lost some entries, if you decide that long usernames are a luxury you can't afford for some reason (say your favorite binary-only system accounting tool breaks, or something). It's not perfect, no, but again (as with the pgp stuff) it's a lot better than saying "no way of going backwards exists, sorry." The wtmp example doesn't perhaps lend itself as well to reverse-motion as many other types of deltas will, but I think it's still a very necessary feature, imperfections and all. > And, the reverse delta may become _really huge_, so the upgrade > procedure must offer several opportunities, like allowing to delete > the latest reverse delta from the hard disk, storing the reverse delta > on external media (tape, ZIP drive) without consuming much temp disk > space, or even not generating the reverse delta at all for those who > think they aren't interested in it. Absolutely, and these are all in the category of refinements I can see us adding in response to real-life concerns about the delta mechanism. For now, however, I think we're more likely to actually get a working framework written if we assume that disk space is cheap (and it is) and just code straight for functionality right now and use whatever resources we need to do that. There's always time to tie ribbons around it later. > Yep. Now, who's going to become FreeBSD's ``upgrade meister''? I'm willing to work with someone on specifying and coding this, but if I try to do it alone then we're also likely to wait another year for a solution. That's both a threat and a plea for help. :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5888.850074771>