Here are the most popular ideas ever about Update manager .
Check my hardware against application blackists BEFORE 'upgrading'
Written by r0g the 12 Jan 09 at 08:02.
New
My graphics hardware was added to the compiz hardware blacklist for the Intrepid release. Annoying asthis is I'm sure they had their reasons. Sadly though I had no idea about this until I 'upgraded' from Hardy and everything went bad without the possibility of undoing any of the changes.
Great.
Maybe the upgrade app could be made to check my (god damn!) hardware BEFORE 'upgrading' me.
In fact if ANY software blacklists ANY hardware should it not be standard practice to publish this info and have applications that do 'upgrading' check it first?
Roger.
PS.
To those smug people just dying to type 'you should have checked yourself before upgrading' really don't bother - my idea is to AUTOMATE SOMETHING THE COMPUTER CAN AND SHOULD DO FOR ME, not become a full time OS geek.
Solution #3:
Have Ubuntu check for incompatible hardware
Written by
Seph_VII the 14 Jan 09 at 21:14.
Before upgrading or installing Ubuntu, make it check an online(or on-cd, if installing from a LiveCD) blacklist of incompatible hardware. If incompatible hardware is found, make Ubuntu warn the user, and ask whether he/she still wants to continue.
Before upgrading or installing Ubuntu, make it check an online(or on-cd, if installing from a LiveCD) blacklist of incompatible hardware. If incompatible hardware is found, make Ubuntu warn the user, and ask whether he/she still wants to continue.
Solution #5:
undo function
Written by
ruben the 26 Jan 09 at 21:09.
The function i have in mind is a simple undo of an update or even a package installation.
Unlike apt-get --perge remove it would also delete any unneaded dependancies simmilar to autoremove. However this would make it possible to install updates and then if it didn't work undo the change. Including any movement of files or changes in other files.
The problem i see with an upgrade advisor is that it can never actually say if it will work as only trial and error can. Or at least in most cases. Also it is very possible that the upgrade advisor does not have all the correct information for all systems and thus advises incorrectly. Furthermore advice given need to be based on information gather beforehand. Thus an easy undo feature would make upgrading a lot less risky.
It would be even better if this feature could some how be accessed from recovery mode or a live cd to repair if the system was rendered unboot able. This feature should be a used in conjunction with an upgrade advisor. Perhaps more as a long run solution
The function i have in mind is a simple undo of an update or even a package installation.
Unlike apt-get --perge remove it would also delete any unneaded dependancies simmilar to autoremove. However this would make it possible to install updates and then if it didn't work undo the change. Including any movement of files or changes in other files.
The problem i see with an upgrade advisor is that it can never actually say if it will work as only trial and error can. Or at least in most cases. Also it is very possible that the upgrade advisor does not have all the correct information for all systems and thus advises incorrectly. Furthermore advice given need to be based on information gather beforehand. Thus an easy undo feature would make upgrading a lot less risky.
It would be even better if this feature could some how be accessed from recovery mode or a live cd to repair if the system was rendered unboot able. This feature should be a used in conjunction with an upgrade advisor. Perhaps more as a long run solution
Solution #6:
Related with idea #3: Implement Smolt
Written by
torkiano the 30 Jan 09 at 20:45.
Smolt is a hardware profiler to enable users to submit their hardware profiles during installation.
Smolt, like PackageKit from Fedora is also a distribution neutral tool and collects stats anonymously and sends it to a central database.
It became clear quite quickly that it does not make sense to have a per-distro solution for that - if we want to have momentum with a hardware database a combined effort promises the most.
Fedora and Opensuse already implemented it.
See
http://smolts.org/
http://www.osnews.com/story/20621/Smolt_gets_adopted_by_openSUSE
Smolt is a hardware profiler to enable users to submit their hardware profiles during installation.
Smolt, like PackageKit from Fedora is also a distribution neutral tool and collects stats anonymously and sends it to a central database.
It became clear quite quickly that it does not make sense to have a per-distro solution for that - if we want to have momentum with a hardware database a combined effort promises the most.
Fedora and Opensuse already implemented it.
See http://smolts.org/
http://www.osnews.com/story/20621/Smolt_gets_adopted_by_openSUSE
Ask for application restart after security update
Written by xfuser4 the 21 Aug 09 at 06:16.
New
There are sometimes very critical security updates for applications (like the last Pidign-Update).
Unfortunately the Update Manager doesn't inform the user, that the update is only effective, if the application is restarted after it.
Since suspend-2-ram works for now on many computers, some applications are only seldom restarted (e.g. Pidgin may run for several weeks).
In the case of pidgin this is even a security risk, since an application with a security leak might run for several weeks until the last security fixes will apply.
Solution #1:
Ask for restart of applications
Written by
xfuser4 the 21 Aug 09 at 06:16.
After kernel updates, we are asked for restarting the computer. If a (critical) update of an application have happened, the update manager should ask for an restart of the application (or inform the user about the need of a restart).
After kernel updates, we are asked for restarting the computer. If a (critical) update of an application have happened, the update manager should ask for an restart of the application (or inform the user about the need of a restart).
Solution #2:
Updater proposes auto-restart and restore of affected apps
If 1 or more critical updates have been installed, we are offered a checklist of all apps that will benefit from a restart. The dialogue makes clear that all listed apps will benefit from a restart (and maybe how) and that all checked apps will be automatically restarted with an attempt made to return the app to its previous state (subject to security or other important concerns). Examples: Transmission torrents return to their individual active/paused status, Pidgin either remains unlogged or autologs the last user, active OpenOffice docs are reopened.
Updater preferences allow the user to choose which update types appear on the checklist: "security", "bug fix", "new feature"
If 1 or more critical updates have been installed, we are offered a checklist of all apps that will benefit from a restart. The dialogue makes clear that all listed apps will benefit from a restart (and maybe how) and that all checked apps will be automatically restarted with an attempt made to return the app to its previous state (subject to security or other important concerns). Examples: Transmission torrents return to their individual active/paused status, Pidgin either remains unlogged or autologs the last user, active OpenOffice docs are reopened.
Updater preferences allow the user to choose which update types appear on the checklist: "security", "bug fix", "new feature"
Solution #3:
Only Prompt for application restart if X time elapsed since update.
Written by
lavinog the 31 Aug 09 at 17:07.
Annoying users with restart notices can deter users from updating in a timely manner.
To avoid displaying excessive restart prompts, the prompts should be displayed after a preset time if the application hasn't been restarted since the update.
User A was only going to be using pidgin for 20 minutes, he shouldn't be interrupted by a dialog asking him to put his conversation on hold for a restart.
User B performs updates, but leaves his computer idle for a couple of hours. When he comes back to his computer, he will see a dialog box explaining that the recent security update wont take affect until the application is restarted.
Annoying users with restart notices can deter users from updating in a timely manner.
To avoid displaying excessive restart prompts, the prompts should be displayed after a preset time if the application hasn't been restarted since the update.
User A was only going to be using pidgin for 20 minutes, he shouldn't be interrupted by a dialog asking him to put his conversation on hold for a restart.
User B performs updates, but leaves his computer idle for a couple of hours. When he comes back to his computer, he will see a dialog box explaining that the recent security update wont take affect until the application is restarted.
Solution #4:
Update the application without restart
I propose to update the application "on-fly". So you don't need to stop chatting if your instant messenger gets an update.
I propose to update the application "on-fly". So you don't need to stop chatting if your instant messenger gets an update.
Solution #5:
Show restart indicator in tray
Written by
adisk the 16 Sep 09 at 15:18.
Show restart indicator in tray.
Click on indicator show question for restart.
Show restart indicator in tray.
Click on indicator show question for restart.
Solution #6:
Send email notification to admin
Written by
adisk the 16 Sep 09 at 15:40.
Send email notification to admin. For servers only.
Send email notification to admin. For servers only.
Solution #7:
#5 but with more details
like #5, but when the "restart-indicator" is clicked it folds down to a list, the top entry saying
"some of your applications received important updates, but need to be restarted before these can take effect".
after that a list of applications in question and a "restart all" item follow.
if the user clicks on one of the apps it is restartet and disappears from the list.
if an app was manually restartet (by the user) it also disappears from the list.
if there are no more apps left the restart-indicator should close by itself.
sometimes system components receive updates which will only take effect after a full reboot. this can be incorporated by adding an item to the very bottom that says "In fact there are some udpates which require to restart the entire operating system. Restart now! "
like #5, but when the "restart-indicator" is clicked it folds down to a list, the top entry saying
"some of your applications received important updates, but need to be restarted before these can take effect".
after that a list of applications in question and a "restart all" item follow.
if the user clicks on one of the apps it is restartet and disappears from the list.
if an app was manually restartet (by the user) it also disappears from the list.
if there are no more apps left the restart-indicator should close by itself.
sometimes system components receive updates which will only take effect after a full reboot. this can be incorporated by adding an item to the very bottom that says "In fact there are some udpates which require to restart the entire operating system. Restart now! "
<img src="http://img390.imageshack.us/img390/5393/ubunturestartnotify.png">
Postpone (some) updates until system shutdown/reboot
Written by hspaans the 13 Jul 08 at 15:56.
New
Some updates trigger a warning that the system needs to be rebooted or an application an user maybe running needs to be restarted. Operating systems like Sun Solaris solve this by postpone that update until the system gets a shutdown/reboot. The user then isn't being annoyed with understandable messages and updates are being safely installed like a kernel or libc update for example.
Automatic backup before upgrading to new release
Written by michel.alexander the 7 Mar 09 at 13:24.
New
It's recommended to backup data and system configuration files before upgrading to a new release. It would be great to do this by just clicking on something like "backup my data and system configuration now" when starting the upgrade process.
Abandoned softwares are unusable after one year.
Written by qwerty800 the 4 Jun 09 at 20:33.
New
Take Jahshaka (the video editor) for exemple.
It once was one of the best and most used video editor in the professional world.
An open-source, linux software!
And then?
The project died near of 2007. And guess what? It's now completely uninstallable!
The only way to get it to work now is to MAKE IT RUN ON WINE!
An open source linux software!
Does it makes sense?
Solution #1:
Keep the old packages in the newer repositories.
In a world where softwares are very often abandonned because of a lack of motivation from the developpers, having an update every 6 month that completely changes the repositories is not a good idea.
We should at least keep some old packages (or make them redirect to newer ones) so that we can still use all of these abandoned softwares.
In a world where softwares are very often abandonned because of a lack of motivation from the developpers, having an update every 6 month that completely changes the repositories is not a good idea.
We should at least keep some old packages (or make them redirect to newer ones) so that we can still use all of these abandoned softwares.
Solution #2:
Add another URL to access it
Written by
Shady3D the 6 Jun 09 at 07:45.
the package manager will be cluttered with versions by adding older versions too, so just make another channel for it, so if someone wants it, just add the URL of the old repository.
the package manager will be cluttered with versions by adding older versions too, so just make another channel for it, so if someone wants it, just add the URL of the old repository.
Solution #3:
look for new maintainers
Written by
rakudave the 6 Jun 09 at 10:47.
Have a page where all abandoned projects are listed and where people can sign up to take over the maintenance of such a project.
Have a page where all abandoned projects are listed and where people can sign up to take over the maintenance of such a project.
Solution #4:
Add a "unsupported" repository section.
Why not simply add a "unsupported" repository branch along with the current main, universe, multiverse and restricted?
Then Canonical can disavow the packages, yet still provide easy access to those that need them.
Why not simply add a "unsupported" repository branch along with the current main, universe, multiverse and restricted?
Then Canonical can disavow the packages, yet still provide easy access to those that need them.
Solution #5:
Notify Bloggers, Who Will Provide Information About Maintained Software
If you are already using the software, moving it to an "unsupported" repository branch won't do much good. Why not have bloggers who specialize in Ubuntu applications make a quick announcement, and get it on sites such as
The Daily Ubuntu or
LXer ?
If you are already using the software, moving it to an "unsupported" repository branch won't do much good. Why not have bloggers who specialize in Ubuntu applications make a quick announcement, and get it on sites such as <a href="http://thedailyubuntu.blogspot.com/">The Daily Ubuntu</a> or <a href="http://lxer.com">LXer</a>?
Solution #6:
Associate the project with a bounty to attract new devs
Written by
ludovicc the 16 Jun 09 at 22:59.
In the package description in Synaptic, link the package to a donation page that you could create on fossfactory.org for example. Then update the package description in Ubuntu (requires some very minimal packaging skills).
The idea is that users of the package will look for more information about that package using the tools provided by Ubuntu, such as Synaptic, then be redirected to a donation site for that project. With enough donations, more developers can be attracted and revive the project.
In the package description in Synaptic, link the package to a donation page that you could create on fossfactory.org for example. Then update the package description in Ubuntu (requires some very minimal packaging skills).
The idea is that users of the package will look for more information about that package using the tools provided by Ubuntu, such as Synaptic, then be redirected to a donation site for that project. With enough donations, more developers can be attracted and revive the project.
Solution #7:
Improve backwards compatibility in the package system
Written by
krycek the 16 Oct 09 at 12:56.
Imagine that packages could be generate just once and be used in future releases without any extra work.
That would reduce significantly the work necessary by canonical developers for every release, since they could use the existing packages that weren't changed.
Users would be allow to use "unsupported" applications too.
That's not an easy solution, I know, but it is the one that has more benefits of all. In the long term, it would help all people involved.
Imagine that packages could be generate just once and be used in future releases without any extra work.
That would reduce significantly the work necessary by canonical developers for every release, since they could use the existing packages that weren't changed.
Users would be allow to use "unsupported" applications too.
That's not an easy solution, I know, but it is the one that has more benefits of all. In the long term, it would help all people involved.
Whats happend after the updates?
Written by TommyGee the 27 Feb 09 at 17:10.
New
I think it's not easy to know and discover all the benefits of the updates.
I like to know WHY my OS needs to upgrade something and the changes... fix, adds...
Hide content of update requests
Written by xfuser4 the 29 Jun 09 at 11:24.
New
While the automatic update of Ubuntu is great, it seems to be confusing to some users.
The problem is, that often there is a list of packages which are totally unknown to the user (like openssl, libwebkit or HAL).
A user that just don't know, what these packages mean, could be confused by the large set of information (esp. after a fresh install of Ubuntu). At least it will be useless for the user and if something went wrong, the user could not really tell what kind of update happened before the system failed, because the list was too long.
Solution #1:
Make a more condensed list
Written by
xfuser4 the 29 Jun 09 at 11:24.
Presenting the user all the details of a software update could be confusing. However the user is still interested in the meaning of a certain update.
Perhaps it would be better to condense the informations somehow. Instead of telling the user the name of all 10.000 packages which are part of OpenOffice, just tell her, that an update of OpenOffice happens. Instead of giving a list of cryptic system packages, just tell, that a set of system core packages will be updated.
Esp. the initial update after the system installation is very long and confusing...
Presenting the user all the details of a software update could be confusing. However the user is still interested in the meaning of a certain update.
Perhaps it would be better to condense the informations somehow. Instead of telling the user the name of all 10.000 packages which are part of OpenOffice, just tell her, that an update of OpenOffice happens. Instead of giving a list of cryptic system packages, just tell, that a set of system core packages will be updated.
Esp. the initial update after the system installation is very long and confusing...
Solution #2:
Give an "advance user" option
Written by
Rodrigo the 29 Jun 09 at 13:42.
Same as
idea #1 , which I personally believe is great. But then some more "advanced" user may like to know exactly what is happening in their systems.
So give them an option to see what packages (one by one) are being updated.
Same as idea #1, which I personally believe is great. But then some more "advanced" user may like to know exactly what is happening in their systems.
So give them an option to see what packages (one by one) are being updated.
Solution #3:
Move update details to an advanced view
Written by
jgoguen the 29 Jun 09 at 13:44.
Short version: Implement Solution 1, but allow the user to still see each individual package through an advanced view.
Long version: Condense update information into items more meaningful to average users, displaying only items such as "Firefox", "Evolution", "Core System", "OpenOffice.org", etc. but provide either a button or an option to display an "advanced view" that shows all packages.
Short version: Implement Solution 1, but allow the user to still see each individual package through an advanced view.
Long version: Condense update information into items more meaningful to average users, displaying only items such as "Firefox", "Evolution", "Core System", "OpenOffice.org", etc. but provide either a button or an option to display an "advanced view" that shows all packages.
Solution #4:
Solution #1 with an expandable tree.
Why not make each "main package" (ex: OpenOffice) the top of an expandable tree?
Hit the + beside the package and see all the related packages that will be updated.
+Gnome
-OpenOffice
=OpenOffice.org
=OpenOffice.org_lan_en_us
+GIMP
+Mozilla-Thunderbird
Why not make each "main package" (ex: OpenOffice) the top of an expandable tree?
Hit the + beside the package and see all the related packages that will be updated.
+Gnome
-OpenOffice
=OpenOffice.org
=OpenOffice.org_lan_en_us
+GIMP
+Mozilla-Thunderbird
Solution #5:
Hide list of updates
Written by
maccam94 the 20 Jul 09 at 23:30.
Initially display a window not much larger than a dialog box. Tell the user "It is recommended that you install # updates for your software." Have a "Show updates" button that expands the window and lists the individual updates. This choice would be remembered for future updates.
Initially display a window not much larger than a dialog box. Tell the user "It is recommended that you install # updates for your software." Have a "Show updates" button that expands the window and lists the individual updates. This choice would be remembered for future updates.
Update Notifier is Less Informative
Written by zalluth the 26 Oct 10 at 11:30.
New
When Ubuntu checking updates or downloading them in the background, update notifier just show package manager is running. So, I don't know whether it is checking updates or downloading them.
Solution #1:
Add Some Informative Message
Written by
zalluth the 26 Oct 10 at 11:30.
Honestly, I'm using Windows beside my Ubuntu. When it is downloading updates, the update icon in notification area show such this message on mouse over (downloading updates 10%). I think, adding some informative message in update notifier will make it more informative. Exp:
- Checking updates 1/50
- Downloading security updates 10%
- Downloading backport updates 10%
- Downloading updates 10%
- Etc.. and everything is up to you all... Thanks
Honestly, I'm using Windows beside my Ubuntu. When it is downloading updates, the update icon in notification area show such this message on mouse over (downloading updates 10%). I think, adding some informative message in update notifier will make it more informative. Exp:
- Checking updates 1/50
- Downloading security updates 10%
- Downloading backport updates 10%
- Downloading updates 10%
- Etc.. and everything is up to you all... Thanks
Solution #2:
Add Button to Interrupt Running Update in the Background
Written by
zalluth the 26 Oct 10 at 11:37.
When checking updates or downloading them is running in the background, I need sometimes to stop it for some reason, exp: installing some other program manually.... In that case, I cannot stop this, and Synaptic or Update Manager says something like "**** locked ***" without giving me a working solution... So it maybe very helpful to add a contextual menu on mouse over above update notifier to stop checking updates or downloading updates that run in the background.... Thanks..Sorry for my bad English...
When checking updates or downloading them is running in the background, I need sometimes to stop it for some reason, exp: installing some other program manually.... In that case, I cannot stop this, and Synaptic or Update Manager says something like "**** locked ***" without giving me a working solution... So it maybe very helpful to add a contextual menu on mouse over above update notifier to stop checking updates or downloading updates that run in the background.... Thanks..Sorry for my bad English...
Solution #3:
Allow user to throttle bandwidth
In addition to above solutions, allow the user to choose how much bandwidth update manager can use. This would allow those with a sufficiently fast connection to do things such as watch a video and get the updates at the same time, instead of having to pause the updates completely in order to watch the video.
This would, of course, be optional.
In addition to above solutions, allow the user to choose how much bandwidth update manager can use. This would allow those with a sufficiently fast connection to do things such as watch a video and get the updates at the same time, instead of having to pause the updates completely in order to watch the video.
This would, of course, be optional.