Hacker News Reader

Comment by schmichael | Hacker News Reader

I joined HashiCorp in 2016 to work on Nomad and have been on the product ever since. Definitely a lot of feelings today. When I joined HashiCorp was maybe 50 people. Armon Dadgar personally onboarded us one at a time, and showed me how to use the coffee maker (remember to wash your own dishes!). There have been a lot of ups (IPO) and downs (BUSL), but the Nomad team and users have been the best I've ever gotten to work with.

I've only ever worked at startups before, but HashiCorp itself left that category when it IPO'd. Each phase is definitely different, but then again I don't want go back to roadmapping on a ridiculously small whiteboard in a terrible sub-leased office and building release binaries on my laptop. That was fun once, but I'm ready for a new phase in my own life. I've heard the horror stories of being acquired by IBM, but I've also heard from people who have reveled in the resources and opportunities. I'm hoping for the best for Nomad, our users, and our team. I'd like to think there's room in the world for multiple schedulers, and if not, it won't be for lack of trying.

View on HN

I've had the incredible displeasure of having to maintain multiple massive legacy COTS systems that were once designed by promising startups and ultimately got bought by IBM. IBM turned every last one into the shittiest enterprise software trash you can imagine.

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.

How is Red Hat going after the acquisition by IBM? From my view, it is going well. The enterprise product (RHEL) is still excellent.

It's going basically fine. If you're in engineering you would never notice the difference.

Companies are often brought in and told that nothing will change, and as long as they can pull their weight, this may be true. IBM seems a pretty diversified company, and there RedHat doing 5% of the total revenue may not be too bad. I don't know how well RedHat is doing commercially, but a few bad quarters could draw negative attention of the sort where upper-management wants to start messing with you, seek more synergy, efficiency, alignment. Being a much smaller small company within Verizon, having been left alone for a little while, we were then told that The Hug was coming. It did. We didn't grow to be their next billion dollar business unit (as no surprise to anyone in our little company), nor were we able to complement other products (ha! synergy!) and we were shuttered. At some point... engineering will notice.

Dropping CentOS was a terrible decision. I’m not sure if that happened before or after the acquisition though.

It mostly happened afterwards but it was not driven by IBM.

Centos stream still exists and it is in fact the actual upstream of rhel.

But for all practical purposes, that is dropping CentOS. They completely changed the identity of the product, so the fact it has the same branding isn't going to placate anyone.

People that actually care about the distro being sustainable are quite happy with the changes. Sorry you don't get it.

so? That just means that it is not necessarily compatible with the current version of rhel deployed on our servers

It's the same major version, so it's extremely compatible. Plus if you run into something that doesn't work the same, you just discovered what's going to break for your workload on your RHEL system when the next minor version is released.

so it's not the same. Which means that it is not equivalent to what centos was. It's highly, but not fully, compatible. centos was "fully". You can't use it to test on the current version of rhel, where with centos you could. You can't say they're equivalent and then start listing the differences that make them not

But CentOS Stream is not CentOS.

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.

To call it "completely different" is false. They are built differently, but the end result is still 90-95% the same software versions (because it has to be as the major version of RHEL). In fact, the way it is built differently is a massive improvement over the old process. The old CentOS was put together by 2-4 people at a time, with long delays after the corresponding RHEL releases, with no ability to actually fix bugs or accept contributions. The new CentOS (CentOS Stream) is built by thousands of engineers, literal subject matter experts who can actually fix bugs you report to them, or even better merge a contribution you submit. Also, the branding wasn't reused, the branding is for the whole CentOS Project, which still exists and is more active than ever. Also, you can still use CentOS in your dev environments, and it works great for that because you can prepare your production workload for upcoming changes in the next RHEL minor version ahead of time. You can also get free RHEL for dev environments, for the things you need to validate with the same minor version as your production RHEL environments.

It is different, otherwise why would then explain at length at how it is better?

CentOS was the downstream of RHEL, and much more people used it than RedHat/IBM knew or wanted to admit. I can argue that at least 90% of their users (by the number of installs) didn't even need any help to configure/troubleshoot that either.

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.

> they got triggered by the few people who abuse Red Hat license model and rugpulled everyone

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?

> Alma is not a clone of CentOS Stream.

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.

