- COFF - www.tuhs.org

by Nelson H. F. Beebe

List members may be interested in this new article published today: Steven M. Bellovin Netnews: The Origin Story IEEE Annals of the History of Computing 47(1) 7--21 Jan/Mar 2025 https://doi.org/10.1109/MAHC.2024.3420896 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: https://www.math.utah.edu/~beebe - -------------------------------------------------------------------------------

1 month, 1 week

4
3
0 0

[TUHS] What would early alternatives to C have been?

by Douglas McIlroy

Beating a nearly dead horse, I'm shipping this to COFF instead of TUHS to which it responds. > I find > > if (a == b && c == d) > > perfectly reasonable, but > > if ((a == b) && (c == d)) > > to be just silly. Amusing. IT's odd that no one has mentioned the use of spaces for grouping. When the operands of == are simple, I prefer to vary the spacingy spacing. It's less intrusive than extra parentheses and just as clear. if(a==b && c==d) or if( a==b && c==d ) K&R usually flank every infix operator with spaces, unlike classical mathematical usage, where spacing reflects operator precedence. I usually write a*b + c*d, not a * b + c * d, which wantonly flattens the parse tree. Here's an example from K&R, where uniform spacing hampers intelligibility. for (i = 0; s[i] >= '0' && s[i] <= '9'; ++i) n = 10 * n + (s[i] - '0'); The "extra" parens in the second line admirably show the intent of the subtraction. Other groupings are not so well indicated. I would write it like this: for(i=0; s[i]>='0' && s[i]<='9'; ++i) n = 10*n + (s[i]-'0'); (I'll admit that the juxtaposition ]>= is less than perspicuous.) Long identifiers constitute a level of grouping that takes precedence even over multiplication. So I may flank long identifiers with spaces. I suppose then + in a sum of products might deserve double spaces. That's probably a bridge too far, but double spaces after the semicolons in the "for" statement above seem justifiable K&R aren't absolutely rigid about spacing. In the following oddly mixed specimen, the first of three operands in a conjunction is spaced tightly, but the third is not; I guess they feel about != the way I do about long identifiers. i<lim-1 && (c = getchar()) != '\n' && c != EOF The middle conjunct is a challenge. I'd probably squeeze out the spaces. But I might instead try to hold it together with outer parens. Doug

1 month, 2 weeks

2
1
0 0

Make your own virtual punchcard

by Douglas McIlroy

Mention of punched cards reminded me of some 1960s trivia. There were two formats for binary code on punched cards for IBM 700-series machines. In "row binary" two 36-bit words filled each of the 12 rows from bottom to top. In "column binary" successive thirds of a word ran downward in each of 3 successive columns. Bob Morris wondered what is the order of the permutation performed in row-to-column conversion. The order of the row-to-column permutation turns out to be 172. There are five cycles of that length plus an oddball of length 4. My souvenir card shows the oddball. If you convert a cycle from row binary to column binary, the output is the same as the input.* Each cycle is also invariant under 180-degree rotation.The 4-cycle is a simple parallelogram. One of the 5-cycles lines up in periodic diagonals. The other cycles show no easily described structure. The images of the two described cycles should be viewed in a fixed-width font. The punches in the 4-cycle are numbered in cyclic order. I keep a few souvenir punched cards. One bears that 4-cycle. * Well, almost the same. The first word on the card contains control information whose layout differs in the two formats. Doug ........................................................................ ........................................................................ ...........................................3............................ ........................................................................ ..............2......................................................... ........................................................................ ........................................................................ .........................................................4.............. ........................................................................ ............................1........................................... ........................................................................ ........................................................................ ..X....X....X....X....X....X....X....X....X....X....X....X....X....X.... ....X....X....X....X....X....X....X....X....X....X....X....X....X....X.. .X....X....X....X....X....X....X....X....X....X....X....X....X....X....X ...X....X....X....X....X....X....X....X....X....X....X....X....X....X... X....X....X....X....X....X....X....X....X....X....X....X....X....X....X. ..X....X....X....X....X....X....X....X....X....X....X....X....X....X.... ....X....X....X....X....X....X....X....X....X....X....X....X....X....X.. .X....X....X....X....X....X....X....X....X....X....X....X....X....X....X ...X....X....X....X....X....X....X....X....X....X....X....X....X....X... X....X....X....X....X....X....X....X....X....X....X....X....X....X....X. ..X....X....X....X....X....X....X....X....X....X....X....X....X....X.... ....X....X....X....X....X....X....X....X....X....X....X....X....X....X..

1 month, 3 weeks

1
0
0 0

Make your own virtual punchcard

by Charles H Sauer (he/him)

https://boingboing.net/2025/03/10/make-your-own-virtual-punchcard.html [50 years ago today I started working at IBM Yorktown. My boxes of punchcards from graduate work at UT-Austin were enroute with the movers from Austin, to be fed into VM-370 after they arrived. I wish I had kept those boxes as souvenirs.] Charlie -- voice: +1.512.784.7526 e-mail: sauer(a)technologists.com fax: +1.512.346.5240 Web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/mas.to: CharlesHSauer

1 month, 3 weeks

5
4
0 0

Kids these days....

by norman＠oclsc.org

Remind them that ed (pronounced e d) is the standard editor.

2 months, 2 weeks

12
12
0 0

Re: Kids these days.... External

by Douglas McIlroy

Besides the first day I sat at the PDP-7 console, one of the biggest Unix thrills came when when I logged in remotely to the new Cray at Bell Labs. Here was a monster machine with a manual I had never seen, and I was able to compile and run a program on it at the first try. God bless sh, ed, cc, and a.out. Doug

2 months, 2 weeks

1
0
0 0

Kids these days....

by Dan Cross

File under "What a Drag it is Getting Old".... My kids have now reached the age where they have started to mock me. Not only must I contend with the fact that I'm not cool anymore (if, indeed, I ever really was) but I also realize that I have no idea what the slang they're using means. None whatsoever; it's all unintelligible gibberish to me. They clearly revel in my ignorance. But I have found a way to get even: I have started spelling out commands verbally, punctuated with random words, and acting like this has more general meaning (and like, you're just not hip with the rizz if you don't understand). For example, "Yo, tar x v; on cat. Sig Pipe, amirite?" I'll throw one of these out, and they stare at me with faux comprehension while I silently, inwardly gloat. Just thought I'd share. - Dan C.

2 months, 2 weeks

1
0
0 0

Source for a vaguely Bourne-like shell, no signals

by Warren Toomey

Hi all, this is a pretty weird question to ask. I've been extending the RISC-V version of xv6 to have a decent libc and some userland programs: https://github.com/DoctorWkt/xv6-riscv-fuzix There's a minimalist shell and my own 'wish' shell; neither have any scripting capability. Also, as it stands there are no signals implemented. I'd love a Bourne-ish shell to write shell scripts, but I've had a hard time finding one that I can snip out the signal handling code. If you have any suggestions, please met me know! Thanks, Warren

3 months, 2 weeks

1
1
0 0

Re: [TUHS] "Webster's Second on the Head of a Pin"?

by sjenkin＠canb.auug.org.au

Not dissimilar work at AT&T Research ~2000 - compressing fixed-length records, better than gzip, +30% for similar compute time. ‘pzip’ - Adam Bushman & Glen Fowler <https://web.archive.org/web/20041019142227/http://www.research.att.com/~gsf…> Later work by others, building on ‘pzip’ ,claims ‘100x’. > On 30 Dec 2024, at 00:44, Douglas McIlroy <douglas.mcilroy(a)dartmouth.edu> wrote: > > I can supply a copy if no one else has beaten me to it. > > Ron Hardin subsequently pushed the limit even further. Unfortunately, > I do not have a record of that work. > > Doug > > On Sat, Dec 28, 2024 at 9:54 PM Royce Williams <royce(a)techsolvency.com> wrote: >> >> Someone I know is seeking the original version of an internal Bell Labs memo from 1974 titled "Webster's Second on the Head of a Pin" by Morris and Thompson. The topic appears to be related to improving the speed of lookups or search. It's cited in a few papers as "Unpublished Technical Memo, Bell Laboratories, Murray Hill, NJ 1974." All I can find online is citations. Any leads appreciated! >> >> -- >> Royce Other links: This repository included ksh-93 sources Glen Fowlers’ downloads <https://web.archive.org/web/20130514131958/http://www2.research.att.com/~gs…> Later AT&T Research page with Software downloads <https://web.archive.org/web/20090626002505/http://public.research.att.com/i…> THE AT&T AST OPENSOURCE SOFTWARE COLLECTION 2000 <https://www.usenix.org/legacy/publications/library/proceedings/usenix2000/f…> Github Repo for AST - I couldn’t make these compile <https://github.com/att/ast/tree/master> KSH93 <https://github.com/ksh93> -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

4 months

1
0
0 0

DEC computer Christmas carols

by Paul Winalski

The PDP-10 had an alarm bell that could be rung under program control. When the TOPS-10 operating system crashed, it displayed a numeric code on the console indicating the reason for the crash. This was called a "stopcode" and is the equivalent of a Unix panic. It also rang the alarm bell. DDT (Dynamic Debugging Tool) was the primary debugger for TOPS-10. PPN (Project-Programmer Number) was used for system security. Each user account was assigned by number to a Project, and within that Project a unique Programmer Number. The low numbers (such as [7,3]) were usually privileged accounts. So here we have the Christmas carol Stopcode Bells, to the tune of Jingle Bells: ========== Stopcode bells, stopcode bells, stopcode all the way. Oh what fun it is to crash the system night and day. Stopcode bells, stopcode bells, stopcode all the way. Oh what fun it is to crash the system night and day. Poking through the core With a bug in DDT Change your PPN To [7,3]. Halt somebody's job. Make them scream and shout. Oh what fun it is to log The operator out. ========== This is one that I wrote while I worked in DEC's software development tools department. Around Christmas time the first baselevels of VAX/VMS Version 3.0 were being sent to alpha test. The engineering departments got first crack at the new system and so were the first to encounter bugs and design problems. VMS Version 3 had been a very ambitious project and was eventually split up into Version 3A (released as Version 3.0) and Version 3B (released as Version 4.0). There was a lot of grumbling by groups whose new features got put into 3B and thus delayed. The early baselevels of 3A broke the VAX C runtime library. So here we have Version 3 is Coming to Town: ========== You'd better work hard You'd better code fast. The system you use Just ain't gonna last. Version 3 is coming to town. They fixed some old bugs And put new ones in, Added some features They think will win. Version 3 is coming to town. There's so many new features. Too bad we can't use C. And the things that we most wanted Were deferred until 3B. You'd better work hard You'd better code fast. The system you use Just ain't gonna last. Version 3 is coming to town. ========= -Paul W.

4 months, 2 weeks

1
0
0 0

Re: [TUHS] After 50 years, what has the Impact of Unix been?

by Douglas McIlroy

Apropos of file types, which Rich Salz commends Unix for discarding. Early in Multics development, I and others visited various influential time-sharing systems in search of good ideas. I tried each one on a simple model of software updating, in particular of remaking a compiler. In every instance I could not make my program work without expert help to get past file-type barriers. My model was based on a trivial Fortran program that copied input to output until an input line with END in column 7 had been processed. Every system was able to compile this program, but ... After compiling, I tried to use the program to make a copy of itself. Here was the first file-type hurdle. Input was typically expected to be of type data, not source code. Gurus had to scramble to overcome this nominal incompatibility. Next I tried to compile the new Fortran program. Same trouble in reverse--data used as source. More scrambling of gurus. Then I ran the newly compiled program to do the above steps over again. This time the gurus had the file-type workarounds under control. One comp center still had trouble, however, which took some time to diagnose. It turned out that Fortran programs were, for unknown reasons, specifically forbidden to read their own source code! One side effect of file-type conventions was that instead of learning once and for all how to create text files, one had to learn different ways to edit files of different types. Doug

4 months, 4 weeks

1
0
0 0

AI and spin locks

by Warren Toomey

I was just trying to find out if there was a way of uploading the TUHS mailing list as a corpus of text into a LLM so that I could ask questions based on the knowledge contained therein. I'm not having much luck yet. Anyway, while messing around with things I asked a simple question and got this answer: What is a spin lock? A spin lock, also known as a spinning lock or spinning lock mechanism, is a type of mechanical locking device used to secure and protect sensitive electronic components, such as microprocessors, memory chips, and other high-value devices. Here's how it worked: when a CPU instruction was executed and the necessary data was stored in registers, the CPU would "lock" the registers by spinning them around to prevent other instructions from accessing them. Those poor registers must get dizzy with all the spinning that they have to endure :-) Cheers, Warren P.S. If anybody has ideas on how to usefully import the TUHS mailing list into a LLM, let me/us know.

