Red Hat cutting back RHEL source availability • Hacker News Board

Re: Red Hat cutting back RHEL source availability

#321

Post by JonChesterfield » Fri, Jun 23, 2023, 3:23 AM UTC

dizhn wrote: post #131

pjmlp wrote: post #65

Earlier quoted context omitted.

Me attacked, not all. HN loves to hate Oracle, IBM, SAP, Adobe and friends, without getting the point that many startups that go through HN programs never achieve half of what they produce.

We seem to even be hating on RedHat now. (I was bummed about the Centos thing too). People on this thread are acting like Redhat doesn't even release any free software.

Well, they used to. Now there's software to be had in exchange for money. Mostly written by people outside of IBM. And the source access they used to provide is disappearing one move at a time. Which leaves a void and an opportunity, but also a lot of annoyance at IBM.

Re: Red Hat cutting back RHEL source availability

#322

Post by pabs3 » Fri, Jun 23, 2023, 6:58 AM UTC

schoen wrote: post #317

pabs3 wrote: post #301

Earlier quoted context omitted.

Please note that "Tivoisation" isn't what Tivo actually did and both the GPLv2 and GPLv3 ban "Tivoisation" but allow what Tivo actually did. "Tivoisation" as it is popularly known refers to blocking the running of modified GPL code, while what Tivo actually did was block running their proprietary software (their UI etc) on top of modified GPL code (here Linux). Both GPL versions block the former while allowing the la…

That's interesting, I remember thinking that the original notion of Tivoization did apply to what Tivo did (including what you describe). I wonder if this is a point of disagreement between FSF and SFC -- I know they now have several disagreements. In a similar time frame, I criticized attestation features in trusted computing because they would allow (in fact one of their main purposes was to allow) network services…

You may be thinking of SFLC, their disagreements with FSF are much larger. SFC's disagreements with FSF are mostly related to keeping RMS around.

Attestation is indeed a big problem today, especially around Android devices and proprietary apps that won't run on libre Android distributions. The attestation feature of WebAuthn could also become a problem, but that is somewhat mitigated by the Apple passkeys not being attestable.

Re: Red Hat cutting back RHEL source availability

#323

Post by bonzini » Fri, Jun 23, 2023, 7:04 AM UTC

jacooper wrote: post #314

bonzini wrote: post #251

Earlier quoted context omitted.

1) Canonical does not have enough testers. As a developer I have seen what kind of bugs are reported on Ubuntu, and some of them denote a serious lack of QA. There are packages in Ubuntu that are almost certainly shipped untested. 2) Canonical does not have enough developers, unless they found a magic recipe by which their relatively few employees know how to fix issues in all these packages while not contributing up…

Honestly I never use PPAs on Ubuntu, because Ubuntu universe has everything I ever need, and now its supported by Ubuntu PRO.

So here is an example. Universe has all system and user-mode emulators for QEMU, it's 20-odd packages. To what extent will Canonical fix bugs in there, even for very old emulated machines? You don't know, but you know that they have no contributions upstream and it's one of the largest packages they have, so your chances aren't great.

Red Hat only has the KVM-enabled binary because, as the #2 contributor to the upstream project, they know exactly what can and cannot be supported. It also has dozens people of employed just to test it. If you have an issue it may languish because no one is perfect, but your prior is a little better.

Re: Red Hat cutting back RHEL source availability

#324

Post by znpy » Fri, Jun 23, 2023, 4:08 PM UTC

prmoustache wrote: post #300

znpy wrote: post #299

Earlier quoted context omitted.

Red Hat recently turned 30 years old as a company. So yeah, 5 years is pretty recent, unless you started using linux last week.

I said at least 5 years because I know I used it 5 years ago in a previous company and I am pretty sure about it but it may have been earlier. If you have a source with the original announcement, by all means share it. EDIT: found an announcement of march 2016 so we are talking +7years at least.

Still fairly recent unless you started using linux last week.

Re: Red Hat cutting back RHEL source availability

#325

Post by Vogtinator » Fri, Jun 23, 2023, 8:47 PM UTC

matthews2 wrote: post #84

Vogtinator wrote: post #55

Earlier quoted context omitted.

How does this not violate the GPL?

The GPL says I must give you access to the source along with the binaries, but it doesn't say I need to give you updates indefinitely.

I'm referring to the "You can redistribute the source, but then we'll cancel support" part which appears to be part of the terms and conditions.

Re: Red Hat cutting back RHEL source availability

#326

Post by fatherlinnux » Sun, Jun 25, 2023, 7:05 AM UTC

jzb wrote: post #148

phpisthebest wrote: post #62

Earlier quoted context omitted.

