Date: 17 May 1996 09:23:53 -0500 From: "Richard Wackerbarth" <rkw@dataplex.net> To: "Chuck Robey" <chuckr@Glue.umd.edu> Cc: "FreeBSD Current" <freebsd-current@FreeBSD.org>, "FreeBSD Hackers" <hackers@FreeBSD.org> Subject: Re(2): Re(2): Standard Shipping Containers - A Proposal for Distributing FreeBSD Message-ID: <n1379797443.54035@Richard Wackerbarth>
next in thread | raw e-mail | index | archive | help
Chuck Robey writes: > No one would argue about upgrading ctm, but you seem to be making claims about both sup and ctm that don't apply to both. > You ask who cares about those not net-connected, but your own comments seem to betray a prejudice against those who ARE net-connected. How about caring for both? That's why there's TWO tools, not one. I think you are making only a shallow reading of my comments. 1) Both sup and ctm have their place in the update scheme. They can be made to complement each other. For regular updates, ctm places a lower burden on the servers. It does not send entire files when just the deltas will do. However, it relies on the concept that the tree is either read-only (as I think it should be) or that you have a mechanism to restore it before you move forward. Sup could be administered in such a manner that it provides the restoration procedure and the subsequent updates could then be done by ctm. 2) Right now both suffer for the lack of standardization and cross usage. Neither can convieniently utilize an up-to-date, or partly up-to-date, tree as a starting point. Ctm does better at this only because of the manual effort of the distributors. I'm not claiming that any method is always superior. However, I do claim that standardization would allow more flexibility. This, in turn, might encourage users to use techniques that, because of present limitations, seem unworkable except in the "best case". -- ...computers in the future may have only 1,000 vacuum tubes and weigh only 1/2 tons. -- Popular Mechanics, March 1949
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1379797443.54035>