From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110112/002071.html | 68 +++++++++ zarb-ml/mageia-dev/20110112/002072.html | 77 ++++++++++ zarb-ml/mageia-dev/20110112/002073.html | 100 +++++++++++++ zarb-ml/mageia-dev/20110112/002074.html | 149 +++++++++++++++++++ zarb-ml/mageia-dev/20110112/002075.html | 69 +++++++++ zarb-ml/mageia-dev/20110112/002076.html | 83 +++++++++++ zarb-ml/mageia-dev/20110112/002077.html | 211 +++++++++++++++++++++++++++ zarb-ml/mageia-dev/20110112/002078.html | 67 +++++++++ zarb-ml/mageia-dev/20110112/002079.html | 79 ++++++++++ zarb-ml/mageia-dev/20110112/002080.html | 127 ++++++++++++++++ zarb-ml/mageia-dev/20110112/002081.html | 82 +++++++++++ zarb-ml/mageia-dev/20110112/002082.html | 96 ++++++++++++ zarb-ml/mageia-dev/20110112/002083.html | 125 ++++++++++++++++ zarb-ml/mageia-dev/20110112/002084.html | 84 +++++++++++ zarb-ml/mageia-dev/20110112/002085.html | 142 ++++++++++++++++++ zarb-ml/mageia-dev/20110112/002086.html | 78 ++++++++++ zarb-ml/mageia-dev/20110112/002087.html | 178 ++++++++++++++++++++++ zarb-ml/mageia-dev/20110112/002088.html | 150 +++++++++++++++++++ zarb-ml/mageia-dev/20110112/002089.html | 67 +++++++++ zarb-ml/mageia-dev/20110112/002090.html | 90 ++++++++++++ zarb-ml/mageia-dev/20110112/002091.html | 70 +++++++++ zarb-ml/mageia-dev/20110112/002092.html | 80 ++++++++++ zarb-ml/mageia-dev/20110112/002093.html | 59 ++++++++ zarb-ml/mageia-dev/20110112/002094.html | 73 ++++++++++ zarb-ml/mageia-dev/20110112/002095.html | 89 +++++++++++ zarb-ml/mageia-dev/20110112/002096.html | 93 ++++++++++++ zarb-ml/mageia-dev/20110112/002097.html | 74 ++++++++++ zarb-ml/mageia-dev/20110112/002098.html | 64 ++++++++ zarb-ml/mageia-dev/20110112/002099.html | 82 +++++++++++ zarb-ml/mageia-dev/20110112/author.html | 192 ++++++++++++++++++++++++ zarb-ml/mageia-dev/20110112/date.html | 192 ++++++++++++++++++++++++ zarb-ml/mageia-dev/20110112/index.html | 1 + zarb-ml/mageia-dev/20110112/subject.html | 192 ++++++++++++++++++++++++ zarb-ml/mageia-dev/20110112/thread.html | 243 +++++++++++++++++++++++++++++++ 34 files changed, 3626 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110112/002071.html create mode 100644 zarb-ml/mageia-dev/20110112/002072.html create mode 100644 zarb-ml/mageia-dev/20110112/002073.html create mode 100644 zarb-ml/mageia-dev/20110112/002074.html create mode 100644 zarb-ml/mageia-dev/20110112/002075.html create mode 100644 zarb-ml/mageia-dev/20110112/002076.html create mode 100644 zarb-ml/mageia-dev/20110112/002077.html create mode 100644 zarb-ml/mageia-dev/20110112/002078.html create mode 100644 zarb-ml/mageia-dev/20110112/002079.html create mode 100644 zarb-ml/mageia-dev/20110112/002080.html create mode 100644 zarb-ml/mageia-dev/20110112/002081.html create mode 100644 zarb-ml/mageia-dev/20110112/002082.html create mode 100644 zarb-ml/mageia-dev/20110112/002083.html create mode 100644 zarb-ml/mageia-dev/20110112/002084.html create mode 100644 zarb-ml/mageia-dev/20110112/002085.html create mode 100644 zarb-ml/mageia-dev/20110112/002086.html create mode 100644 zarb-ml/mageia-dev/20110112/002087.html create mode 100644 zarb-ml/mageia-dev/20110112/002088.html create mode 100644 zarb-ml/mageia-dev/20110112/002089.html create mode 100644 zarb-ml/mageia-dev/20110112/002090.html create mode 100644 zarb-ml/mageia-dev/20110112/002091.html create mode 100644 zarb-ml/mageia-dev/20110112/002092.html create mode 100644 zarb-ml/mageia-dev/20110112/002093.html create mode 100644 zarb-ml/mageia-dev/20110112/002094.html create mode 100644 zarb-ml/mageia-dev/20110112/002095.html create mode 100644 zarb-ml/mageia-dev/20110112/002096.html create mode 100644 zarb-ml/mageia-dev/20110112/002097.html create mode 100644 zarb-ml/mageia-dev/20110112/002098.html create mode 100644 zarb-ml/mageia-dev/20110112/002099.html create mode 100644 zarb-ml/mageia-dev/20110112/author.html create mode 100644 zarb-ml/mageia-dev/20110112/date.html create mode 120000 zarb-ml/mageia-dev/20110112/index.html create mode 100644 zarb-ml/mageia-dev/20110112/subject.html create mode 100644 zarb-ml/mageia-dev/20110112/thread.html (limited to 'zarb-ml/mageia-dev/20110112') diff --git a/zarb-ml/mageia-dev/20110112/002071.html b/zarb-ml/mageia-dev/20110112/002071.html new file mode 100644 index 000000000..7a31fbec6 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002071.html @@ -0,0 +1,68 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 12 00:12:44 CET 2011 +

+
+ +
Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+> hi all,
+> i have one question (maybe it can be a proposal): is it possible to implement 
+> the torrent protocol to faster download the updates of the distro? it could be 
+> an interesting features for the coming Mageia releases
+
+I think the issue of faster download could be simply taken care by
+having more mirror, or faster one.
+
+I had under the impression that some ISP throttle down bittorrent, and
+that it may not be very nat and firewall friendly..
+-- 
+Michael Scherer
+
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002072.html b/zarb-ml/mageia-dev/20110112/002072.html new file mode 100644 index 000000000..4b0ac8896 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002072.html @@ -0,0 +1,77 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Per Øyvind Karlsen + peroyvind at mandriva.org +
+ Wed Jan 12 00:45:35 CET 2011 +

+
+ +
2011/1/12 Michael Scherer <misc at zarb.org>:
+> Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+>> hi all,
+>> i have one question (maybe it can be a proposal): is it possible to implement
+>> the torrent protocol to faster download the updates of the distro? it could be
+>> an interesting features for the coming Mageia releases
+>
+> I think the issue of faster download could be simply taken care by
+> having more mirror, or faster one.
+>
+> I had under the impression that some ISP throttle down bittorrent, and
+> that it may not be very nat and firewall friendly..
+
+aria2 amongst others has bittorrent support though, so metalinks with
+ftp/http/++ mirrors together with torrents could help combine them all
+together. :)
+
+--
+Regards,
+Per Øyvind
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002073.html b/zarb-ml/mageia-dev/20110112/002073.html new file mode 100644 index 000000000..6f1c57115 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002073.html @@ -0,0 +1,100 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ andre999 + andr55 at laposte.net +
+ Wed Jan 12 03:45:42 CET 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+>> hi all,
+>> i have one question (maybe it can be a proposal): is it possible to implement
+>> the torrent protocol to faster download the updates of the distro? it could be
+>> an interesting features for the coming Mageia releases
+>
+> I think the issue of faster download could be simply taken care by
+> having more mirror, or faster one.
+>
+> I had under the impression that some ISP throttle down bittorrent, and
+> that it may not be very nat and firewall friendly..
+
+Some suggestions for faster downloads without bittorrent.
+1) use aria2c (or a similar application), which uses multiple 
+connections, defaulting to 5, and allows multiple mirrors.
+By default it starts by allocating space for the file to be downloaded, 
+which allows non-sequential downloading of the file, facilitating faster 
+downloading from multiple sites.
+
+2) use mirrors which allow multiple connexions.
+(Of course, with download software that takes advantage of this.)
+
+3) use multiple mirrors.
+(Again, according to download software.)
+
+4) use ftp instead of http
+
+5) use closer mirrors.  (less delay in handshaking, etc.)
+
+In my case, using aria2c with 2 mirrors and the default 5 connexions is 
+at least 3 times as fast as a single connexion (to my closest mirror).
+And a much greater improvement over other download options I've tried.
+
+I also have configured rpmdrake to use aria2c -- it seems to give me 
+faster and more reliable updating, but I don't have any figures.
+
+aria2c is a console app, but it works well enough for me that I haven't 
+(yet) bothered to install the available GUI frontend.
+
+-- 
+André
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002074.html b/zarb-ml/mageia-dev/20110112/002074.html new file mode 100644 index 000000000..178ab6889 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002074.html @@ -0,0 +1,149 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 12 04:29:43 CET 2011 +

+
+ +
Le mardi 11 janvier 2011 à 21:45 -0500, andre999 a écrit :
+> Michael Scherer a écrit :
+> >
+> > Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+> >> hi all,
+> >> i have one question (maybe it can be a proposal): is it possible to implement
+> >> the torrent protocol to faster download the updates of the distro? it could be
+> >> an interesting features for the coming Mageia releases
+> >
+> > I think the issue of faster download could be simply taken care by
+> > having more mirror, or faster one.
+> >
+> > I had under the impression that some ISP throttle down bittorrent, and
+> > that it may not be very nat and firewall friendly..
+> 
+> Some suggestions for faster downloads without bittorrent.
+> 1) use aria2c (or a similar application), which uses multiple 
+> connections, defaulting to 5, and allows multiple mirrors.
+> By default it starts by allocating space for the file to be downloaded, 
+> which allows non-sequential downloading of the file, facilitating faster 
+> downloading from multiple sites.
+> 
+> 2) use mirrors which allow multiple connexions.
+> (Of course, with download software that takes advantage of this.)
+> 
+> 3) use multiple mirrors.
+> (Again, according to download software.)
+
+Theses 3 suggestions basically put X time the load of the mirror for
+each client. ( or on more mirror, for that matters ).
+
+And that's quite bad from the point of view of a mirror manager.
+
+For example, distrib-coffee could blacklist you if you do this, if you
+are not alone on your network connexion. And when we deployed this
+measure to protect the server, the limit was 2 connexion per address,
+since this was taking too much ressources on the old server ( each http
+request taking 1 process and so memory ). Hopefully, the hardware was
+upgraded but not everybody can afford 32g of ram and 8*2 ghz CPU. 
+
+[root at distrib-coffee ~]# grep -B 6 -A 3
+MaxConnPerIP  /etc/httpd/conf.d/distrib-coffee.conf
+
+<Directory /var/ftp/pub>
+   order allow,deny
+   Allow from all
+   Options +Indexes +MultiViews +SymLinksIfOwnerMatch
+   <IfModule mod_limitipconn.c>
+       MaxConnPerIP 5
+       ErrorDocument 503 "5 connections at the same time only allowed."
+   </IfModule>
+</Directory>
+
+So I think pissing off mirror maintainers is likely the wrong way of
+solving the problem ( who was not properly explained nor looked at
+besides "it should be faster" ).
+
+> 4) use ftp instead of http
+
+Based on ?
+
+If this is based on using d-c, again, that's our custom QOS rules. If
+this is because of throttling on your provider, not everybody have the
+same provider, and so the same throttling.
+The only difference between http and ftp is that ftp server will likely
+scale better server side. But that should have no impact on file serving
+and download ( both nowadays use fast syscall, such as sendfile, etc ).
+
+> 5) use closer mirrors.  (less delay in handshaking, etc.)
+
+I think tcp handshake is not much a problem, given the fact it happen
+once per rpm, compared to the number of tcp packet for the rest of the
+download. Use wireshark to see. 
+
+
+> In my case, using aria2c with 2 mirrors and the default 5 connexions is 
+> at least 3 times as fast as a single connexion (to my closest mirror).
+> And a much greater improvement over other download options I've tried.
+> 
+> I also have configured rpmdrake to use aria2c -- it seems to give me 
+> faster and more reliable updating, but I don't have any figures.
+> 
+> aria2c is a console app, but it works well enough for me that I haven't 
+> (yet) bothered to install the available GUI frontend.
+
+That's because it worked in your case that it would work for every
+possible case, especially without giving a proper analysis of the issue
+on your side.
+
+-- 
+Michael Scherer
+
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002075.html b/zarb-ml/mageia-dev/20110112/002075.html new file mode 100644 index 000000000..f98bd12f8 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002075.html @@ -0,0 +1,69 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Thierry Vignaud + thierry.vignaud at gmail.com +
+ Wed Jan 12 08:05:30 CET 2011 +

+
+ +
On 12 January 2011 04:29, Michael Scherer <misc at zarb.org> wrote:
+> For example, distrib-coffee could blacklist you if you do this, if you
+> are not alone on your network connexion. And when we deployed this
+> measure to protect the server, the limit was 2 connexion per address,
+> since this was taking too much ressources on the old server ( each http
+> request taking 1 process and so memory ).
+
+switching to nginx would help that
+
+> Hopefully, the hardware was
+> upgraded but not everybody can afford 32g of ram and 8*2 ghz CPU.
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002076.html b/zarb-ml/mageia-dev/20110112/002076.html new file mode 100644 index 000000000..c4506e603 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002076.html @@ -0,0 +1,83 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Romain d'Alverny + rdalverny at gmail.com +
+ Wed Jan 12 09:43:13 CET 2011 +

+
+ +
On Wed, Jan 12, 2011 at 04:29, Michael Scherer <misc at zarb.org> wrote:
+> Le mardi 11 janvier 2011 à 21:45 -0500, andre999 a écrit :
+>> Some suggestions for faster downloads without bittorrent.
+>> 1) use aria2c (or a similar application), which uses multiple
+>> connections, defaulting to 5, and allows multiple mirrors.
+>> By default it starts by allocating space for the file to be downloaded,
+>> which allows non-sequential downloading of the file, facilitating faster
+>> downloading from multiple sites.
+>>
+>> 2) use mirrors which allow multiple connexions.
+>> (Of course, with download software that takes advantage of this.)
+>>
+>> 3) use multiple mirrors.
+>> (Again, according to download software.)
+>
+> Theses 3 suggestions basically put X time the load of the mirror for
+> each client. ( or on more mirror, for that matters ).
+
+However, if 1) was to open 5 connections on 5 distinct servers, that
+would make more sense, no?
+
+But then I'm not sure there is so much more value than using a P2P protocol.
+
+Romain
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002077.html b/zarb-ml/mageia-dev/20110112/002077.html new file mode 100644 index 000000000..200ff664e --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002077.html @@ -0,0 +1,211 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ andre999 + andr55 at laposte.net +
+ Wed Jan 12 09:57:24 CET 2011 +

