Date: Mon, 15 May 2006 10:35:32 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Adrian Pavone" <wingot@eftel.com> Cc: Chris <chrcoluk@gmail.com>, fbsd@a1poweruser.com, ports@freebsd.org, "freebsd-questions@FreeBSD. ORG" <freebsd-questions@freebsd.org>, Spadge <spadge@fromley.net> Subject: Re: Has the port collection become to large to handle. Message-ID: <00d401c67802$ed3be130$b3db87d4@multiplay.co.uk> References: <446786CF.6050807@fromley.net><MIEPLLIBMLEEABPDBIEGGEALHHAA.fbsd@a1poweruser.com> <3aaaa3a0605141906k2622e9dawe7e9bf7def72167@mail.gmail.com> <008b01c677fb$c99b4290$b3db87d4@multiplay.co.uk> <44684361.5080903@eftel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Pavone wrote: > Steven Hartland wrote: > This is why there are options in place that would allow you to > download the cvsup to one of you computers, likely a server of some > sort, and your other computers all retrieve the CVSup from this local > server, significantly speeding up the retrieval time and decreasing > the load on the primary servers, a win for everyone. If you have > computers of varying architectures or in seperated geographical > locations this would not work as worded, but from your wording it > sounded like you had a local LAN of computers. You couldnt be more wrong there even though the cvsup source might as well be on the local LAN we have such a quick connection to it. The shear volume of files that have to be checked adds a significant amount of time to any method to syncing them, from cvsup local rsync to tar I've tried them all. > Ohh, and for your informations, statistics do lie, that is the point > of statistical analysis, which I spent 1 1/2 years of my life studying > before changing into my current Software Engineering/Computer Security > degree. Your just being pedantic, you know quite well what was ment. > And, the arguements would arise from the "common" ports/packages > directory, a suggestion of fbsd's I believe, whereby common ports that > would not be built often primarily due to their size, and so wouldn't > show up in statistics (such as Gnome, KDE, OpenOffice, and a number of > others), would be placed into a common directory of the ports/packages > tree, and would be exempt from these statistics. The arguements would > arise over what should be placed into this "common" directory. The suggestion was capable of registering either when installed by ports or packages so a mute point. > And what about the case of a port that would be built many times over > its lifetime, mainly due to program version changes? The first one > that springs to mind would be Firefox. Firefox has had a number of > version changes in the same space of time that Exim, a very commonly > used mail server application, has been updated, and assuming an even > distribution of mail servers and desktop users with firefox, firefox > would appear to be 10-20 times more active over it's lifetime. And your point being? > It is also common for people with a desktop computer to format their > HDD every 3 months or so, and every time this occured, the desktop PC > ports (Xorg, Firefox, KDE/XFCE/GNOME, OpenOffice.org, etc.) would get > a rebuild/redownload, again throwing the stastics out of whack. No its still being used isnt it which is what we are interested in. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00d401c67802$ed3be130$b3db87d4>