smarks
Joined 11 years ago
Joined 11 years ago
[1]: https://openjdk.org/jeps/524
The article points out a potential pitfall with how this version of the API exposes a sealed class. If the application has an exhaustive switch expression that lists all permitted subclasses, and a later JDK release were to add a new permitted subclass, this would potentially expose the application to a MatchException at runtime.
In the JDK 27 version of the PEM Encodings API, JEP 538 [2], we’ve adjusted the permitted subclasses of the sealed class in question to include a non-public permitted subclass.
[2]: https://openjdk.org/jeps/538
This prevents applications from using an exhaustive switch expression by enumerating all permitted subclasses. This allows the JDK to extend set of permitted subclasses in the future without exposing applications to the risk of unexpected exceptions.
At some point during all my fiddling with this stuff, I discovered a correlation between GPU power consumption (as indicated by iStat Menus) and fan speed. For example, if I switched to high resolution, the power would increase, and at low resolution, power would decrease. And of course more power means more heat, which causes the fans to run. That kind of made sense: moving more pixels consumes more power.
But I also observed an effect caused by refresh rate. Oddly, I seem to recall 30Hz would cause increased power draw but 60Hz the power draw was reduced. Yes, this seems counterintuitive. Since I didn't have a good model for what caused the increased power draw, I decided to try all combinations of the settings. On a lark I tried inverting the image and it actually affected the power draw! Probably has something to do with the access order of memory, but I don't really know. And indeed it seems odd that running the image upside down actually pulled less power than right side up.
The cabling issue was a bit more complicated. My initial configuration was to run the video through a dock, with the dock's video output going to the monitor. That always resulted in high power draw. Connecting the computer directly to the monitor did have the effect of reducing power draw... but only in certain configurations.
I had (and still have) a 4k external monitor. Naturally I wanted the MBP to drive the monitor with a resolution that took advantage of all the pixels. Unfortunately with most monitor settings the GPU power consumption would produce enough heat to run the fans even if the rest of the system was completely idle! If I set the output to full HD the GPU would cool down and the fans would turn off. But full HD on a 4k monitor is a waste.
It was very strange. I could drive the monitor at 4k but with the image upside down, and the power consumption would be low. But flip the image right side up and it would run hot and turn on the fans.
It took a couple weeks of fiddling, but I finally found a combination of refresh rate, resolution, image orientation (right side up!), and cabling that let me drive the monitor at high resolution without running the fans. What a pain.
(I used iStat menus to monitor GPU power consumption. At “good” settings it consumed about 5w. At “bad” settings it would consume 17w. At a bad setting you could immediately see the various temperatures go up and the fans spinning up to compensate.)
I actually still use SCCS… sort of. I have some old code bases that are stored in SCCS. They’re actually Sun CodeManager/Teamware repositories, which used SCCS for file storage. I don’t actually update any files in SCCS; I use it only for browsing history. These old repos have been converted to git, but somehow I find it harder to trace through the history in the converted repo.
Instead, I use the open-sourced version of SCCS commands that the late Jörg Schilling ported to various OSes from the OpenSolaris/SVR4 source base. The guy was a real fan of SCCS. He even gave a conference talk on it once. Kind of retro computing, but for software instead of hardware.
After a while my normal procedure was to run with the thing sitting on top of an ice pack. That would let me run a 60-90 minute video conference without troubles.
The only redeeming feature of these machines is that they could emulate old x86 hardware at speed. That allowed me to run old apps on old OSes without having to keep old hardware running.
/* As outlined in RFC 2525, section 2.17, we send a RST here because
* data was lost. To witness the awful effects of the old behavior of
* always doing a FIN, run an older 2.1.x kernel or 2.0.x, start a bulk
* GET in an FTP client, suspend the process, wait for the client to
* advertise a zero window, then kill -9 the FTP client, wheee...
* Note: timeout is always zero in such a case.
*/
Ok, so the RST is explained and well justified by the literature. But what are the “awful effects” of sending FIN instead? Can someone explain?Much of the film was shot at the Lawrence Hall of Science in the hills above Berkeley, California. This building was probably chosen because of its unique brutalist hexagonal architecture. I spent a bunch of time there as a kid.
Eric Braeden (Forbin) is still alive, but his house in Pacific Palisades burned down in the 2025 fires. :-(
[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?
[1]: https://news.ycombinator.com/item?id=50148756
The discussions around the PEM Encodings API also led my colleagues on the langtools team to write an article "Preparing for Change: Safe Switching over Sealed APIs" that discusses these issues in more detail. [2]
[2]: https://openjdk.org/projects/amber/guides/exhaustiveness-gui...
The article focuses on pattern matching and exhaustive checking, because this is an important feature for a large class of applications.
As a library designer, though, I'm primarily interested in the use of sealed classes to control subclassing. The old idiom for controlling subclassing of concrete and abstract classes was to ensure that all constructors had package access or less. This mostly prohibits subclasses outside the package. (Strictly speaking, it prohibits such subclasses from being compiled or instantiated.) For interfaces, it was formerly impossible to control subclassing at all. The addition of sealed classes to the language solves the problem completely.
Indeed, in the JDK we've converted all the uses of the older idioms to use sealed classes. [3] (This bug covers most of the changes; there are a handful of others that were converted individually.) Of the several dozen examples here, it doesn't look to me like ANY of them are candidates for pattern matching. This probably reflects the long-standing issue of subclassing control in object-oriented systems. That issue has existed in Java much longer than pattern matching. As time goes on, I expect the JDK class libraries to introduce more new APIs that make use of pattern matching and sealed classes.
[3]: https://bugs.openjdk.org/browse/JDK-8283414