Written by hit801 the 3 Apr 12 at 18:26.

Instead of checking and downloading data of more than 10 MB and most importantly wasting time, Software update should use a system footprint file! Or updater should prepare a file of few Kb which has signature/information of all the system installation and software versions currently installed. Whenever user checks for update system should compare this local system file with updated file which lies on update server. Any changes should be reflected in output on local computer as updates ready for download/installation. This will certainly saves time and bandwidth.

Instead of checking and downloading data of more than 10 MB and most importantly wasting time, Software update should use a system footprint file! Or updater should prepare a file of few Kb which has signature/information of all the system installation and software versions currently installed. Whenever user checks for update system should compare this local system file with updated file which lies on update server. Any changes should be reflected in output on local computer as updates ready for download/installation. This will certainly saves time and bandwidth.

Written by puxkggn the 6 Apr 12 at 12:46.

After checking a general date to see if a piece of software has a newer update available. The following things can be done to do this very effective and efficient:

Instead of complete files you could use checksums to check if files are the same.
Very effective and it's guaranteed to give good results when implemented good. We also don't need to compare the dates because the repository can check if the checksum coincidences with an older, newer or unknown version of the file. In the case of unknown the package manager should avoid messing with the file and reporting the situation to the User before doing anything.

Instead of replacing whole files could make something that only replaces the parts to update a file from a previous version to a next version. This could be implemented at the Ubuntu package manager and the Ubuntu repository software so that software developers don't have to make extra packages. Making deltas can even be fully automated. And very efficient: only make delta when a user is detected with a previous version who wants to update to a newer version. Generate delta between two version from packages in warehouse. Then cache the delta update files to speed up serving of them.

Very efficient without loosing effectiveness.

After checking a general date to see if a piece of software has a newer update available. The following things can be done to do this very effective and efficient: Instead of complete files you could use checksums to check if files are the same. Very effective and it's guaranteed to give good results when implemented good. We also don't need to compare the dates because the repository can check if the checksum coincidences with an older, newer or unknown version of the file. In the case of unknown the package manager should avoid messing with the file and reporting the situation to the User before doing anything. Instead of replacing whole files could make something that only replaces the parts to update a file from a previous version to a next version. This could be implemented at the Ubuntu package manager and the Ubuntu repository software so that software developers don't have to make extra packages. Making deltas can even be fully automated. And very efficient: only make delta when a user is detected with a previous version who wants to update to a newer version. Generate delta between two version from packages in warehouse. Then cache the delta update files to speed up serving of them. Very efficient without loosing effectiveness.

Written by aadityabhatia the 20 Apr 12 at 11:01.

We all love rsync because it transfers the deltas only. Why reinvent the wheel?

We all love rsync because it transfers the deltas only. Why reinvent the wheel?

Written by ki4jgt the 28 Apr 12 at 00:59.

A service could be established for broadband users who are limited in bandwidth (it could be implemented into the software center). The service would manage the user's repositories (updating locally) and push updates to the client. The user would be allowed to add additional repositories. This would allow the user to only receive what updates were needed for their particular system.

EDIT: If the user wanted to update the available applications, they could do that as well.

A service could be established for broadband users who are limited in bandwidth (it could be implemented into the software center). The service would manage the user's repositories (updating locally) and push updates to the client. The user would be allowed to add additional repositories. This would allow the user to only receive what updates were needed for their particular system. EDIT: If the user wanted to update the available applications, they could do that as well.

Written by mitcoes the 17 Aug 12 at 10:21.

delta upgrades, using rsync and ...

With Ubuntu one keep the sources.list and a list of packages installed as system backup.

Almost every browser allows you to keep online your config allowing you to install at any computer your bookmarks, passwords,and web apps.

If ubuntu one can keep the list of packages installed, with a database format default + added packages and - uninstalled packages, each new distro upgrade reinstallation or installation at a new computer would be faster and it would be a great Ubuntu One service.

delta upgrades, using rsync and ... With Ubuntu one keep the sources.list and a list of packages installed as system backup. Almost every browser allows you to keep online your config allowing you to install at any computer your bookmarks, passwords,and web apps. If ubuntu one can keep the list of packages installed, with a database format default + added packages and - uninstalled packages, each new distro upgrade reinstallation or installation at a new computer would be faster and it would be a great Ubuntu One service.