diff options
Diffstat (limited to 'zarb-ml/mageia-discuss/20110523/004338.html')
| -rw-r--r-- | zarb-ml/mageia-discuss/20110523/004338.html | 165 |
1 files changed, 165 insertions, 0 deletions
diff --git a/zarb-ml/mageia-discuss/20110523/004338.html b/zarb-ml/mageia-discuss/20110523/004338.html new file mode 100644 index 000000000..e0b353265 --- /dev/null +++ b/zarb-ml/mageia-discuss/20110523/004338.html @@ -0,0 +1,165 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-discuss] Easyurpmi forMageia ? + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Easyurpmi%20forMageia%20%3F&In-Reply-To=%3C1306103903.24450.50.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="004340.html"> + <LINK REL="Next" HREF="004342.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-discuss] Easyurpmi forMageia ?</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-discuss%40mageia.org?Subject=Re%3A%20%5BMageia-discuss%5D%20Easyurpmi%20forMageia%20%3F&In-Reply-To=%3C1306103903.24450.50.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-discuss] Easyurpmi forMageia ?">misc at zarb.org + </A><BR> + <I>Mon May 23 00:38:23 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="004340.html">[Mageia-discuss] Easyurpmi forMageia ? +</A></li> + <LI>Next message: <A HREF="004342.html">[Mageia-discuss] Easyurpmi forMageia ? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#4338">[ date ]</a> + <a href="thread.html#4338">[ thread ]</a> + <a href="subject.html#4338">[ subject ]</a> + <a href="author.html#4338">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le dimanche 22 mai 2011 à 10:21 +0200, Wolfgang Bornath a écrit : +><i> 2011/5/22 Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-discuss">misc at zarb.org</A>>: +</I>><i> > Le dimanche 22 mai 2011 à 05:51 +0200, Wolfgang Bornath a écrit : +</I>><i> >> I haven't used EasyUrpmi, but I used the other (similar) web tool +</I>><i> >> SmartUrpmi regularly. +</I>><i> >> +</I>><i> >> My reason was not to add PLF or any other repo (MUD or other). My main +</I>><i> >> reason was my dislike of the %MIRRORLIST system of Mandriva, you could +</I>><i> >> get connected to a very slow mirror or even to one which was not +</I>><i> >> uptodate without urpmi being able to switch to another mirror during +</I>><i> >> one session (a known bug). So I used SmartUrpmi to select a mirror +</I>><i> >> which I knew to be fast, reliable and uptodate instead of playing +</I>><i> >> lottery with %MIRRORLIST. +</I>><i> > +</I>><i> > There is likely stuff to improve with mirrorlist selection indeed ( I +</I>><i> > would add AS number to it, as well as bandwidth, and push a smarter +</I>><i> > system in urpmi one day to get nearer mirros, and add some weight based +</I>><i> > on network related stuff ), but since everybody work around it, no one +</I>><i> > is motivated to improve it or provides information for that. So because +</I>><i> > people able to fix focus on not facing the problem and because there is +</I>><i> > a know workaround, newer users face the problem. +</I>><i> +</I>><i> As soon as the %MIRRORLIST system +</I>><i> - checks the fastest mirror before using it +</I> +So far, no one gave a working system to find which one is the fastest +without a exhaustive test of all mirrors ( such a test would be quite +wasteful from my point of view, and quite irresponsible for people with +metered download ). And in fact, that's not what you likely want. You +want a mirror that is fast enough to be limited by your current network +connexion. If the ADSL connexion is full, that the mirror is giving 10 +or 100 mo directly to you doesn't matter much. + +Now, as I said, better system for selecting mirrors should be used. But +for that, we need to know : +1) what is the current system ( I think it is based on the geographical +position, which is a very very broad assumption, it help mostly to avoid +brasil people fetching stuff from europa and thing like that ) + +2) when did it gone wrong ( ie, the mirror that was selected and that +shouldn't, and why, and how could we discriminate for a user ) + +In fact, from a network point of view and given current peering +business, the fastest may not be the cheapest one for your isp, so +that's even harder ( cause they could do some throttling, etc ). + +Hence the suggestion of using AS numbers. +First check if a mirror is on the same network, then on the same AS, +then in the same country, then in the same timezone, then in the same +continent. It will likely make people in Antarctic unhappy. + + +><i> - checks the update status of the mirror before using it +</I>usually, for non cooker/cauldron, this is likely not a issue. Release is +frozen, at worst, you have a security update being late. + +And the current system should check more aggressively if the mirror is +up to date ( but it seems to not be the case at the moment since ibiblio +was late due to a change on their side ). + +On the other hand, we cannot force people to sync every 2h, and if a +tier2 mirror sync every day, it can quickly become out of the list +depending on the limit. If someone sync on a tier2 mirror that is +already late ( for some network related reason, like in australia where +the country is not that well connected to the rest of the world ), it +will also be more late, and that would be a bad side effect. + +Again, we need to have specific case of breakage to see how we could fix +anything, and more data on the mirrors to decide how and what to do, +what would be the impact, etc. + +><i> - switches to another mirror if the selected mirror is not reachable +</I>><i> or not uptodate +</I>I tried to fix that part, but unfortunately, the code is "suboptimal". +OTOH, using a manual mirror do not switch to a better mirror in case of +problem too ( IIRC ). + +><i> I will gladly forget all webtools and dedicated mirror selection. +</I>><i> (I remember writing almost the same at least 2 years ago in a same +</I>><i> discussion at Mandriva) +</I>><i> +</I>><i> > Worst, since people focus on specific mirrors ( d-c being the prime +</I>><i> > example ), the mirror slowly become more and more overloaded with +</I>><i> > requests, forcing admin of using complex scheme to divide the +</I>><i> > ressources. +</I>><i> +</I>><i> You can't avoid this. Users want to be connected to teh mirror which +</I>><i> provides the best service, you can't force them to use a slow mirror +</I>><i> just to protect better mirrors. +</I> + +We do not force them, they do by themself. If everybody use the same +mirror, sooner or later, the mirror become the slowest. Maybe sooner if +the admin is a trafic shaping master like Olivier. + +And after, we will see another mirror admin telling us "we removed the +tree because no one was using it" ( like switch.ch did for Mandriva ). + +So if this is what we want and repeat the same problems over and over +because we think we cannot fix users behavior, yes, let's do nothing. + +I think that the mirrors ecosystem also depend on the behavior of people +using it, and it is everybody responsibility to make sure it work fine. + +-- +Michael Scherer + +</PRE> + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="004340.html">[Mageia-discuss] Easyurpmi forMageia ? +</A></li> + <LI>Next message: <A HREF="004342.html">[Mageia-discuss] Easyurpmi forMageia ? +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#4338">[ date ]</a> + <a href="thread.html#4338">[ thread ]</a> + <a href="subject.html#4338">[ subject ]</a> + <a href="author.html#4338">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-discuss">More information about the Mageia-discuss +mailing list</a><br> +</body></html> |