[0]: https://almalinux.org/blog/future-of-almalinux/

> Absorption and "Rebranding and Repositioning" of CentOS both done after IBM acquisition. RedHat is not a company anymore. It's a department under IBM.

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.

Bug for bug is a sham and always was. It's a disservice to users to only clone something.

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.

I'll say it depends.

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.

We don't change the expected versions. We might patch/backport more to them if there are issues, but the versions remain.

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.

I'll be installing a set of small servers in the near future. I'll be retrying Alma in a couple of them, to give it another chance.

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.

Sustainability is one of the core reasons why we are not using RHEL SRPMs to build AlmaLinux. RH doesn't want us doing that, and doing so would be unsustainable and bring into question the future of AlmaLinux as it can, and likely will, turn into a game of cat/mouse getting those SRPMs :)

Let us know if you have any issues!

If you're running cutting edge datacenter hardware, CentOS is a better fit now than it ever has been before. It will be the first to get support for new hardware within a major version, ahead of RHEL and all it's derivatives. It is possible that some hardware doesn't get support within the current major version of any of these related distros, and you'll have to wait until the next major version, which CentOS also does first before the rest.

Red Hat bringing CentOS in-house (well before IBM entered the picture) was IMO one of the first in a string of expedient decisions that were... unfortunate. When I was at Red Hat I loudly argued against some of the ways things were handled but I also understand why various actions were taken when they were.

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.

That closeness allowed CentOS to be a drop-in replacement for RHEL for thousands of installations and exotic hardware combinations. Unfortunately, we don't have this capability anymore. Rocky bears most of that load now.

Despite being a debian/ubuntu guy, I usually used CentOS for production deployments because it would be easy and seamless to upgrade to RHEL when I hit the big leagues.

Not anymore. I just use the latest ubuntu LTS and call it a day.

IBM/RedHat was soo predictably short sighted on this.

The free LTS/distro and pay for support if you feel like it never really worked financially. Maybe Canonical is profitable at this point. It's not Red Hat (or SUSE for that matter.)

There are many large organizations that pay for RHEL support. Supercomputers, for example. These organizations also benefited from being able to spin up analog installs of CentOS on local machines for testing. Not anymore. I expect RHEL's market dominance in these areas to diminish over time.

HPC was always a tough sales area for Red Hat and RHEL.

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.

All the HPC I've used in the past was always RHEL... I wouldn't have imagined it was a tough sales area for RedHat, at least in the past.

For testing environments Red Hat will literally give them free RHEL. Problem solved.

No, they won't. I'm talking about the users of HPC centers, not the maintainers. The supercomputer cluster is at NASA or DoE and running RHEL, but the user is some grad student in Caltech or whatever. The grad student needs the analog environment to run their code before their scheduled time on the big iron.

So you say "it would be easy and seamless", but did you ever actually do it and upgrade to RHEL? Because most people throw that out as a supposed sales pipeline that was lost, but the real life metrics indicate that almost never happened.

In one case, yes.

RHEL has had no significant investment to keep it from becoming irrelevant in the next five years. The datacenter and deployments of linux have changed so rapidly (mostly due to the new centralization and homogeneity of infrastructure investment) that RHELs niche is rapidly shrinking.

RHEL 10 beta has some interesting stuff in it. Running the OS itself as a container caught my eye.

Image mode RHEL is a pretty significant investment.

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.

This is clearly someone that is not paying attention to what Red Hat is doing.

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.

Yes also a gray beard and been around long enough to tell you RHEL is and will continue to be legacy and will continue to dwindle into obsolescence. You mentioned the cool stuff Fedora is doing, that is not RHEL. CoreOS is the future.

RedHat developers are the ones making Fedora.

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. ---

I know all of this already and honestly I’m just amused at how long it has taken. Forget I said anything. Enjoy working on rhel for the rest of your life.

"Enjoy working on rhel for the rest of your life."

Show me on this doll where RHEL touched you.

If RHEL is becoming irrelevant, what distro will replace it for enterprise users?

We don’t run anything on bare metal anymore it’s all containers (90k employee very large enterprise).

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

You have a hardware implementation of Docker?

When I say "we don't run anything on" I mean our involvement in the infra begins after those layers; sure, maybe someone at google cloud is doing rhel stuff but we don't care. Push button receive kubeconfig.

