Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IBM completes acquisition of HashiCorp

newsroom.ibm.com

Post reply on HN
Print view View original

301–310 of 407 posts

Re: IBM completes acquisition of HashiCorp

#301

Post by linuxftw »

worthless-trash wrote: post #184
zzzeek wrote: post #134

Earlier quoted context omitted.

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

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.

Re: IBM completes acquisition of HashiCorp

#303

Post by linuxftw »

goodoldneon wrote: post #101
JohnMakin wrote: post #77

Earlier quoted context omitted.

> For Terraform (at least a few years ago) a badly reviewed PR could cause catastrophic data loss because resources are deleted without requiring an explicit tombstone. There have been lifecycle rules in place for as long as I can remember to prevent stuff like this. I'm not sure this is a "problem" unique to terraform.

IIRC, the lifecycle hook only prevents destruction of the resource if it needs to be replaced (e.g. change an immutable field). If you outright delete the resource declaration in code then it’s destroyed. I may be misremembering though

I find this statement to be technically correct, but practically untrue. Having worked in large terraform deployments using TFE, it's very easy for a resource to get deleted by mistake.

Terraform's provider model is fundamentally broken. You cannot spin up a k8s server and then subsequently use the k8s modules to configure the server in the same workspace. You need a different workspace to import the outputs. The net result was we had like 5 workspaces which really should have been one or two.

A seemingly inconsequential change in one of the predecessor workspaces could absolutely wreck the later resources in the latter workspaces.

It's very easy in such a scenario to trigger a delete and replace, and for larger changes, you have to inspect the plan very, very carefully. The other pain point was I found most of my colleagues going "IDK, this is what worked in non-prod" whilst plans were actively destroying and recreating things, as long as the plan looked like it would execute and create whatever little thing they were working on, the downstream consequences didn't matter (I realize this is not a shortcoming of the tool itself).

Re: IBM completes acquisition of HashiCorp

#304

Post by bonzini »

bayindirh wrote: post #284
bonzini wrote: post #278

Earlier quoted context omitted.

> 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 b…

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

Re: IBM completes acquisition of HashiCorp

#305

Post by richardfontana »

dralley wrote: post #194
cpitman wrote: post #185

Earlier quoted context omitted.

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…

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

Re: IBM completes acquisition of HashiCorp

#306

Post by jonathanspw »

bayindirh wrote: post #284
bonzini wrote: post #278

Earlier quoted context omitted.

> 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 b…

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.

Re: IBM completes acquisition of HashiCorp

#307

Post by PaulRobinson »

jerlam wrote: post #230
nayuki wrote: post #196

Earlier quoted context omitted.

> 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 inst…

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

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

Re: IBM completes acquisition of HashiCorp

#308

Post by ghaff »

bayindirh wrote: post #284
bonzini wrote: post #278

Earlier quoted context omitted.

> 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 b…

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.

Re: IBM completes acquisition of HashiCorp

#309

Post by bayindirh »

jonathanspw wrote: post #306
bayindirh wrote: post #284

Earlier quoted context omitted.

> 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 b…

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 h…

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.

Re: IBM completes acquisition of HashiCorp

#310

Post by jonathanspw »

bayindirh wrote: post #309
jonathanspw wrote: post #306

Earlier quoted context omitted.

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 h…

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

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.

Post reply on HN