Agree, except the probabilities for outcomes in the structured output. I don't think you can get those for most frontier LLMs (logprobas). You can get it for open source models but not frontier LLMs.

That number is a big deal, assuming it is well calibrated. Did they talk about calibration?

I've seen them talk about it a bit on Twitter -- it seems to be fairly well-calibrated in general, but obviously you need to test it on your use case and dial it in comparison with known data for best results.

Found it interesting that a company with this sort of a valuable IP would be using internet reachable GitHub (not behind an internal network / VPN?) and a bunch of safeguards for the IP. What's to stop one disgruntled employee from leaking the entire monorepo to a competitor?

Unimaginable luxury, what are you in about. Have you ever even been outside of US?

you might enjoy the first chapter of Diaspora by Greg Egan

https://www.gregegan.net/DIASPORA/01/Orphanogenesis.html

> I have a corollary hypothesis which is that only young people are actually conscious. One day you go to bed and your mind never wakes up, but your body keeps on living the automaton till you actually die.

Thank you for a new existential fear unlocked. Why do you believe this?

Reminds me of https://www.theintrinsicperspective.com/p/they-die-every-day

I have made a setup that I am really proud of.

Syncthing + Tailscale + old Raspberry Pi + external USB SSD disks + restic for backup + B2

Raspberry Pi OS + syncthing data is on one SSD disk (encrypted)

Restic backs up to second SSD disk (encrypted) and a separate (encrypted) backup is sent to B2

Why does Synchting need Tailscale? It establishes a similar connection.

So that it has a connection even if I am outside of my home network

Synchting uses the same protocols to establish the connection, as far as I know. It even has relays. It will sync without VPN even if you are outside home.

A fair point, I use tailscale for other things too, so it's a freebie

Agreed. It's also objectively worse because you lose the stack trace in the final exception you will display to your user. Enjoy debugging that when a customer sends you an error.

Or you could use a 3rd party error package that’s not a good excuse because the standard don’t have it as a priority

I don't agree with this post.

Engineering is about tradeoffs.

There is more advantage in doing the accepted python solution (exceptions) than inventing your own (which you claim to be better, but I personally think is worse). If you are developing in a team, stick to established conventions and spend your time focusing on your business problem.

The flask-login package should have limited its dependencies to flask<3.0, that's what major versions are for.

So consider what happens when you try to learn Flask in a world like the one you describe. You pip install Flask, and you get 3.0. Next chapter asks you to install Flask-Login, and now you are forced to downgrade Flask.

What you are saying makes sense when there are important reasons to break compatiblity. But I expect the Flask side to love their users a bit more and not break their code for trivial reasons.

> trivial reasons

This is a bit like a No True Scotsman argument. It says that there are reasons for what happened but they didn't have a Good Reason. Why are their reasons so particularly trivial?

> try to learn Flask in a world like the one you describe

This seems moot if the Flask maintainers are using semantic versioning correctly. I'd probably look into it and think that Flask-Login maintainers should have limited their Flask version if they were going to step away from maintenance. If someone else wants to pick it up they can fork it or try to get in touch with the old maintainers to get access to the central repo.

> You pip install Flask, and you get 3.0

The learning material should specify a major version so this doesn’t happen.

framework developer isn't responsible for random tutorials going out of date because abandoned plugin wasn't updated in 2+ years