> 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.