This is only true it RHEL was self contained OS Project with no Upstream sources itself... That is not the case, RHEL is not possible with out the wider ecosystem, and to say Rocky Linux is a "dirtbag" for repacking RHEL, would be like saying RedHat is a "dirtbag" for packaging any number of free software projects they consume into their product. It completely antithetical the free software movement for which Linux i…

I'm not going to call Rocky or Alma "dirtbags" (does anybody use that phrase these days?) but comparing what Red Hat does to Rocky is misleading. RHEL Clones: Take finished source code, rebuild, test, release. RHEL: Work upstream to develop features / submit features upstream before inclusion in RHEL, maintain specific versions of upstream, test hundreds of upstreams together to make sure they can be shipped together…

I read this comment, said to myself hell yeah, this person gets it, then realized it was my friend JZB!!! On point my friend, on point!

Re: Red Hat cutting back RHEL source availability

#327

Post by fatherlinnux » Sun, Jun 25, 2023, 7:12 AM UTC

matheusmoreira wrote: post #306

pietro72ohboy wrote: post #74

Earlier quoted context omitted.

> However it is perfectly on brand of the "Open Source" corporatist movement that seems to be supplanting free software This has been happening on HN too. The vilification of GPL and AGPL as ”not free in the truest sense of the word”, the usage of RMS and his personal image to label the free software movement outdated/fanatical/toxic is a testament to how corporate rebranding efforts have succeeded in replacing free…

Yeah. Open source is a wealth transfer from developers to corporations. I've reached the conclusion that anything other than AGPLv3 means we're working against our own interests. Giving up the leverage provided by the GPL benefits only corporations.

I think I get the gist of your sentiment, and somewhat agree, but let me clarify.

GPL, only enforces redistribution of software you distribute, "to" the people you desteibute it to, aka customers.

Most other licenses (MIT, Apache, BSD, etc) don't require any code redistribution (though some require attribution).

GPL ~= redistribution to customers Other ~= no redistribution

Red Hat is complying with the GPL requirements even for BSD, Apache, and BSD licensed code, which I think is good.

I think a more sinister trend forming is around open core, and essentially proprietary code mixed with no code redistribution at all. This makes open core essentially closed source for all intents and purposes. Companies are using open core simply for free marketing and to drive technology adoption in the sales/marketing funnels.

Re: Red Hat cutting back RHEL source availability

#328

Post by RMPR » Mon, Jun 26, 2023, 9:25 AM UTC

acatton wrote: post #216

Cu3PO42 wrote: post #135

Earlier quoted context omitted.

I have run SELinux on Fedora without too many issues. Of course, Fedora being rather closely related to RHEL that shouldn't be too surprising.

Fedora is to RHEL what Debian Sid is to Debian stable. Yes, it's not that simple, and there are some customization done. But Fedora is the playground for the next RHEL. I woudn't consider Fedora "an alternative" according to what the top-poster was describing.

> what Debian Sid is to Debian stable.

I've heard that a lot but I don't think this is an adequate comparison (yes even with the disclaimer in the next paragraph). First of all because of the relative stability of Fedora, I've been updating my OS since Fedora 29 and every major upgrade is mostly boring. Second, there are some decisions made in Fedora that wouldn't make sense if it was merely a test bed, removing the whole Java stack comes to mind, or more recently the libreoffice debacle.

Re: Red Hat cutting back RHEL source availability

#329

Post by yrro » Mon, Jun 26, 2023, 11:04 AM UTC

2OEH8eoCRo0 wrote: post #34

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

To be fair to Oracle I believe they have their own "unbreakable" kernel packages, though they do ship Red Hat's kernel as well.

Re: Red Hat cutting back RHEL source availability

#330

Post by yrro » Mon, Jun 26, 2023, 11:16 AM UTC

ilyt wrote: post #197

cookiengineer wrote: post #144

Earlier quoted context omitted.

Also in terms of security, Oracle's "forks" are decades behind. They managed to make RedHat unsecure with their own dogshit changes. There are so many CVEs for Oracle specifically that are just bad default usernames and passwords, where they still dispute the CVE reports because it is "intended behaviour". So ridiculous...

RHEL also introduced some.... interesting changes few times, like re-enabling ciphers removed from upstreams because their clients needed them for something. I remember our amazement on how we failed audit on having a cipher enabled in OpenSSH version that had that cipher removed in upstream...

The neat thing about RHEL is that there's a single 'crypto-policies' package which configures available TLS versions and algorithms for everything in the system: TLS, SSH, IPSec, DNSSEC, Kerberos and so on.

Regarding SSH, the FUTURE policy removes AES128, HMAC-SHA1 and DH Group 14.