So Red Hat Openshift.

Talos Linux. Replaced a fleet of RHEL OpenShift with Talos recently. We're planning on moving the rest to Talos within 1.5 years. Basically, bare metal OS is going to be an implementation detail abstracted away from the internal users and developers.

I'm the head of product at Sidero. Thanks for sharing! We love to hear people being successful with Talos.

Not sure why you were down voted, the product you guys create is amazing.

Isn’t MQ pretty good?

It’s heavy and old. We have to consume some but Kafka is nicer to work with typically (provided someone else is running it)

If Kafka is nicer to work with, then it must be horrible.

Podman is pretty good.

> Every IBM product I've ever used is universally reviled by every person I've met who also had to use it

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.

The green screens tend to be much quicker and more responsive than the web frontends that are developed to replace them.

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.

These days most web apps aren’t written to take advantage of the browser’s built-in tab navigation, and unless the dev is a keyboard user, they don’t even think to add it. This is largely the fault of React reinventing everything browsers already have built in, and treating accessibility as an afterthought. Bare metal web apps written in straight-up HTML do have decent tab navigation. They’re still not as snappy as a green terminal app, though. My first summer temp jobs during college were data entry, in the era when you might get a terminal app or a web app, and the old apps invariably had better UX.

I second the TUI argument here.

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.

Things have changed back though - the CLI is hot again at-least amongst developers.

I find it ironic that we developers prefer to use CLI because it's quick, efficient, stable, etc., but what we then deliver to people as web apps is quite the opposite experience.

It's what the default is. TUIs default to fast, stable, high-information-density, so you have to real work to make them otherwise. And I say this next part as primarily a front-end developer the past few years: web apps default to slow, brittle, too-much-whitespace "make the logo bigger" cruft, and it takes real work to make them otherwise.

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.

in my experience, many managers tend to try to dumb products down as much as possible, to make it work for the most people. the problem is that this, together with the usual bad ui/ux, makes the product inefficient to use, especially for power users.

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.

Easier to sell the initial impression for "modern" web apps (shiny, easy-to-learn, low-skill-ceiling) vs the actual performance of TUI/"desktop" apps (mundane, effortful-to-learn, higher skill ceiling).

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

Not just accountants. I remember watching fully “non-technical” insurance admin / customer service people play the green screen keyboard like they were concert pianists. People can cope with a lot when they have to.

I wouldn't say, cope, the green screen stuff has predictable field input, and predictable rules around selecting elements.

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

There is a learning curve, but not coping. One of the crest things with terminal: with experience one can type ahead, even before the form fully opened one can type data, which is queued in the input buffer and work efficiently. In a modern GUI application a lot of time is wasted with reaching for the mouse, aiming and waiting for the new form to render. That requires coping with it

Case in point: the aforementioned accountant obviously hated the new GUI-based app, exactly because of what you said. Aiming the mouse, looking for that button, etc. slows you down.

It doesn't have to. The tab order seems shortcuts are there and very usable... if anyone bothers to implement them.

Not only implement, but implement them consistently and making users aware.

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.

Indeed. One of the things I keep having to tell younger people is: “webapps have no HIG!”

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.

In a native single-threaded UI, you can type ahead too. But it doesn't work on the web unless the page effectively reimplements an input queue.

I had to interact with a windows software which allows you to collect data with a digital form. We used it to digitize paper based survey by mapping free form question to a choices list.

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.

I worked at Best Buy as a high school teenager just before they switched the green screens to some GUI monstrosity. Everyone in the store had to learn how to use the green screens (sales people, cashiers, techs, stockers - everyone) and after a few weeks / months you would get CRAZY fast.

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.

An application I used to deal with was similar, but with a somewhat quirky developer, who would deliberately flip between positive/negative confirmation questions, e.g.:

- 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.

Ah just randomly pick between F1 and F9 for the two questions and don't necessarily put them in order. Yes=F7, No=F3

I was at a ticket window buying concert tickets a couple weeks ago and was surprised to see the worker using the Ticketmaster TUI / Mainframe interface. She flew through the screens. The same experience on the Ticketmaster website is awful.

