There is the largely feature compatible muon¹ re-implementation that doesn't require Python, it is packaged in a few distributions too. As in all things of this nature there are some caveats².
It is actually pretty useful to have installed alongside meson, even if just for access to the manpages as documentation.
The audio player is unfortunately not on GitHub yet, I've still got a few kinks to work out before it's in a shareable state. The statusbar project was also shared mostly so the other Nimdow users could play around with it, so the code quality is quite sub-par.
Just to muddy the waters some more there was also an EC variant¹ of the 030 without the MMU.
The EC variant was available right through to the 060, and I'd be curious to know how prevalent the line was. I suspect the EC versions far outnumbered the "full" chips, because they appeared in all kinds of industrial systems. I'm basing that entirely on working for a company that was still shipping products with MMU-less 68k and coldfire this century, not any real data.
And there's more mud to be found! The 'EC' version of the 68040 & 68060 was "no MMU, no FPU", and there was an 'LC' variant of the 68040 & 68060 that was "MMU, no FPU".
There were huge numbers of embedded 68k family chips shipped, although I've never seen the actual numbers. Folks went from 68000 to 68ec020 to 68ec060 as a (sorta) easy upgrade path. They're still made if you count the 68sec000, and the 68300 line is the spiritual successor.
That is the situation that lead to me to wireproxy; I had a need to use Cloudflare Warp, and no desire to entrust their apt repository with updates to my system.
Added to that their official client has heaps of functionality I have no use for, and wireproxy does everything I want for this usecase with a comparatively tiny amount of code(5MB vs 400MB built). I started the evening with a wg-quick generated config that required root, and ended it using a simple unprivileged daemon that I can toggle easily.
Sutter's 2022 cppcon talk¹ is a great introduction to the topic, both the problems it attempts to solve and solutions it was/is settling on. One of those few talks that left me genuinely enthused about the topic.
[It is probably worth watching for the Compiler Explorer interjection toward the end alone -- Matt Godbolt Appreciation Society]
I always enjoy these side diversions, because they're full of "Huh, WTFs". In English I'd never heard anyone call it anything but "a stitch"¹ colloquially or ETAP as an actual condition, but sure enough side ache features in the list of alternatives on Wikipedia.
Oddly, Wiktionary has an article for sideache² and a link to that page if you look for side stitch. Makes me curious how often that is the case now. [/me sniped]
Marmite has an XO version¹, which is aged for a month instead of a couple of days. Not sure I want to try ten year old mitey, but you're here to tell the tale so it must be okay ;)
Why on earth is there a dancing jar of marmite taking up the bottom right sixth of the screen, and how do I get rid of it?
I'm interested in what aging means here. Presumably it is different to just 'having it in a jar in the cupboard' because then all jars are aged in the supermarket for a few weeks or more. Looks like I've got my afternoon wikipedia rabbit hole sorted.
The 2.99.18 release received a lot of commentary a few weeks ago, although a fair chunk of it was the predictable rehash of every gimp comment section.
"Modern Unix systems offer named pipes, also known as fifos, which can be used to hand-craft arbitrary process communication topologies. However, if combined one-to-many and many-to-one piping are setup by using named pipes, another problem will occur. Due to the limited buffering offered by typical programs, deadlocks can easily occur when a process consuming data from many producers with more than one input, blocks waiting for input from one of the processes feeding it. This can cause a second feeding process to block, waiting to send its output to another one of the consumer process’s inputs, and, thereby, blocking the upstream process feeding both processes that provide data to the consumer one."
dspinellis has commented on another dgsh discussion¹(along with you). Interestingly, with a light comparison to pipexec².
I stumbled upon pipexec trying to find a battle tested solution to extend a data munging task where I was relying on zsh's multios³, mostly because orchestrating the interactions with a coproc'd jq for output were fighting me. There is something both frustrating and soothing about finding a seven year old comment pointing out why my path was doomed before I'd even started; people have solved the problem already, plus people far smarter than me also found the trap.
We could do something like dgsh, but so far I haven't seen a lot of uptake / demand. Every time it's mentioned, somebody kinda wants it, and then it kinda peters out again ... still possible though.
I think flat files work fine for a lot of use cases, and once you add streaming, you also want monitoring, more control over backpressure/queue sizes, etc.
I use mutlios and even I'm not that attached to it. The majority of my use is combined with process substitution, and could be replaced with common-ish tools like pee¹(or pipexec for more complex cases). The only occasion when I'm thankful for it is if I want to use a shell function as a target, but there are workarounds for that too.
As a noclobber user the footgun is largely hidden to me, but I feel its presence. multios without globbing support would be less useful, but would still work for most of my use cases. Scanning my shell history I see various cases of relying on zsh's ability to apply sorting and filtering to globs with multios' input redirection, but only a couple where I want that in output redirection. The input instances could easily be rewritten using cat and globbing.
Even with multios unset the behaviour is different between zsh and bash. For example, nomultios disables all the expansion, so zsh behaves like more like dash with ': >t{1,2}' creating a file instead producing an error like bash does.
[FWIW, I google'd multiios to link the option in mt original comment. It really feels like it needs double-i, and I read the single i name the same way you do.]
---
I'd be one of those people whose desire for dgsh-like functionality wanes. If it was slight DSL that I could "upgrade" pipelines to I'd probably use it, but not enough to warrant working on it or switching other tooling to support it.
The end of result of this morning's pipeline was breaking my jobs up, and applying some judicious use of nq² to keep track of it. I'd follow your advice and move on to more specialist tools if the job grew significantly or if it became a regular occurrence.
For people -- admittedly, like me -- who have a strong knee-jerk reaction to GoboLinux's design the twenty year old "I am not clueless"¹ document contains a fair amount of interesting background and reasoning on the concepts. I don't think I've overcome the reaction entirely, but it isn't so strong anymore ;)
The writing has some of the same feel as the writing for HTMX or Tailwind.
Paraphrasing: "Yes we know this is different. Yes it is very simple. You may not be used to it, but it is easier to understand and work with. You don't have to use this. We like this and we are happy."
I can't help but wonder how much of the kneejerk reaction is due to "cosmetic" parts of the design rather than the functional parts. For example, I notice that a lot of my initial reaction is based on the capitalization; "Programs" with a capital "P" (probably unfairly) evokes an emotional response due to reminding me of the Windows "Program Files" naming, and (perhaps slightly more fairly) I'd probably find it mildly infuriating to type "LibX11" rather than "libx11". Even though Linux filesystems are generally case insensitive, I imagine that package names would still be unique across casing, and it seems pretty likely that a Linux distribution focused on making the filesystem hierarchy more user-friendly wouldn't end up putting a second directory on the root that differs only by case. As silly as it is to verbalize, I genuinely think my initial reaction would be less strong if the naming convention examples were "/packages/libx11/1.6.9" and "/packages/gcc/9.2.0", and I don't think the benefits would be diminished at all by naming things like this.
It is actually pretty useful to have installed alongside meson, even if just for access to the manpages as documentation.
¹ https://git.sr.ht/~lattis/muon
² https://muon.build/releases/edge/docs/status.html