+
+ +
Michael Scherer a écrit :
+>
+> Le mardi 11 janvier 2011 à 21:45 -0500, andre999 a écrit :
+>> Michael Scherer a écrit :
+>>>
+>>> Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+>>>> hi all,
+>>>> i have one question (maybe it can be a proposal): is it possible to implement
+>>>> the torrent protocol to faster download the updates of the distro? it could be
+>>>> an interesting features for the coming Mageia releases
+>>>
+>>> I think the issue of faster download could be simply taken care by
+>>> having more mirror, or faster one.
+>>>
+>>> I had under the impression that some ISP throttle down bittorrent, and
+>>> that it may not be very nat and firewall friendly..
+>>
+>> Some suggestions for faster downloads without bittorrent.
+>> 1) use aria2c (or a similar application), which uses multiple
+>> connections, defaulting to 5, and allows multiple mirrors.
+>> By default it starts by allocating space for the file to be downloaded,
+>> which allows non-sequential downloading of the file, facilitating faster
+>> downloading from multiple sites.
+>>
+>> 2) use mirrors which allow multiple connexions.
+>> (Of course, with download software that takes advantage of this.)
+>>
+>> 3) use multiple mirrors.
+>> (Again, according to download software.)
+>
+> Theses 3 suggestions basically put X time the load of the mirror for
+> each client. ( or on more mirror, for that matters ).
+>
+> And that's quite bad from the point of view of a mirror manager.
+
+Why would it make _any_ difference to the mirrors ?
+Besides spreading the download over multiple mirrors.
+We download the same amount of data from the mirrors in any case.
+So we want to accelerate the download.  Some mirrors might want to 
+throttle the download, or limit the connexions, to spread the download 
+over a longer period of time, and they still can.
+This approach just works around such limitations for the end user.
+
+BTW, aria2c monitors the download speed, to choose the faster mirrors 
+for multiple connexions.  (From the urls put on the command line.)
+
+> For example, distrib-coffee could blacklist you if you do this, if you
+> are not alone on your network connexion. And when we deployed this
+> measure to protect the server, the limit was 2 connexion per address,
+> since this was taking too much ressources on the old server ( each http
+> request taking 1 process and so memory ). Hopefully, the hardware was
+> upgraded but not everybody can afford 32g of ram and 8*2 ghz CPU.
+
+Such restrictions are perfectly legitimate for a mirror.
+
+> [root at distrib-coffee ~]# grep -B 6 -A 3
+> MaxConnPerIP  /etc/httpd/conf.d/distrib-coffee.conf
+>
+> <Directory /var/ftp/pub>
+>     order allow,deny
+>     Allow from all
+>     Options +Indexes +MultiViews +SymLinksIfOwnerMatch
+>     <IfModule mod_limitipconn.c>
+>         MaxConnPerIP 5
+>         ErrorDocument 503 "5 connections at the same time only allowed."
+>     </IfModule>
+> </Directory>
+>
+> So I think pissing off mirror maintainers is likely the wrong way of
+> solving the problem ( who was not properly explained nor looked at
+> besides "it should be faster" ).
+
+Again, the same amount of data is downloaded collectively from the 
+mirrors used.
+And I agree totally with mirrors using whatever download speed controls 
+they wish.  (It is strongly advisable for mirrors with limited resources 
+to put such controls in place.)
+Just as downloaders are free to work within the limits of such controls 
+to their advantage.
+
+>> 4) use ftp instead of http
+>
+> Based on ?
+
+My experience.  Most downloads are noticeably faster downloading larger 
+files via ftp.  (Not just Mandriva downloads by any means.)
+And not just my current provider, either.  I use a very fast internet 
+access for most of my ISO downloads.  (The local library.)
+
+> If this is based on using d-c, again, that's our custom QOS rules. If
+> this is because of throttling on your provider, not everybody have the
+> same provider, and so the same throttling.
+> The only difference between http and ftp is that ftp server will likely
+> scale better server side.
+
+An explanation ...
+And maybe at least some http servers don't allow out-of-order packet 
+requests ?
+
+>> 5) use closer mirrors.  (less delay in handshaking, etc.)
+>
+> I think tcp handshake is not much a problem, given the fact it happen
+> once per rpm, compared to the number of tcp packet for the rest of the
+> download. Use wireshark to see.
+
+Again based on my experience.
+BTW, this is mostly ISOs, since the download time of smaller files -- 
+like typical .rpms -- is relatively fast.
+Isn't there some sort of handshaking and verification by tcp packet ?
+Also propagation time in the event of errors should explain at least 
+part of the difference.
+
+I could have added download to the fastest disk available, but that 
+seemed obvious.  (e.g. one could download to a usb disk, but that would 
+be painfully slow, unless one has a usb3 disk on a usb3 port.)
+
+>> In my case, using aria2c with 2 mirrors and the default 5 connexions is
+>> at least 3 times as fast as a single connexion (to my closest mirror).
+>> And a much greater improvement over other download options I've tried.
+>>
+>> I also have configured rpmdrake to use aria2c -- it seems to give me
+>> faster and more reliable updating, but I don't have any figures.
+>>
+>> aria2c is a console app, but it works well enough for me that I haven't
+>> (yet) bothered to install the available GUI frontend.
+>
+> That's because it worked in your case that it would work for every
+> possible case, especially without giving a proper analysis of the issue
+> on your side.
+
+True.  "Suggestions" based on my experience, in response to a request 
+for faster downloads.
+My figures were based on the same very fast internet access point (the 
+same evening, in fact), so the differences have to be attributed server 
+side.  The ratio was actually about 3.5 : 1 (according to aria2c).  The 
+closest mirror allows only 1 connexion.  Tests in the past have shown 
+that other mirrors (not much further) have about the same speed for a 
+single connexion.  But they allow multiple connexions, which is the 
+default for aria2c.
+In case you haven't used aria2c, it prints the download speed with the 
+estimated finishing time and current number of connexions, once every 
+minute.  (In this comparison, the number of connexions fluctuated 
+between 4 and 5.)
+
+Agreed, I could have provided more suppositions as to why.
+
+Regards :)
+
+-- 
+André
+
+ + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002078.html b/zarb-ml/mageia-dev/20110112/002078.html new file mode 100644 index 000000000..408f50d43 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002078.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jan 12 10:19:51 CET 2011 +

+
+ +
> aria2 amongst others has bittorrent support though, so metalinks with
+> ftp/http/++ mirrors together with torrents could help combine them all
+> together. :)
+Well choosing the best one following a given (configurable) criteria is 
+good idea, i believe :)
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20110112/9ab33e8c/attachment.asc>
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002079.html b/zarb-ml/mageia-dev/20110112/002079.html new file mode 100644 index 000000000..47f14dce1 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002079.html @@ -0,0 +1,79 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Angelo Naselli + anaselli at linux.it +
+ Wed Jan 12 10:18:24 CET 2011 +

+
+ +
mercoledì 12 gennaio 2011 alle 00:12, Michael Scherer ha scritto:
+> I had under the impression that some ISP throttle down bittorrent
+Yes. In Italy it's a common use. Since the most usage of it
+is for... well we all know that... They think all the traffic
+is for that, and they cut the band in any case despite of
+what we're really download...
+
+Angelo
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 198 bytes
+Desc: This is a digitally signed message part.
+URL: </pipermail/mageia-dev/attachments/20110112/e25934b7/attachment.asc>
+
+ + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002080.html b/zarb-ml/mageia-dev/20110112/002080.html new file mode 100644 index 000000000..754c7071d --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002080.html @@ -0,0 +1,127 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ andre999 + andr55 at laposte.net +
+ Wed Jan 12 11:06:10 CET 2011 +