We had a tower of bable collapse, when we switched to web UI. We gained a million things and lost a million things. There was an era from around 1985 to early 2000s, where a large majority of applications had a (somewhat) consistent UI, based partially around MS-Windows, partially around some IBM 'common ui' design guide principles. The hall-marks of it was - keyboard navigation was possible - mostly consistent keyboard nav - common limited set of UI controls with consistent behaviour - for serious applications, there was some actual thought related to how the user was supposed to navigate through the system during operation (efficiency)

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?'

>The green screens tend to be much quicker and more responsive than the web frontends that are developed to replace them.

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 :)

This only matters if "quick and more responsive" is the only thing that matters. Yes of course you can enter payroll timesheets on a TUI if you spend days/weeks/months gaining that muscle memory. The same way you can edit in vim much faster than vscode or Eclipse if you spend weeks/months/years gaining that muscle memory.

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.

Are these really at odds with each other? You can have keyboard and click nav for any app.

For a work app doing data entry, there is supposed to be training for users, because it's somebody's job to use the program consistently all the time everyday.

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.

Is there a good tuinfor web?

IBM eventually figured out that these products were terrible too, even if they saved money on paper; sold the Rational/Lotus/Sametime teams to an Indian competitor, and discontinued usage internally (I think, it's a big company).

huh isn't it funny when you dogfood but instead of food it's... nvm

But yeah some elements of that list have convinced me to steer very clear from any products from that company

There are people even today who want Lotus Notes back, still mourn its loss.

If you used SameTime with Pidgin, SameTime didn't suck. But maybe that's because Pidgin is awesome, and not because of SameTime.

Yeah I was just about to say this -- I used Sametime via Pidgin (I think it may still have been called Gaim back then) on my work Linux machine and it was actually quite nice.

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.

And what was that thing they used for email?

You mean Lotus Notes?

Eclipse was nice but WebSphere Application Developer was pretty horrible - I'm not sure how they achieved that! (WSAD was/was built on Eclipse)

Can we add DOORS to this list please?

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.

DOORS is/was a requirement management tool and frankly speaking was crap but I have never seen another software as good and comprehensive in requirement management.

I expect it to be still used in aviation or army related domain, maybe pharma.

> I don't think the IDE is good for other programming languages or non-programming things like team communication and task management.

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.

I remember using Rational Clear case at my first job. Yeah, in that case count me in on the list of people that revile the IBM products they've had to use.

Heh. I worked on the Mac version of ViaVoice. I joined as I was already an expert in AppKit and Obj-C.

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.

ClearCase. You just triggered my PTSD!

Could this be an employee retention strategy? Making people use bad tooling, so that they can be proud of knowing the bad tooling no one else in the industry uses and when those people feel like looking for something new, "no one values their knowledge" in those obscure tools, so they stay at IBM?

Why leave terraform? You don’t feel OpenTofu will carry the torch well enough?

I think this is an interesting graph comparing web searches for "terraform alternative" and "opentofu". Notice the spike when the IBM rumors began, and the current spike now that the acquisition is complete?

https://trends.google.com/trends/explore?date=all&q=terrafor...

Both of those are still a rounding error compared to searches for Terraform though:

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.

> Every IBM product I've ever used is universally reviled by every person I've met who also had to use it

Not a product, but a service: is Red Hat Linux a counter example?

Everyone I know who works with IBM i (used to be system i, as/400 before that) absolutely adores it. Gods do they every nickel and dime you tho.

Unfortunately IBM is going to ruin everything that was good about working for Hashicorp and eventually everything that was good about Hashicorp products.

I worked for a company acquired by IBM, and we held hope like you are doing, but it was only a matter of time before the benefit cuts, layoffs, and death of the pre-existing culture.

Your best bet is to quit right after the acquisition and hope they give you a big retention package to stay. These things are pretty common to ease acquisition transitions and the packages can be massive, easily six figures. Then when the package pays out you can leave for good.

Red Hatter here.

none of that has happened for us at Red Hat. Other than the one round of layoffs which occurred at the time that basically every tech company everywhere was doing much larger layoffs, that was pretty much it and there's no reason to think our layoffs wouldn't have been much greater at that time if we were not under the IBM umbrella.

Besides that, I dont even remember when we were acquired, absolutely nothing has changed for us in engineering; we have the same co-workers, still using all Red Hat email / intranets / IT, etc., there's still a healthy promotions pipeline, all of that. I dont even know anyone from the IBM side. We had heard all the horror stories of other companies IBM acquired but for whatever reason, it's not been that way at all for us at least in the engineering group.

Former Hatter here (Solution Architect Q2 '21 -> Q4 '22). Other than the discussions that took place around moving the storage/business products and teams under IBM (and the recently announcement transfer of middleware), I wouldn't have expected engineering to do that much interfacing with IBM. At most, division leadership maybe (this is just personal speculation). Finance and Sales on the other hand... quite a bit more.

We had a really fun time where the classic s-word was thrown around... "s y n e r g y". Some of the folks I got to meet across the aisle had a pretty strong pre-2010 mindset. Even around opinions of the acquisition, thinking it was just another case of SOP for the business and we'd be fully integrated Soon™.

They key thing people need to remember about the Red Hat acquisition is that it was purely for expertise and personnel. Red Hat has no (or very little) IP. It's not like IBM was snatching them up to take advantage of patents or whatnot. It's in their best interest to do as little as possible to poke the bear that is RH engineering because if there was ever a large scale exodus, IBM would be holding the worlds largest $34B sack of excrement we've seen. All of the value in the acquisition is the engineering talent and customer relationships Red Hat has, not the products themselves. The power of open source development!

It's heartening to hear that your experience in engineering has been positive (or neutral?) so far. Sales saw some massive churn because that's an area IBM did have a heavier impact in. There were some fairly ridiculous expectations set for year-over-year, completely dismissing previous results and obvious upcoming trends. Lost a lot of good reps over that...

Red Hatter since 2016, first in Consulting, now in Sales.

Oh the “synergy” rocket chat channel we had back then…

Things have been changing, for sure. So has the industry. So have our customers. By and large, Red Hatters on the ground have fought hard to preserve the culture. I have many friends across Red Hat, many that transitioned to IBM (Storage, some Middleware). Folks still love being a part of Red Hat.

On the topic of ridiculous expectations…there’s some. But Red Hatters generally figure out how to do ridiculous things like run the internet on open source software.

Every time you say rocket chat, I have to appear.

FWIW, the change at Red Hat has always been hard to separate between the forces of IBM and the reality of changing leadership. In a lot of ways those are intertwined because some of the new leadership came from IBM. Whatever change there was happened relatively gradually over many years.

Paul Cormier was a very different type of CEO than Jim Whitehurst for sure. But that's not an IBM thing, he was with Red Hat for 20 years previously.

I agree with you FWIW. The company also basically doubled in size from 2019 to 2023. It's very hard to grow like that and experience zero changes. And COVID happened shortly after so that also throws a wrench into the comparisons.

The point is, it's hard to point to any particular decisions or changes I disliked and say "IBM did that"

I do miss having Jim Whitehurst around. Jim spent 90 minutes on the Wednesday afternoon of my New Hire Orientation week with my cohort helping to make sure all of us could login to email and chat, answering questions, telling a couple short stories. He literally helped build the Red Hat culture starting at New Hire. Kind of magical when the company is an 11K person global business and doing 5B in revenue.

Cormier and Hicks have their strengths. Hicks in particular seems to care about cultural shifts and also seems adept at identifying key times and places to invest in engineering efforts.

The folks we have imported from IBM are hiring folks that are attempting to make Red Hat more aggressive, efficient, innovative. Some bets are paying off. More are to be decided soon. These kinds of bets and changes haven’t been for everyone.

>The company also basically doubled in size from 2019 to 2023. It's very hard to grow like that and experience zero changes.

Longtime Red Hatter here. Most of any challenges I see at Red Hat around culture I attribute to this rapid growth. In some ways it's surprising how well so many relatively new hires seem to internalize the company's traditional values.

Yeah, when I left I think there were something like 7x the number of people than when I joined. You can't run those two companies the same way no matter who is in charge.

cpitman!!!! Miss you a ton!!!

> They key thing people need to remember about the Red Hat acquisition is that it was purely for expertise and personnel. Red Hat has no (or very little) IP. It's not like IBM was snatching them up to take advantage of patents or whatnot. It's in their best interest to do as little as possible to poke the bear that is RH engineering because if there was ever a large scale exodus, IBM would be holding the worlds largest $34B sack of excrement we've seen.

We thought the same thing at VMware until Hock moved WITH THE QUICKNESS to jack up prices and RIF a ton of engineering staff.

That said, I'm in tech sales at the Hat now, and IBM is definitely around, but it's still a cool company that tries hard to treat their people right.

They also care A LOT about being an open-source company. Most of my onboarding was dedicated to this, and sales treats it seriously.

If you asked people working for XIV before IBM discontinued the project, they'd tell you the same thing more or less.

We use Nomad where I work and we LOVE it. Previous to Nomad we used K8s for several years which, at that point, allowed us to become cloud agnostic. With the move to Nomad about 3+ years ago, we were able to transition away from cloud and back to leased, bare metal machines. During our time with K8s, it didn't have a good bare-metal strategy with their ingress mechanism. In contrast, as we investigated Nomad, it was easy to deploy on pure metal without a hypervisor. The result of our migration to Nomad was having so many capable and far-less-expensive hosting options. Lastly, as part of our Nomad control plane, we also adopted Vault and Consul with great success.

I know there are horror stories around this acquisition and lots of predictions about what will happen, but only time will tell. On a minimum, it has been a delight to use the Hashicorp software stack along with the approach they brought to our engineering workflow (remember Vagrant?). These innovations and approaches aren't going away.

Glad to hear Nomad is working well for you! It always means a lot. We as the dev team spend all day staring at bugs and missing features, so it's nice to be reminded of what's working well! No one files an issue for a happy cluster. :)

