I was reading an article today in ComputerWorld about something called KSplice, which allows Linux users to install critical updates and patch in without rebooting the computer. I tried it and while it was a bit odd for installing (not auto-disabling the Ubuntu update system), it worked very well. I think something like this would be great for Fedora as well, possibly something for Fedora 12. Would it be possible to implement this or something similar for Fedora?
Note: Article: http://blogs.computerworld.com/never_reboot_again_with_linux_and_ksplice
I understand Microsoft has patented this technology so it is currently no-go for inclusion.
On 29/06/2009, King InuYasha ngompa13@gmail.com wrote:
I was reading an article today in ComputerWorld about something called KSplice, which allows Linux users to install critical updates and patch in without rebooting the computer. I tried it and while it was a bit odd for installing (not auto-disabling the Ubuntu update system), it worked very well. I think something like this would be great for Fedora as well, possibly something for Fedora 12. Would it be possible to implement this or something similar for Fedora?
Note: Article: http://blogs.computerworld.com/never_reboot_again_with_linux_and_ksplice
On Mon, Jun 29, 2009 at 11:19:53PM +0000, Christopher Brown wrote:
I understand Microsoft has patented this technology so it is currently no-go for inclusion.
[jwboyer@hansolo ~]$ koji latest-pkg dist-f11 ksplice Build Tag Built by ---------------------------------------- -------------------- ---------------- ksplice-0.9.7-3.fc11 dist-f11 s4504kr [jwboyer@hansolo ~]$ koji latest-pkg dist-f11 fedora-ksplice Build Tag Built by ---------------------------------------- -------------------- ---------------- fedora-ksplice-0.5-5.fc11 dist-f11 s4504kr [jwboyer@hansolo ~]$
josh
On Mon, Jun 29, 2009 at 7:12 PM, Josh Boyer jwboyer@gmail.com wrote:
On Mon, Jun 29, 2009 at 11:19:53PM +0000, Christopher Brown wrote:
I understand Microsoft has patented this technology so it is currently no-go for inclusion.
[jwboyer@hansolo ~]$ koji latest-pkg dist-f11 ksplice Build Tag Built by
ksplice-0.9.7-3.fc11 dist-f11 s4504kr [jwboyer@hansolo ~]$ koji latest-pkg dist-f11 fedora-ksplice Build Tag Built by
fedora-ksplice-0.5-5.fc11 dist-f11 s4504kr [jwboyer@hansolo ~]$
josh
Then Linux shouldn't be compiled using kmods and instead as a monolithic binary, since kernel modules fall under the patent. Besides, there are tons of prior art on it. KSplice is a good technology that could possibly be integrated in. fedora-ksplice is only build scripts for the kernel it looks like. ksplice is there as a package, but what about the GNOME frontend? The screenshot for ksplice in Ubuntu looks like PackageKit, so maybe it would be possible to integrate ksplice into PackageKit/yum so that rebooting for updates would be unnecessary.
On Mon, 2009-06-29 at 19:38 -0500, King InuYasha wrote:
Then Linux shouldn't be compiled using kmods and instead as a monolithic binary, since kernel modules fall under the patent. Besides, there are tons of prior art on it. KSplice is a good technology that could possibly be integrated in. fedora-ksplice is only build scripts for the kernel it looks like. ksplice is there as a package, but what about the GNOME frontend? The screenshot for
The frontend is Ksplice Inc's Uptrack service, not ksplice. The installable bits of Uptrack seem to be GPLv2 (only the artwork has an exception which is fair enough). I couldn't find any of the backend bits available for download though and as others have pointed out in this thread there's still the problem of making ksplice fit in with Fedora's approach to kernel updates (to be honest, I think it'd be a lot easier to run a service like this for RHEL or CentOS particularly if you're only interested in selected security errata).
Regards, Bryn.
On Mon, 29 Jun 2009 19:38:58 -0500, you wrote:
technology that could possibly be integrated in. fedora-ksplice is only build scripts for the kernel it looks like. ksplice
The fedora-ksplice script are doing the following:
1.) Getting the sources of the current running fedora kernel
2.) Prepare the kernel source tree for running ksplice.
3.) Create the kernel patch module on based of a patch and the prepared kernel sources.
The main aim is a more convinience way to use ksplice on fedora.
Best Regards:
Jochen Schmitt
On 06/29/2009 05:21 PM, King InuYasha wrote:
I was reading an article today in ComputerWorld about something called KSplice, which allows Linux users to install critical updates and patch in without rebooting the computer. I tried it and while it was a bit odd for installing (not auto-disabling the Ubuntu update system), it worked very well. I think something like this would be great for Fedora as well, possibly something for Fedora 12.
From looking at their website, it sounds like this software can take you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like black magic. I'm intrigued.
Michael Cronenworth wrote:
From looking at their website, it sounds like this software can take you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like black magic. I'm intrigued.
It actually can't and this is why it isn't very useful within Fedora, as we get big updates, not just minimal security patches. KSplice can't handle that kind of updates. It can only handle small patches which don't change any data structures. So the official Fedora kernel updates will never be suitable to be distributed through KSplice.
Kevin Kofler
On 06/29/2009 09:49 PM, Kevin Kofler wrote:
It actually can't and this is why it isn't very useful within Fedora, as we get big updates, not just minimal security patches. KSplice can't handle that kind of updates. It can only handle small patches which don't change any data structures. So the official Fedora kernel updates will never be suitable to be distributed through KSplice
... and that answered my question quite nicely. Next!
On 06/29/2009 10:49 PM, Kevin Kofler wrote:
It can only handle small patches which don't change any data structures. So the official Fedora kernel updates will never be suitable to be distributed through KSplice.
And to date there hasn't really been any compelling reason to issue tiny patch security-updated kernels, 'cause you have to reboot anyway, right? But as the technology improves, more opportunities arise.
I recall deploying some sort of hack workaround for the vmsplice exploit a while back on a whole bunch of machines (Fedora or downstreams) that were going to need a reboot scheduled up to a week in the future. This kind of technology would have been really swell to have then.
Lots of reasons to not want to reboot machines - most of the arguments for supporting laptop suspend would fit. Some of them may fall into the "protecting users from themselves" category, but that's not a bad thing either.
-Bill
On Mon, Jun 29, 2009 at 10:58 PM, Bill McGonigle bill@bfccomputing.comwrote:
On 06/29/2009 10:49 PM, Kevin Kofler wrote:
It can only handle small patches which don't change any data structures. So the official Fedora kernel updates will never be suitable to be distributed through KSplice.
And to date there hasn't really been any compelling reason to issue tiny patch security-updated kernels, 'cause you have to reboot anyway, right? But as the technology improves, more opportunities arise.
I recall deploying some sort of hack workaround for the vmsplice exploit a while back on a whole bunch of machines (Fedora or downstreams) that were going to need a reboot scheduled up to a week in the future. This kind of technology would have been really swell to have then.
Lots of reasons to not want to reboot machines - most of the arguments for supporting laptop suspend would fit. Some of them may fall into the "protecting users from themselves" category, but that's not a bad thing either.
-Bill
-- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 http://www.bfccomputing.com/ Cell: 603.252.2606 Twitter, etc.: bill_mcgonigle Page: 603.442.1833 Email, IM, VOIP: bill@bfccomputing.com Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf
Also, while KSplice is currently being used for kernel updates, it isn't limited to those. It could be adapted to work for other updates that normally force a reboot. Though, I can't think of any off the top of my head, it has been over a week since I ran the updater...
On Mon, 2009-06-29 at 23:22 -0500, King InuYasha wrote:
Also, while KSplice is currently being used for kernel updates, it isn't limited to those. It could be adapted to work for other updates that normally force a reboot. Though, I can't think of any off the top of my head, it has been over a week since I ran the updater... --
Please: no.
If parts of userspace cannot re-initialise themselves without a reboot then they should just be fixed. Even init has been able to do this for years now - resorting to exotic live-patching methods for updating userspace is just a workaround for badly written software.
Bryn.
Dnia 2009-06-30, o godz. 10:35:13 "Bryn M. Reeves" bmr@redhat.com napisał(a):
If parts of userspace cannot re-initialise themselves without a reboot then they should just be fixed. Even init has been able to do this for years now - resorting to exotic live-patching methods for updating userspace is just a workaround for badly written software.
Oh please... In your opinion, every program in existence should allow a user to hot-patch it? Like: dump the memory and open descriptors somewhere and execve() new version of itself?
Yeah, you go ahead - write patches, contribute.
Meanwhile, when a security bug strucks in the least obvious place, like wnck-applet or something, we will have means to fix it without logout for our users. That's a win. Really. Even if the method is exotic, which I can't deny.
Lam
Hi folks,
Ksplice is very interesting and I've spoken with a few people about it before. I met the (local to Cambridge, MA) ksplice guys several times and recently talked to them about the kinds of things they're doing right now. Uptrack is a nice showcase of the technology for sure.
More comments below...
On Tue, 2009-06-30 at 04:49 +0200, Kevin Kofler wrote:
Michael Cronenworth wrote:
From looking at their website, it sounds like this software can take you from say kernel 2.6.27 to 2.6.29 without rebooting? Sounds like black magic. I'm intrigued.
It relies upon using the existing module loading code to stop the kernel at a given moment in time (which might have to be attempted several times before succeeding in applying the ksplice patch, if the code paths being updated are currently being exercised) and inserts careful jumps to new code replacing existing functions wholesale with new ones.
It actually can't and this is why it isn't very useful within Fedora, as we get big updates, not just minimal security patches.
It would be useful for stable security updates in an enterprise distribution, and it is useful to some people in community distributions - but there's a lot of effort involved and this is where the ksplice guys have invested time in their infrastructure which we would have to entirely duplicate (and engineers too) to do this in Fedora.
KSplice can't handle that kind of updates.
Actually, it technically can.
It can only handle small patches which don't change any data structures.
That's a load of <removed>. I'm not sure where you get this idea from - perhaps because it's not obvious how they might achieve structural updates and so you assume it cannot be done - but actually, they can handle most kinds of update. They achieve this with shadow data structure tracking and manage the ABI differences - see the paper - and implement pre/post code hooks for things that cannot be done without a human kernel engineer. So you can also apply initcall-time fixes by implementing a custom pre-hook to perform what would happen at boot.
But anyway, yes, it gets complex. And I've no doubt that for the Ubuntu kernel they're doing this for at the moment they have some of the kernel engineers they have on staff actively writing pre/post hooks.
So the official Fedora kernel updates will never be suitable to be distributed through KSplice.
That's not technically true either. It's just not practical. We would need a much larger team of people and all of the infrastructure tools developed by the ksplice guys. And it's indeterminate what the end goal would be from that - most people are happy to reboot occasionally, and those who are not can already pay Ksplice, Inc. to make updates for them. I'm not sure this is something Fedora can practically offer.
Also - for those kernel folks reading. Don't discount ksplice because it sounds ugly. Tim and Waseem really do get it, and they know what they're doing - and they're actively engaging with upstream to get the bits that could be in the mainline kernel in there (ksplice doesn't require any existing kernel modifications because it also injects its own code during the ksplice patch application as part of the wrapper module).
I suggest if you're interested in "add this random code patch here" type of kernel development/testing that you add ksplice to the toolbox.
Jon.
Jon Masters wrote:
That's a load of <removed>. I'm not sure where you get this idea from - perhaps because it's not obvious how they might achieve structural updates and so you assume it cannot be done - but actually, they can handle most kinds of update. They achieve this with shadow data structure tracking and manage the ABI differences - see the paper - and implement pre/post code hooks for things that cannot be done without a human kernel engineer. So you can also apply initcall-time fixes by implementing a custom pre-hook to perform what would happen at boot.
The paper or web page (I don't remember exactly) I've read talked about this limitation. But maybe that information is outdated or this is just for automatically generating the fixes and you can do more complex stuff by manually writing fixup code.
Kevin Kofler
On Mon, 2009-06-29 at 17:21 -0500, King InuYasha wrote:
I was reading an article today in ComputerWorld about something called KSplice, which allows Linux users to install critical updates and patch in without rebooting the computer. I tried it and while it was a bit odd for installing (not auto-disabling the Ubuntu update system), it worked very well. I think something like this would be great for Fedora as well, possibly something for Fedora 12.
Would it be possible to implement this or something similar for Fedora?
The ksplice tools have been included in Fedora since around f8. This gives you the bits you need to create and apply ksplice updates to a running system.
The difference with what Ksplice inc. are now offering for Ubuntu is that they also provide a stream of pre-prepared updates for the released Ubuntu kernels (the "Uptrack" service).
Regards, Bryn.
Bryn M. Reeves wrote:
The difference with what Ksplice inc. are now offering for Ubuntu is that they also provide a stream of pre-prepared updates for the released Ubuntu kernels (the "Uptrack" service).
And as I explained, this can't be done for the released Fedora kernels (because they get big changes which ksplice cannot handle), unless you start from the GA kernel and only backport security fixes, which makes the kernel you provide become completely different from the current Fedora kernel over time.
Kevin Kofler
On Tue, 2009-06-30 at 17:34 +0200, Kevin Kofler wrote:
Bryn M. Reeves wrote:
The difference with what Ksplice inc. are now offering for Ubuntu is that they also provide a stream of pre-prepared updates for the released Ubuntu kernels (the "Uptrack" service).
And as I explained, this can't be done for the released Fedora kernels (because they get big changes which ksplice cannot handle), unless you
Which is more or less what I was getting at in the following message:
The frontend is Ksplice Inc's Uptrack service, not ksplice. The installable bits of Uptrack seem to be GPLv2 (only the artwork has an exception which is fair enough). I couldn't find any of the backend bits available for download though and as others have pointed out in this thread there's still the problem of making ksplice fit in with Fedora's approach to kernel updates (to be honest, I think it'd be a lot easier to run a service like this for RHEL or CentOS particularly if you're only interested in selected security errata).
On Tue, 2009-06-30 at 17:34 +0200, Kevin Kofler wrote:
start from the GA kernel and only backport security fixes, which makes the kernel you provide become completely different from the current Fedora kernel over time.
Not necessarily GA but yes, it's a lot of additional work and a struggle to fit this to the normal approach to kernel updates in Fedora.
To be honest, I'm glad to have the ksplice tools in the distribution as it makes it easy to play with them if you're interested in the technology but I do think that the applicability of this tool to a distribution like Fedora is probably a lot less than it would be for e.g. one of the "enterprise" distributions for the simple fact that end users who are particularly intolerant to reboots are likely already looking for a platform with a longer release and support cycle and stronger (i.e. commercial) support guarantees.
Fedora users who just want quicker reboots can always make use of kexec. Along with the boot time improvements in recent releases that should make installing and booting a new kernel pretty quick (apart from the inconvenience of shutting down applications).
Regards, Bryn.
On 06/30/2009 11:59 AM, Bryn M. Reeves wrote:
I do think that the applicability of this tool to a distribution like Fedora is probably a lot less than it would be for e.g. one of the "enterprise" distributions for the simple fact that end users who are particularly intolerant to reboots are likely already looking for a platform with a longer release and support cycle and stronger (i.e. commercial) support guarantees.
One could use the same premise to make the counter-argument. We already have a hard time getting Fedora used widely across enterprise environments - the easier we make it, the better our user base becomes. Critical security updates without reboots is a powerful enticement.
Fedora users who just want quicker reboots can always make use of kexec. Along with the boot time improvements in recent releases that should make installing and booting a new kernel pretty quick (apart from the inconvenience of shutting down applications).
The parenthetical is the actual reason people don't like to reboot and may ignore security updates. Boot times are trivial in comparison to restoring one's application state, for anything beyond the most trivial of use cases.
Kevin makes a really good point about the succession of kernels and security updates. With enough ksplice updates, you have to maintain something on the order of n! kernels. To actually implement this for Fedora, there would probably have to be practical cut-off requirements. For instance:
ksplice updates are only available for:
1. kernels that have been the lastest kernel in the past two weeks 2. kernel updates that are remotely exploitable 3. kernel updates that rate 'high' on CVSS
I'd have to do more research to be sure, but just guessing this feels like 0-4 candidates per Fedora release cycle.
-Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 30.06.2009 19:04, schrieb Bill McGonigle:
ksplice updates are only available for:
- kernels that have been the lastest kernel in the past two weeks
- kernel updates that are remotely exploitable
- kernel updates that rate 'high' on CVSS
I'd have to do more research to be sure, but just guessing this feels like 0-4 candidates per Fedora release cycle.
Please keep in mind, that you can't handle a kernel update, if globlal structure was changed. Because Fedora has several kernel update in the lifetime, you have to create a ksplice kernelpatch for each kernel release which is available on Fedora.
Best Regards:
Jochen Schmitt
On 06/30/2009 01:20 PM, Jochen Schmitt wrote:
Am 30.06.2009 19:04, schrieb Bill McGonigle:
ksplice updates are only available for:
- kernels that have been the lastest kernel in the past two weeks
- kernel updates that are remotely exploitable
- kernel updates that rate 'high' on CVSS
I'd have to do more research to be sure, but just guessing this feels like 0-4 candidates per Fedora release cycle.
Please keep in mind, that you can't handle a kernel update, if globlal structure was changed.
Jon says this isn't so (BTW, Jon, thanks for the very informative post if you're reading this). But most kernel security updates don't do this anyway, to the best of my knowledge. They're fixing a buffer check, adding an extra if to validate an assumption, etc.
Because Fedora has several kernel update in the lifetime, you have to create a ksplice kernelpatch for each kernel release which is available on Fedora.
Since you quoted my post with criteria to avoid this, I have to assume I'm missing your point here. Could you clarify?
-Bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 01.07.2009 18:44, schrieb Bill McGonigle:
Because Fedora has several kernel update in the
lifetime, you have to create a ksplice kernelpatch for each kernel release which is available on Fedora.
Since you quoted my post with criteria to avoid this, I have to assume I'm missing your point here. Could you clarify?
Ok, lets assume, that we have a security kernel patch for Fedora-10.
On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. This means, that you have to create seperates kernel patch modules for each kernel release which was submitted for Fedora-10.
The reseason to do it, is that ksplice is not able to handled patches, which may change global data structures.
Best Regards:
Jochen Schmitt
On 07/01/2009 01:48 PM, Jochen Schmitt wrote:
On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. This means, that you have to create seperates kernel patch modules for each kernel release which was submitted for Fedora-10.
This is why I suggested it would be practical to set a bar. The example I gave was a kernel which was the latest kernel in the past two weeks. This would usually be one, occasionally two. For a sysadmin, it's pretty easy to schedule a reboot within two weeks. '-r now' can be impossible.
The reseason to do it, is that ksplice is not able to handled patches, which may change global data structures.
Have there been remotely exploitable and/or CVSS 'high' kernel problems for which the patches need to change global data structures? Perhaps I'm just unaware of them. Besides this, Jon Masters' post says ksplice can handle this (unless I'm misunderstanding his post). Even though it can, if a bar as set above were set, Fedora wouldn't need to.
-Bill
On Wed, 2009-07-01 at 14:19 -0400, Bill McGonigle wrote:
On 07/01/2009 01:48 PM, Jochen Schmitt wrote:
On Fedora we have kernels from the 2.6.27 and from the 2.6.28 series. This means, that you have to create seperates kernel patch modules for each kernel release which was submitted for Fedora-10.
This is why I suggested it would be practical to set a bar.
I think it would be very useful to offer rebootless updates on a schedule - so for example, "one CVE fix" followed by "must reboot within a week or so", during which time it is unlikely there will be another CVE to stack upon the first. Truly never rebooting is something most users aren't worried too much about (even with shiny Apple crap) and those who are tend to be telco/embedded types who have had their own hacks for years and years - Montavista still have something in CGL.
The example I gave was a kernel which was the latest kernel in the past two weeks. This would usually be one, occasionally two. For a sysadmin, it's pretty easy to schedule a reboot within two weeks. '-r now' can be impossible.
Indeed. There's a lot of value in saying that you can delay the reboot but that you're protected now - akin to the syscall table hacks we used to shove onto some systems to fix the vmsplice of the moment issue.
The reseason to do it, is that ksplice is not able to handled patches, which may change global data structures.
Why not ask Tim to comment on the limitations directly? The ksplice guys are pretty amenable types and I'm sure they would happily chat with you.
Jon.
Bill McGonigle wrote:
The parenthetical is the actual reason people don't like to reboot and may ignore security updates. Boot times are trivial in comparison to restoring one's application state, for anything beyond the most trivial of use cases.
The average home user turns his/her computer off when going to sleep, so he/she reboots at least once per day. Heck, even I do that. Leaving my computer running when I sleep wastes power and makes me sleep badly (probably because of the noise from the fans, though I don't exclude electromagnetic waves possibly having to do with it as well (but no, I don't use tinfoil hats or similar nonsense ;-) )). Home users with record uptimes are a small minority, even if there are probably many of those on this list.
Kevin Kofler
Kevin Kofler kevin.kofler@chello.at writes:
Bill McGonigle wrote:
The parenthetical is the actual reason people don't like to reboot and may ignore security updates. Boot times are trivial in comparison to restoring one's application state, for anything beyond the most trivial of use cases.
The average home user turns his/her computer off when going to sleep, so he/she reboots at least once per day. Heck, even I do that. Leaving my computer running when I sleep wastes power and makes me sleep badly (probably because of the noise from the fans, though I don't exclude electromagnetic waves possibly having to do with it as well (but no, I don't use tinfoil hats or similar nonsense ;-) )). Home users with record uptimes are a small minority, even if there are probably many of those on this list.
I think most people hibernate or suspend when they go to sleep.
On Wed, Jul 1, 2009 at 1:44 AM, Frank Schmitt ich@frank-schmitt.net wrote:
Kevin Kofler kevin.kofler@chello.at writes:
Bill McGonigle wrote:
The parenthetical is the actual reason people don't like to reboot and may ignore security updates. Boot times are trivial in comparison to restoring one's application state, for anything beyond the most trivial of use cases.
The average home user turns his/her computer off when going to sleep, so he/she reboots at least once per day. Heck, even I do that. Leaving my computer running when I sleep wastes power and makes me sleep badly (probably because of the noise from the fans, though I don't exclude electromagnetic waves possibly having to do with it as well (but no, I don't use tinfoil hats or similar nonsense ;-) )). Home users with record uptimes are a small minority, even if there are probably many of those on this list.
I think most people hibernate or suspend when they go to sleep.
-- Have you ever considered how much text can fit in eighty columns? Given that a signature typically contains up to four lines of text, this space allows you to attach a tremendous amount of valuable information to your messages. Seize the opportunity and don't waste your signature on bullshit that nobody cares about.
Since hibernate has been broken for the last three releases of Fedora, I do suspend to RAM. I wish hibernate worked though. Either way, I don't like rebooting and I think something like this would be great. Most the people I do know, even non-techies, generally either suspend or hibernate the machine since they don't want to wait for the system to start up.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 01.07.2009 17:16, schrieb Kevin Kofler:
Those people must be trusting their hardware and software (drivers in particular) a lot more than I do. ;-)
This behaviour is not right in the time of climatic change.
Running a system 7x24 hours make only sense for a server and for this system you have the need to avoid reboots.
Avoiding reboots have the advantage of minimizing the time of outage during maintaining your system.
Best Regards:
Jochen Schmitt
Jochen Schmitt wrote:
Am 01.07.2009 17:16, schrieb Kevin Kofler:
Those people must be trusting their hardware and software (drivers in particular) a lot more than I do. ;-)
This behaviour is not right in the time of climatic change.
Whose behavior? Turning the computer off completely definitely saves more power than suspend to RAM and on some machines also suspend to disk (hibernate).
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 01.07.2009 17:48, schrieb Kevin Kofler:
Whose behavior? Turning the computer off completely definitely saves more power than suspend to RAM and on some machines also suspend to disk (hibernate).
Yes, and this is the reason why a desktop user should turns his coputer completely of to save the maximum of power.
Best Regards:
Jochen Schmitt
If your desktop doubles as a server, then no you don't turn off the computer...
On Wed, Jul 1, 2009 at 10:55 AM, Jochen Schmitt Jochen@herr-schmitt.dewrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 01.07.2009 17:48, schrieb Kevin Kofler:
Whose behavior? Turning the computer off completely definitely saves more power than suspend to RAM and on some machines also suspend to disk (hibernate).
Yes, and this is the reason why a desktop user should turns his coputer completely of to save the maximum of power.
Best Regards:
Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkpLhsMACgkQT2AHK6txfgzw0ACfSRYdJFzpAlVwM9lY9SURmx+F eeUAoMx9JmTHe4Vob2KvUDbiE885eJwP =aLyW -----END PGP SIGNATURE-----
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On 06/30/2009 06:23 PM, Kevin Kofler wrote:
The average home user turns his/her computer off when going to sleep, so he/she reboots at least once per day.
Can we measure this? My anecdotal evidence says most home users walk away from the computer and let the default power management settings do whatever they do, so they don't have to worry about rebuilding their workspace state every day. Even laziness is sufficient to explain that behavior - few GUI environments can shut down without getting the user involved in making decisions about unsaved changes, terminating stuck apps, etc. I realize the plural of 'anecdote' is not 'data', however, so it would be helpful to have some data. My netbook has low uptimes because it keeps getting hosed on resume from disk, not because I shut it down.
As far as the right thing to do to 'save the earth', there are a bunch of variables. 'How much power does it take to keep DRAM fresh?' vs. 'How much power does it take to book an OS from power-hungry hard drives'. Some new RAM types in the work don't need DRAM refreshes. Engineer down the power cost 'till it's negligible. Linux could come up with some sort of COW-like scheme to start running out of suspend-to-disk space instead of restoring to RAM first (then you can suspend to flash, e.g.), etc.
And none of that addresses the macroeconomic opportunity cost of final-solution energy research as a function of GDP as a function of productivity (but now I'm completely off-topic).
-Bill
On 01/07/09 17:38, Bill McGonigle wrote:
On 06/30/2009 06:23 PM, Kevin Kofler wrote:
The average home user turns his/her computer off when going to sleep, so he/she reboots at least once per day.
Unless they are into torrents\limewire, then it's 24/7. Their is quite a lot of normal users in that catagory.
Frank
-
Bill McGonigle -
Bryn M. Reeves -
Christopher Brown -
Frank Murphy -
Frank Schmitt -
Jochen Schmitt -
Jon Masters -
Josh Boyer -
Kevin Kofler -
Leszek Matok -
Michael Cronenworth -
Neal Gompa