+
+ +
Romain d'Alverny a écrit :
+>
+> On Wed, Jan 12, 2011 at 04:29, Michael Scherer<misc at zarb.org>  wrote:
+>> Le mardi 11 janvier 2011 à 21:45 -0500, andre999 a écrit :
+>>> Some suggestions for faster downloads without bittorrent.
+>>> 1) use aria2c (or a similar application), which uses multiple
+>>> connections, defaulting to 5, and allows multiple mirrors.
+>>> By default it starts by allocating space for the file to be downloaded,
+>>> which allows non-sequential downloading of the file, facilitating faster
+>>> downloading from multiple sites.
+>>>
+>>> 2) use mirrors which allow multiple connexions.
+>>> (Of course, with download software that takes advantage of this.)
+>>>
+>>> 3) use multiple mirrors.
+>>> (Again, according to download software.)
+>>
+>> Theses 3 suggestions basically put X time the load of the mirror for
+>> each client. ( or on more mirror, for that matters ).
+>
+> However, if 1) was to open 5 connections on 5 distinct servers, that
+> would make more sense, no?
+
+Right.
+Another way to look at the question :
+If 1000 people are downloading from mirrors allowing a total of 2000 
+connexions, if no-one uses multiple connexions, then 1000 connexions are 
+wasted.  These unused connexions would likely be from faster mirrors.
+
+The advantage of an application like aria2c, is that it detects 
+automatically the speed of whatever the connexions are available from 
+the urls (mirrors) specified, and chooses the fastest connexions.
+Thus downloading at an optimal speed for the user.
+At the same time, it makes the best use of the resources available, 
+since the slowest connexions won't be used.  Thus relieving slower mirrors.
+(Considering direct downloads, not options like P2P.)
+Of course each user will have their own set of fastest connexions, 
+depending on their location.  A user in Australia would have different 
+connexions from someone in France, or here in Canada.
+So in my view, the approach of aria2c is a win/win for both users and 
+mirrors.
+
+With aria2c, 3 mirrors which support a total of 5 connexions gives me 
+optimal speed.  (The limit being the speed of my computer.)
+
+> But then I'm not sure there is so much more value than using a P2P protocol.
+
+P2P is great if one has (essentially) unlimited bandwidth, and many 
+others are downloading at more or less the same time, and accessible to 
+the Internet when you are downloading.
+And it does relieve bandwidth from the mirrors.
+
+But it's not as good for bandwidth limited users (which included many of 
+us), or those downloading at a time when not many corresponding P2P 
+downloaders are available.
+(I knew someone who had a surprise 100$ plus surcharge due to P2P 
+uploading, before understanding the bandwidth usage factor.)
+
+An aria2c type solution doesn't require any cooperation from mirrors. 
+Although resource-limited mirrors should protect themselves from this 
+approach, to remain readily accessible.
+I'm not sure what is required (from Mageia) for P2P, but it could be 
+worth considering.
+
+another 2 cents :)
+
+> Romain
+
+-- 
+André
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002081.html b/zarb-ml/mageia-dev/20110112/002081.html new file mode 100644 index 000000000..beb7d87e3 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002081.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ andre999 + andr55 at laposte.net +
+ Wed Jan 12 11:14:22 CET 2011 +

+
+ +
Angelo Naselli a écrit :
+> mercoledì 12 gennaio 2011 alle 00:12, Michael Scherer ha scritto:
+>> I had under the impression that some ISP throttle down bittorrent
+> Yes. In Italy it's a common use. Since the most usage of it
+> is for... well we all know that... They think all the traffic
+> is for that, and they cut the band in any case despite of
+> what we're really download...
+>
+> Angelo
+
+Bell Canada does that too -- but only to give priority to other users.
+(So in non-peak times there is no limitation.)
+They used the reputed usage, among other arguments, to get 
+precedent-setting approval from regulatory authorities.
+(They serve maybe half of Canadian users.)
+A number of smaller internet providers have followed suit.
+
+-- 
+André
+
+ + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002082.html b/zarb-ml/mageia-dev/20110112/002082.html new file mode 100644 index 000000000..d31752f6c --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002082.html @@ -0,0 +1,96 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Olivier Thauvin + nanardon at nanardon.zarb.org +
+ Wed Jan 12 12:14:49 CET 2011 +

+
+ +
* andre999 (andr55 at laposte.net) wrote:
+> Michael Scherer a écrit :
+>>
+>> Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+>
+> In my case, using aria2c with 2 mirrors and the default 5 connexions is  
+> at least 3 times as fast as a single connexion (to my closest mirror).
+> And a much greater improvement over other download options I've tried.
+
+This is a selfish point of view, nothing is important except the result
+on your side.
+
+But as I can see the results of such thing on distrib-coffee I can tell:
+- often the bandwidth limititation is client side (eg you, with your DSL
+  connection, and not the mirror, with 100mbits/s or more)
+- all mirrors have limit, and when the max connection will be reached 
+  the mirror will stop serving you (download will be very faster !)
+
+Of course, if in the case I don't blacklist mageia and deny download via
+http/ftp to save my mirror (d-c is already under heavy load).
+
+So, no, don't donwload several times from a mirror.
+
+BTW: on distrib-coffee bandwidth is regulated by IP, not connection, 
+downloading 5 times will not be faster than 1.
+
+-- 
+
+Olivier Thauvin
+CNRS  -  LATMOS
+♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 197 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110112/cabe6745/attachment.asc>
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002083.html b/zarb-ml/mageia-dev/20110112/002083.html new file mode 100644 index 000000000..9c4e60114 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002083.html @@ -0,0 +1,125 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Olivier Thauvin + nanardon at nanardon.zarb.org +
+ Wed Jan 12 12:52:32 CET 2011 +

+
+ +
* andre999 (andr55 at laposte.net) wrote:
+> Romain d'Alverny a écrit :
+>>
+>> On Wed, Jan 12, 2011 at 04:29, Michael Scherer<misc at zarb.org>  wrote:
+>>
+>> However, if 1) was to open 5 connections on 5 distinct servers, that
+>> would make more sense, no?
+>
+> Right.
+> Another way to look at the question :
+> If 1000 people are downloading from mirrors allowing a total of 2000  
+> connexions, if no-one uses multiple connexions, then 1000 connexions are  
+> wasted.  These unused connexions would likely be from faster mirrors.
+
+The upload given by a serveur is split in term of:
+- connection available
+- bandwidth available.
+
+If the mirrors is connected to Gb (which is more likelly the size of
+bandwidth for the whole university...), and you split this Gb/s onto
+2000 connection you obtain 500kb/s.
+
+However, I know only few server in the world really able to read Gb/s
+from their disk. The top rate I obtain on dc is 400mbis/s (the memory
+cache help a lot to obtain more).
+
+The number of connection is set high because some people download at
+only 50kb/s and other 2Mbit/s, so the spare bandwidth from the 50kb/s
+can be given to others. Nothing more.
+
+According the graph on distrib-coffee:
+http://distrib-coffee.ipsl.jussieu.fr/munin/distrib-coffee/distrib-coffee/index.html
+there is an average of 100 http download at a time, if each connection
+become 5 (500), you'll reach the limit (200 on this server).
+What will be the gain on your side ?
+
+I talked here only about http, but apply the same to ftp in the same
+internet connection, so it mean I have 100mbits/s to share between 400
+connections.
+
+As Mickael explain, I voluntary limit the count of connection per IP,
+before I did this, the server was overload 12 hour a day, which mean
+stop serving !
+
+> With aria2c, 3 mirrors which support a total of 5 connexions gives me  
+> optimal speed.  (The limit being the speed of my computer.)
+
+Can we know the speed of your connection ?
+
+Maybe your connection is good enough to provide a mirror for Mageia ?
+And then you'll be able to test what you're suggesting.
+
+What is the result with 5 mirrors and 1 connection per mirror ?
+
+Obviously, any mirror in France (I am in France) is able to fulfill
+my personnal connection... (10mbits/s).
+
+-- 
+
+Olivier Thauvin
+CNRS  -  LATMOS
+♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 197 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110112/69c6e254/attachment.asc>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002084.html b/zarb-ml/mageia-dev/20110112/002084.html new file mode 100644 index 000000000..5abea574a --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002084.html @@ -0,0 +1,84 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 12 13:31:43 CET 2011 +

