From athornton at gmail.com Mon Jan 2 03:21:38 2023 From: athornton at gmail.com (Adam Thornton) Date: Sun, 1 Jan 2023 10:21:38 -0700 Subject: [COFF] [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <20230101014054.GD5825@mcvoy.com> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101014054.GD5825@mcvoy.com> Message-ID: <4000BF98-1847-4935-A7B4-D20322C543CF@gmail.com> > On Dec 31, 2022, at 6:40 PM, Larry McVoy wrote: > > All true except for the Forth choice. It's as bad, maybe worse, as > choosing Tcl for your language. I've written a ton of Tcl but I > need the Tk GUI part so I put up with Tcl to get it. I'd never > push Tcl as a language that other people had to use. Same thing > with Forth. > > I dunno what I'd pick, Perl in the old days, Python now (not that > I care for Python but everyone can program it). Just pick something > that is trivial for someone to pick up. (Moved to COFF) I rather like FORTH. Its chief virtues are that it is both tiny and extensible. It was developed as a telescope control language, as I recall, and in highly constrained environments gives you a great deal of expressivity for a teeny tiny bit of interpreter code. I adored my HP 28S and still do: that was Peak Calculator, and its UI is basically a FORTH interpreter (which also, of course, functions just fine as an RPN calculator if you don't want to bother with flow control constructs). But I also make the slightly more controversial claim that FORTH is just LISP stood up on end. These days I think the right choice for those sorts of applications would be Micropython. Yes, a full-on Python interpreter is heavyweight, but Micropython gives you a lot of functionality in (comparatively) little space. It runs fine on a $4 Pi Pico, for instance, which has IIRC 256KB RAM. And if you find yourself missing TCL, there's always Powershell, which is like what would happen if bash and TCL had a really ugly baby that just wouldn't shut up. The amazing thing is that access to all the system DLLs makes it *almost* worth putting up with Powershell. Adam From athornton at gmail.com Mon Jan 2 03:21:38 2023 From: athornton at gmail.com (Adam Thornton) Date: Sun, 1 Jan 2023 10:21:38 -0700 Subject: [COFF] [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <20230101014054.GD5825@mcvoy.com> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101014054.GD5825@mcvoy.com> Message-ID: <4000BF98-1847-4935-A7B4-D20322C543CF@gmail.com> > On Dec 31, 2022, at 6:40 PM, Larry McVoy wrote: > > All true except for the Forth choice. It's as bad, maybe worse, as > choosing Tcl for your language. I've written a ton of Tcl but I > need the Tk GUI part so I put up with Tcl to get it. I'd never > push Tcl as a language that other people had to use. Same thing > with Forth. > > I dunno what I'd pick, Perl in the old days, Python now (not that > I care for Python but everyone can program it). Just pick something > that is trivial for someone to pick up. (Moved to COFF) I rather like FORTH. Its chief virtues are that it is both tiny and extensible. It was developed as a telescope control language, as I recall, and in highly constrained environments gives you a great deal of expressivity for a teeny tiny bit of interpreter code. I adored my HP 28S and still do: that was Peak Calculator, and its UI is basically a FORTH interpreter (which also, of course, functions just fine as an RPN calculator if you don't want to bother with flow control constructs). But I also make the slightly more controversial claim that FORTH is just LISP stood up on end. These days I think the right choice for those sorts of applications would be Micropython. Yes, a full-on Python interpreter is heavyweight, but Micropython gives you a lot of functionality in (comparatively) little space. It runs fine on a $4 Pi Pico, for instance, which has IIRC 256KB RAM. And if you find yourself missing TCL, there's always Powershell, which is like what would happen if bash and TCL had a really ugly baby that just wouldn't shut up. The amazing thing is that access to all the system DLLs makes it *almost* worth putting up with Powershell. Adam From lars at nocrew.org Mon Jan 2 03:33:28 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 01 Jan 2023 17:33:28 +0000 Subject: [COFF] [TUHS] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <4000BF98-1847-4935-A7B4-D20322C543CF@gmail.com> (Adam Thornton's message of "Sun, 1 Jan 2023 10:21:38 -0700") References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101014054.GD5825@mcvoy.com> <4000BF98-1847-4935-A7B4-D20322C543CF@gmail.com> Message-ID: <7wbknignx3.fsf@junk.nocrew.org> Adam Thornton wrote: > I rather like FORTH. Its chief virtues are that it is both tiny and > extensible. It was developed as a telescope control language, as I > recall It had a history before that, but yes that was it's first killer app. From ralph at inputplus.co.uk Mon Jan 2 19:37:18 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Mon, 02 Jan 2023 09:37:18 +0000 Subject: [COFF] Porting the SysIII kernel: boot, config & device drivers In-Reply-To: <20230101212609.yjg2poiggil7pwat@illithid> References: <335F89A9-30C2-41A2-8E84-C2D761746634@planet.nl> <20230101212609.yjg2poiggil7pwat@illithid> Message-ID: <20230102093718.1102D220FA@orac.inputplus.co.uk> Hi Branden, > Paul Ruizendaal wrote: > > That was my immediate pain point in doing the D1 SoC port. > > Unfortunately, the manufacturer only released the DRAM init code as > > compiler ‘-S’ output and the 1,400 page datasheet does not discuss > > its registers. Maybe this is a-typical, as I heard in the above > > keynote that NXP provides 8,000 page datasheets with their SoC’s. ... > I don't think it's atypical. I was pretty annoyed trying to use the > data sheet to program a simple timer chip on the ODROID-C2 ... > OS nerds don't generally handle procurement themselves. Instead, > purchasing managers do, and those people don't have to face the pain. ... > Data sheets are only as good as they need to be to move the product, > which means they don't need to be good at all, since the people who > pay for them look only at the advertised feature list and the price. I think it comes down to the background of the chip designer. I've always found NXP very good: their documentation of a chip is extensive; it doesn't rely on referring to external source code; and they're responsive when I've found the occasional error, both confirming the correction and committing to its future publication. On the other hand, TI left a bad taste. The documentation isn't good and they rely on a forum to mop up all the problems but it's pot luck which staffer answers and perennial problems can easily be found by a forum search, never with a satisfactory answer. My guess is Allwinner, maker of Paul's D1 SoC, has a language barrier and a very fast-moving market to dissuade them from putting too much effort into documentation. Many simpler chips from China, e.g. a JPEG encoder, come with a couple of pages listing features and some C written by a chip designer or copied from a rival. In my experience, chip selection is done by technical people, not procurement. It's too complex a task, even just choosing from those of one supplier like NXP, as there is often a compromise to make which affects the rest of the board design. That's where FPGAs have an allure, but unfortunately not in low-power designs. -- Cheers, Ralph. From athornton at gmail.com Tue Jan 3 04:41:14 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 11:41:14 -0700 Subject: [COFF] GCC boostrapper? Sort of a continuation of "a few comments..." Message-ID: <444D1F28-37A8-402A-874D-38507F2DE65D@gmail.com> So, all the shell-portability talk on TUHS reminds me of something I believe I saw back in the 90s, and then failed to find a few years ago when I went looking. But my Google-fu is not great, so maybe I just didn't look in the right place. I was trying to port Frotz to TOPS-20, because I wanted to run the Infocom games on TOPS-20 on an emulated PDP-10. (The only further causality to the chain was a warning in the Frotz sources that it assumed 8-bit bytes and if you wanted to try to port it to a 36-bit environment, good luck; this is the difference between "stuff I do fo fun" and "stuff that needs a business justification".) I had a K&R C compiler available, but the sources were all ANSI C. I had remembered that deprotoize had been part of an early GCC, and I did manage to find deprotoize sources, buried, I think, in some dusty piece of the Apple toolchain. But I also have a vague memory that GCC at some point probably in the mid-to-late 1990s came with something that was halfway between autoconf and Perl's bootstrapper. I *think* it was a bunch of shell scripts that could put together a minimal C subset compiler, which then could be used to build the rest of GCC. I'm pretty sure it was released as a reaction to the unbundling of C compilers when Unix vendors realized that was a thing they could do. I could not find that thing at all. Did I hallucinate it? It seems like it would have been an immensely useful tool at the time. I ended up writing my own very half-assed deprotoizer and symbol mangler (only the first six characters of the function name were significant, because that's how the TOPS-20 linker works, and I don't know that I could have gotten past that even with an ANSI compiler without having to do significant toolchain work) which got me over the hump, but I have remained curious whether there really was that nifty GCC bootstrapper or whether I made that up. Adam From crossd at gmail.com Tue Jan 3 04:48:19 2023 From: crossd at gmail.com (Dan Cross) Date: Mon, 2 Jan 2023 13:48:19 -0500 Subject: [COFF] [TUHS] Re: A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: [Apologies for resending; I messed up and used the old Minnie address for COFF in the Cc] On Mon, Jan 2, 2023 at 1:36 PM Dan Cross wrote: > > On Mon, Jan 2, 2023 at 1:13 PM Clem Cole wrote: > > Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused > > > > One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue. Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors. A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design. Seems, there was still a least one CDC-6600 running a particular critical application somewhere. > > > > This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one]. > > One of my favorite stories along these lines is the train signalling > system in Melbourne, running on a "PDP-11". I quote PDP-11 because > that is now virtualized: > https://www.equicon.de/images/Virtualisierung/LegacyTrainControlSystemStabilization.pdf > > Indeed older systems show up in surprising places. I was once on the > bridge of a US Naval vessel in the late '00s and saw a SPARCstaton 20 > running Solaris (with the CDE login screen). I don't recall what it > was doing, but it was a tad surprising. > > I do worry about legacy systems in critical situations, but then, I've > been in a firefight when the damned tactical computer with the satcomm > link rebooted and we didn't have VHF comms with the battlespace owner. > That was not particularly fun. > > - Dan C. From lm at mcvoy.com Tue Jan 3 04:50:53 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 10:50:53 -0800 Subject: [COFF] GCC boostrapper? Sort of a continuation of "a few comments..." In-Reply-To: <444D1F28-37A8-402A-874D-38507F2DE65D@gmail.com> References: <444D1F28-37A8-402A-874D-38507F2DE65D@gmail.com> Message-ID: <20230102185053.GQ25547@mcvoy.com> John Gilmore, Michael Tiemann or Gumby (aka David Henkel-Wallace) would know. It rings a bell but I'm not positive. On Mon, Jan 02, 2023 at 11:41:14AM -0700, Adam Thornton wrote: > So, all the shell-portability talk on TUHS reminds me of something I believe I saw back in the 90s, and then failed to find a few years ago when I went looking. > > But my Google-fu is not great, so maybe I just didn't look in the right place. > > I was trying to port Frotz to TOPS-20, because I wanted to run the Infocom games on TOPS-20 on an emulated PDP-10. (The only further causality to the chain was a warning in the Frotz sources that it assumed 8-bit bytes and if you wanted to try to port it to a 36-bit environment, good luck; this is the difference between "stuff I do fo fun" and "stuff that needs a business justification".) I had a K&R C compiler available, but the sources were all ANSI C. > > I had remembered that deprotoize had been part of an early GCC, and I did manage to find deprotoize sources, buried, I think, in some dusty piece of the Apple toolchain. But I also have a vague memory that GCC at some point probably in the mid-to-late 1990s came with something that was halfway between autoconf and Perl's bootstrapper. I *think* it was a bunch of shell scripts that could put together a minimal C subset compiler, which then could be used to build the rest of GCC. I'm pretty sure it was released as a reaction to the unbundling of C compilers when Unix vendors realized that was a thing they could do. > > I could not find that thing at all. > > Did I hallucinate it? It seems like it would have been an immensely useful tool at the time. > > I ended up writing my own very half-assed deprotoizer and symbol mangler (only the first six characters of the function name were significant, because that's how the TOPS-20 linker works, and I don't know that I could have gotten past that even with an ANSI compiler without having to do significant toolchain work) which got me over the hump, but I have remained curious whether there really was that nifty GCC bootstrapper or whether I made that up. > > Adam -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From athornton at gmail.com Tue Jan 3 05:53:30 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 12:53:30 -0700 Subject: [COFF] [TUHS] A few comments on porting the Bourne shell In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <88f83b4c-b3f9-ed87-b2fa-560fb369742a@makerlisp.com> <20221231035931.GG5825@mcvoy.com> <528f0c53-ccc2-88a1-5a7b-120362c648dd@mhorton.net> <20230102165120.GK25547@mcvoy.com> <20230102174304.GM25547@mcvoy.com> Message-ID: <8328BF52-5885-43F7-95CB-C20C7D0841FC@gmail.com> > On Jan 2, 2023, at 11:48 AM, Dan Cross wrote: > > [Apologies for resending; I messed up and used the old Minnie address > for COFF in the Cc] > > On Mon, Jan 2, 2023 at 1:36 PM Dan Cross wrote: >> >> On Mon, Jan 2, 2023 at 1:13 PM Clem Cole wrote: >>> Maybe this should go to COFF but Adam I fear you are falling into a tap that is easy to fall into - old == unused >>> >>> One of my favorite stores in the computer restoration community is from 5-10 years ago and the LCM+L in Seatle was restoring their CDC-6000 that they got From Purdue. Core memory is difficult to get, so they made a card and physical module that could plug into their system that is both electrically and mechanically equivalent using modern semiconductors. A few weeks later they announced that they had the system running and had built this module. They got approached by the USAF asking if they could get a copy of the design. Seems, there was still a least one CDC-6600 running a particular critical application somewhere. >>> >>> This is similar to the PDP-11s and Vaxen that are supposed to be still in the hydroelectric grid [a few years ago the was an ad for an RSX and VMS programmer to go to Canada running in the Boston newspapers - I know someone that did a small amount of consulting on that one]. >> >> One of my favorite stories along these lines is the train signalling >> system in Melbourne, running on a "PDP-11". I quote PDP-11 because >> that is now virtualized: >> https://www.equicon.de/images/Virtualisierung/LegacyTrainControlSystemStabilization.pdf >> >> Indeed older systems show up in surprising places. I was once on the >> bridge of a US Naval vessel in the late '00s and saw a SPARCstaton 20 >> running Solaris (with the CDE login screen). I don't recall what it >> was doing, but it was a tad surprising. >> >> I do worry about legacy systems in critical situations, but then, I've >> been in a firefight when the damned tactical computer with the satcomm >> link rebooted and we didn't have VHF comms with the battlespace owner. >> That was not particularly fun. And there is certainly no simple relationship between age and likeliness-to-still-work. A couple years ago now, I helped inventory the business space and warehouse of a man who had had a stroke and would thus not be able to continue running his direct mail business. But in 2017, he was running a direct-mail advertising business off an honest-to-god PDP-11/70 and a bunch of ADM-3A terminals. He also had several Vaxen out in his warehouse, a dozen or so TI Silent 700s, and even an 029 card punch. I think his basic philosophy was to buy these machines as they were surplussed and use them for parts, and apparently it worked fine for him until his health failed. I've got what looks to be a pretty pristine VAX-11/730 from the collection, which someday I will get a beefy enough 110V-220V transformer to run (sure, I have 220 to my dryer, but I'm not going to pay to have it run to my office), and an RM-80, which is now a nightstand. I would be very surprised if the VAX wouldn't work with no more than minor capacitor work. I also snagged a Sun 9-track tape drive which came from NOAO and is back home in the correct building, if not the correct office. It's a coffee table now, because I have no half-inch tapes I want to read. If someone does, well, it still powers up and spins the reels. Someone else can sacrifice the goats to get whichever flavor of SCSI it speaks talking to something modern. My annual Elvis' Birthday Party is coming up, which is really a boardgaming and retrogaming party, so I'm going through my stuff trying to figure out what I want to have in Display Mode as guests arrive. A lot of my mid-90s-through-mid-2000s stuff doesn't work anymore, like the original Xbox, and the G5 powermac that suffered from the capacitor plague. But my 80s consoles and 8-bit computers are mostly basically working fine. The blue electron gun on my Bondi Blue iMac has failed, which is sad, the better-built 90s workstations are OK, although the CMOS battery on the SparcStation 10 is long-dead, and the power supplies on pretty much all the Microvax 3000-series need rework (but the VAK4kVLC is running fine, so there is a real VAX to play with). But in general: both machines and magnetic storage prior to 1995 have a good chance of still working (for very occasional duty, anyway), and then there's a decade or so where it's probably dead, and then newer than that is OK again. These things are all extremely fun to play with, but honestly I only ever dust them off a couple times a year. For more-routine retrocomputing jobs (like porting Frotz to TOPS-20), well, emulation doesn't cost me nearly so much electricity, I don't have to deal with fan noise, and I'm not worried about some capacitor somewhere giving up its magic smoke, or just old solder joints finally cracking apart. Because of the magic of Moore's Law, I can run several 36-bit systems at once on a (back in the good old days, when you could actually get them) $50 Raspberry Pi. Note that MetroTrainsMelbourne ended up with PDP-11-on-a-board plugged into Windows XP systems, and some sort of ISA-bus-to-Unibus converter. I wonder what they're doing now? It's always the peripheral support that keeps you running on the original hardware, and from the description and the age of the system I bet the VDU serial links were pretty tightly coupled to the rest of the timetable generator, and I bet that's the hard part to reengineer with equivalent functionality. Me, I would have spent the second 5 years of the extension project paying someone to implement an equivalent (but not necessarily bug-compatible) scheduler and some sort of message-bus-over-TCP/IP-to-small-form-factor-PCs-hidden-behind-HDMI-TVs for the display units, in parallel with the existing system, with particular attention to decoupling production of the schedule data from delivering it to the remote users, so when that 10 years was up, I'd have had something I was confident in switching to that would be cheaply maintainable for a while, and where I could upgrade the display and compute tech individually. But I also suspect management didn't agree to spend their money that way. Adam From athornton at gmail.com Tue Jan 3 07:13:45 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 14:13:45 -0700 Subject: [COFF] [TUHS] Interview question In-Reply-To: <20230102203646.GT25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> Message-ID: <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> > On Jan 2, 2023, at 1:36 PM, Larry McVoy wrote: > > The /bin/sh stuff made me think of an interview question I had for engineers, > that a surprisingly few could pass: > > "Tell me about something you wrote that was entirely you, the docs, the > tests, the source, the installer, everything. It doesn't have to be a > big thing, but it has to have been successfully used by at least 10 > people who had no contact with you (other than to say thanks)." > > Most people fail this. I think the people who pass might look > positively on the v7 sh stuff. But who knows? Huh. That is a surprisingly tricky question, depending on how you want to construe "entirely you". v1 of https://atariage.com/software_page.php?SoftwareLabelID=2023 (before Thomas Jentzsch optimized the display engine) was ... stuff I did, but obviously neither the idea nor the execution was all that original, since I used Greg Troutman's Dark Mage source, which in turn was derived from Stellar Track. There's a certain very large text adventure I once did, which I would certainly not bring up at a real job interview since it's riotously pornographic, but it is 200,000 words of source text, got surprisingly good reviews from many people (Emily Short loved it; Jimmy Maher hated it), and I put it all together myself, but the whole thing is a hodgepodge of T.S. Eliot and The Aeneid and then a few dozen other smaller sources, all tossed in a blender. Not going to directly link it but it's not hard to find with a little Googling. The arrangement is original, sure, but its charm--such as it is--may be that it is in some ways a love letter to early D&D and its "what if Gandalf and Conan teamed up to fight Cthulhu" sort of ethos. (Jimmy Maher found the intertextuality very dense and unappetizing, whereas Emily Short really enjoyed the playfulness.) There's https://github.com/athornton/uCA which fits the criteria but really is a very small wrapper around OpenSSL to automate SAN generation, which is a huge PITA with plain old OpenSSL. Now, of course, you wouldn't bother with this, you'd just use Let's Encrypt, but that wasn't a thing yet. Such as it is it's all me but it is entirely useless without a functional OpenSSL under it. I'm not sure that ten other people ever used https://github.com/athornton/nerdle-solver because there may have been fewer than ten people other than me that found Nerdle all that fascinating. It was fun talking with that community and finding out that the other solver I'm aware of was completely lexical, rather than actually doing the math. But again: it's a thing that makes no sense without someone else having invented Nerdle first. Or there's https://github.com/athornton/tmenu; probably also not actually used by ten other people, but it's the front-end of https://mvsevm.fsf.net (which certainly has been enjoyed by...uh...let's go with "at least a dozen" people). It's original work, insofar as it goes, but it (like uCA) is really just glue between other things: a web server front end, a Javascript terminal emulator, and telnet/tn3270 clients. Which of these, if any, do you count? From lm at mcvoy.com Tue Jan 3 12:58:36 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 2 Jan 2023 18:58:36 -0800 Subject: [COFF] [TUHS] Interview question In-Reply-To: <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> Message-ID: <20230103025836.GZ25547@mcvoy.com> On Mon, Jan 02, 2023 at 02:13:45PM -0700, Adam Thornton wrote: > > > > On Jan 2, 2023, at 1:36 PM, Larry McVoy wrote: > > > > The /bin/sh stuff made me think of an interview question I had for engineers, > > that a surprisingly few could pass: > > > > "Tell me about something you wrote that was entirely you, the docs, the > > tests, the source, the installer, everything. It doesn't have to be a > > big thing, but it has to have been successfully used by at least 10 > > people who had no contact with you (other than to say thanks)." > > > > Most people fail this. I think the people who pass might look > > positively on the v7 sh stuff. But who knows? > > Huh. That is a surprisingly tricky question, depending on how you want to construe "entirely you". > > Which of these, if any, do you count? Any of them that are entirely done by you. Here's an example. I posted move.c and copy.c to comp.sources.unix as an undergrad, a newbie. They let you do stuff like move =.c =.C++ and the = was the wild card. .* in regexp. They were a little better than that because you could have more than one = and could expand with something like \=2 \=1 (it's been 40 years, I might have the details wrong, still have the source, can post). Just did http://mcvoy.com/lm/move.shar I know people used it because later in life it got mentioned. But literally noone ever asked me how to use it or install or anything. It's a tiny thing but it meets what I was looking for. Entirely you means entirely you. If you have done that, you are in a pretty small crowd. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From dave at horsfall.org Tue Jan 3 16:06:26 2023 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 3 Jan 2023 17:06:26 +1100 (EST) Subject: [COFF] [TUHS] Interview question In-Reply-To: <20230103025836.GZ25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> Message-ID: On Mon, 2 Jan 2023, Larry McVoy wrote: > Any of them that are entirely done by you. Here's an example. I posted > move.c and copy.c to comp.sources.unix as an undergrad, a newbie. They > let you do stuff like > > move =.c =.C++ [..] Many moons ago someone posted a script on aus.sources that did something like that i.e. based upon PIP; I'll try and dig it out. -- Dave From athornton at gmail.com Tue Jan 3 16:16:42 2023 From: athornton at gmail.com (Adam Thornton) Date: Mon, 2 Jan 2023 23:16:42 -0700 Subject: [COFF] [TUHS] Interview question In-Reply-To: <20230103025836.GZ25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> Message-ID: <5A66D49E-56F8-499A-B4E3-6673570B25EA@gmail.com> > On Jan 2, 2023, at 7:58 PM, Larry McVoy wrote: > > On Mon, Jan 02, 2023 at 02:13:45PM -0700, Adam Thornton wrote: >> >> >> Which of these, if any, do you count? > > Any of them that are entirely done by you. Well, then, all of the ones I listed, if you'll spot me the Fellowship Of The Ring Atari 2600 cartridge before Thomas Jentzsch got me a little more display space, even though the cartridge you can buy (and the sources available online) are the later version. None of those are world-changing, and, for instance, I'm a lot more proud of the current state of JupyterHub Kubespawner, which wasn't mine to start with, but first I added per-user namespaces and upstreamed that, and then I changed it from threads to coroutines, and upstreamed _that_. The second change has made it a lot more reliable for everyone (the first was useful for Rubin Observatory and people doing things like we do, but not generally useful for JupyterHub under Kubernetes). But both of those were building on (a lot of) existing work and were also made a whole lot better by review commentary from my team. Special thanks to Russ Allbery who was quoted on TUHS a couple days ago, who really, really helped with the thread->coroutine conversion. Sure, I can do decent work on my own, but other people helping me out improves it immensely. I know that I tend to: a) under-test, b) write huge functions and source files when I should be doing things with more granularity, c) write like it's 1979 and keystrokes are precious and use nondescriptive variable names which make things hard to read. Review of my work helps with all of these. Adam From imp at bsdimp.com Wed Jan 4 01:57:42 2023 From: imp at bsdimp.com (Warner Losh) Date: Tue, 3 Jan 2023 08:57:42 -0700 Subject: [COFF] [TUHS] Interview question In-Reply-To: <20230103025836.GZ25547@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> Message-ID: On Mon, Jan 2, 2023 at 7:59 PM Larry McVoy wrote: > On Mon, Jan 02, 2023 at 02:13:45PM -0700, Adam Thornton wrote: > > Which of these, if any, do you count? > > Any of them that are entirely done by you. > With due respect, this seems like an impossible thing to have done. I think it's an arbitrary question. "No man is an Island" John Donne. Nobody on this list can claim to have anything they did entirely by themselves. Everybody used tools built by others. Everybody used an OS built by others. Even people that did a full OS + all the tools used other tools to boostrap that were done by others. They used hardware that was designed by others, made from chips made by others from raw materials mined by others. We all "stand on the shoulders of giants"[*]. While I get the connection to looking for someone that's independent, self sufficient, etc, it seems a bit arbitrary. I've done a ton of work on the FreeBSD kernel, for example, but it isn't all 100% me. Others have contributed to it, others have reviewed my work, others have given me (or the project) bug fixes. That project, as with so many others, are so much better due to the collaboration that happened between people. In many ways that's more important than doing something 100% yourself. Warner [*] "If I have seen further it is by standing on the sholders[sic] of others" -- Isaac Newton in a 1675 letter to his rival Robert Hooke -------------- next part -------------- An HTML attachment was scrubbed... URL: From coff at tuhs.org Wed Jan 4 05:53:29 2023 From: coff at tuhs.org (segaloco via COFF) Date: Tue, 03 Jan 2023 19:53:29 +0000 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> Message-ID: I like the way Carl Sagan put it: "If you wish to make an apple pie from scratch, you must first invent the universe" I've contended with this a lot in my experiences learning computing, programming, etc. Luckily my earliest interest was in embedded platforms (video game consoles specifically) so from an early point in my study I was already much familiar with the idea of a computer being a mindless piece of inorganic matter we overlay structure on in the form of programs. What that's lead to though is a neverending desire to avoid cruft and outside resources in general, which I've thus far found impossible. Yeah I might replace a driver for a device, but that driver talks through a kernel someone else wrote. Yeah I might replace a kernel subsystem, but it still interacts with everything else. Heck, I might write a kernel, but I'm certainly not writing myself a new browser to run it, I'd be bound to at least providing the same interfaces as others to do anything effective. Even still, that kernel, running on a modern CPU, is probably sitting up on top of at the very least microcode and perhaps even a BIOS or other firmware, neither of which I control. Going even further, say I write a game for the Sega Mega Drive. That console maps the ROM cartridge into low-core, so from the moment the CPU hits the RESET vector, it's my code, and this still​ wouldn't be entirely my own. The algorithms internally applied by various ICs on the board based on what I put in the registers aren't mine. It's not like I'm manually bit blasting the analog CVBS signal being pooped out the back of the thing, someone at Ti and/or Sega decided how that works and packaged it in a nice little video display chip for me. I could write every lick of 68000 code that the CPU touches from poweron to poweroff and still wouldn't be solely responsible for the end result. I'm not responsible for determining efficient blitting routines, scrollplane population, FM synthesis calculations, analog signal generation, nor most of the synchronization. That belongs to engineers at Sega, Ti, and whoever else was involved. This speaks to the necessity of good documentation, because any given part of a system becomes relevant when trying to understand it holistically and truly work "from scratch" on things, because any decision you don't make is still a decision you have to be aware of. There's no aspect of a design that won't be relevant to a consumer of that design at some point, that's why it's there after all. Even with side effects, it's better to understand them than not, as it's almost guaranteed if there is a corner that can be cut somewhere, not only is someone going to figure out how to cut it, they're going to make a mission critical decision based on it and blame the creator when it doesn't work. - Matt G. ------- Original Message ------- On Tuesday, January 3rd, 2023 at 7:57 AM, Warner Losh wrote: > On Mon, Jan 2, 2023 at 7:59 PM Larry McVoy wrote: > >> On Mon, Jan 02, 2023 at 02:13:45PM -0700, Adam Thornton wrote: >>> Which of these, if any, do you count? >> >> Any of them that are entirely done by you. > > With due respect, this seems like an impossible thing to have done. I think it's an arbitrary question. > > "No man is an Island" John Donne. > > Nobody on this list can claim to have anything they did entirely by themselves. Everybody used tools built by others. Everybody used an OS built by others. Even people that did a full OS + all the tools used other tools to boostrap that were done by others. They used hardware that was designed by others, made from chips made by others from raw materials mined by others. > > We all "stand on the shoulders of giants"[*]. While I get the connection to looking for someone that's independent, self sufficient, etc, it seems a bit arbitrary. I've done a ton of work on the FreeBSD kernel, for example, but it isn't all 100% me. Others have contributed to it, others have reviewed my work, others have given me (or the project) bug fixes. That project, as with so many others, are so much better due to the collaboration that happened between people. In many ways that's more important than doing something 100% yourself. > > Warner > > [*] "If I have seen further it is by standing on the sholders[sic] of others" -- Isaac Newton in a 1675 letter to his rival Robert Hooke -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Jan 4 09:02:42 2023 From: athornton at gmail.com (Adam Thornton) Date: Tue, 3 Jan 2023 16:02:42 -0700 Subject: [COFF] [TUHS] Re: Command Line Editing in the Terminal Driver (Was: A few comments on porting the Bourne shell) In-Reply-To: References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> <464819f0-d2f6-2a60-6481-a194f4428b4d@case.edu> <20221230200246.GW5825@mcvoy.com> <8ca17d52-a25a-dbbf-e1f0-d743b8884cfa@in-ulm.de> Message-ID: (moving to COFF) On Tue, Jan 3, 2023 at 9:55 AM Marshall Conover wrote: > Along these lines but not quite, Jupyter Notebooks have stood out to me as > another approach to this concept, with behavior I'd like to see implemented > in a shell. > > Well, you know, if you're OK with bash: https://github.com/takluyver/bash_kernel Or zsh: https://pypi.org/project/zsh-jupyter-kernel/ One of the big things I do is work on the Notebook Aspect of the Rubin Science Platform. Each JupyterLab notebook session is tied to a "kernel" which is a specific language-and-extension environment. At the Rubin Observatory, we support a Python 3.10 environment with our processing pipeline included. Although JupyterLab itself is capable of doing other languages (notably Julia and R, which are the other two from which the name "Jupyter" came), many others have been adapted to the notebook environment (including at least the two shells above). And while researchers are welcome to write their own code and work with raw images, we work under the presumption that almost everyone is going to use the software tools the Rubin Observatory provides to work with the data it collects, because writing your own data processing pipeline from scratch is a pretty monumental project. Most astronomers are perfectly happy with what we provide, which is Python plus our processing pipelines, which are all Python from the scientist-facing perspective (much of the pipeline code is implemented in C++ for speed, but it then gets Python bindings, so unless you're actually working very deep down in the image processing code, it's Python as far as you're concerned). However, a certain class of astronomers still loves their FORTRAN. This class, unfortunately, tends to be the older ones, which means the ones who have societal stature, tenure, can relatively easily get big grants, and wield a lot of power within their institutions. I know that it is *possible* to run gfortran as a Jupyter kernel. I've seen it done. I was impressed. Fortunately, no one with the power to make it stick has demanded we provide a kernel like that. The initial provision of the service wouldn't be the problem. It's that the support would be a nightmare. No one on my team is great at FORTRAN; I'm probably the closest to fluent, and I'm not very, and I really don't enjoy working in FORTRAN, and because FORTRAN really doesn't lend itself easily to the kind of Python REPL exploration that notebooks are all about, and because someone who loves FORTRAN and hates Python probably has a very different concept of what good software engineering practices look like than I do, trying to support someone working in a notebook environment in a FORTRAN kernel would very likely be exquisitely painful. And fortunately, since there are not FORTRAN bindings to the C++ classes providing the core algorithms, much less FORTRAN bindings to the Python implementations (because all the things that don't particularly need to be fast are just written in Python in the first place), a gfortran kernel wouldn't be nearly as useful as our Python-plus-our-tools. Now, sure, if we had paying customers who were willing to throw enough money at us to make it worth the pain and both bring a FORTRAN implementation to feature-parity with the reference environment and make a gfortran kernel available, then we would do it. But I get paid a salary that is not directly tied to my support burden, and I get to spend a lot more of my time working on fun things and providing features for astronomers who are not mired in 1978 if I can avoid spending my time supporting huge time sinks that aren't in widespread use. We are scoped to provide Python. We are not scoped to provide FORTRAN. We are not making money off of sales: we're employed to provide stable infrastructure services so the scientists using our platform and observatory can get their research done. And thus far we've been successful in saying "hey, we've got finite resources, we're not swimming in spare cycles, no, we can't support [ x for x in things-someone-wants-but-are-not-in-the-documented-scope ]". (To be fair, this has more often been things like additional visualization libraries than whole new languages, but the principle is the same.) We have a process for proposing items for inclusion, and it's not at all rare that we add them, but it's generally a considered decision about how generally useful the proposed item will be for the project as a whole and how much time it's likely to consume to support. So this gave me a little satori about why I think POSIX.2 is a perfectly reasonable spec to support and why I'm not wild about making all my shell scripts instead compatible with the subset of v7 sh that works (almost) everywhere. It's not all that much more work up front, but odds are that a customer that wants to run new software, but who can't guarantee a POSIX /bin/sh, will be a much more costly customer to support than one who can, just as someone who wants a notebook environment but insists on FORTRAN in it is very likely going to be much harder to support than someone who's happy with the Python environment we already supply. Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Jan 4 12:44:42 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 3 Jan 2023 18:44:42 -0800 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> Message-ID: On Jan 3, 2023, at 7:57 AM, Warner Losh wrote: > > > > On Mon, Jan 2, 2023 at 7:59 PM Larry McVoy > wrote: >> On Mon, Jan 02, 2023 at 02:13:45PM -0700, Adam Thornton wrote: >> > Which of these, if any, do you count? >> >> Any of them that are entirely done by you. > > With due respect, this seems like an impossible thing to have done. I think it's an arbitrary question. I see the point of Larry asking this. Presumably it is *one* of the questions he asks! There are a lot of smart people who don't know or don't have experience with how to deliver a product. Product delivery is a lot more than hacking up some code. It is writing good design and user documentation, thorough testing, lots of trial and error to make the UI/GUI as intuitive as possible, making it as bug free as possible, may be even dealing with customer bug reports and requests etc. etc. At least to me it would not be a pass/fail question (IMHO there is no point in asking such questions to an interviewee). > "No man is an Island" John Donne. > > Nobody on this list can claim to have anything they did entirely by themselves. Everybody used tools built by others. Everybody used an OS built by others. Even people that did a full OS + all the tools used other tools to boostrap that were done by others. They used hardware that was designed by others, made from chips made by others from raw materials mined by others. Right but even with a complete set of tools and detailed plans not everyone can do good carpentry. It requires care, knowing your craft, knowing what shortcuts you can take, knowing who to ask for advice etc. etc. And it is a different challenge when you have to make a dozen matching chairs as opposed to one. When I was interviewing people my job was to assess their experience, abilities & aptitude. Nobody is perfect so you have to find where they would be a good fit in some job for which there is an opening, as well as whether it is of sufficiently interesting/challenging for them etc. > We all "stand on the shoulders of giants"[*]. While I get the connection to looking for someone that's independent, self sufficient, etc, it seems a bit arbitrary. I've done a ton of work on the FreeBSD kernel, for example, but it isn't all 100% me. Others have contributed to it, others have reviewed my work, others have given me (or the project) bug fixes. That project, as with so many others, are so much better due to the collaboration that happened between people. In many ways that's more important than doing something 100% yourself. > > Warner > > [*] "If I have seen further it is by standing on the sholders[sic] of others" -- Isaac Newton in a 1675 letter to his rival Robert Hooke -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Jan 4 13:06:10 2023 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 3 Jan 2023 19:06:10 -0800 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> Message-ID: <20230104030610.GB25689@mcvoy.com> Bakul gets it. "Entirely by you" does not mean "go get some sand because you need to make some silicon ..." "Entirely by you" means given a set of tools, show me what you did. Just you. Not your team, just you. It's not an arbitrary question, Warner, it's giving people have done it a chance to say so. And weeding out the people who haven't. Which is not a great way to sort people in general, it was a great way to sort people for my 12 person company. We needed people who could do that, we were too small for people who couldn't. And Bakul, yes, I asked a lot of other questions. The only other one that came up repeatedly was the "Safeway question". What's that? If you saw a coworker at the store, do you go talk to them or do you hide in another aisle and hope they don't see you? There is your hire/don't hire answer. Bill Moore's question was "If we need you to, will you sweep the floors?" My 2 manager interview questions were: If we hire you, who is going to come with you (good managers always have people who love them and follow them. Bad managers don't). Tell me about the hardest time you had when you had to fire someone. (I had people who wanted to be my VP of engineering who had never had to fire anyone. And it wasn't because they were awesome, it was because they had no experience). Firing people, without it blowing up in your face, is hard. On Tue, Jan 03, 2023 at 06:44:42PM -0800, Bakul Shah wrote: > On Jan 3, 2023, at 7:57 AM, Warner Losh wrote: > > On Mon, Jan 2, 2023 at 7:59 PM Larry McVoy > wrote: > >> On Mon, Jan 02, 2023 at 02:13:45PM -0700, Adam Thornton wrote: > >> > Which of these, if any, do you count? > >> > >> Any of them that are entirely done by you. > > > > With due respect, this seems like an impossible thing to have done. I think it's an arbitrary question. > > I see the point of Larry asking this. Presumably it is *one* of the questions he asks! There are a lot of smart people who don't know or don't have experience with how to deliver a product. Product delivery is a lot more than hacking up some code. It is writing good design and user documentation, thorough testing, lots of trial and error to make the UI/GUI as intuitive as possible, making it as bug free as possible, may be even dealing with customer bug reports and requests etc. etc. At least to me it would not be a pass/fail question (IMHO there is no point in asking such questions to an interviewee). > > > "No man is an Island" John Donne. > > > > Nobody on this list can claim to have anything they did entirely by themselves. Everybody used tools built by others. Everybody used an OS built by others. Even people that did a full OS + all the tools used other tools to boostrap that were done by others. They used hardware that was designed by others, made from chips made by others from raw materials mined by others. > > Right but even with a complete set of tools and detailed plans not everyone can do good carpentry. It requires care, knowing your craft, knowing what shortcuts you can take, knowing who to ask for advice etc. etc. And it is a different challenge when you have to make a dozen matching chairs as opposed to one. > > When I was interviewing people my job was to assess their experience, abilities & aptitude. Nobody is perfect so you have to find where they would be a good fit in some job for which there is an opening, as well as whether it is of sufficiently interesting/challenging for them etc. > > > We all "stand on the shoulders of giants"[*]. While I get the connection to looking for someone that's independent, self sufficient, etc, it seems a bit arbitrary. I've done a ton of work on the FreeBSD kernel, for example, but it isn't all 100% me. Others have contributed to it, others have reviewed my work, others have given me (or the project) bug fixes. That project, as with so many others, are so much better due to the collaboration that happened between people. In many ways that's more important than doing something 100% yourself. > > > > Warner > > > > [*] "If I have seen further it is by standing on the sholders[sic] of others" -- Isaac Newton in a 1675 letter to his rival Robert Hooke > > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Thu Jan 5 01:42:03 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 4 Jan 2023 10:42:03 -0500 Subject: [COFF] [TUHS] Interview question In-Reply-To: <20230104030610.GB25689@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> <20230104030610.GB25689@mcvoy.com> Message-ID: On Tue, Jan 3, 2023 at 10:06 PM Larry McVoy wrote: > Bakul gets it. "Entirely by you" does not mean "go get some sand > because you need to make some silicon ..." > > "Entirely by you" means given a set of tools, show me what you did. > Just you. Not your team, just you. Hmm. I've worked on projects where all code had to be reviewed prior to submission into a shared repository (though there was a carve-out for a little experimental area). In that context, how does one define "just you"? > It's not an arbitrary question, Warner, it's giving people have done > it a chance to say so. And weeding out the people who haven't. > > Which is not a great way to sort people in general, it was a great > way to sort people for my 12 person company. We needed people who > could do that, we were too small for people who couldn't. It seems to me that the outcome is more important than the specifics of this exercise. Reading between the lines, it sounds like you were using this as a proxy for whether someone can come in and start contributing largely unguided and without a lot of handholding, and drive something to completion without a lot of external help. That's all well and good, but I don't know if this is the best way to assess that; as worded, it sounds mostly like you're asking if someone has built some tool explicitly used by (at least?) a few other people, but some people make much bigger contributions with much higher impact in very complex systems without ever doing that. I think Warner's point is sound: you're building something within a framework/system/design/whatever that's been shaped by many others before you; what is the meaning of an individual contribution in that sense? In some sense, I've written software used by billions of people, but they would never know that. I remember when my late mother called me once and said, "I saw that Google was in the news for doing , was that you?" and I replied, "mom, if you ever hear about anything that I did at Google in the news, then I messed up very badly and I'm really in a lot of trouble and probably looking for a new job." "Oh," my crestfallen mother said, "I told my friends you worked on that." "Sorry, ma." Internally, I might have built something or changed something used by tens of thousands of engineers, well-documented, etc, but again, most wouldn't think about it that way; most of them wouldn't even know. Warner's example of working inside the FreeBSD kernel similarly: that's used in all kinds of places by many, many people, but most don't give a second thought to wondering how it works. > And Bakul, yes, I asked a lot of other questions. The only other one that > came up repeatedly was the "Safeway question". What's that? If you saw > a coworker at the store, do you go talk to them or do you hide in another > aisle and hope they don't see you? There is your hire/don't hire answer. Ha! Which is the right answer? :-) Seriously, though, this seems highly contextually dependent: I see folks I now around town not infrequently, and I generally smile and nod or say hello if I catch their eye, but if they look like they're in a rush or are shepherding a couple of screaming kids, I'm not going to bother them. > Bill Moore's question was "If we need you to, will you sweep the floors?" This better be well contextualized. Does this mean, "we're a small organization and everyone needs to be willing to pitch in as needed?" or does it mean, "are you willing to prostrate yourself before the altar of this organization in order to prove yourself?" If the former, sure. If the latter, then no: sorry, I've done my time in more ways than one, including literally sweeping and mopping the floors (and cleaning the head) in the Marines. There's a tendency in technology to basically haze the friendly new guy; I'm done with that. - Dan C. From imp at bsdimp.com Thu Jan 5 02:00:17 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 4 Jan 2023 09:00:17 -0700 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> <20230104030610.GB25689@mcvoy.com> Message-ID: On Wed, Jan 4, 2023 at 8:44 AM Dan Cross wrote: > > Bill Moore's question was "If we need you to, will you sweep the floors?" > > This better be well contextualized. Does this mean, "we're a small > organization and everyone needs to be willing to pitch in as needed?" > or does it mean, "are you willing to prostrate yourself before the > altar of this organization in order to prove yourself?" If the former, > sure. If the latter, then no: sorry, I've done my time in more ways > than one, including literally sweeping and mopping the floors (and > cleaning the head) in the Marines. There's a tendency in technology to > basically haze the friendly new guy; I'm done with that. > The best programmers I've ever worked with understood teamwork and the team produced something way better than what any one of us could do (this was back in the days before egoless programming, CI, code reviews, etc), so we invented the bits that worked for us on the fly). The thing is, every single person on that team could (and often did) work on any aspect of the product, be it the documentation (though the tech writers usually did that), the code (the programmers usually did that, but the tech writers committed fixes to the example code that was in the book), to the printer being out of toner / paper, the soda supply in closet running out, the snacks that we got at costco running low, stuffing product into boxes to ship to customers, handling customer calls, dealing with talking to customers at a technical conference in a sales booth, presenting papers at conferences, etc. Nobody did anything entirely by themselves. We interviewed several 'lone wolves' that had done it all, but found the one we hired couldn't integrate into our pack because they couldn't be part of a team and put the team first and the group needs ahead of their own. That's the Genesis of my mistrust of this question, or at least the premise behind it. And Dan, these 'scut tasks' weren't about hazing, but just about doing what needed to be done... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Jan 5 02:06:42 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 4 Jan 2023 08:06:42 -0800 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> <20230104030610.GB25689@mcvoy.com> Message-ID: <20230104160642.GF25689@mcvoy.com> I think people are bike shedding this so I'm gonna let it go. What worked for me might not work for you, so be it. You guys have fun. On Wed, Jan 04, 2023 at 10:42:03AM -0500, Dan Cross wrote: > On Tue, Jan 3, 2023 at 10:06 PM Larry McVoy wrote: > > Bakul gets it. "Entirely by you" does not mean "go get some sand > > because you need to make some silicon ..." > > > > "Entirely by you" means given a set of tools, show me what you did. > > Just you. Not your team, just you. > > Hmm. I've worked on projects where all code had to be reviewed prior > to submission into a shared repository (though there was a carve-out > for a little experimental area). In that context, how does one define > "just you"? > > > It's not an arbitrary question, Warner, it's giving people have done > > it a chance to say so. And weeding out the people who haven't. > > > > Which is not a great way to sort people in general, it was a great > > way to sort people for my 12 person company. We needed people who > > could do that, we were too small for people who couldn't. > > It seems to me that the outcome is more important than the specifics > of this exercise. Reading between the lines, it sounds like you were > using this as a proxy for whether someone can come in and start > contributing largely unguided and without a lot of handholding, and > drive something to completion without a lot of external help. That's > all well and good, but I don't know if this is the best way to assess > that; as worded, it sounds mostly like you're asking if someone has > built some tool explicitly used by (at least?) a few other people, but > some people make much bigger contributions with much higher impact in > very complex systems without ever doing that. > > I think Warner's point is sound: you're building something within a > framework/system/design/whatever that's been shaped by many others > before you; what is the meaning of an individual contribution in that > sense? In some sense, I've written software used by billions of > people, but they would never know that. I remember when my late mother > called me once and said, "I saw that Google was in the news for doing > , was that you?" and I replied, "mom, if you ever hear > about anything that I did at Google in the news, then I messed up very > badly and I'm really in a lot of trouble and probably looking for a > new job." "Oh," my crestfallen mother said, "I told my friends you > worked on that." "Sorry, ma." Internally, I might have built something > or changed something used by tens of thousands of engineers, > well-documented, etc, but again, most wouldn't think about it that > way; most of them wouldn't even know. Warner's example of working > inside the FreeBSD kernel similarly: that's used in all kinds of > places by many, many people, but most don't give a second thought to > wondering how it works. > > > And Bakul, yes, I asked a lot of other questions. The only other one that > > came up repeatedly was the "Safeway question". What's that? If you saw > > a coworker at the store, do you go talk to them or do you hide in another > > aisle and hope they don't see you? There is your hire/don't hire answer. > > Ha! Which is the right answer? :-) > > Seriously, though, this seems highly contextually dependent: I see > folks I now around town not infrequently, and I generally smile and > nod or say hello if I catch their eye, but if they look like they're > in a rush or are shepherding a couple of screaming kids, I'm not going > to bother them. > > > Bill Moore's question was "If we need you to, will you sweep the floors?" > > This better be well contextualized. Does this mean, "we're a small > organization and everyone needs to be willing to pitch in as needed?" > or does it mean, "are you willing to prostrate yourself before the > altar of this organization in order to prove yourself?" If the former, > sure. If the latter, then no: sorry, I've done my time in more ways > than one, including literally sweeping and mopping the floors (and > cleaning the head) in the Marines. There's a tendency in technology to > basically haze the friendly new guy; I'm done with that. > > - Dan C. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Thu Jan 5 02:52:53 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 4 Jan 2023 11:52:53 -0500 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> <20230104030610.GB25689@mcvoy.com> Message-ID: On Wed, Jan 4, 2023 at 11:00 AM Warner Losh wrote: > On Wed, Jan 4, 2023 at 8:44 AM Dan Cross wrote: >> > Bill Moore's question was "If we need you to, will you sweep the floors?" >> >> This better be well contextualized. Does this mean, "we're a small >> organization and everyone needs to be willing to pitch in as needed?" >> or does it mean, "are you willing to prostrate yourself before the >> altar of this organization in order to prove yourself?" If the former, >> sure. If the latter, then no: sorry, I've done my time in more ways >> than one, including literally sweeping and mopping the floors (and >> cleaning the head) in the Marines. There's a tendency in technology to >> basically haze the friendly new guy; I'm done with that. > > The best programmers I've ever worked with understood teamwork and the team produced something way better than what any one of us could do (this was back in the days before egoless programming, CI, code reviews, etc), so we invented the bits that worked for us on the fly). The thing is, every single person on that team could (and often did) work on any aspect of the product, be it the documentation (though the tech writers usually did that), the code (the programmers usually did that, but the tech writers committed fixes to the example code that was in the book), to the printer being out of toner / paper, the soda supply in closet running out, the snacks that we got at costco running low, stuffing product into boxes to ship to customers, handling customer calls, dealing with talking to customers at a technical conference in a sales booth, presenting papers at conferences, etc. Nobody did anything entirely by themselves. We interviewed several 'lone wolves' that had done it all, but found the one we hired couldn't integrate into our pack because they couldn't be part of a team and put the team first and the group needs ahead of their own. That's the Genesis of my mistrust of this question, or at least the premise behind it. And Dan, these 'scut tasks' weren't about hazing, but just about doing what needed to be done... Perhaps I was not clear. What you are describing sounds more like what I meant when I wrote, 'does this mean, "we're a small organization and everyone needs to be willing to pitch in as needed?"' That's fine; if it needs to be done, it needs to be done. Sometimes that _may_ mean literally sweeping the floor. But too often I've observed what I've taken to calling, "the old school Unix mentality": putting people in a pecking order based on mostly arbitrary criteria, forming an in-group (and implicitly an out-group) and expecting people to grovel to get into the in-group. This is the opposite of teamwork, it's garbage treatment of people, and I'm not interested in it anymore. Here's a literal example of what I mean. From a "pattern" actually called "Sweep the Floor" at https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch04.html: | Playing the role of a traditional apprentice also helped me to | build up humility and respect for the senior craftsmen. I remember | Uncle Bob Martin came into a room, saw the trash overflowing, | and changed the garbage bag. My mentor scolded me and | appropriately said that it is not the job of the master craftsman to | take out the garbage. It is a sign of respect and piety that was an | important lesson for me to learn. Yeah, no. Robert C Martin can take out his own trash, thank you very much. And the "mentor" can hire custodial workers. This is highly inappropriate and the person who wrote this should have walked. Again, I've paid my dues in this department. - Dan C. From coff at tuhs.org Thu Jan 5 02:58:14 2023 From: coff at tuhs.org (segaloco via COFF) Date: Wed, 04 Jan 2023 16:58:14 +0000 Subject: [COFF] [TUHS] Interview question In-Reply-To: <20230104160642.GF25689@mcvoy.com> References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> <20230104030610.GB25689@mcvoy.com> <20230104160642.GF25689@mcvoy.com> Message-ID: I do like the conversation that has spun up here and I think a good takeaway is that different projects require different workmanship. Different goals hinge on different ideas of what a team should look like and how work is delegated. The question on what one would do upon seeing a coworker some random place out in public is quite an interesting one these days what with remote work and all. Admittedly there are a few coworkers I've done on-site assignments with in the past that I'd be encouraged to know were around and bump into every now and then, but by and large it would feel uncomfortable and awkward just by default. As grateful as I am to have the sort of flexibility this work style allows, there's a part of me that feels hobbled by not having a big table to gather the team around and a white board at the end of the room to scribble all sorts of ideas on. Oh for the day that I could find a local software job... As for the sweeping, I'll echo other sentiments that it depends on whether it's a genuine need or an exercise in authority. The former, of course, I care about the cleanliness of my space and would be one of the first to grab a mop when there's a problem. On the flip side though, I've never sat well with completely arbitrary authority, and so if I see a legitimate reason to not do something, I most certainly will say so. Granted, I've been of the persuasion for a while that the mindless drone direction is not the key to success and that sometimes you just have to exercise the expertise you've been trusted with, even if that means telling the boss something they don't want to hear. They pay you to be the best at what you do (hopefully) so should hopefully expect dissent when it is warranted. This was an area that took some adjusting to in my early working days, that a good supervisor is encouraging of criticism or alternative suggestions when those come from a place of sound reasoning, and that only a fool would dictate over any and all concerns voiced by those who will be doing the work. - Matt G. ------- Original Message ------- On Wednesday, January 4th, 2023 at 8:06 AM, Larry McVoy wrote: > I think people are bike shedding this so I'm gonna let it go. What > worked for me might not work for you, so be it. You guys have fun. > > On Wed, Jan 04, 2023 at 10:42:03AM -0500, Dan Cross wrote: > > > On Tue, Jan 3, 2023 at 10:06 PM Larry McVoy lm at mcvoy.com wrote: > > > > > Bakul gets it. "Entirely by you" does not mean "go get some sand > > > because you need to make some silicon ..." > > > > > > "Entirely by you" means given a set of tools, show me what you did. > > > Just you. Not your team, just you. > > > > Hmm. I've worked on projects where all code had to be reviewed prior > > to submission into a shared repository (though there was a carve-out > > for a little experimental area). In that context, how does one define > > "just you"? > > > > > It's not an arbitrary question, Warner, it's giving people have done > > > it a chance to say so. And weeding out the people who haven't. > > > > > > Which is not a great way to sort people in general, it was a great > > > way to sort people for my 12 person company. We needed people who > > > could do that, we were too small for people who couldn't. > > > > It seems to me that the outcome is more important than the specifics > > of this exercise. Reading between the lines, it sounds like you were > > using this as a proxy for whether someone can come in and start > > contributing largely unguided and without a lot of handholding, and > > drive something to completion without a lot of external help. That's > > all well and good, but I don't know if this is the best way to assess > > that; as worded, it sounds mostly like you're asking if someone has > > built some tool explicitly used by (at least?) a few other people, but > > some people make much bigger contributions with much higher impact in > > very complex systems without ever doing that. > > > > I think Warner's point is sound: you're building something within a > > framework/system/design/whatever that's been shaped by many others > > before you; what is the meaning of an individual contribution in that > > sense? In some sense, I've written software used by billions of > > people, but they would never know that. I remember when my late mother > > called me once and said, "I saw that Google was in the news for doing > > , was that you?" and I replied, "mom, if you ever hear > > about anything that I did at Google in the news, then I messed up very > > badly and I'm really in a lot of trouble and probably looking for a > > new job." "Oh," my crestfallen mother said, "I told my friends you > > worked on that." "Sorry, ma." Internally, I might have built something > > or changed something used by tens of thousands of engineers, > > well-documented, etc, but again, most wouldn't think about it that > > way; most of them wouldn't even know. Warner's example of working > > inside the FreeBSD kernel similarly: that's used in all kinds of > > places by many, many people, but most don't give a second thought to > > wondering how it works. > > > > > And Bakul, yes, I asked a lot of other questions. The only other one that > > > came up repeatedly was the "Safeway question". What's that? If you saw > > > a coworker at the store, do you go talk to them or do you hide in another > > > aisle and hope they don't see you? There is your hire/don't hire answer. > > > > Ha! Which is the right answer? :-) > > > > Seriously, though, this seems highly contextually dependent: I see > > folks I now around town not infrequently, and I generally smile and > > nod or say hello if I catch their eye, but if they look like they're > > in a rush or are shepherding a couple of screaming kids, I'm not going > > to bother them. > > > > > Bill Moore's question was "If we need you to, will you sweep the floors?" > > > > This better be well contextualized. Does this mean, "we're a small > > organization and everyone needs to be willing to pitch in as needed?" > > or does it mean, "are you willing to prostrate yourself before the > > altar of this organization in order to prove yourself?" If the former, > > sure. If the latter, then no: sorry, I've done my time in more ways > > than one, including literally sweeping and mopping the floors (and > > cleaning the head) in the Marines. There's a tendency in technology to > > basically haze the friendly new guy; I'm done with that. > > > > - Dan C. > > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From athornton at gmail.com Thu Jan 5 03:51:08 2023 From: athornton at gmail.com (Adam Thornton) Date: Wed, 4 Jan 2023 10:51:08 -0700 Subject: [COFF] [TUHS] Interview question In-Reply-To: References: <20230102203646.GT25547@mcvoy.com> <7AC50DD1-DAB2-443A-B275-E3FB08031167@gmail.com> <20230103025836.GZ25547@mcvoy.com> <20230104030610.GB25689@mcvoy.com> Message-ID: <5F32EB3A-A50F-4996-84DB-6B3DC2BFA96A@gmail.com> > On Jan 4, 2023, at 9:00 AM, Warner Losh wrote: > > The best programmers I've ever worked with understood teamwork and the team produced something way better than what any one of us could do (this was back in the days before egoless programming, CI, code reviews, etc), so we invented the bits that worked for us on the fly). The thing is, every single person on that team could (and often did) work on any aspect of the product, be it the documentation (though the tech writers usually did that), the code (the programmers usually did that, but the tech writers committed fixes to the example code that was in the book), to the printer being out of toner / paper, the soda supply in closet running out, the snacks that we got at costco running low, stuffing product into boxes to ship to customers, handling customer calls, dealing with talking to customers at a technical conference in a sales booth, presenting papers at conferences, etc. Nobody did anything entirely by themselves. We interviewed several 'lone wolves' that had done it all, but found the one we hired couldn't integrate into our pack because they couldn't be part of a team and put the team first and the group needs ahead of their own. That's the Genesis of my mistrust of this question, or at least the premise behind it. And Dan, these 'scut tasks' weren't about hazing, but just about doing what needed to be done... One of the things that makes working in my team at the Rubin Observatory the best job I've ever had is that our manager is brilliant at hiring smart generalists who can play nice together. It's not that we can all do everything: I'm pretty terrible at RDBM stuff, for instance (I have learned a fair bit about time-series databases in the last year), but in a pinch, we can step in and try and get each other unstuck, and between all of us we have a lot of experience and our hunches have gotten pretty good. And honestly, it's just a lot more fun to have other people to bounce ideas off of and to make the stuff I'm writing better through thoughtful code reviews. Sure, I have done solo projects that saw the light of day, some very very large (that text adventure is the second-biggest Inform 7 project I'm aware of, and it took a decade or so of free-time screwing around, on and off; it's got a good-sized novella, anyway, of text displayed to the player, and all the logic wrapped around that probably doubles the size[*]), but the stuff I am most proud of currently (which is the conversion of the JupyterHub Kubespawner to coroutines) was a maintenance project. I didn't own the original codebase, my work went through several rounds of internal review before we submitted it upstream, and then it went through a couple more rounds of review with the project maintainers before they accepted it. But accept it they did, and our spawn error rate is less than 10% of what it was with the thread-based version. And to get that last 10% down significantly farther we're going to have to abandon their spawning model entirely, which is the right decision for the Rubin Observatory but almost certainly the wrong one for the vast majority of sites who want to run JupyterHub/Lab under K8s. Adam [*] Inform 7 is a weird language. It's fundamentally declarative, and in some sense wants to make the experience of writing a text adventure a lot like the experience of playing a text adventure. From g.branden.robinson at gmail.com Sat Jan 7 02:38:40 2023 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Fri, 6 Jan 2023 10:38:40 -0600 Subject: [COFF] Microware's OS-9 (was: [TUHS] Clever code) In-Reply-To: References: <20221214151444.niv5xtnxlmoifbrm@illithid> Message-ID: <20230106163839.oj7recybz3bk5ozp@illithid> At 2022-12-14T10:39:59-0500, Brad Spencer wrote: > "G. Branden Robinson" writes: > The source to OS-9/6809 would have been released by Microware a long > time ago had it not been for a particular person in the user > community. Got mucked up. I fell out of following it after the BSD > Unixs became available. They guy's name wasn't Mark Siegel, was it? (Feel free to reply privately.) > Level II was nice. It was able to use bank switching and would allow > a set of random 8k memory blocks out of the 128k or 512k present in > the CC3 system to be mapped into the 6809 64k address space. The > Color Computer didn't support memory protection, so no paging or any > real process protection, but this banking allowed for a lot of > possibilities. I know that there was other OS-9 systems around that > ran Level II but I don't really know how they managed memory. I would > suspect it to be simular to the CC3, but that is just a guess on my > part. I ask because I asked around elsewhere, and this guy got very hostile very fast, and touted the GIME chip as performing "address translation" as if it were a Motorola 68451 or something. (I'm not sure even _that_ does address translation in the sense we think of it today, but in any case it was a more powerful, more complex and therefore expensive part than Tandy was ever going to replicate or put in their Color Computers.) Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From coff at tuhs.org Sun Jan 22 07:12:03 2023 From: coff at tuhs.org (segaloco via COFF) Date: Sat, 21 Jan 2023 21:12:03 +0000 Subject: [COFF] The era of general purpose computing (Re: AIX moved into maintainance mode In-Reply-To: <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> References: <202301180943.30I9hrOw030485@freefriends.org> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> <202301211812.30LICtSl021234@freefriends.org> <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> Message-ID: COFF'd I wonder if we'll see events around 2038 that renew interest in conventional computing. There are going to be more public eyes on vintage computers and aging computational infrastructure the closer we get to that date methinks, if even just in the form of Ric Romero-esque curiosity pieces. Hopefully the cohort of folks that dive into Fortran and Cobol for the first time to pick up some of the slack on bringing 2038-averse software and systems forward will continue to explore around the margins of their newfound skills. I know starting in assembly and C influenced me to then come to understand the bigger picture in which those languages and their paradigms developed, so hopefully the same is true of a general programming community finding itself Fortran-and-Cobol-ish for a time. - Matt G. ------- Original Message ------- On Saturday, January 21st, 2023 at 10:43 AM, Luther Johnson wrote: > Yes, I know, but some of that SW development is being automated ... I'm > not saying it will totally go away, but the numbers will become smaller, > and the number of people who know how to do it will become smaller, and > the quality will continue to deteriorate. The number of people who can > detect quality problems before the failures they cause, will also get > smaller. Not extinct, but endangered, and we are all endangered by the > quality problems. > > On 01/21/2023 11:12 AM, arnold at skeeve.com wrote: > > > Real computers with keyboards etc won't go away; think about > > all those servers running the backends of the apps and the > > databases for the cool stuff on the phones. Someone is still > > going to have to write those bits. > > > > Arnold > > > > Luther Johnson luther at makerlisp.com wrote: > > > > > Well, that's a comforting thought, I hope it goes that way. > > > > > > On 01/19/2023 06:10 PM, John Cowan wrote: > > > > > > > On Thu, Jan 19, 2023 at 5:23 PM Luther Johnson > > > mailto:luther at makerlisp.com> wrote: > > > > > > > > Computers that are not smart phone-like are definitely on the > > > > endangered > > > > species list. You know, the kind on a desk, with a keyboard ... > > > > > > > > I don't have statistics for this, but I doubt it. Consider amateur > > > > radio, which has been around for a century now. Amateur stations are > > > > an ever-shrinking fraction of all transmitters, to say nothing of > > > > receivers, but in absolute terms there are now more than 2 million > > > > hams in the world, which is almost certainly more than ever. From davida at pobox.com Sun Jan 22 15:23:09 2023 From: davida at pobox.com (David Arnold) Date: Sun, 22 Jan 2023 16:23:09 +1100 Subject: [COFF] [TUHS] The era of general purpose computing (Re: AIX moved into maintainance mode (COFFed) In-Reply-To: <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> <202301211812.30LICtSl021234@freefriends.org> <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> Message-ID: (Move to COFF) > On 22 Jan 2023, at 05:43, Luther Johnson wrote: > > Yes, I know, but some of that SW development is being automated ... I'm not saying it will totally go away, but the numbers will become smaller, and the number of people who know how to do it will become smaller, and the quality will continue to deteriorate. The number of people who can detect quality problems before the failures they cause, will also get smaller. Not extinct, but endangered, and we are all endangered by the quality problems. Is it possible that this concern mirrors that of skilled programmers seeing the introduction of high-level languages? I’ve played with ChatGPT, and the first 10 minutes were a bit confronting. But the remainder of the hour or so I played overcame my initial concerns. It’s amazing what can be done, especially with Javascript or Python, when you ask for something that’s fairly simple to define, and in a common application area. You can get reasonable code, refine it, ask for an altered approach, etc. It’s probably quicker than writing it yourself, especially if you’re not intimately familiar with the library being used (or even the language). But … it pretty quickly becomes clear that there’s no semantic understanding of what’s being done behind it. And unless you specify what you want in pretty minute detail, the output is unlikely to be what you want. And, as always, going from a roughed-out implementation of the core functionality to a production-ready program is a lot of work. In the end, it’s like having an intern with a bit of experience, Stack Overflow, and a decent aptitude driving the keyboard: you still have to break down the spec into small, detailed chunks, and while sometimes they come back with the right thing, more often, you need to walk through it line by line to correct the little mistakes. I’m looking forward to seeing a generative model combined with static analysis, incremental compilation, unit test output: I think it will be possible for a good programmer to multiply their productivity by a few times (maybe even 10x, but I don’t see 100x). There’ll still be times when it’s simpler to just write the code yourself, rather than trying to rephrase the request. All of which makes me think of the assembly language to high-level language transition ... d From stuff at riddermarkfarm.ca Mon Jan 23 01:40:27 2023 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 22 Jan 2023 10:40:27 -0500 Subject: [COFF] The era of general purpose computing (Re: AIX moved into maintainance mode (COFFed) In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <202301181513.30IFDDUJ015224@freefriends.org> <20230118151446.GD2964@mcvoy.com> <202301190802.30J82KwQ025718@freefriends.org> <20230119150434.GA626@mcvoy.com> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> <202301211812.30LICtSl021234@freefriends.org> <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> Message-ID: On 2023-01-22 00:23, David Arnold wrote (in part): > I’ve played with ChatGPT, and the first 10 minutes were a bit > confronting. But the remainder of the hour or so I played > overcame my initial concerns. > > It’s amazing what can be done, especially with Javascript or > Python, when you ask for something that’s fairly simple to > define, and in a common application area. You can get reasonable > code, refine it, ask for an altered approach, etc. It’s probably > quicker than writing it yourself, especially if you’re not > intimately familiar with the library being used (or even the > language). > > But … it pretty quickly becomes clear that there’s no semantic > understanding of what’s being done behind it. And unless you > specify what you want in pretty minute detail, the output is > unlikely to be what you want. The comment by Derek Jones (https://shape-of-code.com/2023/01/15/coding-mistakes-made-by-chatgtp/) may be of interest here. N. From coff at tuhs.org Mon Jan 23 02:38:52 2023 From: coff at tuhs.org (segaloco via COFF) Date: Sun, 22 Jan 2023 16:38:52 +0000 Subject: [COFF] The era of general purpose computing (Re: AIX moved into maintainance mode (COFFed) In-Reply-To: References: <202301180943.30I9hrOw030485@freefriends.org> <7cc2b7c5-5e98-9299-4fa8-a477fbf4ff77@makerlisp.com> <75cfc721-a662-ddea-1188-767462d747ae@makerlisp.com> <202301211812.30LICtSl021234@freefriends.org> <396750c7-6fc8-9b15-5e68-9f569718ba2e@makerlisp.com> Message-ID: One of the higher ups at work has suggested quite an interest in ChatGPT as a code documentarian. I'm wary to let that thing near my code bases, but I'm a stickler for style as much as function, so a bit you could also tell to make pretty, readable code would be interesting. I see most effective applications in documentation and cleanup, as a bot could probably be made to spit out pretty consistent documentation of functions to the tune of "always describe an if else option with this verbiage" or "add a mention of the stack depth added by every routine", and then cleanup like enforcing/removing braces on one liners, resorting procedures to group more relevant operations (when not order-dependent), and perhaps better intelligent editors that don't need as much configuration to smartly support many programming languages. I'd love an editor that allows for rich editing of assembly alongside C. Hopefully the direction the improvements on productivity go are "Gee my workers can work so efficiently now they deserve the time this frees up for them." although my fear is "Gee my workers can work so efficiently now I only need half of them." I only support automation that makes workers' lives easier, not automation that makes executives bottom lines better at the cost of jobs. - Matt G. ------- Original Message ------- On Sunday, January 22nd, 2023 at 7:40 AM, Stuff Received wrote: > On 2023-01-22 00:23, David Arnold wrote (in part): > > > I’ve played with ChatGPT, and the first 10 minutes were a bit > > > confronting. But the remainder of the hour or so I played > > > overcame my initial concerns. > > > It’s amazing what can be done, especially with Javascript or > > > Python, when you ask for something that’s fairly simple to > > > define, and in a common application area. You can get reasonable > > > code, refine it, ask for an altered approach, etc. It’s probably > > > quicker than writing it yourself, especially if you’re not > > > intimately familiar with the library being used (or even the > > > language). > > > But … it pretty quickly becomes clear that there’s no semantic > > > understanding of what’s being done behind it. And unless you > > > specify what you want in pretty minute detail, the output is > > > unlikely to be what you want. > > > The comment by Derek Jones > (https://shape-of-code.com/2023/01/15/coding-mistakes-made-by-chatgtp/) > may be of interest here. > > N. From crossd at gmail.com Wed Jan 25 03:16:14 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 24 Jan 2023 12:16:14 -0500 Subject: [COFF] Fwd: How did Bell Labs start to work on Project MAC? Message-ID: [Bcc: to TUHS as it's not strictly Unix related, but relevant to the pre-history] This came from USENET, specifically, alt.os.multics. Since it's unlikely anyone in a position to answer is going to see it there, I'm reposting here: >From Acceptable Name : >Did Bell Labs approach MIT or was it the other way around? >Did participating in Project MAC come from researchers requesting >management at Bell Labs/MIT or did management make the >decision due to dealing with other managers in each of the two >organizations? Did it grow out of an informal arrangement into >a format one?" These are interesting questions. Perhaps Doug may be in the know? - Dan C. From jnc at mercury.lcs.mit.edu Wed Jan 25 04:47:38 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Jan 2023 13:47:38 -0500 (EST) Subject: [COFF] [TUHS] Fwd: How did Bell Labs start to work on Project MAC? Message-ID: <20230124184738.5564518C080@mercury.lcs.mit.edu> > From: Dan Cross > From Acceptable Name : Gmail has decided this machine is a source of spam, and is rejecting all email from it, and I have yet to sort out what's going on, so someone might want to forward anything I turn up to this person. >> Did Bell Labs approach MIT or was it the other way around? I looked around the Multics site, but all I could find is this: "Bell Laboratories (BTL) joined the Multics software development effort in November of 1964" https://multicians.org/history.html I did look through IEEE Annals of the History of Computing, vol. 14, no. 2, listed there, but it's mostly about the roots of CTSS. It does have a footnote referring to Doug, about the timing, but no detail of how Bell Labs got involved. I have yet to look at the oral history things from Corby, etc which may answer this in passing. I'll ask Jerry Saltzer if he remembers; he's about the only person left from MIT who was around at that point. >> Did participating in Project MAC come from researchers requesting >> management at Bell Labs/MIT At MIT, the 'managers' and the researchers were the same people, pretty much. If you read the panel transcript in V14N2, Fano was the closest thing to a manager (although he was really a professor) there was at MIT, and he talks about not wanting to be involved in managing the thing! Noel From jnc at mercury.lcs.mit.edu Wed Jan 25 07:09:23 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Jan 2023 16:09:23 -0500 (EST) Subject: [COFF] [TUHS] Fwd: How did Bell Labs start to work on Project MAC? Message-ID: <20230124210923.22CAC18C080@mercury.lcs.mit.edu> > I have yet to look at the oral history things from Corby, etc which may > answer this in passing. This page: https://multicians.org/project-mac.html links to oral history transcripts from Fano, Corby and Dennis. Only Corby: https://conservancy.umn.edu/handle/11299/107230 http://archive.computerhistory.org/resources/access/text/2013/05/102658041-05-01-acc.pdf was involved when Bell Labs came on board; he says: "Also Bell Labs was interested in acquiring a new computer system. They were quite intrigued and sympathetic to the notions of what we were doing. Ed David down there was a key figure and an old friend of Fano. They decided to become partners (pg. 16, CHM interview) "Simultaneously, Bell Labs had been looking for a new computer acquisition for their laboratories, and they had been scouting out GE. There was some synergism: because they knew we were interested they got interested. I think they first began to look independently of us. But they saw the possibility of our developing a new operating system together." (pg. 43, CBI interview) So it sounds like it was kind of a mutual thing, aided by the connection between Fano and David (who left Bell after Bell bailed on multics). Noel From stuff at riddermarkfarm.ca Sat Jan 28 05:31:33 2023 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Fri, 27 Jan 2023 14:31:33 -0500 Subject: [COFF] [TUHS] Re: [off-topic] Anyone still using USENET? In-Reply-To: <2e22ed63-3817-cd91-3f1b-cf169eb83230@riddermarkfarm.ca> References: <202301270853.30R8rif6014271@freefriends.org> <086b01d93276$c3982c80$4ac88580$@henare.com> <2e22ed63-3817-cd91-3f1b-cf169eb83230@riddermarkfarm.ca> Message-ID: <57bd364a-8460-d01f-dd5f-53861831a44c@riddermarkfarm.ca> On 2023-01-27 14:23, Stuff Received wrote: > On 2023-01-27 12:42, Henry Mensch wrote (in part): >> I'd like to find solid Android and Windows clients so I could once >> again use USENET. > > I read USENET (at Newsdemon -- USD3 monthly) with Firefox (on MacOS) but > presumably will also work on Windows. Oops -- Thunderbird, not Firefox. > > N. > > (We seem to have strayed into COFF territory...) From e5655f30a07f at ewoof.net Sun Jan 29 06:12:14 2023 From: e5655f30a07f at ewoof.net (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 28 Jan 2023 20:12:14 +0000 Subject: [COFF] [TUHS] Re: reading historic magnetic tapes In-Reply-To: <1595e77d-697c-b2e8-5aff-fe63c92f4747@ucsb.edu> References: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> <1595e77d-697c-b2e8-5aff-fe63c92f4747@ucsb.edu> Message-ID: <2c916808-5463-44a5-a89d-cc50e685631a@home.arpa> On 28 Jan 2023 11:29 -0800, from frew at ucsb.edu (James Frew): > As I was leaving the lab late one evening during this mini-crisis, I had to > walk around a custodian who was busy giving the linoleum floor in the > hallway its annual deep cleaning / polishing. This involved a dingus with a > large (~18" diameter) horizontal buffing wheel, atop which sat an enormous > (like, a cylinder about as big around as a soccer ball) electric motor, > sparking commutator clearly visible through the vents in the metal housing. This is probably more COFF than TUHS, but I recall a story from almost certainly much later where someone (I think it was a secretary; for now, let's pretend it was) had been told to change backup tapes daily and set the freshly taken backup aside for safekeeping. Then one day the storage failed and the backups were needed, only it turned out when trying to restore the backups that _every_ _single_ _tape_ was blank. Nobody, least of all the secretary, could explain how that could have happened, and eventually, the secretary was asked to demonstrate exactly what had been done every day. Turned out that while getting the replacement tape, the secretary put the freshly taken backup tape on a UPS, which apparently generated a strong magnetic field, before setting that tape aside. So the freshly taken backup tape was dutifully well and thoroughly erased. Nobody had mentioned the little detail of not putting the tape near the UPS. Oops. -- Michael Kjörling 🏡 https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?” From sauer at technologists.com Sun Jan 29 06:17:30 2023 From: sauer at technologists.com (Charles H Sauer (he/him)) Date: Sat, 28 Jan 2023 14:17:30 -0600 Subject: [COFF] reading historic magnetic tapes In-Reply-To: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> References: <6778F07B-DD74-4F04-A877-7D3751E96317@quintile.net> Message-ID: <9274d976-dad7-06af-b546-23d4091f7ed4@technologists.com> This seems COFF, not TUHS, and mostly not digital... I have many 4mm DAT cartridges from 20-30 years ago. Every now and then I will access one. So far I've yet to see evidence of the media degrading. On 1/28/2023 4:12 AM, Steve Simon wrote: > baking old, badly stored magnetic tapes prior to reading them is a common practice. For the last year+ I have been digitizing selected audio tapes made in the 70s at AWHQ (https://en.wikipedia.org/wiki/Armadillo_World_Headquarters). The ones I've been working with are 1/4" on 10.5" reels. A printed inventory I was given says "bake" next to almost all of the items, but so far, after processing roughly 40 reels, I've yet to find one that seemed to need "baking" (actually, "baking" is a bit overstated, in that best practice is to raise temperature to roughly 150F -- https://www.radioworld.com/industry/baking-magnetic-recording-tape). For now, I'm not able to share those AWHQ recordings, but I can share other recordings I made in the 60s and 70s at https://technologists.com/60sN70s/. In all those reels, many of which are cheap, unbranded tape, I didn't find any that seemed to me to need baking. Charlie -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer From nevin at eviloverlord.com Sun Jan 29 07:24:07 2023 From: nevin at eviloverlord.com (Nevin Liber) Date: Sat, 28 Jan 2023 15:24:07 -0600 Subject: [COFF] Anyone still using USENET? In-Reply-To: References: <202301270853.30R8rif6014271@freefriends.org> Message-ID: [moved to COFF] On Sat, Jan 28, 2023 at 4:16 AM Andy Kosela wrote: > Great initiative and idea! While I am personally not interested in reading > USENET that much nowadays, the concept of providing free, public access to > classic Internet services (public USENET, FTP, IRC, finger, etc.) gets all > my praise. What happened to free, public services these days? First off, what is stopping you from providing free, public access to those services? I don't know where you are, but I have orders of magnitude more access to freely available content and services than I ever did in the heyday of Usenet, etc. And for most of it, one doesn't have to be highly technical to use it. > Everything appears to to be subscriber pay-as-you-go based. The > commercialization killed the free spirit of Internet we all loved in the > 90s. > "Free" was never really true, as it required massive subsidies of equipment, power, bandwidth and employee time, usually w/o the direct knowledge or consent of the entities paying for it. It reminds me of the lemonade stands I'd occasionally run as a kid, which were "profitable" to me because mom and dad, with their knowledge and consent, let me pretend that the costs were $0. -- Nevin ":-)" Liber +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Mon Jan 30 20:37:25 2023 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 30 Jan 2023 21:37:25 +1100 (EST) Subject: [COFF] ChatGPT and Mark V. Shaney Message-ID: Has anyone hooked them up? :-) -- Dave