On Oct 18, 2014 5:00 PM, "Nico Kadel-Garcia" <nkadel(a)gmail.com> wrote:
On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
> My comment was not meant to be argumentative, but rather
tongue-in-cheek.
> However, I do believe when changing a default, it isn't
about what is
> convenient for me. It's about what is best for the entire community and
> what are the real world ramifications. I'm not buying the "let's
change the
> default because high bandwidth is pervasive argument".
>
> I'll go out on a limb here and suggest:
>
> 1. Most people who can afford to pay the monthly recurring cost for a
high
> speed bandwidth connection have multi-core machines.
> 2. People who are running Fedora on multiple machines possess the
skill set
> to easily change the default and turn Presto off if they wish.
You left out some but related issues.
3) People who have a lot of hosts and high bandwidth, high speed
local deployment requirements can, and do, set up an internal Fedora
mirror with much lower bandwidth costs. This reduces the tangible
benefits of deltarpms significantly. This is combined with my direct
observation that working from plain rpms is much faster and more
reliable. Re-assembly from deltarpms is computationally expensive and
thus expensive for large numbers of yum clients. It sounds like a
great idea at first glance, but it profoundly and unpredicatably
increases the disk space and bandwidth needed for mirrors themselves
at a relatively small benefit in download bandwidth. The great example
of difficult to "delta RPM's" sems to be libreoffice. Between the
compressed and distinct binaries for the war files, and the deltarpm
process itself, they save very little bandwidth for many of the
builkies projects.
4) The much, much larger source of wasted bandwidth and resources is
the yum repodata. That's 50 Meg, every time the repodata expires or is
updated, even if there are no actual RPM updates. And for systems that
need frequent updates and refreshes to ensure the latest packages,
it's consumed *every single time* you flush the metadata.
> What about the repositories and mirrors? Do they all have unlimited,
cheap
> bandwidth?
No one does. But in my direct observation, deltarpms are a
theoretically clever attempt to solve the wrong problem, an attempt
that requires massive *extra* diskspace and resources for the mirror
sites that doesn't address the more consistent and demonstrable
problem.
There are environments where bandwidth limits are so great that even
the bare RPM downloads are vulnerable to interruption, and the
marginal improvement of the deltarpm would be noticeable. But I've not
seen such an environment in roughly 10 years, and it was usually to
some bad network hardware or local misconfiguration.
--
Network operators will experience a real, tangible cost increase from
turning off deltarpms. End users with metered bandwidth - off the cuff,
I'd guess hundreds of thousands of current users and billions of
prospective users - will experience a real financial impact from the 'loss'
of this feature.
Now, I realize everyone can turn this on, and everyone can turn it off.
Changing the default option doesn't take away the feature. Those with
metered connections will probably, eventually, discover they can turn
deltarpms on. After the first bill arrives, or the second. These are
likely to be people with limited financial resources, using computers that
you couldn't pay me to work on these days. We're keeping the entire 32bit
architecture alive for them; in contrast to that, the infrastructure burden
of deltarpms is slight. Even so, we continue to welcome this demographic
to use and participate in Fedora.
Faster update transactions are good, but anyone that's concerned about the
*financial impact* of consuming extra CPU cycles ( as in Nico's case #3)
is very likely to be employing a competent administrator (like Nico) that
should know how and why to flip the switch. Nobody wants to take this
option away, and I doubt it would even be possible.
--Pete