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.
You know where to get it.
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.
WorknMan,
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.
I hope this feature eventually makes it’s way to other distros too!
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”.
b00gie,
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.
b00gie,
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.
Edited 2018-10-31 14:58 UTC
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.
Let’s all co-exist with all the different colors and diversity.
b00gie,
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
Edited 2018-10-31 18:11 UTC
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.
Snaps work perfectly for me.
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
Pipewire has two immensely useful properties.
1. It allows secure audio and video access from Docker, Flatpak, and other containers.
2. It unifies the PulseAudio and JACK use cases so pros get ease of configuration and normies get better latency.
Once those propagate out to the wider world (probably with pulseaudio sink and ALSA device shims for the audio side), the Linux world looks a lot nicer for people like DAW developers.
you can install latest and greatest package for your LTS install, if you need it.
it’s a pretty neat thing for people stuck on older release due to various constraints.
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.
Edited 2018-10-31 12:42 UTC
Allowing (and supporting) CentOS has effectivly allowed Oracle and Amazon to follow suit and get a linux distro “for free”. With Redhat shouldering the costs of deveopment and management.
I can see CentOS being re-absorbed into RedHat, as an attempt to get these two to either licence or go it alone. I fully expect it to remain the free (beer) option.
Fedora, I think will change fundamentally. IBM can only capitalise it if it becomes “Redhat Workstation” with an Ubuntu style LTS version.
In short, I think IBM will revert Rehat distro setup to the early 2000s
Edited 2018-10-31 14:16 UTC
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.
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.
FlatPak is for applications.
Kubernetes handles server software, standardizing around Helm as best I can tell.
Snap is a one-size-fits-no-one-in-particular solution. It’s too bloated for applications and not powerful enough for servers.
With containers, the solutions are necessarily different when dealing with many across various machines compared to a single workstation.
Edited 2018-10-31 15:27 UTC
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.)
Since fedora quit supporting perfectly good older hardware why waste time bothering with this shitty software with it’s crappy install processes, horrid GUI design and unreliable support.
Fedora has also become totally useless for most purposes if you don’t have a high-speed internet connection.
Nice try. Give me another distro that has SELinux implemented like Fedora does, quality packaging process and feedback like Bodhi, excelent auditing and installing packages like dnf and so forth
What you’re not denying that:
fedora doesn’t support perfectly good older hardware?
It’s crappy(SHITTY)install processes especially when you compare it to what Fedora 14 and below had?
It’s horrid GUI design and unreliable support?
That Fedora has become totally useless for most purposes if you don’t have a high-speed internet connection?