Lol at "remember Vagrant".

I used it literally this year to create a test double of the NUC that runs my home automation stack. I also used Packer to configure Flatcar and create the qcow2 that Vagrant consumes.

Vagrant is still the best tool for creating a general purpose VM on your machine. It got kind-of forgotten in the containers and Kubernetes hype, but it still gets the job done. Packer is also the best tool for creating VM images that got buried for the same reasons.

The datacenter is coming back, though. IBM would be smart to invest in these tools as loss leaders to TFE and Vault and monetize the providers, IMO.

I would GTFO, IBM ain't your friend and ain't your savior and are unlikely to invest and the worse may come with increasing IBM management sticking their fingers in the pie. The folks who did well out of this already know, they have the checks to cash if that was your take away congratulations. Otherwise find another opportunity. If nothing else look around and find out what you are worth on the market and then have that hard discussion soon with HashiCorp/IBM.

I worked with a bunch of people who had worked at a startup that got bought by IBM. As the other commenters attested, they too experienced that IBM is not the kind of company that's going to turn on the investment taps.

There are worse companies to get bought by, but if you've only ever worked at startups then you're not likely to enjoy what this becomes.

I spoke with a guy (too long ago) that was a "genius architect" and worked for a company that was small enough, that he got to implement his castles in the air. Knowing him, they might have been quite good, but it was one person that knew the details and made changes at the architect scale. He had a quirky way of thinking.

