From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 4799224A5F for ; Mon, 13 May 2024 04:57:33 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 92F1A4367C; Mon, 13 May 2024 12:57:28 +1000 (AEST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by minnie.tuhs.org (Postfix) with ESMTPS id 03A1C4367C for ; Mon, 13 May 2024 12:57:21 +1000 (AEST) Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a599a298990so930057766b.2 for ; Sun, 12 May 2024 19:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1715569039; x=1716173839; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wsN3Q/Pvdgyxn7NP0LdNJmBhiaBxn2eKx/Q6uiMNUcU=; b=Ay5k5KQquzP5LERVwo24fwCGOsxHfBPVnr6bBEMqZ3ckG23lZDZ/TJ8LMogZWd8CWF 4iILfxB7BqXcbEoYrs3AnmQgKKaACnNoR22PoB8Vo0bfSDtNZsDnQ+/q+m/r5gywbPs3 HLv2+0MgBXlBAbg9gfe3o7FDNKRtK/ySO09uGXQsanDSQrZFP3ksOpvbdexqrH5hfElz pq6cv72ioUWJl/TBYSzYDKfxBPfwJC8EmRGUKYRlQUtQYxgCFGpV17xSoiedBWWeyUuo YLMH0XMrM4CWKjLUyLr0xPHfr+l67cahwuw1kl/dJrAuRakyjYdYpoT8ZIL2DtKw5qqK kbdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715569039; x=1716173839; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wsN3Q/Pvdgyxn7NP0LdNJmBhiaBxn2eKx/Q6uiMNUcU=; b=n+F52l+FE6QiHnTqLg1BIXhNJhTaG/+z+g9czm2FKnUXbBH3y5XZdqd7Gk58wz9OLJ iqf4Rzp7IZA5+nVxK74931WGiMZ2oY8U8zYo6kGWCyfwIpe1KxFw4sgu6z/4k/eXRhB7 b3maGqGPuXA5wiioXrThSnHh80aF2x5LvJ7HHxlxirYVntfTGy+vZ2indGqS6tyJvOCh MUYQWwfKb8qXoWS0JgP+A6JGLDBMfBFJY+mODpBJHGd+FlLU6Km36Wa98DCwN7r3ilYW w0jIK2/K1lRXl3KfrjdMrCE+rteyzyJz5sQFjJIoOSpbqSem8xze3VVxIVxnqXdZAoRc U7yg== X-Gm-Message-State: AOJu0YwpJX4gEQW7CNrQHtZPkTsAitlcfvJ/2EnzCqftuACA5T0qWEMD VHaamE1dlXspGMxYF9vlPPpIl3mbYa9EgWtr7R91+Pyfnik1y6CfiH5jErdbhwnmfxcUTnIneTw sRo5+tN07eBuCa+uUfsbW+IlwYTBHHYsg5k092sPgcMh6wXf6 X-Google-Smtp-Source: AGHT+IGP6y/0Oq60S/rSHttAX5bCSljJJpitPgRavk/f26g8bgKEeTB8qRIB/pPYctv75z9AZr49nqFNMoxoG8e654c= X-Received: by 2002:a17:906:3bd1:b0:a55:a072:1ab8 with SMTP id a640c23a62f3a-a5a2d55e3damr554374366b.27.1715569038551; Sun, 12 May 2024 19:57:18 -0700 (PDT) MIME-Version: 1.0 References: <20240511213532.GB8330@mit.edu> <87y18ebfu4.fsf@gmail.com> In-Reply-To: <87y18ebfu4.fsf@gmail.com> From: Warner Losh Date: Sun, 12 May 2024 20:57:05 -0600 Message-ID: To: Alexis Content-Type: multipart/alternative; boundary="00000000000021860106184d0b85" Message-ID-Hash: HXA3OF57GRG7IIPBQWRB5I4KR5M5GYM6 X-Message-ID-Hash: HXA3OF57GRG7IIPBQWRB5I4KR5M5GYM6 X-MailFrom: wlosh@bsdimp.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Unix Heritage Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: [COFF] Re: On Bloat and the Idea of Small Specialized Tools List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000021860106184d0b85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 12, 2024, 8:34=E2=80=AFPM Alexis wrote: > > > On Sat, May 11, 2024 at 2:35=E2=80=AFPM Theodore Ts'o > > 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 =E2=80=94 on the command line, STDIN, STDOUT, STDERR =E2= =80=94 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=C3=A9. 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. > --00000000000021860106184d0b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 12, 2024, 8:34=E2=80=AFPM Alexis <flexibeast@gmail.com> wrote:
<= /div>

> On Sat, May 11, 2024 at 2:35=E2=80=AFPM Theodore Ts'o <tytso@mit.ed= u>
> 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 ti= ming 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 ma= ny 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&#= 39;. Plus MI data representations for almost everything so only the driver = reader thread cared about the hw. See also tty abstraction or ifnet abstrac= tion in unix....

So actu= ally not a set of FDs passing data between process, but threads doing the s= ame sort of thing.

The w= hole 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 create= d 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 doz= en attempts to closely broker fork/exec dance proved... unreliable.=C2=A0

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 =E2=80=94 on the command line, STDIN, STDOUT, STDERR = =E2=80=94 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=C3=A9. Sure, regexes can, and do, get used where they shouldn't <= br> 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.
--00000000000021860106184d0b85--