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 -- 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@xxxxxxxxxxxxxxxx Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list