Live data from Hacker News

IBM completes acquisition of HashiCorp

newsroom.ibm.com

281–290 of 407 posts

Re: IBM completes acquisition of HashiCorp

#281

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

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.

Re: IBM completes acquisition of HashiCorp

#282

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

The Google Cloud Terraform provider includes, on Cloud SQL instances, an argument "deletion_protection" that defaults to true. It will make the provider fail to apply any change that would destroy that instance without first applying a change to set that argument to false.

That's what I expected lifecycle.prevent_destroy to do when I first saw it, but indeed it does not.

Re: IBM completes acquisition of HashiCorp

#283
post #196

Earlier quoted context omitted.

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

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

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.

Re: IBM completes acquisition of HashiCorp

#284

Earlier quoted context omitted.

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

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

Re: IBM completes acquisition of HashiCorp

#285
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…

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.

Re: IBM completes acquisition of HashiCorp

#286

Earlier quoted context omitted.

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.

Re: IBM completes acquisition of HashiCorp

#287
post #159

Earlier quoted context omitted.

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

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.

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

Re: IBM completes acquisition of HashiCorp

#288

Earlier quoted context omitted.

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?

Re: IBM completes acquisition of HashiCorp

#289
post #248

Earlier quoted context omitted.

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.

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

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.

Re: IBM completes acquisition of HashiCorp

#290

Earlier quoted context omitted.

I'm not familiar with every lifecycle argument but I don't know of any that prevent resources being destroyed if they are removed from the tf file (what the parent was talking about). prevent_destroy, per docs, only applies as long as the resource is defined. I think the only way to avoid accidentally destroying a resource is to refer to it somewhere else, like in a depends_on array. At least that would block the pla…

>I don't know of any that prevent resources being destroyed if they are removed from the tf file (what the parent was talking about). Azure Locks (which you can also manage with Terraform), Open Policy Agent, Sentinel rules, etc. will prevent a destroy even if you remove the definition from your Terraform codebase. Again, if you're not operationally mature enough, the problem isn't the tool, it's you.

[deleted]
Post reply on HN