Slashdot Mirror
Fedora Introduces Offline Updates
itwbennett writes "Thanks to a new feature approved this week by the Fedora Engineering Steering Committee, you won't hear Fedora 18 users bragging about systems that have been running continuously for months on end. 'Fedora's new Offline System Update feature will change the current system to something that is more Windows- and OS X-like: while many updates can still be made on the fly, certain package updates will require the system to be restarted so the patches can be applied in a special mode, according to the Fedora wiki page on the feature,' writes blogger Brian Proffitt."
why is this a good thing exactly?
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
"Installing updates while the session is running causes havoc with some apps like Firefox that have file resources that have not been locked (just try updating xulrunner when Firefox or Thunderbird is open)," blogged Fedora developer Richard Hughes.
Seems to me adding features to the package system that can determine and possibly correct such things (ie, closing Firefox or Thunderbird) would be the better way to go rather than force me to have to reboot. Hopefully it will retain the capability to install new software while updates are pending. I'd hate to have to reboot to install some tiny dependency. (A restart is required before you can install libfoo. Ugh!)
Good grief, the Stupid coming from Fedora and the GNOMEs is making my head hurt. We managed to update running systems with package management for how long? Leave it to the GNOMEs to fudge things up.... or just have Mac/Windows envy and convince themselves that this isn't a bug, it is a feature!
Democrat delenda est
> Are Gentoo/Debian really that intertwined with whatever Fedora maintainers decide?
Not yet. But if GNOME and/or Firefox start requiring the feature other distros have a choice between two bad options. This new Linux only notion that started with systemd is increasingly Fedora only. You can have your distro if you want, if it behaves just like Fedora. One big monolitic blob of alien tech. Want the new udev? It is part of systemd. Want the new GNOME, wait for it to be unusable without udev which requires systemd. And so on.
Democrat delenda est
I actually took time to read the TFA and as many background freaking thing that are related that I can find on this thing, and tell you the truth, I am still trying to understand
I just do not understand why they want to take the thing offline, in order to run an update
I mean, what is wrong in keeping the system running while the patches run in the background?
I can understand it if the thing got a big hit - either from a worm attack or trojan or attacks from the outside - ... in real big emergency where the system can't just take it anymore, maybe, just maybe, take the whole thing offline (or power down the entire system), that makes sense
But ... just updating the damn thing you gotta take it offline, just like Windoze?
What's the freaking point?
Muchas Gracias, Señor Edward Snowden !
A lot of Windows users have been burned enough to have learned the lesson that updates will not only interrupt your work flow, but risk dumping your unsaved files and/or the tabs that they were in the middle of reading when the update dialog popped up. These users are taught that the responsible thing to do is to keep their systems up to date, but what seems worse: an action that risks dumping all of your unsaved progress, or a "security update" that fixes something that hasn't been a visible problem on their end?
The workaround to the focus-stealing forced-reboot update is, of course, is simply *not to apply the updates in a timely fashion.* As long as their applications are up and running, and they'd prefer to leave them up and running, why would they?
With this move FC is just setting itself up for the deprioritization of updates, and this could ultimately lead to worse security and stability.
try resizing your /var or / LVM partitions while the system is running, let me know how that goes
An OS upgrade has no business resizing your /var or root partitions. Period. Heck, you have to be pretty ignorant if you presume they're always local.
Seriously, what has happened to Fedora lately? First they added gvfs so backup programs broke when root was denied access. Then the went Gnome 3 to cater to the iGeneration. Then they went to systemd, where you can't quickly and easily decide what to run on startup in each runlevel, but have to edit dozens or hundreds of different files. And don't even get me started on mtab. Now this?
Thank goodness RHEL is supposed to be feature fixed for many years to come. And there, updates don't require a reboot. They actually TEST.
Ok, you guys (and TFA) seriously missunderstand this feature, and yes it is a feature. This won't affect any update that doesn't already require a reboot. The difference is that currently if you update a critical system library, everything that depends on that library has the potential to act in an unstable manner until the next reboot occurs. This change says that if you're updating one of those libraries, the update doesn't actually happen at package install time, it gets scheduled to occur on the next reboot. That's it. No more extra reboots, just more stability and updates scheduled for boot time.
The fact that windows has this feature isn't a problem, its the fact that it requires it on nearly every dll update. The reason for this is that windows locks files when they're in use, so its actually impossible to update the file until the services that use it (which are often core system services) are stopped, ie at boot time. Linux has avoided this by making its filesystem be refcounted. If a file is in use and you delete it, it stays there until the thing using it exits. So library updates just delete the old library and install a new one, while programs using the old library continue to until they're restarted. This works until you have something dynamically loading stuff, or when you have ipc between programs using the different versions of the library, or a million other modern techniques that unix designers didn't think of.
Anyway, this really is not the travesty everyone here thinks it is.
ToasterMonkey is correct: The reason that you usually do not need to restart the system or applications on Linux is the fact that the potential problems of *not* restarting are simply *ignored* on Linux. It's a head-in-the-sand solution.
Most of the time this does not present a problem. It is only when some application uses dynamic or delayed loading (and the suddenly loads an updated and binary incompatible library), uses on-demand loaded resources (what Firefox does) or have other types of dependencies between what sits in memory and what sits on disk.
But there is no secret or magic sauce in Linux which makes this not a pronlem. It is simply assumed that it's not a big problem. But in the case of Firefox this is a regular occurrence. And we all what updating glibc can lead to.
Java will also delay/demand load classes/libraries. Updating to the next version of a Java application while it is running may very well set the running application up for a crash. If a library/class has not yet been loaded (or has been evicted), the risk is that updating the disk files will lead to an incompatible class being loaded when it is required. While designing with backwards-compatibility in mind is good style, it is not reasonable to expect that the developer foresees all of the problems and complexities this can lead to.
The same situation exists for binary modules and other types of runtime environments. As software is getting more complicated techniques such as dynamically or delay loaded libraries/resources, object serialization which depend on a specific binary format, pre-compiled scripts etc. all risk running afoul of the head-in-the-sand mentality.
What is needed is a way for applications or services to register that they depend on certain files. The application may very well be able to survive (or even encourage) updating some of the files during normal operating (think plug-ins). But other files are expected to *not change* beneath the application. This is a reasonable expectation, but only the application (developer) can tell the update process which files it is ok to change on the fly and which files really only should be changed while the application or system is offline.
At this time there is no way for applications or background processes to tell the Linux system or an installer what it should do prior to and after updating certain files. Individual updates may be written to look for certain processes it considers in-risk - but that is really getting it backwards.
Windows has had the Restart Manager (http://msdn.microsoft.com/en-us/library/windows/desktop/cc948910(v=vs.85).aspx) since Vista. Applications, device drivers, system services etc can now register with the RM (for instance all of the files in its directory and certain system wide libraries) and tell it that certain files should not be clobbered during an update/installation if the application is running. When an installer wants to replace a file which has been registered with RM, it can ask (default if using MSI installers) the RM to ask applications with a registered interest if it would be ok to save their state and close. If all applications/services agrees, the RM will then send the actual save+close message to the applications/services. The RM will then relinquish control to the installer which will replace the files. After the installation, the installer invokes the RM again to let it restart all of the applications.
When saving their state the applications/services can register how they want to be restarted to re-establish the state they left, i.e. Word and Excel opens the same documents, Chrome opens the same tabs re-establishing scroll positions etc.
When the RM determines that a file is being held locked by an application which is *not* registered with the RM it backs off and does not ask any apps to stop (it wouldn't know how to ask them to restart). Instead the installer schedules *all* of the files to be replaced "off-line", i.e. you will not have a situation where some of the files have be
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*