I’ve been diving into Linux and rapidly traversing through distributions finding things I like, don’t like, etc.
One thing I’m hung up on is that in “enterprise” operating systems (RHEL, CentOS, Alma, Rock, etc.) Apache is presently sitting at 2.4.37-43, while 2.4.51 is available from apache.org . I understand the last number (-43) would be a build increment of some form but what does being limited to 2.4.37 vs 2.4.51 mean from a practical and pragmatic standpoint?
Is the .37 release up to date with regards to critical security fixes/CVE disclosures, leaving out the features and development that went into later builds by Apache?
From what I can tell, this applies to virtually all “enterprise” packages so help me understand this package version convention.
There is a good explanation here. In essence, RH takes all the latest security fixes and applies them to the current version. This ensures that the current feature set remains stable throughout its life and doesn’t break dependencies.
Yes, up to date regards to security, but might contain some features from later versions.
Example: EL7 has kernel based on 3.10, but does now contain nftables, which was introduced in upstream 3.13.
Red Hat develops RHEL. Oracle, CentOS Linux, AlmaLinux, Rocky Linux all do build from the published sources of RHEL. Therefore, what is in RHEL, is in the others too.
The others might inject some additional/modified content, but AL, CL, RL keep that to minimum because development and maintenance is not cheap.
Red Hat has created httpd-2.4.34 as Software Collection for RHEL 7, which has httpd-2.4.6.
The RHEL 8 has Application Streams, where Red Hat could add a stream for another httpd.
Example: dnf module list php\* shows that AppStream offers now three versions of PHP.
At a high level, this was my understanding of enterprise OS operations, but it wasn’t clear how it was achieved in a secure fashion. Thanks! I’ll give that a read through!
Thank you for the detail. I’ve just recently been exposed to downstream, upstream, mainstream, etc. and this provides some additional context.
In most respects, I’m not a feature monger, and will use what is popular. I was tempted by Ubuntu 21.10, but within a few days some features seemed to break, and that’s what prompted me to understand the enterprise proposition in more detail.
I guess CloudLinux is an example of injecting custom content (for a fee) as they do a lot of maintenance and security updates for old packages.
On this topic, what typically triggers a version update? With RHEL derived code, I suppose this all points to RH and what they deem is an appropriate time for an update?
Would AL ever override this and do an update on their own?
AlmaLinux OS is 1:1 binary compatible with RHEL®
(except for the branding, artwork including RH logos, etc… obviously, here the 1:1 binary compatibility needs to be “broken” )
What is the goal then of AL (and other RHEL clones) that are 1:1 binary compatible? What value is added to the distribution? Presumably AL = RHEL + ??
For CL, I could see AL being adopted as the canonical base OS moving forward so I see a business reason why CL would have a “free hit” in the form of AL.
Definitely not trolling, I’m just trying to figure things out.
RHEL offer a number of advantages in terms of support for earlier point releases, access to propitiatory information and full time support. They charge for this and that is how they make their money.
AL and RL do not provide any support, instead they rely on the various communities to help each other out, as, when and if they are able. AL and RL do not charge for this!
You have to make a balanced assessment here. If you need full-time professional support and the ability to avoid point releases until you are ready, then put your hand in your pocket and go with RHEL. If on the other hand you are happy to self-maintain and rely on the community, then AL is the way forward. Finally, some places will adopt a hybrid stance and pay for support for critical production machines, but use the free alternative for development machines or simple number-crunching compute nodes.
So the difference between AL and RL is practically none aside from perhaps mission statements?
I don’t need full-time support so all that stuff is out of my scope of interest and I would never be using RHEL proper. I’m looking for a commodity type OS to host various activities on, and I think AL delivers that, though I’m wondering how it compares to Ubuntu LTS.
You’d need to talk to @jack to be certain, but as a user my feeling is that AL is quicker to get software out (first stable release was at least a month ahead of RL) and has more support for SIGs and other specialist stuff. I plumped for AL last March and have been very happy with it and the community support.
AL has solid corporate support from CL, and CL has incentive to encourage users to converge on a single platform before or after CL (at least, that’s my take on it).
One thing that bugs me, is why a package like nano is at 2.9.8 which is about 3 years old. It may be my inexperience, but I can’t see many having software dependencies on a text editor as it is predominantly a UI thing, not an automation thing. Again, I could be entirely wrong, I just want to understand.
)