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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