+
+ +
Le mercredi 12 janvier 2011 à 08:05 +0100, Thierry Vignaud a écrit :
+> On 12 January 2011 04:29, Michael Scherer <misc at zarb.org> wrote:
+> > For example, distrib-coffee could blacklist you if you do this, if you
+> > are not alone on your network connexion. And when we deployed this
+> > measure to protect the server, the limit was 2 connexion per address,
+> > since this was taking too much ressources on the old server ( each http
+> > request taking 1 process and so memory ).
+> 
+> switching to nginx would help that
+
+According to the current mirror maintainer, the problem is not only on
+http server memory usage ( I do use nginx myself on my own servers and
+indeed, that would alleviate this part of the issue ).
+
+It is also that doing random access to file result in random seek on the
+raid array, and on a regular scsi disk ( not on ssd but ssd is not cheap
+for the moment ), this is more disrupting since the head of the disk is
+constantly moving to seek the block to fetch. 
+
+Fetching continuous block from the disk is faster, since there is no
+delay. Fetching from random part of the disk is more problematic.
+
+And the same goes when done on multiple servers. It is lighter on the
+overall ressources to download on one mirror and stick to it than open 5
+connexions and do 5 random seeks on 5 different disk.
+
+-- 
+Michael Scherer
+
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002085.html b/zarb-ml/mageia-dev/20110112/002085.html new file mode 100644 index 000000000..0fe9711cd --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002085.html @@ -0,0 +1,142 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ andre999 + andr55 at laposte.net +
+ Wed Jan 12 15:10:52 CET 2011 +

+
+ +
Olivier Thauvin a écrit :
+> * andre999 (andr55 at laposte.net) wrote:
+>> Michael Scherer a écrit :
+>>>
+>>> Le mardi 11 janvier 2011 à 20:03 +0100, Marcello Anni a écrit :
+>>
+>> In my case, using aria2c with 2 mirrors and the default 5 connexions is
+>> at least 3 times as fast as a single connexion (to my closest mirror).
+>> And a much greater improvement over other download options I've tried.
+>
+> This is a selfish point of view, nothing is important except the result
+> on your side.
+
+Sorry, but this can't be serious.
+If a user is to download say a 4,7G DVD iso, it is 4,7G if the user uses 
+one or 5 connexions, from one or 5 mirrors.
+And if the 5 connexions go to 5 different mirrors, that is only 20% per 
+mirror.
+Globally, if the same files are downloaded, the same amount of data is 
+downloaded.
+What we are talking about here, from the user side, is downloading 
+faster, if the capacity is _available_ on the network of mirrors.
+Nothing more, nothing less.
+
+There are many mirrors which provide multiple connexions, with a very 
+large bandwidth.  If users don't use the available connexions on these 
+servers, other mirrors will be more heavily impacted.
+So, as I said in another post on this thread, it is win-win for both 
+users and mirrors.
+
+> But as I can see the results of such thing on distrib-coffee I can tell:
+> - often the bandwidth limititation is client side (eg you, with your DSL
+>    connection, and not the mirror, with 100mbits/s or more)
+> - all mirrors have limit, and when the max connection will be reached
+>    the mirror will stop serving you (download will be very faster !)
+
+That is the advantage of applications like aria2c.  They search 
+available connexions from the urls (mirrors) given, and choose which 
+give the fastest downloads.  The number of connexions vary according to 
+the conditions.  With the default of 5 connexions, aria2c tries to 
+maintain 5 connexions, but in practice fluctuates (dynamically) between 
+3 and 5, according to conditions.  (From my experience.)
+
+Think of it another way.
+Scenerio 1)  Suppose at this moment the mirror network has 20% free 
+capacity.  We download without multiple connections or multiple mirrors, 
+without using this excess capacity.  In one hour we are still 
+downloading, at a time when there is no free capacity.
+
+Scenerio 2) We download using multiple connexions and multiple mirrors, 
+accelerating the downloads with the otherwise unused 20% free capacity. 
+  In one hour, most of our downloads are finished, thus leaving free 
+capacity.
+
+Just who is served by scenerio 1 ?
+The users that don't have access, or the mirrors that are overloaded ?
+
+> Of course, if in the case I don't blacklist mageia and deny download via
+> http/ftp to save my mirror (d-c is already under heavy load).
+>
+> So, no, don't donwload several times from a mirror.
+
+The solution ?  If a mirror can't handle multiple connexions, restrict 
+it in some way.  Many mirrors do.  Either all the time, or from time to 
+time.  Or throttle the transfer speed.
+Just do whatever works best for the mirror in question.
+However let users use the capacity available.  Because it may not be 
+available in one hour, or even 5 minutes.
+
+> BTW: on distrib-coffee bandwidth is regulated by IP, not connection,
+> downloading 5 times will not be faster than 1.
+
+Essentially the same thing.  Great, if it works for the mirror.
+
+aria2c senses the the bandwidth dynamically, and reacts accordingly. 
+I'm sure that many other applications do the same thing.
+Don't forget that much of the increase in download speed comes from 
+using multiple mirrors. (Clearly indicated in the aria2c documentation, 
+and verified in my usage.)
+
+Why not think globally ?
+
+another 2 cents :)
+
+-- 
+André
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002086.html b/zarb-ml/mageia-dev/20110112/002086.html new file mode 100644 index 000000000..e7dbe431d --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002086.html @@ -0,0 +1,78 @@ + + + + [Mageia-dev] 12/01/2011 meeting + + + + + + + + + +

[Mageia-dev] 12/01/2011 meeting

+ Anne nicolas + ennael1 at gmail.com +
+ Wed Jan 12 16:51:11 CET 2011 +

+
+ +
Our next weekly meeting will happen tonight, 20h UTC on #mageia-dev
+
+Topics
+======
+
+- mentoring: review on current process
+- build system status: summary of current status
+- relation with mdv: asked by several people - speak about what to do
+on that topic
+- mageia policies: review
+- organize maintainership for packages
+- short notice about FOSDEM
+
+Cheers
+
+-- 
+Anne
+http://www.mageia.org
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002087.html b/zarb-ml/mageia-dev/20110112/002087.html new file mode 100644 index 000000000..584f94575 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002087.html @@ -0,0 +1,178 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Olivier Thauvin + nanardon at nanardon.zarb.org +
+ Wed Jan 12 17:07:15 CET 2011 +

