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."

Comments

Wrong area of focus.

[elysiuan]

"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!)

I am still trying to understand

[Taco Cowboy]

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?

Re:I am still trying to understand

[Anonymous Coward]

I'll wait until I can actually do anything remotely useful in Linux, then I'll be happy.

Ignorance isn't bliss then?

Re:I am still trying to understand

[mysidia]

Well, yes they can get away with patching on the fly for a lot of things, but really the system needs a reboot or it might be unstable. Some things may segfault if libraries get yanked out from underfoot

Library changes don't effect running programs that have already loaded the libraries. The file on disk is updated; the program won't be linked against new libraries until it is restarted.

Ever see what happens when a glibc upgrade goes awry? You can't even so much as run "ls". Many times have I had to boot with other media and finish a glibc install by hand.

This is why you need a package manager. GLIBC is a critical system library.

Requiring a reboot for a GLIBC update makes it scarier, not safer.

Hardware doesn't always come back up when you issue 'reboot'; you know, especially when you are doing the update remotely, to systems several hundred miles away, and don't have the luxury of a computer monitor and power switch.

Sometimes the reboot takes a long time; sometimes you have a component such as a RAID card that hates warm boots, and will fail to come up properly after a reset until you cold boot.

users will just deprioritize updates

[ffflala]

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.

Everyone calm down

[Fnord]

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.