My biggest concern would be lock-in to the license, not lock-in to an old Python version. The nominal cost to get up-to-date right now doesn't guarantee me perpetual updates, right?
I'm also suspect of the misleading presentation on the landing page; nothing in the "Open Source" section says anything about the fact that the author has resolved to let the Open Source version effectively die, while up-selling existing users to the paid version. I respect the approach, and you deserve to be payed for the work, but it would be good to not effectively lie on the home page.
The resolution does mention there will be documentation on switching to sysv after an installation, so I assume this option will have to be officially supported; it sounds to me as though systemd is simply a default, not a requirement.
I find it telling that the recommendations for mitigating these sorts of vulnerabilities include adding some slop to the end of allocations (which I believe will only prove to make off-by-one errors "acceptable" when they are clearly still incorrect; perhaps we will see off-by-two error now…) and introducing more randomization to allocations.
This second point I find particularly insidious because the very essense of this paper is that other attempts at randomization (e.g. ASLR) have been found wanting: as long as overflow is feasible there will be creative ways to access the instruction counter.
I wonder how much performance would degrade if a language with a similar runtime to C but with bounds checking (e.g. Ada or Rust) were used to write this sort of software. It seems like the only reasonable way to completely prevent these exploits, and I suspect profiling would reveal there are still hot-spots where selective optimization could bring performance back on par (if it is not already).
The fish[1] shell also has process substitution (without requiring additional syntax) in the form of psub (which is implemented simply as a fish function; see `type psub` from a fish shell):
Well put! Rust shines in that these sorts of abstractions (channels being just one example) which must be builtin in other languages can be expressed as library types in Rust. It is a distinct strength, not a weakness as this article seems to imply.
I'm also suspect of the misleading presentation on the landing page; nothing in the "Open Source" section says anything about the fact that the author has resolved to let the Open Source version effectively die, while up-selling existing users to the paid version. I respect the approach, and you deserve to be payed for the work, but it would be good to not effectively lie on the home page.