Slashdot Mirror
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.
Is systemd an incremental upgrade?
M$ even lets you upgrade 98 to XP. These are very different OS.
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 always do fresh installs since I have a /home on a separate partition. A fresh install of my Linux Mint takes like 5-10 minutes, and then I queue up stuff from the software store and go watch tv for a few minutes. It is so fast to do any fresh install, maintain your settings, and add extra software. Only Windows requires massive amounts of backup and preparations which is why I use Acronis on that OS to restore a perfect install after a miserable day setting everything up to begin with.
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.
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.)
Don't give Lennart any ideas. We'll be seeing packagemanerd fucking up systems in whole new ways.
Wayland, GNU HURD, Year of the Linux Desktop – they're always one year away.
When you do an initial install, install that to a physical drive, install your data, settings and whatever else on a separate physical drive. When you need to upgrade the OS, install clean the new version to that OS physical drive, and then again repoint the settings, tada, takes a lot less time.
I'm only saying this as a matter of fact that the entire "download binary packages" aspect of upgrading Linux gets extremely broken as time progresses. There is something terribly wrong when I can upgrade FreeBSD 4.x to 11, and skip every second major OS update without breaking it, yet I can't even skip a minor kernel update on Linux without all hell breaking loose in the updating of packages.
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.
Linuxd
Lenux distros that each utilize systemd/kerneld.
I know, I shouldn't reply to trolls, but, there is nothing wrong with X11. GNOME might be broken yes, but X11 is a perfectly fine display protocol. It's a shame that X.org is the only surviving X server (I'm still using XSGI here! It's awesome!)
I'm starting to think GNU is the problem with "GNU/Linux" these days.
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.
What kind of boxes are you running? My boxes are a few years old and nothing special hardware-wise, and to me dnf runs very smoothly.
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.
Complexity breeds more complexity. And when that complexity is unnecessary it's quite silly.
- 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.
Seriously:The only real feature DNF added was "recommended" components. That could have been activated for yum with far, far less pain, because dnf was a buggy nightmare for several years. In the meantime, thousands of man-hours have been wasted as the whole Fedora build system was repeatedly broken. And they only figured out that dnf and koji were bringing oll the "recommnded" components, not just the "requieed" components, and in some cases tripling the size of the build environments and activating detectable local versons of libraries that are not in the .spec compilation configuration files.
No, what has helped stabilize Fedora is the increasing rigor of accepted build configuraitons, which is a real improvement, and systemd scaring away script kiddie who used to write new daemons which they don't really need. Not that systemd is better: the new binary logging is still painful, and the difficulty of starting a daemon in a debugger is still nasty. But it scared off a lot of people who were writing unstable daemons.
Brother, I gave up on Gnome a long, long time ago. It's a resource pig, and violates every one of Eric Raymond's guidelines on open source interfaces ( http://www.catb.org/esr/writings/cups-horror.html )
I switched to "vtwm" back in.... 2000 ? It's been rock stable since its last update in 2005, and there are RPM building tools for Fedora users at https://github.com/nkadel/vtwm-5.5.x-srpm .
Not the OP either, but the 6 or so different toolkits *all* trying to run dnf all the time to manage updates are insane. I try to rip out PackageKit by the roots, but there are too many dependencies on it. A nightly cron job is *plenty* for scheduling system updates, or for reporting needed ones, and the PackageKit tools have tried to "optimize" dnf to death.
dnf has all the premature optimization flaws of yum (huge compressed databases that require complete update if a single RPM changes) and non-incremental updates of those databases require complete reloading.) But the "Recommends" installations were very destabilizing, for a long time, because they brought a lot of unnecessary and destabilizing lincompatible crap in with different based packages.
The problems are not being able to track processes or control resource usage. Those are provided by cgoups (a kernel feature), which break compatibility with other Unixes. The second problem is that init scripts collectively are a terrible codebase in dire need of an abstraction layer and a core library. OpenRC has also replaced big chunks of SysV init with C libraries. The next problem was that starting processes with the interpreter was slow, in-order, and had no concept of dependency resolution, and again, both OpenRC and Systemd had the same idea here. The main difference between the two projects is that with OpenRC cgroups are optional, and with Systemd since the whole point of the project was to take advantage of cgroups, they discarded any idea of Unix compatibility and took a more green-field approach. On the whole, they have succeeded admirably,
Systemd fixes no problems that you know about, because you are a lackwitted reproductive accident.
VMs that meet the minimum specs for Fedora. They work just fine in production and the services provided with them work just fine. Until DNF chews on all the resources at the same time. Can't cache disk reads when it wants all the memory, which would be fine if it didn't go heavy on the I/O at the same time and the high CPU just exacerbates the problem because scheduling becomes a nightmare due to all the switches..
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.
I recall celebrating The Year of the Linux Desktop in 2005.
Next you'll be telling us you also recall getting laid in 2005. This is /., so we know that didn't happen.
Maybe you were asleep and missed it.
Sleep? No, sleep is for the weak.
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).