llimllib

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

It really feels like Firefox is not a supported browser on GitHub, I hit this and also find that much of the time the commit message is not correctly pulled from the PR description when that setting is enabled

My alma mater, Ursinus, is a very small school and has few claims to fame; but one of them is that John Mauchly taught there before going to Penn to design ENIAC. Wikipedia puts it bluntly:

Mauchly's teaching career truly began in 1933 at Ursinus College where he was appointed head of the physics department, where he was, in fact, the only staff member.

OKPalette by David Aerne is my favorite tool for this, it chooses points sensibly but then also lets you drag around or change the number of colors you want: https://okpalette.color.pizza/

You’re in luck, he sells it as a book: https://www.amazon.com/Gervais-Principle-Complete-Office-Rib...

For me, it's file system latency on mac os when virtualizing that kills me. Cargo, npm, pip, etc create many small files and there's a high per-file latency on the FS layer

I've built tools with both Go and Rust as LLM experiments, and it is a real advantage for Go that the test/compile cycle is much faster.

I've been successful with each, I think there's positives and negatives to both, just wanted to mention that particular one that stands out as making it relatively more pleasant to work with.

who has a js engine that is both fast and embeds well? nobody

Fabrice Bellard! https://github.com/bellard/mquickjs

(I agree with you, just wanted to note this super neat project)

I created one I like: https://github.com/llimllib/mdriver

it can echo images with kitty image protocol, and streams the output, which I use to show LLM output as it arrives

It doesn't handle paging - you can pipe it to `less` or whatever pager for that

Not OP, but I use ripgrep and customize it with an alias as well, so it applies equally there

Yes I think the device itself is fine, but the Apple TV apps are mostly terrible and often very laggy/poorly written.

The way developers use the UI toolkit that the Apple TV provides also seems to tend towards apps where it's very difficult to figure out what's the active selection, which is of course _the_ critical challenge.

https://go.dev/doc/faq#assertions

I'm not generally opposed to vibe-coded tools, I've even created some.

However I wouldn't be excited to trust one with my AWS key and read/write access to my infra

I have a benchmark program I use, a solution to day 5 of the 2017 advent of code, which is all python and negligible I/O. It still runs 8.8x faster on pypy than on python 3.14:

    $ hyperfine "mise exec python@pypy3.11 -- python e.py" "mise exec python@3.9 -- python e.py" "mise exec python@3.11 -- python e.py" "mise exec python@3.14 -- python e.py"
    Benchmark 1: mise exec python@pypy3.11 -- python e.py
      Time (mean ± σ):     148.1 ms ±   1.8 ms    [User: 132.3 ms, System: 17.5 ms]
      Range (min … max):   146.7 ms … 154.7 ms    19 runs

    Benchmark 2: mise exec python@3.9 -- python e.py
      Time (mean ± σ):      1.933 s ±  0.007 s    [User: 1.913 s, System: 0.023 s]
      Range (min … max):    1.925 s …  1.948 s    10 runs
     
    Benchmark 3: mise exec python@3.11 -- python e.py
      Time (mean ± σ):      1.375 s ±  0.011 s    [User: 1.356 s, System: 0.022 s]
      Range (min … max):    1.366 s …  1.403 s    10 runs
     
    Benchmark 4: mise exec python@3.14 -- python e.py
      Time (mean ± σ):      1.302 s ±  0.003 s    [User: 1.284 s, System: 0.022 s]
      Range (min … max):    1.298 s …  1.307 s    10 runs
     
    Summary
      mise exec python@pypy3.11 -- python e.py ran
        8.79 ± 0.11 times faster than mise exec python@3.14 -- python e.py
        9.28 ± 0.13 times faster than mise exec python@3.11 -- python e.py
       13.05 ± 0.16 times faster than mise exec python@3.9 -- python e.py