EDIT: This was caused by using an old version uv (0.7.3) updating with `uv self update` to the latest version (0.11.2) resolved it. Original message below:
While the first form seems to work with `pyproject.toml`, it seems like the second form in the global `uv.toml` only accepts actual dates and not relative times. Trying to put a relative time (either in the form "7 days" or "P7D") results in a failed to parse error.
My understanding is they used to be fairly strict about using a set for 2 weeks before changing, but research has shown very little difference in outcomes down to 1 week.
There is some discomfort/soreness for the first few days after switching. My dentist's instructions were to wear each for at least a week and then switch to the next set whenever I wanted after that. Basically at whatever rate I was comfortable/could tolerate. I'm now at set 15 and have switched most of them after a week while a few I delayed a couple of days because I had something happening where I didn't want to worry about any discomfort.
Just to avoid confusion, while SMB as used above may be referring to the owner it typically means "Small and/or Medium Business". Where what counts as small and medium varies a bit but is generally <500 employees and annual revenue <$10 million.
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'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".
For those further interested in PEG vs LL(1) parsers. The first few sections of the Python PEP[1] where they switched from an LL(1) to PEG parser for CPython has a nice short introduction to both and their rationale for switching from LL(1) to PEG.
The current 4h12m hour record is for 100% (where you have to get every single achievement in the game, in the one run), any% (where you just need to launch a rocket) is under 2 hours (1h42 for the latest factorio v2.x, 1h18 for v1.x). There are a few other differences between the categories regarding map selection and blueprint use as well.
If the PRNG is good enough then shipping floppies full of PRNG output is very much unnecessary. Simply send the seeds used to initialize the PRNG thereby fitting many (~180k of them on a 720kb floppy) seeds on one floppy and save your couriers a lot of risk.
The one thing that stood out to me with the original blog post and a quick glance at the code was that it appeared as if the pad was certainly not actually random.
Could anyone that has actually understood it a bit more confirm or reject this?
Edit: It seems that the random generation can be found starting here https://github.com/Vulacode/RANDOM/blob/d6a1a1d694b22e6a115b...
With three methods, one (RAND2) seems to use the basic interpreter rng more or less directly and the other two seem to be fairly simple prngs seeded from the basic interpreter's rng.
I don't actually know what the state of basic interpreter rngs was in the early '80s but I would be fairly surprised if they're anything that is secure.
Let's make up some numbers, say 98% commit a single murder and 2% commit 20 leaving an average of 1.38. If the new system stops every murderer after the first one, the number of murders have a 27.5% reduction. Actual reduction quoted in the article is 12.8%.
So it could very well be true that the average number of murders committed is close to 1 and at the same time the reduction is wholly accounted for by stopping multiple murders.
I still doubt that either cause speculated on in the article are the actual full reason, or even possibly the primary reasons, but it would at least be possible with the information provided.
1. https://ksp-kos.github.io/KOS_DOC/ 2. https://krpc.github.io/krpc/