Announcing the release of Fedora 29

This release is particularly exciting because it’s the first to include the Fedora Modularity feature across all our different variants. Modularity lets us ship different versions of packages on the same Fedora base. This means you no longer need to make your whole OS upgrade decisions based on individual package versions. For example, you can choose Node.js version 8 or version 10, on either Fedora 28 or Fedora 29. Or you can choose between a version of Kubernetes which matches OpenShift Origin, and a module stream which follows the upstream.

Other big changes include GNOME 3.30 on the desktop, ZRAM for our ARM images, and a Vagrant image for Fedora Scientific.

So the groundbreaking new feature is you can choose which version of apps you want to install? I’m surprised they didn’t have that baked in 20 years ago.

It sounds a little insignificant, but you’d be surprised how many times I’ve needed a different version than what was included in a distro’s repositories. For most people who’ve experienced dependency problems in linux, this is probably the root of the problem.

Other distros must have the freedom to do whatever they want, for example security minded downstream developers who don’t wish to get their hands dirty with packaged containers that include unmaintained parts of the base system.

In some extend this is already happening on distros that have some serious package managers, for example in Gentoo there is support for multiple installations through slots but as soon as any of the dependencies that is required by an older version will go unmaintained and removed from the repository then either the programs that depend on it will have to be patched or must go too.

Choices is good, forcing it down to one’s throat is not good simply because “shinny new toy”.

Other distros must have the freedom to do whatever they want, for example security minded downstream developers who don’t wish to get their hands dirty with packaged containers that include unmaintained parts of the base system. [/q]

Well, let me tell you exactly what happens in this case on real production systems when you cannot get the version you need from the repo, you end up having to install packages from source manually, however because they’re not in sync with your distro, it will often requires installing more libraries from sources manually in a cascading manor. You can end up with a frankenstein installation where you are stepping all over the package manager’s responsibilities and visa versa. In short, you’ve opened yourself up to dependency hell and you can no longer rely on package managers to keep the system stable or up to date.

You should count yourself lucky if you’ve never needed to do this because seriously it’s not pleasant.

[q]Choices is good, forcing it down to one’s throat is not good simply because “shinny new toy”.

I’m sorry, but this makes no sense at all. “Forcing something down people’s throats” is the anathema of choice.

Well, let me tell you exactly what happens in this case on real production systems when you cannot get the version you need from the repo, you end up having to install packages from source manually, however because they’re not in sync with your distro, it will often requires installing more libraries from sources manually in a cascading manor. You can end up with a frankenstein installation where you are stepping all over the package manager’s responsibilities and visa versa. In short, you’ve opened yourself up to dependency hell and you can no longer rely on package managers to keep the system stable or up to date.

You should count yourself lucky if you’ve never needed to do this because seriously it’s not pleasant. [/q]

Oh i have seen that multiple times when i had to deal with the nightmare called .rpm. Thankfully done with that many years ago.

The fact remains, those dependencies that you have to install are mostly always old versions with bugs and even security holes. Just by hiding them in a container will give the user a _very_ false sense of security.

The proper solution is project developers not be lazy and update their supported products with newer libraries and also downstream distro developers to be very strict about projects that bundle libraries (the old method of doing what fedora trying now) and ofcourse not to permit mindless downgrades and this dependency hell.

[q]I’m sorry, but this makes no sense at all. “Forcing something down people’s throats” is the anathema of choice.

The statement makes total sense if someone considers redhat’s recent ventures to “standarize” their own toys… and now we pick up the pieces.

Oh i have seen that multiple times when i had to deal with the nightmare called .rpm. Thankfully done with that many years ago.

The fact remains, those dependencies that you have to install are mostly always old versions with bugs and even security holes. Just by hiding them in a container will give the user a _very_ false sense of security.

The proper solution is project developers not be lazy and update their supported products with newer libraries and also downstream distro developers to be very strict about projects that bundle libraries (the old method of doing what fedora trying now) and ofcourse not to permit mindless downgrades and this dependency hell.

You speak of the ideal world, but we don’t all get the benefit of working there.

I’ll give you an example. PHP is notorious for breaking compatibility between versions (this is a topic unto itself…). Well, I had a client who had a hard dependency on an older version of PHP, which became a major issue when I was updating servers. I had a dilemma, install an older LTS version of ubuntu than I wanted, or install the latest and fix the website incompatibilities.

At the time I opted to do the server update and also update the client’s monstrous website, but that was a mistake in hindsight. I underestimated the scope of the PHP incompatibilities, the work and therefor costs were far greater than I had anticipated.

PHP, when installed manually for it’s part has no issue running older versions on the system, but just like you, I was convinced that keeping the system managed by the distro was the only “right” way. But when I confined myself to that methodology it created a royal mess and going against the grain for that part of my life was just stress and friction with clients that I didn’t need. I was wrong, and so are you, there are times when you have to break with the repos.

And while you may not sympathize with those of us supporting older code, I do want to point out that I’ve had the opposite problem too where I needed a newer version than the repos made available. It’s the exact same problem! We must recognize that our unique requirements don’t always fit nicely into the one size fits all approach. So if containerization helps us handle differences more gracefully, then it’s a good thing to have.

