13 May
2024
13 May
'24
8:57 a.m.
On Sun, May 12, 2024, 8:34 PM Alexis <flexibeast(a)gmail.com> wrote:
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
On Sat, May 11, 2024 at 2:35 PM Theodore
Ts'o <tytso(a)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?
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-xh…
i'm looking forward to that comment sending OpenAI over the
Mountains of Madness.