Now we get to guess if it's broken in the same way as gpt, or did it pick up that pattern from all the cases of people posting it on the internet. (In the second case, that's not a good look for their data cleanup process)
I so miss bazaar's UI around merges/commits/branches. I feel like most of the push for squashing is a result of people trying to work around git's poor UI here.
The 650 main memory was a drum; but what IBM called Random Access Memory (and RAM) for this machine was a hard drive. As described in the Manual of Operation linked above. Here are a few quotes:
"Records in the IBM Random Access Memory Unit are stored on the faces of magnetic disks."
"The stored data in the Random Access Memory Unit are read and written by access arms."
"The IBM 355 RAM units provide extemely large storage capacity for data... Up to four RAM units can be attached to the 650 to provide 24,000,000 digits of RAM storage."
The main memory on the other hand:
"The 20,000 digits of storage, arranges as 2000 words of memory on the magnetic drum..."
Given that the actual vulnerability seems relatively niche along with it being such a popular library officially maintained by the Python foundation, the scariest line in the advisory is almost certainly:
The vulnerability was originally reported to the library maintainers on September 12, 2024, but no fix is available.
Just a clarifying note, Craig Reynolds is the original researcher for Boids, and he did have a Java applet implementation in the above page. But the original Boids simulation was from 1986, almost a decade prior to Java applets.
The original paper, published in 1987, is "Flocks, herds and schools: A distributed behavioral model"[1]. The implementation was done in Lisp on a Symbolics 3600 Lisp Machine.
Edit: One quite interesting paragraph from the paper regarding performance:
The boid software has not been optimized for speed. But
this report would be incomplete without a rough estimate of the actual performance of the system. With a flock of 80 boids, using the naive O(N²) algorithm (and so 6400 individual boid-to-boid comparisons), on a single Lisp Machine without any special hardware accelerators, the simulation ran for about 95 seconds per frame. A ten-second (300 frame) motion test took about eight hours of real time to produce.
Once again, amazing how far hardware has advanced.
I've had a lot of fun playing with BBC Microbot (https://bbcmic.ro/). If you add &experimental=true to the URL it will add a rocket ship button underneath the display. Clicking it sends the code off to beebjit and runs it for 10,000 seconds instantly, allowing you to do unreasonable things such as this: https://bbcmic.ro/?t=bC9Go (not mine)
I'm pretty positive that is showing the reverse, i.e. how much a given "location" is moving using gps coordinates. Not adjusting the gps coordinates to refer to a constant "location".
(With help from Claude completing the list)