First dot point:
>"Durable foundation for IT innovation fuels more intelligent hybrid cloud operations with AI-powered Linux management"
Wtf does this even mean!?
His second best song after No Church In The Wild.
Shame he went off the deep end, he was talented, now if it wasn’t for his money/fame he wouldn’t look out of place shouting at pigeons in the local park.
I had to look up the song title. It seems to be a collaboration between Jay-Z and another person who U have Zero respect for and who I don't want to give a dime of my money.
Do you think it is more the work of Jay-Z or that other person?
he unfortunately had a lot of really good tracks from his early career that I can never listen to because it feels gross listening to a literal unironic fuckin nazi
It's hard for me to take that seriously when you hear the other stuff he says when he's manic and unmedicated.
To be clear, I hate Nazis and I hate that he could be creating more Nazis. I just feel like this is insanity.
“We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing.”
Without the buzz words.
# Red Hat Enterprise Linux (RHEL) 10 - Key Updates
- **Kernel Update**
- Upgraded to Linux kernel version 6.12.0-55.9.1.el10_0.
- **Package Updates**
- Updated core components like OpenSSH, SELinux, and Podman (now version 5.0).
- **Container Tools**
- Enhanced support for Podman, Buildah, and Skopeo for container management.
- **Image Creation**
- Improved tools for building and managing system images, including support for Edge deployments.
- **Security Enhancements**
- System-wide cryptographic policies now support post-quantum algorithms (Tech Preview).
- Replaced VNC with RDP for graphical remote access.
- New system role for managing `sudo` configuration across systems.
- **Architecture Support**
- Exploring support for x86-64-v3 microarchitecture for better CPU optimization.
- **Graphics Stack Changes**
- Removed Xorg server (except Xwayland); full transition to Wayland.
- **Resilient Storage Add-On**
- Discontinued support for the Resilient Storage Add-On in RHEL 10+.
- **Release Cadence**
- Adopted a three-year release cycle for major RHEL versions.
- **General Availability**
- RHEL 10.0 was officially released on May 13, 2025.
Makes me wonder what managers actually do, if they can make sense of such word-soup and base their decisions off what they claim to obtain out of such messages. Are their decisions any better than tossing a coin if they're just acting on information-free white-noise?
Certainly would explain some actions I've seen out of management everywhere I've worked.
> Makes me wonder what managers actually do, if they can make sense of such word-soup and base their decisions off what they claim to obtain out of such messages.
A lot of them don't really have a deep technical skillset and just kind of depend on their subordinates to familiarize themselves with the technical details. Even though it seems like a bunch of word soup to them it seems like these terms just have a lot of social currency and lets them have some vague reference point for what is being talked about.
Also a lot of them don't really know what a solid write up would be or how to locate one.
It's a press release. "press-releases" appears in the URL.
Press releases are *always* a bunch of buzz words, that's what press releases are for. That's how they work. They're intended to create buzz.
If you want something that's not buzz words, you're looking for the Release Notes: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/index
From Wikipedia, the free encyclopedia
A.1. Sauce
Product type Brown sauce
Owner In North America Kraft Heinz
Country England
Introduced 1831; 194 years ago
Website kraftheinz.com/a1
A.1. Sauce (formerly A.1. Steak Sauce and sometimes stylized as A1 Sauce in certain markets) is a brand of brown sauce produced by Brand & co, a subsidiary of Premier Foods in the United Kingdom (as "Brand's A.1. Sauce") and in North America by Kraft Heinz. Sold from 1831 as a condiment for "fish, meat, fowl and game" dishes in the United Kingdom, the makers introduced the product to Canada, and later to the U.S. where it was later marketed as a steak sauce.
Did that answer your question?
You’re not wrong. About the two important things in there is image mode (bootc, probably) and post quantum crypto (which is just a cooler word for saying “slightly better next-gen cryptography”). Iirc lightspeed is some IBM junk, and idk about anything else in there. Another boring RHEL release, minus Xorg.
Tl;DR - The are doing a good PR
Alma Linux so far provided a product that is not a clone but an improvement to RHEL while keeping the old Centos structure which people were used to. They have patched some issues before RH did and even provided the patches upstream, and the lateness in RH reply to them was bad on RH side.
Now, I personally would license my stuff with Alma and second with Red Hat (they have done a lot for the community and deserve the money, mostly) and I PERSONALLY avoid all else.
Everyone has their reasons to not use the other but between then you can find.
* CenOS, because Red Hat killed the old release scheme and replaced with Stream, which is harder to match 1-to-1 with an official dot release. The main problem is that since it's a server distribution many need to be sure you are using the exact version of packages as the providers request.
* RHEL, first, for the license cost (they do offer some dev licenses); the change in Centos being a PR nightmare when it happened; people not trusting IBM; Second making the access to the sources used to build the distro registry dependent. After that they took a long time to fix some issues that Alma provided the solution first and sent upstream.
* Oracle Linux, because it's Oracle;
* Rocky, Partnered up with Oracle and SUSE forming CIQ, it was formed by Gregory Kurtzer who is shady at best.
I do recommend reading more about as there are some good articles on the whole history.
Yep, someone in BART IT needs to work on the displays in the SF Montgomery station :) It's a really nice logo! It caught my attention and I had to look it up.
Adding to the first answer, Rocky history is has some shady moments and it is part of CIQ, which Oracle also belong and that is a red flag for many (like me).
For the same reason, many stopped caring for Centos and RHEL due to principle as the change they did to the source and binary releases left a very bad taste in most users' mouths.
Rocky founders also are a bit sketchy in my opinion. They named their distro after one of the founders of CENTOS who died but won't give any details about this person and what I was able to find online is disturbing to say the least.
AlmaLinux is willing to merge patches that are not present in CentOS Stream or RHEL, and that means they can decide to fix bugs that affect their users which Red Hat does not fix in RHEL.
For the same reason, AlmaLinux is able to build for architectures that RHEL/CentOS Stream do not support. For example, RHEL 10's minimum micro-architecture is x86-64-v3. AlmaLinux has a build for x86-64-v2. Rocky Linux does not, in part because building for v2 requires patching the source.
"Bug compatible" is a myth. There is no such thing as a 1:1 rebuild of RHEL. There never has been.
For one thing, Red Hat has never published the build root info (or other info) that would be required for a "bug for bug" rebuild. The original CentOS developers understood that, and occasionally tried to clarify that for users. For example, [here](https://www.spinics.net/lists/centos-devel/msg19564.html), "CentOS was NEVER bug-for-bug compatible." But that wasn't a message that CentOS users wanted to hear, so it never spread too far, despite being the opinion of the project's own maintainers.
But more importantly, the whole idea is just a hobgoblin. RHEL doesn't try to be bug-for-bug compatible with itself, so why should anything else try to be? Red Hat ships bug fixes on a regular basis. Every time you apply updates, your system is no longer bug-for-bug compatible with its state before you applied updates.
That reminds me, thank you for reminding me to use more of their Oracle cloud services and to sign up for things on there with as many credit cards as I can find.
I beg a differ. Our operators and testers require Chrome or Firefox with all the non FOSS codecs installed. I would 1000% prefer including flatpaks for Chrome than include it in our monthly RPM patching. I’ll admit Im biased since I already heavily use them with Silverblue. But managing GUI apps is just so much easier as flatpaks, pending you have the necessary mesa libs already installed. Only reason we don’t use them is because we’re somewhat airgapped and its a PITA getting non RHEL/EPEL packages past security (gov).
How do you handle security when it comes to Flatpaks? As it stands today, it isn't possible (unless I missed it) to actually lock down Flatpak usage without adding complexity via other system tools and controls. If you disable network access for a Flatpak application via Flatpak config/manifest/controls, a user can just flip it back on. In the current state, a user has the highest precedence when it comes to application configuration, which does not fly with InfoSec teams I've worked with.
I do have a customer case open with Red Hat about this very issue.
You're right that user-modifiable permissions are a legitimate concern for your InfoSec team. The permission precedence (app manifest → system overrides → user overrides) does mean users can override restrictions.
That said, if users have shell access to run `flatpak override`, they can already bypass most application controls through other means - downloading binaries, modifying configs, setting environment variables, etc. The fundamental issue isn't Flatpak-specific but rather about trusting users with command line access.
For your use case though, Flatpak still offers benefits: you start from a sandboxed state (vs RPMs with full user access), avoid dependency conflicts, and get cleaner updates. If you need to lock down permissions completely, you'd need OS-level controls (SELinux policies, restricted shells) regardless of packaging format.
Maybe the real question for your InfoSec team is whether they're looking for perfect permission enforcement (which requires removing user shell access) or just better defaults and simplified management (which Flatpak provides over traditional RPMs).
In many ways I agree. At my org it's not so much the info-sec team but me as the primary owner of the workstation stack. I personally prefer RPMs in most cases, except for highly complex and/or fast moving software where system dependencies can't keep up. I consider the Flatpak sandbox fundamentally broken for enterprise usage if admin defined properties can be bypassed. The moment that is fixed and we have the ability to prevent users from installing/updating Flatpaks and adding user-level repositories I'm throwing it on the systems.
In my sector (Animation and VFX), clamping down command line access would significantly level productivity. By not supporting Flatpaks it removes yet-another-attack-vector if the application in question is only distributed in that format. Building non-industry software from source is fortunately not very high on the todo list by our developers and users. There are a few AppImages in use, but virtually every third-party application has been legal/infosec approved.
I just really want to avoid needing to perform too many SELinux, fapolicy, etc operations for non-critical workloads.
Flatpak support allows Red Hat to focus more narrowly on supporting components that their enterprise customers need, while providing a means for users to run software that Red Hat does not directly support. I think that's unambiguously good.
Flatpak also provides the infrastructure for a much more secure desktop with much better privacy controls.
I thought RHEL always targeted a non-LTS release, for reasons that never made sense to me. So isn't it a rather big deal that this is using 6.12, which is a ten year LTS and further one that Debian uses?
Have RHEL and Debian ever used the same kernel?
They won't use the LTS kernel releases. They backport their own patches. So the kernel version will always be 6.12.0 then you'll see a - and then a incrementing version number for their changes.
I was personally hoping for a rebase to 6.13 explicitly to prevent this confusion but it was too late to do so when the 10.0 branch freeze came into effect.
IMO most noteworthy changes are complete removal of X11 based sessions and the seamless replacement of some natively packaged applications with Flatpaks, similar to Ubuntu and Snap. Curious to see how this will affect more mainstream distros
Removing it reduces maintenance burden for understaffed distributions while fully removing the "Wayland is too niche to deal with" that some applications prefer to live in. Next year's GNOME 50 is currently set to rip out all X11 session code (though could happen as soon as GNOME 49). New desktops like Cosmic don't have X11 session support. KDE will likely drop X11 session support too in the not so distant future.
It's slowly becoming possible for developer's to release Wayland-only apps (i.e. Waydroid) without leaving behind most of the Linux user base.
My org sent me to Red Hat Summit (sitting in my Boston hotel as we speak). My takes:
BootC/Image Mode seems neat though I feel like that sort of paradigm for server builds will take a while for mass adoption. RHEL Lightspeed, namely the command-line-assistant, will likely be immediately blocked or disallowed by many orgs since by default it sends queries to Red Hats own LLM and Watson, though they do plan to allow use of local models.
I mean... don't you typically support RHEL/Ubuntu/Suse anyways? You'd be pretty foolish to at least not cover those three... But, it's also not like RHEL is a new distro, either.
So, you're paid by your boss to do a job.
That said, it's not like a bunch would change from a customer service standpoint here. Nothing different than any other RHEL release. Welcome to the world of Information Technology.
So, get out of customer support roles, then, and get into SRE roles.
RHEL 10 will be some variable updates in our ansible plays, and thats about it, and that includes the RHEL derivs like OL10 and Rock 10.
We're like 80% of the way already, and it took us a couple of weeks.
This happens every time there's a new RHEL, Debian, or Ubuntu release. Part of those "actual interesting things" are, sadly, keeping the plumbing clear.
If you're a software architect, a) then you should be well aware that a) RHEL releases happen on a very set schedule and this is in now way new, and b) why the hell are you dealing with bash scripts? and c) The world works in the way that YOU get a paycheck to support X, Y, and Z. If you do not like the support matrix your employer uses, as a software architect, change that, or go work for another company more matched to your desires.
I mean, hell, as an SRE, I touch more of this than you do, and it's a nothingburger. I'd see your concern during the init changeover period, but hell man... This is par for the course.
Systems engineers annd andmins are about to extinct. Don’t believe me? Use Warp terminal and you can literally tell it in plane English what you want done (for example: have system configure firewall rules and validate those rules on system boot) and it’ll think up the steps and executes. Humans are finished with working in command line.
Using a Workstation version at one of my work desktop since RHEL 8. Very satisfied at all. Absolutely no problems. Running it at PC with the newest Xeon w7 and two RTX A6000.
Compared to naming a distro after yourself and (ex-)spouse?
There wasn't anything wrong with the name when they picked it and they can't control world events that cause it to pick up a different symbology. Could be worse, see [The Tea Party](https://en.wikipedia.org/wiki/The_Tea_Party_\(band\)) band.
Compare the
We still have OS information in RH Satellite from that era. I should really purge some of it but man if it isn't annoying trying to find RHEL when you have "Red Hat Linux" and "Red Hat Enterprise Server" listed as well.
The only docs that actually matter -
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/overview
Ignore OP’s link.
Well this is the press release and what you have are the docs. I would expect a the press release to be a bit more "Hey! Look at our neat thing!" and not well, the docs lol. Just two different audiences for each one.
The press release doesn't have any actual information. It's just buzz word salad. It's not even a "look at our neat things", it's just random buzz words organized into paragraphs with no information.
While true, I believe the majority of the audience in this sub would be more technically minded and want to see what's changed without all of the flavor text meant to push a product.
I recognize what I have linked is also not a replacement for an announcement, but it is useful auxiliary information.
145 Comments
billysmusic@reddit
RhubarbSpecialist458@reddit
Stoned420Man@reddit
daemonpenguin@reddit
kuroimakina@reddit
noir_lord@reddit
Salt_Blackberry_1903@reddit
rpgnymhush@reddit
Salt_Blackberry_1903@reddit
gallifrey_@reddit
moonflower_C16H17N3O@reddit
piesou@reddit
bastardoperator@reddit
diligentgrasshopper@reddit
dpokladek@reddit
Keely369@reddit
Nearby-Sugar-161@reddit
MichaelTunnell@reddit
ImpossibleEdge4961@reddit
spacelama@reddit
ImpossibleEdge4961@reddit
yur_mom@reddit
gordonmessmer@reddit
Misicks0349@reddit
hkric41six@reddit
billysmusic@reddit
goblin-socket@reddit
harrywwc@reddit
Chance-Restaurant164@reddit
ThatOneShotBruh@reddit
Ok_Second2334@reddit
ThatOneShotBruh@reddit
tu_tu_tu@reddit
RoomyRoots@reddit
RoomyRoots@reddit
MaToP4er@reddit
RoomyRoots@reddit
jonspw@reddit
MaToP4er@reddit
a_deneb@reddit
jonspw@reddit
UnPlugged_Toaster@reddit
Keely369@reddit
my_name_isnt_clever@reddit
jonspw@reddit
my_name_isnt_clever@reddit
ten-oh-four@reddit
DesiOtaku@reddit
RedditorsRSoyboys@reddit
RoomyRoots@reddit
DrunkOnRamen@reddit
SpaceCadet2000@reddit
mishrashutosh@reddit
NaheemSays@reddit
gordonmessmer@reddit
AtlanticPortal@reddit
gordonmessmer@reddit
hadrabap@reddit
thatsbutters@reddit
Ancient_Sentence_628@reddit
RoomyRoots@reddit
acdcfanbill@reddit
JQuilty@reddit
babuloseo@reddit
MechanicalTurkish@reddit
hadrabap@reddit
bullwinkle8088@reddit
struct_iovec@reddit
Resource_account@reddit
omenosdev@reddit
Resource_account@reddit
omenosdev@reddit
gordonmessmer@reddit
struct_iovec@reddit
no_f-s_given@reddit
boomboomsubban@reddit
thewrinklyninja@reddit
omenosdev@reddit
Leinad_ix@reddit
Ivan_Kulagin@reddit
derangedtranssexual@reddit
DriNeo@reddit
cAtloVeR9998@reddit
derangedtranssexual@reddit
VoidDuck@reddit
Ezmiller_2@reddit
untetheredocelot@reddit
derangedtranssexual@reddit
swn999@reddit
1kfaces@reddit
ravagetalon@reddit
79215185-1feb-44c6@reddit
leocura@reddit
Ancient_Sentence_628@reddit
79215185-1feb-44c6@reddit
Ancient_Sentence_628@reddit
79215185-1feb-44c6@reddit
Ancient_Sentence_628@reddit
79215185-1feb-44c6@reddit
Ancient_Sentence_628@reddit
79215185-1feb-44c6@reddit
Ancient_Sentence_628@reddit
JQuilty@reddit
NaheemSays@reddit
ThenExtension9196@reddit
Sibexico@reddit
thomasthetanker@reddit
midgaze@reddit
killerdeathman@reddit
daemonpenguin@reddit
Ancient_Sentence_628@reddit
gmes78@reddit
TexasDex@reddit
killerdeathman@reddit
jhansonxi@reddit
AcordeonPhx@reddit
blendernoob64@reddit
JQuilty@reddit
blendernoob64@reddit
Engineering-Guy-185@reddit
IHaveNeverLeftUtah@reddit
bullwinkle8088@reddit
agent-squirrel@reddit
Fernmixer@reddit
bleshim@reddit
MetaTrombonist@reddit
rinnys@reddit
OddAcanthaceae2819@reddit
Jarmund5@reddit
gmes78@reddit
Dre_Dede@reddit
bengringo2@reddit
daemonpenguin@reddit
abotelho-cbn@reddit
MaToP4er@reddit
AssociateFalse@reddit
DolitehGreat@reddit
daemonpenguin@reddit
AssociateFalse@reddit
Keely369@reddit
linuxhacker01@reddit
_OVERHATE_@reddit
hadrabap@reddit
e_t_@reddit
niomosy@reddit