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
Bad things are features now?
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.
Spelling mistakes, grammatical errors, and stupid comments are intentional.
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.
what's the most annoying feature Windows has? Nice one Fedora.
-- Alexander E. Patrakov (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.
> 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
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.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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
epic sig..... ya i got nothing
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?
They just want to load shit while you're unable to watch it being loaded.
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.
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.
No, no, you're not thinking; you're just being logical. --Niels Bohr
Not really, it's pretty easy.
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.
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.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
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.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
It's possible to convert to the new unified filesystem without using anaconda, as described here and in the original reference here.
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.
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
Yup. I used the same method. Worked great!
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.
Contrary to the popular belief, there indeed is no God.
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.
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 !
I thought this was a joke article. It is hard to believe that it is true.
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.
It was bad enough being forced into logging out and back in again because the desktop couldn't gracefully handle updates.
Fedora != Linux.
The rest of us never have to reboot.
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â¦)
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.
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.
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.
The headline made me think "Fedora will start sending patches and updates on CD through the mail."
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?
Muchas Gracias, Señor Edward Snowden !
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?!).
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.
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?
Muchas Gracias, Señor Edward Snowden !
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).
Official feature page
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. This guy is a one man engine of destruction.
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.
Only to idiots, are orders laws.
-- Henning von Tresckow
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 .
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.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
> redhat (aka fedora) has always had a pathetic package mgmt system.
No, rpm is a better system than deb. It had signed packages years before Debian and nice all in one file .srpm/.src.rpm files that build from pristine sources plus patches and a .spec. And rpm specifically forbids (although clueless commerical vendors sometimes ignore it) interactive install/update, absolutely required for mass installs or unattended update. I think you are getting confused over the update systems built atop them. There I would agree that Debian's apt family was better than what Red Hat was shipping until fairly recent versions of Yum and even then I would note that Yum is still a P.I.G. And delta rpms absolutely rock if you aren't sitting on the wire with a local mirror.
> Debian has handled updates and major upgrades flawlessly for decades
Not exactly. It took far longer to update my Mythtv system from Debian 5.0 to 6.0 following the directions at debian.org than I have ever spent doing a single version upgrade on a RH/Fedora system. Admitted that was my first time doing a version update on Debian on a machine I cared about and was taking pains to avoid pooching the system so that probably accounts for some of the extra time. Along with the fact that it was connected to a TV and the console was not easily visible so I was also taking care to keep it available over the network at all times during the process, something I haven't tried yet on RH. Point is neither one does version upgrades 100% hands off.
> (years before RH existed)
Obviously you weren't actually using Linux way backthen or you wouldn't have said something so ignorant. Debian saw first light Aug 1993 and got it's first primitive package system with 0.01 in Jan 1994. It didn't hit 1.x until years later. RH released 1.0 Oct 1994 and got rpm in 1995.
> Debian just restarts the bits that are likely to break if they were not restarted.
Like RH up until this idiotic new notion.
Democrat delenda est
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.
It's not Linux that's regressing, it's Fedora.
RHEL, the non-community release based on Fedora, doesn't ever require restarts. You can, if you like, but they actually test that the updates don't require the new kernel they provide. If the Fedora guys present a community release that's completely unusable for RHEL, I expect that Red Hat will pull support of Fedora, and spend that money on in-house development instead. When Red Hat said they wanted to support visionaries, I'm quite sure they didn't mean the kind of visions you only get through illegal substances, and where you end up wearing underwear on your head.
First, yum is superior technically to debians packaging system. Not going to bother explaining, because I seriously doubt it would do any good.
Next, this idea of rebooting (technically, two boots - download updates, reboot into a small system, apply updates, reboot into complete environment) is an idea that won't matter much soon.
Hard drives are already in the 3TB territory. btrfs or zfs will become necessary for reliability. When this happens, snapshots will be available to solve the problem properly.
Now, why Redhat recommends re-install? Redhat really only sells servers. Best practice is to re-install to verify that nothing has been forgotten during an upgrade. This applies whether its AIX, Redhat, Solaris or even Windows.
Fedora? Supports preupgrade. Just updated from F16 to F17 with that. Note that /bin is now only symlinks to /usr/bin; a major filesystem layout change was included.
It just worked (originally installed from a Fedora XFCE live CD spin).
Just another "Cubible(sic) Joe" 2 17 3061
It appears to me that the real problem is that these libraries are not versioned.
Surely a neater solution would be to have some type of version number associated with them so that multiple copies of a library could co-exist peacefully on the same system.
Two roads diverged in a wood, and I - I took the one less travelled by. (Robert Frost, 1916)
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.
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!
I'm sorry, but there is not one bit of POSIX or UNIX or Linux or Gnome or GNU or Open Source, etc. design that deals with explaining system behavior after replacing arbitrary parts of the library search path, or in general, any filesystem resources at runtime. There is nothing special happening in Linux in this regard, no magic, your emperor has no clothes.
You Linux guys have been burying your head in the sand this whole time. I sat through it while Windows locked files that were in use and you all made fun of it, Solaris recommended booting into single user mode to apply updates, and you mocked that. They improved greatly over the years, gaining convenience while maintaining system integrity at runtime. OS X, Windows, and Solaris either lock files in use, apply system updates from a special environment, snap shot a running system root, or some combination of those. Linux systems just skate by doing NOTHING, maybe an individual update will restart the service it is responsible for (MySQL RPM) maybe it wont (httpd RPM).
A god damned teenager with weeks of Unix experience can even come up with "If you only have to reboot to update your kernel, how do you patch your C runtime? Hey... what about other libraries?" It scares me that most people posting on this page have absolutely no clue how ghetto the operations behind a 'yum update' are, and many of you sadly, are professional Unix system admins. Some of you even taught yourselves not to apply system patches from a GUI tool, and you still just don't get it, you never stopped to think WHY, what was the problem, and how could that be FIXED.
It truly is scary, the lack of engineering discipline displayed by people who call themselves "geeks". Step one is admit you have a problem. Step three is do what these Fedora guys tell you to, they have a clue, you mentally lazy bastards.
- Angry in IT Ops
First, yum is superior technically to debians packaging system. Not going to bother explaining, because I seriously doubt it would do any good.
By all means, please do.
I've worked professionally with the RPM build system and at one time was far too intimately aware of its shortcomings. I haven't built nearly as many .deb packages, but what exposure I've had to them sure made me feel good about their packaging toolkit.
From a sysadmin's perspective, I don't particularly hate yum, but I don't see anything that makes it more compelling than apt. In fact, I don't see a lot of daylight between them any more, except for yum's tendency to go online and update itself prior to every operation (a minor annoyance for those of us who live in a low-bandwidth part of the world).
So I'd be really interested in knowing what exactly makes yum superior to apt (and aptitude especially), because for the life of me I can't see it, despite using both Debian and Redhat since the 1990s.
Crumb's Corollary: Never bring a knife to a bun fight.
As others have commented, the wiki is not very clear on all implications on this, but as far as my use of linux (12 years now), I have never had to reboot for any kind of update or security patch that is not kernel related or glibc, that is why I use Linux, because once it works it just keeps working, I really hated the times when even installing an application on Windows would reboot the entire system, WTF?
Seems to me that the upper level of the Linux desktop stack is getting more and more complex and more and more fragile, needing now this kind of "kludges" (in my personal opinion) to keep stuff running.
Fortunately the server side is very different and I hope this does not extend to the server stack, having to reboot because you updated apache, postgresql, php or whatever your stack includes; a good amount of server software is designed to keep working with minimum downtime, even on updates, like nginx that can reload itself without loosing connections (by keeping an instance to finish its work and exit when done while giving the new request to the new reloaded instances), even ssh can be updated without loosing you current session.
C-x C-c
"The Linux Ecosystem" isn't Red Hat's responsibility. It's not their fault everyone got bored of working for free on thankless bullshit and moved on. If you want to see a different direction then take it there. It's open source, after all.
I read TFA, and read some of the comments above, and I still don't understand why it's infeasible to stop/start the appropriate programs and services, patch/replace software, then start them again.
TFA gives the example of Firefox freaking out if you upgrade xulrunner while it's running. Solution...(wait for it)...close Firefox for 30 seconds while the changes are occurring! (Anyone...?) I really don't see why that example can be considered valid, since I've been doing it for years--both in Linux and (*gasp*) in Windows--without restarting the whole friggin' machine in the process. (Also, some versions of Firefox/Xulrunner packages--incl. Ubuntu's, IIRC--will prompt you to close Firefox before continuing.)
I can understand that upgrading parts of the GUI (as well as other things, of course) while it's running causes problems. I've had Gnome, Unity, KDE, etc. crash/glitch badly as a result...but it's never something that can't be fixed by...(wait for it)...shutting down the GUI for a minute and running apt/yum/emerge/whatever from the command prompt. It works in every single distro I've tried. Also, network services like Samba/CIFS, NFS, Avahi, etc. are quite alright with "service stop X"/"service start X", so that's not an issue, either. (Restarting them takes a lot less time than rebooting, obviously.) Finally, I don't think I've yet encountered a single service in the dozen or so distros I've used that can't be stopped/restarted for an upgrade if you know what you're doing. In VERY rare instances, you have to go down to init 1 (which isn't all that different from rebooting, in many ways--but is still faster to recover from), but that's usually just a workaround for not knowing what services depend on others--which Fedora's devs obviously DO know (or I'd find it quite amazing/surprising if none of them did, at least). I don't use ksplice, so I understand the need to reboot for kernel upgrades...but that's always been the case, and I don't see it as a big deal. Just how often are you planning on upgrading your mission-critical, "always-up" server's kernel, anyway?
So, it would seem that: (1) Fedora's doing something else that's crazy-different from what every distro in the world has done up to this point (perhaps involving an upstream change?); or (2) I'm missing something important--that nobody else seems to get, either (outside of Fedora's developers, or maybe someone I haven't yet read the explanation from); or (3) Fedora's just doing something really, really stupid that shouldn't actually be happening. As a new Fedora user (refugee from Ubuntu's Unity push...), this kind-of ticks me off.
One last thing: it was mentioned that Fedora is not generally used for business/mission-critical applications. Huh? It was my understanding that Fedora is used for little else! (It's certainly not designed for Desktop end-users, what with their draconian media codec/non-free software policy. As a "technical user," it's not a big deal for me to add repos and such, but I certainly don't recommend it for Mom and Dad.) Also, it's always been made clear that Fedora is the "testing ground" and (in a sense) "upstream" for RHEL--which is absolutely used for mission-critical and business stuff. I guess I just don't see how they're fooling themselves into thinking that this change is "good."
Thoughts? Am I just too dense to understand the reasons? Are the Fedora folks really being as stupid about this as I suspect? (I have great respect for them, in general, but a stupid idea is still stupid, no matter whose it is.) Does anyone know of a *good* reason for this change?
Have a good one, all.
--Dane
Hmmm... Just wondering...
Maybe... it has something to do with the secure boot thingies?
You know - that stuff Microsoft is pushing on the hardware makers to make sure the hardware is booting Windows 8 and all other operating Systems are locked out until they pay "boot money"? You know - the $99 Red Hat would have to pay to make sure Fedora can be dual-booted on a Windows contaminated system?
It would not surprise me a bit if this whole reboot circus is a result from this side infection from MS Windows.
Because ... wait for it .... applications not behaving properly during updates and figuring out what to do is NOT the expected behavior for non-technical end users?
Because ... wait for it .... applications not behaving properly during updates and figuring out what to do is NOT the expected behavior for non-technical end users?
Of course; I realize that. It is, however, the expected behavior for those making the packages: if program/service X is running, stop it or prompt the user to do so. I've seen it done before, so why not now?
have they figured out how to have peer-VMs share physical memory?
+1 to that...
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Gnome and/or firefox are becoming increasingly irrelevant...
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
KDE is becoming increasingly Linux only as well.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Oh hey, it's another brilliant idea for fucking up my Linux systems. I wonder if Lennart Poettering has anything to do with it.
Let's see:
I thought Fedora was implementing some kind of tool for computers without connection receive updates from media disks without so much issue. Like, generate package list in the offline computer, download in an online computer, burn in DVD/USB/whatever, update the offline, done.
It would be far, far more useful than this reboot thing...
Nerdy news for your nerdy needs? http://www.soylentnews.org Soylent News is people!
Though I must admit Razor-QT does feel different.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Well, there are 2 Qt based DEs still around - KDE and Razor-qt. The former is the rich DE w/ all those K-apps bundled in, while the latter is sans all the bloat. So doesn't matter what happens to GTK and X.org - Qt still has its desktops, and KDE5 also has Wayland support as a goal, so the GTK based DEs and X.org aren't gonna remain all there is of Linux.
Besides, Fedora is by no means the only game in town - aside from Debian and Gentoo and others (Arch, Slack and so on), there are still the BSDs. So if you don't like the trends w/ Fedora and fear that it's contaminating the other Linux distro bases out there, you can always go to the likes of PC-BSD, GhostBSD or some of the other BSD distros that are out there.
Half my systems, more or less, have /usr mounted read only and about a 10% have /boot mounted read only.
The rational for mergin /bin and /lib into /usr is that you don't need them to bring up a minimal shell if you are using initrd and have busybox compiled into initrd.
The compatibility with other operating systems is sort of BS though, as it skirts the issue of most ports based software being installed in /usr/local/bin so you still need to use env to get a portable bash script.
I was skeptical until I remembered that my debian boxes all have busybox compiled into intird and it is reasonable to make busy box already has to mount /, and /boot, so why not have it mount /usr as well. Further if busybox can mount /usr it makes it more usable as a rescue shell.
The idea that Desktop software sucks so lets do what windows does is just stupid however.
Work bio at MMWD
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*
RPM generally lets you install to what ever file location you want via options, much more so than dpkg.
Debian's philosophy is that files being placed in the wrong place is a release blocking bug, so the end user needing to do this means fix the package instead of providing a flag for the dpkg to work around the issue.
Apt gets a lot of credit for being the user interface of Debian policy, but Debian policy means that apt has potentially less to do than yum, so it can therefore be a slightly less capable tool.
Work bio at MMWD
That is sort of surprising as PCBSD is based on kde, and it seems pretty popular among FreeBSD developers that use a full desktop environment.
Work bio at MMWD
It was sluggish on a brand new Lenovo desktop machine with 8GB of ram, an SSD and a NVidia display card.
If my eeepc 1000H can run it at an acceptable speed, your machine can too.
awww did his comment hurt your feelings? are you guys that sensitive that anything remotely critical is "flamebait"?
It had signed packages years before Debian
I don't know who got what first but as you said, Debian has this too.
and nice all in one file .srpm/.src.rpm files that build from pristine sources plus patches and a .spec.
Same as Debian, you have a [package-source].orig.tar.gz, [package-description].dsc and [debian-specific-patches].diff.gz.
And rpm specifically forbids (although clueless commerical vendors sometimes ignore it) interactive install/update, absolutely required for mass installs or unattended update.
You can do unattended installs or updates in debian with
DEBIAN_FRONTEND=noninteractive apt-get -q -y dist-upgrade
I think it's pretty safe to assume that the systems are equivalent nowadays.
What's the problem here? This sounds like a big win for KDE users (such as all the Gnome 3 refugees). Even pulling a minor point release of KDE using "yum update" can cause the current desktop to go absolutely haywire. Then you have to reboot. If the reboot can be postponed, all the better! And I really don't care if I have kernel release 3.3.3.2.1.1.1.2 or 3.3.3.2.1.1.1.4 - the kernel of the week's point releases rarely matter, and a reboot for that can be postponed indefinitely.
We managed to update running systems with package management for how long?
Yes, but we didn't actually manage to make it work with modern desktops. Firefox and Chromium both fail when the packages of libraries that they depend on are moved underneath the running process. It is fine to say that this is a package manager problem, but it has been a known problem for years and is still unfixed (telling the sysadmin that his users should all manually restart Firefox is not a seamless solution, even assuming that he notices the message and acts on it). You can hardly blame people for wanting a more robust desktop, with applications that don't start randomly crashing when the sysadmin (or an automated script) runs a background update.
Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to.
So, this really is a non-issue.
Sure
rpm --root
yum history rollback
yum history redo
yum downgrade
rpm -V (may be debsums?)
yum versionlock
yum --enablerepo --disablerepo
rpm --docfiles --configfiles
rpm/yum reporting is nicer
Only two commands rpm underneath and yum on top.
The GP tore a hole out of yum/rpm vs apt/deb. As you point out there really isn't much daylight between. Except that (as a non-administrator having to do occasional admin tasks) I find rpm superior.
Just another "Cubible(sic) Joe" 2 17 3061
While I agree with your sentiment your poor grasp of the facts harms the argument you are making by making you appear to be an ignorant fool.
Debian has not "Handled updated and major upgrades flawlessly for decades," Debian has only handled this for *years*. Debian has not yet reached its 20th anniversary, and apt did not exist at its founding (much less in a flawless form).
You cannot have a host that started on potato in the mid 1990s because potato was released in 2000. The only "Mid '90s" Debian releases were Buzz and Rexx. I don't consider the release of Bo in 1997 to be "mid" enough, I count it as "late" 90s.
Nevertheless, I have personally experienced what you experience: A system installed as potato that is still running today using the current stable. Debian's package system, package manager, policy and culture contribute to a high quality system where updates work smoothly and do not require reboots.
I want my Cowboyneal
You can hardly blame people for wanting a more robust desktop, with applications that don't start randomly crashing when the sysadmin (or an automated script) runs a background update.
Sure I can. It's an engineering problem they opted to solve in the worst possible way: Not solve it at all. I blame people for being lazy.
I want my Cowboyneal
What's wrong with the current system? How in hell is rebooting for update a feature? Stop "fixing" things that aren't broken!
Oh yeah I forgot to mention that I loathe Gnome 3.
It's not Linux that's regressing, it's Fedora.
AIUI the trouble is that fedora/redhat have a lot of influence with certain upstreams. This can make it difficult for other distros to resist the changes they are pushing.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
This just goes to show the shocking lack of innovation and forward thinking in open source software. Some people have, in fact, put in long hours to work out the conflicting libraries problem. Some people have, in fact, come up with creative and cutting-edge solutions, such as designing a referentially transparent formal DSL precisely for that, with non-destructive updates, such as this project:
http://nixos.org/nixos/
Instead, what we see is open source once again emulating the bad parts of Windows (but, to be fair, a good amount of innovation has been coming out of Microsoft: it adopts formal methods for driver verification, PowerShell (years ahead of anything on Linux), and pushes language innovations such as F# and the newer features C# has).
Advanced projects such the Nix package management system seem simply go way over the heads of the Unix gurus, the gray neckbeards and the not-so-old, that insist very much on older programming paradigms.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
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.
Thank God for that...if it were rocket science it would be something like "Pressing this button may or may not cause the rocket to explode". You'd be left wondering if the engineers were talking about rockets being a semi-controlled explosion that propels you into space or the alternative.
"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."
Except that's not true. At all. This affects only graphical updates via PackageKit. If you want to continue to update on-the-fly you can perfectly happily do so via yum.
I'm sorry but that will have to wait until the work on the new GNome registry is done. Oh wait. They already have that. Bring on the DLL's.
When patches come out only once a week or year for some products rebooting isn't an issue. But in the Linux world patches flow like water. If you need to be rebooting all the time that is going to kill one of the great security strengths of Linux. That is the credo of patch fast and patch often.
udev is usable without systemd. They are maintained in a single code base because there's a lot of shared code.
Which makes your argument funny... The reasons you'd dislike systemd are pretty much exactly the reasons people didn't like udev to begin with.
RH doesn't give a shit about the "linux ecosystem" or the "community", its like any other corporation. It only cares about the bottom line.
Just like Canonical?
Yup, but i don't think KDE upstream care. It is starting to depend on linux only things like HALD (for automount), and doesn't support the FreeBSD equivalent, DEVD. If you're a modern desktop environment developer it seems that no one cares about cross platform any more.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
TinyCore Linux uses one file system for each package, albeit with a very different intent:
Each package is a SquashFS file system that gets mounted & overlayed over the root FS at boot time.
Their intent is to save disk space.
and switched to LinuxMint, and have never even thought about going back. I don't have to worry about their screwing around with how they update shit, or whether they (or their parent company Redhat,) have decided to pay extortion money to Misro$oft, because I've switched away from any RHL based distro. Have been happy as fuck ever since. If you're still using that wretched distro, try Mint, it's better!
Mmm... Minty!
What does it TASTE LIKE, in you having to "eat your words" flavored w/ your foot in your mouth + spiced with the "bitter taste of SELF-defeat" -> http://slashdot.org/comments.pl?sid=2931443&cid=40430025
* Hmmm?? I don't care what evasive BULLSHIT you state here either - face me directly over there, that is, IF YOU HAVE *ANY* BALLS!
You surely trolled me there, and in other places (I proved that much there), so, let's see how "brave" you are, & see you disprove my points on custom hosts files and what they do benefitting end users of them... ok, troll?
Of course, you'll evade that too, as per your TROLLING weak usual!
(Now, I am going to do to YOU, what you *TRIED* to do to me, and you failed in it, numerous times, not just there... no, I am putting the shoe on the other foot, yours, and you put that foot into your mouth, lol!)
APK
P.S.=> You've trolled me in the past, & RUN from disproving points I made on custom hosts files, which I proved in that exchange also (as well as the fact you can't back up your b.s. technically either in computing), so "turnabout is fair play" & I am loving humiliating you for it!
Perhaps it will teach you a lesson to RESPECT YOUR ELDERS & BETTERS & do the next person dealing with you trolling them a favor, getting you to consider that not everyone "blows off trolls & ignores them"...
(Not I - I, rather, systematically DESTROY wise-ass worms like you, with your OWN FAULTS/MISTAKES, & especially since you seem to "get off" on trolling others... So, again - how's it FEEL when the shoe's on the other foot, AND IN YOUR MOUTH, and you've been made to look a fool for it?)...
... apk
What does it TASTE LIKE, in you having to "eat your words" flavored w/ your foot in your mouth + spiced with the "bitter taste of SELF-defeat" -> http://slashdot.org/comments.pl?sid=2931443&cid=40430025
* Hmmm?? I don't care what evasive BULLSHIT you state here either - face me directly over there, that is, IF YOU HAVE *ANY* BALLS!
You surely trolled me there, and in other places (I proved that much there), so, let's see how "brave" you are, & see you disprove my points on custom hosts files and what they do benefitting end users of them... ok, troll?
Of course, you'll evade that too, as per your TROLLING weak usual!
(Now, I am going to do to YOU, what you *TRIED* to do to me, and you failed in it, numerous times, not just there... no, I am putting the shoe on the other foot, yours, and you put that foot into your mouth, lol!)
APK
P.S.=> You've trolled me in the past, & RUN from disproving points I made on custom hosts files, which I proved in that exchange also (as well as the fact you can't back up your b.s. technically either in computing), so "turnabout is fair play" & I am loving humiliating you for it!
Perhaps it will teach you a lesson to RESPECT YOUR ELDERS & BETTERS & do the next person dealing with you trolling them a favor, getting you to consider that not everyone "blows off trolls & ignores them"...
(Not I - I, rather, systematically DESTROY wise-ass worms like you, with your OWN FAULTS/MISTAKES, & especially since you seem to "get off" on trolling others... So, again - how's it FEEL when the shoe's on the other foot, AND IN YOUR MOUTH, and you've been made to look a fool for it?)...
... apkcid=40430025
It seems that fedora needs to get a better packaging system. Man I love Arch Linux and pacman. Sure it doesn't tell you to reboot even with a kernel upgrade, but then again, arch assumes user compotence.