Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-soc
Navigation:
Lists: gentoo-soc: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-soc@g.o
From: mmacleod@...
Subject: Re: GLEP 25 + GLEP 9
Date: Mon, 23 Mar 2009 08:00:32 +0200
> I just re-read the GLEPs. The first thing that comes to my mind is: Is
> there still a big use case for smaller downloads with the advance of
> broadband internet? However, I accept that not everyone has alot of
> bandwidth available to them and ignore my initial reaction ;)
I would just like to comment on possible motivations for this as well.

Some parts of the world have very low threshold for what they consider broad 
band, where I am from(South Africa) I have an ADSL line that is crippled to 
384k and am only allowed to do 3 gigabytes of traffic(combined 
upload/download) a month, after which my connection is completely cut off even 
for local browsing.
It is possible to buy more bandwidth and a faster line but the pricing is 
really prohibitive.
At these speeds the downloads do not take an insignificant time especially for 
a large package like open office(+-400mb)[1], it is not uncommon for me to 
have to delay updating packages to a new month in order to save money.
Sadly when it comes to Internet I am better off then many, it is not uncommon 
for people to use the internet through 56k/ISDN/GPRS here, I can only imagine 
there are other countries where this might be even worse.

The extreme large cases like open office are likely to benefit even people 
with fairly decent bandwidth/caps, it is an example of how designing software 
with the lowest target system in mind can benefit even those on faster 
systems.

Lower bandwidth load on mirrors, if a large amount of users make use of this 
the bandwidth load on mirrors would be substantially reduced. This in turn can 
lower the requirements needed to host a mirror and therefore make donated 
mirrors more likely.

Social responsibility. As internet users it is our responsibility to not waste 
large quantities of bandwidth unnecessarily, as it is eventually a finite 
resource that we all  have to pay for, as human beings it is also our 
responsibility in general to try and be less wasteful.
While the bandwidth usage of Gentoo might be a small drop in the ocean I am of 
the opinion that every small bit helps.
> There is a utility created by Brian Ferring (former Gentoo dev, author
> of GLEP 25) called dev-util/diffball that is used by infra to create the
> portage daily snapshot patches.
> http://distfiles.gentoo.org/snapshots/deltas/
There is also deltup created by the author of GLEP 9.
> Can you elaborate on where you envision this idea going? and perhaps
> some implementation (high level) details that you are interested in
> pursuing?
I would like to first reevaluate all the outcomes and assumptions of GLEP 9/25 
and see if there are areas where improvements could be made, I suspect there 
are one or two areas where this might be the case.
I also reevaluate the various options for which difference program should be 
used, starting with diffball and deltup, and then looking at a few others as 
well. I would want to examine each to see if there is room for improvement as 
well, and document these areas if possible.
I would then like to publish a new GLEP like document or even a GLEP itself 
and allow others a small period to comment on the new outcomes, or add any new 
ideas of there own.
I would then begin work on implementing the new "GLEP", starting with a server 
daemon in charge of generating the initial patch directory for the existing 
distfiles and new patches for new distfiles as they are added.
Finally I would do modifications to portage itself so that it can make use of 
the difference information where necessary and apply the patches etc. I would 
also look into other portage tools that should be aware of this, disfiles-
clean should take care of getting rid of patches that are no longer needed as 
well, knowledge of patches should be taken into account when chosing which 
distfiles to delete as well.
There would obviously be fairly large amounts of testing required for each of 
these parts as well.


[1] I realize open office might not be the best example as open office 
tarballs must be fetched from sun directly and are not stored on distfiles 
server. I don't think patches should be generated for externally hosted 
packages yet although it could be done if people want it. Manual adding of 
patches would also be possible so open office maintainers could potentially 
"manually" do differences for it as a special case.



Replies:
Re: GLEP 25 + GLEP 9
-- Jeremy Olexa
References:
GLEP 25 + GLEP 9
-- mmacleod
Re: GLEP 25 + GLEP 9
-- Jeremy Olexa
Navigation:
Lists: gentoo-soc: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: GLEP 25 + GLEP 9
Next by thread:
Re: GLEP 25 + GLEP 9
Previous by date:
Re: GSoc 2009 : Making the cluster LiveCD bootable from USB
Next by date:
Re: Improved binary package support


Updated Jun 17, 2009

Summary: Archive of the gentoo-soc mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.