When IBM acquired that company, after a few weeks, this guy had a meeting with new engineering people. The very first meeting, they changed things for him. Instead of a single winding road of development, they wrote out a large spreadsheet. The rows were the distinguishable parts of his large'ish and clever architecture; the columns were assignments. They essentially dismantled his world into parts, for a team to implement. He was distraught. He didn't think like that. They did not discuss it, it was the marching orders. He quit shortly afterwards, which might have been optimal for IBM.

If you are a good at your job and want to deliver fast then you need to adapt to changing circumstances and continue on. Nothing wrong if you can’t but I have learnt that’s how you play along to deliver your best continuously.

You mean perhaps if you define "your job" and "adapting to changing circumstances" strictly through a corporate vocabulary.

One could argue that to deliver his best continuously he adapted to changing circumstances and left.

Fairly large Nomad Enterprise user here, and I just want to say thanks for all of the work you and the team put in. I'm a big fan of Nomad and really appreciate the opportunities it has afforded me.

Regardless of the general sentiment, hoping for the best outcome for all of you.

Thanks for supporting us!

Hey on a personal note, dealing with you and your team on Nomad's GitHub issue tracker was always a good experience. I hope nomad still has a future under IBM's roof.

Thanks! We have kept an explicit community rotation and issue triage policy for Nomad's entire life. Definitely one of my hard lines.

