Live data from Hacker News

CentOS Project shifts focus to CentOS Stream

lists.centos.org

581–590 of 642 posts

Re: CentOS Project shifts focus to CentOS Stream

#581
post #473

Earlier quoted context omitted.

I'm wondering, what ties you so strongly to a single OS? Nay, to a single Linux distribution? I have a hard time imagining, and the only scenarios that come to mind are those where things have gone awfully haywire. I'm sure I'm missing something. Enlighten me?

An existing support contract? If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.

> If you run a for-profit operation, and downtime is costly, you (or your VP of eng) want a way to pay for immediate assistance from the OS's maker / distributor, when (not if) things go wrong.

There is a difference between asking "how do I ensure there is one throat to choke when things go wrong?", and "how do I minimize the potential for things to go wrong?"

RHEL is a decent solution if you are trying to answer the former question (or both), but many budget conscious orgs focused on the latter and chose CentOS. Red Hat has now pulled the rug out from under them by trimming eight years off the EOL previously committed to with little notice.

EOL in this case means "no security updates" so even if your org was prepared, technically, to deal with a zero-day for example by rolling out an update in a timely manner without relying on paying a vendor for hand-holding, that option has now been eliminated.

Essentially, you now only get the stability and problem-minimization if you also pay the vendor for support. Otherwise you're stuck with a (relatively) unstable rolling release that will keep your internal teams very busy with a constant stream of minor issues, or potentially trying to roll-your-own updates or backports after the EOL for anything serious.

It's difficult to see this as anything other than a naked, money-grabbing betrayal of users.

Re: CentOS Project shifts focus to CentOS Stream

#582
post #425

Earlier quoted context omitted.

Okay, this is a serious question. For me, not an official RH position. In my time in HPC, nodes were baked with a specific image and then that basically never ever got updates. As I came to that as a sysadmin from other areas, I found that somewhat horrifying, but it seemed pretty universal. Have things changed such that applying patches regularly (like, more often than once a month or so except in emergencies) is a…

Not much, but in our setup the image is not something which can evolve or change over time. This practice has some very practical reasons though. Scientific applications can be very picky about the libraries they use or need, down to minor version since the results they produce are very, very precise. Even if not very accurate, you need to know the inaccuracy. An optimization in a math library can change this and, it…

Right, so: for this case, CentOS Stream will be virtually identical to the CentOS Linux RHEL rebuild.

Re: CentOS Project shifts focus to CentOS Stream

#583
post #109

This is awful. It's proof of the downsides to the IBM acquisition, which I think we all knew was coming. Imagine if you were running a business, and deployed CentOS 8 based on the 10 year lifespan promise. You're totally screwed now, and Red Hat knows it. Why on earth didn't they make this switch starting with CentOS 9???? Let's not sugar coat this. They've betrayed their users. I personally run a CentOS 7 server (as…

An interesting take on the impact of this change:

https://threadreaderapp.com/thread/1336603153341550592.html

Re: CentOS Project shifts focus to CentOS Stream

#584
post #107

Earlier quoted context omitted.

Fedora doesn't like to be put in that particular niche anyway. Yes, Fedora is fast moving and it is what Red Hat uses as the base for major releases, but we're more than "Redhat-unstable" in so many ways. CentOS Stream will be the upstream for RHEL minor branch development. This is actually a huge thing that I think people are missing: previously, once branched from Fedora, RHEL development did not happen in the publ…

>This is huge and awesome good news. So why the negativity at this "huge and awesome good news"?

Change is scary.

Re: CentOS Project shifts focus to CentOS Stream

#585
post #580

I don't think this has anything to do with the IBM acquisition of Red Hat, but this is something that's driven by Red Hat's management itself. They did a similar thing with JBoss application server (the community edition) which was extremely popular and used within the community and even in production. Red Hat offered (and still offers) an enteprise version of it (JBoss EAP). Few years back they slowly started dimini…

There was even a restriction on the community edition to not release bug fix releases (just one was allowed). So if X.0.0 was released then X.0.1, X.0.2 and so on were not allowed. Without these bug fix releases the community versions started seeing X.1.0, X.2.0 and so on which included additional enhancements/features and weren't merely bug fix releases. As a result, the stability that the community edition of the server was known to provide (previously), no longer existed. This all boiled down to one thing - the sales team couldn't convince customers that paying hundreds of thousands of dollars for the enterprise edition was a good thing when the community edition was equally good and well maintained, even if by volunteer community members.

Re: CentOS Project shifts focus to CentOS Stream

#586
post #576

Earlier quoted context omitted.

Of course but, there are sub-committees which melt all the agendas into a single pot and create solutions which makes everyone happy. Also some of these languages have or had BDFLs. Oracle's governance is different from this. C++ is an ISO committee. Python has a lot of working groups, etc. Java is much more centralized when you compare with others.

