Written by cyberix the 24 Aug 09 at 12:05.

Define speed targets for shutdown in future releases. Ubuntu already defines such speed targets for going up, in a blueprint called foundations-karmic-bootspeed-targets. The work should be extended to cover the whole on/off experience.

Define speed targets for shutdown in future releases. Ubuntu already defines such speed targets for going up, in a blueprint called foundations-karmic-bootspeed-targets. The work should be extended to cover the whole on/off experience.

Written by Otus the 24 Aug 09 at 15:56.

Possibly even more important for laptop use scenarios are speeds to and from sleep and hibernate states. Also define targets for these as appropriate.

Possibly even more important for laptop use scenarios are speeds to and from sleep and hibernate states. Also define targets for these as appropriate.

Written by Penguin Guy the 31 Aug 09 at 10:56.

99% of the time, startup speed matters more than shutdown speed. At the moment using a multi-threaded startup is dodgy because some programs need to be loaded before others - create a program to manage this.

This will mean that if you have a dual core you will be able to boot twice as fast, if you have a quad core you will be able to boot four times as fast, etc. I believe a program that does this is already in development, but couldn't find it's name. If so; continue work on that.

99% of the time, startup speed matters more than shutdown speed. At the moment using a multi-threaded startup is dodgy because some programs need to be loaded before others - create a program to manage this. This will mean that if you have a dual core you will be able to boot twice as fast, if you have a quad core you will be able to boot four times as fast, etc. I believe a program that does this is already in development, but couldn't find it's name. If so; continue work on that.

Written by Aielyn the 8 Sep 09 at 11:31.

NOTE: As I suspect that people are voting my solution down because they think I'm suggesting it as a replacement, rather than merely an option, I've removed the phrasing that implied it.
---

Have a special "optimised" shutdown option that does only what is absolutely necessary for the shutdown. This would include things like only checking to make sure that disc writing isn't happening while shutting down, rather than waiting for various processes to end.

Perhaps processes could also be tagged to indicate whether they must be ended properly or can be allowed to remain running until powerdown - that way, the system knows immediately if such processes need to be shut down properly.

And regarding Solution #2, the same logic could be applied, except that there would also be tags indicating which processes can be halted and then restarted at wake, and which need to be properly suspended/hibernated.

This should stop situations where the system is kept waiting while a particular process or application is trying unsuccessfully to end, without requiring user input for each instance of such a problem process.

NOTE: As I suspect that people are voting my solution down because they think I'm suggesting it as a replacement, rather than merely an option, I've removed the phrasing that implied it. --- Have a special "optimised" shutdown option that does only what is absolutely necessary for the shutdown. This would include things like only checking to make sure that disc writing isn't happening while shutting down, rather than waiting for various processes to end. Perhaps processes could also be tagged to indicate whether they must be ended properly or can be allowed to remain running until powerdown - that way, the system knows immediately if such processes need to be shut down properly. And regarding Solution #2, the same logic could be applied, except that there would also be tags indicating which processes can be halted and then restarted at wake, and which need to be properly suspended/hibernated. This should stop situations where the system is kept waiting while a particular process or application is trying unsuccessfully to end, without requiring user input for each instance of such a problem process.