I know we aren't perfect. In fact it's my turn this week, and I've utterly failed at keeping up with triage!!

We get tremendous joy and value from engaging with our community. Thanks for your patience (with me in particular!)

I just wanted to say thank you for your work on Nomad. It's one of the most pleasant and useful pieces of software I have ever worked with. Nomad allowed us to build out a large fleet of servers with a small team while still enjoying the process.

> Nomad allowed us to build out a large fleet of servers with a small team

I really love these stories. Our customers constantly shock me with how large of clusters they're able to manage with just a few people. >10k nodes by <10 people isn't uncommon although we are not good at rigorously collecting data on this.

Nomad is far from perfect, but we really strive to ease the pains of managing your compute substrate.

What a blessing to see your comment today. It's been a while. I hope this works in your favor, whatever that means.

No matter how long you worked at the acquiree and instrumental you were, be prepared for your opinions to be overridden by IBM lifers because you're not "true blue" (ie. directly to IBM). Also prepare for the bluewashing!

Just wanted to say thanks for your work on Nomad. Amazing tool that had me rethink a lot of things about how i work with infra and software in general and is always pleasant to work with by itself.

Thanks! I think this is a really insightful comment because Nomad is more opinionated than I think we let on. The subtle interactions between signals, service discovery, health checks, templates, etc. all have a big impact on the reliability of the system as a whole. I've always wanted to do a "HashiCorp Validated Nomad App Design" kind of doc to outline these best practices, but it's always proved too big of a lift. Maybe now is the time!

As good of a time as ever. Feels like it would be a good read.

There are no resources and opportunities after being acquired by IBM. I worked for Red Hat when they were acquired. Our former CEO was quickly shown the door. We were making so much profit, almost a $1B in quarterly revenue. I left not long after the acquisition. Not long after I left, they laid off a bunch of staff.

No matter what they tell you, your day to day will not improve. For my area, it was mostly business as usual, but a net decrease in comp because IBM's ESPP is trash.

if you left right after the acquisition how can you even speak to what the experience has been?

It was within a year, not like the day after.

I have found the experience very different than what the OP's experience is.

As you know the layoffs that happened were around the same time as the rest of the industry layoffs were happening (fashion firing), I don't feel like it had a significant effect on the culture.

I am fully remote though, and have been for 15 years.

What part of my experience did you find different than your own? I said the day to day was mostly the same, minus the decrease in comp. I mostly was trying to articulate that the idea that IBM is going to 'super power' Hashicorp is not real, despite what IBM says.

A lot of what was communicated during the acquisition process was how IBM was going to super power Red Hat and help Red Hat grow into an even larger entity, and how Red Hat actually need IBM to survive.

> There are no resources and opportunities after being acquired by IBM.

Got promoted twice, once between teams. Went to multiple countries and I was in product security (cost center ) at the time.

> No matter what they tell you, your day to day will not improve.

I am down to a 40 hour work week, down from 50-60.

> Not long after I left, they laid off a bunch of staff.

I don't see any difference, corporate has laid off many different groups, I guess the only different to the mothership laid off people in the US so it hits closer to your home. I've seen layoffs in Support in phillipines, Documentation in Brisbane, Most of Singapore GLS/GPS.

The USA has always been insulated from the layoffs because execs find it harder to lay off people you meet in the corridors.

> A lot of what was communicated during the

> acquisition process was how IBM was going to super

> power Red Hat and help Red Hat grow into an even

> larger entity, and how Red Hat actually need IBM to

> survive.

Maybe this was in the US, most of the IBM briefing/cheerleading meetings were not held during the APAC timezone so I skipped them and prioritized high value work. I have always assumed that if I needed to know something my manager would tell me.

If i was getting let go, nothing I could do about it if I was already doing the work I was supposed to be doing.

I was at a certain open source company IBM acquired, and it was certainly an interesting experience. I certainly don't harbor any overtly negative feelings towards IBM. I used to have negative feelings about IBM many years ago, as a customer in my former life as a sysadmin, many decades ago. However being under the IBM umbrellas was alright. Yall are going to be fine!

The Nomad team is a big reason why I am using it and I am sad to see you go.

> I am sad to see you go.

I'm not going anywhere! My grammar isn't always the best, so I apologize for the confusion.

Reply on news.ycombinator.com