From coff at tuhs.org Mon Dec 2 13:05:17 2024 From: coff at tuhs.org (Warren Toomey via COFF) Date: Mon, 2 Dec 2024 13:05:17 +1000 Subject: [COFF] Sending TUHS to an LLM In-Reply-To: References: Message-ID: On Thu, Nov 28, 2024 at 10:40:59AM +1000, Warren Toomey via COFF wrote: > I was just trying to find out if there was a way of uploading the TUHS > mailing list as a corpus of text into a LLM so that I could ask questions > based on the knowledge contained therein. I'm not having much luck yet. Steve Jenkin pointed me at Google's NotebookLM. I took the first 1M (of 137M) of the TUHS mailing list mbox, filtered out most of the headers and fed it in. It seems to do a good job of summarising the contents and responding to questions. Here's a link: https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9?_gl=1*dqtpyz*_ga*NTgzOTM5MzU2LjE3MzMxMDY0NzU.*_ga_W0LDH41ZCB*MTczMzEwNjQ3NC4xLjEuMTczMzEwNjQ5OS4zNS4wLjA.&original_referer=https:%2F%2Fnotebooklm.google%23&pli=1 What's weirder is you can generate a 30-minute dialogue where two AI entities talk about the content. There's a lot of verbal diarrhoea, but here is the link if you feel like listening to it :-) https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9/audio Cheers, Warren From imp at bsdimp.com Mon Dec 2 13:07:28 2024 From: imp at bsdimp.com (Warner Losh) Date: Sun, 1 Dec 2024 20:07:28 -0700 Subject: [COFF] Sending TUHS to an LLM In-Reply-To: References: Message-ID: On Sun, Dec 1, 2024, 8:05 PM Warren Toomey via COFF wrote: > On Thu, Nov 28, 2024 at 10:40:59AM +1000, Warren Toomey via COFF wrote: > > I was just trying to find out if there was a way of uploading the TUHS > > mailing list as a corpus of text into a LLM so that I could ask questions > > based on the knowledge contained therein. I'm not having much luck yet. > > Steve Jenkin pointed me at Google's NotebookLM. I took the first 1M (of > 137M) > of the TUHS mailing list mbox, filtered out most of the headers and fed it > in. > > It seems to do a good job of summarising the contents and responding to > questions. Here's a link: > > > https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9?_gl=1*dqtpyz*_ga*NTgzOTM5MzU2LjE3MzMxMDY0NzU.*_ga_W0LDH41ZCB*MTczMzEwNjQ3NC4xLjEuMTczMzEwNjQ5OS4zNS4wLjA.&original_referer=https:%2F%2Fnotebooklm.google%23&pli=1 > > What's weirder is you can generate a 30-minute dialogue where two AI > entities > talk about the content. There's a lot of verbal diarrhoea, but here is the > link if you feel like listening to it :-) > > > https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9/audio Better or worse than the analyze-pinhead output in gnuemacs? Warner > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Dec 2 15:29:16 2024 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 2 Dec 2024 16:29:16 +1100 (AEDT) Subject: [COFF] Sending TUHS to an LLM In-Reply-To: References: Message-ID: <51a1bc11-a05b-1959-284a-5ebf0af4804e@horsfall.org> On Mon, 2 Dec 2024, Warren Toomey via COFF wrote: > What's weirder is you can generate a 30-minute dialogue where two AI > entities talk about the content. There's a lot of verbal diarrhoea, but > here is the link if you feel like listening to it :-) Where's ELIZA when we need her? :-) -- Dave From gbuday.irtf at gmail.com Mon Dec 2 18:02:50 2024 From: gbuday.irtf at gmail.com (Gergely Buday) Date: Mon, 2 Dec 2024 08:02:50 +0000 Subject: [COFF] Sending TUHS to an LLM In-Reply-To: References: Message-ID: The first link asks me to add sources first. I guess I don't have rights to use your sources. - Gergely Warren Toomey via COFF ezt írta (időpont: 2024. dec. 2., Hét 3:23): > On Thu, Nov 28, 2024 at 10:40:59AM +1000, Warren Toomey via COFF wrote: > > I was just trying to find out if there was a way of uploading the TUHS > > mailing list as a corpus of text into a LLM so that I could ask questions > > based on the knowledge contained therein. I'm not having much luck yet. > > Steve Jenkin pointed me at Google's NotebookLM. I took the first 1M (of > 137M) > of the TUHS mailing list mbox, filtered out most of the headers and fed it > in. > > It seems to do a good job of summarising the contents and responding to > questions. Here's a link: > > > https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9?_gl=1*dqtpyz*_ga*NTgzOTM5MzU2LjE3MzMxMDY0NzU.*_ga_W0LDH41ZCB*MTczMzEwNjQ3NC4xLjEuMTczMzEwNjQ5OS4zNS4wLjA.&original_referer=https:%2F%2Fnotebooklm.google%23&pli=1 > > What's weirder is you can generate a 30-minute dialogue where two AI > entities > talk about the content. There's a lot of verbal diarrhoea, but here is the > link if you feel like listening to it :-) > > > https://notebooklm.google.com/notebook/eca37b7c-dfbd-4346-bdaa-2cc038087fb9/audio > > Cheers, Warren > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Dec 5 05:03:58 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 4 Dec 2024 14:03:58 -0500 Subject: [COFF] [TUHS] After 50 years, what has the Impact of Unix been? Message-ID: Apropos of file types, which Rich Salz commends Unix for discarding. Early in Multics development, I and others visited various influential time-sharing systems in search of good ideas. I tried each one on a simple model of software updating, in particular of remaking a compiler. In every instance I could not make my program work without expert help to get past file-type barriers. My model was based on a trivial Fortran program that copied input to output until an input line with END in column 7 had been processed. Every system was able to compile this program, but ... After compiling, I tried to use the program to make a copy of itself. Here was the first file-type hurdle. Input was typically expected to be of type data, not source code. Gurus had to scramble to overcome this nominal incompatibility. Next I tried to compile the new Fortran program. Same trouble in reverse--data used as source. More scrambling of gurus. Then I ran the newly compiled program to do the above steps over again. This time the gurus had the file-type workarounds under control. One comp center still had trouble, however, which took some time to diagnose. It turned out that Fortran programs were, for unknown reasons, specifically forbidden to read their own source code! One side effect of file-type conventions was that instead of learning once and for all how to create text files, one had to learn different ways to edit files of different types. Doug From paul.winalski at gmail.com Tue Dec 17 03:32:07 2024 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 16 Dec 2024 12:32:07 -0500 Subject: [COFF] DEC computer Christmas carols Message-ID: The PDP-10 had an alarm bell that could be rung under program control. When the TOPS-10 operating system crashed, it displayed a numeric code on the console indicating the reason for the crash. This was called a "stopcode" and is the equivalent of a Unix panic. It also rang the alarm bell. DDT (Dynamic Debugging Tool) was the primary debugger for TOPS-10. PPN (Project-Programmer Number) was used for system security. Each user account was assigned by number to a Project, and within that Project a unique Programmer Number. The low numbers (such as [7,3]) were usually privileged accounts. So here we have the Christmas carol Stopcode Bells, to the tune of Jingle Bells: ========== Stopcode bells, stopcode bells, stopcode all the way. Oh what fun it is to crash the system night and day. Stopcode bells, stopcode bells, stopcode all the way. Oh what fun it is to crash the system night and day. Poking through the core With a bug in DDT Change your PPN To [7,3]. Halt somebody's job. Make them scream and shout. Oh what fun it is to log The operator out. ========== This is one that I wrote while I worked in DEC's software development tools department. Around Christmas time the first baselevels of VAX/VMS Version 3.0 were being sent to alpha test. The engineering departments got first crack at the new system and so were the first to encounter bugs and design problems. VMS Version 3 had been a very ambitious project and was eventually split up into Version 3A (released as Version 3.0) and Version 3B (released as Version 4.0). There was a lot of grumbling by groups whose new features got put into 3B and thus delayed. The early baselevels of 3A broke the VAX C runtime library. So here we have Version 3 is Coming to Town: ========== You'd better work hard You'd better code fast. The system you use Just ain't gonna last. Version 3 is coming to town. They fixed some old bugs And put new ones in, Added some features They think will win. Version 3 is coming to town. There's so many new features. Too bad we can't use C. And the things that we most wanted Were deferred until 3B. You'd better work hard You'd better code fast. The system you use Just ain't gonna last. Version 3 is coming to town. ========= -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: