[RndTbl] RHEL pulls source code

Alberto Abrao alberto at abrao.net
Sat Jun 24 16:24:22 CDT 2023


On 2023-06-23 22:03, Trevor Cordes wrote:
> Well, RH making dumb mistakes (ever since creating RHEL and making RH
> non-free) always causes a big upheaval in the Linux world.  (Well, blame
> IBM this time.)  This usually turns out for the better.  Often it
> forces RH to backtrack.

This time, it's a a lot more than that IMHO. If they succeed, the GPL 
becomes kind of a joke, really.


> They can out-RHEL RHEL, one-upping them and getting all the users.
> Think Maria vs MySQL (who's that?).  Of course, such a thing would take
> months and that means major pain or short-term RHEL subscriptions for
> all the RHEL-clone users.
>
> (Heck, it gets me itching to do my big PHP fork idea again, as PHP goes
> down the path of insanity, too.)
>
> As always it makes me reiterate my support for Fedora (until they screw
> that up...) which is still 100% free, has great easy upgrade paths, and
> if you play your cards right has only modest occasional "you're the
> bleeding edge now" pain.

Fedora is great.

After the first round of IBM-RH mishaps - the CentOS debacle - I did run 
Fedora Server on everything for a while.

I did not have many - if any - breakages, that's true. But it does 
require updates fairly often - that's the whole point of it! - and many 
of these require a reboot. I am diligent in doing updates and rebooting 
as needed, so I obliged.

Even my home stuff started to be a little bit of a pain in the bottom to 
keep current and fresh. I can't imagine anything that requires a solid 
uptime being subject to that. You can, of course, not do that as 
promptly, but I just can't bring myself to not do those things on a 
timely manner.


On 2023-06-23 22:23, Adam Thompson wrote:
> Not wrong, but there are a LOT of users who can't even tolerate modest 
> occasional "you're on the bleeding edge" pain.  In fact I'd say nearly 
> 100% of corporate Linux instances can't tolerate that - all the SMBs 
> who can are merely a rounding error... for better or worse.

I am with Trevor that the "bleeding edge pain" claims are wildly 
exaggerated more often than not. Regular updates proceed without issues. 
Even between versions it goes fine more often than no.

But that's only a part of it  Even if you accept this, a Fedora Server 
installation still requires significantly more attention to keep current.

> Most of my clients (EDU) cannot tolerate one second more of downtime 
> than absolutely necessary... during the school day, anyway.  And those 
> pain points don't come at predictable dates :-).  If I started using a 
> distro (no, not a dildo, WTF autocorrect?!?!?) that I *knew* would 
> cause even one hour more per year of service outage or degradation, 
> I'd get lynched.  (At my previous employers, I'd simply get fired.)

(I lauighed out loud, thanks for that one!)

I can relate to that, 100%. Again, even if you consider all updates will 
be flawless, there's still the work between applying them, and making 
sure system hygiene is done properly so it comes back online and running 
the latest bits. Updates between major versions can take a little bit of 
(down)time, even considering they tend to work surprisingly well.

Hand wave the potential pitfalls, and you still have the increased 
frequency of the updating process itself. It does add up.


> IMHO, corporate Fedora users are unicorns, or, "it's nice work, if you 
> can get it".
>
> We're now waiting to see if we get the exciting joy of migrating ~100 
> CentOS/Alma VMs to another distro, which would easily be a year-long 
> project or more.  Oh, or we could just buy RH's Enterprise license 
> that provides blanket licensing for<Infinity> VMs for only US$2500 per 
> CPU socket... that's a really big ouch on a VMware cluster our size!

Back when they first pulled a fast one, we looked.

No support RHEL was 4 times what Ubuntu would cost at the time, and 
Ubuntu has the "live update" feature included, which seemed like a 
decent value-add. We didn't investigate how well it really works, but 
still....

>
> Bah, humbug.  Post CentOS "acquisition", we all suspected this day 
> would come, but hoped it wouldn't.

Not that far out, back in 2020, the fears were there for us. We started 
moving to Ubuntu, then decided not to, because it's so damn annoying. 
They get so much right, and yet, decide to die on the most stupid hills 
ever. Snaps on a server distro? Get out of here.

Alma and Rocky show up, disaster averted, it seemed.

Until now. I really, really like the "flow" of RPM-based distros. But 
that's it. It is time to face the music.

When I moved to Winnipeg three years ago, I set up my mail server and 
other things using Debian 10. At the time, it was a cheap old desktop 
PC. It was later virtualized, moved between hypervisors a million times, 
wrecked by fat fingering when messing with its qcow2 file, recovered, 
you name it. But it was never reinstalled. The Debian 10 installation 
was brought forward to 11, flawlessly, and is running right now, ready 
to be upgraded to the newest Debian 12.

It gives me very little headache, other than when I actively poke in it, 
or have it sitting on flaky hard drives. Can't blame the distro for it, 
of course.

It almost dawned on me that maybe, just maybe, I should just use Debian. 
No trickery, no Snaps, just old school reliable, predictable, current*, 
and SysAdmin friendly.

The only remaining question concerns to my desktop/laptop installations. 
I've been running Fedora, and I really enjoy it, so I am in no rush to 
change. But, as it stands, it would not be wise to ignore the warnings 
for the second time. We'll see.


Kind regards,
Alberto Abrao


* Yes, current. For Desktop users it may not seen like it, but Server 
distros move on a different pace. Debian has new releases every 3 or so 
years, so you can get your PHP -or whatever -  ducks in a row. If you're 
not ready, you have time, because older versions hang around for at 
least two more years. For a community distribution with no strings 
attached, what more can you ask for, really?



More information about the Roundtable mailing list