[1]: N. G. Leveson and C. S. Turner, "An investigation of the Therac-25 accidents," in Computer, vol. 26, no. 7, pp. 18-41, July 1993.

[2]: Nancy Leveson. Safeware: System Safety and Computers. Addison-Wesley, 1995.

[3]: http://sunnyday.mit.edu/papers/therac.pdf

[4]: https://web.mit.edu/6.033/2014/wwwdocs/papers/therac.pdf

I'm assuming you're using octal here. Myself, I haven't used octal since 03677.

:-)

I see you mentioned https://interlisp.org/ ; while it's not a Lisp machine, the Medley Interlisp Project aims to recreate the Interlisp environment that ran on Xerox D-machines up through the 1980s or so. Still very interesting.

> Then, seemingly out of nowhere...

> In my case, the “Wake for maintenance” option was disabled...

So presumably the option was originally enabled. Somehow it was disabled, resulting in the battery-draining behavior. Re-enabling it manually solved the problem. Great.

But how did the setting get changed in the first place?

I've noticed this on my Macs (actually mostly the new one; not the old, obsolete ones I still run) as well as various iOS devices. At some point I'll notice some odd, unusual, or different behavior. Hunting around in the settings, I'll sometimes find an option that seems like it should control the behavior. Changing the setting has the desired effect of restoring the former behavior. So what changed it? It's a mystery.

A memorably egregious example was the "do not disturb" setting. I normally have do-not-disturb enabled from 11pm to 7am on my phone so I'm not awakened by notifications. But one night I was awakened at 3am by my phone buzzing, because some random text message had arrived. Huh?!? The next day, working on my Mac, it seemed unusually quiet... maybe a lot of people were on vacation or something. Then I checked Slack and there were a lot of messages pending, questions put to me that went unanswered, and even speculation that I had gone on vacation. What happened? My Mac had somehow set itself to do-not-disturb from 9am to 5pm, which covers most of the workday. And my iOS devices also had do-not-disturb set for the same incorrect time interval. (Well at least I got a lot of work done.)

In this case I suspect iCloud settings synching was the culprit. My conjecture is that I logged into my iCloud account from a new device, and that device's default settings got synched to my other devices. But I'm not entirely sure.

I know I've had other cases where settings seemed to be changed spontaneously. My speculation is that OS updates will change settings. Unfortunately this isn't reproducible, and it happens rarely and with different settings. But it's happened enough times over the past couple years that it seems to be a pattern. Maybe it happened to the OP. Does anybody else experience this?

https://groups.google.com/g/comp.lang.lisp/c/T_Tozq2P53I/m/N...

Lee's post seems more of a question, but to my eye it's a "why X" question that thinly disguises an "X is bad (or ugly, redundant, useless, confusing, counterproductive, unnecessary, etc.)" argument. Essentially though it's the same topic.

The post elicited around 60 responses, among them this one from the late Erik Naggum:

https://groups.google.com/g/comp.lang.lisp/c/T_Tozq2P53I/m/g...

which includes the following gem (or turd, depending upon your point of view):

  > All in all, the pairs notion is redundant.
  
  I hope you understand and appreciate what I have written above so the
  following does not apply to you anymore. you see, I wrote it all because
  I _really_ wanted to say that that sentence is the single most ignorant
  and shallow-minded line that I have ever seen in any programming language
  newsgroup or forum and I hope _never_ to see anybody display such utter
  disregard for the brilliance and genius of people who came before them
  just because they grew up in an age when "simple interface" is sneered
  and laughed at in favor of "simple implementation" so any dumb fsck can
  implement it right out of a "for Dummies" book.

[1]: https://herbsutter.com/2024/08/07/reader-qa-what-does-it-mea...

[2]: https://news.ycombinator.com/item?id=43779449

For reference, the actual proposal that was accepted into C++26 is [2]. It discusses performance only in general, and it refers to an earlier analysis [3] for more details. This last reference describes regressions of around 0.5% in time and in code size. Earlier prototypes suggested larger regressions (perhaps even "horrendous") but more emphasis on compiler optimizations has brought the regression down considerably.

Of course one's mileage may vary, and one might also consider a 0.5% regression unacceptable. However, the C++ committee seems to have considered this to be an acceptable tradeoff to remove a frequent cause of undefined behavior from C++.

[1]: https://herbsutter.com/2024/08/07/reader-qa-what-does-it-mea...

[2]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

[3]: https://open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1...

We've been using TCO here ("tail call optimization") but I recall Guy Steele advocating for calling this feature TCE ("elimination") because programs can rely on TCE for correctness.

However, there are other things still in the platform for which stack frames are significant. These are referred to as “caller sensitive” methods. An example is Class.forName(). This looks up the given name in the classloader of the class that contains the calling code. If the stack frames were shifted around by TCO, this might cause Class.forName() to use the wrong classloader.

No doubt there are ways to overcome this — the JVM does inlining after all — but there’s work to be done and problems to be solved.

Another common source of comparator bugs is when people compare floats or doubles and they don’t account for NaN, which is unequal to everything, including itself!

In Java, the usual symptom of comparator bugs is that sort throws the infamous “Comparison method violates its general contract!” exception.

https://datatracker.ietf.org/doc/html/rfc9413

I don't think Postel's Law was necessarily a bad idea, in its time and context. However it seems to have fallen into usage as an argument-ender. This RFC is a useful antidote to that.

Ah yes, the proverbial "glass TTY." There were a few years in the late 1970s where printing terminals (actual Teletypes such as the ASR 33, and matrix printing terminals like the DECwriter) were fading out and "dumb" CRT terminals came in. When I arrived at university in 1980 the computer center was filled with dumb terminals like the ADM-3. There were a few smart terminals (they could run Emacs!) but they were hard to come by.

Within a couple years, though, the dumb terminals were all gone and were replaced by "smart" CRT terminals that had the more sophisticated features. So the lifetime of the glass TTY might have been only 5-10 years.

I think the scheme was fairly clever but it wasn't terribly sophisticated; nothing like public-key crypto for instance. It did have a number of countermeasures that attempted to prevent cheating, such as restarting from a modified save file. For example, I believe it hashed all the bytes of the file, plus a bunch of metadata -- possibly including the uid and the file's i-number, as you suggest -- and also things like the file modification time and maybe even the i-node change time. Then it would write this hash back into the file. I seem to recall a bit of cleverness to avoid problems because writing the hash could potentially modify things like the file modification time. Maybe it just retried until the modtime didn't change. Not too difficult since the granularity was one second.

In principle this is easy to defeat if you know the hash algorithm, and if you knew how to use the Unix system calls to change a file's modification time. Since the original rogue program was closed source, the hash algorithm was secret. But eventually somebody reverse-engineered it, and programs emerged that were able to successfully copy save files.

Such a letdown. You'd play for hours and it would all be over in an instant. That damned tombstone.

I know Dijkstra is famous for having said that we're mentally mutilated beyond hope of regeneration, but you know, I kinda think we didn't turn out half bad.