Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Le Mar 19 juin 2012 06:45, Adam Williamson a écrit : One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. And instead of making the system adapt to system problems (inhibit reboot during updates) we're making the user adapt to system problems (add forced reboots were they were none before??) Isn't the system supposed to help the user, not the other way around? -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Hi. On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote: And instead of making the system adapt to system problems (inhibit reboot during updates) we're making the user adapt to system problems (add forced reboots were they were none before??) Inhibiting reboots? I cannot wait to see how well that one will go down. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/22/2012 01:16 PM, Ralf Ertzinger wrote: Hi. On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote: And instead of making the system adapt to system problems (inhibit reboot during updates) we're making the user adapt to system problems (add forced reboots were they were none before??) Inhibiting reboots? I cannot wait to see how well that one will go down. Well, there is difference between inhibited reboot and are you really sure you want to reboot and break your system questions. Anyway, what would happen when user press power button or ctrl-alt-delete in yum-update-in-extra-target case? Would it shutdown/reboot (breaking the system) or would it ignore the request? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 22 June 2012 12:40, Michal Hlavinka mhlav...@redhat.com wrote: Well, there is difference between inhibited reboot and are you really sure you want to reboot and break your system questions. Is that a joke? [Click here to break your system] is never a good idea. Anyway, what would happen when user press power button or ctrl-alt-delete in yum-update-in-extra-target case? Would it shutdown/reboot (breaking the system) or would it ignore the request? If the required systemd features land in time, it would ignore the ctrl-alt-del when the package manager is locked. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote: On 22 June 2012 12:40, Michal Hlavinka mhlav...@redhat.com wrote: Well, there is difference between inhibited reboot and are you really sure you want to reboot and break your system questions. Is that a joke? [Click here to break your system] is never a good idea. Anyway, what would happen when user press power button or ctrl-alt-delete in yum-update-in-extra-target case? Would it shutdown/reboot (breaking the system) or would it ignore the request? If the required systemd features land in time, it would ignore the ctrl-alt-del when the package manager is locked. Oh well, in one of may VMs half of the time systemd ignores my requests for reboot anyway ... How do we make sure that if package manager goes crazy the user still have a way to reboot his system that is not 'press power button for 5 seconds' ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Le Ven 22 juin 2012 13:40, Michal Hlavinka a écrit : On 06/22/2012 01:16 PM, Ralf Ertzinger wrote: Hi. On Fri, 22 Jun 2012 10:28:14 +0200, Nicolas Mailhot wrote: And instead of making the system adapt to system problems (inhibit reboot during updates) we're making the user adapt to system problems (add forced reboots were they were none before??) Inhibiting reboots? I cannot wait to see how well that one will go down. Well, there is difference between inhibited reboot and are you really sure you want to reboot and break your system questions. Anyway, what would happen when user press power button or ctrl-alt-delete in yum-update-in-extra-target case? Would it shutdown/reboot (breaking the system) or would it ignore the request? It would display 'waiting for system update end to reboot...' and if you want to be fancy 'press y to force and break your system' (of course that only works for soft reboot/soft shutdown but there is no way to protect against the others no matter what you do) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 22 June 2012 13:56, Simo Sorce s...@redhat.com wrote: How do we make sure that if package manager goes crazy the user still have a way to reboot his system that is not 'press power button for 5 seconds' ? Just make sure the package manager doesn't go crazy. It's just doing a simple rpm transaction afterall. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, 22.06.12 08:56, Simo Sorce (s...@redhat.com) wrote: On Fri, 2012-06-22 at 13:38 +0100, Richard Hughes wrote: On 22 June 2012 12:40, Michal Hlavinka mhlav...@redhat.com wrote: Well, there is difference between inhibited reboot and are you really sure you want to reboot and break your system questions. Is that a joke? [Click here to break your system] is never a good idea. Anyway, what would happen when user press power button or ctrl-alt-delete in yum-update-in-extra-target case? Would it shutdown/reboot (breaking the system) or would it ignore the request? If the required systemd features land in time, it would ignore the ctrl-alt-del when the package manager is locked. Oh well, in one of may VMs half of the time systemd ignores my requests for reboot anyway ... Hmm, did you file a bug? How do we make sure that if package manager goes crazy the user still have a way to reboot his system that is not 'press power button for 5 seconds' ? If you have a shell then systemd actually offers you tree ways to reboot the system, depending on how tough you think you are: # systemctl reboot This does the normal clean reboot, stops all services cleanly, ... # systemctl reboot -f This does not stop all services cleanly, simply kills all processes with SIGTERM and after a short timeout with SIGKILL, but it does try to unmount/detach all file systems/storage devices/swaps/... and the reboots. This is something like a yes, i want it know, but i don't like fsck delaying my next boot. # systemctl reboot -ff This is the super hardcore reboot. It just invokes the reboot() system call immediately. Your file systems are likely to be dirty on the boot. During the update process you will find that the usualy gettys are available on tty[2-6]. Now, the way how the btrfs snapshotting should be implemented should probably be something like this: a) make a snapshot of the fs, and make it where all changes from now on are written to, but do not make it the default snapshot to be mounted for the next boot. b) make the updates c) if the update succeeded make the previously created snapshot the new default, otherwise just drop it. The result of this will be that the OS will either be in the old state, or in the new state, but not in half-way state. This should also allow the user to hard reboot any time without any ill-effect. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 22 June 2012 15:27, Lennart Poettering mzerq...@0pointer.de wrote: a) make a snapshot of the fs, and make it where all changes from now on are written to, but do not make it the default snapshot to be mounted for the next boot. b) make the updates c) if the update succeeded make the previously created snapshot the new default, otherwise just drop it. Yes, agreed. The result of this will be that the OS will either be in the old state, or in the new state, but not in half-way state. This should also allow the user to hard reboot any time without any ill-effect. Right. I was playing with this a bit last night, is there any kind of informal naming rules when generating the btrfs snapshot name? Should the date and time be encoded for instance? The process name? Ideas welcome. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, Jun 22, 2012 at 14:22:31 +0100, Richard Hughes hughsi...@gmail.com wrote: On 22 June 2012 13:56, Simo Sorce s...@redhat.com wrote: How do we make sure that if package manager goes crazy the user still have a way to reboot his system that is not 'press power button for 5 seconds' ? Just make sure the package manager doesn't go crazy. It's just doing a simple rpm transaction afterall. I have seen %post scripts hang a number of times. So things can and do go badly wrong with updates. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, 2012-06-22 at 14:22 +0100, Richard Hughes wrote: On 22 June 2012 13:56, Simo Sorce s...@redhat.com wrote: How do we make sure that if package manager goes crazy the user still have a way to reboot his system that is not 'press power button for 5 seconds' ? Just make sure the package manager doesn't go crazy. It's just doing a simple rpm transaction afterall. You mean, it's calling a bunch of scripts which run with root privileges, are written by a wide variety of people with little to no oversight, and could do absolutely anything? What could possibly go wrong...=) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, 2012-06-22 at 22:37 -0700, Adam Williamson wrote: On Fri, 2012-06-22 at 14:22 +0100, Richard Hughes wrote: On 22 June 2012 13:56, Simo Sorce s...@redhat.com wrote: How do we make sure that if package manager goes crazy the user still have a way to reboot his system that is not 'press power button for 5 seconds' ? Just make sure the package manager doesn't go crazy. It's just doing a simple rpm transaction afterall. You mean, it's calling a bunch of scripts which run with root privileges, are written by a wide variety of people with little to no oversight, and could do absolutely anything? What could possibly go wrong...=) Ooh! I forgot 'and which, by design, cannot possibly be run in parallel, and which must all at least return in order for the transaction to be considered complete'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
Hi,
On Wed, 20 Jun 2012 02:22:26 + (UTC)
Ben Boeckel maths...@gmail.com wrote:
On Mon, Jun 18, 2012 at 13:19:13 GMT, Michal Hlavinka wrote:
I wonder if it would be possible to do it on shutdown instead of
during start up? I usually do not care if shutdown takes ten
seconds or five minutes, but when I start my computer I do so
because I want to use it and not wait several minutes before its
ready.
Hmm. I usually have the other problem, especially with laptops.
Shutting down due to low battery only to have it wait to do updates
while there's a chance the updates won't matter because it's going to
crash soon is scarier than booting up and doing updates (presumably
you have juice available when booting). There's also the I need to
be somewhere case where shutting down fast is more important than
booting fast (airplane take off, losing track of time before class,
etc.).
Either way, it certainly isn't an obvious either-or issue. The obvious
solution, to me, is to have mind-reading computers, but I think that
may have one or two other consequences with it.
I agree that mind reading computers may not be the final answer, but I
do have a data point that might be helpful: we locally implemented
updates-at-reboot for a few years now. At first we had them on startup,
but now we do it at shutdown -- we made this change due to user
complaints as they did not mind the computer doing stuff when they went
away, but did mind longer wait times at the start of the {day,week,...}.
Note though that we only implemented this policy for desktop computers,
not for laptops. I agree that for a laptop, shutting down fast can be
necessary as well -- so maybe distinguishing on on AC power would be
a good substitute for mind reading as to when to run the actual updates?
--Stijn
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On 20 June 2012 08:08, Stijn Hoop st...@sandcat.nl wrote: I agree that mind reading computers may not be the final answer... Well, switching to system-update.service from a running desktop should probably kill off everything and start the offline update, so that would be possible with the new scheme too. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On Wed, 20 Jun 2012 10:22:22 +0100 Richard Hughes hughsi...@gmail.com wrote: On 20 June 2012 08:08, Stijn Hoop st...@sandcat.nl wrote: I agree that mind reading computers may not be the final answer... Well, switching to system-update.service from a running desktop should probably kill off everything and start the offline update, so that would be possible with the new scheme too. Good to know, thanks -- although I wonder, in what capacity is this supported then? Would you / others be willing to deal with both update timings in this Feature? --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: update installation timing (was Re: Schedule for Monday's FESCo Meeting (2012-06-18))
On 20 June 2012 12:51, Stijn Hoop st...@sandcat.nl wrote: Good to know, thanks -- although I wonder, in what capacity is this supported then? Well, I've got no idea if it works at all, let alone if it works well ;) Would you / others be willing to deal with both update timings in this Feature? It's not something I want to include in this feature, but I'd be happy to accept patches for PackageKit if required. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 10:53 PM, Lennart Poettering wrote: Well, even if Mozilla fixed that, such a solution wouldn't work for OS updates, already due to privilege reasons. i.e. pre-staging changes as root which are applied when a user does something simply cannot work if you care about security or supporting multi-user systems. It's not trivial, but in theory the updates could be made to work in an RCU-like fashion: Think of running Firefox processes as RCU read-side sections. The processes that are already running before the update keep seeing the old files. Newly started processes would see the new files. The RCU grace period elapses when all the previously running processes quit. At that point the old files can be deleted. As a bonus a notification would nag the users to restart their Firefox processes. After some timeout the processes would be killed by force. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 19.06.2012 06:45, schrieb Adam Williamson: On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote: if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. We shipped F16 with PackageKit set up, by default, to silently automatically install security updates Ah so you made a BIG MISTAKE as decision and now try to fix it in all sort of ways? who do developers think they are installing SILENT system-upgrades as default? you must not touch the setup of a enduser without a question before so do not fix the rsult, fix the problem and give users back the control of their system signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Tue, Jun 19, 2012 at 9:49 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 19.06.2012 06:45, schrieb Adam Williamson: On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote: if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. We shipped F16 with PackageKit set up, by default, to silently automatically install security updates Ah so you made a BIG MISTAKE as decision and now try to fix it in all sort of ways? who do developers think they are installing SILENT system-upgrades as default? you must not touch the setup of a enduser without a question before [citation needed] so do not fix the rsult, fix the problem and give users back the control of their system Here is a scientific study that refutes your claims: http://www.techzoom.net/publications/silent-updates/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Jun 18, 2012 at 13:19:13 GMT, Michal Hlavinka wrote: I wonder if it would be possible to do it on shutdown instead of during start up? I usually do not care if shutdown takes ten seconds or five minutes, but when I start my computer I do so because I want to use it and not wait several minutes before its ready. Hmm. I usually have the other problem, especially with laptops. Shutting down due to low battery only to have it wait to do updates while there's a chance the updates won't matter because it's going to crash soon is scarier than booting up and doing updates (presumably you have juice available when booting). There's also the I need to be somewhere case where shutting down fast is more important than booting fast (airplane take off, losing track of time before class, etc.). Either way, it certainly isn't an obvious either-or issue. The obvious solution, to me, is to have mind-reading computers, but I think that may have one or two other consequences with it. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJP4S0OAAoJEKaxavVX4C1XTEcQANdkuW1hJWdTfdEta+ZOuCYr VPzB/3lnBb1Pgedd/j6NprYRv0P7yte4fjiNR9PY8FtJ+j3DNZPvGRdztfnvtQuK Cs82FHmG+wrvlN9iCKsZmukM85OyI+kjB1HCCAJE2KTP3mFMj6M5SrGnUWlqqra9 R4O3QG9qq7to6PrpTX79QPR0z+o9GOuFfnxpSW8ETA8Qv3nUj6Vsew13l1DPhxPy UJUGknX54eYz2i2njm55hUxsRZW+rk/abZA7XQRX/g3CDGvib8j2FfUBj41A9M/4 zz/bIQmntCHuOk5+Ks7gIBK/YbkyU6n5NNVAjsaamLg3HcSVyEhWUw6bBaFQrSKV 6LC1IWwEDQFvMHjiM6WUn8uI5tFEgdzMtV1QfS/tCtp2+SqkwObedYDD7soMND3e R/h8DktMUTyzCIKa+ld1G2JoYXqbx/HrG4aVTsle4yAV7MEeO4rZIJz3Cr7Av29E jlJCjnXUN8ybWt/FpY4cVKug1Aou4XR4fI8fb5gUObDIe5qo4OBMoCp3egAD21eX cSvgvl+i4uUjXd0Y4QZvX8h3xt9kHRAKJm7ilvTYbLGWa9xKi/OfUR27x72/qfib s7SvRChtzQe4XmhGNDFdKlb73WpR6I8daDrlAgJN46c2Iq5xZQUJfm7l5OqTKRMO gn4DKLtMawZvzaCCQOr9 =Eh0L -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote: On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Because designing an asynchronous messaging bus that can be restarted without losing any messages is a difficult problem. If only Red Hat was involved in writing one ... Oh wait, what's this? https://qpid.apache.org/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:23 PM, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote: On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Because designing an asynchronous messaging bus that can be restarted without losing any messages is a difficult problem. If only Red Hat was involved in writing one ... Oh wait, what's this? https://qpid.apache.org/ Unless, you can change d-bus to do this while retaining the features, it isn't very relevant to the discussion. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 02:07:08PM +0530, Rahul Sundaram wrote: On 06/18/2012 01:23 PM, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote: On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Because designing an asynchronous messaging bus that can be restarted without losing any messages is a difficult problem. If only Red Hat was involved in writing one ... Oh wait, what's this? https://qpid.apache.org/ Unless, you can change d-bus to do this while retaining the features, it isn't very relevant to the discussion. What we shouldn't do is break things further by making almost all updates require a reboot. I believe there is or was an effort to replace dbus by something AMQP-based. However I can't find that right now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 02:40 PM, Richard W.M. Jones wrote: What we shouldn't do is break things further by making almost all updates require a reboot. What do you want to do? Either we should fix all the possible issues with restarting things on demand or we can accept this simpler solution but pretending that problems don't exist isn't the right way. Of course, you want to do that, you are free to continue using yum and ignore this solution. I believe there is or was an effort to replace dbus by something AMQP-based. However I can't find that right now. Good luck with that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18.06.2012 12:10, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 02:07:08PM +0530, Rahul Sundaram wrote: On 06/18/2012 01:23 PM, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 02:10:32AM +0100, Matthew Garrett wrote: On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Because designing an asynchronous messaging bus that can be restarted without losing any messages is a difficult problem. If only Red Hat was involved in writing one ... Oh wait, what's this? https://qpid.apache.org/ Unless, you can change d-bus to do this while retaining the features, it isn't very relevant to the discussion. What we shouldn't do is break things further by making almost all updates require a reboot. I believe there is or was an effort to replace dbus by something AMQP-based. However I can't find that right now. Probably it is doable on top of ZeroMQ too (+ few bits sqlite around the restarts) and IMO zmq is relatively closer to dbus compared to AMQP. But it is possible to rework dbus in any of these ways (inject persistence, adopting different messaging core) in the F18 timeframe? May be we should look at the proposed feature as unfortunate temporary workaround for the problem introduced by accident in the past, which should be properly addressed for F19. As I understand the proposal, the necessary workaround only affects the desktop instances and specifically Gnome ones - I am under the impression that my servers will continue to be updated by the normal way. Kind regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 10:50, Alek Paunov a...@declera.com wrote: As I understand the proposal, the necessary workaround only affects the desktop instances and specifically Gnome ones - I am under the impression that my servers will continue to be updated by the normal way. Exactly. This will not touch either RHN or yum console updating. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 10:10, Richard W.M. Jones rjo...@redhat.com wrote: I believe there is or was an effort to replace dbus by something AMQP-based. However I can't find that right now. The async-message bus isn't the only problem. You *have* to restart a process before it will be running a new library version. That mean testing (and probably patching) every single application and daemon in our stack and working around this for the proprietary stuff we can't even see the code for. That includes things like wine, mono, all the different interpretors, and all the runtimes that we include in Fedora. Sorry. Not going to happen. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Richard Hughes hughsi...@gmail.com writes: The async-message bus isn't the only problem. You *have* to restart a process before it will be running a new library version. That mean testing (and probably patching) every single application and daemon in our stack Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. and working around this for the proprietary stuff we can't even see the code for. That includes things like wine, mono, all the different interpretors, and all the runtimes that we include in Fedora. Requiring a log out is ok IMHO, if there are processes in the session still having the old library mapped after the upgrade. If there are processes which are neither daemons nor part of a session, we should probably have a good look at why. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 12:03, Benny Amorsen benny+use...@amorsen.dk wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing systemctl restart libvirtd.daemon -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. Restarting a daemon really means pause, dump all in-process-stuff-to-disk, exit-cleaning-up, load-and-detect-saved-state-and-convert-if-required, un-pause -- that's a different thing entirely to reload. Requiring a log out is ok IMHO, if there are processes in the session still having the old library mapped after the upgrade. If there are processes which are neither daemons nor part of a session, we should probably have a good look at why. Although I agree with your last statement, if you have more than one user logged in (or use fast-user-switching), the premise of a session re-login allowing all the open applications to relink against new library versions breaks down. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 12:22:16PM +0100, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsen benny+use...@amorsen.dk wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing systemctl restart libvirtd.daemon -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. This is not true for any libvirtd since ca. 2009. In fact it was fixed (with a lot of work) precisely because the old behaviour was broken. We didn't just throw our arms in the air and say this could never be fixed and people would have to reboot. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18.06.2012 14:22, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsen benny+use...@amorsen.dk wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing systemctl restart libvirtd.daemon -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. This is not entirely true for my current hypervisors (f16) - all VMs, spicec RDP connections stays live after: systemctl restart libvirtd.service However, I never tried to update qemu-system with live VMs. Kind regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 02:57:12PM +0300, Alek Paunov wrote: However, I never tried to update qemu-system with live VMs. The update will work, but the VMs will still be running the old code. You can actually solve that problem using VM migration: live migrate the VM from the old qemu to the new qemu. Downtime should be minimal (a fraction of a second). Like a good daemon, qemu is able to serialize its internal state and reproduce it in another instance. So there is definitely a path to make this work if, for example, qemu was found to have a serious security bug. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/17/2012 06:06 PM, Richard Hughes wrote: On 17 June 2012 10:53, Richard W.M. Jonesrjo...@redhat.com wrote: So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. It's a complete fallacy to believe you can update core libraries on a modern Linux system without rebooting. Add btrfs snapshotting to the mix (to be able to do updates safely) and doing updates in-situ becomes impossible. If Fedora wants to statically link everything, then it's certainly possible to workaround, but that's not acceptable to Fedora for perfectly understandable reasons. I wonder if it would be possible to do it on shutdown instead of during start up? I usually do not care if shutdown takes ten seconds or five minutes, but when I start my computer I do so because I want to use it and not wait several minutes before its ready. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:09 AM, drago01 wrote: On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsenbenny+use...@amorsen.dk wrote: Richard Hugheshughsi...@gmail.com writes: It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. If boot time is your concern we can make it (after BIOS) way faster by simply not enable lots of stuff that sits there unused after boot. Another concern is that this type of update is not always completely automatic - some users have different default options in grub like windows or different linux distro. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 01:22 PM, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsenbenny+use...@amorsen.dk wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing systemctl restart libvirtd.daemon -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. Restarting a daemon really means pause, dump all in-process-stuff-to-disk, exit-cleaning-up, load-and-detect-saved-state-and-convert-if-required, un-pause -- that's a different thing entirely to reload. Requiring a log out is ok IMHO, if there are processes in the session still having the old library mapped after the upgrade. If there are processes which are neither daemons nor part of a session, we should probably have a good look at why. Although I agree with your last statement, if you have more than one user logged in (or use fast-user-switching), the premise of a session re-login allowing all the open applications to relink against new library versions breaks down. How is the above different from restarting a computer? If you can aggressively reboot computer with daemons or (different user) sessions running, you can also restart (or even stop-update-start) them all with the same effect. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 01:09, schrieb drago01: On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Richard Hughes hughsi...@gmail.com writes: It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. If boot time is your concern we can make it (after BIOS) way faster by simply not enable lots of stuff that sits there unused after boot. that is not the point because every admin is dong this all the time the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? something must have gone terrible wrong in the meantime if this is what you call development then YES we should stop development now until we have ideas for real improvements instead wasting time by making steps backward signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 06/18/2012 05:08 AM, Reindl Harald wrote: that is not the point because every admin is dong this all the time the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? Since admins you are referring to are not managing desktop systems, how the updates are done in desktop systems is irrelevant to them. You are free to continue using yum on them as always. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 00:38, Reindl Harald h.rei...@thelounge.net wrote: the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? Well, if you're running a headless server with just http, netatalk and samba then you can of course update now live using yum, restarting services when convenient. I'm not going to change that. What I want to change is for the case of updating a fully functioning desktop with ~30 session processes per user talking to each other over session DBus, ~20 doing IPC with system DBus, and ~15 processes in the system context, ~3 of which do DBus IPC with each other. That's about as far removed from a simple server with three non-connected daemons that do one thing each as you can get. something must have gone terrible wrong in the meantime If your goal is to just run three simple daemons, I agree. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 7:38 PM, Reindl Harald h.rei...@thelounge.net wrote: if this is what you call development then YES we should stop development now until we have ideas for real improvements instead wasting time by making steps backward Language like this isn't helpful. Might I suggest that if you're going to make comments like this, you back them up with technical details on how to improve the situation? Early in my career (when I was still doing electrical engineering), the company I was working for was big on technical design reviews. Essentially, any time you designed something, you'd get your work reviewed by a room full of engineers. The rule was that you could criticize any part of someone else's review, but if you did, you had to offer a better *realistic* alternative, and be willing to take over the design of the alternative. While I'm not suggesting we get the formal in Fedora, I am growing increasingly tired of people saying You're doing it wrong without offering technical details on how to come up with realistic alternatives. Also please note that I'm not just picking on you here -- your comments just happened to trigger me into taking the time to write something I've been thinking about for a while. -- Jared Smith -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 18 Jun 2012, Richard Hughes wrote: On 18 June 2012 00:38, Reindl Harald h.rei...@thelounge.net wrote: the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? Well, if you're running a headless server with just http, netatalk and samba then you can of course update now live using yum, restarting services when convenient. I'm not going to change that. What I want to change is for the case of updating a fully functioning desktop with ~30 session processes per user talking to each other over session DBus, ~20 doing IPC with system DBus, and ~15 processes in the system context, ~3 of which do DBus IPC with each other. That's about as far removed from a simple server with three non-connected daemons that do one thing each as you can get. something must have gone terrible wrong in the meantime If your goal is to just run three simple daemons, I agree. As dbus is required for various things like networkmanager - does this mean that if a server happens to be using nm for network setup that in order to apply a security patch to dbus, for example, that the server will require a reboot? Since more and more we're relying on dbus for server-y processes it feels like we'll be adding one more component that requires a reboot for updates to take effect. That eats up real time and causes real pain later on for admins maintaining systems. Either we need to make dbus something we can sensibly restart or we need to rely on it less for server-y tasks (or both). I understand you're not working on PK for servers but the packaging expectations will trickle down to our slower-changing server installations and this will cause real pain and irritation. The implications for servers are fairly serious. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 15:32, Seth Vidal skvi...@fedoraproject.org wrote: As dbus is required for various things like networkmanager - does this mean that if a server happens to be using nm for network setup that in order to apply a security patch to dbus, for example, that the server will require a reboot? Well, if we take down NetworkManager, then it's going to disappear from the bus and come back (hopefully) a few seconds later. Apps / daemons can cope with this by watching the name-owner-changed signals, but a *lot* of apps and services don't bother and just go boom with critical warnings when the connection changes. Since more and more we're relying on dbus for server-y processes it feels like we'll be adding one more component that requires a reboot for updates to take effect. That eats up real time and causes real pain later on for admins maintaining systems. Any self-respecting admin isn't going to be clicking hundreds of little buttons in a shell GUI on the client machines, and is probably using RHN or yum and ssh. If they're installing updates on the server itself, they probably aren't using the auto-download and click-button-in-shell method either, but yum on the command line and restarting services at the weekend. Either we need to make dbus something we can sensibly restart or we need to rely on it less for server-y tasks (or both). Look at the process list of the daemons we boot by default on a Fedora 17 desktop install. On my system more than half are using DBus for IPC. Using DBus less just isn't going to happen. I understand you're not working on PK for servers but the packaging expectations I don't think any expectations are changing now. There are certainly no planned changes to the Fedora packaging guidelines at all. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 16:20, schrieb Richard Hughes: On 18 June 2012 00:38, Reindl Harald h.rei...@thelounge.net wrote: the point is that it was perfectly possible in 2005 to make a fedora dist-upgrade at friday night while http, netatalk or samba was fully up and running until saturday sometimes at evening where you rebootet the machine and now EIGHT years later we discuss about making updates at reboot/offline like windows? Well, if you're running a headless server with just http, netatalk and samba then you can of course update now live using yum, restarting services when convenient. I'm not going to change that. boah this was changed long ago with implement a braindead restart on update in each fedora server-package instead define a global config-setting to disable this crap signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 16:27, schrieb Jared K. Smith: On Sun, Jun 17, 2012 at 7:38 PM, Reindl Harald h.rei...@thelounge.net wrote: if this is what you call development then YES we should stop development now until we have ideas for real improvements instead wasting time by making steps backward Language like this isn't helpful. Might I suggest that if you're going to make comments like this, you back them up with technical details on how to improve the situation? you refused to understand waht i am saying if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, 17.06.12 10:53, Richard W.M. Jones (rjo...@redhat.com) wrote: On Sat, Jun 16, 2012 at 03:06:10PM +0200, Ralf Ertzinger wrote: Hi. On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. Linux has, in principle, the same problem as Windows, that while you can replace files that are in use running processes will (of course) not pick up the changes until restarted. Most daemons do so when updated themselves, but, for example, updating zlib because of an exploit will not restart all daemons using the exploitable library, so unless the admin restarts those manually or the system is rebooted you might still be vulnerable. So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. Well, if you are referring to doing lsof do figure out mapped libraries, than this is simply not sufficient, since there are many more ways how pieces of code we run interface than just shared library interfaces. Sure, with lsof you can find link time shared libs deps of running core. But there are so much other deps you'd need to follow to fully determine the set of things to restart: local socket protocols, bus interfaces or just data files (in /usr/share or so) that are used by code, that when upgraded also need its users restarted. And then there is the huge amount of code we cannot restart at all within a running system. Like the kernel, or dbus. But even more this is true for user applications: how would you go forward and ensure that firefox is restarted if the SSL libs have a vulnerability? And then, upgrades cannot be atomic, that means that there's a time where a process has not been restarted yet where it partially uses old deps/data files and where it partially uses new deps/data files, which is just doomed to go wrong. I mean, have you ever tried to upgrade firefox while running firefox? If you did, you know how awfully wrong that goes... [1] So, you have three problems: a) you cannot safely determine what to restart. b) you cannot restart many components of the OS at all c) upgrades cannot be atomic. Altogether this means, that in-system updates are something that is highly likely to break, and it does all the time. Sure, often enough you get away with doing in-system upgrades, but if we write our programs in a way that things work corretly only often enough, then we'd bad bad programmers. But anyway, nobody is taking yum upgrade away from you. It makes a ton of sense to use this, especially if you are a developer. I for one will always continue to use it, simply because I can deal with the fallout. But that doesn't mean we should implement the safe, technically correct way for the majority of users. Lennart Footnotes: [1] it's actually fun to try, in many cases firefox throws a tonload of JS errors, and even refuses to be shut down at all, unless SIGKILL is used... -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 12:09 PM, Lennart Poettering mzerq...@0pointer.de wrote: I mean, have you ever tried to upgrade firefox while running firefox? If you did, you know how awfully wrong that goes... [1] I run Mozilla's nightly builds and receive updates every day. They disrupt nothing because Mozilla has built infrastructure to make that possible. Firefox must be restarted for the updates to take effect, which is when it does the actual swapout of the staged files, but the restart is basically just a window flickering— tabs retain their state, including forms— in fact to prove the point I manually triggered it while writing this email. This is the direction Fedora should be heading in, if not quite as non-disruptive as what firefox does... and it's not that far off because with the exception of the recently written desktop infrastructure the system largely already support non-disruptive updates. By making updates regularly require reboots the incentive to bridge the gap is reduced and the expectations of a clean enviroment will increase until a rebootless update is as inconceivable in Fedora as it is in Windows. By making updates regularly require reboots you put users in an adversarial relationship with updates. Rather than being seen as something that helps them, updates will be seen as something that get in their way. Many will turn them off completely if you give them an option to do so. We don't have to speculate about the long term consequences of this path because we can already see it in the Windows world: e.g. On several occasions I have seen windows update disrupt presentations because the speaker was talking to the audience and didn't react fast enough to the snooze button on the mandatory updates they've been deferring. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 18:09, schrieb Lennart Poettering: I mean, have you ever tried to upgrade firefox while running firefox? If you did, you know how awfully wrong that goes... [1] So, you have three problems: a) you cannot safely determine what to restart. b) you cannot restart many components of the OS at all c) upgrades cannot be atomic. i even did DIST-UPGRADES while Firefox, Thunderbird, the whole KDE and Eclipse where up and running without issues only while KDE parts get updated the start of a NEW instamce of a kde-app (as example kate) fails but there was never a problem with running applications and now you come the road and thell us firefox can not be updated while it is running? strange that i apply FF updates since years in my daily workload and after all are finished the browser get's restarted or even at the next day if the update happens 1 or 2 hours before i go home signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 18 June 2012 17:36, Reindl Harald h.rei...@thelounge.net wrote: and now you come the road and thell us firefox can not be updated while it is running? strange that i apply FF updates since years in my daily workload and after all are finished the browser get's restarted or even at the next day if the update happens 1 or 2 hours before i go home No, I'm telling you that it works 99.99%[1] of the time quite well. When it fails, it fails hard, and the user creates an angry bugzilla pointing at me that i have to read and try to explain to the user why their bookmarks are lost or why firefox needs to be kill-9'd before it can be launched again from a launcher. Richard. [1] 0.01% x installed userbase = lots of bugzilla spam in my inbox. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating jkeat...@j2solutions.net wrote: On 06/18/2012 09:24 AM, Gregory Maxwell wrote: I run Mozilla's nightly builds and receive updates every day. They disrupt nothing because Mozilla has built infrastructure to make that possible. Firefox must be restarted for the updates to take effect, which is when it does the actual swapout of the staged files, but the restart is basically just a window flickering— tabs retain their state, including forms— in fact to prove the point I manually triggered it while writing this email. Your anecdata does not match my anecdata. Both Firefox and Thunderbird will malfunction in strange and subtle ways if the package is while the application is running. A restart of the application is required before things start behaving as expected. There are enough people out there experiencing this that one cannot wave it off as hallucinations. It is a real problem that exists despite your experience to the opposite. I'm not waving it off. It's something which Mozilla has fixed in their nightly update process which is not addressed in Fedora updates for Firefox. Mozilla nightly pre-stages the update and then does the update on startup. When combined with persisting the application state across restarts it makes the whole thing painless. Otherwise, yes, it can be problematic, as firefox does runtime dlopening and such and can end up inconsistent if you swap out files out from under it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 18.06.2012 18:58, schrieb Richard Hughes: On 18 June 2012 17:36, Reindl Harald h.rei...@thelounge.net wrote: and now you come the road and thell us firefox can not be updated while it is running? strange that i apply FF updates since years in my daily workload and after all are finished the browser get's restarted or even at the next day if the update happens 1 or 2 hours before i go home No, I'm telling you that it works 99.99%[1] of the time quite well. When it fails, it fails hard, and the user creates an angry bugzilla pointing at me that i have to read and try to explain to the user why their bookmarks are lost or why firefox needs to be kill-9'd before it can be launched again from a launcher. Richard. [1] 0.01% x installed userbase = lots of bugzilla spam in my inbox. currently here are much more problems that firefox needs SIGKILL without any firefox update - so many of this 0.01% coming from users only updated extensions, confirmed restart and nothing happend i still can't count how often this happened in the last few months interesting that after rpm-updates there is mostly no single problem signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 2012-06-18 at 19:03 +0200, Reindl Harald wrote: currently here are much more problems that firefox needs SIGKILL without any firefox update - so many of this 0.01% coming from users only updated extensions, confirmed restart and nothing happend i still can't count how often this happened in the last few months interesting that after rpm-updates there is mostly no single problem You misspelled irrelevant. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 18.06.12 15:25, Gregory Maxwell (gmaxw...@gmail.com) wrote: On Mon, Jun 18, 2012 at 3:00 PM, Jesse Keating jkeat...@j2solutions.net wrote: On 06/18/2012 09:24 AM, Gregory Maxwell wrote: I run Mozilla's nightly builds and receive updates every day. They disrupt nothing because Mozilla has built infrastructure to make that possible. Firefox must be restarted for the updates to take effect, which is when it does the actual swapout of the staged files, but the restart is basically just a window flickering— tabs retain their state, including forms— in fact to prove the point I manually triggered it while writing this email. Your anecdata does not match my anecdata. Both Firefox and Thunderbird will malfunction in strange and subtle ways if the package is while the application is running. A restart of the application is required before things start behaving as expected. There are enough people out there experiencing this that one cannot wave it off as hallucinations. It is a real problem that exists despite your experience to the opposite. I'm not waving it off. It's something which Mozilla has fixed in their nightly update process which is not addressed in Fedora updates for Firefox. Mozilla nightly pre-stages the update and then does the update on startup. When combined with persisting the application state across restarts it makes the whole thing painless. Otherwise, yes, it can be problematic, as firefox does runtime dlopening and such and can end up inconsistent if you swap out files out from under it. Well, even if Mozilla fixed that, such a solution wouldn't work for OS updates, already due to privilege reasons. i.e. pre-staging changes as root which are applied when a user does something simply cannot work if you care about security or supporting multi-user systems. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 4:53 PM, Lennart Poettering mzerq...@0pointer.de wrote: Well, even if Mozilla fixed that, such a solution wouldn't work for OS updates, already due to privilege reasons. i.e. pre-staging changes as root which are applied when a user does something simply cannot work if you care about security or supporting multi-user systems. Cannot is a strong word. For example, an update process can hang around and watch for all instances process to go away while some notification facility nags users to restarted. Or on close the DE can signal the staged upgrade to go through, or just automatic on reboot. Reboots on triggered from the desktop environment certainly no more multi-user hostile than that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
I wonder if it would be possible to do it on shutdown instead of during start up? Perhaps on shutdown, the default shutdown target gets replaced with the system update target, so that this doesn't affect start up speed. My issue with this is not the concept or the technical merits, but the user experience. I have spent many hours twiddling my thumbs at windows and OSX updates for desktop systems that I need to support. I think there are ways that the updates could be prepared ondisk to make this process as fast as possible. I think another idea, is that if the system has btrfs (which will be default in fedora soon), make /usr and /var subvolumes. Then, when updates come along, snapshot /usr and /var (maybe even /etc) and do the updates into the new snapshots since btrfs snapshots are writable. Once the update is complete, just make the new default subvol for /usr and /var the newly updated volumes. If people want to roll back, each update we add a new kernel menu entry that points at different subvolumes (Similar to a solaris boot environment) This way, Your reboot is extremely fast and you gain all the benefits of the offline updates. This is similar to yum-fs-snapshot. -- Sincerely, William Brown pgp.mit.edu http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x3C0AC6DAB2F928A2 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 2012-06-18 at 12:47 +0100, Richard W.M. Jones wrote: On Mon, Jun 18, 2012 at 12:22:16PM +0100, Richard Hughes wrote: On 18 June 2012 12:03, Benny Amorsen benny+use...@amorsen.dk wrote: Why testing the daemons? Any daemon which cannot be restarted by systemctl restart foo.daemon is broken already. Try booting a few VMs and then doing systemctl restart libvirtd.daemon -- libvirtd restarts okay (hopefully) but all the clients are disconnected and all the VMs are no longer running. This is not true for any libvirtd since ca. 2009. In fact it was Well, it was broken for a time during the F17 cycle, which may be where the other Richard got his mistaken impression. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, 2012-06-18 at 16:32 +0200, Reindl Harald wrote: if things are working fine they do not need to be reinvented and developed forever - the problem i see the last years is that way to often are wroking things replaced because people can not life with the fact that things sometimes are finished and good as they are One trigger for the current proposal was the discovery, quite late in F17 cycle, that if you reboot while PK is automatically installing security updates, you can entirely screw your system. We shipped F16 with PackageKit set up, by default, to silently automatically install security updates. If you leave this as it is, and just use and reboot the system as normal, there is a small but not insignificant chance that you will eventually wind up with a completely broken system, when you happen to reboot just as PK is halfway through updating glibc or something. So no, things are clearly not good 'as they are'. One obvious 'fix' for the above bug was not to automatically install security updates any more, and that's the band-aid we used for F17, but obviously once you come across that issue and start thinking in broader terms about how we _ought_ to handle updates on the desktop, it's reasonable to wind up thinking up the plan encapsulated by this feature. I can't find the bug # for the above bug, unfortunately, but hughsie probably has it handy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sat, Jun 16, 2012 at 02:57:30PM +0200, Jochen Schmitt wrote: On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote: #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates .fesco 869 The titel of this feature is a lttle misleading for me and the description of the feature sounds linke Windows where you get the message: Pleaae reboot your system to activate the installed updates. One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. This features is inpractical of server systems where you want to avoid reboots to minimizize downtimes. +1. This is another case where we ape the misfeatures of Mac OS X and Windows, instead of doing it better (cf. Wayland, GNOME 3, etc) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sat, Jun 16, 2012 at 03:06:10PM +0200, Ralf Ertzinger wrote: Hi. On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. Linux has, in principle, the same problem as Windows, that while you can replace files that are in use running processes will (of course) not pick up the changes until restarted. Most daemons do so when updated themselves, but, for example, updating zlib because of an exploit will not restart all daemons using the exploitable library, so unless the admin restarts those manually or the system is rebooted you might still be vulnerable. So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 16/06/12 00:15, Kevin Fenzi wrote: .fesco 868 #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates .fesco 869 Not much use to Xfce users. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 17 June 2012 10:53, Richard W.M. Jones rjo...@redhat.com wrote: So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. It's a complete fallacy to believe you can update core libraries on a modern Linux system without rebooting. Add btrfs snapshotting to the mix (to be able to do updates safely) and doing updates in-situ becomes impossible. If Fedora wants to statically link everything, then it's certainly possible to workaround, but that's not acceptable to Fedora for perfectly understandable reasons. This is another case where we ape the misfeatures of Mac OS X and Windows, instead of doing it better (cf. Wayland, GNOME 3, etc) I'm not sure how non-technical and misleading comments like this help people in coming to a decision. Can you refrain from posting things like this to a development mailing list please. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 16 June 2012 14:04, Reindl Harald h.rei...@thelounge.net wrote: the next have solution, searching problem of Lennart? hopefully this leads not sooner or later in uncareful designs where it get more and more a must No, if you mist blame somebody please send insults to me instead. I asked Lennarts advice on how to patch systemd to do this correctly, which was discussed in http://lists.freedesktop.org/archives/systemd-devel/2011-August/003190.html and Lennart added the tiny amount of code to systemd, and added the specification page so that any project could implement the specification. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 17 June 2012 11:00, Frank Murphy frankl...@gmail.com wrote: Not much use to Xfce users. Xfce doesn't have a native PackageKit client. If you run the gnome-settings-daemon updates plugin then it just works. I don't think XFCE has the manpower to re-implement all the stuff needed for the existing QA release time package management tests, so I don't think that should block this F18 feature. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 17/06/12 17:17, Richard Hughes wrote: On 17 June 2012 11:00, Frank Murphyfrankl...@gmail.com wrote: Not much use to Xfce users. Xfce doesn't have a native PackageKit client. If you run the gnome-settings-daemon updates plugin then it just works. Not since F16. iirc I don't think XFCE has the manpower to re-implement all the stuff needed for the existing QA release time package management tests, Agreed. so I don't think that should block this F18 feature. Didn't say it should. Richard. -- Regards, Frank Jack of all, fubars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 05:06:51PM +0100, Richard Hughes wrote: On 17 June 2012 10:53, Richard W.M. Jones rjo...@redhat.com wrote: So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. You're asserting that dbus-daemon etc cannot be restarted, but without saying why. The current design may make restarting some daemons difficult but we should fix those problems. If you want to look around for ideas to lift from other OSes, take a look at: - QNX - z/VM - EROS Some of these OSes can run virtually indefinitely, being upgraded all the time as they go along. So please don't tell me that it's simply not possible. It might not be possible *with poorly designed Linux daemons* but that's quite a different thing. [More assertions without explanations snipped] [Irrelevant comment about static linking snipped] This is another case where we ape the misfeatures of Mac OS X and Windows, instead of doing it better (cf. Wayland, GNOME 3, etc) I'm not sure how non-technical and misleading comments like this help people in coming to a decision. Can you refrain from posting things like this to a development mailing list please. That was a very relevant comment. The Wayland stack reinvents X, with fewer features, including omitting very important features. GNOME 3 tries to impose a tablet interface even though people are still using keyboards and mice (I'm sure GNOME 3 works well on tablets, although all tablets out there run iOS or Android so that's a bit irrelevant). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 12:06 PM, Richard Hughes hughsi...@gmail.com wrote: That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. It's a complete fallacy to believe you can update core libraries on a modern Linux system without rebooting. I upgraded running systems from a.out to elf and from libc to glibc without shutting down. Okay, init itself is a bit tricky, but it also basically does nothing on a running system so the problems in upgrading it are not especially relevant. And now some mere userspace daemons mean users will constantly need to reboot for upgrades? Regressions against featuresets from the '70s and '80s are pretty unfortunate. This is starting to sound like evidence of a serious design flaw in some of these daemons. I find that unfortunate because I really like systemd. (And the you can manually force it, seems not much of a consolation to me— since that will be untested, unsupported, and very likely non-functional.) If we ask the question— retrospectively, if we knew that eventually the acceptance of systemd (or newer dbus-daemon) would have ultimately resulted in needing to reboot for updates would we have accepted it? I think the answer is pretty clearly No. If slippery slope arguments are to be dismissed when they're used against new features like systemd (or Wayland or whatever), then Fedora really does need to draw a line in the sand and say no to bad effects when they crop up. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 7:59 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Jun 17, 2012 at 12:06 PM, Richard Hughes hughsi...@gmail.com wrote: And now some mere userspace daemons mean users will constantly need to reboot for upgrades? No. Regressions against featuresets from the '70s and '80s are pretty unfortunate. A new feature is being added nothing is getting removed so no there is no regression. This is starting to sound like evidence of a serious design flaw in some of these daemons. I find that unfortunate because I really like systemd. (And the you can manually force it, seems not much of a consolation to me— since that will be untested, unsupported, and very likely non-functional.) Why do you think so? I am pretty sure that it will get a lot of testing by server users and users of otther / niche desktop environments. If we ask the question— retrospectively, if we knew that eventually the acceptance of systemd (or newer dbus-daemon) would have ultimately resulted in needing to reboot for updates would we have accepted it? I think the answer is pretty clearly No. dbus is not optional. Not including it would mean throw out half of the distro. And no idea what that has to do with systemd either. Randomly blame stuff does not help your point. If slippery slope arguments are to be dismissed when they're used against new features like systemd (or Wayland or whatever), then Fedora really does need to draw a line in the sand and say no to bad effects when they crop up. I am not seeing any bad effects here ... I am seeing a feature proposal that tries to solve a problem that you dismiss as non existent while it is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 8:08 PM, drago01 drag...@gmail.com wrote: [...] If slippery slope arguments are to be dismissed when they're used against new features like systemd (or Wayland or whatever), then Fedora really does need to draw a line in the sand and say no to bad effects when they crop up. I am not seeing any bad effects here ... I am seeing a feature proposal that tries to solve a problem that you dismiss as non existent while it is. err should read while it does exist. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 2:08 PM, drago01 drag...@gmail.com wrote: A new feature is being added nothing is getting removed so no there is no regression. Thats newspeak if I ever saw any. Going from a system which generally doesn't prompt users to reboot to one that does is a regression. dbus is not optional. Not including it would mean throw out half of the distro. And no idea what that has to do with systemd either. Randomly blame stuff does not help your point. I was not randomly blaming I was copying from Richard Hughes message. He said these services need system reboots for upgrades. That isn't what we signed up for I am not seeing any bad effects here ... I am seeing a feature proposal that tries to solve a problem that you dismiss as non existent while it is. I haven't personally experienced problems with this but I trust that there are problems. Causing users to need to reboot for updates does not solve the problem— it masks it. And masking can be a fine solution where its harmless, but it certainly isn't here. The reboot for upgrades stuff in windows is one of the most often cited annoying anti-features, so it's understandable why people would throw stones at something that looked like it was emulating it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 8:19 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Jun 17, 2012 at 2:08 PM, drago01 drag...@gmail.com wrote: A new feature is being added nothing is getting removed so no there is no regression. Thats newspeak if I ever saw any. Going from a system which generally doesn't prompt users to reboot to one that does is a regression. dbus is not optional. Not including it would mean throw out half of the distro. And no idea what that has to do with systemd either. Randomly blame stuff does not help your point. I was not randomly blaming I was copying from Richard Hughes message. He said these services need system reboots for upgrades. That isn't what we signed up for Yeah but those where examples not the sole reason why reboots are required. It is not like if we didn't switch to systemd this problem wouldn't exist. (which was my point re blaming). I am not seeing any bad effects here ... I am seeing a feature proposal that tries to solve a problem that you dismiss as non existent while it is. I haven't personally experienced problems with this but I trust that there are problems. Causing users to need to reboot for updates does not solve the problem— it masks it. And masking can be a fine solution where its harmless, but it certainly isn't here. The reboot for upgrades stuff in windows is one of the most often cited annoying anti-features, so it's understandable why people would throw stones at something that looked like it was emulating it. Sure but then suggest alternatives just doing nothing is not a solution either. This feature also allows updates to be applied in a well defined state and use btrfs snapshots to make sure that everything works even if the upgrade got aborted by a crash, power failure etc. (rpm transactions are not ACID so you end up in an undefined state in that case). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 08:40:31PM +0200, drago01 wrote: Yeah but those where examples not the sole reason why reboots are required. It is not like if we didn't switch to systemd this problem wouldn't exist. (which was my point re blaming). Do we realy need a complete reboot of the system? I think stopping and starting of all daemons are enough to solve the issues discussed in this thread. In this case we may save outage time, because we don't have waste time for the BIOS POST, loading the bootloader and the kernel. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 09:01:11PM +0200, Jochen Schmitt wrote: On Sun, Jun 17, 2012 at 08:40:31PM +0200, drago01 wrote: Yeah but those where examples not the sole reason why reboots are required. It is not like if we didn't switch to systemd this problem wouldn't exist. (which was my point re blaming). Do we realy need a complete reboot of the system? I think stopping and starting of all daemons are enough to solve the issues discussed in this thread. You are free to propose reliable way of determining which application to restart. Including those affected by dbus interface changes, application data changes (like Firefox' javascripts) etc. etc. In this case we may save outage time, because we don't have waste time for the BIOS POST, loading the bootloader and the kernel. If you want to skip BIOS POST, use kexec. -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 17 June 2012 20:01, Jochen Schmitt joc...@herr-schmitt.de wrote: In this case we may save outage time, because we don't have waste time for the BIOS POST, loading the bootloader and the kernel. It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 17 June 2012 18:49, Richard W.M. Jones rjo...@redhat.com wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Okay, I'll say why. The core protocol was never designed to support the dbus-daemon being restarted. The current design may make restarting some daemons difficult but we should fix those problems. So, to install a zlib update, according to your proposal we now have to QA the effects of restarting several per-system userspace daemons at runtime (which may be disabled or enabled depending on the specific user config) and also have to test the session clients (of all three desktops) code support when core system services disappear and then (hopefully) reappear a few seconds later. And make sure that this works for multi-user logins and fast-user switching. And we hope that the updates have not failed to be installed leaving the session without core stuff like gnome-session and dbus. So then we try to roll back to the previous system state using snapshotting, even though the non-idle system has already written other normal stuff to /usr and /etc which we mistakenly revert... See how crazy this sounds? Please trust me when I say we've thought about this stuff quite a lot, and the only sane way to do this was wither with a recovery partition or a minimal boot environment like I've suggested. It's a miracle the stuff we try to QA now works at all. - QNX - z/VM - EROS Have you got an example of any popular desktop OS? It might not be possible *with poorly designed Linux daemons* but that's quite a different thing. As the maintainer of a few of the aforementioned poorly designed Linux daemons I can tell you that's simply not possible. I'm sure you appreciate how complicated restarting a service without dropping state would be with your work with libvirtd. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Richard Hughes hughsi...@gmail.com writes: It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Mon, Jun 18, 2012 at 12:24 AM, Benny Amorsen benny+use...@amorsen.dk wrote: Richard Hughes hughsi...@gmail.com writes: It takes me 4 seconds to POST, boot the kernel, get into system-update.service, and then reboot. Using a new rpm version, applying several dozen test updates takes another 20 seconds. Your hardware is too cheap. BIOS boot time is proportional to price when the hardware was introduced. More generally, the fact that your hardware happens to boot fast does not mean that extra reboots are not a problem. If boot time is your concern we can make it (after BIOS) way faster by simply not enable lots of stuff that sits there unused after boot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On 17 June 2012 11:49, Richard W.M. Jones rjo...@redhat.com wrote: On Sun, Jun 17, 2012 at 05:06:51PM +0100, Richard Hughes wrote: On 17 June 2012 10:53, Richard W.M. Jones rjo...@redhat.com wrote: So this is a problem that needs to be solved, but does it require a reboot? Not really ... it's possible to list all processes using zlib, convert that back into a list of packages, then instruct those packages to restart themselves. Job done, BETTER than Windows / OS X. That's simply not possible. Some processes like dbus-daemon and gnome-session just cannot be restarted in this way. You're asserting that dbus-daemon etc cannot be restarted, but without saying why. The current design may make restarting some daemons difficult but we should fix those problems. My understanding is that many of the plumbing layer items are basically kernel level issues even if they aren't a kernel. To get them to be a QNX level issue one would need to design the kernel to be QNX (micro kernel like where parts of the kernel can reboot without worrying about other parts.) However that is something that is designed day 1 for QNX and you would need similar attendance. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sun, Jun 17, 2012 at 06:49:43PM +0100, Richard W.M. Jones wrote: You're asserting that dbus-daemon etc cannot be restarted, but without saying why. Because designing an asynchronous messaging bus that can be restarted without losing any messages is a difficult problem. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote: #topic ticket 863 F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure .fesco 863 I think Leiminger may be a better name for this feature. the aim of this feature is the introduction of Lieminger as an IDE for clojure. Clojure itselft is part of the current Fedora releases. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote: #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates .fesco 869 The titel of this feature is a lttle misleading for me and the description of the feature sounds linke Windows where you get the message: Pleaae reboot your system to activate the installed updates. One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. This features is inpractical of server systems where you want to avoid reboots to minimizize downtimes. I oppsoite it may be beeter to tag the packages where a reboot may be requrire to activate the installed update with a virtual provides. Yum may detect this virtaul provide during the update and can take accorate action in this case. Best Regards: Jochen Schmitt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Hi. On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. Linux has, in principle, the same problem as Windows, that while you can replace files that are in use running processes will (of course) not pick up the changes until restarted. Most daemons do so when updated themselves, but, for example, updating zlib because of an exploit will not restart all daemons using the exploitable library, so unless the admin restarts those manually or the system is rebooted you might still be vulnerable. MS has choosen the reboot route to deal with this, and current versions leave it up to the user to initiate the reboot while nagging about it in regular intervals (which Fedora does not do, and I'm not sure this is a good thing tbh). -- Democracy is 3 wolves a sheep voting on what to have for dinner. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Le samedi 16 juin 2012 à 14:57 +0200, Jochen Schmitt a écrit : On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote: #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates .fesco 869 The title of this feature is a little misleading for me and the description of the feature sounds linke Windows where you get the message: Pleaae reboot your system to activate the installed updates. One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. In fact, this cause various subtles issues : http://neugierig.org/software/chromium/notes/2011/08/zygote.html I do see mysterious crash from time to time due to upgrade. This feature is inpractical of server systems where you want to avoid reboots to minimizize downtimes. Then you can still use yum update to do it instead of doing it with packagekit and systemd. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 16.06.2012 14:57, schrieb Jochen Schmitt: On Fri, Jun 15, 2012 at 05:15:53PM -0600, Kevin Fenzi wrote: #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates Owner Name: Richard Hughes Lennart Poettering Make updating of system components more reliable by doing it in an minimal, controlled environment. the next have solution, searching problem of Lennart? hopefully this leads not sooner or later in uncareful designs where it get more and more a must after around 400 fedora DIST-Upgrades - who needs this? better fixing systemd taht VMwareWorkstation suspends running VM's as reliable as before Fedora 15 The system update mode is implemented by booting into a special target. The target installs the downloaded updates and then reboots back into the regular default target. For more details, see http://freedesktop.org/wiki/Software/systemd/SystemUpdates Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still be possible from the UI without restarting the system. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Am 16.06.2012 15:06, schrieb Ralf Ertzinger: Hi. On Sat, 16 Jun 2012 14:57:30 +0200, Jochen Schmitt wrote One of the most inportant advance of Linux over Windows is the fact, that there are only a few situations - like kernel updates - which requires a reboot of your system. Linux has, in principle, the same problem as Windows, that while you can replace files that are in use running processes will (of course) not pick up the changes until restarted. this is not the problem in windows the problem in windows is that you CAN NOT replace a open file Most daemons do so when updated themselves which is a really bad behavior on production systems and was introduced not soo long ago with no way to disable this systemwide because each package has this restart crap but, for example, updating zlib because of an exploit will not restart all daemons using the exploitable library, so unless the admin restarts those manually or the system is rebooted you might still be vulnerable. yes you have to restart the services but at a time YOU decide and controlled without any dumb restarts you can rollout testsed updates at business-time and do the restarts ina small time window MS has choosen the reboot route to deal with this, and current versions leave it up to the user to initiate the reboot while nagging about it in regular intervals (which Fedora does not do, and I'm not sure this is a good thing tbh). no, no and again: no microsoft has chosen this way because windows can not replace open files and so you can not compare linux and windows here in any way signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
Kevin Fenzi wrote: #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo .fesco 868 I really hope this is rejected. As already discussed in the relevant thread, it would add bloat to the live images which would force us to drop useful software from the KDE spin to fit the size target. And for what gain? We have -debuginfo packages, we have ways to auto-install them when needed, and we even have the Retrace Server. I shall also point out that the percentages given for the size increase are very misleading, because they are for (xz-)compressed debugging information vs. uncompressed executables. But on the live images, EVERYTHING is xz- compressed. And of course already xz-compressed data will not compress any further with another xz run. So 43 MiB of xz-compressed symbols means a live image size increase of 6.14%! That is HUGE, and will require dropping a lot of other things to compensate for. IMHO, it is just plain unacceptable that this feature is being pushed through by its submitter without any regard to the live images, and I strongly hope FESCo will block this. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sat, Jun 16, 2012 at 11:58 PM, Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo .fesco 868 I really hope this is rejected. As already discussed in the relevant thread, it would add bloat to the live images which would force us to drop useful software from the KDE spin to fit the size target. Well as I said in the other thread ... we are in 2012 there is *no* reason why we should be restricted by a medium from the 90s. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Schedule for Monday's FESCo Meeting (2012-06-18)
On Sat, Jun 16, 2012 at 23:58:03 +0200, Kevin Kofler kevin.kof...@chello.at wrote: I really hope this is rejected. As already discussed in the relevant thread, it would add bloat to the live images which would force us to drop useful software from the KDE spin to fit the size target. And for what gain? We Be aware that there is a plan to switch to livemedia-creator for F18. That does things a bit differently and may have an effect on the size of the images. (I don't know whether they will be larger or smaller, but expect some change.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Schedule for Monday's FESCo Meeting (2012-06-18)
Following is the list of topics that will be discussed in the FESCo meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic ticket 861 - Cleanup of maintainers with bugzilla account .fesco 861 #topic ticket 857 F18 Feature: Initial Experience - https://fedoraproject.org/wiki/Features/InitialExperience .fesco 857 = New business = #topic ticket 863 F18 Feature: Clojure - https://fedoraproject.org/wiki/Features/Clojure .fesco 863 #topic ticket 864 F18 Feature: DNF - https://fedoraproject.org/wiki/Features/DNF .fesco 864 #topic ticket 865 F18 Feature: DragonEgg - https://fedoraproject.org/wiki/Features/DragonEgg .fesco 865 #topic ticket 866 F18 Feature: Dwarf Compressor - https://fedoraproject.org/wiki/Features/DwarfCompressor .fesco 866 #topic ticket 867 F18 Feature: Hawkey - https://fedoraproject.org/wiki/Features/Hawkey .fesco 867 #topic ticket 868 F18 Feature: MiniDebugInfo - https://fedoraproject.org/wiki/Features/MiniDebugInfo .fesco 868 #topic ticket 869 F18 Feature: Offline Updates using systemd and packagekit - https://fedoraproject.org/wiki/Features/OfflineSystemUpdates .fesco 869 #topic ticket 870 F18 Feature: SELinux Booleans Rename - https://fedoraproject.org/wiki/Features/SELinuxBooleansRename .fesco 870 #topic ticket 871 F18 Feature: SysV to systemd - https://fedoraproject.org/wiki/Features/SysVtoSystemd .fesco 871 #topic ticket 872 F18 Feature: systemd unit cleanup and enhancement - https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup .fesco 872 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
