http://brainstorm.ubuntu.com/item/13/ Ability to download only changed bits of files and use much less bandwidth.
Scope and Use Cases:
Ann has slow internet connection. She sees that there are 150MB of updates and decides not to update at all leaving her with vulnerable and buggy system.
Implementation Plan:
Adopt it from Debian?

Previously discussed here, but still not implemented: http://ubuntuforums.org/showthread.php?t=409916

[1766 votes] Solution #1: Auto-generated solution of idea #13


[85 votes] Solution #2: develop DEBs similar to deltaRPMs


[2 votes] Solution #3: 'dar' archives in deb packages


[2 votes] Solution #4: Download a diff and apply it to an old package file.


[1 votes] Solution #5: Copy/adapt the update method from Foresight


[2 votes] Solution #6: Use rsync to transport update-files


]]> en-us Thu, 28 Feb 2008 14:31:54 +0000 Sat, 09 Jul 2011 02:34:12 +0000 QAPoll module http://brainstorm.ubuntu.com/idea/13/ Thu, 28 Feb 2008 14:32:55 +0000 Thu, 28 Feb 2008 17:59:44 +0000 Thu, 28 Feb 2008 19:12:11 +0000 I think of this: Synaptic generates a Python script. Running the script on other machine with Internet access (Windows with OpenOffice with built-in Python; or other Linux machine with Python installed) would download all needed packages into a singles direcotry. Than you just show this directory to Synaptic and it installs the packages, and also updates the package database information.]]> Thu, 28 Feb 2008 20:12:17 +0000 Fri, 29 Feb 2008 00:32:43 +0000
If disk space on the server isn't too much an issue it could work like so:
1) make a 100% par2 set on the patch server (this is faster in an extreme fashion with par3 (100x), par2 also has a limitation of 32767 blocks where par3 would have one much higher. Given patches I see tend to top-end at the hundreds of MB this probably wouldn't be a concern in block-size.)

2) Retrieve .par2 from patch server

3) Run .par2 against a script-given directory (directories would need to be implemented)

4) request as many blocks as are needed to repair all blocks of 'damage' (this process of repair would be faster with par3 in some situations)

As long as the tool being patched isn't intolerant of being reset completely to default any version could be reverted to any other version currently stored on the patch server. I imagine it wouldn't be terribly impossible to script something to handle the reverse direction if necessary to revert something everywhere at once in userland.

It's worth noting that tampering with the par2 data breaks the math function and will fail the repair. I suppose one could alter the par2 data entirely but it would require re-paring the entire set as no one repair block has any direct bearing on a particular section of data. though it's not exactly hard to find a hash that would work if the security folks want to be paranoid. (Which they probably would to detect tampering before the parity process. heh)

I'm no OS coder but that's my two cents on the matter of improved choice of patch algorithm.]]> Fri, 29 Feb 2008 02:46:23 +0000 Fri, 29 Feb 2008 02:57:41 +0000 https://bugs.launchpad.net/ubuntu/+bug/190926]]> Fri, 29 Feb 2008 09:50:49 +0000 Russia is one of examples: we still have very limited access to the Internet over the country. Slow and expensive.

Delta updates will save money, time and server resources.]]> Fri, 29 Feb 2008 11:00:57 +0000 Unpacking previous and updated debs and performing bsdiff on files show differences about 1% of package size or less for larger ones!!!
One of previous minor updates of OOo (~100 MiB or such), turns in 10-20 KiB of binary diff. This could be fantastic savings...]]> Fri, 29 Feb 2008 11:11:57 +0000
BTW,Ubuntu got these vast resources,then why cant they use conary package manager used in Foresight Linux etc?AFAIK Conary can update using the changed file portions etc :)]]> Fri, 29 Feb 2008 13:51:25 +0000 Fri, 29 Feb 2008 14:05:41 +0000
Ex: OpenOffice doesn't re-download it's 100MB install, rather only the changed code.

+1]]> Fri, 29 Feb 2008 16:10:05 +0000 Sat, 01 Mar 2008 03:30:18 +0000
Firstly, one of Linux's best growth opportunities has been in 3rd world countries, many of which have much less access to the Internet or it's more costly. Automatic delta based updates would drive adoption in these areas.
I already saw South Africa and Russia mentioned in the comments above.

Secondly and most obviously, it cuts down on bandwidth at Canonical.

Thirdly, it cuts down on bandwidth chez moi.

Fourthly, since delta base updates require the end user to store file on their side, it makes it more practical if Canonical or end users wanted to distribute updates over P2P.

You could imagine other senarios also, such as bandwidth savings for corporate install servers.

etc...
]]> Sat, 01 Mar 2008 07:19:14 +0000
I remember an MMORPG project I was involved with a while back that decided to do it regardless because of the efficiency, but someone (Microsoft, I think) had the idea patented with the Windows Update jazz.

I'm not really sure if this is the case/has changed, but it's worth double checking. Software patents are a pain.]]> Sat, 01 Mar 2008 13:42:32 +0000 Sat, 01 Mar 2008 15:24:15 +0000
By the way: the fact that SuSE had this feature and ubuntu hasn't was the reason why i waited so long to switch to ubuntu. But now i'm very happy with it...]]> Sat, 01 Mar 2008 15:40:25 +0000 I can't even imagine a single reason to reject this idea.]]> Sat, 01 Mar 2008 17:53:20 +0000
Did some testing on my own on packages like wine where there is currently a lot of development you only save a about 50% bandwidth.