+
+ +
* andre999 (andr55 at laposte.net) wrote:
+> Olivier Thauvin a écrit :
+>> * andre999 (andr55 at laposte.net) wrote:
+>>> Michael Scherer a écrit :
+>>>>
+>> This is a selfish point of view, nothing is important except the result
+>> on your side.
+>
+> Sorry, but this can't be serious.
+> If a user is to download say a 4,7G DVD iso, it is 4,7G if the user uses  
+> one or 5 connexions, from one or 5 mirrors.
+> And if the 5 connexions go to 5 different mirrors, that is only 20% per  
+> mirror.
+> Globally, if the same files are downloaded, the same amount of data is  
+> downloaded.
+> What we are talking about here, from the user side, is downloading  
+> faster, if the capacity is _available_ on the network of mirrors.
+
+Exactly, it is seriously a selfish point of view as:
+- you're talking about users side, me both
+- IF the capacity, obviously no one really know the capacity of mirrors
+  except admin of them (and I am one of them).
+
+Moreover you're mixing "downloading on several server" and "downloading
+several time on one or more servers".
+
+> There are many mirrors which provide multiple connexions, with a very  
+> large bandwidth.  If users don't use the available connexions on these  
+> servers, other mirrors will be more heavily impacted.
+> So, as I said in another post on this thread, it is win-win for both  
+> users and mirrors.
+
+All mirrors provides multiple connection, otherwise they would serve
+only one client a time...
+
+And no, it is not win-win, I am trying to explain, munin statistics in
+hand, only the users think to win something. And you're ignoring my
+comment as mirror admin.
+
+> Think of it another way.
+> Scenerio 1)  Suppose at this moment the mirror network has 20% free  
+> capacity.  We download without multiple connections or multiple mirrors,  
+> without using this excess capacity.  In one hour we are still  
+> downloading, at a time when there is no free capacity.
+>
+> Scenerio 2) We download using multiple connexions and multiple mirrors,  
+> accelerating the downloads with the otherwise unused 20% free capacity.  
+> In one hour, most of our downloads are finished, thus leaving free  
+> capacity.
+>
+> Just who is served by scenerio 1 ?
+
+Mirrors, they are not serving only you and your 5 connections, they
+already serving 100 users other than just you !
+
+I cannot see how the mirror will give more bandwidth with 1 or 5
+connections. Except in the case each connection take same amount of
+bandwidth, then you're 5 part while other take one. And this is not a
+fair use of ressource.
+
+> The users that don't have access, or the mirrors that are overloaded ?
+>
+>> Of course, if in the case I don't blacklist mageia and deny download via
+>> http/ftp to save my mirror (d-c is already under heavy load).
+>>
+>> So, no, don't donwload several times from a mirror.
+>
+> The solution ?  If a mirror can't handle multiple connexions, restrict  
+> it in some way.  Many mirrors do.  Either all the time, or from time to  
+> time.  Or throttle the transfer speed.
+> Just do whatever works best for the mirror in question.
+> However let users use the capacity available.  Because it may not be  
+> available in one hour, or even 5 minutes.
+
+The problem is (maybe I am not clear) your 5 connections will get queue
+letting other people having to wait more to download their file, or
+getting "too many connections" error.
+
+Indeed, this maybe does not matter for you, except when you'll complain
+because the distribution cannot be download.
+
+>
+> Why not think globally ?
+
+I do, especially, I prefectly when http stop to reply, it stop to reply
+globally, for Mageia but also for Fedora / Ubuntu / Scientific Linux /
+Arklinux / Gentoo / ... and all other project hosted on mirrors.
+
+This is really a more global issue.
+
+I also think my mirror have first to serve my work, and time to time
+my colleague complain about slowdown cause by external downloader (eg
+YOU).
+
+
+Here my POV:
+1) I am mirror admin and get tired of abuse
+2) I am mirror manager for the distro
+
+a) According the fact doing this create an huge load on some mirrors,
+b) according we'll have to search mirror around the world and the distrib
+  size is already a problem
+c) according doing this can discourage people offering space and bandwidth
+  for us
+
+I am aginst such things.
+
+I cannot deny you to do this, but don't complain if no mirror agree to
+serve you.
+
+-- 
+
+Olivier Thauvin
+CNRS  -  LATMOS
+♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: not available
+Type: application/pgp-signature
+Size: 197 bytes
+Desc: not available
+URL: </pipermail/mageia-dev/attachments/20110112/e41f6344/attachment.asc>
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002088.html b/zarb-ml/mageia-dev/20110112/002088.html new file mode 100644 index 000000000..171eb3829 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002088.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Frank Griffin + ftg at roadrunner.com +
+ Wed Jan 12 17:24:09 CET 2011 +

+
+ +
Farfouille wrote:
+> Hi
+>
+> I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy
+>
+> Corrections and comments are welcome.
+>   
+
+The bit about pre-packaged JARs may cause trouble.  In theory, it's
+great, but many applications depend upon certain versions of their
+utility JARs, and can't all run with the latest versions.  Any such app
+would have a Requires for its specific version, which would prevent the
+utility JAR from being updated with a newer version for other apps. 
+This is why EJB allows EJB apps to include their own specific versions
+of utility JARs, which are visible to them but not to other apps or the
+container itself, and also why Maven uses versioned artifacts.
+
+An extreme example of such an app is NetBeans, which includes its own
+versions of Ant and Maven.
+
+Also, for such apps, upstream developers may refuse to investigate
+issues unless the shipped versions of supplemental JARs are being used.
+
+> As I have never used maven, a deep reread is required
+>
+>
+>   
+
+Maven POMs allow the packager to specify required other objects
+("artifacts") not only for building the package but for execution as
+well.  There are central Maven repositories which contain versioned
+artifacts for commonly-used projects, e.g. JUnit, and many companies
+have site-wide repositories of their own.  Finally, every user of Maven
+has a personal repository located in $HOME/.m2, which is why the policy
+has code for creating this directory.
+
+Repositories are seached for needed artifacts from the most local (the
+user's personal repository) to the most remote (the central Maven
+repositories) as directed by a settings.xml file in the user's .m2
+directory or <repositories> tags in the individual pom.xml files.  The
+general intent is to obtain artifacts from the "closest" repository. 
+Company repositories are not just the central location for
+company-specific artifacts, but also a local cache for central Maven
+repository artifacts.
+
+>From the policy, it looks like the personal repository for the ID under
+which RPM builds the package is wiped clean for every package, and thus
+every needed artifact will be downloaded from the remote repositories
+for every build.  If that's the case, it's an awful waste of bandwidth,
+since many of these artifacts are used for every Maven project.
+
+We might want to consider having a central repository for each system,
+which would be one level above the individual users' personal
+repositories, and would be used before more remote repositories.  There
+is no harm to allowing artifacts to accumulate there, since all
+artifacts are versioned.  Cleanup might be possible through filetriggers
+if a tool identified all dependent artifacts for each installed Maven
+package, and deleted ones no longer used by anything installed.  If
+there were such a repository, say under /var, then it should be used for
+builds rather than an individual repository tied to the RPM userid.
+
+There's also the issue of allowing company or site repositories to be
+used if they exist.  For packages installed during system installation,
+there would be no way for a sysadmin to specify local repositories
+unless the install were modified to allow it, but few if any Java
+packages (much less Maven ones) are installed at that time.  For later
+package installs, perhaps a dynamic settings.xml could be created for
+the build using XML fragments in something like an
+/etc/maven/repositories.d with the same sort of numeric prefix
+preference that chkconfig uses to establish precedence.
+
+Finally, there's the issue of using repository artifacts on the system
+in the execution-time CLASSPATHs for the Maven applications.  Maven has
+a plugin which will build a single huge JAR containing an application's
+classes as well as classes from every JAR artifact on which it depends,
+and many docs recommend this as the way to distribute an application,
+but it consumes quite a bit of space as every app is carrying its own
+copy of every supplemental utility class it needs when it could probably
+find the identical classes in the versioned artifacts in a system
+repository.  This ties in to the build-classpath and
+build-jar-repository capabilities for non-Maven apps.
+
+By the way, the policy should probably contain full usage instructions
+for build-classpath and build-jar-repository as well as a description of
+the uses to which they are put.
+
+Good Work !
+
+
+
+
+ + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002089.html b/zarb-ml/mageia-dev/20110112/002089.html new file mode 100644 index 000000000..dff1ffe75 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002089.html @@ -0,0 +1,67 @@ + + + + [Mageia-dev] 12/01/2011 meeting + + + + + + + + + +

