arthur-st

Yes, although it's not worded in the clearest way. "Added a check that asks before a web or shell tool call sends your account email address to the network"

https://code.claude.com/docs/en/changelog#2-1-317

This was patched in 2.1.317.

What they're saying is that if something is not worth the time needed to write it, it's not worth the time needed to read it either.

iPhones have supported it for 3 years.

Yes, but a lossless encode of a lossy copy of an image results in a lossy image functionally.

The US very much has been trying to get Ukraine to surrender to Russia since Trump was elected. Quite nothing would seemingly please Trump more than Ukrainians rolling over and clearing the way to a fat kickback from Russia.

Strange blog post. Given that it's from a developer of proprietary and paid commercial encoders, the inclusion of their upcoming "aperture-alpha" encoder on the charts that are purportedly about JPEG XL makes this feel like a marketing piece of some fashion. Certainly, they advertise their Iris-WebP encoder throughout the post, with an implication that if you haven't paid to the author for it, you're not using WebP correctly, I guess?

Moreover, there are some methodological oddities. For example, JPEG XL decoding is tested in single-threaded mode when it's optimized for multi-threaded decoding (where AVIF has artifacts from tiling). Also, the tested command is "jxl_cli --speedtest", which means that the benchmarked time includes the warm-up procedure of the "--speedtest" flag, rather than the pure decoding time.

Another example of this is progressive rendering, where the comparison moment is chosen at a local maximum that favors AVIF. JPEG XL materializes a full frame much sooner than AVIF, and starting at, say, the 96,256 B mark, it looks better than AVIF until the full image is loaded.

Yes, that's essentially the only practical reason.

Self-hosted Gitea is a good time if you're comfortable taking care of backups and other self-hosting stuff.

There are two Graphite companies. The time series DB for metrics (not this) and the stacked diff code review platform (this). Looking at other comments under the post, they seem to have executed a hard AI pivot recently.

For real. I consider myself to be “into Python typing,” and yet I had no knowledge of Zuban before the parent comment and a very faint memory of Jedi.

I mean, that is what the term implies.

OpenAI is BYOK-only on OpenRouter, which artificially depresses its utilization there.

It is exactly that

To be fair, you do get enums and pattern matching from base language.

4o on ChatGPT.com vs. Opus in an IDE is like cooking food without kitchen tools vs. using them. 4o is neither a coding-optimized model nor a reasoning model in general.

I did work for a Russian financial multinational just before COVID-19, as a native Russian speaker, and it was a free-for-all mess interally. The IT side had a load-bearing, old-school sysadmin type with a personality for heroics.

Aider has been doing that for a long time now, it was the first project to do this afaik.

They have a healthy enterprise customer base, and an engineering team that clearly knows how to work with power users (which OpenAI is bad at).

They have an old-school enterprise sales operation that is doing superb work. Apart from that, ChatGPT's projects are useless crap (can't read other convos in a project; can't generate project documents from a convo), and so clearly they would get value out of just getting some developers who have built anything of use to a poweruser.

Having experience with digitizing a university textbook in physics by hand, this is a very nice LaTeX guide for everyone interested. One thing worth noting from 2025 perspective that the "default" local setup is most likely going to be VSCode with LaTeX Workshop[1] and LTeX+[2] extensions, and that you should use TeX Live on every platform supported by it (since MiKTeX and friends can lag). Also, use LuaTeX, as it's the officially recommended[3] engine since November 2024.

[1] https://marketplace.visualstudio.com/items?itemName=James-Yu...

[2] https://marketplace.visualstudio.com/items?itemName=ltex-plu...

[3] https://www.texdev.net/2024/11/05/engine-news-from-the-latex...

No, the parent clearly indicates that they consider XeTeX a worse choice than LuaTeX.

> They weren't contributing before

That is not true. Companies like AWS had paid staff working as OSS Redis core maintainers before the licencing schism. This talk of "achieving their goals" is just bluster serving no reason other than damage control.

Pyright has semantic improvements (and also some differences) over MyPy. As for using the type checker as a language server, it's difficult to go back to “it's compiling” after you've had one stop you from typing bugs out in-flight.

Check if your configuration allows pyright to use other files in the workspace.

To round out the big 4, there's also Pyre from Meta. I haven't used it myself, as when I last checked it had a low number of PEPs covered, but I've heard some good words for it.

MyPy's rules are reference-grade, being as close to an official spec as we get until the Typing Council is done establishing their moat.

To understand shortcomings of MyPy, I strongly suggest reading pyright's documentation for how they compare: https://github.com/microsoft/pyright/blob/main/docs/mypy-com...

Quoting the pertinent part:

> Pyright was designed with performance in mind. It is not unusual for pyright to be 3x to 5x faster than mypy when type checking large code bases. Some of its design decisions were motivated by this goal.

> Pyright was also designed to be used as the foundation for a Python language server. Language servers provide interactive programming features such as completion suggestions, function signature help, type information on hover, semantic-aware search, semantic-aware renaming, semantic token coloring, refactoring tools, etc. For a good user experience, these features require highly responsive type evaluation performance during interactive code modification. They also require type evaluation to work on code that is incomplete and contains syntax errors.

> To achieve these design goals, pyright is implemented as a “lazy” or “just-in-time” type evaluator. Rather than analyzing all code in a module from top to bottom, it is able to evaluate the type of an arbitrary identifier anywhere within a module. If the type of that identifier depends on the types of other expressions or symbols, pyright recursively evaluates those in turn until it has enough information to determine the type of the target identifier. By comparison, mypy uses a more traditional multi-pass architecture where semantic analysis is performed multiple times on a module from the top to the bottom until all types converge.

> Pyright implements its own parser, which recovers gracefully from syntax errors and continues parsing the remainder of the source file. By comparison, mypy uses the parser built in to the Python interpreter, and it does not support recovery after a syntax error. This also means that when you run mypy on an older version of Python, it cannot support newer language features that require grammar changes.

Astral's type checker seems to an exercise in speeding up Pyright's approach to designing a type checker, and removing the Node dependency from it.

This depends on the model, e.g., the non-entry level Forerunner series watches have had training load-related metrics for a while now. That said, Garmin is mainly a cardio watch, and by extension the Apple training load metrics seems to be giving a more presentable UX to the "default"[1] approach to cardio training load.

[1] https://evokeendurance.com/a-new-and-better-look-at-training...

This was interesting, cheers!

> especially after ... the white house praise for rust

What's the threat model here, that Rust is a trojan language from the feds?