Red Hat sweetens the RHEL deal for biz devs – just don't put it in prod IBM's Linux subsidiary is offering a new way to get RHEL without paying, now with up to 25 instances. Yesterday, Red Hat announced a new type of free developer subscription for its enterprise distro. The new entitlement is aimed at developers working inside "corporate organizations" and allows them to get up to 25 instances of …
Yes, there's not much meaningful advantage to RHEL itself, but it can be hard to ignore the associated employment opportunities from corporations who don't know any better.
To be fair, Red Hat do have an abundance of documentation, and some of it is decent, even good on occasion. But I somewhat liken it to Cisco, e.g. as a lever to sell more vendor courses, certification tracks, manuals, etc. Which feeds the corporate employment cycle, and must be renewed periodically.
> Do they think corporate organisations have just 25 developers or something?
I did wonder reading the article whether they meant 25 per developer or 25 per organisation. I could go and look on RHEL's website to find out but it's too hot and I can't be arsed. :-)
Simplified access to the world’s leading enterprise Linux platform with the self-service ability to entitle up to 25 physical, virtual or cloud-based instances per registered user as a member of the Red Hat Developer Program.
It's cooler now so I checked. Per developer. You just have to get past your corporate's bureaucracy first. Or the other way is just downloading Rocky or Alma.
> Wondering what is the advantage of this over using the corresponding clone version:
Branding. This is the _real thing_.
It's like a T-shirt that says "DOLCE AND GABBANA" on the front. I mean _obviously_ that's better than a T-shirt that doesn't say D&G. It's a _designer_ T-shirt. Designer clothes are _better_. Even if they are just a T-shirt. It may look exactly like other T-shirts but it must be better because it's a designer one. It's probably... like... better made, from better quality cotton. Right? Because it says it's a designer one right there on it... and it costs more.
So it makes sense that it's better. I mean if it wasn't better people wouldn't pay for it, so it has to be, or the company would go broke, and yet it's worth billions! Nobody ever for fired for buying IBM, right?
IBM costs more but it's quality kit. This is IBM Linux. IBM wouldn't have bought them if they were rubbish. IBM is expensive and it's been around for 114 years so it knows its stuff, right? It wouldn't buy some cheap crappy distro that couldn't do version-to-version in-place upgrades, right?
I'm sorry. Something just came in on my mind-control ray. Please scratch the part about version upgrades. You don't need those. Nobody upgrades servers. You deploy new ones. Please ignore that and continue to pay for this high quality ENTERPRISE distro. It says ENTERPRISE right there in the name so you know it must be good.
"Please scratch the part about version upgrades."
Tried that once on a test system a very long time ago†. Not a pretty sight. Once seen, never forgotten.
Most if not all proprietary Unixes supported in place (major) version upgrades‡ which generally worked unless you had been playing silly buggers with the system disk or its file systems. I always wondered how many Unix sysadmins moving to Linux system got burnt by this.
† Before RHEL 4 I would imagine.
‡ Usually one way. Normally no downgrade path. A backup root and /usr were always a wise investment as were actual backups. ;)
> I always wondered how many Unix sysadmins moving to Linux system got burnt by [no in-place major upgrades]
Possibly not as many as you'd think. E.g. those of us who started as Unix Sysadmins didn't have that many Linuxes early on, and by the time we did, we'd either been warned by the Red Hat sales team, and/or were burned once by an attempt at RHEL major upgrading, and didn't bother with it again.
Some (likely fewer) of us were fortunate enough to have Debian and/or FreeBSD et al, and didn't really see what the fuss was about.
A smaller still number of us had to support all of them, the worst of all worlds, as it were.
Now, we did typically do full re-installs for 32- vs. 64-bit OSes on everything, but often as not the underlying hardware was changing too, so it was considered the price of admission.
Unless RHSAT 6.x has toddled off in the direction of Damascus and had an epiphany in the last few years I would count that omission as a feature.
The previous Spacewalk based version 5. was for all its flaws a great improvement on its successor.
I think SuSE did maintain and support a Spacewalk based system which could be used instead to manage RH fleets but the service had to run on a SuSE system.
The only reason I would run RHEL using this offering would be to keep my RHELative fleet as functionally compatible with stock RHEL as legally possible.
If you were using Alma Linux (AL) it would depend on your actual usage whether RHEL ⊆ AL or AL ⊆ RHEL was more important. If you were developing applications targeted towards the RHEL platform AL ⊆ RHEL might be wise although targetting AL ⋂ RHEL would be wiser. If you just consumed fairly common third party packages RHEL ⊆ AL would be acceptable as would in practice a great deal less.
In environments where hardware and software has to be certified and supported these concerns do not arise; you choose your poison and pay for the pain.
I never did SAT because we had issue with the way system config and details were stored *at redhats end*.
Cloned the repos we had access to and kept our own copies. Used several different FOSS utilities to keep the systems updated and since we never stored app/user data on the same volumes as the OS we did (reinstall) on version jumps. Release updates and security patch runs were in general painless. I learned entirely too much about anaconda.