[Mageia-dev] 12/01/2011 meeting

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 12 17:29:14 CET 2011 +

+
+ +
Le mercredi 12 janvier 2011 à 16:51 +0100, Anne nicolas a écrit :
+> Our next weekly meeting will happen tonight, 20h UTC on #mageia-dev
+
+I have another exceptional appointment tonight, sorry for not being
+there.
+( as said you should not have voted for me ).
+-- 
+Michael Scherer
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002090.html b/zarb-ml/mageia-dev/20110112/002090.html new file mode 100644 index 000000000..b1908d4d4 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002090.html @@ -0,0 +1,90 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Michael Scherer + misc at zarb.org +
+ Wed Jan 12 17:32:35 CET 2011 +

+
+ +
Le mercredi 12 janvier 2011 à 11:24 -0500, Frank Griffin a écrit :
+> Farfouille wrote:
+> > Hi
+> >
+> > I have published a first draft of Java application package policy. http://mageia.org/wiki/doku.php?id=java_applications_policy
+> >
+> > Corrections and comments are welcome.
+> >   
+> 
+> The bit about pre-packaged JARs may cause trouble.  In theory, it's
+> great, but many applications depend upon certain versions of their
+> utility JARs, and can't all run with the latest versions.  Any such app
+> would have a Requires for its specific version, which would prevent the
+> utility JAR from being updated with a newer version for other apps. 
+> This is why EJB allows EJB apps to include their own specific versions
+> of utility JARs, which are visible to them but not to other apps or the
+> container itself, and also why Maven uses versioned artifacts.
+
+That's the same issue for everything.
+
+Shipping binary jar given by upstream tarball cause trouble because you 
+1) cannot patch them in case of bug
+2) cannot see how and what was compiled 
+
+That's not very free software friendly, and I think we should refuse
+that.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002091.html b/zarb-ml/mageia-dev/20110112/002091.html new file mode 100644 index 000000000..f4ee16881 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002091.html @@ -0,0 +1,70 @@ + + + + [Mageia-dev] 12/01/2011 meeting + + + + + + + + + +

[Mageia-dev] 12/01/2011 meeting

+ Cazzaniga Sandro + cazzaniga.sandro at gmail.com +
+ Wed Jan 12 17:43:44 CET 2011 +

+
+ +
Le 12/01/2011 17:29, Michael Scherer a écrit :
+> Le mercredi 12 janvier 2011 à 16:51 +0100, Anne nicolas a écrit :
+>> Our next weekly meeting will happen tonight, 20h UTC on #mageia-dev
+> 
+> I have another exceptional appointment tonight, sorry for not being
+> there.
+> ( as said you should not have voted for me ).
+I'll be here :)
+
+-- 
+Sandro Cazzaniga
+IRC: Kharec (irc.freenode.net)
+Twitter: @Kharec
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002092.html b/zarb-ml/mageia-dev/20110112/002092.html new file mode 100644 index 000000000..e6d645675 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002092.html @@ -0,0 +1,80 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Frank Griffin + ftg at roadrunner.com +
+ Wed Jan 12 17:45:23 CET 2011 +

+
+ +
Michael Scherer wrote:
+> Le mercredi 12 janvier 2011 à 11:24 -0500, Frank Griffin a écrit :
+>   
+>> The bit about pre-packaged JARs may cause trouble.
+> That's the same issue for everything.
+>
+> Shipping binary jar given by upstream tarball cause trouble because you 
+> 1) cannot patch them in case of bug
+> 2) cannot see how and what was compiled 
+>
+> That's not very free software friendly, and I think we should refuse
+> that.
+>
+>   
+Granted, but unless every free software project migrates to Maven, you'd
+be refusing a lot of popular apps.   
+
+In theory, the packager of such an application could create
+supplementary packages for the specific versions of included JARs and
+build them first from source.  But for something like NetBeans or
+Eclipse, that's going to be a lot of work....
+
+
+ + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002093.html b/zarb-ml/mageia-dev/20110112/002093.html new file mode 100644 index 000000000..22bf16b14 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002093.html @@ -0,0 +1,59 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Wolfgang Bornath + molch.b at googlemail.com +
+ Wed Jan 12 18:10:08 CET 2011 +

+
+ +
Thanks Olivier, for saying this much better than I could
+
+wobo, yet another mirror maintainer
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002094.html b/zarb-ml/mageia-dev/20110112/002094.html new file mode 100644 index 000000000..58f91af23 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002094.html @@ -0,0 +1,73 @@ + + + + [Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download + + + + + + + + + +

[Mageia-dev] Proposal for Mageia: implement bitorrent protocol to allow updates download

+ Marcello Anni + marcello.anni at alice.it +
+ Wed Jan 12 20:14:54 CET 2011 +

+
+ +
> Thanks Olivier, for saying this much better than I could
+> 
+> wobo, yet another mirror maintainer
+> 
+yes wobo, but  except Per Øyvind no one has really answered to my question... 
+i think if that if we want Mageia to become the most popular distro over the 
+world -yep!- we should find a way to augment the overall bandwith available for 
+updates download, and what's better than bittorrent protocol to use user 
+available bandwith to do this? i would like to know:
+
+- if it is possible from a techincal pov
+- if it is convenient and useful (overall in a long-term vision)
+- if we could plan it for the coming releases (and who could take in charge 
+this)
+
+
+cheers,
+Marcello 
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002095.html b/zarb-ml/mageia-dev/20110112/002095.html new file mode 100644 index 000000000..04384ddee --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002095.html @@ -0,0 +1,89 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Farfouille + farfouille64 at laposte.net +
+ Wed Jan 12 20:49:22 CET 2011 +

+
+ +
Le 12/01/2011 17:45, Frank Griffin a écrit :
+> 
+> Michael Scherer wrote:
+>> Le mercredi 12 janvier 2011 à 11:24 -0500, Frank Griffin a écrit :
+>>   
+>>> The bit about pre-packaged JARs may cause trouble.
+>> That's the same issue for everything.
+>>
+>> Shipping binary jar given by upstream tarball cause trouble because you 
+>> 1) cannot patch them in case of bug
+>> 2) cannot see how and what was compiled 
+>>
+>> That's not very free software friendly, and I think we should refuse
+>> that.
+>>
+>>   
+> Granted, but unless every free software project migrates to Maven, you'd
+> be refusing a lot of popular apps.   
+> 
+> In theory, the packager of such an application could create
+> supplementary packages for the specific versions of included JARs and
+> build them first from source.  But for something like NetBeans or
+> Eclipse, that's going to be a lot of work....
+> 
+> 
+> 
+I propose to keep the restriction, but to allow some exception, mainly blockbuster like
+Eclipse and Netbeans in order to build an appealing distro.
+
+Do you know other softwares that are worth to be exception ?
+--
+Farfouille
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002096.html b/zarb-ml/mageia-dev/20110112/002096.html new file mode 100644 index 000000000..19aada261 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002096.html @@ -0,0 +1,93 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Renaud MICHEL + r.h.michel+mageia at gmail.com +
+ Wed Jan 12 22:41:42 CET 2011 +

