janzer

Just a note: the Technology Connections video above goes over why this doesn't work well for cars (but does for train locomotives).

Have you ever combined KSP with the coding instruction using either kOS[1] or kRPC[2]?

1. https://ksp-kos.github.io/KOS_DOC/ 2. https://krpc.github.io/krpc/

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.

Yes, Apple, Windows, Amazon, Shell, Target, Dove, Ivory, Tide, Polo.

(With help from Claude completing the list)

Well if you ask it to show you the seahorse emoji it tries really hard. :)

https://grok.com/share/c2hhcmQtMw_d7bf061f-2999-46b6-a7fb-58...

Although it does eventually come to the right conclusion... sort of.

It would be really nice if something said what the actual problem was.

The last commit[0] is a fix for date parsing to bring it in line with the GNU semantics, which seems like a pretty good candidate.

Edit: Or not, see evil-olive's comment[1] for a more likely candidate.

0: https://github.com/uutils/coreutils/commit/0047c7e66ffb57971...

1: https://news.ycombinator.com/item?id=45687743

Sadly the 6000 mile antenna never got built, but they did get a few tens of mile long ones built.

https://en.wikipedia.org/wiki/Project_Sanguine

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..."

(1997) with some updates/postscripts through 2008

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.

1. https://dl.acm.org/doi/10.1145/37402.37406

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.

https://peps.python.org/pep-0617/

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.

Records and specific rules for all categories can be found at https://www.speedrun.com/factorio

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.

> that your pad generation is actually random

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.

FYI, the original freenet can now apparently be found under the name hyphanet[1].

Although it seems there has been no activity since the rename happened almost a year ago?

1. https://www.hyphanet.org/freenet-renamed-to-hyphanet.html

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.

It seems that this has been in syncthing about 2.5 years[1], is there something that changed recently to make this notable now?

[1] Initial release behind a feature flag in 1.15 on April 6, 2021 and without the feature flag in 1.16 on May 4, 2021.

From the article: Nishimura, which has the scientific name C/2023 P1, will pass closest to the sun on 17 September.

Closest to the sun, not earth. Also, while not an area I have much knowledge in, I believe it gets rather harder to view as the angle between it and the sun narrows.

For those wanting to try this out note that the download links in this post are still giving the previous Bullseye (11.7) release at the moment.

Yep, definitely right there with you on this one. Every time I think oh this will be an interesting blast from the past, followed by bah, get off my lawn...

Not sure what your exactly looking for this to be, but you can already become eligible for citizenship via military service.

https://www.uscis.gov/military/naturalization-through-milita...

Since the article starts right off by stating almost the direct opposite, I'd guess the matter is at least less certain/more debated than the wikipedia article makes it out to be.

Guido stepping down from BDFL may indeed be what allowed the recent speed improvements to progress; but certainly not in the way you're implying. If there is a causal effect here it seems more likely that it's because it has allowed him to concentrate more on the speed improvement work than he otherwise would have with BDFL issues taking up his time.

From what I've seen Guido has been quite actively involved in the speed up work, somewhat in the actual development but even more so in getting it merged (a problem many previous speed up attempts have failed at).

There's quite a bit more than just the unittest removals

https://docs.python.org/dev/whatsnew/3.12.html#removed

An example of a more recent deprecation is the 'distutils' module which was deprecated in 3.10.

A one character typo seems more likely, than a non-standard date format for two dates in the future being used as timestamps.