yum-presto not on by default

Seth Vidal skvidal at fedoraproject.org
Thu Sep 24 20:00:20 UTC 2009



On Thu, 24 Sep 2009, Ben Boeckel wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> shmuel siegel wrote:
>> The article also hints at our problem. We ARE doing the
> compression on
>> the end user side. So the compression is costing us 3 minutes
> to save 24
>> megabytes of transmission. This actually slows things down for
> most
>> broadband users.
>>
> Since when was yum-presto about time? I thought it was about
> bandwidth usage. Here, the dorm connections are capped at
> 600kb/s (well, not a hard cap, but it can be annoying anyways).
> At one university I know (with over 20k students on the main
> campus), there is (or was last year at least) a cap at 2GB /
> week. Go over and you're capped at 56k for the rest of the
> semester. I can't imagine Fedora on such a restriction (and I
> have 4 machines to update, 2 with largely non-overlapping
> package sets, the other 2 are similar and a caching server would
> help) and that's a lot of students that would be hard pressed to
> use Fedora at college. CPU time is cheaper than bandwidth these
> days. Maybe I'm mistaken about what yum-presto was aiming to
> solve?
>

it's not about local cpu But if we make presto be on by default and the 
local performance is so bad for people with fast connections that it is 
almost unusuable then we have a problem.

So the idea is:

1. make performance not suck
2. maybe not make presto the default anyway.


Now #1 is obvious, I think :)

#2 is about the way someone would use the system. If I'm a place where I 
know the bandwidth is questionable then I figure immediately after install 
I can run: yum install yum-presto and be ready to go.

Or, we install yum-presto by default but disable it. So the first thing 
someone with bandwidth issues does is enable the plugin.


i think that's what this is all about.

-sv




More information about the fedora-devel-list mailing list