On Sat, Nov 8, 2014 at 2:25 PM, Reindl Harald wrote:
>
>
> Am 08.11.2014 um 20:21 schrieb Nico Kadel-Garcia:
>>>
>>> [root@rawhide ~]# rm -rf /var/cache/dnf/*
>>
>>
>> I do think you also flushed all the historical data on what packages
>> were installed from what repositories
>
>
> no - that woul
Am 08.11.2014 um 20:21 schrieb Nico Kadel-Garcia:
[root@rawhide ~]# rm -rf /var/cache/dnf/*
I do think you also flushed all the historical data on what packages
were installed from what repositories
no - that would be
rm -rf /var/lib/yum/*
rm -rf /var/lib/dnf/*
and yes i delete them regul
On Fri, Nov 7, 2014 at 3:31 PM, Reindl Harald wrote:
> the meta-data are fat
> look below
The metadata are bulky, fairly monolithic databases. They cannot
easily support incremental updates of the metadata because they are
compressed, singular files storing data for all available packages.
The b
Am 07.11.2014 um 17:53 schrieb Rahul Sundaram:
On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore wrote:
/etc/yum.repos.d/fedora-updates.repo on f21 has
metadata_expire=6h
I was looking at dnf since the discussion is about dnf
where do you see DNF using other than "/etc/yum.repos.d/"
DNF
Hi
On Fri, Nov 7, 2014 at 1:19 AM, Dennis Gilmore wrote:
>
> /etc/yum.repos.d/fedora-updates.repo on f21 has
> metadata_expire=6h
>
I was looking at dnf since the discussion is about dnf
> and the metadata right now for f21 updates is an empty repo with no
> packages in it f20 updates repo
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 19 Oct 2014 22:56:40 -0400
Rahul Sundaram wrote:
> Hi
>
> On Sun, Oct 19, 2014 at 9:52 PM, Nico Kadel-Garcia wrote:
>
> > It's a rough figure, from
> > http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
> >
>
> Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 6 Oct 2014 08:16:30 -0700
"Gerald B. Cox" wrote:
> On Mon, Oct 6, 2014 at 8:00 AM, drago01 wrote:
>
> > I am not convinced that "being fast" and "download less" are
> > mutually exclusive when using deltas. So we should keep deltas
> > *and
On Mon, Oct 6, 2014 at 10:41 AM, Rahul Sundaram wrote:
> Hi
>
> One of the long standing features that were enabled by default in yum is
> support for delta rpms. dnf developers have disabled this and I think this
> change deserves a broader discussion
>
> https://bugzilla.redhat.com/show_bug.cg
On 10/17/2014 05:52 AM, poma wrote:
> On 06.10.2014 16:46, Jaroslav Reznik wrote:
>> - Original Message -
>>>
>>>
>>>
>>> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
On 6 October 2014 09:41, Rahul Sundaram wrote:
> Hi
>
> One of the long standing features that wer
Am 20.10.2014 um 13:57 schrieb Nico Kadel-Garcia:
On Mon, Oct 20, 2014 at 4:22 AM, Reindl Harald wrote:
Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald
wrote:
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:
On Mon, Oct 20, 2014 at 6:40 AM, Reindl Harald wrote:
>
> Am 20.10.2014 um 12:31 schrieb Gerd Hoffmann:
>>
>> On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
>>>
>>> Roberto Ragusa robertoragusa.it> writes:
>>>
Are compressed rpms completely impossible to diff efficiently by rsync?
>
On Mon, Oct 20, 2014 at 4:22 AM, Reindl Harald wrote:
>
>
> Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:
>>
>> On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald
>> wrote:
>>>
>>>
>>> Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald
On Sun, Oct 19, 2014 at 11:07 PM, Kevin Fenzi wrote:
> On Sun, 19 Oct 2014 21:52:00 -0400
> Nico Kadel-Garcia wrote:
>
>> It's a rough figure, from
>> http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
>> (a useful local mirror). Since the number of packages there changes
Am 20.10.2014 um 12:31 schrieb Gerd Hoffmann:
On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
Roberto Ragusa robertoragusa.it> writes:
Are compressed rpms completely impossible to diff efficiently by rsync?
In a word, yes. They're already compressed, so it's unlikely there would be
On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
> Roberto Ragusa robertoragusa.it> writes:
>
> > Are compressed rpms completely impossible to diff efficiently by rsync?
>
> In a word, yes. They're already compressed, so it's unlikely there would be
> any matching blocks between old and n
Hi,
> 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.
Maybe mirrormanager can give a hint in case it directs yum/dnf to a
onsite mirror?
cheers,
Gerd
--
deve
Am 20.10.2014 um 04:02 schrieb Nico Kadel-Garcia:
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald wrote:
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald
wrote:
#!/usr/bin/bash
basearch=`uname -i`
releasever=`rpm -q --qf "%{version}\n" fedo
On Sun, 19 Oct 2014 21:52:00 -0400
Nico Kadel-Garcia wrote:
> It's a rough figure, from
> http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
> (a useful local mirror). Since the number of packages there changes
> day to day, but are likely to increase monotonically over t
Hi
On Sun, Oct 19, 2014 at 9:52 PM, Nico Kadel-Garcia wrote:
> It's a rough figure, from
> http://mirrors.kernel.org/fedora/releases/20/Everything/x86_64/os/repodata/
>
That doesn't seem to be the right way to look at the numbers. In a local
system, there are two different repositories enable
On Sun, Oct 19, 2014 at 5:26 AM, Reindl Harald wrote:
>
> Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
>>
>> On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald
>> wrote:
>>>
>>> #!/usr/bin/bash
>>> basearch=`uname -i`
>>> releasever=`rpm -q --qf "%{version}\n" fedora-release`
>>> for g in `ls -1
On Sun, Oct 19, 2014 at 3:51 AM, Rahul Sundaram wrote:
> Hi
>
> On Sun, Oct 19, 2014 at 3:40 AM, Nico Kadel-Garcia wrote:
>>
>> Even then, though still means up to 60 MB * 15/month,
>
>
> Earlier you mentioned 50 MB. Now you claim 60 MB. Can you show where these
> figures are from?
>
> Rahul
It
Am 19.10.2014 um 06:37 schrieb Nico Kadel-Garcia:
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald wrote:
#!/usr/bin/bash
basearch=`uname -i`
releasever=`rpm -q --qf "%{version}\n" fedora-release`
for g in `ls -1b /var/cache/yum`
do
if [ -d /var/cache/yum/$g/packages ]
then
echo "/var/cac
Hi
On Sun, Oct 19, 2014 at 3:40 AM, Nico Kadel-Garcia wrote:
> Even then, though still means up to 60 MB * 15/month,
>
Earlier you mentioned 50 MB. Now you claim 60 MB. Can you show where
these figures are from?
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedorapr
On Sun, Oct 19, 2014 at 1:04 AM, Rahul Sundaram wrote:
> Hi
>
> On Sun, Oct 19, 2014 at 12:37 AM, Nico Kadel-Garcia wrote:
>>
>> . And the "bandwidth saving" is still badly
>> overshadowed by the necessary repodata bandwith from almost every run
>> of "reposync" in the model you've just described
Hi
On Sun, Oct 19, 2014 at 12:37 AM, Nico Kadel-Garcia wrote:
> . And the "bandwidth saving" is still badly
> overshadowed by the necessary repodata bandwith from almost every run
> of "reposync" in the model you've just described. 50 Megabytes, *every
> time* it runs unless the metadata for the
On Sat, Oct 18, 2014 at 8:28 PM, Reindl Harald wrote:
>
>
> Am 19.10.2014 um 02:19 schrieb Solomon Peachy:
>>
>> On Sat, Oct 18, 2014 at 07:00:19PM -0400, Nico Kadel-Garcia wrote:
>>>
>>>3) People who have a lot of hosts and high bandwidth, high speed
>>> local deployment requirements can, and
Am 19.10.2014 um 02:19 schrieb Solomon Peachy:
On Sat, Oct 18, 2014 at 07:00:19PM -0400, Nico Kadel-Garcia wrote:
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. Thi
On Oct 18, 2014 5:00 PM, "Nico Kadel-Garcia" wrote:
>
> On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox 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
On Sat, Oct 18, 2014 at 07:00:19PM -0400, Nico Kadel-Garcia wrote:
> 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
On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox 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
On Fri, Oct 17, 2014 at 9:58 AM, Tom Rivers wrote:
> My point was to say Linux users are usually more tech savvy than XBox and
> Playstation users. If they say they have a high speed connection and they
> don't and that decision ends up costing them more money in ISP costs, then
> that's on them
On Fri, Oct 17, 2014 at 2:44 PM, Tom Rivers wrote:
>
> I suppose I'm having trouble understanding that when you started this
> thread with:ble by default for many users. dnf should enable this
> configuration by default as well"
Yes, that was true when I posted it. As a result of this discussi
On 10/17/2014 14:24, Rahul Sundaram wrote:
Deltarpms is again enabled by default in Dnf a while back if you read
the bug report. Everything else has been an tangent, yes.
I suppose I'm having trouble understanding that when you started this
thread with:
On 10/6/2014 04:41, Rahul Sundaram w
Hi
On Fri, Oct 17, 2014 at 2:17 PM, Tom Rivers wrote:
>
> I would really like to know how you can equate that with my original
> point: "Hey, maybe instead of throwing Presto under the bus.."
We aren't though. Deltarpms is again enabled by default in Dnf a while
back if you read the bug repo
On 10/17/2014 13:19, Rahul Sundaram wrote:
For the last time, my point is that: "smart" and "stupid" is not
determined by whether a user understands bandwidth/processor
considerations.
I completely understand that not comprehending all of the complexities
of bandwidth/processor consideration
Am 17.10.2014 um 19:45 schrieb drago01:
1) deltarpms -> low bandwidth use but takes a while to apply the updates
2) no deltarpms -> high bandwidth use but faster updates application.
So now people suggest the user (or the distro) has to either choose 1) or 2) ...
What I am suggesting is adding
On Fri, Oct 17, 2014 at 6:50 PM, Reindl Harald wrote:
>
> Am 17.10.2014 um 17:07 schrieb drago01:
>
>> On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius
>> wrote:
>>>
>>> On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
>
>
> Because it makes
Hi
On Fri, Oct 17, 2014 at 1:03 PM, Tom Rivers wrote:
> If you deconstruct the sentence you quoted above, it boils down to the
> subject "users" and the predicate "aren't". Therefore I said quite
> specifically that users ARE NOT "too stupid to understand
> bandwidth/processor considerations."
On 10/17/2014 11:29, Rahul Sundaram wrote:
On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote:
I didn't call them stupid - in fact I suggested just the opposite.
Go back and read what I wrote.
I did. You said "My point is that users aren't too stupid to
understand bandwidth/processor
On 10/17/2014 12:11, Gerald B. Cox wrote:
I think you're setting up a false equivalency here. There is a
difference between the requirements of say an XBOX or Playstation user
and that of updating a Fedora system. If given the choice, most
people will say "Yes, I have a high speed connection.
Am 17.10.2014 um 17:07 schrieb drago01:
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do bo
On Fri, Oct 17, 2014 at 5:52 PM, Ralf Corsepius wrote:
> On 10/17/2014 05:07 PM, drago01 wrote:
>>
>> On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius
>> wrote:
>>>
>>> On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
>
>
> Because it makes n
On 10/17/2014 06:00 PM, Matthew Miller wrote:
Everyone: please remember the code of conduct here, and advance the
conversation in a productive way or take it elsewhere. Thank you.
Well, then please explain, how you expect people to express fundamental
disagreement with somebody's rationale, if
On Fri, Oct 17, 2014 at 7:24 AM, Tom Rivers wrote:
> If the proper configuration can be determined automagically, then by all
> means just do it. My point is that users aren't too stupid to understand
> bandwidth/processor considerations. The configuration of how much
> bandwidth/processor time
On Mon, Oct 6, 2014 at 8:07 AM, Stephen Gallagher wrote:
[ . . . ]
>
> It would be nice to see if we can find ways to improve the performance
> of the deltarpm reconstruction instead. Much of the time is spent on
> compression/decompression tasks which *should* be massively parallel; we
> should
Everyone: please remember the code of conduct here, and advance the
conversation in a productive way or take it elsewhere. Thank you.
--
Matthew Miller
Fedora Project Leader
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of
On 10/17/2014 05:07 PM, drago01 wrote:
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius wrote:
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both
Hi
On Fri, Oct 17, 2014 at 11:09 AM, Tom Rivers wrote:
I didn't call them stupid - in fact I suggested just the opposite. Go back
> and read what I wrote.
>
I did. You said "My point is that users aren't too stupid to understand
bandwidth/processor considerations". I am just saying even if on
On 10/17/2014 10:43, Rahul Sundaram wrote:
Wile users might be able to handle such questions (I would avoid
calling them stupid even otherwise)
I didn't call them stupid - in fact I suggested just the opposite. Go
back and read what I wrote.
, it is contrary to the goals of the installer. T
On 06.10.2014 16:46, Jaroslav Reznik wrote:
> - Original Message -
>>
>>
>>
>> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
>>> On 6 October 2014 09:41, Rahul Sundaram wrote:
Hi
One of the long standing features that were enabled by default in yum is
support for
On Fri, Oct 17, 2014 at 5:02 PM, Ralf Corsepius wrote:
> On 10/17/2014 04:24 PM, Tom Rivers wrote:
>>
>> On 10/17/2014 10:05, drago01 wrote:
>>>
>>> Because it makes no sense and pushes it to the user. The os (i.e we)
>>> should handle that. In that case we should do both 1) have lower
>>> bandwit
On 10/17/2014 04:24 PM, Tom Rivers wrote:
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. T
Hi
On Fri, Oct 17, 2014 at 10:24 AM, Tom Rivers wrote:
>
> If the proper configuration can be determined automagically, then by all
> means just do it. My point is that users aren't too stupid to understand
> bandwidth/processor considerations. The configuration of how much
> bandwidth/process
On 10/17/2014 10:05, drago01 wrote:
Because it makes no sense and pushes it to the user. The os (i.e we)
should handle that. In that case we should do both 1) have lower
bandwith requirements (i.e use deltas) *and* 2) have fast installation
of updates. Those two goals are not mutually exclusive
On Fri, Oct 17, 2014 at 2:53 PM, Tom Rivers wrote:
> On 10/17/2014 05:09, Reindl Harald wrote:
>>
>> on a 56kbit modem you don't want to download the full RPMs and on a
>> 150Mbit line the download will always be faster than rebuild the RPM
>
>
> Perhaps this has already been suggested, but why no
On 10/17/2014 05:09, Reindl Harald wrote:
on a 56kbit modem you don't want to download the full RPMs and on a
150Mbit line the download will always be faster than rebuild the RPM
Perhaps this has already been suggested, but why not ask a question
during the installation of the OS? For example
Roberto Ragusa robertoragusa.it> writes:
> Are compressed rpms completely impossible to diff efficiently by rsync?
In a word, yes. They're already compressed, so it's unlikely there would be
any matching blocks between old and new rpms for rsync to take advantage of.
(You can verify this by tryi
Am 17.10.2014 um 10:55 schrieb Roberto Ragusa:
On 10/06/2014 07:25 PM, Reindl Harald wrote:
the last discussions suggested that the result needs to be *identical* to the
full RPM downloaded for not break signatures
Bizarre design; the signature should protect the content (uncompressed), not
Am 17.10.2014 um 10:49 schrieb Roberto Ragusa:
On 10/06/2014 07:57 PM, Reindl Harald wrote:
oh no - don't tie all together for reasons which did not destory the world over
years - it is a damned good design that the part dealing with rpm packages
don't need to know anything aboutt delta rpms
On 10/06/2014 07:25 PM, Reindl Harald wrote:
> the last discussions suggested that the result needs to be *identical* to the
> full RPM downloaded for not break signatures
Bizarre design; the signature should protect the content (uncompressed), not
the transport method (compressed).
--
Robe
On 10/06/2014 07:57 PM, Reindl Harald wrote:
>
> oh no - don't tie all together for reasons which did not destory the world
> over years - it is a damned good design that the part dealing with rpm
> packages don't need to know anything aboutt delta rpms because the normal
> packages are created
On 10/17/2014 05:40 AM, Gerald B. Cox 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 ramificati
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 defau
Gerald B. Cox composed on 2014-10-16 12:52 (UTC-0700):
> Kevin Kofler wrote:
>> And parallelization (as others in the thread have suggested) will not help
>> at all on the single-core machine I'm typing this on.
> Single-Core? Really Kevin? Even the One Laptop Per Child machines are
> dual-cor
On Thu, Oct 16, 2014 at 8:00 AM, Kevin Kofler
wrote:
> And parallelization (as others in the thread have suggested) will not help
> at all on the single-core machine I'm typing this on.
>
Single-Core? Really Kevin? Even the One Laptop Per Child machines are
dual-core. ;-)
--
devel mailing li
Ian Malone wrote:
> "I have an internet flatrate at 150 mbs, and downloading the full rpms
> is ALOT faster than the the work that the delta rpms requires."
>
> Wow. Good to see normal users are taken into account.
I have a normal Austrian broadband connection, and it is still much faster
to jus
On Mon, Oct 6, 2014 at 9:55 PM, Jonathan Dieter wrote:
> On 10/06/2014 08:57 PM, Reindl Harald wrote:
>>
>> Am 06.10.2014 um 19:45 schrieb Florian Festi:
>>>
>>> The way of getting around all this unnecessary computation is
>>> establishing trust via the deltarpm itself and giving up the idea of
>
On 10/06/2014 08:57 PM, Reindl Harald wrote:
Am 06.10.2014 um 19:45 schrieb Florian Festi:
The way of getting around all this unnecessary computation is
establishing trust via the deltarpm itself and giving up the idea of
reconstructing the originally rpm as a prove of everything worked out
just
On 10/06/2014 07:53 PM, Jonathan Dieter wrote:
As mentioned elsewhere, the problem *is* signatures. yum (quite
rightly) refuses to install an rpm whose signature doesn't match the one
in the primary repodata. And I believe that the signature in the RPM is
also over the whole compressed rpm. To
Am 06.10.2014 um 19:45 schrieb Florian Festi:
On 10/06/2014 06:53 PM, Jonathan Dieter wrote:
Get to coding. ;)
As mentioned elsewhere, the problem *is* signatures. yum (quite
rightly) refuses to install an rpm whose signature doesn't match the one
in the primary repodata. And I believe that
On 10/06/2014 06:53 PM, Jonathan Dieter wrote:
>> Get to coding. ;)
>
> As mentioned elsewhere, the problem *is* signatures. yum (quite
> rightly) refuses to install an rpm whose signature doesn't match the one
> in the primary repodata. And I believe that the signature in the RPM is
> also over
Ok I think the above thread explains it, the Jonathan's mail lists what
would be needed and it looks like there are some blockers on the infra
side. Disregard.
--
Later,
Lukas #lzap Zapletal
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/dev
On Mon, Oct 6, 2014 at 7:01 PM, Florian Festi wrote:
> On 10/06/2014 05:16 PM, Gerald B. Cox wrote:
>> The fact that some users have more bandwidth means exactly
>> what? Most people also have faster processors and disks now. It is
>> more efficient from a networking perspective to minimize unne
Am 06.10.2014 um 19:18 schrieb Lukas Zapletal:
because it needs to build the complete xz-compressed RPM
there was a discussion here not that long ago
Is the XZ the only option for RPMs now? Can't it do it uncompressed? Or
at least gzip -1.
Or Rich can add new feature to his ultra-blazing-fast
> because it needs to build the complete xz-compressed RPM
> there was a discussion here not that long ago
Is the XZ the only option for RPMs now? Can't it do it uncompressed? Or
at least gzip -1.
Or Rich can add new feature to his ultra-blazing-fast multi-core XZ
decompressor. Compression :-)
-
Bandwidth may be growing faster, but it started way behind processing
power. It hasn't caught up. The current definition from the FCC for
broadband is 4Mb. They are working to increase it, but that hasn't
happened. Carriers are looking for ways to throttle traffic. Your
assumption that everyon
On 10/06/2014 05:16 PM, Gerald B. Cox wrote:
> The fact that some users have more bandwidth means exactly
> what? Most people also have faster processors and disks now. It is
> more efficient from a networking perspective to minimize unnecessary
> traffic and use local processing. That was behin
FWIW, I wrote and maintained yum-presto before it was integrated into
yum. I've commented inline:
On 10/06/2014 06:31 PM, Kevin Fenzi wrote:
On Mon, 06 Oct 2014 09:07:33 -0400
Stephen Gallagher wrote:
The deltarpms were meant to serve two purposes
1) (lesser) Address the needs of users in
On Mon, 06 Oct 2014 09:07:33 -0400
Stephen Gallagher wrote:
> The deltarpms were meant to serve two purposes
>
> 1) (lesser) Address the needs of users in developing countries (where
> Fedora is fairly popular) and bandwidth concerns are very
> considerable. Many of these users have connections
On Mon, Oct 6, 2014 at 8:00 AM, drago01 wrote:
> I am not convinced that "being fast" and "download less" are mutually
> exclusive when using deltas. So we should keep deltas *and* make them
> faster.
>
Exactly. The fact that some users have more bandwidth means exactly what?
Most people also h
On Mon, Oct 6, 2014 at 4:46 PM, Jaroslav Reznik wrote:
> - Original Message -
>>
>>
>>
>> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
>> > On 6 October 2014 09:41, Rahul Sundaram wrote:
>> > > Hi
>> > >
>> > > One of the long standing features that were enabled by default in yum
- Original Message -
>
>
>
> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
> > On 6 October 2014 09:41, Rahul Sundaram wrote:
> > > Hi
> > >
> > > One of the long standing features that were enabled by default in yum is
> > > support for delta rpms. dnf developers have disabled
On Mon, Oct 6, 2014 at 3:48 PM, Gerd Hoffmann wrote:
> Hi,
>
>> > It would be nice to see if we can find ways to improve the performance
>> > of the deltarpm reconstruction instead. Much of the time is spent on
>> > compression/decompression tasks which *should* be massively parallel
>>
>> s/mas
Hi,
> > It would be nice to see if we can find ways to improve the performance
> > of the deltarpm reconstruction instead. Much of the time is spent on
> > compression/decompression tasks which *should* be massively parallel
>
> s/massively parallel/not done at all/ ... but we had this discussi
On Mon, Oct 6, 2014 at 3:07 PM, Stephen Gallagher wrote:
>
>
>
> On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
>> On 6 October 2014 09:41, Rahul Sundaram wrote:
>> > Hi
>> >
>> > One of the long standing features that were enabled by default in yum is
>> > support for delta rpms. dnf deve
On Mon, Oct 06, 2014 at 12:00:04PM +0100, Richard W.M. Jones wrote:
> The amount of time taken to rebuild rpms from delta rpms meant that
> they didn't seem to save anything for me.
It's not about saving *time*; it's about reducing the amount of data
sent over the wire -- this is particularly imp
On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote:
> On 6 October 2014 09:41, Rahul Sundaram wrote:
> > Hi
> >
> > One of the long standing features that were enabled by default in yum is
> > support for delta rpms. dnf developers have disabled this and I think this
> > change deserves a bro
Am 06.10.2014 um 13:00 schrieb Richard W.M. Jones:
On Mon, Oct 06, 2014 at 04:41:07AM -0400, Rahul Sundaram wrote:
One of the long standing features that were enabled by default in yum is
support for delta rpms. dnf developers have disabled this and I think this
change deserves a broader discu
On Mon, Oct 06, 2014 at 04:41:07AM -0400, Rahul Sundaram wrote:
> Hi
>
> One of the long standing features that were enabled by default in yum is
> support for delta rpms. dnf developers have disabled this and I think this
> change deserves a broader discussion
>
> https://bugzilla.redhat.com/sh
On 6 October 2014 09:41, Rahul Sundaram wrote:
> Hi
>
> One of the long standing features that were enabled by default in yum is
> support for delta rpms. dnf developers have disabled this and I think this
> change deserves a broader discussion
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1148
Hello All!
2014-10-06 12:41 GMT+04:00 Rahul Sundaram :
> Hi
>
> One of the long standing features that were enabled by default in yum is
> support for delta rpms. dnf developers have disabled this
At last!
--
With best regards, Peter Lemenkov.
--
devel mailing list
devel@lists.fedoraproject.o
91 matches
Mail list logo
