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. |