On Sun, May 12, 2024, 8:34 PM Alexis <flexibeast@gmail.com> wrote:

>
> > On Sat, May 11, 2024 at 2:35 PM Theodore Ts'o <tytso@mit.edu>
> > wrote:
> >
> > So while some of us old farts might be bemoaning the death of
> > the
> > Unix
> > philosophy, perhaps part of the reality is that the Unix
> > philosophy
> > were ideal for a simpler time, but might not be as good of a fit
> > today
>
> Hm .... i guess it might depend on the specific use-case(s)
> involved?
>

I created, years ago, a set of time legos. They were connected as a network
of producer / consumer interfaces. Each lego would do one thing and pass
the results to the next thing in the chain. A driver would read timing data
from the driver and convert it to a MI interface. Different other legos
would take time differences, compute phase or frequency differences and
these would feed into more sophisticated algorithms or output etc. All
locking was on yhe pipe's queues so all these algorithms were lock free
apart from the queueing or dequeueing of data.

Concrptually, this is just a bunch of pipe, with many to 1 or 1 to many
added. Each lego did one thing and passed the results along to the thing in
the chain... much like 'cmd | grep | awk | more'. Plus MI data
representations for almost everything so only the driver reader thread
cared about the hw. See also tty abstraction or ifnet abstraction in
unix....

So actually not a set of FDs passing data between process, but threads
doing the same sort of thing.

The whole data filtering paradigm works in lots of different ways. And it
still works really well by analogy.

Warner

ObComplaint: fork sucks for address spaces with 100s of threads. Forst
thing we created a child process we used to broker different threads
needing to run popen or system... having a create process / munge process /
start process API is kinda what we did behind the scenes though with "send
this data" and "receive that data". We iterated to this after the first
dozen attempts to closely broker fork/exec dance proved... unreliable.

At one point i realised that a primary reason i enjoy using *n*x
> systems is that they're fundamentally
> _text-oriented_. (Unsurprisingly, of course, given the context in
> which Unix was developed.) i spend a lot of my time interacting
> and working with text, and *n*x systems provide me with many
> useful tools for this. Quoting the old "UNIX As Literature" piece,
> https://theody.net/elements.html:
>
> "[T]he most recurrent complaint was that [Unix] was too
> text-oriented. People really hated the command line, with all the
> utilities, obscure flags, and arguments they had to memorize. They
> hated all the typing. One mislaid character and you had to start
> over. Interestingly, this complaint came most often from users of
> the GUI-laden Macintosh or Windows platforms. ...
>
> "[A] suspiciously high proportion of my UNIX colleagues had
> already developed, in some prior career, a comfort and fluency
> with text and printed words. ...
>
> "With UNIX, text — on the command line, STDIN, STDOUT, STDERR — is
> the primary interface mechanism: UNIX system utilities are a sort
> of Lego construction set for word-smiths. Pipes and filters
> connect one utility to the next, text flows invisibly
> between. Working with a shell, awk/lex derivatives, or the utility
> set is literally a word dance."
>
> Perl, with its pervasive regex-based functionality and extensive
> Unicode support, fits neatly into this. i find regexes an
> _incredibly_ powerful tool for working with text, whether via
> Perl, sed, awk, or whatever. But my experience is that many people
> treat regexes as an anathema, with Zawinski's "Now you have two
> problems" regularly trotted out as a thought-terminating
> cliché. Sure, regexes can, and do, get used where they shouldn't
> be[a]; that doesn't mean the baby should be thrown out with the
> bathwater.
>
> But if one is only working with text under sufferance, trying to
> avoid it via substantially more graphically-oriented environments,
> the text-based "Unix philosophy" and the tools associated with it
> might feel (and actually be) much less appropriate and
> useful. Fair enough. The Unix construction set will still be there
> for those of us who find them very appropriate and tremendously
> useful.
>
>
> Alexis.
>
> [a] It seems unlikely that anyone on this list hasn't already seen
> this, but just in case:
>
>
> https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags/1732454#1732454
>
> i'm looking forward to that comment sending OpenAI over the
> Mountains of Madness.
>