You are not logged in.
To think that 1Mb/s was once considered broadband...
Well, I haven't done -Syu for about two weeks, and as a result, today the update would weigh in at 700 MB (KDE 4.6.1, kernel, libreoffice, etc.) - a whole CDROM worth of updated packages, most of which have probably changed less than 1% on a byte-by-byte basis. I am on 1Mb/s connection with a draconian monthly transfer limit, 14% of which would be exhausted by this single update.
What can be done by an average Arch Linux user to hasten the adoption of pacman's delta technology by the official repositories?
Offline
Vote for the request I guess:
https://bugs.archlinux.org/task/18590
And writing patches for the mentioned scripts?
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
Well, I haven't done -Syu for about two weeks, and as a result, today the update would weigh in at 700 MB (KDE 4.6.1, kernel, libreoffice, etc.) - a whole CDROM worth of updated packages, most of which have probably changed less than 1% on a byte-by-byte basis. I am on 1Mb/s connection with a draconian monthly transfer limit, 14% of which would be exhausted by this single update.
I'm interested in why you assume less than 1% change. For compiled binaries I doubt deltas would really save all that much (or anything at all), the savings would be on the unchanged data files, which would be considerably less than 99% of total package size.
Yes there will be space-savings, but I highly doubt they'd be anywhere near that amount.
What can be done by an average Arch Linux user to hasten the adoption of pacman's delta technology by the official repositories?
The best way is to get coding. Bug requests only help for things which aren't already known, votes are of minimal value at best (if noone has bothered so far, noone will really care about the votes). Most big changes in Arch are community-implemented at least initially. See the example of [multilib] growing out of the multitude of lib32- packages, or the current work on systemd.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Have a look at
https://bbs.archlinux.org/viewtopic.php?id=92085
home: 635.20MB => 227.25MB (36% of reg)
work: 739.77MB => 301.14MB (40% of reg)
with delta: Total Download Size: 13.00 MB
and without: Total Download Size: 29.78 MB
฿ 18PRsqbZCrwPUrVnJe1BZvza7bwSDbpxZz
Offline
Not directly related, but you should update more frequently, and if you are truly concerned about your bandwidth usage, consider lighter alternatives instead of KDE and libreoffice.
Offline
Not directly related, but you should update more frequently
I'm sorry but this is just plain incorrect. Updating more frequently consumes more bandwidth in the long run because you do not skip any updates. If an example package happens to be updated on each day for seven consecutive days, then by updating every day you will download seven times as many versions of this package as you would if you only updated on the last of the seven days. For another example, some of the KDE 4.6.1 packages that I am downloading right now have package version 4.6.1-2. Had I updated every day, I would have downloaded their 4.6.1-1 versions too.
Offline
He said "not directly related", so that wasn't about your bandwidth problem, more of a "Arch runs better if you update more frequently" and this is really true! Of course you, Rulatir, are right, all in all you consume less bandwidth if you update less frequently!
What tomk mentioned after that is true of course, you won't have such big updates with lighter DEs. Give Cdh's link a try, because there IS a delta repo. I guess it won't save you that much bandwidth when it comes to big binary files (like ngoonee already mentioned), which are all over KDE's packages.
So, I summarized the posts from here and in my opinion everything important has been said. Consider switching to the delta repo, I hope it works! And consider switching to a lighter DE. I for example only use lightweight software and my monthly bandwidth with pacman is about ... I don't know, never measured it, but I guess it's 200MB TOPS! And I update EVERY DAY!
Offline
I know of that delta repo Cdh linked to. I've been watching it for a while now, and my impression is that it tends to be 3-5 weeks behind the official repos.
Last edited by Rulatir (2011-03-10 10:34:50)
Offline
I know of that delta repo Cdh linked to. I've been watching it for a while now, and my impression is that it tends to be 3-5 weeks behind the official repos.
When you update every 2 weeks, the damage isn't that big then right? You're still quite ahead of a lot of other distros, less breakage because it's been tested more etc.
ᶘ ᵒᴥᵒᶅ
Offline
<blockquote>When you update every 2 weeks, the damage isn't that big then right?</blockquote>
When I am forced to update every 2 weeks, the damage to my forehead from frequent violent encounters with my desk is immense
That is precisely what I want to avoid by using an up-to-date delta repo.
Offline
Pacman already has delta support, so you'll just need to find a repo. I don't believe there's any official plans to support deltas, but there's at least 1 user who ran an i686 delta repo. Not sure if this is still up to date, or if you need 64-bit.
Also going to agree with tomk's sentiment that lighter software choices would alleviate this if you're bandwidth constrained.
Offline
<blockquote>When you update every 2 weeks, the damage isn't that big then right?</blockquote>
When I am forced to update every 2 weeks, the damage to my forehead from frequent violent encounters with my desk is immense
That is precisely what I want to avoid by using an up-to-date delta repo.
I meant in combination with the delta repo, as you said it is 3-5 weeks behind.
ᶘ ᵒᴥᵒᶅ
Offline
Also going to agree with tomk's sentiment that lighter software choices would alleviate this if you're bandwidth constrained.
I have some nasty experiences with supposedly lighter software turning out to be not so light in the end, much slower to run, and with (obviously) much less features.
Offline
Apologies if I wasn't clear earlier - and thanks Army for expanding on my brief suggestion.
Offline