From owner-freebsd-current Thu Sep 5 10:29:52 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04096 for current-outgoing; Thu, 5 Sep 1996 10:29:52 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA04084 for ; Thu, 5 Sep 1996 10:29:50 -0700 (PDT) Received: from vector.jhs.no_domain (slip139-92-42-139.ut.nl.ibm.net [139.92.42.139]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id JAA19642 ; Thu, 5 Sep 1996 09:28:00 -0700 (PDT) Received: (from root@localhost) by vector.jhs.no_domain (8.7.5/8.6.9) id SAA13786; Thu, 5 Sep 1996 18:27:42 +0200 (MET DST) Date: Thu, 5 Sep 1996 18:27:42 +0200 (MET DST) From: "Julian Stacey jhs@freebsd.org" Message-Id: <199609051627.SAA13786@vector.jhs.no_domain> To: John Polstra cc: current@freebsd.org Subject: Re: Latest Current build failure Reply-To: "Julian H. Stacey" Organization: Vector Systems Ltd. Mailer: EXMH 1.6.7, PGP available X-Address: Holz Strasse 27d, 80469 Munich, Germany X-Phone: +49.89.268616 X-Fax: +49.89.2608126 X-Web: http://www.freebsd.org/~jhs/ In-reply-to: Your message of "Wed, 04 Sep 1996 09:58:30 PDT." <199609041658.JAA18063@austin.polstra.com> Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Reference: > From: John Polstra > > Julian Stacey : > > >CTM is asynchronous to net disturbances, so ideal for those with > > >poor net access, whereas cvsup requires a net in good condition. > > Justin Gibbs : > > This isn't true since CVSup is a streaming protocol instead of a > > synchronous like SUP. I know quite a few people who switched from > > CTM to CVSup that have poor links to the net. > > Justin is right. CVSup works very well under poor network conditions. Off topic for a moment, & meaning no one specificaly, but all of us, self included :-) .... It should not matter _who_ is right, or _who_ is wrong, it should matters _what_ is right, & _what_ is wrong. To attack, defend & build on ideas is constructive, To attack personalities advocating ideas, is divisive. An unskilled person can come up with an occasional great idea, just as a skilled person can come up with a daft idea. Ideas should be judged on merit, not by proponent & opponent personalities. FreeBSD lists far too often contain personality oriented conflicts, rather than idea oriented conflicts, which is a liability, & gives a bad image. --------- John, The key to this thread is Semantics ! What I said: poor net access What you said: under poor network conditions CVSup presumably functions well: With the _subset_ of poor network connectivity comprising: low speed & latency. With these advantages: streaming protocol, [& optimised for CVS transfer, I recall]. Subject to the constraints: - user is allowed to port, compile, & run cvsup on client host - client has room for source tree (presumed pre-requisite) - no firewall in the way - every node is up & running between client & server at the time when client wants to update (sup, cvsup,mirror,rdist etc all intrinsicaly rely on being able to establish an end to end virtual circuit) CTM performs well: With the subset of poor network connectivity comprising: Intermittent drop out of parts of net, end to end links either unavailable or appallingly slow. With these advantages: - mail can be forwarded to a local high bandwidth host while the recipient sleeps. - recipient can receive patches on a non FreeBSD mainframe, - CTMs can be carried home on a floppy - recipient needs no room on work machine for src/ or cvs/ - tcp/ip firewalls irrelevant, if mail works, it's enough. > That was one of the primary design goals. In fact, CVSup almost > certainly works better under adverse conditions than SMTP, which > delivers your CTM updates. But for anyone using a local proximity mail server: CTM merely requires your are connected for mail sometime or other most days. CVSup needs a permanent virtual circuit to be established end to end, between CVSup server & client, exactly when you want to update. CVSup cannot deliver more bandwidth than the ISP can deliver, which sometimes isnt very fast at all, when running protocols through the net to remote hosts, whereas the ISP can often offer to saturate the local modem, to 100% efficiency, if the CTM mail is stored localy. > Julian, have you even _tried_ CVSup?? I watch the server logs pretty > closely, and I don't recall seeing your name in them. Irrelevant. > But if you're going to comment publically on either CVSup or CTM, > you really ought to know what you're talking about first. Posted flame bait endangers a list's S/N ratio. I'll ignore it. > It's not in anybody's interest to start a "CVSup vs. CTM" war. They > each have advantages and disadvantages. People are welcome to use the > one that serves their needs the best. Agreed. I merely corrected Justin's incomplete assertion of where CVSup would be beneficial, by pointing to situations where no end to end protocol could cope, no matter how marvelous the protocol, & where one would have no choice but a store & forward mail method. (As before, Justin's understanding of `poor net connectivity' is presumably rather different to mine, hence our different conclusions.) Construe that as criticism of CVSup if you wish, but it's not my intention. >From what I've read CVSup seems attractive, & intend to use it, where appropriate. What some USA residents consider `poor net connectivity', some other net citizens would consider a luxury, and if you don't happen to know or remember how tenuous & bad `poor net connectivity' can get, consider yourself lucky :-) Julian -- Julian H. Stacey jhs@freebsd.org http://www.freebsd.org/~jhs/