61–70 of 184 posts
>Red Hat uses and will always use an open source development model Yes, I do not mean to sound harsh but I do not know how say this in a nice way. To me, this means we will still happily take work from our volunteers, but we will restrict other people from using this work so we can get more $. But thank you volunteers for keeping our payroll low and helping out our stockholders. I really think this is another small s…
> Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity. So... completely tone deaf.
They gotta eat, how do you propose to feed them? I'm pretty sure if all paid Redhat developers stopped contributing it would be a massive blow to the Linux ecosystem that would not readily be replaced by volunteers. They employ people who work on every fundamental pillar of kernel space and userspace. Even if the fired devs wanted to continue contributing, it would probably be reduced hours compared to what they cont…
What makes this extra worrying is the important role RH plays in the linux ecosystem. When they get fully IBM'd, what will happen to Gnome, Systemd, Flatpak, etc?
Earlier quoted context omitted.
I'm not even a user of rhel but the difference is: security patches. Enterprise uses rhel because they fix or triage nearly every vuln, every time. If you work for a company with extremely stringent security requirements, or sell to government entities, rhel and its derivatives (CentOS/Amazon Linux 2, etc) are basically the only way you can clear their requirements. Debian (and by extension, Ubuntu) chooses to not fi…
I work for a eu government with extremely high security requirements (in the national identity / IDP / health space). We actually _CANNOT_ use redhat for compliance reasons. (We're using ubuntu LTS as it goes)
McGrath seems to be fessing up to removing access to binaries, and has his hard-truth he wants to try to deal, but but it seems like the story goes significantly deeper or the anger/frustration wouldn't be anywhere near as high. It's not clear to me from a quick browse of the repo what backports/security fixes are/aren't available.
Earlier quoted context omitted.
I know why they use RHEL - support is apparently good and not every corpo wants to keep some linux experts on payroll to fix the rare issues that need a bit more expertise. And they keep old versiond of Red Hat updated for longer so you old crusty enterprise garbage can stay garbage few years longer and claim "but OS is updated" in audit. I have no idea who in their right mind would use derivative, it has zero benefi…
Funny; our RHEL systems were a nightmare for compliance actually. Most of the tools the auditor/pentester type people use only search for, (completely fake example) libfoo 1.x.2 having a security hole, and redhat's libfoo 1.x.2-wibble13 even though it has a backported fix, is flagged as vulnerable. For each one of these packages, it's a crazy process to prove that the CVE they reported isn't actually there, and it de…
Sounds like they think of Rocky as the enemy, 'under no obligation' to make it easier, 'rebuilding code' is a 'threat'... I have a project in RHEL that they 'rebuild' but I don't see that as a 'threat'. They want to be a little bit more careful with dogma that makes sense to their management, will get them patted on the head there, but is just nonsense seen from other perspectives - like my perspective contributing t…
Earlier quoted context omitted.
I know why they use RHEL - support is apparently good and not every corpo wants to keep some linux experts on payroll to fix the rare issues that need a bit more expertise. And they keep old versiond of Red Hat updated for longer so you old crusty enterprise garbage can stay garbage few years longer and claim "but OS is updated" in audit. I have no idea who in their right mind would use derivative, it has zero benefi…
Funny; our RHEL systems were a nightmare for compliance actually. Most of the tools the auditor/pentester type people use only search for, (completely fake example) libfoo 1.x.2 having a security hole, and redhat's libfoo 1.x.2-wibble13 even though it has a backported fix, is flagged as vulnerable. For each one of these packages, it's a crazy process to prove that the CVE they reported isn't actually there, and it de…
Maybe Ubuntu LTS does less security backports than RHEL, but that doesn't make it better per se (saying this as an Ubuntu user).
Earlier quoted context omitted.
I work for a eu government with extremely high security requirements (in the national identity / IDP / health space). We actually _CANNOT_ use redhat for compliance reasons. (We're using ubuntu LTS as it goes)
Why? What compliance reasons make Ubuntu LTS work and RHEL not work?
In the end, we just went with ubuntu for those nodes, and they all passed the certification. Shrug.
Since then, we don't even need the OS to be certified, since we are using confidential computing, and we stuck with ubuntu for our k8s nodes etc -- but we are forbidden from using rhel anywhere by our legal / compliance people now.
Earlier quoted context omitted.
Funny; our RHEL systems were a nightmare for compliance actually. Most of the tools the auditor/pentester type people use only search for, (completely fake example) libfoo 1.x.2 having a security hole, and redhat's libfoo 1.x.2-wibble13 even though it has a backported fix, is flagged as vulnerable. For each one of these packages, it's a crazy process to prove that the CVE they reported isn't actually there, and it de…
t.b.h. all this tells me is that your pentesters are bad.