You speak of the ideal world, but we don’t all get the benefit of working there.

I’ll give you an example. PHP is notorious for breaking compatibility between versions (this is a topic unto itself…). Well, I had a client who had a hard dependency on an older version of PHP, which became a major issue when I was updating servers. I had a dilemma, install an older LTS version of ubuntu than I wanted, or install the latest and fix the website incompatibilities.

At the time I opted to do the server update and also update the client’s monstrous website, but that was a mistake in hindsight. I underestimated the scope of the PHP incompatibilities, the work and therefor costs were far greater than I had anticipated.

PHP, when installed manually for it’s part has no issue running older versions on the system, but just like you, I was convinced that keeping the system managed by the distro was the only “right” way. But when I confined myself to that methodology it created a royal mess and going against the grain for that part of my life was just stress and friction with clients that I didn’t need. I was wrong, and so are you, there are times when you have to break with the repos.

And while you may not sympathize with those of us supporting older code, I do want to point out that I’ve had the opposite problem too where I needed a newer version than the repos made available. It’s the exact same problem! We must recognize that our unique requirements don’t always fit nicely into the one size fits all approach. So if containerization helps us handle differences more gracefully, then it’s a good thing to have.

I’m sorry but i don’t buy it.

Right now the oldest supported php version is 5.6, that is 4 years old and soon they will stop supporting it. On my modern Gentoo installation php-5.6 with default flags requires no downgrades. That might sound irrelevant for some user of another distro, the point is that at least for php if it’s pulling the hell of dependencies then distro developer possibly not trying hard enough.

But let’s assume that php or some other project indeed cannot be built on a modern base system then if we are talking about a production machine 1st) someone did a really bad choice with the operating system based on his client’s needs, 2nd) as a solution i would incorporate the grandad of all containers: chroot. If you wish to be a bit more fancy i could go with lxd too. The point is that i would make SURE that the base system is under my total control, staying up to date and secure ESPECIALLY with projects like php and its security track, especially when we talking about production system. Ofcourse that requires some extra work and automation but after all that’s one’s administrator’s job.

Anyway, i will leave it here. I’m sure some people worked hard to bake this Fedora release.

Right now the oldest supported php version is 5.6, that is 4 years old and soon they will stop supporting it. On my modern Gentoo installation php-5.6 with default flags requires no downgrades. That might sound irrelevant for some user of another distro, the point is that at least for php if it’s pulling the hell of dependencies then distro developer possibly not trying hard enough. [/q]

I’m not sure what we disagree on? You quoted me saying the same thing “PHP, when installed manually for it’s part has no issue running older versions on the system”

With regards to Gentoo, that could change your perspective because building from source is normal there. But that’s not the way that administrators of mainstream linux distros work, we use binary repos. We could debate the merits of both, but my gripe was more with the packages management of mainstream binary distros.

But let’s assume that php or some other project indeed cannot be built on a modern base system then if we are talking about a production machine 1st) someone did a really bad choice with the operating system based on his client’s needs, 2nd) as a solution i would incorporate the grandad of all containers: chroot. If you wish to be a bit more fancy i could go with lxd too.

It’s clear you got the impression that PHP won’t build, but it builds fine.

[q]Anyway, i will leave it here. I’m sure some people worked hard to bake this Fedora release.

Let’s all co-exist with all the different colors and diversity.

Yeah, if multi-version features make their way into cent-os, that might be compelling enough for me to consider it over debian/ubuntu lines. It’s a feature that would have been useful for me many times.

I’ve also wanted to give BSDs a go for production systems, but my workflow and expertise is already so linux-centric that I don’t know that it would be worthwhile. I have a linux distro and everything.

It’s a question of trying something new versus sticking with what you know

Oh i have seen that multiple times when i had to deal with the nightmare called .rpm. [/q] I fail to see how this is only tied to rpm, I work with both, .deb and .rpm and when you need to install some old or new library you end up needing to correct where they are going to be put (i.e., set where include files, libraries, data and executable will end up and from where it will get its dependencies).

[q]The proper solution is project developers not be lazy and update their supported products with newer libraries ..

I think you never had to deal with numeric libraries. Yes, some of them have a very stable interface but don’t count on it as granted. And why should I change many lines of my code when I’m not going to use the new parameters and features? My time is already too short and I have more urgent things to do with it.

The big question is, there will be enough maintainers for all those different app versions? You can be sure there will be active maintenance of those for which Red Hat, erm… IBM, sells support, the others may fall back on the community. Which has to prove itself on this task.

For desktop apps, one can already use different versions maintained by community from Copr.

The concept already exists on some other distros, at least for some packages.

A rather good example is ‘slots’ in Portage (Gentoo’s package management infrastructure). As long as the versions of a package have different slots, they can be installed concurrently. This mostly gets used to support libraries and scripting languages which allow multiple versions inherently, but some other packages do it too.

The reality of modularity, from my understanding, is that it is the first step along the way to a fully containerized system.

