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: 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 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 > > 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: 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: References: Message-ID: <20240510230217.IRjT8OER@steffen%sdaoden.eu> Clem Cole wrote in : |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: References: Message-ID: On Fri, May 10, 2024 at 11:37 AM Clem Cole 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 iber at gmail.com> +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: <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: References: 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: References: Message-ID: 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 wrote: > On Fri, May 10, 2024 at 11:37 AM Clem Cole 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 iber at gmail.com> > +1-847-691-1404 > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: On Fri, May 10, 2024 at 7:23 PM Nevin Liber wrote: > On Fri, May 10, 2024 at 11:37 AM Clem Cole 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: References: Message-ID: On May 11, 2024, at 6:12 AM, Dan Cross wrote: > > On Fri, May 10, 2024 at 7:23 PM Nevin Liber wrote: >> On Fri, May 10, 2024 at 11:37 AM Clem Cole 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: References: 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: 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: <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: References: Message-ID: On Fri, May 10, 2024 at 7:23 PM Nevin Liber wrote: > On Fri, May 10, 2024 at 11:37 AM Clem Cole 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: 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: <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: <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 = )) { 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: References: 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 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: <20240511213532.GB8330@mit.edu> Message-ID: Theodore Ts'o 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: 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: <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: <20240511213532.GB8330@mit.edu> <20240512072903.DA7E12064E@orac.inputplus.co.uk> Message-ID: 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: References: Message-ID: 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: <202405160651.44G6pi8G018059@freefriends.org> <20240516073351.267351FAE3@orac.inputplus.co.uk> Message-ID: 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 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: 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: References: <202405160651.44G6pi8G018059@freefriends.org> <20240516073351.267351FAE3@orac.inputplus.co.uk> Message-ID: On Thu, May 16, 2024 at 7:51 AM John Cowan 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: References: <202405160651.44G6pi8G018059@freefriends.org> <20240516073351.267351FAE3@orac.inputplus.co.uk> 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 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: References: <202405160651.44G6pi8G018059@freefriends.org> <20240516073351.267351FAE3@orac.inputplus.co.uk> Message-ID: 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 wrote: > On Thu, May 16, 2024 at 7:51 AM John Cowan 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: 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: References: <202405160651.44G6pi8G018059@freefriends.org> <20240516073351.267351FAE3@orac.inputplus.co.uk> Message-ID: On Thu, May 16, 2024 at 10:44 AM John Cowan 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 wrote: >> >> On Thu, May 16, 2024 at 7:51 AM John Cowan 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: 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: 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 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: References: Message-ID: 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: 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: 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: 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: References: Message-ID: On Wed, May 22, 2024, 4:17 PM Clem Cole 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: 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: References: Message-ID: For those interested, check out: PiDP-10 [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 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 > 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: