Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Fedora Introduces Offline Updates

samzenpus posted more than 2 years ago | from the while-you-sleep dept.

Linux 287

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

cancel ×

287 comments

Sorry! There are no comments related to the filter you selected.

um... (4, Insightful)

lister king of smeg (2481612) | more than 2 years ago | (#40405665)

why is this a good thing exactly?

Re:um... (0)

cryoman23 (1646557) | more than 2 years ago | (#40405919)

as far as i can tell its not, looks kinda like another ploy to make linux look/feel windows like... personally i like my machine to have massive amounts of uptime... and then hear about my friends needing to reboot every other day because of some update :)

I am still trying to understand (5, Insightful)

Taco Cowboy (5327) | more than 2 years ago | (#40406303)

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 (4, Insightful)

sdnoob (917382) | more than 2 years ago | (#40406527)

updates have been working just fine for years.. i don't understand either... sounds more like being too lazy to write proper post-install/update scripts that could trigger or recommend a reboot *when necessary*

___

to those who keep saying..

"i wish linux were more like windows"

there ya go. hope you're happy.

now sod off.

Re:I am still trying to understand (-1, Troll)

Anonymous Coward | more than 2 years ago | (#40406639)

there ya go. hope you're happy.

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

You sod off.

Re:I am still trying to understand (5, Funny)

Anonymous Coward | more than 2 years ago | (#40406947)

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 (3, Interesting)

TheRealGrogan (1660825) | more than 2 years ago | (#40406591)

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 unless they are 100% drop-in, binary compatible. 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. (I soon learned to "make install install_root=/someplace/else" first before running "make install" so I could easily manually install the finished product if the make install failed)

It's a lot easier when a distributor with packaging utilities is just installing same version with patches back ported, because the entry points and symbols and stuff are all the same. But these "offline updates" that happen in a "special mode" (While few daemons are running) will actually give them more freedom to upgrade things.

Re:I am still trying to understand (1)

Anonymous Coward | more than 2 years ago | (#40406693)

"more freedom to upgrade things" -> "programmers can be lazier about testing"

Re:um... (0)

AHuxley (892839) | more than 2 years ago | (#40406113)

A few gigs of updates on a dvd at work/edu/city vs a few hours of downloads on your broadband suburban adsl @ a few 100k?

Re:um... (3, Insightful)

moderatorrater (1095745) | more than 2 years ago | (#40406317)

You need to read the summary. When they say offline, they aren't referring to the internet, they're referring to your OS, ie you have to restart to apply the update. Just like Windows.

Re:um... (1)

lister king of smeg (2481612) | more than 2 years ago | (#40406385)

this has nothing to do with installing without a network connection it has to do with shutting down and rebooting to install. Read the summery and artical. Besides you can put the rpm's or deb's on a cd/dvd/thumbdrive and install them all now and i think there is a group working on super-deb's which is a deb package with the main app plus all dependencies. Not only that but you can already have synaptic generate a script to download the debs you need from a connected computer, in ubuntu it does at least. So not only were you wrong about the real issue you were wrong about the one you made a mistake about.

Re:um... (4, Interesting)

smash (1351) | more than 2 years ago | (#40406399)

I *suspect* it is perhaps due to securing system files in a manner so they can't be modified when running multi-user (thus immune to exploit by user code) - kinda like freebsd securelevels perhaps. At least, thats the only reason I can see for it.

Would it *kill* you to read the article? (2)

kiwimate (458274) | more than 2 years ago | (#40406443)

in order to avoid problems related to conflicts of libraries and services that are currently running with those on disk...

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â¦)

Re:Would it *kill* you to read the article? (1)

Taco Cowboy (5327) | more than 2 years ago | (#40406497)

I have read TFA, and I still CAN NOT understand the whole thing !!

If it's the FF, they can kill FF and re-launch the thing after the patch are done

What's the freaking need to take the whole system down?
 

Re:Would it *kill* you to read the article? (-1)

Anonymous Coward | more than 2 years ago | (#40406735)

try resizing your /var or / LVM partitions while the system is running, let me know how that goes. This is because real enterprises have issues your linux server in mom's basement don't.

Re:Would it *kill* you to read the article? (2)

lister king of smeg (2481612) | more than 2 years ago | (#40406717)

First off i did read the artical

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â¦)

but i am also a regular Linux desktop user and as for firefox needing to be shut off when ever i run update i am simply informed that i need to restart firefox. no reboot ever. occasionally i may have to logout and back in for a update/install but still no reboot needed. this is still a pointless bad idea.

Re:um... (0)

Anonymous Coward | more than 2 years ago | (#40406701)

Because, as an example, this may give server admins the ability to queue LVM resize operations on lvms (say shrink /opt or /var paritions) and grow (say /home) and get a post unmount or pre-mount phase in the boot\shutdown sequence. I might be able to then upgrade and hold an apache2 update, mysql, and syslog-ng and commit those upgrades in one-shot without having to walk into the server room, throw in a live disc or hook up a serial console or init to specific runlevels. In short: make administering remote linux machines more manageable. There are a surprising number of things in day-to-day linux that do require reboots now. The days of Linux being secure from viruses, maleware, and hacks because of it's obscurity are long gone. The bulk of virus and hacking most enterprises have to deal with are now in the Linux court because of complacency. This is a good thing so when I have to do it to 1200+ machines I don't have to spend 9 hours doing it. Yeah, 9 hours because every damn machine needed to have a boot CD so pre-mount work could be done.

Re:um... (1)

slazzy (864185) | more than 2 years ago | (#40406873)

I think Fedora is intended to be "bleeding edge" technology wise, so they are trying something new (for Linux) and I guess they'll see how it works?

Wrong area of focus. (5, Insightful)

elysiuan (762931) | more than 2 years ago | (#40405669)

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

Re:Wrong area of focus. (2, Insightful)

silas_moeckel (234313) | more than 2 years ago | (#40405871)

So a bunch of gui apps are breaking things? Step A tell them there idiots and to fix there broken bits. Step B go down to text mode and back lets the X sessions figure themselves out. Why would you need a reboot for any of this. Server apps should be restarted if needed and user apps should not be so broken.

Re:Wrong area of focus. (4, Insightful)

tuffy (10202) | more than 2 years ago | (#40405935)

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.

This is exactly right. Look at the Flash updater on other systems. If a browser is running, Flash closes it down during an update. Fedora could easily detect Firefox is running and close that down during an update. If X11 needs an update, bounce the user to the console until it completes. And so forth. A whole boot mode just for installing "extra important" updates feels like the wrong approach to a more general problem.

Re:Wrong area of focus. (4, Interesting)

serviscope_minor (664417) | more than 2 years ago | (#40406253)

If X11 needs an update, bounce the user to the console until it completes.

Or, update X, and the user gets the new version when X is next restarted. This is what Arch does: the old files (binaries) are deleted, but remain on disk until the program exits. I've had uptimes of many months and not had trouble with X being updated.

Re:Wrong area of focus. (2)

matthiasvegh (1800634) | more than 2 years ago | (#40406445)

Do that, and 4 months later, -one- of the many successfully applied updates will screw things up, and you'll have to figure out which update exactly was the culprit. Don't get me wrong, it's a fine strategy, it's just one of the reasons I dread reboots..

That _still_ doesn't make sense !! (1)

Taco Cowboy (5327) | more than 2 years ago | (#40406529)

Do that, and 4 months later, -one- of the many successfully applied updates will screw things up, and you'll have to figure out which update exactly was the culprit.

Problem is, it still does NOT make any sense !!

Okay, they took the whole system down and do a reboot

Does that provide any guarantee that 4 months from now one of the updates will not fuck up and leave you scratching your head?
 

Re:That _still_ doesn't make sense !! (2)

DeSigna (522207) | more than 2 years ago | (#40406627)

It's still best practice to pull systems from production for updates and restart after patching to test for issues.

Rebooting makes sure everything is using the new version, making it quite obvious if there's any big problems with the updates.

Having the updates process force-kill dependant applications on a multi-user or server system isn't going to make the sysadmin any friends unless they are taking it out of production first. Enforcing this for Fedora makes sense (it's upstream of RHEL), and it reduces the support problems of users complaining about weird issues after updating a month ago.

Re:Wrong area of focus. (1)

CastrTroy (595695) | more than 2 years ago | (#40406451)

The problem is, is that X doesn't get updated until you actually restart the process. If you don't restart for many months, you haven't really updated anything. This is especially true if, for instance, you are updating Apache. If you leave it running, and don't restart it, the updates never actually get loaded, and your system is still vulnerable. Same goes for things like Kernel updates. I know that it's possible to swap the kernel out while running, but I don't think most distributions do that. To reload a new kernel, you have to reboot. I could see how this would be useful. Fedora is supposed to be a Desktop centric distribution. And while you could use it as a server, many of the features are aimed at desktop users. For advanced users, it's probably fine to let them restart certain processes whenever they want, but if they want to make inroads with the general public, then having the system reboot when it's necessary to make updates is probably a good thing. And if you're going to kick the user out of X to apply updates to that, you might as well be rebooting the entire machine, at least in a desktop setting.

Re:Wrong area of focus. (2)

reub2000 (705806) | more than 2 years ago | (#40406691)

Fedora has never been aimed at the general public. I've always seen it as aimed at power users who don't want to tweak things to get a working desktop. A middle ground between Ubuntu and Arch.

As far the rebootin, that's just silly. If the Fedora devs think the user should reboot after applying an update, then they can present that as a message to user after they apply updates. Then the user can reboot if they want to.

Re:Wrong area of focus. (1)

cheater512 (783349) | more than 2 years ago | (#40406339)

Or rather make programs not care if their files get updated. It should all be in memory anyway.

I can do a full system update (Gentoo) without any programs caring that their files have been replaced by newer ones. Restart a program, say Firefox, and its the new version.

Re:Wrong area of focus. (2)

SuiteSisterMary (123932) | more than 2 years ago | (#40406645)

Then you get somebody who things 'woohoo, I'm all up to date!' and doesn't wind up actually restarting the program in question for however long, and is vulnerable.

Re:Wrong area of focus. (1, Insightful)

Anonymous Coward | more than 2 years ago | (#40405953)

They are finally dropping the tired dogma and figuring out what everyone in the commercial world figured out 20 years ago. Yes, you can live update your simple LAMP setup and manually restart Apache. However, in a desktop environment, you have a complex series of library dependancies, the only feasible way to ensure everything is updated is to restart the world. Otherwise you have users running with known security holes for months until they feel like rebooting. This is a good sign that Linux is finally targeting normal users and not just unix administrators.

Re:Wrong area of focus. (0)

linuxtelephony (141049) | more than 2 years ago | (#40405999)

So, exit X and all X apps, update, restart X. You've "restarted" the graphical world.

Rebooting the entire machine is just lazy, short of a kernel update, and even then there used to be other options (ksplice, which oracle bought).

Re:Wrong area of focus. (2)

nabsltd (1313397) | more than 2 years ago | (#40406125)

So, exit X and all X apps, update, restart X. You've "restarted" the graphical world.

Not quite, because some KDE and Gnome daemons run even if there is no X server started. But, restarting these should do the trick.

Re:Wrong area of focus. (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40406449)

OS X has an "offline updater" and just reboots the machine. My Mac boots in like 5 seconds off an SSD, so what you're suggesting is a lot more complicated and would be only be slightly faster.

It's not 1998 anymore, every OS is stable and can boot quickly. Nobody cares about your "uptime".

Reboot still does not guarantee anything (1)

Taco Cowboy (5327) | more than 2 years ago | (#40406589)

Not quite, because some KDE and Gnome daemons run even if there is no X server started. But, restarting these should do the trick.

Now, can you guarantee that the system after the reboot will never have any problem left ?

The list of daemons that runs on the background, even after X is taken off, is already known.

They could have just create a script to off all those daemons, after that, patch the system, after that, re-launch all those daemons, without having to reboot

Couldn't they?
 

Re:Reboot still does not guarantee anything (0)

Anonymous Coward | more than 2 years ago | (#40406779)

Yes, if only there was a script to launch all your daemons... We could call it "init".

Either that or someone could afro-engineer this other thing you guys are talking about. I'm sure none us have anything better to do but learn a new completely different system for starting daemons.

Re:Wrong area of focus. (0)

Anonymous Coward | more than 2 years ago | (#40406107)

And we just had a bunch of development LAMP services go haywire because Python updates changed the on-disk libraries in a way that confused our mod_wsgi Python web apps. And the packages apparently don't track dependencies like that, so we had to restart HTTPD manually.

I don't think offline update is the answer though. The answer is a packaging model and file layout that allows side-by-side install of multiple versions of all resources, so that there isn't this insane race condition where an update replaces resources that might be in use or start being used at any moment during the update process.

Re:Wrong area of focus. (1)

smash (1351) | more than 2 years ago | (#40406423)

+1 to that. End user desktop = easier to just restart the OS. If its a server platform, well the admin can figure it out and re-start stuff manually.

Re:Wrong area of focus. (0)

marcello_dl (667940) | more than 2 years ago | (#40405963)

> just try updating xulrunner when Firefox or Thunderbird is open

That's a package manager issue. Service/apps need to be restarted? notify it ahead of installation, or restart them. Isn't it nice to login using ssh, update ssh and not lose the connection?

This offline updates idea is a wasted april's fool joke.

Re:Wrong area of focus. (3, Interesting)

Anonymous Coward | more than 2 years ago | (#40405971)

The correct solution seems to be how Gentoo does it: Install BOTH versions of the library. Until nothing is accessing the old version anymore, it won't get uninstalled. So in this case, until FireFox is restarted it will keep having the old version of XULRunner around all the live-long day.

Or is using library versioning really such a foreign concept to newer Linux developers? Hell, my Gentoo box right now has four different versions of Python installed: 2.4, 2.6, 2.7, and 3.2, so I can do cross-version development against latest-2, latest-3, and CentOS 5.x and CentOS 6.x equivalent versions.

Re:Wrong area of focus. (0)

Anonymous Coward | more than 2 years ago | (#40406235)

Is Gentoo still glued to python 2.4?

Re:Wrong area of focus. (1)

Anonymous Coward | more than 2 years ago | (#40406333)

And why is this a good thing? Running a vulnerable version of XULRunner with known security holes just for connivence sake is retarded.

Desktop Linux will never ever become popular, but if it were, attackers would be taking advantage of this.

Re:Wrong area of focus. (3, Insightful)

bill_mcgonigle (4333) | more than 2 years ago | (#40406083)

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

When Ubuntu noticed this same problem, they included a Firefox extension to tell the user to restart. Fedora tries to re-plumb the OS and re-invent the behavior Windows is moving away from instead?

Fortuantely, it looks like this is constrained to the GNOME environment at the moment, so most of us may be safe - for now. I'll have to surf over to the KDE list to see if there's some righteous indignation going on there.

Re:Wrong area of focus. (0)

Anonymous Coward | more than 2 years ago | (#40406359)

And waving a magic wand and saying "ooga-booga" would be great if it worked, too.

Actually resolving dynamic library dependencies is a nightmare in this day of "object oriented code". And the likelihood of a system to reboot, successfully, and run all the installed services drops *dramatically* if the package managers try to get cutesy with library and utility integration.

Think I'm kidding? Take a *good look* at the underlying mess that is Java module loading, and the typically crapware hand-driven installation mes that is JBoss. Then take a look at the tendency of people to hand-install PHP, Pythin, Perl, and Apache modules on top of existing components. Then take a really good look at the CPAN and Maven software building systems, which randomly collect the latest untested crap from the offsite repositories and are never tested against the existing, already installed components when run by hand, and which are *never recorded in the packaging system*.

The stupid! It hurts! (4, Insightful)

jmorris42 (1458) | more than 2 years ago | (#40405673)

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!

Re:The stupid! It hurts! (-1)

Anonymous Coward | more than 2 years ago | (#40405853)

It must be tough being a virgin in our modern sex crazed world.

Re:The stupid! It hurts! (2, Insightful)

Anonymous Coward | more than 2 years ago | (#40406085)

Not really, it's pretty easy.

Re:The stupid! It hurts! (0)

Anonymous Coward | more than 2 years ago | (#40405939)

That's not as stupid as the Fedora 17(18?) 'feature' that requires merging /bin /lib /sbin into the /usr equivalents and will cause breakage with doing in-place distribution upgrades. So now finally you actually *MUST* use that stupid anaconda based installed CD that will tell you 8 to 24 hours to 'upgrade' your system while it's offline.

Re:The stupid! It hurts! (3, Informative)

Swave An deBwoner (907414) | more than 2 years ago | (#40406191)

It's possible to convert to the new unified filesystem without using anaconda, as described here [gmane.org] and in the original reference here [fedoraproject.org] .

I can say from personal experience that the method described worked, without evidence of any problem, when I upgraded via yum from F16 to F17 on a hard drive dedicated to Fedora.

Re:The stupid! It hurts! (0)

Anonymous Coward | more than 2 years ago | (#40406269)

Yup. I used the same method. Worked great!

Re:The stupid! It hurts! (2)

jmorris42 (1458) | more than 2 years ago | (#40406293)

No, preupgrade can handle it. It still requires a reboot into Anaconda but it does its work without any need for interraction and it does it fairly fast.

I was opposed to the merge on historical principle until I read all of the arguments and thought on it a bit.

The change does make sense. Existing practice is a solution to a problem that hasn't really existed for decades. The whole distro now fits into a tiny (by modern standards) partition and we have rescue media now so the importance of always being able to boot / to make repairs doesn't apply anymore. Meanwhile the benefits to nfs mounting of the OS and just generally putting all of the OS proper down that one /usr tree feels right.

It probably should be called /os instead of /usr but that is probably a bridge too far from the changing established practices p.o.v. But imagine a future where we fixed everything to no longer even need the symlinks to the old /bin /sbin /lib, etc. Then I wonder how much trouble it would be to work out sharing /etc and /var between two distros? Then instead of /usr you put Fedora 20 under /fedora-20 along with /debian-wheezy and the initrd sets up the default paths on boot. Suspect it would require too much standardization of things in /etc though for distict distros to even mean anything. Just thinking aloud, trying to get outside the box a bit.

Re:The stupid! It hurts! (1)

steelfood (895457) | more than 2 years ago | (#40406175)

Next up: All the niceties of DLL hell.

If anything, people should be working towards not having to restart for all updates, even kernel patches. Instead, in the fevor to be more like iOS/OSX and Windows, Linux is regressing.

Re:The stupid! It hurts! (1)

digitaltraveller (167469) | more than 2 years ago | (#40406261)

As parent said, this is a terrible outcome.

Moving on constructively, I would suggest fedora should just be a minimal package set and a system for managing VMs. A good way to partition each VM would be for example, each system that manages it's own packages (eg. ruby, perl, firefox). Because of the rise of multi core computing this would have no performance impact at all. The advantages of a system like this include easier system management, better security, and convenience. There will be better upgrade-ability because although fedora has no rolling releases (a shame), users will be able to create specialized appliances that they can copy over to the new version of fedora without hassle and upgrade them at their leisure. It is way easier to deal with variable-sized VM images then partitions.

Support the android mainlining project
http://elinux.org/Android_Mainlining_Project [elinux.org]

DO ... NOT ... WANT!!!! (1)

RabidReindeer (2625839) | more than 2 years ago | (#40406391)

It was bad enough being forced into logging out and back in again because the desktop couldn't gracefully handle updates.

Re:The stupid! It hurts! (0)

Anonymous Coward | more than 2 years ago | (#40406475)

Yeaah.... no, you have no fucking clue what you're talking about. It's painfully obvious that you're just making shit up and that you're one of the people who likes to talk about computers rather than actually use them to do things.

Re:The stupid! It hurts! (2, Informative)

Anonymous Coward | more than 2 years ago | (#40406583)

redhat (aka fedora) has always had a pathetic package mgmt system. They finally got something that didn't completely suck when they adopted yellow dog's, but really, RH's Not Invented Here mantra is really to its and its users detriment (I think since yellowdog was as RH derivative, and RH's pkg manager, uptodate, sucked sooooo bad, they made this one exception to NIH).

Debian has handled updates and major upgrades flawlessly for decades (years before RH existed). Maybe fedora / redhat can base their distro on something that works. Just become yet another Debian based distro that just works.

Debian just restarts the bits that are likely to break if they were not restarted. Config files that have been modified are always asked if you want to keep / replace / view diff and merge. I've got hosts that started on potato (mid 1990s) and are now running squeeze (current stable)-- uneventful upgrades, all (apt-get dist-upgrade; done.). Debian got it right, just use it.

Redhat seems to attract windows users, so I guess they will accept this just like they accept not being able to do upgrades (yeah, redhat recommends a clean install rather than an in place upgrade WTF up with that?!).

Re:The stupid! It hurts! (2)

k(wi)r(kipedia) (2648849) | more than 2 years ago | (#40406649)

Implemented for a small set of critical system packages, an offline[*] update makes sense. By "critical system packages", I exclude user applications like Firefox. At worst (or at best) the policy should be limited to kernel upgrades, the way it's been done in a typical Unix or Unix-like system.

Which strictly isn't necessary. For example, I've already "updated" my running kernel since two weeks ago, while my system continues to run under the old kernel. I know this has security issues, but I'm not a server, so I'm waiting for the next power failure to reboot and for new kernel to actually be used.

*I'm perhaps not the only one confused by the use of "offline" in the title and TFA. In a different sense, Debian and friends can already do an "offline" update. There's a "--download-only" option in apt-get and an equivalent option in GUI package managers like synaptic. A more accurate but less sexy title would probably be "Reboot now needed to complete Fedora system updates" (if that's what it really is).

What? (2)

Anonymous Coward | more than 2 years ago | (#40405681)

Bad things are features now?

Giving the people what they want. (redux) (2)

LighterShadeOfBlack (1011407) | more than 2 years ago | (#40405707)

Finally, the Fedora guys have listened to its customers and fanbase! People have been clamouring for years to be able to restart their computers needlessly after updating and now these long years of loyalty have been rewarded. Bravo, Fedora. Bravo.

Soft reboots! (1)

sidthegeek (626567) | more than 2 years ago | (#40405729)

They should use soft reboots with kexec, so the downtime is minimized. It really makes a difference by skipping all the POST and BIOS stuff.

Re:Soft reboots! (2)

tepples (727027) | more than 2 years ago | (#40406111)

I was under the impression that some cards needed all that "POST and BIOS stuff" in order to get back into a predictable state.

So everyone.. (1)

Severus Snape (2376318) | more than 2 years ago | (#40405731)

what's the most annoying feature Windows has? Nice one Fedora.

Re:So everyone.. (0)

Anonymous Coward | more than 2 years ago | (#40405851)

Not only that, but windows 7 almost completely did away with it. Back in college, I kept a win7 box running for at least 5 months continuously.

linux just gets shittier and shitter (-1)

Anonymous Coward | more than 2 years ago | (#40405759)

glad i jumped ship for OS X a couple years ago.

Re:linux just gets shittier and shitter (1)

cheater512 (783349) | more than 2 years ago | (#40406415)

Fedora != Linux.
The rest of us never have to reboot.

Re:linux just gets shittier and shitter (3, Funny)

UnknownSoldier (67820) | more than 2 years ago | (#40406455)

That's one thing OSX does right. It *shows* you if you need to reboot for EACH package. Microsoft _still_ can't get this right after how many years?? "This update may require to reboot." WTF you don't know?? Either it modifies kernel files or it doesn't? Either the resources provided by a .dll are in use or they are not. It's not fucking rocket science.

Fedora, whatever... wait, kill Debian and Gentoo? (0)

Anonymous Coward | more than 2 years ago | (#40405775)

This offline-updates feature, if made mandatory, will kill both Debian and Gentoo. Are you sure you want to do this without coordinating with their maintainers? The conflicting features are interactive post-install scripts and the general concept of installing packages from source one-by-one.

In Debian, package installation (or, more precisely, postinst scripts) may be interactive. If this is a remote server, how do I connect to the post-install script to provide the required input? This applies, e.g., to all applications that use a database via the dbconfig-common package and have SQL files in a standard location – if the SQL fails they ask what to do. The solution would be to extract and run all the config templates before the reboot, and ban using interactive features of debconf in other scripts. This does require dropping some error-handling features from dbconfig-common.

In Gentoo, there is no PackageKit. However, if it existed, your proposal would amount to compiling all packages between the first and the second rebot – i.e. ~10 hours of downtime if both Chromium, Wine, Inkscape and OpenOffice happen to be updated at the same time. In other words, Gentoo users rely on their system to be usable while compiling and installing packages one-by-one. The solution would be to use btrfs (once it becomes usable) and compile/install all updates to a writeable snapshot, as already suggested in another comment.

-- Alexander E. Patrakov [gnome.org] (Emphasis mine)

Are Gentoo/Debian really that intertwined with whatever Fedora maintainers decide? I can at see where the maintainers are coming from regarding a distro like Fedora, but if these changes affect other distros, I see it as very Not Good from my perspective.

Re:Fedora, whatever... wait, kill Debian and Gento (4, Interesting)

jmorris42 (1458) | more than 2 years ago | (#40405921)

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

Re:Fedora, whatever... wait, kill Debian and Gento (0)

Anonymous Coward | more than 2 years ago | (#40406025)

I hope the Debian project gives the finger to the Gnometards and whatever shit comes out of Fedora.
Time to make XFCE the default desktop environment for Debian, and maybe start polishing E17 and other less known windows managers.

Re:Fedora, whatever... wait, kill Debian and Gento (0)

Anonymous Coward | more than 2 years ago | (#40406897)

Oh well, you won't get very far relying on XFCE environment since the organization of developers hell bent on ruining Gnome (primarily the RedHat Desktop team) have teams very heavily involved in GTK and Xorg development. Desktop linux has unfortunately found itself too dependent upon one company for its technology; linux is closer to a monoculture than ever before and it's only going to get worse .

Re:Fedora, whatever... wait, kill Debian and Gento (2)

LordLucless (582312) | more than 2 years ago | (#40406177)

Not yet. But if GNOME and/or Firefox start requiring the feature other distros have a choice between two bad options.

Actually, I think it leaves with one good option. Give GNOME the boot, Firefox the finger, and ship with KDE and Chromium. I used to use both, until GNOME3 and Firefox's general suckiness pushed me off onto the alternatives.

Re:Fedora, whatever... wait, kill Debian and Gento (0)

Anonymous Coward | more than 2 years ago | (#40406485)

Oh, please. twm, and if you need virtual screen space, vtwm. I find the spew of useless, inconsistent, and confusing eye candy to be pure demoware that actively interferes with getting any work done.

Re:Fedora, whatever... wait, kill Debian and Gento (1)

Savage-Rabbit (308260) | more than 2 years ago | (#40406837)

KDE and Chromium. I used to use both, until GNOME3 and Firefox's general suckiness pushed me off onto the alternatives.

I'm kind of on the fence with Chrome, I regard it as a giant piece of spyware but I use it at work because it requires one click to create a security exception every time the Websense thought police software decides to rewrite yet another security certificate as opposed to Firefox where creating a security exception requires three clicks. As for GNOME I rather like it, it's rather fast, and I must be one of a handful of people who actually like the new UI even if it is bug ridden as hell. Even with all of their bugs and shortcomings I still prefer Xfce (despite the disappearing GUI widgets), Gnome (despite the blue screens and non functioning shortcut config utility) or even Unity (even though its still FUBAR) to KDE. I took one look at the latest iteration of the KDE desktop and boy is that thing bloated. It was sluggish on a brand new Lenovo desktop machine with 8GB of ram, an SSD and a NVidia display card.

Re:Fedora, whatever... wait, kill Debian and Gento (1)

LordLucless (582312) | more than 2 years ago | (#40406965)

I suggested Chromium rather than Chrome because it is open source - which means its processes are all open for inspection to avoid spyware, and it fits with Debians policies.

Re:Fedora, whatever... wait, kill Debian and Gento (2)

NotSanguine (1917456) | more than 2 years ago | (#40406035)

Not necessarily. From the Fedora wiki [fedoraproject.org] :

Also note that this feature is about implementing offline updates for GNOME. Other spins are not affected, although they could choose to use the same systemd and PackageKit infrastructure, and provide a similar experience.

[emphasis mine]

I guess you could just use a spin that doesn't require this or just not use GNOME.

per-package filesystems (3, Interesting)

bill_mcgonigle (4333) | more than 2 years ago | (#40405947)

It's too bad btrfs still has such performance problems with common applications (BTDTBTEXT4).

We really ought to have each package on its own filesystem. When there's an update, snapshot the filesystem, let currently running processes reference the old stuff so they don't crash, but new processes can have the new stuff. When the old version on longer has any references left, it can go away. This might not always make sense, but for a desktop it's a lot better than what we have now.

Yeah, there's some plumbing work that needs solving (rpm, containers interaction perhaps, VersionKit or whatever) but this idea of rebooting a linux system to get consistent updates is just picking at a scab, and indicative that a real solution is still necessary.

Re:per-package filesystems (2)

xororand (860319) | more than 2 years ago | (#40405993)

That's an interesting proposition. A similar idea has been realized in the research Linux (and Hurd) distibution NixOS.

"In NixOS, the entire operating system — the kernel, applications, system packages, configuration files, and so on — is built by the Nix package manager from a description in a purely functional build language. The fact that it’s purely functional essentially means that building a new configuration cannot overwrite previous configurations. Most of the other features follow from this."

http://nixos.org/nixos/ [nixos.org]

I just stumbled upon it recently. I have not tried it.

Re:per-package filesystems (1)

bill_mcgonigle (4333) | more than 2 years ago | (#40406435)

That's good stuff. Linux distributions need to stay nimble and borrow liberally from other good ideas.

I experienced rollback upgrades with nexenta, and liked that quite a bit. ZFS >> BTRFS right now, though.

I'm using Puppet to describe a test cluster, and I absolutely love that (at least the ideas if not the expression necessarily). Functional declaration is absolutely the right way to do things. I've been wondering about how something like Puppet (if not Puppet) should become integral to Fedora. Yum, rpm, puppet - all essential pieces to the puzzle.

If none of the distributions evolve, a new one will spring up that implements these ideas and rapidly steal mindshare.

Re:per-package filesystems (0)

Anonymous Coward | more than 2 years ago | (#40406647)

Yeah, the expression leaves something to be desired. I've been a hardcore puppet user for about 5 years now, with large production installations. I continue to use it because nothing truly better exists yet, IMHO. However, while Luke did a great job at designing some of the key bits of puppet, he really, really, failed (and fails) at the basic language design stuff for the puppet language itself. It's almost like he wrote a declarative OO-language for config.... but then no real concept of traits/mixins/roles, no multiple-inheritance, and variable scoping is a complete nightmare. Puppet's core ideas with a better-designed language front end would rock my world.

Re:per-package filesystems (0)

Anonymous Coward | more than 2 years ago | (#40406547)

So you want MVCC (http://en.wikipedia.org/wiki/Multiversion_concurrency_control) at the FS level? Seems reasonable.

Of course, now that you have (snapshot-)transactional semantics, you need transactional syntax. That means changes to POSIX.

Woops.

Re:per-package filesystems (1)

rrohbeck (944847) | more than 2 years ago | (#40406729)

Btrfs performance is bad due to a lot of seeks. With a SSD and Facebook's Flashcache to cache your rotating clunkers it performs very nicely.

ksplice anyone (1)

cryoman23 (1646557) | more than 2 years ago | (#40405955)

So as one project aim to help with linux uptime(http://www.ksplice.com/) another aims to shoot it down?! I love linux but can't we all agree that reboots should only be forced when actually required(and maybe not then even, just say "Hey reboot pal"), otherwise just restart the effected programs/services

what about freebsd? (0)

Anonymous Coward | more than 2 years ago | (#40405981)

if this is a gnome and firefox fuckup shouldnt this apply to the bsds too? or is linux just putting in extra effort to suck?

Re:what about freebsd? (1)

armanox (826486) | more than 2 years ago | (#40406329)

Last I checked GNOME 3 didn't run on BSD. Now, it's been a while since I checked, but, I remember the GNOME devs not caring about non-Linux platforms.

Re:what about freebsd? (1)

fnj (64210) | more than 2 years ago | (#40406539)

And just what do you think BSD will do when the orphaned Gnome2 is no longer a viable desktop (security vulnerabilities, unfixed bugs, etc)?

Re:what about freebsd? (1)

armanox (826486) | more than 2 years ago | (#40406817)

Well that's easy. They can use MATE, or a different DE (KDE works fine last I checked).

Re:what about freebsd? (1)

fnj (64210) | more than 2 years ago | (#40406833)

If you had said Xfce I could accept that :-)

It's a trap! (0)

Anonymous Coward | more than 2 years ago | (#40406007)

They just want to load shit while you're unable to watch it being loaded.

Offline updates are a SecureBoot requirement (1)

Anonymous Coward | more than 2 years ago | (#40406087)

Considering the flak they're catching for the whole move to Microsoft key controlled cryptographically signed bootloader and kernel (with no non-fedora sourced modules) it's not surprising that they're not bragging about this particular point: The offline updates are actually a requirement of SecureBoot.

The issue is that if you can update after any unsigned code is run the update process can be obstructed by malware on your system and thus malware defeating updates would be stopped. With "Offline updates" the updates are all performed inside a hermetically sealed totally signed pre-boot environment which checks the signatures on the updates themselves. Without this the SecureBoot only limits what people can do with their computers it doesn't improve security, so it's important.

There are also some rare issues like dbus updates crashing the panel, for example. These only happen about 0.01% of the time but with enough users the bug reports still flood the maintenance teams at RedHat.

Re:Offline updates are a SecureBoot requirement (1)

0123456 (636235) | more than 2 years ago | (#40406815)

Without this the SecureBoot only limits what people can do with their computers

I thought that was the whole point of 'Secure Boot'?

Again? (1)

Alex Belits (437) | more than 2 years ago | (#40406291)

1. This feature was in other distributions for years if not decades -- if kernel or libraries used by everything are updated, the updater asks the user to reboot, otherwise only affected programs are restarted.
2. It's Brian Proffitt, an anti-Linux attack dog again.

Re:Again? (1)

fnj (64210) | more than 2 years ago | (#40406555)

FAIL. That's not the same as what this MIS-feature does. This abortion actually APPLIES the updates during the bootup process - like -hack- Windows -spit-.

This feature was in other distributions for years if not decades -- if kernel or libraries used by everything are updated, the updater asks the user to reboot, otherwise only affected programs are restarted.

Re:Again? (1)

Alex Belits (437) | more than 2 years ago | (#40406599)

[citation needed], and Brian Proffitt does not qualify.

Re:Again? (3, Informative)

fnj (64210) | more than 2 years ago | (#40406751)

Assuming you don't want to RTFA, how about the the feature page [fedoraproject.org] itself.

Re:Again? (1)

Alex Belits (437) | more than 2 years ago | (#40406665)

Looked through Fedora wiki page he referenced. It's an experimental feature that may end up not even being used, applicable to a very small subset of packages, to make sure that updater itself won't get broken or confused halfway through the update process. What may say a lot about the expected quality of the package manager/updater, but with no real effect on anything.

To be fair, Gentoo occasionally suffered from the very kind of breakage they are trying to prevent, but Gentoo has an excuse of package manager using a full-blown development environment.

Re:Again? (1)

fnj (64210) | more than 2 years ago | (#40406775)

I looked at the page too. The word "experimental" does not occur there. It's targeted at Fedora 18 and is 85% complete already.

While I might not care if Fedora gets screwed up by this abortion, Fedora is the source for Redhat Enterprise Linux, and I care VERY MUCH if RHEL 7 gets screwed up come 2013 or 2014.

April Fool's Day? (0)

Anonymous Coward | more than 2 years ago | (#40406311)

I thought this was a joke article. It is hard to believe that it is true.

Direct link (0)

Anonymous Coward | more than 2 years ago | (#40406323)

The summary links to an article about this feature, but the Fedora feature page itself is located at https://fedoraproject.org/wiki/Features/OfflineSystemUpdates

Reading the feature proposal makes it sound almost as bad and just plain idiotic as the Slashdot summary. While Fedora will (for now) retain the ability to use plain YUM to install updated packages, this new update procedure really does attempt to ape Windows. It's a huge step backward and, like several other steps backward, this one has Lennart Poettering's name on it.

Not only will Fedora 18 feature support for MS secure boot, breaking from their tradition of only shipping software which can be freely modified and redistributed, but they're also introducing one of the most hated Windows features. It's like Red Hat is trying to slowly kill the Fedora project.

More Lennart Poettering vandalism (1)

fnj (64210) | more than 2 years ago | (#40406667)

Official feature page [fedoraproject.org]

Do not want. Will not accept. Have a nice day and bye. Fix stupid apps and libs; don't cater to lowest denominator. Yeah I understand in the proposal there is still an option to do updates the old way, but how long do you think that will survive?

This idiot is progressively turning linux into a cesspool. Don't take my word for it. Take the word of 18,600 guys [google.com] . This guy is a one man engine of destruction.

Awwww... (2)

Guppy06 (410832) | more than 2 years ago | (#40406519)

The headline made me think "Fedora will start sending patches and updates on CD through the mail."

users will just deprioritize updates (5, Insightful)

ffflala (793437) | more than 2 years ago | (#40406587)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>