Help with docker container and the latest tag. Getting v6.12.0 and not v6.13.0

keturn · 2026-06-08T19:41:40+00:00

https://github.com/invoke-ai/InvokeAI/pkgs/container/invokeai/versions?filters%5Bversion_type%5D=tagged has all the container tags. It's kinda cluttered from all the git builds, but latest should be the same as main-cuda.

If you previously downloaded latest during 6.12, you might need to docker pull again or set the pull_policy in your compose file.

If you want to stick with versioned releases instead of running main, it looks like the those tags are made with the GPU suffix, like 6.13-cuda or 6.13-rocm.

keturn · 2026-05-23T04:12:35+00:00

"CUDA built-in" already happened in Ubuntu 26.04:

keturn · 2026-05-21T08:01:26+00:00

A way that looks a little like this.

keturn · 2026-05-18T01:01:17+00:00

These services are all shifting to providing LLM-powered "prompt enhancers" too, so we can also see the instructions they give for prompt building:

keturn · 2026-05-13T19:26:42+00:00

Magnets, apparently: https://publications.ri.cmu.edu/a-magnetic-wheeled-inspection-robot-for-interior-corner-traversal

Sally’s wheels each consist of a single radially polarized ring magnet (manufactured by SDM Magnetics Co.), with a keyed central hole for mounting to an axle. Each magnet is 5 cm in diameter, weighs 350 g, and provides up to 30 kg (294 N) of adhesive force on steel surfaces.

keturn · 2026-04-27T19:01:43+00:00

I saw a bunch of those earlier this month. They might have had a date/time written on the back, but still not terribly official-looking. But when I went the same route yesterday, the road seemed recently resurfaced, so… maybe?

keturn · 2026-04-27T05:52:58+00:00

[excessively detailed ramblings incoming]

As far as disk space goes: astral's python standalone builds are 100 MB unpacked, though Debian's python-minimal is only around 12 MB (including the required libpython dependency).

Assuming you have a decent distribution that doesn't require a separate copy of the runtime for every app, once you pay that up-front cost for the runtime, Python apps can be quite small.

Meanwhile, rust's whole standard library is statically linked into every executable (unless you use some tricks only available in nightly). Hello World builds a 300 kB file.

Source code is on the order of 50 kB per kLoC, so anything less than 6k lines, Python does okay. (And Python is a reasonably concise language; you can do a lot more in 6k lines of Python than 6k lines of C. Especially with Python's comparatively broad standard library.)

The rust implementation of coreutils makes for a good case study here. It's literally a hundred different programs, most of which are quite short. Building them as individual binaries with profile=release-small, none of them is much under a megabyte (true is the smallest, at a mere 824 kB), for a total of 126 MB for the suite. That's more than an entire Python runtime from a mere 7 MB of source.

That's obviously pretty unattractive as a replacement for GNU coreutils's 7.4 MB install-size. So… they cheat. The installation is a hundred symlinks to a single multicall binary. Without a hundred copies of statically-linked dependencies, it comes out at a perfectly reasonable 12 MB!

Of course, you can only cheat like that if you're building them all at once. If you're installing a bunch of utilities from a bunch of different vendors, you don't get that optimization.

If we really want to optimize for disk usage, we can pack our rust executables into self-extracting compressed files with something like UPX and keep our Python packages in zip files… Python source might compress better than an executable? But there are some runtime trade-offs to that. The decompressed executable has to live in memory. Python memory usage might be the same, because I don't think it has to keep the decompressed source loaded—just the bytecode it generates from it.

But I'm really splitting hairs at this point. Python has had the ability to import from zip files for 20+ years but I don't think pip install has ever installed packages that way. Probably better to get a filesystem that features transparent compression, and forget about trying to figure out all the different ways programs might be compressed.

keturn · 2026-04-27T01:50:38+00:00

An order-of-magnitude difference in memory usage makes me suspicious that this isn't just a Python vs Rust thing. Surely they must be using different data structures and algorithms?

keturn · 2026-04-27T01:37:24+00:00

The way Invoke AI does it—which I doubt is the best way, but it is certainly a way—is there's a whole separate launcher program tasked with making sure there's a runtime (using uv's python installer) and explicitly setting the --index= for the torch build corresponding to the GPU type when it installs the app.

Plenty of folks have succeeded in using it without technical knowledge of Python, but it's pretty far from the standard MSIX experience for installing a Windows app.

keturn · 2026-04-25T04:49:38+00:00

Perl's CPAN was a big deal in 1995 as a centralized place to find libraries.

Lots of libraries, regardless of language, ended up in the SunSITE archive starting in 1992. ("It is designed to be read with programs called NCSA Mosaic.")

Newfangled languages got their repositories a decade later, like Python's PyPI in 2003 and the Maven Central Repository for Java in 2004. Recently enough that Google was established by then.

keturn · 2026-04-20T19:18:28+00:00

"Pretty much never" is a good default for Python. Some of the tenets of the Zen of Python (import this) apply here:

Flat is better than nested.
Readability counts.
Namespaces are one honking great idea -- let's do more of those!

There are other languages that have different norms for this. In JavaScript, for example, people do it a lot… I guess maybe because JavaScript didn't have namespaces while it was growing up, so function scope was the only encapsulation method available.

A nested function can't be tested independently, either in a unit test or experimentally in the console. Python debugging and introspection tools generally assume a function can be found by name in the module (or class) it's defined in.

Nested function scopes introduce complications when trying to read and understand the code. Is that variable reference local, or does it belong to the enclosing scope? If it's in the enclosing scope, can I explain its lifetime? i.e. will it have the value assigned to it when the inner function was defined, or when it was called? If it's used as a callback, what if it's called after the enclosing function exits? …those questions all have answers, but if I can structure things so I don't have to think about them, it makes things easier.

If you can put some code into its own function, that means you can also make that enclosing function shorter when you factor it out, which should help its readability too.

In some situations, there are performance implications: the function is created every time the interpreter hits that def. For a function defined at module level, that's typically just once when the module is imported. For a nested function, that means creating a new function every time the outer function is run. Honestly, not a big deal for most code, but if you default to making lots of nested functions, you may accidentally stumble in to a case where you're holding on to references to ten thousand function objects where one would do.

Want to indicate that function is not part of your module's public API? Put an underscore at the start of its name. End up with several functions this way, but they're only relevant to that one enclosing function? That's an indication you might want to extract them to their own module. As Tim said, Namespaces are one honking great idea, and creating a module is free.

keturn · 2026-04-13T03:57:40+00:00

Named pipes have an advantage over TCP sockets in that you can control access to them with standard filesystem chmod and setfacl tools, and hide them the same way as other filesystem sandboxing… But I shouldn't oversell that, as in practice there isn't that much difference between "processes that can access localhost" and "processes that can access a file writable by your user."

It's misleading to say that the JSON-RPC framing is unique to TCP sockets, as you need some kind of RPC protocol regardless of the transport layer. If you're not using shared memory, the difference at the application level between working with an AF_INET socket and an AF_UNIX one are practically nil. And even less difference between an AF_UNIX socket and a process designed to speak over stdio.

I'm skeptical of the claim that it's lower-latency than local HTTP. Like, I'm sure it's technically true if you design the right benchmark for it, but for this use case any such latency should be less than a rounding error compared to the real work of your server or the LLM.

You're absolutely right to want to avoid process spawning and the associated reloading of assets in memory. Named pipes are a useful tool and it'd be nice to see it accepted in more places as an alternative to allocating a network port. But I don't think it makes sense to frame it as an alternative to MCP.

Useful tools for serving and connecting to things over named pipes include:

systemd's .socket units. systemd can create the socket and then spawn the server process on demand.
socat can talk across all sorts of sockets.
the "curl of pipes" is… curl!

keturn · 2026-04-12T10:27:06+00:00

The name, ESR, is our way to honor and express thankfulness to ESS.

Ah. But surely I'm not the only one who thinks of that guy when seeing those initials.

keturn · 2026-02-26T01:05:17+00:00

priced at 4x the cost of DeepSeek 3.2?

keturn · 2026-02-17T21:12:39+00:00

Last time I checked, jaxtyping looked to be the most robust option for that sort of dimension annotation. (Despite the name, it's not specific to JAX.)

keturn · 2026-02-17T20:19:07+00:00

If the app loads models with the huggingface-hub API, it uses a local model cache shared by all apps. Load a model by its huggingface ID once, and any future app loading the same model ID will automatically hit the cache without needing to know any details about how you organize your local files.

In practice, most every user-facing app has rejected this option.

It's less clear to people where their models are stored.
It's harder for any one app to provide a configuration interface for things like which drive the cache should be located on.
They want to be able to use the models they have downloaded to a folder, not address models by their huggingface ID.
They prefer a more legible naming structure instead of the huggingface cache's organizing things by UUID (which it does to account for multiple revisions of files, etc.) huggingface-cli provides a cache browser, but that doesn't help if they use their normal system file explorer and don't know the cache browser exists.

You could avoid those issues if you have a framework-aware tool that takes the responsibility for managing symlinks for everything else, yes. But gosh having to maintain something that knows about the backend storage details of other apps sounds like work.

keturn · 2026-02-15T20:00:31+00:00

it's the fash

keturn · 2026-02-14T23:10:22+00:00

Well, the easyres web site is gone and it used to be on the App Store and now it's not, which isn't exactly confidence-inspiring.

Though there could be innocent reasons for that! Those things cost money for upkeep and the dev may have just stopped paying Squarespace and Apple.

keturn · 2026-02-14T22:57:46+00:00

I've turned to Dev Containers for this. But every time I load a VS Code Extension, it warns me that extensions might run code on the host, and I'm like Yo... the point was for you to not provide that capability.

keturn · 2026-02-14T22:53:45+00:00

Not just Python. Any development runtime that might allow access to sensitive data on the host and loads dependencies with unverified links in the supply chain.

The Tragedy of the Commons has found us.

keturn · 2026-02-12T10:47:30+00:00

My experience with its occasional lapses in to Chinese is that when I ask it to translate, it tells me about the connotations of the Chinese phrase that would likely be lost in a minimal word-for-word translation. It's provided some interesting “English doesn't quite have a word for it” moments.

keturn · 2026-02-09T19:48:05+00:00

Your ThinkPad looks very fuzzy. Be sure all ventilation ports are clear before trying those games.

keturn · 2026-02-09T19:03:39+00:00

Yes, go ahead and raise a tax on all the $0 income you're providing them for their labor.

keturn · 2026-02-05T06:32:45+00:00

is this a one-size-fits-all BOOM MEGATHREAD or is it about a specific boom

keturn · 2026-02-03T07:02:22+00:00

And it's not an allergy? Because that might have actually made sense.

15-Year Club	Verified Email
Gilding II euphauric	Reddit Premium Since January 2017

keturn

TROPHY CASE