On Mar 28, 2010, at 12:52 AM, Arthur Corliss wrote: > > :-) You'll have to pardon my indiscriminate epithets. The barbs are coming > from multiple directions. My point still stands, however. Your experience, > however worthy, has zero bearing on whether or not my experience is > just as worthy. Even moreso when you guys have zero clue who you're talking > to. And you shouldn't have to know. I would have thought simple communal > and professional courtesy would be extended and all points considered in > earnest. Which does not appear to be the case.
I'm not sending any barbs, only my reasonable opinion borne from years on the reality-based operations side of this equation. As for who you are, it doesn't matter as I work daily with those who wrote, and continue to write, large chunks of operating systems, X, etc., and though their legend may precede them when it comes to my having to implement what works fabulously in their imagination, I do my best to bring them back to the grim reality that is operations. It's a frequent problem of engineers and those of us stuck having to live with and fix their grand ideas. Lofty goals usually die somewhere between dreams and production. > Ah, you're one of them. All objects look like nails when all you have is a > hammer, eh? Rsync is a good tool, but like Perl, it isn't the perfect tool > for all tasks. You've obviously exceeded what the tool was designed for, > it's only logical to look for (or write) another tool. Ironically, what I'm > suggesting is so basic that rsync can be replaced by a script which will > likely run on every mirror out there with no more fuss than rsync. Well, you'll have to forgive those who mock your näivete as if it were so basic and trivial to replace rsync, it would have been done several times over by now as it's limitations are well known to all who use it on any large scale. However, it is a well-known, well-used, multi-platform and time-tested tool that will not be unseated very easily without good reason and a reason that reads something along the lines of improving performance on an archive that should have been trimmed back a bit is not a compelling reason for adoption. > What you're overlooking is that CPAN has, and will, continue to grow. Even > if you remove the cruft now at some point it might grow to the same size just > with fresh files. When that happens, you're right back where you are now. > Rsync can't cut it, it wasn't designed for this. And this is a good point to make, yes, it will continue to grow and I know that the current manager(s) of nic.funet.fi have commented on the burden it presents to the system which is also home to a number of other mirrors. You cannot assume that the generosity and the resources of the mirror ops are limitless and finding out where that limit lies will come too late to make amends. Pruning back the archive is a good compromise until and unless another solution can be done that will not bother the mirror ops terribly much in terms of real work. e.