Nope, IBM, Azul, Amazon, Red-Hat, Alibaba, Twitter, Microsoft also seat at the Java table. Should I also start listing the dark sides of each company that seats at ISO C and ISO C++ table? Python working groups also need money from those corporations, and Python is yet to provide the performance levels of Java, so much for free beer development.

> Nope, IBM, Azul, Amazon, Red-Hat, Alibaba, Twitter, Microsoft also seat at the Java table.

I know Java has stakeholders but, what I'm trying to say is the table is at Oracle's HQ, not somewhere else.

> Should I also start listing the dark sides of each company that seats at ISO C and ISO C++ table?

A primer would be nice, actually.

> Python working groups also need money from those corporations, and Python is yet to provide the performance levels of Java, so much for free beer development.

I've never alleged that Python takes no money from corporations and, Python doesn't aim the performance of Java. Their byte-code even doesn't get optimized. Instead Python prefers native libraries for performance. SciPy, NumPy, PyTorch and others obtain native performance on any system they run and, it's enough for Python.

No need to move the goalposts and compare apples to oranges. Python is never meant to replace Java. Java is not meant to replace system programming languages like C/C++. You may like Java and it might help you to pay the bills but, pushing other languages around just because they don't fill your needs from your point of view is not the correct stance.

Re: CentOS Project shifts focus to CentOS Stream

#587
post #577

Earlier quoted context omitted.

Do we need to have free beer JIT, AOT and GC implementations for every language? If I understood it correctly, a programming language has some foundational design decisions (including its memory and execution model) to attack a particular set of problems?

What we need are top level JIT, AOT and GC implementations, anything else is just going backwards. The people capable of achieving that, naturally have bills to pay.

> What we need are top level JIT, AOT and GC implementations, anything else is just going backwards.

Not always. As I aforementioned in another thread, we also need C/C++, Python, Perl, etc. as is since they fill different roles and attack different problems.

I've written Java, C, C++, Python, Perl, PHP. Had to abuse some of them to fit roles which they're not designed to do. At the end of the day, these languages satisfy different needs and solve different problems in different scenarios. Java wouldn't be able to do all of them. Neither C++, nor Python.

As I said, you may like Java but, it's not the king of every programming language. No programming language is king of everything BTW.

Re: CentOS Project shifts focus to CentOS Stream

#588
post #533

Earlier quoted context omitted.

There are two types of people: People who haven't used Oracle yet, and people who will never use it again. And I'll forever hate them for what they did to Java (and in setting the precedent that APIs can be copyrighted).

What have they done, lets see: - Brought MaximeVM of research and creating GraalVM - In the process of adding value types to Java - In the process of adding support for explicit SIMD in Java - In the process of adding co-routines to Java - Added type inference support - Added pattern matching - Added record types - Integrated J/Rockit support for JIT caches - Made Flight Recorder available in OpenJDK - In the process…

> I hope they squash Android Java, Google had the opportunity to buy Sun after screwing them up.

Do you really think that would be a reasonable thing to happen, and good for technology and the world in general? It seems disproportionately punitive, and the "right" thing to happen only if all you care about is watching things burn.

And you haven't addressed the precedent that's been set that APIs are now copyrightable. Do you like that precedent? Do you ever use anyone else's APIs in your daily development, and do you like how that now opens you to huge potential liability? Is all of this worth it just because Google didn't acquire Sun??

Re: CentOS Project shifts focus to CentOS Stream

#589
post #582

Earlier quoted context omitted.

Not much, but in our setup the image is not something which can evolve or change over time. This practice has some very practical reasons though. Scientific applications can be very picky about the libraries they use or need, down to minor version since the results they produce are very, very precise. Even if not very accurate, you need to know the inaccuracy. An optimization in a math library can change this and, it…

Right, so: for this case, CentOS Stream will be virtually identical to the CentOS Linux RHEL rebuild.

We will certainly try. Need to mirror a repo, freeze it and update our installation infra so it looks to the local repo rather than the national mirror.

All repo settings will look to local repo so we'd have no dependency problem or version creep if we need to install an additional package.

Didn't completely think how to handle the occasional emergency update though.

Also, we need to compile in some packages. Hope they won't break. High performance stuff needs optimized/customized compilations.

I just want to add: Hope that the packages in CentOS stream won't end up too cutting edge for the scientific software community. These communities move slow due to stability requirements. We'll certainly see but it might be another potential problem.

Re: CentOS Project shifts focus to CentOS Stream

#590
post #584

Earlier quoted context omitted.

>This is huge and awesome good news. So why the negativity at this "huge and awesome good news"?

Change is scary.

Come on, be serious. You think people who standardized their infrastructure on CentOS 8 under the assumption that they will have 10 years of stable support, are negative about this because they are afraid of change?

And you know that's not the reason for the negativity, so I don't know why you're being so flippant about this. Nobody has a problem with the idea of 'CentOS 8 Stream'. They have a problem with this being the replacement to CentOS 8 Linux because it doesn't fulfill the same use-cases.

Post reply on HN