jbbarth

How is the POSIX non compliance a major problem? Does it have practical impacts when writing scripts that are not meant to be portable to other systems/shells?

Wow thanks for the completeness of the answer.

I found myself nodding on all the conceptual limits and features you added, I'm sold, gonna try Cadence asap :)

The tooling around SWF (web console and ability to get insights about tasks, failures, etc.) is definitely a big one from an operational perspective. The SWF console is indeed absolutely terrible (with basic bugs not fixed for years, like broken pagination), so we ended up developing our own here at Botify, along with a python based client lib that mimics most of RubyFlow principles. I'm curious if all this can be integrated with Cadence, will have a look. I can keep you informed if you feel it's valuable for the Cadence project.

Cadence looks like an OSS version of Amazon Simple Workflow (SWF) service. The author used to work on SWF at AWS afaik.

I'm a heavy SWF user at work for managing complex data pipelines. SWF requires an important conceptual and tooling effort in the beginning, but it gets reimbursed if you use it a lot.

As for other comments mentioning Airflow: the programming model is quite different , since Airflow as far as I understand forces to provide a DAG of tasks upfront. SWF (and Cadence?) doesn't, it coordinates the work of Deciders and Activity Workers and only acts as a source of truth for the state of the workflow (+ distribute task in a unique manner to many long-polling workers). As a result you don't declare anything upfront and can have deciders take dynamic decisions along the way, which is really nice when you want very dynamic logic for your workflows (e.g. dynamic partitioning of tasks, decisions depending on external factors, etc.).

I'd love to have Maxim insights about how Cadence compares to SWF, and what would be the reasons/challenges behind migrating from SWF to Cadence for SWF users (except that SWF is basically stale for 4+ years and rigged with arbitrary limits)

Don't throw the baby out with the bathwater maybe? Here's a fixed version of your statement:

"The default Turbolinks progress bar that can be removed with one line of CSS gives the impression that things are slow on slow connections."

Turbolinks is not perfect and has some drawbacks, but it also makes things faster in 99% (100%?) cases in my experience for almost 0 development effort.

Unfortunately this workflow is pretty fragile and it will not protect you from any of pip locking shortcomings.

It will basically work only in favorable cases where you have no ambiguous choice, no conflict (A depends on B==1.2.3, C depends on B==2.3.4), no reinstall to consider (git VS non git deps for instance), ... Really pip-tools is not that bad for now, until pip itself moves toward industry standards by default (lock file, deps resolution, reliable version checks, ..)

It seems there's an assumption in the article and in the comments here that "more EVs == net positive impact on pollution / greenhouse gases". This is not obvious at all. It depends on the way you produce electricity, and when 75% of it comes from coal, you may end up worsening the problem. This could be a smart move if the automobile market had a bigger inertia than the energy one, but I doubt it's the case...

Patches from upstream are regularly backported by distribution vendors, including Redhat, Debian, Ubuntu (though I don't know if Ubuntu do this themselves or base on Debian). Anyway, looking at the version number is not enough, you should refer your vendor security advisories.

Context: working at a company heavily relying on AWS. Made a request for such credits yesterday.

It reflects their SLA policies and docs, no surprise here. My AWS sales contact confirmed there's no problem with such demands (and basically they won't waste your time asking for failing X-Request-Id's or deny there was a problem).

What will be more interesting is how they'll deal with credit demands on all the S3-dependent services that were down at the same time. My company AWS bill is only 20% of S3@us-east-1, so we were completely down for 4+ hours and can only claim for 2% of our previous bill (woohoo).

But if we add Cloudfront, part of EC2, SWF, etc. it can become a different story.

It's likely that with the feature set growing, a version that uses a slightly more advanced language would be easier to maintain and have less "traps" than the bash version...

I'd be happy to see your 10 lines bash version of this ruby tool, with the same options/properties (debug messages, customizable prompt, history logging, same safeguards, rlwrap support, man page).