But on packages like the Linux kernel and libc updates I was able to update from the original release to the current release in about 10seconds for libc and 12s for the kernel using standard ASL line.]]> Mon, 03 Mar 2008 07:13:13 +0000 I'm happy to read and vote for this!]]> Mon, 03 Mar 2008 14:24:23 +0000 Mon, 10 Mar 2008 15:40:15 +0000 Thu, 13 Mar 2008 12:33:17 +0000 ]]> Wed, 02 Apr 2008 16:05:56 +0000 Thu, 24 Apr 2008 08:07:19 +0000 Tue, 06 May 2008 15:14:25 +0000
People complaining that their internet is slow whilst downloading updates for instance, would be a lot happier automatically if they only had to download 3MB instead of 50MB


+1.


]]> Sun, 08 Jun 2008 14:48:22 +0000 Wed, 18 Jun 2008 18:38:54 +0000
http://samba.anu.edu.au/rsync/rsync-and-debian/rsync-and-debian.html

What about precomputing file-grained checksums in the build farm?]]> Mon, 23 Jun 2008 10:14:19 +0000 Wed, 02 Jul 2008 16:59:57 +0000
1) updates for features that are not relevant
2) minor updates for features that are relevant (eg developer versions being tested)

In the case of (1) the problem could also be addressed by doing greater system profiling and only updating for systems that will benefit. eg in the linked #11000 idea the complaint is that "* Fix broadcom Makefile" produces a large download and the user doesn't have any broadcom stuff. So if the package management system were cleverer it would know not to download that upgrade because the system has no broadcom hardware.

This is a substantially larger alteration than that needed for (2), namely the previously widely touted binary diff/patch.]]> Mon, 04 Aug 2008 15:18:22 +0000
Any ideas, how to make it happen?]]> Sat, 13 Sep 2008 11:59:31 +0000 http://digg.com/linux_unix/Ubuntu_Delta_patch_based_updates?OTC-fft-4]]> Sat, 13 Sep 2008 12:01:30 +0000
]]> Sat, 13 Sep 2008 12:19:17 +0000 Wed, 08 Oct 2008 12:59:03 +0000
Someone designed a delta system for Gentoo that worked automatically. You'd use a special server set up that would mirror the updates, it would work out the diff and only submit the changes between the cached copy of it on your own machine (it only worked when you had a previous downloaded copy). And it would cache the diff.

With Ubuntu its even easier, because updates get released on gentoo faster then you can compile the last version. ]]> Wed, 08 Oct 2008 13:08:08 +0000
With a bit of patience, we'll get this idea implemented.
(In the meantime, vote +1 on this idea)]]> Sat, 11 Oct 2008 08:25:42 +0000 Sat, 11 Oct 2008 08:56:35 +0000 Fri, 17 Oct 2008 02:15:26 +0000
Patches would be great for those who update regularly, but full package updates can be used if the user is more than 1-3 version updates behind.

4 consecutive patches is less bandwidth effective.]]> Wed, 12 Nov 2008 15:04:37 +0000 Mon Nov 17 21:44:05 EST 2008


$ sudo apt-get install gnome-backgrounds
The following NEW packages will be installed:
gnome-backgrounds
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 9782kB of archives.
.........................................
Setting up gnome-backgrounds (2.24.0-0ubuntu1) ...


$ date
Mon Nov 17 22:31:48 EST 2008



Enough said.
]]> Tue, 18 Nov 2008 03:33:44 +0000 Tue, 09 Dec 2008 09:49:17 +0000 Fri, 19 Dec 2008 05:56:02 +0000 Sun, 28 Dec 2008 18:38:39 +0000 Sun, 28 Dec 2008 19:41:10 +0000 You cant write a patch for binaries.

Of course you can.

Besides, the packages are not binaries; they are a collection of many binary files. In most upgrades, many of these files are not changed, so even a diff that includes only the changed files would be an improvement.]]> Mon, 29 Dec 2008 21:46:53 +0000 Wed, 14 Jan 2009 23:16:32 +0000 Thu, 02 Apr 2009 09:11:22 +0000
I've got about 900 megs of games installed from Synaptic. I'd love the updates to be patch-based so I'm not downloading 600megs of duplicate fluff every release cycle!!

And just think how much easier it would be on the mirrors.]]> Fri, 12 Jun 2009 18:31:39 +0000 Fri, 12 Jun 2009 21:13:35 +0000
It would be great if I could update my Kubuntu in the same way I upgraded my Fedora, especially because my Kubuntu is behind a slower connection to the Internet with the monthly bandwith limit of 1 GiB.]]> Sun, 09 Aug 2009 11:24:46 +0000 There has/had been some discussion on this topic sometime back. Please refer to thread https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-August/009201.html as well as a blog entry written sometime earlier by yours truly on the same subject.

http://flossexperiences.wordpress.com/2008/12/19/better-package-management/]]> Fri, 23 Oct 2009 19:32:44 +0000 Sat, 24 Oct 2009 09:49:47 +0000 Mon, 21 Dec 2009 21:28:54 +0000 Status: http://status.ubuntu.com/ubuntu-oneiric/u/mvo.html]]> Sat, 09 Jul 2011 02:34:12 +0000