But with a very IBM move and with some tunnel vision, they got triggered by the few people who abuse RedHat license model and rugpulled everyone. More importantly universities, HPC/Research centers and other (mostly research) datacenters which were able to sew their own garments without effort.
Now we have Alma, which is a clone of CentOS stream, and Rocky which tries to be bug to bug compatible with RHEL. It's not a nice state.
They damaged their reputation, goodwill and most importantly the ecosystem severely just to earn some more monies, because number and monies matter more than everything else for IBM.
Remember. When you combine any company with IBM, you get IBM.
Alma is not a clone of CentOS Stream. You can use Alma just like you were using CentOS. It's really no different than before except for who's doing the work.
I agree that communication was bad. But why do you believe that Red Hat isn't able to screw up on their own?
I'll kindly disagree on this with you. Reading the blog post titled "The Future of AlmaLinux is Bright", located at [0]:
> After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be binary compatible with RHEL.
> The most remarkable potential impact of the change is that we will no longer be held to the line of “bug-for-bug compatibility” with Red Hat, and that means that we can now accept bug fixes outside of Red Hat’s release cycle.
> We will also start asking anyone who reports bugs in AlmaLinux OS to attempt to test and replicate the problem in CentOS Stream as well, so we can focus our energy on correcting it in the right place.
So, it's just an ABI compatible derivative distro now. Not Bug to Bug compatible like old CentOS and current RockyLinux.
TL;DR: Alma Linux is not a RHEL clone. It's a derivative, mostly pulling from CentOS Stream.
> I agree that communication was bad. But why do you believe that Red Hat isn't able to screw up on their own?
Absorption and "Rebranding and Repositioning" of CentOS both done after IBM acquisition. RedHat is not a company anymore. It's a department under IBM.
Make no mistake. No hard feelings towards IBM and RedHat here. They are corporations. I'm angry to be rug-pulled because we have been affected directly.
Lastly, in the words of Bryan Cantrill:
> You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end.
You're wrong. CentOS Stream was announced September/October 2019, too close to the IBM announcement to be an IBM decision; it had been in the works for quite some time before, and in fact this all started in 2014 when Red Hat acquihired CentOS.
From 2014 to ~2020 you were under the impression that nothing had changed, but Red Hat had never cared about CentOS-the-free-RHEL. All that Red Hat cared about was CentOS as the basis for developing their other products (e.g. OpenStack and OpenShift), and when Red Hat came up with CentOS Stream as a better way to do that, Red Hat did not need CentOS Linux anymore.
Anyhow, I've been through that and other stuff as an employee, and I'm pretty sure Red Hat is more than able to occasionally fuck up on its own, without any need for interference from IBM.
Underneath it all, compatibility is what matters. At AlmaLinux we still target RHEL minor versions and will continue to do so. We're a clone in the sense of full compatibility but a derivative in the sense that we can do some extra things now. This is far, far better for users and also let's us actually contribute upstream and have more of a mutually beneficial relationship with RH versus just taking.
Sometimes the hardware or the software you run requires exact versions of the packages with some specific behavior to work correctly. These include drivers' parts on both kernel and userland, some specific application which requires a very specific version of a library, so on and so forth.
I for one, can use Alma for 99% of the time instead of the old CentOS, but it's not always possible, if you're running cutting edge datacenter hardware. And when you run that hardware as a research center, this small distinction cuts a lot deeper.
Otherwise, taking the LEAPP and migrating to Alma or Rocky for that matter is a no-brainer for an experienced groups of admins. But, when computer says no, there's no arguing in that.
Basically the goal is still to fit the exact situation you just brought up. I'm not aware of this ever not being the case if it weren't to be the case for some reason, then we have a problem we need to fix.
All of the extra stuff we do, patch, etc. is with exactly what you just stated in mind.
As I said, in some cases Rocky is a better CentOS replacement than Alma is.
But to be crystal clear, I do not discount Alma as a distribution or belittle the effort behind it. Derivative, clone or from scratch, keeping a distro alive is a tremendous amount of work. I did it, and know it.
It's just me selecting the tools depending on a suitability score, and pragmatism. Not beef, not fanaticism, nothing in that vein.
Let us know if you have any issues!
I'd also argue that CentOS classic was mostly bug for bug compatible but probably close enough for most. It shared sources but did use a different (complex) build system as I understand it.
Not anymore. I just use the latest ubuntu LTS and call it a day.
IBM/RedHat was soo predictably short sighted on this.
In general, while RHEL is obviously still an important revenue source, there's also a lot of focus on OpenShift going forward which has done of pretty good job of covering (and more) inevitable RHEL declines moving forward.
They are completely different products just reusing branding to confuse what people are asking for.
RHEL Developer is closer, as a no-support, no-cost version of RHEL, but you still have the deal with the licence song and dance.
CentOS gave folks a free version that let you run some dev environments that mostly mirrors prod, without worrying about licences or support. CentOS stream doesn't do this out of principle. It's upstream.
Apart from that, in terms of keeping RHEL relevant, most of the attention is on making it easier to operate fleets at scale rather than the OS itself. Red Hat Insights, Image Builder, services in general, etc.
Those are the key things that would keep it competitive against Ubuntu, Debian, Alma, Oracle etc.
RHEL is the enterprise gold standard.
Fedora is a lot of the pipeline for it, which itself has become an incredible server and desktop platform.
All the work with Open shift, backstage, podman / qubelet, etc.
They're going to be fine, from my graybeard position.
Fedora is the upstream for RHEL.
You are going to see RHEL transition to bootc: https://docs.fedoraproject.org/en-US/bootc/
Get with the times, fellow gray beard: https://github.com/redhat-cop/redhat-image-mode-demo
---
* What is RHEL Image Mode?
RHEL Image mode is a new approach for operating system deployment that enables users to create, deploy and manage Red Hat Enterprise Linux as a bootc container image.
This approach simplifies operations across the enterprise, allowing developers, operations teams and solution providers to use the same container-native tools and techniques to manage everything from applications to the underlying OS.
* How is RHEL Image Mode different?
Due to the container-oriented nature, RHEL Image mode opens up to a unification and standardization of OS management and deployment, allowing the integration with existing CI/CD workflows and/or GitOps, reducing complexity.
RHEL Image mode also helps increasing security as the content, updates and patches are predictable and atomic, preventing manual modification of core services, packages and applications for a guaranteed consistency at scale. ---
Show me on this doll where RHEL touched you.
Of course I can’t speak for all the teams, but all new projects are going out on kubernetes and we don’t care about rhel at all, typically it’s alpine it Debian base images
During my time at IBM and at other companies a decade ago, I can name examples of this:
* Lotus Notes instead of Microsoft Office.
* Lotus Sametime Connect instead of... well Microsoft's instant messengers suck (MSN, Lync, Skype, Teams)... maybe Slack is one of the few tolerable ones?
* Rational Team Concert instead of Git or even Subversion.
* Rational ClearCase instead of Git ( https://stackoverflow.com/questions/1074580/clearcase-advant... ).
* Using a green-screen terminal emulator on a Windows PC to connect to a mainframe to fill out weekly timesheets for payroll, instead of a web app or something.
I'll concede that I like the Eclipse IDE a lot for Java, which was originally developed at IBM. I don't think the IDE is good for other programming languages or non-programming things like team communication and task management.
I've seen a lot of failed projects for data entry apps because the experienced workers tend to prefer the terminals over the web apps. Usually the requirement for the new frontend is driven by management rather than the workers.
Which is understandable to me as a programmer. If it's a task that I'm familiar with, I can often work much more quickly in a terminal than I can with a GUI. The assumption that this is different for non-programmers or that they are all scared of TUIs is often a mistaken assumption. The green screens also tend to have fantastic tab navigation and other keyboard navigation functionality that I almost never see in web apps (I'm not sure why as I'm not a front end developer, but maybe somebody else could explain that).
I'll defend green screens all day long. Lots of people like them and I like them.
Everything else you listed I would agree with you about being terrible and mostly hated though.
Back in ... maybe 2005 or what, in our ~60 people family business, I had the pleasure to watch an accountant use our bespoke payroll system. That was a DOS-based app, running on an old Pentium 1 system.
She was absolutely flying through the TUI. F2, type some numbers, Enter, F5 and so on and so on, at an absolutely blistering speed. Data entry took single-digit seconds.
When that was changed to a web app a few years later, the same action took 30 seconds, maybe a minute.
Bonus: a few years later, after we had to close shop and I moved on, I was onboarding a new web dev. When I told him about some development-related scripts in our codebase, he refused to touch the CLI. Said that CLIs are way too complicated and obsolete, and expecting people to learn that is out of touch. And he mostly got away with that, and I had to work around it.
I keep thinking about that. A mere 10 years before, it was within the accepted norm for an accountant to drive a TUI. Inevitable, even. And now, I couldn't even get a "programmer" to execute some scripts. Unbelievable.
Consistency is a thing. Old windows apps often followed a style guide to some degree, that was lost with web (while it's also hard, as styleguides differ between systems, like Windows and Mac) and wasn't ever as close as Mainframe terminal things where function keys had global effects.
All of the major platforms have a HIG that tells developers how to maximize the experience for users. Webapps have dozens of ways to do things like “search”. Those who never developed for a platform with a HIG do not value it and keep reinventing everything.
The best oart was that it was entirely keyboard driven. If you can touch type, you can just read the paper and type away. The job was mind numbing, but the software itself was great.
Despite its obvious downsides, for people who do regular form input and editing, it's often better than the flavor of the day web framework IMO
I mean, I wouldn't choose to use it, but I get it
A few years later in college I worked there again and by that point they'd transitioned to a much slower GUI that basically just wrapped the underlying green screen system. The learning curve was slightly better, but it wasn't nearly as fast.
Purpose-built mainframe-based TUIs were amazing. We lost a lot in pursuit of colored pixels.
At the end of the day most people are lazy and most things, including (especially?) things done for work, are low quality. So you end up with the default more often than not.
then, every couple of years, a startup tries to carve out a niche by making a product that caters to power users and makes efficiency a priority. those power users adopt it and start to recommend it to other regular users. this usually also tends to work quite well because even regular users are smarter than expected, especially when motivated. thus the product grows, the startup grows and voila, a tech giant buys it.
now one of the tech giants managers gets the task to improve profits and figures out, the way to do this is to increase the user base by making the product easier to use. UX enshittification ensues, the power users start looking out for the next niche product and the cycle starts anew.
rule of thumb: if the manager says "my grandma who never used a computer before in her life must be able to use it", abandon ship.
Maybe someone has examples of web apps made for also a high skill ceiling?
I've heard Linear, Superhuman does something like that while maintaining a nice interface, but I've never used those
- Confirm this is correct? (Yes=F1, No=F2) - Would you like to make any changes? (Yes=F1, No=F2)
And maybe sometimes flip the yes/no F-key assignments as well.
In theory this was done to force users to read the question and pay attention to what they were doing, in practice, users just memorized the key sequences.
/s
Post-web and post 9/11, where web browser UI has infested everything, we are now in a cambryan explosion of crayon-eating UI design.
It seems our priorities have been confused by important things like 'Hi George. I just noticed, that for the admin panels in our app, the background colours of various controls get the wrong shade of '#DEADBF' when loading on the newest version of Safari, can you figure out why that happens?'. 'Oh, and the new framework for making smushed shadows on drop-downs seems to have increased our app's startup time on page transitions from 3.7 seconds to 9.2 seconds, is there any way we can alleviate that, maybe by installing some more middleware and a new js framework npm module? I heard vite should be really good, if you can get rid of those parts where we rely on webpack?'
Agree! Back in 2005, I was involved in a project to build a web front end as a replacement for the 'green screen' IBM terminal UI connecting to AS400 (IIRC). All users hated the web frontend with passion, and to this day, I do not see web tech that could compete in terms of data entry speed, responsiveness, and productivity. I still think about this a lot when building stuff these days. I'm hoping one day I'll find an excuse to try textualize.io or something like this for the next project :)
The fact that someone who has been doing it for years can do it faster is obvious, and pretty irrelevant.
Take someone who has never used either, and they'll enter data on the web app much faster.
You don't see keyboard nav in most web apps for similar reasons. First-time users won't know about it, there's no standard beyond what's built-in the browser (tab to next input, that kind of thing), and 90% of your users will never sit through a tutorial or onboarding flow, or read the documentation.
I would agree with you if we were talking about a customer facing webpage or something. But an app for say an accountant? That should be a TUI or as fast as a TUI. The workers are literally hired to get over the learning curve and become fast with the app, so it's not as big a concern if first-use is more difficult. You arent trying to sell them a product and drive higher percentage click through.
I 100% agree with you for applications for say online shopping. Those should prioritize new user experience over long time user efficiency probably.
It works great for Python and C++, honestly. If you're a solo dev, Mylyn does a great job of syncing with your in-code todo list and issue tracker, but it's not as smooth as the IDE side.
However, its Git implementation is something else. It makes Git understandable and allows this knowledge to bleed back to git CLI. This is why I'm using it for 20+ years now.
But yeah some elements of that list have convinced me to steer very clear from any products from that company
My favourite Sametime feature within Pidgin was, well, tabs (I can't remember if the Windows client had tabs as well..?), which was revolutionary for an IM client in 2005.
But my secret actual favourite feature was the setting which automatically opened an IM window /tab when the other person merely clicked on your name on their side (because the Sametime protocol immediately establishes a socket connection), so you could freak them out by saying hello even before they'd sent their initial message.
I have no idea how/why IBM of all places developed or sold this software but it badly needs to die in a fire.
Database technology which would seem outdated in 1994 with a UI and admin management tools to match.
I expect it to be still used in aviation or army related domain, maybe pharma.
We were given old Macs running Classic to run Notes so we had two computers. One being MacOSX. Notes was the biggest pile of crap I’ve ever had to use. With one exception…
On the OSX box we were happily running svn until we were forced to use some IBM command-line system for source control. To add insult to injury, the server was in Texas and we were in Boca Raton (old PC factory as it happens). The network was slow.
It had so many command-line options a guy wrote a TCL for it.
Adding to that was the local IBM lan was token ring and we were Ethernet. That was fun.
https://trends.google.com/trends/explore?date=all&q=terrafor...
https://trends.google.com/trends/explore?date=all&q=terrafor...
That being said, it'll be interesting to see if it's still a rounding error 2 years from now.
Not a product, but a service: is Red Hat Linux a counter example?
Every IBM product I've ever used is universally reviled by every person I've met who also had to use it, without exaggeration in the slightest. If anything, I'm understating it: I make a significant premium on my salary because I'm one of the few people willing to put up with it.
My only expectation here is that I'll finally start weaning myself off terraform, I guess.