So, right now the benefits and differences aren’t that great, but that’s where everything is really headed right now… the way Red Hat is doing containers is that every process is a container, as apposed to everything being under the docker process. They go on saying containers just are linux exactly for this reason…

This is also the reason for new things like PipeWire, allowing audio to work with containers as well. Lots of stuff are fundamentally changing so it’s exciting… for now, you can have 2 instances of an app at the same time, woopdy doo

Despite assurances threw away by “community leaders”, this is probably the last version of Fedora as we knew it. Changes, for the better or for the worse, are bound to happen now with a different corporate ownership.

Why would it even make sense to get rid of Fedora or CentOS? They provide on-ramps as well as giving QA for free…

Of course, Fedora is in the process of changing, within the next couple releases they’re moving to containers wholesale so it will look nothing like what we’re used to today within a year or so…

There are reasons Red Hat did both though, and it makes just as much sense for IBM as it did for them.

The only thing I’m particularly worried about is how many of the leading developers will actually stick around. People work at Red Hat exactly because it aligned with their ideals, will they be happy to continue towards their ideals as part of a largely proprietary company? Will they take up the challenge of trying to change the culture inside IBM to move even more to those ideals? Where will they go if they leave the company? There really aren’t any good options so we’re at the risk of losing a lot of important open source developers. Both SUSE and Ubuntu depend on these guys a lot, but I think SUSE is making choices a lot of Red Hat guys don’t like and Ubuntu isn’t even really open source because of all the CLA’s on internal projects.

I think that Oracle and Amazon providing a common developer platform is beneficial, but I can see them advertising the fact that they depend on IBM completely and thus you should just go with the company that knows what they’re doing, etc…

I think that if CentOS is re-branded it’ll be under the Fedora naming, as you suggest “Fedora LTS”… again, though, Fedora is a QA platform for new technology. It would be detrimental to the overall quality of Red Hat products to take this away. CentOS is already the LTS free distro though, so I don’t know that it makes sense to make the situation more confusing.

I think your statements overall underestimate the enterprise nature of Red Hat pre-merger… they do things this way because it makes sense and IBM would be stupid to change anything.

Essentially, this deal is about bolstering Red Hat as the base for IBM’s cloud offerings. I also think we’ll see IBM moving to the various toolings around OpenShift rather than their current tools because working with partners is just beneficial. Everyone is saying IBM outsources development too much, but that’s sort of the point of open source, everyone is outsourcing to each other. IBM just paid 34 billion to have a bigger say in the direction of the community.

This is not chump change, if you piss off the developers at Red Hat you just wasted every penny of it. I think the thing here is that trillion dollar market, IBM wants a big chunk of that and Red Hat feels like it can get there with IBM’s resources.

Open source just makes sense with IBM’s values, and without them Linux would still be where the BSD’s are… if it could even exist at all given the SCO nonsense (which actually disputed BSD code mostly, again) so they’ve really been the communities biggest allies for years.

Why would it even make sense to get rid of Fedora or CentOS? They provide on-ramps as well as giving QA for free… [/q]

If you were around back when RHL was split in RHEL and Fedora, you may remember how Red Hat’s own marketing team was FUD-ing Fedora and trying to drive people to RHEL. It took a a few years to really embrace Fedora. With CentOS it was much worse, with legal threats. And that was coming from a company with a strong FOSS culture.

Of course, Fedora is in the process of changing, within the next couple releases they’re moving to containers wholesale so it will look nothing like what we’re used to today within a year or so…

I don’t think that’s the plan for the whole Fedora, but only for certain spins (I am not very up to date, I retired from contributing some 5 years ago). Still, if that’s the case, one more reason to switch away.

[q]TThe only thing I’m particularly worried about is how many of the leading developers will actually stick around. People work at Red Hat exactly because it aligned with their ideals, will they be happy to continue towards their ideals as part of a largely proprietary company? Will they take up the challenge of trying to change the culture inside IBM to move even more to those ideals? Where will they go if they leave the company? There really aren’t any good options so we’re at the risk of losing a lot of important open source developers. Both SUSE and Ubuntu depend on these guys a lot, but I think SUSE is making choices a lot of Red Hat guys don’t like and Ubuntu isn’t even really open source because of all the CLA’s on internal projects.

I am aware of quite a few of former Red Hat developers who moved away and work now at companies like Intel, Facebook, SUSE and such. And I am also aware of quite a few people working at Red Hat simply because is a paying job.

I thought this whole idea of being able to install packages independently of the distro version (and the distro itself, for that matter) was supposed to be the reason for FlatPak’s existence. Unfortunately while FlatPak is superior to Snap in some ways, it is was designed exclusively for desktop applications and not console/server packages, necessitating a solution like “Fedora Modules”. IMHO a unified solution like Snap offers would have made more sense. But I’m open to hearing reasoning why the Fedora way is better.

Thanks for the explanation. But I’m not clear on how your description fits together with Fedora Modules. When a module package is installed what is the result? What happens when I then start NodeJS via “node” from the command line? Does it automatically create a Kubernetes container? (Keep in mind I have relatively little experience with Kubernetes but I know how package management on Fedora “normally” works.)