Linked by Thom Holwerda on Tue 30th Oct 2018 22:46 UTC
Fedora Core

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.

Order by: Score:
Wow
by WorknMan on Tue 30th Oct 2018 23:44 UTC
WorknMan
Member since:
2005-11-13

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.

Reply Score: 3

RE: Wow
by Alfman on Wed 31st Oct 2018 00:33 UTC in reply to "Wow"
Alfman Member since:
2011-01-28

WorknMan,

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.

I hope this feature eventually makes it's way to other distros too!

Reply Score: 4

RE[2]: Wow
by b00gie on Wed 31st Oct 2018 04:55 UTC in reply to "RE: Wow"
b00gie Member since:
2006-06-09

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".

Reply Score: 2

RE[3]: Wow
by Alfman on Wed 31st Oct 2018 13:48 UTC in reply to "RE[2]: Wow"
Alfman Member since:
2011-01-28

b00gie,

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.


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.


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.

Reply Score: 3

RE[4]: Wow
by b00gie on Wed 31st Oct 2018 14:26 UTC in reply to "RE[3]: Wow"
b00gie Member since:
2006-06-09


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.


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.

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.

Reply Score: 2

RE[5]: Wow
by Alfman on Wed 31st Oct 2018 14:54 UTC in reply to "RE[4]: Wow"
Alfman Member since:
2011-01-28

b00gie,

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.

Edited 2018-10-31 14:58 UTC

Reply Score: 3

RE[6]: Wow
by b00gie on Wed 31st Oct 2018 17:27 UTC in reply to "RE[5]: Wow"
b00gie Member since:
2006-06-09


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.
Let's all co-exist with all the different colors and diversity.

Reply Score: 1

RE[7]: Wow
by Alfman on Wed 31st Oct 2018 18:08 UTC in reply to "RE[6]: Wow"
Alfman Member since:
2011-01-28

b00gie,

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.


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.


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 ;)

Edited 2018-10-31 18:11 UTC

Reply Score: 3

RE[5]: Wow
by acobar on Wed 31st Oct 2018 16:26 UTC in reply to "RE[4]: Wow"
acobar Member since:
2005-11-15

Oh i have seen that multiple times when i had to deal with the nightmare called .rpm.

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).

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.

Reply Score: 4

RE[2]: Wow
by nicubunu on Wed 31st Oct 2018 07:30 UTC in reply to "RE: Wow"
nicubunu Member since:
2014-01-08

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.

Reply Score: 3

RE[2]: Wow
by ahferroin7 on Thu 1st Nov 2018 12:16 UTC in reply to "RE: Wow"
ahferroin7 Member since:
2015-10-30

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.

Reply Score: 3

RE[2]: Wow
by juzzlin on Thu 1st Nov 2018 19:22 UTC in reply to "RE: Wow"
juzzlin Member since:
2011-05-06

Snaps work perfectly for me.

Reply Score: 2

RE: Wow
by Lunitik on Wed 31st Oct 2018 12:35 UTC in reply to "Wow"
Lunitik Member since:
2005-08-07

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

Reply Score: 3

RE[2]: Wow
by tidux on Thu 1st Nov 2018 18:06 UTC in reply to "RE: Wow"
tidux Member since:
2011-08-13

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.

Reply Score: 0

RE: Wow
by yoshi314@gmail.com on Wed 31st Oct 2018 15:14 UTC in reply to "Wow"
yoshi314@gmail.com Member since:
2009-12-14

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.

Reply Score: 3

End of an era
by nicubunu on Wed 31st Oct 2018 07:33 UTC
nicubunu
Member since:
2014-01-08

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.

Reply Score: 3

RE: End of an era
by Lunitik on Wed 31st Oct 2018 12:30 UTC in reply to "End of an era"
Lunitik Member since:
2005-08-07

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

Reply Score: 4

RE[2]: End of an era
by Adurbe on Wed 31st Oct 2018 14:15 UTC in reply to "RE: End of an era"
Adurbe Member since:
2005-07-06

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

Reply Score: 3

RE[3]: End of an era
by Lunitik on Wed 31st Oct 2018 15:18 UTC in reply to "RE[2]: End of an era"
Lunitik Member since:
2005-08-07

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.

Reply Score: 3

RE[2]: End of an era
by nicubunu on Wed 31st Oct 2018 18:19 UTC in reply to "RE: End of an era"
nicubunu Member since:
2014-01-08

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


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.

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.

Reply Score: 3

Isn't that what FlatPak is for?
by Moochman on Wed 31st Oct 2018 13:43 UTC
Moochman
Member since:
2005-07-06

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.

Reply Score: 4

RE: Isn't that what FlatPak is for?
by Lunitik on Wed 31st Oct 2018 15:22 UTC in reply to "Isn't that what FlatPak is for?"
Lunitik Member since:
2005-08-07

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

Reply Score: 3

Moochman Member since:
2005-07-06

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.)

Reply Score: 3

who really gives a damn?!?
by Yoko_T on Thu 1st Nov 2018 06:13 UTC
Yoko_T
Member since:
2011-08-18

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.

Reply Score: 1

RE: who really gives a damn?!?
by C5523 on Thu 1st Nov 2018 11:45 UTC in reply to "who really gives a damn?!?"
C5523 Member since:
2013-04-08

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

Reply Score: 0

RE[2]: who really gives a damn?!?
by Yoko_T on Thu 1st Nov 2018 18:38 UTC in reply to "RE: who really gives a damn?!?"
Yoko_T Member since:
2011-08-18

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?

Reply Score: 0