llimllib

note that if you want range queries in duckdb-wasm to work, you currently need to make sure that you disable `builtin_httpfs`, otherwise you can end up pulling a ton of data: https://github.com/duckdb/duckdb-wasm/issues/2228#issuecomme...

my tests are against the Apple Intelligence model, fwiw, not any earlier model

interesting! I only tested against Parakeet v2 because my agent suggested it would be faster for English transcription (v3 is multilingual but somewhat slower, it suggested)

On my bench, parakeet-tdt-0.6b-v2 is 2x slower

I wonder if you're using different Apple models when you go through that app? I don't know

apple's is 5x faster than `large-v3-turbo` with whisper.cpp and in my test had somewhat worse performance, so it's a tradeoff

Apple's on-device transcription model is about 3x slower than their reported results on my more powerful computer, with a similar error rate in my test (which I consider pretty good results)

I'll test theirs too if I get around to it

Here's a sample CLI wrapping the apple model and providing a simple benchmark: https://github.com/llimllib/transcribe

update: doesn't seem like they provide their model and I don't feel like trying to dig it out of their app bundle, so I'm not going to test this one

The specific language is:

> projects that mostly consist of code written by "generative AI"-tools

And "mostly" here seems egregiously undefined to me

https://codeberg.org/Codeberg/org/commit/96fac426a32d1ba91ff...

re: npm, if you upgrade your global node version, you will lose that installation, right?

Your agent writes secret.txt with the placeholder, and the tokenizing proxy replaces it with the token, then the agent reads secret.txt

Poorly! Apple’s facilities for this are the ones I know best, and they are woefully insufficient

right, but say you give the agent access to github and it can push as you, or make a gist; now it can easily exfiltrate your secret.

And that's just an easy case - really if it has any network access at all it can come up with a clever way to route a request through the network such that the key comes back somewhere in the request. If you scan for it inbound too, the machine can obfuscate it.

Our agents are trained to be so intensely helpful and they have such intricate knowledge of how things work that they will do some incredibly clever tricks to do what you ask them to do.

Operating systems ought to be providing us the utilities we need to safely sandbox processes (agent or otherwise), but they appear to not be interested in the job

This is what I currently do, but my software uses docker and docker mounts act as a bypass for the file system restrictions, plus docker processes started outside the sandbox allow network proxy escape.

Currently, I don't allow the agent access to docker, start docker myself, and then do short-lived sandbox-free sessions when the agent needs to do things that interact directly with docker; but that's annoying.

“Smoking gun”

> Is that built in protection really a filter, on code level

yes, on mac it uses seatbelt and on other platforms it uses similar tools: https://code.claude.com/docs/en/sandboxing

Yes, as a consequence of how aggressively transparent to the postgres wire protocol pgbouncer wants to be. This article does a good job explaining it: https://www.augusteo.com/blog/how-pgbouncer-works

the author of this post (whom you were responding to) made `libgit`, the library that preceded `libgit2`, and contributed to libgit2 a long time ago as well. Here he is in 2010 writing about libgit2: https://github.blog/news-insights/libgit2-a-git-linkable-lib...

Is this new? I thought we had this already

In my testing (iirc) filesystem performance was not good enough to be usable with node/rust dev where lots of small files get stat-ed

update: what's new is the `container machine` subcommand. I went to test it out, but container failed to run at all for me: https://github.com/apple/container/issues/1681

I remember sitting in the senior study lounge reading the previous Bishop book and implementing the perceptron from it, 22 years ago: https://github.com/llimllib/personal_code/blob/945b017b2915c...

(before numarray and numpy merged!)

it's usually a "something is better than nothing" situation.

If you have somebody willing to write custom release messages, that's definitely better; but conventional commits is better than nothing for it.

the surreal docs should not say "surreal is open source", it's source-available under the BSL

cross-checking your profile suggests that https://github.com/tensorzero/durable is the repo you're referring to

You might consider another name for it, that one is wholly ungoogle-able! Looks neat though

Armin Ronacher's `absurd` is an implementation of durable workflows for postgres:

https://lucumr.pocoo.org/2025/11/3/absurd-workflows/

https://github.com/earendil-works/absurd

https://earendil-works.github.io/absurd/

I've not used it, but it's worth comparing to other options

I've written typst, but if I understand correctly (which I'm really not sure I do?) the article is talking about markdown documents with pandoc commands in them that get translated into typst formatting, but I don't know what the _markdown_ looks like

I wish the article showed what the markdown format for working with typst and pandoc looked like, and what an output PDF looked like. I have no idea whether I'm interested or not from this article

3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

bagder merged a fix to curl in response to my report: https://github.com/curl/curl/commit/b079595f2e903b820a027a68...

Sorry for not believing you initially! I'm very surprised that was in there

Interesting! I took a look with the agent and it looks like it was this change that went in at curl 8.8.0: https://github.com/curl/curl/commit/3eac21d86bc50ba459a9a8a0... (same one susam saw)

There's a flag that would preserve it, but no way to set it from the CLI afaict

edit: I started a discussion here: https://github.com/curl/curl/discussions/21544

> curl, for example, seems to illegitimately strip a trailing question mark (could be only for the command line, didn’t test library usage).

umm what? I don't know what they're actually sending where they think this, but if you think curl is broken you should re-think that maybe you're the one doing something wrong.

Here are some examples showing curl not stripping question marks (obviously), I am very curious what this person was actually seeing

    $ curl -s 'https://httpbingo.org/get?' | jq .url
    "https://httpbingo.org/get?"
    $ curl -s 'https://httpbingo.org/get?path' | jq .url
    "https://httpbingo.org/get?path"
    $ curl -s 'https://httpbingo.org/get?path,query=bananas' | jq .url
    "https://httpbingo.org/get?path,query=bananas"
    $ curl -s 'https://httpbingo.org/get????' | jq .url               
    "https://httpbingo.org/get????"
    $ curl -sv 'https://httpbingo.org/????' 2>&1 | grep :path
    * [HTTP/2] [1] [:path: /????]

libgit2 is not nearly as thoroughly tested as the git CLI is, and it is not actually hard to imagine that calling the git CLI to create new repos is faster than shelling out to a C library.

Your comment does not seem to be in good faith, implying that they've made up the performance difference. There's a comment with a benchmark here: https://github.com/oven-sh/bun/blob/4760d78b325b62ee62d6e47b...

referencing the commit where they removed the ability to link with libgit2 because it was slower.

Having built a service on top of libgit2, I can say that there are plenty of tricky aspects to using the library and I'm not at all surprised that bun found that they had to shell out to the CLI - most people who start building on libgit2 end up doing so.

I don't know what the bun team actually did or have details - but it seems completely plausible to me that they found the CLI faster for creating repositories.