savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-hackers-public] Re: autoredirect for savannah downloads


From: Yavor Doganov
Subject: Re: [Savannah-hackers-public] Re: autoredirect for savannah downloads
Date: Sat, 01 Nov 2008 01:23:21 +0200
User-agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/22.3 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

Karl Berry wrote:
> 
> No, we certainly don't want to redirect the ftp.gnu.org name itself.

OK, I haven't thought about that aspect.  Entirely reasonable and
understandable.

>     to actually redirect to the _fastest_ nearest mirror.
> 
> What's done now is the best that can be done, as far as I know.
> Do you have something else in mind?

Not really, but something similar was done in some Debian package --
to determine which mirror is "best" from your location (of course the
"location" is not permanent in some cases, which is why you could run
a certain command to reconfigure your sources.list).  (I don't
remember the name of the package and never used it, sorry.)

I believe it's not that hard to figure out what is the fastest mirror
from a given predetermined list, although this approach is likely to
be entirely unsuitable for the task we're talking about.

> It's not like there is some global network topology table that has
> traceroutes for every computer on the Internet!

Sure there isn't.  But the "regional" flow is no longer relevant;
e.g. the major ISPs in my country connect directly to France, Belgium
and Austria or maybe the US, or satellites.  It does not make sense
for me to download GCompris from Greece, it is 3 times faster if I
download it from Japan, say.  (Of course, I'll happilly do it, I don't
care at all about the speed, personally.)

> that distro X will think that the new version of package foo has
> disappeared

Don't worry about that: no distro tools are so insane or so poorly
written to the extent that they could not possibly identify such a
case.  In this scenario, such a tool will give a false positive (if
the job is run more frequently) that eventually the maintainer will
ignore.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]