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…
Chef to be acquired by Progress
61–70 of 146 posts
Re: Chef to be acquired by Progress
#62What 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…
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
#63It'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.
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
#64What'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.
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
#65What's a good alternative to Chef?
https://www.cvedetails.com/vulnerability-list/vendor_id-1294...
Re: Chef to be acquired by Progress
#66Earlier 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.
Re: Chef to be acquired by Progress
#67Earlier 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 .
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
#68It'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…
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
#69What'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…
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
#70I 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.
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