+
+ +
On mercredi 12 janvier 2011 at 17:45, Frank Griffin wrote :
+> In theory, the packager of such an application could create
+> supplementary packages for the specific versions of included JARs and
+> build them first from source.  But for something like NetBeans or
+> Eclipse, that's going to be a lot of work....
+
+I don't know for netbeans (maybe it is the same as eclipse), but eclipse 
+needs anyway all of its dependencies inside his own plugins directory, so it 
+would anyway be hard to use other system installed jars.
+But the source of the required version could probably be included in the 
+src.rpm of the requiring plugins and built/installed before them (but I 
+actually have no idea how eclipse plugins are built from source).
+
+The problem is, many eclipse plugins (or plugins collections actually) have 
+dependencies on the same libs (for example xalan and xerces) which they all 
+provide in their zip archive. We cannot have them in each package that need 
+them as it would create file conflicts between those packages.
+So we would need to create separate packages for those "external 
+dependencies plugins". They could be built from their own source (from the 
+official project) and then the real plugins would depend on them.
+That would probably require a special naming convention for dependencies 
+between plugins (as the package doesn't provide "xalan" but "xalan as an 
+eclipse plugin")
+
+Or maybe, if the jar in the external dependency plugin is actually the same 
+(or compatible) version as the on from the normal package maybe we could 
+make a plugin package only containing the eclipse related files 
+(plugin.properties) and creating a symlink to the system wide jar. But that 
+mean that eclipse plugins, which are now frequently provided as single jar 
+files, would need to be packaged as files and directories like in older 
+eclipse releases.
+
+What do you think?
+
+-- 
+Renaud Michel
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002097.html b/zarb-ml/mageia-dev/20110112/002097.html new file mode 100644 index 000000000..0d5ba0234 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002097.html @@ -0,0 +1,74 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Renaud MICHEL + r.h.michel+mageia at gmail.com +
+ Wed Jan 12 22:54:12 CET 2011 +

+
+ +
On mercredi 12 janvier 2011 at 22:41, Renaud MICHEL wrote :
+> Or maybe, if the jar in the external dependency plugin is actually the
+> same  (or compatible) version as the on from the normal package maybe we
+> could make a plugin package only containing the eclipse related files
+> (plugin.properties) and creating a symlink to the system wide jar. But
+> that mean that eclipse plugins, which are now frequently provided as
+> single jar files, would need to be packaged as files and directories
+> like in older eclipse releases.
+
+Looking at fedora's eclipse plugins packages, it seems they are symlinking 
+directly the jars from their system bundle in the eclipse plugins directory, 
+with full package and version as symlink name.
+I thought some eclipse specific files (like plugin.properties) were required 
+inside the jar, but it seems not.
+
+-- 
+Renaud Michel
+
+ + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002098.html b/zarb-ml/mageia-dev/20110112/002098.html new file mode 100644 index 000000000..7a32661aa --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002098.html @@ -0,0 +1,64 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Frank Griffin + ftg at roadrunner.com +
+ Wed Jan 12 23:36:52 CET 2011 +

+
+ +
Farfouille wrote:
+>
+> I propose to keep the restriction, but to allow some exception, mainly blockbuster like
+> Eclipse and Netbeans in order to build an appealing distro.
+>
+> Do you know other softwares that are worth to be exception ?
+>   
+The only one that comes to mind is JBoss, but I'm sure there will be
+others.  Any servlet or EJB container is going to be prone to this.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/002099.html b/zarb-ml/mageia-dev/20110112/002099.html new file mode 100644 index 000000000..7c2401d64 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/002099.html @@ -0,0 +1,82 @@ + + + + [Mageia-dev] Java-Policy first draft published + + + + + + + + + +

[Mageia-dev] Java-Policy first draft published

+ Frank Griffin + ftg at roadrunner.com +
+ Wed Jan 12 23:54:48 CET 2011 +

+
+ +
Renaud MICHEL wrote:
+>
+> Or maybe, if the jar in the external dependency plugin is actually the same 
+> (or compatible) version as the on from the normal package maybe we could 
+> make a plugin package only containing the eclipse related files 
+> (plugin.properties) and creating a symlink to the system wide jar. But that 
+> mean that eclipse plugins, which are now frequently provided as single jar 
+> files, would need to be packaged as files and directories like in older 
+> eclipse releases.
+>
+> What do you think?
+>
+>   
+I think we want to consider carefully before we try to replace complex
+existing plugin installation procedures in various products.  This issue
+is also being discussed relative to Firefox in another thread.
+
+Users of things like NetBeans and Eclipse are used to the mechanisms
+provided by those tools for managing plugin installation, and are not
+going to take kindly to having to use rpmdrake instead.  And in some
+cases, e.g. Maven, you don't have a choice - if Maven needs it and it
+isn't there, it will get it from repositories whether or not you have
+packaged a plugin as an RPM.
+
+At some point, you just give up and accept the fact that you can't
+reform the entire world.  As more and more projects migrate to Maven,
+the problem (sort of) goes away.  All of our suggestions here are
+basically trying to recreate what Maven does without requiring projects
+to use it.
+
+ + +
+

+ +
+More information about the Mageia-dev +mailing list
+ diff --git a/zarb-ml/mageia-dev/20110112/author.html b/zarb-ml/mageia-dev/20110112/author.html new file mode 100644 index 000000000..b2cc9a14f --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/author.html @@ -0,0 +1,192 @@ + + + + The Mageia-dev 12 January 2011 Archive by author + + + + + +

12 January 2011 Archives by author

+ +

Starting: Wed Jan 12 00:12:44 CET 2011
+ Ending: Wed Jan 12 23:54:48 CET 2011
+ Messages: 29

+

+

+ Last message date: + Wed Jan 12 23:54:48 CET 2011
+ Archived on: Wed Jan 12 23:54:55 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20110112/date.html b/zarb-ml/mageia-dev/20110112/date.html new file mode 100644 index 000000000..b995182ce --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/date.html @@ -0,0 +1,192 @@ + + + + The Mageia-dev 12 January 2011 Archive by date + + + + + +

12 January 2011 Archives by date

+ +

Starting: Wed Jan 12 00:12:44 CET 2011
+ Ending: Wed Jan 12 23:54:48 CET 2011
+ Messages: 29

+

+

+ Last message date: + Wed Jan 12 23:54:48 CET 2011
+ Archived on: Wed Jan 12 23:54:55 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20110112/index.html b/zarb-ml/mageia-dev/20110112/index.html new file mode 120000 index 000000000..db4b46f72 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/zarb-ml/mageia-dev/20110112/subject.html b/zarb-ml/mageia-dev/20110112/subject.html new file mode 100644 index 000000000..d4eeca043 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/subject.html @@ -0,0 +1,192 @@ + + + + The Mageia-dev 12 January 2011 Archive by subject + + + + + +

12 January 2011 Archives by subject

+ +

Starting: Wed Jan 12 00:12:44 CET 2011
+ Ending: Wed Jan 12 23:54:48 CET 2011
+ Messages: 29

+

+

+ Last message date: + Wed Jan 12 23:54:48 CET 2011
+ Archived on: Wed Jan 12 23:54:55 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/zarb-ml/mageia-dev/20110112/thread.html b/zarb-ml/mageia-dev/20110112/thread.html new file mode 100644 index 000000000..5079b2022 --- /dev/null +++ b/zarb-ml/mageia-dev/20110112/thread.html @@ -0,0 +1,243 @@ + + + + The Mageia-dev 12 January 2011 Archive by thread + + + + + +

12 January 2011 Archives by thread

+ +

Starting: Wed Jan 12 00:12:44 CET 2011
+ Ending: Wed Jan 12 23:54:48 CET 2011
+ Messages: 29

+

+

+ Last message date: + Wed Jan 12 23:54:48 CET 2011
+ Archived on: Wed Jan 12 23:54:55 CET 2011 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + -- cgit v1.2.1