- COFF - www.tuhs.org

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

4 days

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

2 weeks, 6 days

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.

1 month

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

1 month, 2 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.

1 month, 2 weeks

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

1 month, 3 weeks

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.

1 month, 3 weeks

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

1 month, 3 weeks

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

1 month, 3 weeks

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.

1 month, 4 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

COFF