teh

The readme says: "Small and dependency-light. Pure Rust, built on lopdf, pdf_oxide, rten, and friends.", and paperpilot-pdf/Cargo.toml confirms that.

FWIW I am using gnome 49 and 3 finger swipe works out of the box on my asahi macbook linux.

benbye - do you have any intuition why the model only needs 4 frames to work? I played with LeWorldModel and I am mystified why the latent prediction frame number is so small. It's an almost Markov like property where a short history is packaged as state.

I sometimes wonder how much of intelligence is being good with tools.

I feel pretty averagely smart but give me some good tooling like a good editor, a good type system, semantic grep, good testing and some solvers and I can actually deliver some work.

Maybe the trick isn't 500 billion parameters but a model super integrated with the task at hand for iteration and debugging?

FWIW the article really mirrors my own experience. I can run a small gemma4 for quick edits (and it's fast!) or data cleanup but for other tasks you do need a different tool (claude).

Another useful "Emergency exit" is CTRL+Z which stops the process and cannot be intercepted.

It's often faster than hitting CTRL+C and waiting for process cleanup, especially when many resources are used. Then you can do e.g. `kill -9 $(jobs -p)` to kill the stopped tasks.

Super useful tool but need to be aware that this is reading potentially untrusted input (e.g. in the case of http request logs) and written in c++, so a possible attack vector. I use lnav where I trust the logs, but do wish a safe implementation existed.

There is precedent: with type checkers like pyright you can opt into specific checks, or have a basic, standard, strict setting, each expanding the set of checks done.

How would dependencies work in this schism? E.g. if serde starts using named impls, do all dependencies have to use named impls?

I can't fully answer your question but I did once spend about a week porting plain internal configuration to cue, jsonnet, dhall and a few related tools (a few thousand lines).

I was initially most excited by cue but the novelty friction turned out to be too high. After presenting the various approaches the team agreed as well.

In the end we used jsonnet which turned out to be a safe choice. It's not been a source of bugs and no one complained so far that it's difficult to understand its behaviour.

I feel you (like many people) got burned by the steep learning curve. Empirically some pretty high powered companies use nix successfully. It's of course always difficult to know the counterfactual (would they have been fine with ubuntu) but the power to get SBOMs, patch a dependencies deep in the dependency stack, roll back entire server installs etc. really helps these people scale.

nixpkgs is also the largest and most up to date package set (followed by arch) so there's clearly something in the technology that allows a loosely organised group of people to scale to that level.

I feel the same way. Excited to see another attempt. But it's a c++ engine so not something I would want to expose to the internet really.

I've looked into this but saw hugely variable throughput, sometimes as little as 20 MB / second. Even if full throughput I think s3 single key performance maxes out at ~130 MB / second. How did you get these huge s3 blobs into lambda in a reasonable amount of time?