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.
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
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.
> 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
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/1594859115557232640https://x.com/allenholub/status/1613609655519019008https://x.com/allenholub/status/1656811047783899138https://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.
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
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
[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.
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
(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. :-)
