Live data from Hacker News

I'm Done with Red Hat (Enterprise Linux)

jeffgeerling.com

311–320 of 410 posts

Re: I'm Done with Red Hat (Enterprise Linux)

#311

[flagged]

This honestly sounds like an infomercial testimonial and is bizarre to read on here.

I assure you I'm not being payed by anyone to make comments online, in fact my $dayjob is paying huge amounts of money to IBM/Red Hat for our partnership with them.

I've been using open source for over 20 years, and I admit to using CentOS because it was a FREE version of a stable RHEL distro.

I wish I could find a free, community-based and non-commercial distro in the Linux ecosystem that I was happy with, but I just can't. The closest one is Debian, but I still don't want to leave RHEL.

Re: I'm Done with Red Hat (Enterprise Linux)

#312
post #278

Earlier quoted context omitted.

I believe that was for Ubuntu Pro. Ubuntu Pro provides some extra support (five more years) for packages in Ubuntu's existing (gratis) Long Term Support (LTS) releases of Ubuntu.

Hmmm, not sure about that. The wording was along the lines of "There are security updates for package XYZ. If you join (maybe its Ubuntu Pro like you mention?) you'd have access to them." That's not really a message that should be showing up on a box running 20.04 LTS, which is years before its EOL date.

Yeah, I saw it too.. we used a precursor to Ubuntu Pro so I'm sure my message was less obnoxious.

I think they're also offering patches for some commonly installed third-party stuff like nodejs via Ubuntu Pro.

I actually quite like Ubuntu Pro for the fact I can send a developer a laptop and know that there's 24/7 support from Canonical. I was a little dubious at how good they'd be, but they were able to diagnose the problem and provide a fix.

Re: I'm Done with Red Hat (Enterprise Linux)

#313

Earlier quoted context omitted.

Probably not, at least not initially. Hopefully we see more usage of distros like Alpine out in the security field.

Why not SLES?

SLES is worse than RHEL in my eyes. Their support is horrendous, absolutely the worst in the industry. Their early move to btrfs caused so many headaches at client sites. I haven't trusted their technical decision making since.

Re: I'm Done with Red Hat (Enterprise Linux)

#314

Earlier quoted context omitted.

Nope nope nope means this is a different quality of thing, the things you are trying to put in the same category are in different categories. the GPL, by it's own text explaining itself, is intended to ensure that users of GPL software always have the right to re-distribute it. It says that right in it. If your point is that IBM has enough lawyers and money to prevent users from redistributing GPL software, and they…

> If your point is that IBM has enough lawyers and money to prevent users from redistributing GPL software, and they may have figured out how to exersize a loophole that will be difficult to do anything about it, especially cause of all those lawyers and money... right, indeed, sure. It's not. The that IBM has here is that they're doing is not lawyers and money, it's that their customers depend on them -- vendor lock…

If using open source while putting food on the table is incompatible with the freedom for users to redistribute open source software, than the aims of the GPL has failed.

Which is possible.

Where we disagree is that you are trying to summarize them all as the same thing -- either you are doing something that violates the license in a way that can be enforced in court, or it's all just the same category of doing what the license allows as a tool while putting food on the table.

The difference, I am suggesting, within that category, is simply that the GPL was very specifically designed to allow users of GPL software to redistribute that software without restriction, and Red Hat is trying to prevent this, while using GPL'd software.

It's as simple as that. This makes it different than just any generic "I'm within the letter of the license while trying to maximize the profit I can make from using this open source".

Whether it is within the license or not is not clear, only a court can decide.

Whether it violates the intent of the GPL is pretty clear, it says so right in the GPL.

Of course, nobody has to care about the intent of the GPL, but you don't have to consider open source an "end and not a tool" to care about the intent of the GPL. The choice is not just "I think open source is a political movement rather than tool", vs "I am fine with companies using GPL software to do things the GPL's whole reason for existing is to prevent, if that's what they need to do to maximize their profit, cause we're all just maximizing our profit here, whatever you can get away with is fine."

Open source is a tool, and GPL open source is a tool that preserves the right to modify and/or redistribute it, which is why some people choose to use it or license under it. I do understand that those rights are of no concern to you, right.

Re: I'm Done with Red Hat (Enterprise Linux)

#315
post #302
post #99

Some reasons why Stream is not replacement for Centos alike (Alma, Rocky, ...). 1. Stream can't be used as base to build el-compatible packages. There is no any guarantees Stream doesn't break ABI compatibility. 2. Stream has no large (several years) support cycle and can't be used as a stable system. Yes, there is a big community who don't need a paid licensed support from a RH and ready to help with bug reports and…