5 months

9
11
0 0

[TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Douglas McIlroy

> Curiously, Robert Martin's in the acknowledgements for K&R > (I forget which edition). I guess he read an early draft? I didn't find Robert Martin in the long list of acknowledgements in the preface to the second edition. But any such acknowledgement would certainly be to Bob Martin, a savvy Bell Labs executive whose advice was always welcome. He is acknowledged in Aho and Ullman's "Theory of Parsing, Translation, and Compiling", but not in the Dragon Book. I have never seen a Robert Martin book on programming; I probably would have were it written by Bob. Doug

5 months

2
1
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Dan Cross

On Tue, Nov 26, 2024 at 8:48 AM Kevin Bowling <kevin.bowling(a)kev009.com> wrote: > On Thu, Nov 21, 2024 at 6:53 PM Dan Cross <crossd(a)gmail.com> wrote: >> [TUHS to Bcc:, Cc: COFF] >> >> On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt(a)gmail.com> wrote: >> > Dan Cross <crossd(a)gmail.com> wrote: >> > >Programmer ability is certainly an issue, but I would suggest that >> > >another goes back to what Rob was alluding to: compiler writers have >> > >taken too much advantage of UB, making it difficult to write >> > >well-formed programs that last. >> > >> > Following the letter, rather than the spirit, of the standard? >> >> Pretty much! >> >> > [snip] >> > >My sense is that tossing in bad programmers is just throwing gasoline >> > >onto a dumpster fire. Particularly when they look to charlatans like >> > >Robert Martin or Allen Holub as sources of education and inspiration >> > >instead of seeking out proper sources of education. >> > >> > I am a bad one as well, to have liked some things in Martin's books >> > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor >> > Dijxtra, nor Knuth, but why a charlatan? > > And what about Hollub? Pretty much the same thing. > A long time ago I came across and seemed to think some of his earlier books (on C) were ok. Yeah. He wrote a book about compilers, but as near as I can tell, it's mostly material regurgitated from the Dragon Book, just a different presentation, and a less academic focus. Curiously, he's in the acknowledgements for K&R (I forget which edition). I guess he read an early draft? > Looking lately, I don’t tend to care for the metaphysical and ceremonial stuff whence one starts talking about design patterns and scrum instead of doing the work so I haven’t paid attention. > > It’s a strong accusation to levy publicly and maybe should be explained. Many of Hollub's claims are ridiculous on the face of them ("you don't need a bug tracker! You don't need schedules! Code should be written by 'mobbing'!" Here's a representative example: https://twitter.com/allenholub/status/1734661813638459843 In that tweet he writes, "What we do involves essentially no mathematical analysis of anything. We are not doing math.If you're building a system that requires math, then the math is part of the _domain_, not the development process." I suppose he's never heard of time or space complexity analysis of algorithms? Or how about this one: https://twitter.com/allenholub/status/1827790079617892675 "A PR [Pull Request] is necessary only when someone you don't trust writes code in isolation. It's essential for OS work, for example, or if you're working using scatter/gather [https://bit.ly/3XYLhb3] It's also a complete waste of time if you're working in a mob#/ensemble (or even a pair) because the code is reviewed as it's written." I suppose he's never worked someplace with a real, rigorous review culture. Also, https://x.com/allenholub/status/1634050850434826240 A few others: https://x.com/allenholub/status/1594859115557232640 https://x.com/allenholub/status/1613609655519019008 https://x.com/allenholub/status/1656811047783899138 https://x.com/allenholub/status/1610708432331632641 He has some code on Github that's relatively recent. It's not very good. - Dan C. >> Briefly, because he writes with unwarranted confidence, and just isn't >> a very good programmer himself. >> >> He writes with an authoritative voice about things that he doesn't >> know very much, if anything, about. For example, the things he's >> written about static typing in programming languages are complete >> nonsense. Sriram Krishnamurthi called him out on that >> (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did >> not respond well, doubling down on his unfounded opinions >> (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html) >> Later, he justified his opinion by making allusions to the amount of >> time he's been programming >> (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html) Hey, >> when it comes to logical fallacies centered on appeals to length of >> experience, well...I swooshed a basketball for the first time more >> than 40 years ago, but I've given up any dream I may have ever had of >> being a point guard in the NBA. Just doing something for a long time >> doesn't mean you're good at it. >> >> Robert Martin doesn't write production-quality code, period. He claims >> to "ship" lots of code, but acknowledges that most of that is example >> code for his books and personal side-projects. But the code examples >> he has publicly available are not particularly well-structured, >> readable, or maintainable. For a particular egregious example, see >> https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca… >> (not the current commit; he modified it somewhat after I sent him >> https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff7…, >> which he did not acknowledge; see >> https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320c… >> for the timeline). >> >> And while that small program is a particularly bad example, other bits >> of his code are also bad. Ousterhout was asked to comment on his >> "extract till you drop" approach and presented with a "refactoring" >> Martin did of a program due to Knuth >> (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-…) >> Ousterhout responded that he was "bewildered and horrified" by the >> approach. As Ousterhout put it, "He has taken 25 lines of code that >> are pretty straightforward and easy to understand, and turned them >> into 38 lines with 9 methods, none of which has a stitch of >> documentation. What was the point of this?" >> (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCA…) >> >> These are all typical of Martin's approach. Hence why I say the man is >> a charlatan. Others have written at length about why, and how, his >> advice is generally bad. >> >> - Dan C.

5 months

3
2
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by John Levine

According to Dan Cross <crossd(a)gmail.com>: >> And what about Hollub? > >Pretty much the same thing. > >> A long time ago I came across and seemed to think some of his earlier books (on C) were ok. > >Yeah. He wrote a book about compilers, but as near as I can tell, >it's mostly material regurgitated from the Dragon Book, just a >different presentation, and a less academic focus. It was terrible because none of the code worked. There was a fat list of errata that fixed some of them but it was more trouble than it was worh. R's, John -- Regards, John Levine, johnl(a)taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

5 months

1
0
0 0

A couple thoughts about BASIC

by Adam Thornton

I was one of those 80s kids who grew up with 6502s with BASIC in ROM. Yeah, I learned some bad habits from that, but they weren't that hard to unlearn, and they, at the very least, got me screwing around with computers and figuring out how to make them do what I wanted. It's been my career for three and a half decades now, so I'm not gonna complain. A couple decades later we had PHP for the web, which did almost exactly the same thing: made the barrier to entry, for getting stuff you wanted to see on the screen actually show up there, really low. And yeah, a bunch of people wrote a bunch of terrible web pages, but at least some of them, I'll wager, got inspired by that to learn more and do better. Sneering at BASIC is exactly the same sort of irritating privileged-ivory-tower BS that The Unix-Hater's Handbook and the cult of ITS represent. Sure, in some perfect world, people would learn better habits and have access to more capable (and therefore grossly more expensive) machines, but in the world in which we actually live, a really-low-barrier-to-entry for smart kids without tons of money is a lovely democratizing force. Here endeth the rant. Adam

5 months, 1 week

3
3
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Dan Cross

[TUHS to Bcc:, Cc: COFF] On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev <anton.txt(a)gmail.com> wrote: > Dan Cross <crossd(a)gmail.com> wrote: > >Programmer ability is certainly an issue, but I would suggest that > >another goes back to what Rob was alluding to: compiler writers have > >taken too much advantage of UB, making it difficult to write > >well-formed programs that last. > > Following the letter, rather than the spirit, of the standard? Pretty much! > [snip] > >My sense is that tossing in bad programmers is just throwing gasoline > >onto a dumpster fire. Particularly when they look to charlatans like > >Robert Martin or Allen Holub as sources of education and inspiration > >instead of seeking out proper sources of education. > > I am a bad one as well, to have liked some things in Martin's books > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor > Dijxtra, nor Knuth, but why a charlatan? Briefly, because he writes with unwarranted confidence, and just isn't a very good programmer himself. He writes with an authoritative voice about things that he doesn't know very much, if anything, about. For example, the things he's written about static typing in programming languages are complete nonsense. Sriram Krishnamurthi called him out on that (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did not respond well, doubling down on his unfounded opinions (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html) Later, he justified his opinion by making allusions to the amount of time he's been programming (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html) Hey, when it comes to logical fallacies centered on appeals to length of experience, well...I swooshed a basketball for the first time more than 40 years ago, but I've given up any dream I may have ever had of being a point guard in the NBA. Just doing something for a long time doesn't mean you're good at it. Robert Martin doesn't write production-quality code, period. He claims to "ship" lots of code, but acknowledges that most of that is example code for his books and personal side-projects. But the code examples he has publicly available are not particularly well-structured, readable, or maintainable. For a particular egregious example, see https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca… (not the current commit; he modified it somewhat after I sent him https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff7…, which he did not acknowledge; see https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320c… for the timeline). And while that small program is a particularly bad example, other bits of his code are also bad. Ousterhout was asked to comment on his "extract till you drop" approach and presented with a "refactoring" Martin did of a program due to Knuth (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-…) Ousterhout responded that he was "bewildered and horrified" by the approach. As Ousterhout put it, "He has taken 25 lines of code that are pretty straightforward and easy to understand, and turned them into 38 lines with 9 methods, none of which has a stitch of documentation. What was the point of this?" (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCA…) These are all typical of Martin's approach. Hence why I say the man is a charlatan. Others have written at length about why, and how, his advice is generally bad. - Dan C.

5 months, 1 week

1
0
0 0

Fwd: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, Dies at 96

by Dan Cross

I don't believe this was sent here yet. BASIC is much maligned, but was important nonetheless. - Dan C. ---------- Forwarded message --------- From: Tony Patti via Internet-history <internet-history(a)elists.isoc.org> Date: Sun, Nov 17, 2024, 3:50 PM Subject: [ih] NYT: Thomas E. Kurtz, a Creator of BASIC Computer Language, Dies at 96 To: <internet-history(a)elists.isoc.org> https://www.nytimes.com/2024/11/16/technology/thomas-kurtz-dead.html (published yesterday November 16, 2024) "At Dartmouth, long before the days of laptops and smartphones, he worked to give more students access to computers. That work helped propel generations into a new world." Me too, I owe it all to BASIC. Because 5 decades earlier, via an ASR 33 Teletype and acoustic coupler at 110 baud to a remote HP 2100, BASIC was my introduction to computers and programming. Tony Patti (ARPAnet NIC IDENT "TP4") -- Internet-history mailing list Internet-history(a)elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history

5 months, 2 weeks

3
2
0 0

Re: [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

by Theodore Ts'o

(Moving this thread over to COF, since we've gotten pretty far afield from the TUHS list's charter.) On Sat, Nov 09, 2024 at 04:23:34PM -0600, G. Branden Robinson wrote: > > The Linux Foundation does not exclusively own the copyright on the > > Linux kernel. The copyright is jointly owned by all of the > > contributors of the Linux kernel. This makes it quite unlike the FSF > > projects, where contributions to FSF project require a copyright > > assignment[1]. > > That's a myth. It is the FSF's stated _preference_, but it is a > negotiable point. For example, Thomas Dickey negotiated reversion of > copyright to himself when becoming ncurses maintainer 26 years ago.[A] In the web site I quoted, the fact that there is an option not to do the copyright assignment was apparently conveniently ommitted. And in the early 1990's, I *personally* tried negotiating to not do the copyright assignment directy with the FSF, and I was told to go to heck. Given that I *had* taken a legal class from the MIT Sloan School (Legal issues for the I/T Manager), I knew what the word "indemnify" meant, and there was no way in the world I was going to sign the damned FSF copyrioght legal paperwork, and I told the FSF so. The only other alternative was my not contributing to the GNU Project. The FSF may have since relaxed their poition in the past 30 years, but it's not something that they've really admitted (again, see the FSF web page I referenced). My theory is that the only reason *why* they relaxed their position was that it would have made GNU even more irrelevant if they hadn't (e.g., people don't have to contribute to GCC; if it's more friendly and easier to contribute to Clang.) > But is it true for less prestigious projects or individual contributors > with no clout to speak of? Well, apparently in the early 1990's I didn't have any clout in the eyes of the FSF. :-) Probably for the best, all things considered. > With respect to the Linux kernel in particular, it seems the GPL _in > practice_ imposes no obligations. That was my point. Little > enforcement is visible. As far as "public shaming" goes, I've seen it > from the FSF and the Software Freedom Conservancy, not from the LF. > > Give me examples of the LF leaning on infringers and getting results! > I want them! OK, I see where you are coming from here. And I think the main isue is that the goals of the Linux community are quite different from that of the FSF. (And note that I say the Linux community, since these atttudes predate the founding of the Linux Foundation by **years** and existed across many developers, some of whom, like me, weren't yet hired by a Linux corporation; I was at MIT, and my day job was TL for MIT Kerberos and IPSEC working group chair for the IETF as well as serving on MIT Network Operations.) The Linux attitude was a focus on the social contract between *developers*. If you improve the Linux kernel, we expect that you contribute those changes back. So what we care about is the company that has 9,000 out of tree patches, representing hundreds of engineer years of SWE investment. And here, this is where in practce, GPL social contract becomes self-enforcing. It is in the interest of the company who is interested in keeping up with upstream to get the changes back upstream. The FSF and Richard Stallman has a much bigger focus on the ability of users to be able to get the sources for GPL'ed code, make changes, and then install that changed sources on their hardware. That's a fine goal, and I respect that some people might have that as a very strong policy preference and something that they care about. It's just that it's a very different goal than what most Linux kernel developers care about. (And again, this wasn't shaped by my employers; I and many of the people I know had these preferences long before the Linux companies formed and started hiring us.) So take for example, the hypothetical someone who makes a tiny change to the Linux kernel to create a crappy AI gadge in a square orange box. Call it, for the sake of argument, the "Squirrel S1". :-) As far as the Linux kernel community is concerned, the Squirrel S1 is irrelevant. It has no interesting technology that we would care about, and while it might be sad that a user might not be able to change the software in the S1, either because the manufacturer didn't meet their GPL oligations, or the hardware was locked down and the GPL2 does't have an anti-Tivo clause it it, in my opinion, the enforcement is self-executing. If you're a user, and can't make changes, and you want to, then don't fork over $199 for the Squirrel S1! From the FSF's Free Softare perspective, they obviously have a very different goal. They believe all users should have the ability to access the source code and modify software on a Squirrel S1, whether they want to doit or not, and regardless of whether that might cause the device to become more expensive. They believe this is a core user freedom, that should never be abograted. I respect those people who have those feelings. But obviously people in the BSD camp don't share those priorities --- and in the Linux kernel community, while we believe the GPL2 is a great way of expressing the social expectations between developers, we don't necessarily share the same attitudes as Mr. Stallman. Could someone who has some copyright ownership try do some vexatious lawsuits in order to (legally) extort money out of companies who are infringing the GPL? Sure; although I'll note that for the targets of those lawsuits, I'm not so sure that they would see that much difference between a Patrck McHardy and the SFC. And at least personally, the amount of help that I would give a Patric McHardy and an SFC lawsuit is pretty much the same; zero, and my personal opinion is that they are not really helpful, since my goal is to have more companies being *happy* to contribute to Linux; not to feel coerced and forced to contribute by sullenly dropping a bunch of code to comply with the GPL and then walking away. > > So why do companies join the Linux Foundation? Well, there are a > > number of benefits, but one very important one is that it provides a > > way for companies to directly collaborate with funded programs to make > > improvements to Linux without worrying about anti-trust conerns. > > Are these concerns anything more than notional? Well, I was at the IBM Linux Technology Center when we were first working on standardizing ISO/IEC 23360-2:2006. This was well after the FTC consent decree was dissolved in 1996, and while a Republican (George W. Bush) was president --- and I can tell you that it *was* something that my employer at the time very much cared about. We got very clear instructions about what we could and could't do when we participated with OSDL and Linux Foundation work groups, and we had madatory training regarding how to not get in trouble with anti-trust enforcers. > But I do sympathize with WG14 and the Austin Group; following recent > developments with C23 and POSIX 2014, it seems that ISO is bent > on giving them a hard time. Maybe ISO/IEC, or certain players within, > are trying to shed some mass, and/or don't see C and Unix as worth > standardizing anymore. Old and busted. What's the new hotness? ISO/IEC participation has always been heavyweight, and companies are quite strategic about the understanding the cost benefit tradeoffs of participating in ISO. This has been true for years; and once various European government customers stopped requiring ISO standardization, IBM and HP pretty quickly stopped funding the standards tech writer and those of us who were on the US National Body represenatives to ISO/IEC for 23360. (And not just the US; the various companies working on the ISO/IEC 23360 effort had carefully made sure that to have their employees in other country's national bodies, to make sure the fix was in. This was not too different from what Microsoft was accused of doing while standardizing ISO/IEC 29500, although not to the same scale; there were many more countries' national bodies involved with ISO/IEC 29500. So when you say "ISO" is giving the Austin Group a hard time, I'd ask the question, "who on ISO"? And what company do they work for; or if they are an independent contractor, which company might be paying them at the time; and what the agenda of those company(s) might be?) Am I super cynical about ISO/IEC standards? Perhaps. :-) - Ted P.S. Obviously, not *everyone* in the Linux ecosystem feels this way. For example, there are many people in Debian who are much more aligned with the FSF. After all, they are one of the few distros that will use the GNU/Linux terminology demanded by Stallman. But I have talked to many Linux kernel developers over the past 30+ years, and I think have a pretty good sense of what the bulk of the "old-timers" priorities have been. After all, if we had been much more aligned with the FSF's philosophies, perhaps we would have worked on GNU/HURD isntead. :-)

5 months, 3 weeks

1
0
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Adam Thornton

Moving over to COFF from TUHS. The following was Larry McVoy: > I don't consider myself to be that good of a programmer, I can point to > dozens of people my age that can run circles around me and I'm sure there > are many more. But apparently the bar is pretty low these days and I > agree, that's sad. > > It's hard not to feel like the bar is lower. I feel like since Steve Grandi retired at NOIRLab, I and Josh Hoblitt are the only people left who actually understand how IP networks work. And I'm not great, never was, but I know a lot more than...everyone else. And kids these days, well, I'm not very fluent in TypeScript and I really don't understand why every damn thing needs to be asynchronous especially if you're just awaiting its completion anyway. But, hey, it ain't that hard to do. But again, there's a part of me that wonders how relevant the skills I miss *are* anymore. I'm a software developer now, but I always thought of myself as basically a sysadmin. It's just that we had automated away all of what I started out doing (which was, what, 35-ish years ago?) by 20 years ago, and staying ahead of the automation has made me, of necessity, a software developer now. But I was also thinking of Larry saying he wouldn't last a week in today's workplace, and I'm not sure that's true. I mean, there's a lot of stuff that you once COULD say that would these days get you a quick trip through HR and your crap in a box and a walk to the curb...but I am a pretty foul-mouthed individual, and I have said nasty things about people's code, and, indeed, the people who are repeat offenders with respect to said code, and nevertheless I have had surprisingly few issues with HR these last couple decades. So in some sense it really DOES matter WHAT it is that's offensive that you're saying, and I am living-and-still-employed proof. If you generally treat people with respect until they prove they don't deserve it, and you base your calumny on the bad technical decisions they make and not their inherent characteristics, then it really ain't that hard to get along in a woke workplace. And I say this as an abrasive coworker, who happens to be a cis het white dude from a fairly-mainstream Christian background and the usual set of academic credentials. Let's face it: to do a good job as a software developer or generally an IT person, you do not need a penis. You do not need to worship the way most people at your workplace do. You do not need a college degree, let alone in CS. You do not need to be sexually attracted to the opposite sex. You do not need to have the same gender now that you were assigned at birth. You do not need two (or given the current state of the art, ANY) working eyes. Or hands. You do not need to be under 40. You do not need to be able to walk. You do not need pale skin. And anyone who's saying shit about someone else based on THAT sort of thing *should* be shown the curb, and quickly. And the fact that many employers are willing to do this now is, in my opinion, a really good thing. On the other hand, if someone reliably makes terrible technical decisions, well, yeah, you should spend a little time understanding whether there is a structural incentive to steer them that way and try to help them if they're trainable, but sometimes there isn't and they're not. And those people, it's OK to say they've got bad taste and their implementations of their poor taste are worse. And at least in my little corner of the world, which is quasi-academic and scientific, there's a lot of that. Just because you're really really good at astronomy doesn't mean you're good at writing intelligible, testable, maintainable programs. Some very smart people have written really awful code that solved their immediate problems, but that's no way to start a library used by thousands of astronomers. But whether or not they're competent software engineers ain't got shit to do with what they have in their pants or what color their skin is. And it's not always even obvious bigotry. I don't want to work with toxic geniuses anymore. Even if the only awful things they do and say are to people that they regard as intellectually inferior and are not based on bullshit as above...look, I'd much rather work with someone who writes just-OK code and is pleasant than someone who writes brilliant code and who's always a quarter-second from going off on someone not quite as smart as they are. Cleverness is vastly overrated. I'd rather have someone with whom I don't dread interacting writing the stuff I have to interface with, even if it means the code runs 25% slower. Machine cycles are dirt cheap now. The number of places where you SHOULD have to put up with toxicity because you get more efficient code and it actually matters has been pretty tiny my entire adult lifetime, and has been shrinking over that lifetime as well. And from a maintainability standpoint...if I encounter someone else's just-OK code, well, I can probably figure out what it's doing and why it's there way, way more easily than someone's code that used to be blazing fast, is now broken, and it turns out that's because it encodes assumptions about the runtime environment that were true five years ago and are no longer correct. That said, it's (again, in my not-necessarily-representative experience) not usually the nonspecific toxic genius people who get in trouble with HR. The ones who do, well, much, MUCH, too often, are the people complaining about wokeness in the workplace who just want to be able to say bad things about their coworkers based on their race or gender (or...) rather than the quality of their work, and I'm totally happy to be in the "That's not OK" camp, and I applaud it when HR repeats that and walks them out the door. Adam

6 months, 4 weeks

2
1
0 0

Penn State

by G. Branden Robinson

At 2024-10-02T16:42:59-0400, Dan Cross wrote: > On Wed, Oct 2, 2024 at 2:27 AM <arnold(a)skeeve.com> wrote: > > Also true. In the late 80s I was a sysadmin at Emory U. We had a Vax > > connected to BITNET with funky hardware and UREP, the Unix RSCS > > Emulation Program, from the University of Pennsylvania. Every time I > > had to dive into that code, I felt like I needed a shower > > afterwards. :-) > > Uh oh, lest the UPenn alumni among us get angry (high, Ron!) I feel I > must point out that UREP wasn't from the University of Pennsylvania, > but rather, from The Pennsylvania State University (yes, "The" is part > of the name). UPenn (upenn.edu) is an Ivy in Philly; Penn State > (psu.edu) is a state school in University Park, which is next to State > College (really, that's the name of the town) with satellite campuses > scattered around the state. There's another method of distinguishing UPenn from Penn State. Permit me to share my favorite joke on the subject, from ten years ago. "STATE COLLEGE, Pa. -- Construction workers tore down Penn State's iconic Joe Paterno statue on campus two years ago -- but this town might not be without one for much longer. Two alumni already have received the OK from the borough to install a projected $300,000 life-sized bronze sculpture downtown, about two miles from the original site." -- ESPN ([1]) "The key difference is that the new statue will look the other way." -- Chris Lawrence Regards, Branden [1] https://www.espn.com/college-football/story/_/id/10828351/joe-paterno-honor…

7 months

1
0
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Paul Winalski

On Tue, Oct 1, 2024 at 9:13 AM <arnold(a)skeeve.com> wrote: > This goes back to the evolution thing. At the time, C was a huge > step up from FORTRAN and assembly. > Certainly it's a step up (and a BIG step up) from assembly. But I'd say C is a step sidewise from Fortran. An awful lot of HPTC programming involves throwing multidimensional arrays around and C is not suitable for that. -Paul W.

7 months

3
2
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Paul Winalski

On Tue, Oct 1, 2024 at 10:07 AM <arnold(a)skeeve.com> wrote: [regarding writing an Ada compiler as a class project] > Did you do generics? That and the run time, which had some real-time > bits to it (*IIRC*, it's been a long time), as well as the cross > object code type checking, would have been real bears. > > Like many things, the first 90% is easy, the second 90% is hard. :-) > > I was in DEC's compiler group when they were implementing Ada for VAX/VMS. It gets very tricky when routine libraries are involved. Just figuring out the compilation order can be a real bear (part of this is the cross object code type checking you mention). From my viewpoint Ada suffered two problems. First, it was such a large language and very tricky to implement--even more so than PL/I. Second, it had US Government cooties. -Paul W.

7 months

1
0
0 0

Re: [TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

by Stuff Received

[-->COFF] On 2024-10-01 10:56, Dan Cross wrote (in part): > I've found a grounding in mathematics useful for programming, but > beyond some knowledge of the physical constraints that the universe > places on us and a very healthy appreciation for the scientific > method, I'm having a hard time understanding how the hard sciences > would help out too much. Electrical engineering seems like it would be > more useful, than, say, chemistry or geology. I see this as related to the old question about whether it is easier to teach domain experts to program or teach programmers about the domain. (I worked for a company that wrote/sold scientific libraries for embedded systems.) We had a mixture but the former was often easier. S. > > I talk to a lot of academics, and I think they see the situation > differently than is presented here. In a nutshell, the way a lot of > them look at it, the amount of computer science in the world increases > constantly while the amount of time they have to teach that to > undergraduates remains fixed. As a result, they have to pick and > choose what they teach very, very carefully, balancing a number of > criteria as they do so. What this translates to in the real world > isn't that the bar is lowered, but that the bar is different. > > - Dan C.

7 months

1
0
0 0

Shadowing variables in Go.

by Ralph Corderoy

Taken to COFF... Hi Arnold, > In main(), I *think* I'm assigning to the global clientSet so that > I can use it later. But because of the 'err' and the :=, I've > actually created a local variable that shadows the global one, and in > otherfunc(), the global clientSet is still nil. Kaboom! > > The correct way to write the code is: > > var err error > clientSet, err = cluster.MakeClient() // or whatever I think this is a common problem when learning Go, like assigning getchar()'s value to a char in C. It was back in ’14 anyway, when I saw https://www.qureet.com/blog/golang-beartrap/ which has an ‘err’ at an outer scope be unwritten by the ‘:=’ with the new, assigned-to ‘err’ going un-checked. The author mentions ‘go vet’ highlights these cases with -shadow, which is off by default. https://pkg.go.dev/github.com/golangci/govet#hdr-Shadowed_variables suggests that's still the case. -- Cheers, Ralph.

7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF