Nick @internic@qoto.org

It’s time for a special holiday Bridgy Fed status update!

Since last time, we’ve been working mostly on getting A New Social off the ground and on Bridgy Fed internals. Specifically, my development focus for a while now has been cost cutting. I fund Bridgy Fed myself right now, which I’m happy to do, but it costs more to run than it should, probably by 2-3x or so.

(We do plan to fundraise for A New Social eventually and fund Bridgy Fed there instead! Including individual donations, among other sources. Stay tuned for more news when we have it.)

In the meantime, I’ve been pushing the optimization boulder uphill, making slow progress. I’m currently struggling with one big issue: getting caching working in ndb, our ORM.

ndb can cache both in memory and in memcache. We configure it to do both, but it doesn’t seem to be using memcache in production, and I’m not even sure it’s caching in memory there either. If you have experience with ndb, Google Cloud Datastore, Memorystore, or related tools, please take a look and let me know if you see anything obviously wrong!

This also means that I haven’t had much time to spend on features, bug fixes, or other user-visible updates. I’m the only developer on Bridgy Fed right now, and I’m only part time. I’d love help! It’s entirely open source, so if you’re interested, check out the open issues, feel free to dive in, and ping me on GitHub if you have any questions!

Having said that, I have done a bit besides cost cutting since last time:

Generate link previews (aka embeds) on Bluesky.
Launch Threads support! Just via normal ActivityPub, nothing special, but I worked with them a fair amount on interop.
Improve sign-up flow for web => Bluesky bridging.
Try harder to redirect fediverse @-mentions of bridged users to their web site or Bluesky profile.
Reduce confusion on the home page sign-up form by detecting web sites that are already fediverse instances.
Let fediverse accounts re-enable the bridge even if they disabled it before October.
Improve interop with Friendica, Hubzilla, Misskey/Sharkey, Sharkey, WordPress Friends plugin, and GoToSocial.
Improve authorization to prevent a cache poisoning attack.
Improve DNS scaling for Bluesky handles.
Populate the discoverable and indexable flags on bridged ActivityPub actors.
Misc bug fixes for web sites on www subdomains.
Fix rare bug where we occasionally missed bridging posts or other interactions to Bluesky.
Fix rare bug where we occasionally missed bridging deletes.
Continued debugging of accounts bridged into Bluesky that occasionally get stuck and stop bridging.
Lots of docs improvements.

As usual, feel free to ping us with feedback, questions, and bug reports. You can follow the now label on GitHub to see what we’re currently focusing on. See you on the bridge!

Ten million new cases of dementia are reported globally each year. But a recent study suggests up to 13 percent of people diagnosed with dementia in the U.S. may have a misdiagnosis and are instead struggling with a condition called hepatic encephalopathy. The upside: it’s treatable. @ScienceAlert has more.

https://flip.it/JYLv2Y

#Science #Health #Humans #Neurology #Brain

Mathematical physicist Cécile DeWitt-Morette was born #OTD in 1922. She made foundational contributions to the study of Feynman functional integrals, organized the first American conference on general relativity (playing an indirect but important role in the eventual detection of gravitational waves), and started the Les Houches Summer School.
Images: UT-Austin

Some people think medieval astronomers kept adding 'epicycles' to the orbits of planets, culminating with the Alfonsine Tables created in 1252. The 1968  Encyclopædia Britannica says:

"By this time each planet had been provided with from 40 to 60 epicycles to represent after a fashion its complex movement among the stars."

But this is complete bullshit!

Medieval astronomers did *not* use so many epicycles. The Alfonsine Tables, which the Brittanica is complaining about above, actually computed planetary orbits using Ptolemy's method, developed way back in 150 AD. This method uses just 6 circles and 6 epicycles - nothing like Britannica's ridiculous claim of between 240 and 360 epicycles.

That's right: Ptolemy got a good fit to planetary orbits using one circle and one epicycle each for the Sun, Mercury, Venus, Mars, Jupiter and Saturn. It's not much worse than what we do now: use one ellipse each for Mercury, Venus, Earth, Mars, Jupiter and Saturn.

I must admit that in Ptolemy's model, the circles weren't centered on the Earth. They were offset, like in the gif below, where the big green dot is the Earth. The big blue circle, offset from the Earth, is called a 'deferent'. This approximates an ellipse. The smaller black circle is called an epicycle. This makes up for how the Earth is not actually stationary, but moving around the Sun.

This gif was created by Richard W. Pogge, Distinguished Professor of Astronomy at Ohio State. You can see more of his animated planetary models here:

https://www.astronomy.ohio-state.edu/pogge.1/TeachRes/Artwork/Anims/index.html

So, just because something is in an encyclopedia, or even an encyclopædia, doesn't mean it's true. Don't believe me? Check out the references in part 2!

(1/2)

@nixCraft and youtube now shows a popup on brave, whenever I play a video, pathetic.

I finally turned off GitHub Copilot yesterday. I’ve been using it for about a year on the ‘free for open-source maintainers’ tier. I was skeptical but didn’t want to dismiss it without a fair trial.

It has cost me more time than it has saved. It lets me type faster, which has been useful when writing tests where I’m testing a variety of permutations of an API to check error handling for all of the conditions.

I can recall three places where it has introduced bugs that took me more time to to debug than the total time saving:

The first was something that initially impressed me. I pasted the prose description of how to communicate with an Ethernet MAC into a comment and then wrote some method prototypes. It autocompleted the bodies. All very plausible looking. Only it managed to flip a bit in the MDIO read and write register commands. MDIO is basically a multiplexing system. You have two device registers exposed, one sets the command (read or write a specific internal register) and the other is the value. It got the read and write the wrong way around, so when I thought I was writing a value, I was actually reading. When I thought I was reading, I was actually seeing the value in the last register I thought I had written. It took two of us over a day to debug this. The fix was simple, but the bug was in the middle of correct-looking code. If I’d manually transcribed the command from the data sheet, I would not have got this wrong because I’d have triple checked it.

Another case it had inverted the condition in an if statement inside an error-handling path. The error handling was a rare case and was asymmetric. Hitting the if case when you wanted the else case was okay but the converse was not. Lots of debugging. I learned from this to read the generated code more carefully, but that increased cognitive load and eliminated most of the benefit. Typing code is not the bottleneck and if I have to think about what I want and then read carefully to check it really is what I want, I am slower.

Most recently, I was writing a simple binary search and insertion-deletion operations for a sorted array. I assumed that this was something that had hundreds of examples in the training data and so would be fine. It had all sorts of corner-case bugs. I eventually gave up fixing them and rewrote the code from scratch.

Last week I did some work on a remote machine where I hadn’t set up Copilot and I felt much more productive. Autocomplete was either correct or not present, so I was spending more time thinking about what to write. I don’t entirely trust this kind of subjective judgement, but it was a data point. Around the same time I wrote some code without clangd set up and that really hurt. It turns out I really rely on AST-aware completion to explore APIs. I had to look up more things in the documentation. Copilot was never good for this because it would just bullshit APIs, so something showing up in autocomplete didn’t mean it was real. This would be improved by using a feedback system to require autocomplete outputs to type check, but then they would take much longer to create (probably at least a 10x increase in LLM compute time) and wouldn’t complete fragments, so I don’t see a good path to being able to do this without tight coupling to the LSP server and possibly not even then.

Yesterday I was writing bits of the CHERIoT Programmers’ Guide and it kept autocompleting text in a different writing style, some of which was obviously plagiarised (when I’m describing precisely how to implement a specific, and not very common, lock type with a futex and the autocomplete is a paragraph of text with a lot of detail, I’m confident you don’t have more than one or two examples of that in the training set). It was distracting and annoying. I wrote much faster after turning it off.

So, after giving it a fair try, I have concluded that it is both a net decrease in productivity and probably an increase in legal liability.

Discussions I am not interested in having:

You are holding it wrong. Using Copilot with this magic config setting / prompt tweak makes it better. At its absolute best, it was a small productivity increase, if it needs more effort to use, that will be offset.
This other LLM is much better. I don’t care. The costs of the bullshitting far outweighed the benefits when it worked, to be better it would have to not bullshit, and that’s not something LLMs can do.
It’s great for boilerplate! No. APIs that require every user to write the same code are broken. Fix them, don’t fill the world with more code using them that will need fixing when the APIs change.
Don’t use LLMs for autocomplete, use them for dialogues about the code. Tried that. It’s worse than a rubber duck, which at least knows to stay silent when it doesn’t know what it’s talking about.

The one place Copilot was vaguely useful was hinting at missing abstractions (if it can autocomplete big chunks then my APIs required too much boilerplate and needed better abstractions). The place I thought it might be useful was spotting inconsistent API names and parameter orders but it was actually very bad at this (presumably because of the way it tokenises identifiers?). With a load of examples with consistent names, it would suggest things that didn't match the convention. After using three APIs that all passed the same parameters in the same order, it would suggest flipping the order for the fourth.

#GitHubCopilot #CHERIoT