> There is no any guarantees Stream doesn't break ABI compatibility. This is incorrect. Or, sure, there are no _guarantees_, but any such break would also break a future RHEL release, and is therefore a bug. 2. Five years.

AFAIK, there is no rule RHEL is strictly based on Stream.

Re: I'm Done with Red Hat (Enterprise Linux)

#316
post #94

Earlier quoted context omitted.

> But that said, as far as I know, one guy used the term "freeloaders" and the context wasn't clear at all who he was talking about, and certainly not clear whether that is one person's opinion. Yeah, Red Hat wasn't the one that called them "freeloaders", this was language The Register used in an article: >> Having given the move time to successfully eliminate most of the clones, Red Hat then killed off its own offic…

Hi there. I am the author of the Register article that you quote: > this was language The Register used in an article So, in response to that, I'd like to point out a few things. 1. This is, I feel, now widely and well-established language in this discussion. For example, note its use in the comments to this article about the discontinuation of CentOS Linux three years ago: https://blog.centos.org/2020/12/future-is-c…

So amazingly primitive they even think a digital watch is a pretty neat idea.

Re: I'm Done with Red Hat (Enterprise Linux)

#317

Earlier quoted context omitted.

https://lwn.net/Articles/929582 AFAIK Oracle employs major contributors to btrfs and XFS. I'm mostly interested in filesystems, so I can't speak for other subsystems (seems like they do a decent amount of work on core kernel development — the really important stuff like schedulers and the memory subsystem — second place just below Google).

Oracle Linux is also not a pure RHEL clone. They customize it as they desire and ship it accordingly. For example, they have an alternative kernel for their distribution with different features.

But they also have RHEL native kernel version for version if you're to choose to run that instead. It's just that RHEL kernel is usually very old and UEK kernel has more modern features and improvements in it.

Overall while they have some extra packages available they are on top of RHEL clone and you don't have to use them.

Re: I'm Done with Red Hat (Enterprise Linux)

#318
post #302
post #99

Some reasons why Stream is not replacement for Centos alike (Alma, Rocky, ...). 1. Stream can't be used as base to build el-compatible packages. There is no any guarantees Stream doesn't break ABI compatibility. 2. Stream has no large (several years) support cycle and can't be used as a stable system. Yes, there is a big community who don't need a paid licensed support from a RH and ready to help with bug reports and…

> There is no any guarantees Stream doesn't break ABI compatibility. This is incorrect. Or, sure, there are no _guarantees_, but any such break would also break a future RHEL release, and is therefore a bug. 2. Five years.

> Five years

So basically 2 times less, nice.

Re: I'm Done with Red Hat (Enterprise Linux)

#319
post #181

Earlier quoted context omitted.

If you don't mind, what makes more niche hardware drivers work / build better against RHEL? I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel. Beside the driver developers apparently using RHEL / CentOS (so on…

> I suppose RHEL uses basically the same kernel, with patches that don't alter its interface too substantially. So I presume that a driver in source form, or even partly in binary blob form, should build and work approximately equally well with any stock kernel. No, I think that's exactly the difference; Linux (in)famously has no stable ABI for drivers, and regularly makes changes that break things if you don't recom…

Yes, exactly this.

Maintaining any kernel modules that are not in the Linux kernel tree is extremely painful.

Almost every new kernel version breaks the older kernel modules, e.g. device drivers, by moving definitions between kernel headers, by adding or deleting function parameters, or by adding or deleting structure members.

Most of these changes are very poorly documented, so anyone who does not follow daily the kernel development is clueless for instance about which values should be put in the new function parameters or new structure members in order to obtain the same behavior as in the previous kernel version.

The kernel developers who make these breaking changes do not bother to write upgrading instructions for the benefit of those who must maintain an out-of-tree device driver, so those may have to waste a lot of time with reading the kernel sources, to discover what must be done to make the old device drivers compatible with a new kernel.

Re: I'm Done with Red Hat (Enterprise Linux)

#320
post #94

Earlier quoted context omitted.

> But that said, as far as I know, one guy used the term "freeloaders" and the context wasn't clear at all who he was talking about, and certainly not clear whether that is one person's opinion. Yeah, Red Hat wasn't the one that called them "freeloaders", this was language The Register used in an article: >> Having given the move time to successfully eliminate most of the clones, Red Hat then killed off its own offic…

Hi there. I am the author of the Register article that you quote: > this was language The Register used in an article So, in response to that, I'd like to point out a few things. 1. This is, I feel, now widely and well-established language in this discussion. For example, note its use in the comments to this article about the discontinuation of CentOS Linux three years ago: https://blog.centos.org/2020/12/future-is-c…

If we’re very lucky, will Red Hat read some poetry to us first?
Post reply on HN