Gentoo Archives: gentoo-soc

From: mmacleod@××××××××××.za
To: gentoo-soc@l.g.o
Subject: Re: [gentoo-soc] GLEP 25 + GLEP 9
Date: Mon, 23 Mar 2009 06:00:35
Message-Id: 200903230800.32852.mmacleod@webmail.co.za
In Reply to: Re: [gentoo-soc] GLEP 25 + GLEP 9 by Jeremy Olexa
1 > I just re-read the GLEPs. The first thing that comes to my mind is: Is
2 > there still a big use case for smaller downloads with the advance of
3 > broadband internet? However, I accept that not everyone has alot of
4 > bandwidth available to them and ignore my initial reaction ;)
5 I would just like to comment on possible motivations for this as well.
6
7 Some parts of the world have very low threshold for what they consider broad
8 band, where I am from(South Africa) I have an ADSL line that is crippled to
9 384k and am only allowed to do 3 gigabytes of traffic(combined
10 upload/download) a month, after which my connection is completely cut off even
11 for local browsing.
12 It is possible to buy more bandwidth and a faster line but the pricing is
13 really prohibitive.
14 At these speeds the downloads do not take an insignificant time especially for
15 a large package like open office(+-400mb)[1], it is not uncommon for me to
16 have to delay updating packages to a new month in order to save money.
17 Sadly when it comes to Internet I am better off then many, it is not uncommon
18 for people to use the internet through 56k/ISDN/GPRS here, I can only imagine
19 there are other countries where this might be even worse.
20
21 The extreme large cases like open office are likely to benefit even people
22 with fairly decent bandwidth/caps, it is an example of how designing software
23 with the lowest target system in mind can benefit even those on faster
24 systems.
25
26 Lower bandwidth load on mirrors, if a large amount of users make use of this
27 the bandwidth load on mirrors would be substantially reduced. This in turn can
28 lower the requirements needed to host a mirror and therefore make donated
29 mirrors more likely.
30
31 Social responsibility. As internet users it is our responsibility to not waste
32 large quantities of bandwidth unnecessarily, as it is eventually a finite
33 resource that we all have to pay for, as human beings it is also our
34 responsibility in general to try and be less wasteful.
35 While the bandwidth usage of Gentoo might be a small drop in the ocean I am of
36 the opinion that every small bit helps.
37 > There is a utility created by Brian Ferring (former Gentoo dev, author
38 > of GLEP 25) called dev-util/diffball that is used by infra to create the
39 > portage daily snapshot patches.
40 > http://distfiles.gentoo.org/snapshots/deltas/
41 There is also deltup created by the author of GLEP 9.
42 > Can you elaborate on where you envision this idea going? and perhaps
43 > some implementation (high level) details that you are interested in
44 > pursuing?
45 I would like to first reevaluate all the outcomes and assumptions of GLEP 9/25
46 and see if there are areas where improvements could be made, I suspect there
47 are one or two areas where this might be the case.
48 I also reevaluate the various options for which difference program should be
49 used, starting with diffball and deltup, and then looking at a few others as
50 well. I would want to examine each to see if there is room for improvement as
51 well, and document these areas if possible.
52 I would then like to publish a new GLEP like document or even a GLEP itself
53 and allow others a small period to comment on the new outcomes, or add any new
54 ideas of there own.
55 I would then begin work on implementing the new "GLEP", starting with a server
56 daemon in charge of generating the initial patch directory for the existing
57 distfiles and new patches for new distfiles as they are added.
58 Finally I would do modifications to portage itself so that it can make use of
59 the difference information where necessary and apply the patches etc. I would
60 also look into other portage tools that should be aware of this, disfiles-
61 clean should take care of getting rid of patches that are no longer needed as
62 well, knowledge of patches should be taken into account when chosing which
63 distfiles to delete as well.
64 There would obviously be fairly large amounts of testing required for each of
65 these parts as well.
66
67
68 [1] I realize open office might not be the best example as open office
69 tarballs must be fetched from sun directly and are not stored on distfiles
70 server. I don't think patches should be generated for externally hosted
71 packages yet although it could be done if people want it. Manual adding of
72 patches would also be possible so open office maintainers could potentially
73 "manually" do differences for it as a special case.

Replies

Subject Author
Re: [gentoo-soc] GLEP 25 + GLEP 9 Jeremy Olexa <darkside@g.o>