From clemc at ccc.com Sat May 11 02:36:43 2024
From: clemc at ccc.com (Clem Cole)
Date: Fri, 10 May 2024 12:36:43 -0400
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
Message-ID: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
While the idea of small tools that do one job well is the core tenant of
what I think of as the UNIX philosophy, this goes a bit beyond UNIX, so I
have moved this discussion to COFF and BCCing TUHS for now.
The key is that not all "bloat" is the same (really)—or maybe one person's
bloat is another person's preference. That said, NIH leads to pure bloat
with little to recommend it, while multiple offerings are a choice. Maybe
the difference between the two may be one person's view over another.
On Fri, May 10, 2024 at 6:08 AM Rob Pike <robpike at gmail.com> wrote:
> Didn't recognize the command, looked it up. Sigh.
>
Like Rob -- this was a new one for me, too.
I looked, and it is on the SYS3 tape; see:
https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/man1/nl.1
> pr -tn <file>
>
> seems sufficient for me, but then that raises the question of your
> question.
>
Agreed, that has been burned into the ROMs in my fingers since the
mid-1970s 😀
BTW: SYS3 has pr(1) with both switches too (more in a minute)
> I've been developing a theory about how the existence of something leads
> to things being added to it that you didn't need at all and only thought of
> when the original thing was created.
>
That is a good point, and I generally agree with you.
> Bloat by example, if you will. I suspect it will not be a popular theory,
> however accurately it may describe the technological world.
>
Of course, sometimes the new features >>are<< easier (more natural *for
some people*). And herein lies the core problem. The bloat is often
repetitive, and I suggest that it is often implemented in the wrong place -
and usually for the wrong reasons.
Bloat comes about because somebody thinks they need some feature and
probably doesn't understand that it is already there or how they can use
it. But they do know about it, their tool must be set up to exploit it - so
they do not need to reinvent it. GUI-based tools are notorious for this
failure. Everyone seems to have a built-in (unique) editor, or a private
way to set up configuration options et al. But ... that walled garden is
comfortable for many users and >>can be<< useful sometimes.
Long ago, UNIX programmers learned that looking for $EDITOR in the
environment was way better than creating one. Configuration was as ASCII
text, stored in /etc for system-wide and dot files in the home for users.
But it also means the >>output<< of each tool needs to be usable by each
other [*i.e.*, docx or xlx files are a no-no).
For example, for many things on my Mac, I do use the GUI-based tools --
there is no doubt they are better integrated with the core Mac system >>for
some tasks.<< But only if I obey a set of rules Apple decrees. For
instance, this email read is easier much of the time than MH (or the HM
front end, for that matter), which I used for probably 25-30 years. But on
my Mac, I always have 4 or 5 iterm2(1) open running zsh(1) these days. And,
much of my typing (and everything I do as a programmer) is done in the shell
(including a simple text editor, not an 'IDE'). People who love IDEs swear
by them -- I'm just not impressed - there is nothing they do for me that
makes it easier, and I have learned yet another scheme.
That said, sadly, Apple is forcing me to learn yet another debugger since
none of the traditional UNIX-based ones still work on the M1-based systems.
But at least LLDB is in the same key as sdb/dbx/gdb *et al*., so it is a
PITA but not a huge thing as, in the end, LLDB is still based on the UNIX
idea of a single well-designed and specific to the task tool, to do each
job and can work with each other.
FWIW: I was recently a tad gob-smacked by the core idea of UNIX and its
tools, which I have taken for a fact since the 1970s.
It turns out that I've been helping with the PiDP-10 users (all of the
PiDPs are cool, BTW). Before I saw UNIX, I was paid to program a PDP-10. In
fact, my first UNIX job was helping move programs from the 10 to the UNIX.
Thus ... I had been thinking that doing a little PDP-10 hacking shouldn't
be too hard to dust off some of that old knowledge. While some of it has,
of course, come back. But daily, I am discovering small things that are so
natural with a few simple tools can be hard on those systems.
I am realizing (rediscovering) that the "build it into my tool" was the
norm in those days. So instead of a pr(1) command, there was a tool that
created output to the lineprinter. You give it a file, and it is its job to
figure out what to do with it, so it has its set of features (switches) -
so "bloat" is that each tool (like many current GUI tools) has private ways
of doing things. If the maker of tool X decided to support some idea, they
would do it like tool Y. The problem, of course, was that tools X and Y
had to 'know about' each type of file (in IBM terms, use its "access
method"). Yes, the engineers at DEC, in their wisdom, tried to
"standardize" those access methods/switches/features >>if you implemented
them<< -- but they are not all there.
This leads me back to the question Rob raises. Years ago, I got into an
argument with Dave Cutler RE: UNIX *vs.* VMS. Dave's #1 complaint about
UNIX in those days was that it was not "standardized." Every program was
different, and more to Dave's point, there was no attempt to make switches
or errors the same [getopt(3) had been introduced but was not being used by
most applications). He hated that tar/tp used "keys" and tools like cpio
used switches. Dave hated that I/O was so simple - in his world all user
programs should use his RMS access method of course [1]. VMS, TOPS, *etc.*,
tried to maintain a system-wide error scheme, and users could look things
like errors up in a system DB by error number, *etc*. Simply put, VMS is
very "top-down."
My point with Dave was that by being "bottom-up," the best ideas in UNIX
were able to rise. And yes, it did mean some rough edges and repeated
implementations of the same idea. But UNIX offered a choice, and while Rob
and I like and find: pr -tn perfectly acceptable thank you, clearly someone
else desired the features that nl provides. The folks that put together
System 3 offer both solutions and let the user choose.
This, of course, comes as bloat, but maybe that is a type of bloat so bad?
My own thinking is this - get things down to the basics and simplest
privatives and then build back up. It's okay to offer choices, as long as
the foundation is simple and clean. To me, bloat becomes an issue when you
do the same thing over and over again, particularly because you can not
utilize what is there already, the worst example is NIH - which happens way
more than it should.
I think the kind of bloat that GUI tools and TOPS et al. created forces
recreation, not reuse. But offering choice and the expense of multiple
tools that do the same things strikes me as reasonable/probably a good
thing.
1.] BTW: One of my favorite DEC stories WRT to VMS engineering has to do
with the RMS I/O system. Supporting C using VMS was a bit of PITA.
Eventually, the VMS engineers added Stream I/O - which simplified the C
runtime, but it was also made available for all technical languages.
Fairly soon after it was released, the DEC Marketing folks discovered
almost all new programs, regardless of language, had started to use Stream
I/O and many older programs were being rewritten by customers to use it. In
fact, inside of DEC itself, the languages group eventually rewrote things
like the FTN runtime to use streams, making it much smaller/easier to
maintain. My line in the old days: "It's not so bad that ever I/O has
offer 1000 options, it's that Dave to check each one for every I/O. It's a
classic example of how you can easily build RMS I/O out of stream-based
I/O, but the other way around is much harder. My point here is to *use
the right primitives*. RMS may have made it easier to build RDB, but it
impeded everything else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240510/4150acba/attachment-0001.htm>
From steffen at sdaoden.eu Sat May 11 09:02:17 2024
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 11 May 2024 01:02:17 +0200
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
Message-ID: <20240510230217.IRjT8OER@steffen%sdaoden.eu>
Clem Cole wrote in
<CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw at mail.gmail.com>:
|While the idea of small tools that do one job well is the core tenant of
|what I think of as the UNIX philosophy, this goes a bit beyond UNIX, so I
|have moved this discussion to COFF and BCCing TUHS for now.
|
|The key is that not all "bloat" is the same (really)—or maybe one person's
|bloat is another person's preference. That said, NIH leads to pure bloat
Yeah, give me back my "cat -vet"!
|with little to recommend it, while multiple offerings are a choice. Maybe
|the difference between the two may be one person's view over another.
Sure. Many of the small Unix tools are simply unknown to many
newcomers (like myself), or they turn out to be too simple, pr has
always been enscript here, for example. I wonder how many modern
Linux systems even ship the majority of these tools, or how often
they get invoked, if at all.
But deep in my heart i dislike the systemd that totally
contradicts the entire concept as such, and hope i can stick to my
fast and simple booting with SysV scripts, and separate daemons
for separate tasks.
...[dropped the top-posted stuff]
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From nliber at gmail.com Sat May 11 09:22:15 2024
From: nliber at gmail.com (Nevin Liber)
Date: Fri, 10 May 2024 18:22:15 -0500
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
Message-ID: <CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc at ccc.com> wrote:
> The key is that not all "bloat" is the same (really)—or maybe one person's
> bloat is another person's preference.
>
A lot of "bloat" comes because our systems really aren't focused on
"discoverability".
While I probably have used "pr" in the past, I've totally forgotten, the
name "pr" doesn't really help me understand what it is for, and it's just
one of 982 files in my /usr/bin directory alone. How does one discover it?
It's like using "sed" instead of "head": sure, if you already know "sed",
you don't need "head", but for English speaking folks who know "tail" is
there, it would be (and was in the old days) surprising and frustrating not
to have "head".
If I have a command and I want it to do something slightly different, the
first place I look is to see if there is a command line option for that. I
know how to discover that (either --help or the man pages).
GUIs were better at discoverability. The menu at the top made it easy to
see (and constantly reinforced) what was possible, at least until we got
into the era of contextual menus, gestures and force presses.
They aren't perfect. I get plenty of dialog boxes which have a check box
for "Do not show this message again" which I don't dare check, because I
don't know how to bring up whatever choice it wants me to decide on should
I need to change it in the future.
And once you have users/customers, it's hard to get rid of things, because
they value stability.
--
Nevin ":-)" Liber <mailto:nl <nevin at eviloverlord.com>iber at gmail.com>
+1-847-691-1404
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240510/43ab0d88/attachment.htm>
From ralph at inputplus.co.uk Sat May 11 19:18:22 2024
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 11 May 2024 10:18:22 +0100
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <20240510230217.IRjT8OER@steffen%sdaoden.eu>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<20240510230217.IRjT8OER@steffen%sdaoden.eu>
Message-ID: <20240511091822.B6691215AA@orac.inputplus.co.uk>
Hi Steffen,
> pr has always been enscript here, for example.
enscript turns text into PostScript. That's not too handy to read.
pr's output doesn't have to be sent to a printer. I doubt there's
a week goes by without my using it. It just depends what your fingers
know.
--
Cheers, Ralph.
From ralph at inputplus.co.uk Sat May 11 19:31:07 2024
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 11 May 2024 10:31:07 +0100
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
Message-ID: <20240511093107.EC94C215AA@orac.inputplus.co.uk>
Hi Nevin,
> the name "pr" doesn't really help me understand what it is for
As typical of the early commands, it's readily mnemonic.
PR(I) 3/20/74 PR(I)
NAME
pr - print file
SYNOPSIS
pr [-h header] [-n] [+n] [-wn] [-ln] [-t] [name...]
> How does one discover it?
Back then, by reading through the permuted index, turning the pages of
the printed manual, word of mouth... By making effort to learn the
profession's tools.
> If I have a command and I want it to do something slightly different,
> the first place I look is to see if there is a command line option for
> that. I know how to discover that (either --help or the man pages).
And a fine man page's SEE ALSO may help learn of new commands.
--
Cheers, Ralph.
From jpl.jpl at gmail.com Sat May 11 22:51:27 2024
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Sat, 11 May 2024 08:51:27 -0400
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
Message-ID: <CAC0cEp_wTKZ5B15g06fKAdaaK6_f3Jx=5N9=8dYftv4V13aWbg@mail.gmail.com>
Marc Rochkind used to advise reading the entire UNIX manual cover to cover
each year. The manual was short enough that it could be done in a day or
two. It was a great way to discover commands and system calls you didn't
use every day, and deepen your understanding of the ones you did use every
day. We were in a center that ran PWB UNIX, and the manual was overseen by
Ted Dolotta, who was a stickler for good writing. I can't imagine trying to
do something similar now. -- jpl
On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber at gmail.com> wrote:
> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc at ccc.com> wrote:
>
>> The key is that not all "bloat" is the same (really)—or maybe one
>> person's bloat is another person's preference.
>>
>
> A lot of "bloat" comes because our systems really aren't focused on
> "discoverability".
>
> While I probably have used "pr" in the past, I've totally forgotten, the
> name "pr" doesn't really help me understand what it is for, and it's just
> one of 982 files in my /usr/bin directory alone. How does one discover it?
>
> It's like using "sed" instead of "head": sure, if you already know "sed",
> you don't need "head", but for English speaking folks who know "tail" is
> there, it would be (and was in the old days) surprising and frustrating not
> to have "head".
>
> If I have a command and I want it to do something slightly different, the
> first place I look is to see if there is a command line option for that. I
> know how to discover that (either --help or the man pages).
>
> GUIs were better at discoverability. The menu at the top made it easy to
> see (and constantly reinforced) what was possible, at least until we got
> into the era of contextual menus, gestures and force presses.
>
> They aren't perfect. I get plenty of dialog boxes which have a check box
> for "Do not show this message again" which I don't dare check, because I
> don't know how to bring up whatever choice it wants me to decide on should
> I need to change it in the future.
>
>
> And once you have users/customers, it's hard to get rid of things, because
> they value stability.
> --
> Nevin ":-)" Liber <mailto:nl <nevin at eviloverlord.com>iber at gmail.com>
> +1-847-691-1404
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240511/a5def569/attachment-0001.htm>
From crossd at gmail.com Sat May 11 23:12:33 2024
From: crossd at gmail.com (Dan Cross)
Date: Sat, 11 May 2024 09:12:33 -0400
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
Message-ID: <CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber at gmail.com> wrote:
> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc at ccc.com> wrote:
>> The key is that not all "bloat" is the same (really)—or maybe one person's bloat is another person's preference.
>
> A lot of "bloat" comes because our systems really aren't focused on "discoverability".
>
> While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone. How does one discover it?
This is a fantastic question. At one point, I went through every
command in /bin and /usr/bin and figured out what it did. That was a
tremendously useful exercise, but that was in the days when the total
number of commands in those directories numbered in the low hundreds;
982 is a lot.
`pr` is an interesting case in point. I would guess that the name
comes from Multics, where `print` (short name `pr`) is sort of the
equivalent of `cat`, but contains a lot of extra functionality to
control output, read archives, etc. But if one has never used Multics
(and let's be honest: the total number of people in the world who have
done so is a tiny, tiny fraction of the number of computer users), one
would never guess that. When I started using Unix, I thought that "pr"
was how you sent a file to the printer; "lpr" was highly
non-intuitive, but I'd never seen a line printer at that point (our
first home computer was a Mac with an imagewriter); the idea of
`cat`ing a file into the printer device wasn't something I'd ever even
considered (besides, I think the device was owned and writable only as
root).
> It's like using "sed" instead of "head": sure, if you already know "sed", you don't need "head", but for English speaking folks who know "tail" is there, it would be (and was in the old days) surprising and frustrating not to have "head".
I don't know if this is an argument about bloat per se, but rather
about system design generally. Sure, `sed 10q` does more or less what
`head` does, but that's not a great argument for `head` not existing.
After all, assembler can do everything that C can, and yet given a
choice between the two, for most programs I'd prefer the latter.
> If I have a command and I want it to do something slightly different, the first place I look is to see if there is a command line option for that. I know how to discover that (either --help or the man pages).
>
> GUIs were better at discoverability. The menu at the top made it easy to see (and constantly reinforced) what was possible, at least until we got into the era of contextual menus, gestures and force presses.
>
> They aren't perfect. I get plenty of dialog boxes which have a check box for "Do not show this message again" which I don't dare check, because I don't know how to bring up whatever choice it wants me to decide on should I need to change it in the future.
>
> And once you have users/customers, it's hard to get rid of things, because they value stability.
Absolutely.
- Dan C.
From coff at tuhs.org Sun May 12 00:41:56 2024
From: coff at tuhs.org (Bakul Shah via COFF)
Date: Sat, 11 May 2024 07:41:56 -0700
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
Message-ID: <F3936873-25F9-4076-8C92-15AE07CB23CF@iitbombay.org>
On May 11, 2024, at 6:12 AM, Dan Cross <crossd at gmail.com> wrote:
>
> On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber at gmail.com> wrote:
>> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc at ccc.com> wrote:
>>> The key is that not all "bloat" is the same (really)—or maybe one person's bloat is another person's preference.
>>
>> A lot of "bloat" comes because our systems really aren't focused on "discoverability".
>>
>> While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone. How does one discover it?
>
> This is a fantastic question. At one point, I went through every
> command in /bin and /usr/bin and figured out what it did. That was a
> tremendously useful exercise, but that was in the days when the total
> number of commands in those directories numbered in the low hundreds;
> 982 is a lot.
I did this when I first encountered Unix (v7): tried out most things
described in every command's man page! I still occasionally scan the
the [s]bin directories. But it seems there are fewer and fewer new
programs that can be used in cmd pipelines. The situation is a bit
like Sanskrit (built from a relatively small set of root words but
infinitely combinable) and prakrits, vernacular dialects that are
not so flexible but more practical.
From coff at tuhs.org Sun May 12 01:45:40 2024
From: coff at tuhs.org (Grant Taylor via COFF)
Date: Sat, 11 May 2024 10:45:40 -0500
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
Message-ID: <4bd2002a-ea47-4f57-bf0b-b482bac3e96c@tnetconsulting.net>
On 5/11/24 08:12, Dan Cross wrote:
> `pr` is an interesting case in point. I would guess that the name comes
> from Multics, where `print` (short name `pr`) is sort of the equivalent
> of `cat`, but contains a lot of extra functionality to control output,
> read archives, etc. But if one has never used Multics (and let's be
> honest: the total number of people in the world who have done so is a
> tiny, tiny fraction of the number of computer users), one would never
> guess that. When I started using Unix, I thought that "pr" was how
> you sent a file to the printer; "lpr" was highly non-intuitive, but
> I'd never seen a line printer at that point (our first home computer
> was a Mac with an imagewriter); the idea of `cat`ing a file into the
> printer device wasn't something I'd ever even considered (besides,
> I think the device was owned and writable only as root).
It wasn't until this thread that I became aware of `pr` as I've been an
`nl` user for years.
It wasn't until the message that I'm replying to that I realized the
naming relation between `pr` and `lpr`.
I also wonder if `pr` makes more sense in the context of teletypes
wherein when you `pr`(int) a file, you end up with a printout on the
teletype that you're using. Conversely `lpr` would send something to
the line printer elsewhere.
It makes sense in my head.
I have no idea if it's accurate or not.
--
Grant. . . .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4033 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240511/db4256f9/attachment.p7s>
From ralph at inputplus.co.uk Sun May 12 03:18:27 2024
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 11 May 2024 18:18:27 +0100
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <4bd2002a-ea47-4f57-bf0b-b482bac3e96c@tnetconsulting.net>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
<4bd2002a-ea47-4f57-bf0b-b482bac3e96c@tnetconsulting.net>
Message-ID: <20240511171827.04CAB2039A@orac.inputplus.co.uk>
Hi,
> It wasn't until this thread that I became aware of `pr` as I've been
> an `nl` user for years.
Learning of pr can also be done by reading Kernighan and Plauger's
‘Software tools’. There, it's called print and is more basic but
a variety of enhancements are listed. They then write:
When you write a program, there is a great temptation to add more
and more ‘features’ like these, little things that it will do for
you. But beware -- unless the features work together in a uniform
way, the result is going to be a grab-bag of unrelated capabilities,
most of which won't get used because nobody can remember them.
If you have to look up how to use a program for even the simplest
applications, you know you've gone too far. When in doubt, treat
‘feature’ as a pejorative. (Think of a hundred-bladed Swiss army
knife.)
>From memory, I think all of the significant programs written in that
book have an early Unix ancestor.
--
Cheers, Ralph.
From clemc at ccc.com Sun May 12 05:24:13 2024
From: clemc at ccc.com (Clem Cole)
Date: Sat, 11 May 2024 15:24:13 -0400
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
Message-ID: <CAC20D2OgB5pzzdXQy_+DgbYa5erx3cm-7X1GjwBZEGFLXT8g-Q@mail.gmail.com>
On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber at gmail.com> wrote:
> On Fri, May 10, 2024 at 11:37 AM Clem Cole <clemc at ccc.com> wrote:
>
>> The key is that not all "bloat" is the same (really)—or maybe one
>> person's bloat is another person's preference.
>>
>
> A lot of "bloat" comes because our systems really aren't focused on
> "discoverability".
>
> While I probably have used "pr" in the past, I've totally forgotten, the
> name "pr" doesn't really help me understand what it is for, and it's just
> one of 982 files in my /usr/bin directory alone. How does one discover it?
>
Chapter 1, Page 15 of Kernigahan and Pike -- "The Unix Programming
Environment"
It's still the best book for learning, regardless if Linux is your
preferred UNIX implementation.
>
> It's like using "sed" instead of "head": sure, if you already know "sed",
> you don't need "head", but for English speaking folks who know "tail" is
> there, it would be (and was in the old days) surprising and frustrating not
> to have "head".
>
Hmmm.. date on 1BSD tape for head is Nov 23, 1977. It's been around since
the Sixth Edition.
And again - this is my observation - some tools are easier to use, and the
head is easier than a sed script. One can argue a shell script that exec's
sed for you would have been sufficient to Joy's program.
However, in wnj's defense, he wrote it for sed was not part of the Sixth
Edition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240511/d540045f/attachment.htm>
From steffen at sdaoden.eu Sun May 12 07:18:43 2024
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 11 May 2024 23:18:43 +0200
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <20240511091822.B6691215AA@orac.inputplus.co.uk>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<20240510230217.IRjT8OER@steffen%sdaoden.eu>
<20240511091822.B6691215AA@orac.inputplus.co.uk>
Message-ID: <20240511211843.WS4s1gBI@steffen%sdaoden.eu>
Ralph Corderoy wrote in
<20240511091822.B6691215AA at orac.inputplus.co.uk>:
|Hi Steffen,
|
|> pr has always been enscript here, for example.
|
|enscript turns text into PostScript. That's not too handy to read.
|pr's output doesn't have to be sent to a printer. I doubt there's
|a week goes by without my using it. It just depends what your fingers
|know.
Nah, it can create text too (with control sequences, but that you
can filter away again, and mostly there are none, anyway).
I am actually not using it no more that often; i used it often to
review (80 column) code via printout, and it can/could give you
8 pages on a single DIN A4 paper. (Or two times 4 pages, to be
more exact.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
From lm at mcvoy.com Sun May 12 07:33:51 2024
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 11 May 2024 14:33:51 -0700
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <20240511211843.WS4s1gBI@steffen%sdaoden.eu>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<20240510230217.IRjT8OER@steffen%sdaoden.eu>
<20240511091822.B6691215AA@orac.inputplus.co.uk>
<20240511211843.WS4s1gBI@steffen%sdaoden.eu>
Message-ID: <20240511213351.GE9216@mcvoy.com>
On Sat, May 11, 2024 at 11:18:43PM +0200, Steffen Nurpmeso wrote:
> Ralph Corderoy wrote in
> <20240511091822.B6691215AA at orac.inputplus.co.uk>:
> |Hi Steffen,
> |
> |> pr has always been enscript here, for example.
> |
> |enscript turns text into PostScript. That's not too handy to read.
> |pr's output doesn't have to be sent to a printer. I doubt there's
> |a week goes by without my using it. It just depends what your fingers
> |know.
>
> Nah, it can create text too (with control sequences, but that you
> can filter away again, and mostly there are none, anyway).
> I am actually not using it no more that often; i used it often to
> review (80 column) code via printout, and it can/could give you
> 8 pages on a single DIN A4 paper. (Or two times 4 pages, to be
> more exact.)
Wow, that brings back memories. Let me look. Yeah here it is.
Prints 8 pages per page from postscript. Pretty sure I wrote it,
it looks like my style. But 100% sure it was useful when my eyesight
was better :-)
#!/usr/bin/perl -w
open(STDOUT, "|mpage -a -P- -8");
# Print the starting stuff
while (<>) {
print;
last if /%%EndProlog/;
}
$base = "/tmp/psrev";
$page = 1;
# Save each page from
# %%Page to the next in a file
$_ = <>;
while ($_ && !/%%Trailer/) {
$file = $base . $page++;
#warn "Creating $file\n";
open(OUT, ">$file");
do {
print OUT;
$_ = <>;
} while ($_ && !/%%Page/ && !/%%Trailer/);
close(OUT);
}
# Take each 8 and print them in the right order
$here = 0;
while ($here < $page - 8) {
foreach $i (2,4,6,8,1,3,5,7) {
&show($here + $i);
}
$here += 8;
}
# One page left.
if ($here == $page - 2) {
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
}
# Two pages left
if ($here == $page - 3) {
&show($here + 2);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
}
# Three pages left
if ($here == $page - 4) {
&show($here + 2);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
&show($here + 3);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
}
# Four pages left
if ($here == $page - 5) {
&show($here + 2);
&show($here + 4);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
&show($here + 3);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
}
# Five pages left
if ($here == $page - 6) {
&show($here + 2);
&show($here + 4);
print "%%Page: 0 0\nshowpage\n";
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
&show($here + 3);
&show($here + 5);
print "%%Page: 0 0\nshowpage\n";
}
# Six pages left
if ($here == $page - 7) {
&show($here + 2);
&show($here + 4);
&show($here + 6);
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
&show($here + 3);
&show($here + 5);
print "%%Page: 0 0\nshowpage\n";
}
# Seven pages left
# foreach $i (2,4,6,8,1,3,5,7) {
if ($here == $page - 8) {
&show($here + 2);
&show($here + 4);
&show($here + 6);
print "%%Page: 0 0\nshowpage\n";
&show($here + 1);
&show($here + 3);
&show($here + 5);
&show($here + 7);
}
if ($_) {
do {
print;
} while (defined($_ = <>));
}
exit;
sub show
{
local($p) = $_[0];
$file = $base . $p;
if (-e $file) {
#warn "Doing $file\n";
open(IN, $file);
while (defined($line = <IN>)) {
print $line;
}
unlink($file);
}
}
From tytso at mit.edu Sun May 12 07:35:32 2024
From: tytso at mit.edu (Theodore Ts'o)
Date: Sat, 11 May 2024 17:35:32 -0400
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
Message-ID: <20240511213532.GB8330@mit.edu>
On Sat, May 11, 2024 at 09:12:33AM -0400, Dan Cross wrote:
> On Fri, May 10, 2024 at 7:23 PM Nevin Liber <nliber at gmail.com> wrote:
> > A lot of "bloat" comes because our systems really aren't focused on "discoverability".
> >
> > While I probably have used "pr" in the past, I've totally forgotten, the name "pr" doesn't really help me understand what it is for, and it's just one of 982 files in my /usr/bin directory alone. How does one discover it?
>
> This is a fantastic question. At one point, I went through every
> command in /bin and /usr/bin and figured out what it did. That was a
> tremendously useful exercise, but that was in the days when the total
> number of commands in those directories numbered in the low hundreds;
> 982 is a lot.
Yeah, I think that a lot of this goes back to scalability. What might
work well in the simpler world of V7 Unix might be more challenging
probem space today. One example of this is how many people got
started with Kernel programming. When I first started working on
Linux, which was back in 1991, I could print out all of the kernel
source (heh, using "enscrpt -2rGh") and that was less than an inch
think of paper, and I could read it all. I'm sure people had done
similar things with the Unix source code, or via the underground
photocopied of the Lyons book (AT&T copyright be d*mned :-). But
today, that's really not a practical way for people to get started
with Unix/Linux systems programming.
Another example of this is if you want to do something with more
complex data than just plain text files with fixed data fields that
you could manipulate using sort, awk, and Unix pipes. What if you
>need more complex structured data, stored say in JSON? Sure, you can
do something with pipes and jq. So sure, I can do something that is
more true to the Unix philosphy like this:
gcloud compute instances describe \
--zone "$z" "$i" --format=json > "$inst_info"
kver=$(jq < "$inst_info" 2> /dev/null \
'.metadata.items[] | select(.key == "kernel_version") | .value' | \
sed -e 's/^"//' -e 's/"$//' \
-e 's/^Linux xfstests-[0-9A-Za-z-]* //' -e 's/ .*//')
` gce_status=$(jq < "$inst_info" .status | \
sed -e 's/^"//' -e 's/"$//')
status=$(jq < "$inst_info" 2> /dev/null \
'.metadata.items[] | select(.key == "status") | .value' | \
sed -e 's/^"//' -e 's/"$//')
ip=$(jq < "$inst_info" 2> /dev/null \
'.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' | \
sed -e 's/^"//' -e 's/"$//')
... but arguably, this is at the limit at what you can do using Unix
pipes as opposed to using Perl or Python.... but commands like:
jq '.metadata.items[] | select(.key == "kernel_version") | .value'
is doing a huge amount of the heavy lifting.
I bet most of the young'uns would not be trying to do this as a shell
script, but using the Cloud SDK with perl or python or Go, which is
*way* more bloaty than using /bin/sh.
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.
Cheers,
- Ted
From gbuday.irtf at gmail.com Sun May 12 17:13:20 2024
From: gbuday.irtf at gmail.com (Gergely Buday)
Date: Sun, 12 May 2024 08:13:20 +0100
Subject: [COFF] [TUHS] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <20240511213532.GB8330@mit.edu>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
<20240511213532.GB8330@mit.edu>
Message-ID: <CA+HOLVBu-J=HFQB36oiBDdZc0nOPJWsHzDjM2FnZkcSohWcPbQ@mail.gmail.com>
Theodore Ts'o <tytso at mit.edu> ezt Ãrta (idÅ‘pont: 2024. máj. 11., Szo 22:35):
>
>
> 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.
These days functional programmers follow the idea of writing small
functions and combine them in interesting ways.
- Gergely
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240512/39354495/attachment-0001.htm>
From ralph at inputplus.co.uk Sun May 12 17:29:03 2024
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sun, 12 May 2024 08:29:03 +0100
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <20240511213532.GB8330@mit.edu>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
<20240511213532.GB8330@mit.edu>
Message-ID: <20240512072903.DA7E12064E@orac.inputplus.co.uk>
Hi,
As an example of pushing the limit of Unix pipes, I found this awkward
to read, e.g. the noise of the redundant backslash after an end-of-line
pipe.
> gcloud compute instances describe \
> --zone "$z" "$i" --format=json > "$inst_info"
> kver=$(jq < "$inst_info" 2> /dev/null \
> '.metadata.items[] | select(.key == "kernel_version") | .value' | \
> sed -e 's/^"//' -e 's/"$//' \
> -e 's/^Linux xfstests-[0-9A-Za-z-]* //' -e 's/ .*//')
> ` gce_status=$(jq < "$inst_info" .status | \
> sed -e 's/^"//' -e 's/"$//')
> status=$(jq < "$inst_info" 2> /dev/null \
> '.metadata.items[] | select(.key == "status") | .value' | \
> sed -e 's/^"//' -e 's/"$//')
> ip=$(jq < "$inst_info" 2> /dev/null \
> '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' | \
> sed -e 's/^"//' -e 's/"$//')
Re-formatting, including the more idiomatic placement of I/O
redirection, gives
gcloud compute instances describe \
--zone "$z" "$i" --format=json >"$inst_info"
kver=$(
jq '.metadata.items[] | select(.key == "kernel_version") | .value' \
<"$inst_info" 2>/dev/null |
sed '
s/^"//; s/"$//
s/^Linux xfstests-[0-9A-Za-z-]* //
s/ .*//
'
)
gce_status=$(
jq .status \
<"$inst_info" |
sed 's/^"//; s/"$//'
)
status=$(
jq '.metadata.items[] | select(.key == "status") | .value' \
<"$inst_info" 2>/dev/null |
sed 's/^"//; s/"$//'
)
ip=$(
jq '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP' \
<"$inst_info" 2>/dev/null |
sed 's/^"//; s/"$//'
)
The repetition is now more clear to me. And I see jq's stderr is
discarded in all but one case. Assuming that one can be, or should be,
the same allows factoring.
gcloud compute instances describe \
--zone "$z" "$i" --format=json >"$inst_info"
query() {
jq "${1?}" <"$inst_info" 2>/dev/null |
sed 's/^"//; s/"$//'
}
kver=$(
query '.metadata.items[] | select(.key == "kernel_version") | .value' |
sed 's/^Linux xfstests-[0-9A-Za-z-]* //; s/ .*//'
)
gce_status=$(query .status)
status=$(query '.metadata.items[] | select(.key == "status") | .value')
ip=$(query '.networkInterfaces[] | .accessConfigs[] | select(.name == "external-nat") | .natIP')
--
Cheers, Ralph.
From dave at horsfall.org Mon May 13 08:23:08 2024
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 13 May 2024 08:23:08 +1000 (EST)
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <20240512072903.DA7E12064E@orac.inputplus.co.uk>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
<CAEoi9W7FbGZFhiddHWWqdivGFfgFAj9nsUApomswfP56rqTMpQ@mail.gmail.com>
<20240511213532.GB8330@mit.edu>
<20240512072903.DA7E12064E@orac.inputplus.co.uk>
Message-ID: <alpine.BSF.2.21.9999.2405130731370.15285@aneurin.horsfall.org>
On Sun, 12 May 2024, Ralph Corderoy wrote:
> As an example of pushing the limit of Unix pipes, I found this awkward
> to read, e.g. the noise of the redundant backslash after an end-of-line
> pipe.
Y'know, I've been writing "| \" for donkeys' (well, "^ \" early in the
game), and I never knew...
I suppose I could write a Perl script to modify them.
-- Dave
From coff at tuhs.org Mon May 13 16:20:13 2024
From: coff at tuhs.org (Arno Griffioen via COFF)
Date: Mon, 13 May 2024 08:20:13 +0200
Subject: [COFF] On Bloat and the Idea of Small Specialized Tools
In-Reply-To: <CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
References: <CAC20D2PeOLQre8x4XcJdyGGAFmKUC3j-JB=v=j+VJ7KuFrGojw@mail.gmail.com>
<CAGg_6+Ov6hYTxQ5M-hEBoOiUQ0UVRP0V+aVi0STKAALLDUGY7g@mail.gmail.com>
Message-ID: <ZkGxHUETGzg-zPlf@ancienthardware.org>
On Fri, May 10, 2024 at 06:22:15PM -0500, Nevin Liber wrote:
> GUIs were better at discoverability. The menu at the top made it easy to see
> (and constantly reinforced) what was possible, at least until we got into the
> era of contextual menus, gestures and force presses.
At the risk of really sounding like a grumpy old fart... This in spades..
I have to laugh whenever there's a new iPhone/Android/Home-automation/Car
or other 'touchscreen' device out and these days it seems required to watch
about a dozen Youtube video's before you even know what new
tap/touch/button/squeeze action you can or have to do now to access some
feature.
Supposedly we didn't want CLI's anymore because they were 'not intuitive' and
'hard to access for lay persons'. (fair ciriticism..)
... and now we have these devices that often show a pretty picture, but *no*
outward sign or indication about possible inputs/actions you can perform.
It's.. Almost like it's getting as bad as a '$ ' prompt for the 'uninitiated'
For fun, give a heavy iPhone user an Android phone or vice-versa and see
smoke coming out of their ears as they fight with it.. :)
Bye, Arno.
From cowan at ccil.org Thu May 16 21:51:06 2024
From: cowan at ccil.org (John Cowan)
Date: Thu, 16 May 2024 07:51:06 -0400
Subject: [COFF] [TUHS] Re: Be there a "remote diff" utility?
In-Reply-To: <20240516073351.267351FAE3@orac.inputplus.co.uk>
References: <alpine.BSF.2.21.9999.2405161623130.15285@aneurin.horsfall.org>
<202405160651.44G6pi8G018059@freefriends.org>
<20240516073351.267351FAE3@orac.inputplus.co.uk>
Message-ID: <CAD2gp_TQjyrDxvRMQ7YXyW0tUQ=-EyVeABwxtAVFKRTijTb6gQ@mail.gmail.com>
The Newcastle Connection, aka Unix United, was an early experiment in
transparent networking: see <
https://web.archive.org/web/20160816184205/http://www.cs.ncl.ac.uk/research/pubs/articles/papers/399.pdf>
for a high-level description. A name of the form "/../host/path"
represented a file or device on a remote host in a fully transparent way.
This was layered on V7 at the libc level, so that the kernel did not need
to be modified (though the shell did, since it was not libc-based at the
time). MUNIX was an implementation of the same idea using System V as the
underlying system.
This appears to be a VHS vs. Betamax battle: NFS was not transparent, but
Sun had far more marketing clout. However, the Manchester Connection
required a single uid space (as far as I can tell), which may also have
been a (perceived) institutional barrier.
On Thu, May 16, 2024 at 3:34 AM Ralph Corderoy <ralph at inputplus.co.uk>
wrote:
> Hi,
>
> I've set ‘mail-followup-to: coff at tuhs.org’.
>
> > > Every so often I want to compare files on remote machines, but all
> > > I can do is to fetch them first (usually into /tmp); I'd like to do
> > > something like:
> > >
> > > rdiff host1:file1 host2:file2
> > >
> > > Breathes there such a beast?
>
> No, nor should there. It would be slain less it beget rcmp, rcomm,
> rpaste, ...
>
> > > Think of it as an extension to the Unix philosophy of "Everything
> > > looks like a file"...
>
> Then make remote files look local as far as their access is concerned.
> Ideally at the system-call level. Less ideal, at libc.a.
>
> > Maybe
> >
> > diff -u <(ssh host1 cat file1) <(ssh host2 cat file2)
>
> This is annoyingly noisy if the remote SSH server has sshd_config(5)'s
> ‘Banner’ set which spews the contents of a file before authentication,
> e.g. the pointless
>
> This computer system is the property of ...
>
> Disconnect NOW if you have not been expressly authorised to use this
> system. Unauthorised use is a criminal offence under the Computer
> Misuse Act 1990.
>
> Communications on or through ...uk's computer systems may be
> monitored or recorded to secure effective system operation and for
> other lawful purposes.
>
> It appears on stderr so doesn't upset the diff but does clutter.
> And discarding stderr is too sloppy.
>
> --
> Cheers, Ralph.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240516/d671b457/attachment.htm>
From crossd at gmail.com Thu May 16 23:45:38 2024
From: crossd at gmail.com (Dan Cross)
Date: Thu, 16 May 2024 09:45:38 -0400
Subject: [COFF] [TUHS] Re: Be there a "remote diff" utility?
In-Reply-To: <CAD2gp_TQjyrDxvRMQ7YXyW0tUQ=-EyVeABwxtAVFKRTijTb6gQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2405161623130.15285@aneurin.horsfall.org>
<202405160651.44G6pi8G018059@freefriends.org>
<20240516073351.267351FAE3@orac.inputplus.co.uk>
<CAD2gp_TQjyrDxvRMQ7YXyW0tUQ=-EyVeABwxtAVFKRTijTb6gQ@mail.gmail.com>
Message-ID: <CAEoi9W44y=7vraTWnXnMnumUtrWTzqG6ktFWccWKyNmFTieaDQ@mail.gmail.com>
On Thu, May 16, 2024 at 7:51 AM John Cowan <cowan at ccil.org> wrote:
> [snip]
> This appears to be a VHS vs. Betamax battle: NFS was not transparent, but Sun had far more marketing clout. However, the Manchester Connection required a single uid space (as far as I can tell), which may also have been a (perceived) institutional barrier.
So did NFS, for that matter.
This is one of those areas where Unix appears creaky in comparison to
Plan 9. `ssh` is all about remote access to resources, whereas plan 9
was all about resource sharing: you'd set up a namespace with all of
the resources (exposed as files from wherever they ultimately came
from) you cared about, and then operate on those "locally"; the
resources were shared with you and access was transparent, via a
consistent, file-based interface. You want to `diff` two remote files?
Import the filesystems they're both on, mount those somewhere, and
`diff /n/host1/file /n/host2/file`.
I think the `sshfs`+FUSE model that Doug mentioned is about the
closest you're going to get these days.
- Dan C.
- Dan C.
From lm at mcvoy.com Fri May 17 00:03:51 2024
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 16 May 2024 07:03:51 -0700
Subject: [COFF] [TUHS] Re: Be there a "remote diff" utility?
In-Reply-To: <CAEoi9W44y=7vraTWnXnMnumUtrWTzqG6ktFWccWKyNmFTieaDQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2405161623130.15285@aneurin.horsfall.org>
<202405160651.44G6pi8G018059@freefriends.org>
<20240516073351.267351FAE3@orac.inputplus.co.uk>
<CAD2gp_TQjyrDxvRMQ7YXyW0tUQ=-EyVeABwxtAVFKRTijTb6gQ@mail.gmail.com>
<CAEoi9W44y=7vraTWnXnMnumUtrWTzqG6ktFWccWKyNmFTieaDQ@mail.gmail.com>
Message-ID: <20240516140351.GZ9216@mcvoy.com>
On Thu, May 16, 2024 at 09:45:38AM -0400, Dan Cross wrote:
> On Thu, May 16, 2024 at 7:51???AM John Cowan <cowan at ccil.org> wrote:
> > [snip]
> > This appears to be a VHS vs. Betamax battle: NFS was not transparent, but Sun had far more marketing clout. However, the Manchester Connection required a single uid space (as far as I can tell), which may also have been a (perceived) institutional barrier.
>
> So did NFS, for that matter.
>
> This is one of those areas where Unix appears creaky in comparison to
> Plan 9. `ssh` is all about remote access to resources, whereas plan 9
> was all about resource sharing: you'd set up a namespace with all of
> the resources (exposed as files from wherever they ultimately came
> from) you cared about, and then operate on those "locally"; the
> resources were shared with you and access was transparent, via a
> consistent, file-based interface. You want to `diff` two remote files?
> Import the filesystems they're both on, mount those somewhere, and
> `diff /n/host1/file /n/host2/file`.
If you are all trusting, behind a firewall, like the Sun campus was:
diff /net/host1/file /net/host2/file
Seems pretty darn similar and you don't set up a namespace other than
saying what you want to share in /etc/exports.
Seems far from creaky to me, no root access required (other than setting
up /etc/exports), any user can access any exported file. I was at Sun
and it worked great. Granted, you needed a working NFS implementation
and when I left Sun I found that Sun was really the only place that got
that right in the 1990's. Linux has caught up, don't know about the
rest.
--lm
From cowan at ccil.org Fri May 17 00:43:56 2024
From: cowan at ccil.org (John Cowan)
Date: Thu, 16 May 2024 10:43:56 -0400
Subject: [COFF] [TUHS] Re: Be there a "remote diff" utility?
In-Reply-To: <CAEoi9W44y=7vraTWnXnMnumUtrWTzqG6ktFWccWKyNmFTieaDQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2405161623130.15285@aneurin.horsfall.org>
<202405160651.44G6pi8G018059@freefriends.org>
<20240516073351.267351FAE3@orac.inputplus.co.uk>
<CAD2gp_TQjyrDxvRMQ7YXyW0tUQ=-EyVeABwxtAVFKRTijTb6gQ@mail.gmail.com>
<CAEoi9W44y=7vraTWnXnMnumUtrWTzqG6ktFWccWKyNmFTieaDQ@mail.gmail.com>
Message-ID: <CAD2gp_QFmLi0aWJyzhCrFKaMLeieHT7AOjomuHu3LEhGtY60LQ@mail.gmail.com>
NFS v4 provides idmapping between client uids/gids and their server
equivalents using a config file.
On Thu, May 16, 2024 at 9:46 AM Dan Cross <crossd at gmail.com> wrote:
> On Thu, May 16, 2024 at 7:51 AM John Cowan <cowan at ccil.org> wrote:
> > [snip]
> > This appears to be a VHS vs. Betamax battle: NFS was not transparent,
> but Sun had far more marketing clout. However, the Manchester Connection
> required a single uid space (as far as I can tell), which may also have
> been a (perceived) institutional barrier.
>
> So did NFS, for that matter.
>
> This is one of those areas where Unix appears creaky in comparison to
> Plan 9. `ssh` is all about remote access to resources, whereas plan 9
> was all about resource sharing: you'd set up a namespace with all of
> the resources (exposed as files from wherever they ultimately came
> from) you cared about, and then operate on those "locally"; the
> resources were shared with you and access was transparent, via a
> consistent, file-based interface. You want to `diff` two remote files?
> Import the filesystems they're both on, mount those somewhere, and
> `diff /n/host1/file /n/host2/file`.
>
> I think the `sshfs`+FUSE model that Doug mentioned is about the
> closest you're going to get these days.
>
> - Dan C.
>
>
> - Dan C.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240516/025c7dd6/attachment.htm>
From crossd at gmail.com Fri May 17 00:49:00 2024
From: crossd at gmail.com (Dan Cross)
Date: Thu, 16 May 2024 10:49:00 -0400
Subject: [COFF] [TUHS] Re: Be there a "remote diff" utility?
In-Reply-To: <CAD2gp_QFmLi0aWJyzhCrFKaMLeieHT7AOjomuHu3LEhGtY60LQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.2405161623130.15285@aneurin.horsfall.org>
<202405160651.44G6pi8G018059@freefriends.org>
<20240516073351.267351FAE3@orac.inputplus.co.uk>
<CAD2gp_TQjyrDxvRMQ7YXyW0tUQ=-EyVeABwxtAVFKRTijTb6gQ@mail.gmail.com>
<CAEoi9W44y=7vraTWnXnMnumUtrWTzqG6ktFWccWKyNmFTieaDQ@mail.gmail.com>
<CAD2gp_QFmLi0aWJyzhCrFKaMLeieHT7AOjomuHu3LEhGtY60LQ@mail.gmail.com>
Message-ID: <CAEoi9W6vDK4jg7K_565siW8gZf+aLtQ_v8BfY56J=cs6Xt_rWg@mail.gmail.com>
On Thu, May 16, 2024 at 10:44 AM John Cowan <cowan at ccil.org> wrote:
> NFS v4 provides idmapping between client uids/gids and their server equivalents using a config file.
NFS v4 came much later, of course. But even earlier NFS
implementations provided something like this, and UID 0 has been
mapped to "nobody" for many decades. But that's not terribly relevant;
the point is that, by default, the NFS protocol relies on UIDs having
meaning, as opposed to properly authenticated principles independent
of the underlying implementation of "identity", as in e.g. AFS. To be
fair, it's my understanding that NFSv4 _does_ improve on the situation
here.
- Dan C.
> On Thu, May 16, 2024 at 9:46 AM Dan Cross <crossd at gmail.com> wrote:
>>
>> On Thu, May 16, 2024 at 7:51 AM John Cowan <cowan at ccil.org> wrote:
>> > [snip]
>> > This appears to be a VHS vs. Betamax battle: NFS was not transparent, but Sun had far more marketing clout. However, the Manchester Connection required a single uid space (as far as I can tell), which may also have been a (perceived) institutional barrier.
>>
>> So did NFS, for that matter.
>>
>> This is one of those areas where Unix appears creaky in comparison to
>> Plan 9. `ssh` is all about remote access to resources, whereas plan 9
>> was all about resource sharing: you'd set up a namespace with all of
>> the resources (exposed as files from wherever they ultimately came
>> from) you cared about, and then operate on those "locally"; the
>> resources were shared with you and access was transparent, via a
>> consistent, file-based interface. You want to `diff` two remote files?
>> Import the filesystems they're both on, mount those somewhere, and
>> `diff /n/host1/file /n/host2/file`.
>>
>> I think the `sshfs`+FUSE model that Doug mentioned is about the
>> closest you're going to get these days.
>>
>> - Dan C.
>>
>>
>> - Dan C.
From coff at tuhs.org Tue May 21 14:55:25 2024
From: coff at tuhs.org (segaloco via COFF)
Date: Tue, 21 May 2024 04:55:25 +0000
Subject: [COFF] Draft Full BASIC Standard Circa September 15th, 1980 Scan?
Message-ID: <3kE4keYnK6xfUjRmqvAPcacXX1AB8qTavs0id-FYK7hlpxGAyRKtHmbz7CbGyIgOU8XLC9YaLskfiGYVvI0J3lL9hEn4ezR0Wf8Hxuygxtw=@protonmail.com>
Good evening, I recently came into possession of a "Draft Proposed American National Standard for BASIC" circa September 15, 1980, 6 years prior to the publication of the Full BASIC standard.
I did some brief searching around, checked bitsavers, archive.org, but I don't happen to see this archived anywhere. Is anyone aware of such a scan? If not, I'll be sure to add it to my scan docket...which is a bit slow these days due to a beautiful spring and much gardening...but not forgotten!
Flipping through this makes me wonder how things might have been different if this dropped in 1980 rather than 1986.
- Matt G.
From dave at horsfall.org Tue May 21 15:39:20 2024
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 21 May 2024 15:39:20 +1000 (EST)
Subject: [COFF] Draft Full BASIC Standard Circa September 15th,
1980 Scan?
In-Reply-To: <3kE4keYnK6xfUjRmqvAPcacXX1AB8qTavs0id-FYK7hlpxGAyRKtHmbz7CbGyIgOU8XLC9YaLskfiGYVvI0J3lL9hEn4ezR0Wf8Hxuygxtw=@protonmail.com>
References: <3kE4keYnK6xfUjRmqvAPcacXX1AB8qTavs0id-FYK7hlpxGAyRKtHmbz7CbGyIgOU8XLC9YaLskfiGYVvI0J3lL9hEn4ezR0Wf8Hxuygxtw=@protonmail.com>
Message-ID: <alpine.BSF.2.21.9999.2405211534160.15285@aneurin.horsfall.org>
On Tue, 21 May 2024, segaloco via COFF wrote:
[...]
> Flipping through this makes me wonder how things might have been
> different if this dropped in 1980 rather than 1986.
Well, I taught myself BASIC way back in school, in 1970; of course, the
language has changed a bit since then...
-- Dave
From dave at horsfall.org Wed May 22 08:14:49 2024
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 22 May 2024 08:14:49 +1000 (EST)
Subject: [COFF] =?utf-8?q?PiDP-10_=E2=80=94_The_MagPi_magazine?=
Message-ID: <alpine.BSF.2.21.9999.2405220808040.15285@aneurin.horsfall.org>
Could interest a few OFs here... I've used the -8 and of course the -11,
but not the -10 so I may as well start now.
-- Dave
---------- Forwarded message ----------
From: A fellow geek
To: Dave Horsfall <dave at horsfall.org>
Subject: PiDP-10 — The MagPi magazine
RasPi is now masquerading as a PDP-10…
https://magpi.raspberrypi.com/articles/pidp-10
From athornton at gmail.com Wed May 22 15:26:21 2024
From: athornton at gmail.com (Adam Thornton)
Date: Tue, 21 May 2024 22:26:21 -0700
Subject: [COFF] =?utf-8?q?PiDP-10_=E2=80=94_The_MagPi_magazine?=
In-Reply-To: <alpine.BSF.2.21.9999.2405220808040.15285@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2405220808040.15285@aneurin.horsfall.org>
Message-ID: <CAP2nic351DOtfGVQTizLmG2tJ3c+MVx-Ep7XAC6cQ0L41J47nw@mail.gmail.com>
I've got all of Oscar's kits. The new PiDP-10 is absolutely gorgeous. You
won't regret it.
If you aren't in it for the blinkylights, a single Pi4 can run quite a lot
of simh and dps8m and Hercules instances all at once.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240521/085bf278/attachment.htm>
From clemc at ccc.com Thu May 23 06:00:58 2024
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 May 2024 16:00:58 -0400
Subject: [COFF] NYTimes.com: C. Gordon Bell,
Creator of a Personal Computer Prototype, Dies at 89
Message-ID: <CAC20D2MEr4n7BbwnHzO9wxpqRqUE7kLae5YJGFMck3XUAtGUrQ@mail.gmail.com>
Explore this gift article from The New York Times. You can read it for free
without a subscription.
C. Gordon Bell, Creator of a Personal Computer Prototype, Dies at 89
It cost $18,000 when it was introduced in 1965, but it bridged the world
between room-size mainframes and the modern desktop.
https://www.nytimes.com/2024/05/21/technology/c-gordon-bell-dead.html?unlocked_article_code=1.t00.KCKI.tLvZxBitrHP2&smid=em-share
á§
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240522/28501b9b/attachment.htm>
From crossd at gmail.com Thu May 23 06:23:34 2024
From: crossd at gmail.com (Dan Cross)
Date: Wed, 22 May 2024 16:23:34 -0400
Subject: [COFF] NYTimes.com: C. Gordon Bell,
Creator of a Personal Computer Prototype, Dies at 89
In-Reply-To: <CAC20D2MEr4n7BbwnHzO9wxpqRqUE7kLae5YJGFMck3XUAtGUrQ@mail.gmail.com>
References: <CAC20D2MEr4n7BbwnHzO9wxpqRqUE7kLae5YJGFMck3XUAtGUrQ@mail.gmail.com>
Message-ID: <CAEoi9W54TttFyD2Q_wGa+LgUN3mdVM011hbffdojdR3qqZrjrg@mail.gmail.com>
On Wed, May 22, 2024, 4:17 PM Clem Cole <clemc at ccc.com> wrote:
> Explore this gift article from The New York Times. You can read it for
> free without a subscription.
>
> C. Gordon Bell, Creator of a Personal Computer Prototype, Dies at 89
>
> It cost $18,000 when it was introduced in 1965, but it bridged the world
> between room-size mainframes and the modern desktop.
>
>
> https://www.nytimes.com/2024/05/21/technology/c-gordon-bell-dead.html?unlocked_article_code=1.t00.KCKI.tLvZxBitrHP2&smid=em-share
>
As I understand it, the lede is very often out of the control of the
article's author, but this one very much undersells it!
- Dan C.
á§
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240522/1be36291/attachment.htm>
From clemc at ccc.com Thu May 23 08:30:34 2024
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 May 2024 18:30:34 -0400
Subject: [COFF] =?utf-8?q?PiDP-10_=E2=80=94_The_MagPi_magazine?=
In-Reply-To: <alpine.BSF.2.21.9999.2405220808040.15285@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2405220808040.15285@aneurin.horsfall.org>
Message-ID: <CAC20D2PbjAGjvdYSCGRYOu5hpeUrxoU8E76rBUoAoesY+Ty2Sw@mail.gmail.com>
For those interested, check out: PiDP-10 <pidp-10 at googlegroups.com>
[There are similar groups for the pidp-11 and pidp-8].
Order are here:
https://obsolescence.wixsite.com/obsolescence/pidp-10-get-one
FWIW, Oscar has just started shipping, and he is very backlogged with
orders. They are kitted in Panama and then shipped 50 at a time to Florida,
where he has a fulfillment company handle the orders. It's better than when
Oscar was doing this on his kitchen table - but he's still a very small
concern, so you need patience and understanding.
Frankly, go to the website, download the SW, and start playing without the
blinkenlights. There is plenty to do before you get your kit.
á§
On Tue, May 21, 2024 at 6:15 PM Dave Horsfall <dave at horsfall.org> wrote:
> Could interest a few OFs here... I've used the -8 and of course the -11,
> but not the -10 so I may as well start now.
>
> -- Dave
>
> ---------- Forwarded message ----------
> From: A fellow geek
> To: Dave Horsfall <dave at horsfall.org>
> Subject: PiDP-10 — The MagPi magazine
>
> RasPi is now masquerading as a PDP-10…
>
> https://magpi.raspberrypi.com/articles/pidp-10
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/coff/attachments/20240522/ef1a6382/attachment.htm>