Live data from Hacker News

Chef to be acquired by Progress

blog.chef.io

61–70 of 146 posts

Re: Chef to be acquired by Progress

#61
post #38

It's confirmed then. Absolutely nobody wants to buy Puppet. Anyone know why that fell through?

From my viewpoint, Puppet's portfolio is comprised of mostly half-baked stuff. You have Puppet itself, which is decent, and then an almost Google-level of weird stuff. They keep announcing new products but so far nothing seems to be sticking and they're all ludicrously expensive IMHO. Meanwhile, their core technology is kind of a dead end. More and more people are looking to manage containers and other serverless typ…

Being a Portland techie, I pay a tiny bit of attention to Puppet and I’d say I agree with your comment re: product portfolio, until about a year ago. They have actually killed off a number of things in recognition of this critique and are trying to bring back focus on a sane portfolio strategy.

Re: Chef to be acquired by Progress

#62

What is the product offering of Progress? Quickly went through the website.. not sure, but it sounds more like smoke and mirrors..

Disclaimer: I cut my teeth on Progress 4GL back in the 80's, which is now called OpenEdge. It tickles me to see them still around, and to have bought Chef? Well, that's just sugar. Basically, they're a business apps technology provider, and have been around since 1981, providing app development tools for enterprise scale applications. Progress 4GL was a database-backed application environment, quite widely used (albe…

> but actually their tooling is pretty awesome

huh. That's not been my experience. To me, it looks like they stopped improving things circa 2005. Things that are new tend to be half-baked (.NET integration, OOP language features). No command line compiler (although you can write one yourself and a java-based community project exists), no linting or other static analysis tools. Their IDE is eclipse-based and frequently crashes when working with GUI for .NET. The autocomplete and in-IDE documentation that it provides is terrible- missing methods, not context aware, etc. They have a docker image, but only for their app-server product. I'm currently building a REST API using their app server product and I keep running into stumbling blocks. I've built similar APIs in PHP and Python and those were (largely) easy- I could focus on the problem and not the tooling. Here, I keep stumbling over things that work differently than anywhere else or that aren't well documented at all.

Their earlier stuff is quite impressive when you judge it by the time. They just seem to have fossilized.

Re: Chef to be acquired by Progress

#63

It's confirmed then. Absolutely nobody wants to buy Puppet. Anyone know why that fell through?

They made some serious missteps imho re: strategy. releasing and then not marketing razor server when everyone was shifting to VMs, halting development of the open source dashboard, not really investing in containerized environments, kubernetes, etc.

Halting development of the open source dashboard really hurt me, so I setup my own little alternative:

https://github.com/skx/puppet-summary/

Simple to deploy, configure, and use. Although I always felt I should perhaps have based my work against the puppetdb to get a more dynamic "dashboard" it certainly replaced the old dashboard, and being only a single binary it is simple to install & manage.

Re: Chef to be acquired by Progress

#64

What's a good alternative to Chef?

There's pyinfra ( https://pyinfra.com , full disclosure: I built it). Ansible, Salt have been mentioned already. Also CFEngine and Rudder might be worth a look.

CFEngine never really seemed to recover from the 2.x to 3.x migration. I know that's around the point I switched my fleet from CFEngine to Puppet.

I toyed with a simple puppet-alike, written in golang, called marionette (in hindsight a terrible name):

https://github.com/skx/marionette/

It isn't anywhere near as complex, or featureful, but starting with golden AMIs it allows the necessary changes that I need in a consistent fashion.

Re: Chef to be acquired by Progress

#65

What's a good alternative to Chef?

A lot of recommendations for Salt here, but wanted to point out they have had a pretty poor track record of security vulnerabilities. Something to keep in mind when evaluating alternatives.

https://www.cvedetails.com/vulnerability-list/vendor_id-1294...

https://news.ycombinator.com/item?id=23078421

Re: Chef to be acquired by Progress

#66

Earlier quoted context omitted.

My organization is actually moving away from Telerik after ten years of use. My biggest complaint is how unresponsive they are to fixing bugs. After reported it may be months or a year before you see it fixed. What I dont know is if that is common in that "ui component" sector?

> What I dont know is if that is common in that "ui component" sector? I think this is why almost nobody uses closed-source libraries. Having to pay isn't the biggest problem: it's not being able to fix issues like these yourself.

This 100%. Earlier in my career I managed a bunch of VB developers and we used a number of commercial UI components. Without exception they were a nightmare to deal with.

Re: Chef to be acquired by Progress

#67
post #42

Earlier quoted context omitted.

Ditto this. I was a ASP/VB-then-.Net developer 20 years ago and happened upon Progress 4GL when I had to create apps either communicating with or extracting data from Progress sources. My only beef was the horrifically quirky ODBC driver (and the convoluted SQL Server DTS packages & openqueries that resulted) -- 4GL was rock solid on AIX, and also on CentOS/RHEL once we moved away from AS400... and this was for high…

My job for years was developing and supporting Progress applications mainly on AIX. So much less crap to deal with than is common today. Things actually worked .

My experience with AIX as a sysadmin ca 2005 was dramatically different.

Things "worked", but everything was OLD. CLI tools had bugs and warts that GNU figured out decades previously.

I remember having to use obnoxious workarounds when tooling broke because 'find' wouldn't even work properly once you exceeded a certain number of files. (Several thousand, IIRC)

And that curses-based wrapper for doing administration tasks... glad I forgot the name of it, to be honest.

Re: Chef to be acquired by Progress

#68
post #38

It's confirmed then. Absolutely nobody wants to buy Puppet. Anyone know why that fell through?

From my viewpoint, Puppet's portfolio is comprised of mostly half-baked stuff. You have Puppet itself, which is decent, and then an almost Google-level of weird stuff. They keep announcing new products but so far nothing seems to be sticking and they're all ludicrously expensive IMHO. Meanwhile, their core technology is kind of a dead end. More and more people are looking to manage containers and other serverless typ…

Puppet is a great tool for managing containers, and so is Chef. There is nothing inherently good about YAML.

There is less buzz around those tools now however, and people tend to gravitate to other tools which are easier to get started with.

They may end up "silent heroes" (much like Ruby itself, I would say) or they may end up replaced by other tools. The concept of state as text in version control is a timeless concept and continue to exist in one form or another.

One of the problems with configurations management systems is that they are conceptually easy, everyone has opinions of them, and they really need to control your whole world in order to shine. There was never really room for one clear standard to emerge.

Puppet Inc.'s problem was that they kept chasing shiny stuff (agentless you say? we have that too!) in order to woo enterprise customers. Their customers should have been developers and sysadmins, not their bosses. There is only room for so many VMware in the world.

Re: Chef to be acquired by Progress

#69

What's a good alternative to Chef?

The alternative is ansible. Everybody I know moved away from Chef to Ansible and never looked back. Historically there were 4 main configuration management tools: puppet/chef/ansible/salt. The first two faded away. They're unarguably not the most usable and require to program in ruby. The next generation ansible/salt came out and arguably did better on every aspect. I think it's fair to say that ansible is the safe s…

Some people still like promise theory and the execution model behind chef and puppet.

I don't want to orchestrate against hundreds of systems with SSH and tell them what to do. I'd rather tell them what I want, and let them sort it out locally.

Re: Chef to be acquired by Progress

#70
post #34

I know nothing of Progress. Are they OSS friendly? I'd hate to see some of the OSS chef-managed tools die on the vine because of this.

No, they are not.

They might claim though - as in the link below - that this is because their products are too niche to support quality input from open source. Make of that what you will.

https://www.progress.com/tutorials/odbc/open-source-database

Post reply on HN