Fedora Linux Might Drop Incremental Upgrades (happyassassin.net)
prisoninmate writes: As you might know, Fedora and many other GNU/Linux distributions require users to do an incremental upgrade when attempting to move from an older version of the operating system to the most recent one. For example, if you want to upgrade from Fedora 21 to Fedora 23, you will have first to upgrade to Fedora 22. Lately, Fedora upgrades have become more stable and reliable, mostly because of some brand-new technologies, such as the DNF package manger. Fedora's Adam Williamson theorizes about an innovative method that might support official upgrade of the Fedora Linux operating system across two releases in the future.
I have gone from 20 to 23 via upgrades with no issues. The fedora team does a pretty good job with the instructions and methods. Now if they would only get rid of the stinking graphical boot and the "quiet" mode. What do people fear kernel messages at boot?
Yeah, occasionally, when there are major changes, like when systemd (peace be upon it) was introduced, this might not work, but I've gotten through quite a few version skips just fine.
Excuse my while I hurl. dnf from an interface perspective has been nothing but a headache for 2.5 releases, and it STILL can't do the things with reliability that yum did, nor does it have the ecosystem of plugins for people with various edge cases. And don't even get me started about local file system + repo installs.
Going back beyond that, "stable and reliable" is not the track record I would ascribe to anything about Fedora in the last 8 releases, except for maybe SELinux policy (except for the policy *RPM* which had a major clusterf*ck blocking update a couple of releases back).
Fedora brought us such lovely presents like UsrMove, the confusing mish-mash of grub2, and the unholy holy war precipitated by strong-arming the "systemd way of doing thing" from the ground up, so much as restricting RPMs from having *any* SysV support in the spec file.
So Fedora isn't inspiring a lot of confidence with moving to a direct rolling release. Frankly, people that want this might as well just sit on rawhide instead and re-vagrant/chef/devops/continainer their boxes anew each nanosecond.
Hire a Linux system administrator, systems engineer,
So basically what it says is that jumping from Fedora 21 to 23 is unsupported, but 21 -> 22 and 22 -> 23 is supported. Well that's nice, so why can't I daisy chain updates? It's not unique to Linux, I'm sure everybody who had to reinstall Windows knows what I'm talking about.... first there's a bunch of updates, then you can install some more updates, then update the updater, then install the service pack, then install some more updates, then some more security patches to the last updates. If you don't want to do the conflict management, at least let it simulate success and let you schedule up several rounds of patching. That way it could say install 22, okay after installing this then 23 will be available, okay install that too in round 2, after that install all updates in round 3 and then you hit "go" and it all happens at once without further interaction. Obviously if one round fails don't proceed to the next, that way you should have an updated machin in one go.
Live today, because you never know what tomorrow brings
I totally agree. I've been using a separate partition, fresh installs and Ansible playbooks for my last two "upgrades" and it's been a breeze. I do a HDD backup and put some stuff in the cloud just in case but so far no problem.
The only thing that is constantly a PITA is VirtualBox. Every single time it's a nightmare to get that thing running with the right mix of kernels, kernel headers and various libraries. When I move to Fedora 24 (or whatever version) I'm switching my VMs back to VMWare Workstation.
lucm, indeed.
welcome to the club :)
Wayland unfortunately doesn't fix many problems linux desktop applications have. You still will need compositor specific code in order to support more than the bare minimum. Fortunately however, wayland fixes many security related issues.
it seems like the MS win 10 strategy is making Linux distros follow suit. I wish Linux could get its own USP before copying MS. I love Linux mint but it's still catching instead of leading. open source is amazing, but how is this different to an apt-get upgrade? I shouldn't have to know this!
Excuse my while I hurl. dnf from an interface perspective has been nothing but a headache for 2.5 releases, and it STILL can't do the things with reliability that yum did,
What problems are there with dnf? I'm rather neutral towards it, but I haven't found any problems that I didn't have with yum.
"First they came for the slanderers and i said nothing."
Impressively bad new-slashdot headlining here.
Is it really worth plumbing the depths of false 'shock headlines' just to pull in views?
They are not DROPPING anything, they are looking at ADDING the ability to skip updates.
You can still incrementally update of course, there is no hint of dropping that.
They may allow you to instead update two versions in one go.
If anything, you could say they are dropping the REQUIREMENT for incremental updates.
But hey, the heyday of Slashdot editors is, as we know, long gone. Such a pity.
Libvirt and qemu are the way to go
Geology - it's not rocket science; it's rock science
I agree very much but I have a couple fears with Wayland :
- many apps may fail to implement mouse selection -> paste on middle click. Worse, we may get lectured by "designers" about how we do not actually want to do that?
- a new round of bugs and graphics driver limitations, obviously.
I suppose a 3D desktop on Wayland will have less bugs than a 3D desktop on Xorg, but more than a 2D desktop on Xorg. But may still have some new bugs anyway.
A crapton of applications will still require X so will run in the nested X server : have fun with the new bugs in that. (e.g. GIMP? GIMP is on GTK2.)
But is it really an upgrade? Doesn't the MS installer just installs a clean XP next to 98 and renames the Windows folder to Windows.old?
I was always under the impression that Microsoft didn't real upgrades, just fresh installs and then trying to install existing programs on the fresh installs based on the information found in the registry or install logs or whatever. Or by just putting a shortcut to the application somewhere on the hard disk and let the backwards compatibility do its work. Not that it's bad of course. It has worked for many people, so kudos to MS for delivering a working system (most of the time).
Many Linux distributions tried to upgrade installed packages in such an order that none would have missing dependencies, which often left you with a broken installation when the upgrade cycle failed in the past. Although the latest years I've never had problems with upgrades (Ubuntu/openSuse/Fedora), but I've heard numerous complains about broken upgrades.
What I would like to see in Linux is a kind of export that just lists all the packages that you have currently installed, an export of all the settings in all relevant files (like etc folder) and a way to back up all your data and maybe settings, so that you can reinstall all your packages after a new fresh install with the latest version of your distribution. Some sort of upgrade package that help you temporary save your settings and data on an external storage, until you are ready to reconstruct your system on a newer version of your distribution of choice. Preferably a distribution agnostic upgrade package that helps you 'upgrading' from Fedora 23 to Fedora 21 (yes a downgrade), or to Debian, Ubuntu, SuSe, etc ...
I personally like to do this by hand making a file with all install packages, but it is not really the same of course. You need to do some kind of hand code to put the reinstallation into a working script.
Took far too long to be released, was overhyped during the time, and when it finally came out, by a different group of people, it was derided for being a fairly lazy sequel to DN3D.
Well I just tried, and performance is awful compared to VirtualBox. The host is taking a beating and the guest is sluggish.
I've looked at a few Youtube videos of gamers and they had stellar performance with qemu and splice, but after reviewing the details I found out they typically use PCI pass-thru with a dedicated video card for the guest. When you're duplicating hardware and dedicating it to individual virtual machines I don't see the point of using virtualization at all.
Maybe qemu works well for headless servers, but for that kind of workload I use AWS (which now offers nano instances for $4/month!). On my desktop I use virtualization to run a bunch of guests with VPN connections to the network of my various clients, and apparently that's not something that I can easily achieve with qemu.
lucm, indeed.
'never had a problem with Fedora. I've only ever done a single install on the 4 machines I run (2 "desktop + 2 laptop)), and then incrementally upgrade 3 month after a new release.
I always do fresh installs since I have a /home on a separate partition.
OpenSUSE user here, been doing essentially the same as you for years. I have difficulty seeing why anyone would want to do it any other way.
Il n'y a pas de Planet B.
I recall celebrating The Year of the Linux Desktop in 2005. Maybe you were asleep and missed it.
Il n'y a pas de Planet B.
You have to reinstall all your applications/packages, reconfigure (assuming you've changed settings) etc. /home
System wide settings are not saved in
Yeah, I've been keeping /home on a separate physical drive for years, whatever OS I'm using (and periodically mirrored to a NAS).
Never understood why /home was not enforced to be at least on a different partition.
Mac
If performance is awful it sounds like you use the software emulation mode of qemu instead of the KVM extension from the Linux kernel, KVM should give you performance that is equal to or better than that of VirtualBox.
After moving to FreeBSD thanks to systemd I've noticed how much easier things like upgrades are. With a few command lines I can upgrade my base system and my programs thanks to ports are always up to date. No need to upgrade a whole linux distro version to get the latest updates to programs.
- many apps may fail to implement mouse selection -> paste on middle click. Worse, we may get lectured by "designers" about how we do not actually want to do that?
That isn't something apps need to be written for, Wayland already has that functionality. The problem is that the way it's implemented in Wayland is different from the way that it's implemented in X.Org. So while middle click paste and copy on selection work for native Wayland apps, and apps that run on a shim, they do not work between the shim and a native app. As far as I've been able to gather from internet searching anyway.
So if a program is running as a native Wayland app everything should work as it used to (barring an attack by some young hip UX expert who feels like the mouse and keyboard are obsolete and we should be copying and pasting by willing it across with our mind.
(I tried doing a Debian install, but it's still compiling...)
You may be thinking of Gentoo.
Not being funny, but if incremental upgrades are supported, or were at one point, is there not a blindingly obvious fact that you could get an old one, and update it twice in a row transparently, and not tell the user?
I understand that a properly non-incremental upgrade might be slightly faster but also it's likely to cock a lot of things up. I just don't get why - if there's an upgrade path from 1.0 to 2.0, and from 2.0 to 3.0, and from 3.0 to 3.1, you can't just install 3.1 over the top of 1.0. You don't need to contain the bulk of the 2.0, 3.0 etc. updates because most of them are again overwritten by later versions. Just conversion scripts, upgrade scripts, and then the latest package, surely? It's a nonsense that you can't upgrade like this in one fell swoop, even if it means the distro goes "Hold on, I have to download a handful of intermediary updates to do that which are on this 3.1 disk... is that okay?"
The software I use in work just has thousands of versions. When you upgrade, it goes through a series of updates, of databases, configurations, even data (e.g. splitting out some fields into more than one field so you can add new features, etc). It doesn't matter what version you start with, or are aiming towards, the same process occurs, in the same linear order, and gets you to the same point.
Old data is migrated where necessary, fixes and tweaks (e.g. to database schema) happen for each update as necessary, and rarely do you have to do anything special. If your v83 upgrades to v84 by changing the config files to the new format for v84, and the later update v95 does it again for the new version of that software or to fix a bug, then whether you do them years apart, or within seconds of each other does it really matter?
As such, all you're really doing is bringing forward small scripts that do such (rare) actions, and then extracting a tarball of binaries over the top, after checking dependencies. Is it really that miraculous that you can do this? Jumping two versions? Run the scripts that modify config / db schema for each intermediate version in serial, then unpack the latest binaries for the new version over the top of whatever was there - whatever version - as normal.
I honestly don't get why there's not just one huge version number for distros. Every time a package is changed, increment the version for the entire distro. Mark certain versions as bad as necessary (so upgrades to those versions are ignored). Then keep a list of tags of versions, and their regarded stability, as you expect.
When it comes time to upgrade, oh look, you have version 5434 of the distro and the latest is 6000. So we run updates 5435 - 6000, and those updates skip if you don't have that particular software that changed installed or if there was a bad update published. Would you really know or care?
At least then you can just refer to ONE version number. Bug in MySQL? Oh, yes, we fixed that in 5869. Upgrade to at least that, or you're on your own.
When we are told to upgrade a distro by multiple versions, we all do exactly this. We install linearly, by increments, until we get to a supported configuration. Why that process isn't automatic and supported in all distros, I can't fathom. Even Slackware's done that to me in the past and I've had to snapshot, perform each version upgrade one-by-one and then fix up exactly what I would have needed to anyway.
The summary seems to get this a bit garbled, so here's an executive summary:
* This is simply about the support status of upgrades across more than one Fedora release
* It's not about making any major technical / design changes to any software
* It's certainly not about removing anything that is currently possible
* Right now, upgrades across more than one release are technically possible, but until recently were not really tested and not necessarily considered 'supported'
* We're now testing upgrades across two releases, and they tend to work pretty well, so we're considering making them more 'supported'
that's all this is.
You can run Wayland on Fedora already, and quite a few folks are (I have my F23 laptop running GNOME on Wayland full time).