I convinced a software company to use a version control system (RCS on shared disk) back in 1993. To make it work we had to setup a network — Ethernet over (thin) coaxial cable at the time. This was so new to us that we didn't know we needed to use terminators on the two cable ends.

Indeed! The repo includes some v4 elements: https://github.com/dspinellis/unix-history-repo/tree/Researc...

The provided kernel predates the actual edition by a few months. It is based on https://www.tuhs.org/Archive/Distributions/Research/Dennis_v..., which matches V4 more than V3.

I don't think the concept of a rebase existed before Bitbucker and Git.

It wasn't called rebasing, but working on a shared branch and updating that branch while having local changes did the same thing.

30 years ago (1995) open source offerings: mostly CVS for large projects and RCS for smaller ones. On the proprietary side, the aged SCCS was available and used, while Perforce and Microsoft Visual Source Safe were being launched.

(Meanwhile, apparently MS itself continued using SLM, the in-house source-control system which had been commercialised as MS Delta, internally until about 2000. https://wiki.c2.com/?MicrosoftDelta https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97... https://ricomariani.medium.com/super-brief-notes-on-early-so... https://news.ycombinator.com/item?id=44255526 )

I published an updated extension of this post's linked article in Empirical Software Engineering. You can read it without a paywall at https://rdcu.be/b7FzE. You may also be interested to see the actual GitHub repository at https://github.com/dspinellis/unix-history-repo.

Right. The title of this submission should have a "(2015)".

A nicer syntax and a lower probability of deadlocks.

I'm curious: what do you mean by "dgsh will use iteration under the hood too"? Dgsh does several things under the hood, but I wouldn't characterize any of them as iteration.

Yes you’re right. My apologies. I was glancing at the examples while cooking, specifically the git example (https://www2.dmst.aueb.gr/dds/sw/dgsh/#commit-stats) thinking that it was iterating over the lines output from git, but clearly that’s not even how bash would work. That will teach me for commenting without giving something my full attention first doh!

Looking properly at this, I can see no iteration is needed. Which actually makes the Murex implementation even easier because Murex already has tee pipes just like dgsh. It’s just not (yet) particularly well documented.

Admiring your multi-tasking!

Haha thank you but it’s really not that good otherwise I’d have grokked the iteration thing before making a fool out of myself!

Manually playing around with fds is definitely unmaintainable. My hope is that a clean syntax can help create maintainable complex pipelines.

Nice benchmark! This is a (not at all efficient) awk one-liner.

awk -F\; ' $2 > max[$1] { max[$1] = $2 } !($1 in min) || $2 < min[$1] { min[$1] = $2 } { sum[$1] += $2; count[$1]++} END { for (n in sum) printf("%s=%.1f/%.1f/%.1f, ", n, min[n], sum[n] / count[n], max[n])}'

Can't see how dgsh could be applied to it.

I've found creating pipelines with Python to be messy and intuitive. Other than creating a DSL to express them I can't see how DAGs can be expressed naturally with Python's syntax.

Even creating tools in Python that can be connected together in a Unix shell pipeline isn't trivial. By default if a downstream program stops processing Python's output you get an unsightly broken pipe exception, so you need to execute signal.signal(signal.SIGPIPE, signal.SIG_DFL) to avoid this.