Live data from Hacker News

CentOS Project shifts focus to CentOS Stream

lists.centos.org

571–580 of 642 posts

Re: CentOS Project shifts focus to CentOS Stream

#571

It does not matter if nightlies are more stable than they used to be. It does not matter if nightlies never crash. If you work in an industry or corporation that is highly security conscious, i.e. that prizes risk mitigation over using the cutting edge or getting to market first above all else, then you won't be able to use nightlies. Security policy will dictate that you use use a stable versioned release, that the…

> If you work in an industry or corporation that is highly security conscious, i.e. that prizes risk mitigation over using the cutting edge or getting to market first above all else, then you won't be able to use nightlies. > Security policy will dictate that you use use a stable versioned release, that the release be vetted through scripts/STIGs, and that the release be installed by Security+ certified and blessed a…

It is (or was) definitely possible to be security conscious and use an Open Source OS:

* You can use reposync to update a copy of EPEL, PowerTools, etc.

* You can use yum -q deplist PACKAGENAME to list dependencies

* You can copy the necessary RPMs to a DMZ and apply security scans/tests, then take them to your boxes and install them

Also, any corporation or organization like I'm talking about has internal approval/certification of software as usable on their networks. The Army formalized this as the CoN, Certificate of Networthiness.

Re: CentOS Project shifts focus to CentOS Stream

#572
I think people are missing something here... this isn't going to make a typical CentOS deployment less stable than before. The intended result is to make RHEL even more stable than before, but leaving CentOS in the position where RHEL was until now.

Seriously, think about it. Yes, users of CentOS Stream will be essentially be doing beta-testing for RedHat, but it's a type of beta testing that until now didn't even exist; any instability, conflict, or vulnerability that enters into CentOS Stream is one that would have entered into production RHEL systems otherwise. So the net effect is fewer of those for RHEL, but the same number as before for CentOS. CentOS users lose nothing they ever had.

Re: CentOS Project shifts focus to CentOS Stream

#573
post #26

Earlier quoted context omitted.

Official CentOS/RHEL is more like Debian Stable. The new CentOS "Stream" sounds like it will be more like Debian Testing.

Exactly. As stated in https://www.redhat.com/en/blog/centos-stream-building-innova... (linked from the article): "CentOS Stream now sits between the Fedora Project’s operating system innovation and RHEL’s production stability" So if we compare to Debian, this means: Fedora Debian unstable (Sid) CentOS Stream Debian testing (currently Bullseye) RHEL Debian stable (currently Buster)

There is no real equivalent to CentOS Stream in Debian's release model.

Perhaps the closest is "the DAK upload queue for Debian stable", but that tends to contain mostly security updates, and according to other posts in this thread that is the one case where CentOS Stream is not an upstream of RHEL.

CentOS Stream contains feature backports, which generally don't happen in Debian stable, but it's only very specific backports, not every package gets updated like in Debian testing.

I'd put it like:

Fedora rawhide Debian unstable

Fedora Debian testing

CentOS Stream DAK upload queue for Debian stable

RHEL Debian stable

Re: CentOS Project shifts focus to CentOS Stream

#574
post #563

Earlier quoted context omitted.

I don't think that's really true. My understanding from talking to people there is that Java funding was increased for so many years despite losing money because Larry Ellison just thought it was cool tech and they use it a lot. Likewise, GraalVM is so well funded largely because it's cool and Oracle doesn't have many cool R&D projects. It's not clear it's all that commercially driven when you observe that so much of…

Oracle has been in the bed with IBM and Sun regarding Java since version 1.0. The supported versions of Java and Graal are the same price as any other enterprise product. They put the effort, someone has to pay for it. Where are the free beer JIT, AOT and GC implementations for free beer languages that outperform Java?

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?

Re: CentOS Project shifts focus to CentOS Stream

#575
post #255

Earlier quoted context omitted.

Facebook have their own kernel developers. It was a selling point one of their teams used to try to lure me there.

It must be a classic selling point... a French company (pretty big) told me the same thing to lure me (even if my hypothetical job was not directly related to that fact)

"We spend company resources on work that gets released as open-source software" is always preferable to a company never contributing back to OSS.

Re: CentOS Project shifts focus to CentOS Stream

#576
post #567

Earlier quoted context omitted.

It is naïve to think that the employees of the companies aren't driving their employers agenda, regardless how "independent" those governing bodies are.

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.

Re: CentOS Project shifts focus to CentOS Stream

#577
post #563

Earlier quoted context omitted.

Oracle has been in the bed with IBM and Sun regarding Java since version 1.0. The supported versions of Java and Graal are the same price as any other enterprise product. They put the effort, someone has to pay for it. Where are the free beer JIT, AOT and GC implementations for free beer languages that outperform Java?

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.

Re: CentOS Project shifts focus to CentOS Stream

#578
post #570

Earlier quoted context omitted.

That is a great opportunity to switch to Debian, which can be upgraded in place between major versions and, by being completely community driven, does not suffer from this kind of surprises.

If only it had comprehensive SELinux support...

There is AppArmor (enabled by default) which is another Linux Security Module.

I find it easier to configure than SELinux.

Re: CentOS Project shifts focus to CentOS Stream

#579

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?

Software doesn’t run on its own. They rely on bunch of other software that is typically provided by distributions. So unless there’s some magic piece of technology that can take CentOS RPMs and make it work flawlessly on any Linux distro, the entire software industry is suddenly going to have to spend significant amounts of time on repackaging work.

There is alien[1], but I'm not sure if it is flawless, because of slightly different ways of doing things across distros like /etc/default vs /etc/sysconfig for example.

Depending on how good is the source, its usefulness and dependencies, packaging it to Debian is pretty straight forward. The dh_* helpers[2] does the job automatically most of the time. There is also tools for helping with specific languages, like dh-make-golang, dh-python, etc...

[1] https://packages.debian.org/buster/alien

[2] https://manpages.debian.org/testing/debhelper/debhelper.7.en...

Re: CentOS Project shifts focus to CentOS Stream

#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 diminishing the prominence of the community version. They first renamed it (to WildFly) since the "JBoss" name confuses users with their enterprise edition offering. Then they started adding confusion around usage of the community edition of the server (now named WildFly) and started sending out messages (which never were clarified) that WildFly "cannot" be used in production environments (no explanation of what production environment was). Answers to these questions typically directed users to JBoss EAP (the enterprise edition) where they could enroll in developer programs and use the JBoss EAP for free for development use and then pay for the same when they use that or deploy that in production. This effectively killed the entire JBoss (now WildFly) community (external contributions, user discussions and any such interactions). WildFly these days is just there as a community project for the sake of it. There's no real external involvement in it and it's mostly driven by Red Hat employees and only rarely see any discussion happening in the open in their mailing lists anymore (can't blame them when no one external to their own employed team participates anymore).

The thing though is, developers actually involved in this project had strong opposition to the way this was handled, but none of it was heard and the "decision was already done" by people who hardly had any role to play on the day to day community involvement with the project. I am pretty sure it was the same with this CentOS decision.

Post reply on HN