CentOS Starts An Integration SIG To Help Products/Services Built On RHEL / CentOS Stream

[phoronix]

Phoronix: CentOS Starts An Integration SIG To Help Products/Services Built On RHEL / CentOS Stream

The CentOS board has approved the creation of a CentOS Integration Special Interest Group (SIG) to assist those building products and services atop Red Hat Enterprise Linux (RHEL) or in particular its upstream, CentOS Stream...

https://www.phoronix.com/news/CentOS-Integration-SIG

[skeevy420]

The Xzibit SIG

Yo dawg, we heard you used CentOS to test software so now you can test what tests what you're testing so you're not surprised when you go to test what you planned to test.

Seriously though, that actually does sound useful if one was doing development on a rolling release platform. It's better than doing "sudo pacman -Syu" and finding out WTF a GTK3 is the hard way.

oiaohm That quoted block in the article is what you were talking about yesterday. Take the first sentence:

"Integration is verifying that products and services built on top of RHEL or CentOS Stream will continue to work on CentOS Stream and the next release of RHEL and will not break on package updates."

"Integration is verifying that products and services built on top of RHEL or CentOS Stream will continue to work on CentOS Stream, the next release of RHEL, and will not break upon package updates."

People have such a hard time with comma usage.

[oiaohm]

The Xzibit SIG

Yo dawg, we heard you used CentOS to test software so now you can test what tests what you're testing so you're not surprised when you go to test what you planned to test.

Seriously though, that actually does sound useful if one was doing development on a rolling release platform. It's better than doing "sudo pacman -Syu" and finding out WTF a GTK3 is the hard way.

oiaohm That quoted block in the article is what you were talking about yesterday. Take the first sentence:

"Integration is verifying that products and services built on top of RHEL or CentOS Stream will continue to work on CentOS Stream and the next release of RHEL and will not break on package updates."

"Integration is verifying that products and services built on top of RHEL or CentOS Stream will continue to work on CentOS Stream, the next release of RHEL, and will not break upon package updates."

People have such a hard time with comma usage.

You do have to take will "not break on package updates" with a grain of salt thinking that from time to time RHEL itself sometimes breaks third party applications with package updates.

If you run the normal level of required RHEL quality control not to have RHEL break your important operations with CentOS Stream the result should be CentOS Stream should be no worse.

Now if you are winging not doing the testing to protect your important operations things might be a little worse because CentOS Stream users are getting the updates first so will be the first to notice opps this update breaks something.

With how complex software is and the limited resources to test everything means almost anyone with software who makes a claim "will not break on updates" is telling a huge lie the question is working out how to get back from this lie to the truth.

The rare cases that they are telling the truth you are talking very not complex hardware system that you like find eChronos RTOS inside. eChronos RTOS is one of the likely military drone flight control OS that you find delivering a very unfriendly gift dependable but with a slight side of evil. Yes parties doing this are willing to spend the true arm and leg+ in cost to make sure the stuff works right.

So Redhat telling the truth on this stuff is that "will not break on updates" is basically impossible all the real meaning is that Redhat does a decent amount of due care to attempt to make sure it does not break on updates but they have to draw a budget line to stay profitable and not in fact test everything so faults that are rare corner cases will be missed and the bugs taken out against RHEL over time show this. Yes this is not a new grain of salt you have to apply when reading Redhat Marketing.

Many companies make these over claims to sell their products.

[skeevy420]

I'm not going to make others suffer by quoting all of that.

I don't think anything is immune from update breakage which is why I thought that this was a decent idea. That's especially true with non-fixed hardware environments like consumer computing systems. Even fixed hardware like the drone can still mess things up. How many times have you updated your router only to have to update your router to fix what the first update broke? (maybe not you specifically...)

The alternative to something like this is running the same workload you have with your distribution's testing repositories where you may or may not be able to provide feedback and resolve any issues that crop up. RHEL creating a SIG that's designed to address feedback is what I see as important here. Shit'll eventually break (and Birdie will tell us all about it), that's a given, but when it does hit the fan, having a collaborative platform to fix it might be better than filing bug reports at random project pages. That could be really hold true if anecdotes like 15 year old Wine bugs that haven't been read is the norm.

[oiaohm]

Even fixed hardware like the drone can still mess things up. How many times have you updated your router only to have to update your router to fix what the first update broke? (maybe not you specifically...)

Flight control software is not ultra complex that the thing that doing the adjustments automatically that the aircraft stays in the air. Not we are going this waypoint to this waypoint this is basically hold item on current course and that is as far as it smarts go. We are talking automated tests running for 6 months though basically any possible combination of input. No civilian business can justify doing this this is weapons grade mil stuff. Yes they even throw in handling that silicon has developed defects.

Mil drones flight systems are segmented. You have section with radio and location planing and then independent part controlling the flight surfaces/moters.

Yes your normal hobby drones normally have everything thrown in a single CPU making them a lot simpler to jam. Yes optical isolation between the radio parts and the flight control parts in the mil drones as well. So you hit the radio part hard the drone stays on last set path.

This is just the highest quality control we can do. Do note even the military cannot afford to-do the highest level of quality for all parts of the control system of a drone. When USA military budgets for making stuff does not have enough budget to justify todo more than the flight control part in a drone is kind of a warning of problem.

Yes the cost calculation to audit what in RHEL repertoires to the same level as those mil drone flight control systems is at least 1000 times the number of atoms in the Universe in USD. Do note I said atleast a NSA guy decided to start calculating it and stopped when he got to that value because at that point there was no point calculating any more because it already hit impossible level. This level of operational auditing is something we can only afford to-do for limited special cases. So not your house hold devices or general business devices.

[tracker1]

IBM/RedHat is right up there with Oracle in terms of companies best avoided.

[Developer12]

This new SIG's pitch reminds me strongly of some of the SFC's stories about redhat's attempted enforcement.

In the first violation, a large Fortune 500 company (which we'll call Company A), who both used RHEL internally and also built public-facing Linux-based products, decided to create a consumer-facing product (which we'll call Product P) based primarily on CentOS Linux, but P included a few packages built from RHEL sources. Company A did not seek nor ask for support or update services for this separate Product P. Red Hat later became aware that Product P contained some part of RHEL, and Red Hat demanded royalty payments for Product P. Red Hat threatened to revoke the support and update services on Company A's internal RHEL servers if such royalties were not paid.

Since Company A was powerful and had good lawyers and savvy business development staff, they did not acquiesce. Company A ultimately continued (to our knowledge) on as a RHEL customer for their internal servers and continued selling Product P without royalty payments. Nevertheless, a demand for royalties for distribution is clearly a violation as that demand creates a “further restriction” on the permissions granted by GPL.
https://sfconservancy.org/blog/2023/...-gpl-analysis/

Redhat can't prevent people from incorporating bits of RHEL source code into products, at least not without violating various licencing terms. However, this may instead be them taking a page from apple's handling of repair and creating an "official" process.

It could work something like this:
They provide a service to help incorporate RHEL into products in ways they're willing to "support" and as part of this service's terms they get to impose restrictions on the products themselves. They can then claim that those terms don't conflict with the GPL, MPL, etc in the same way that their termination of service for sharing RHEL source code supposedly doesn't. They can also now use the existence of an "official" process as a means of marketing against and intimidating anyone who decides to repackage RHEL code into a product outside of this service (including termination of their regular RHEL seat licences).

Honestly, wouldn't be surprised if the initial SFC article was the inspiration for this scummy move.

[Guest]

this is yet another redhat move against "freeloaders". what they are doing here is they are saying "use centos stream, your software solutions will not break". so it's a carrot since stick backfired badly.