I am pretty confident that I know how the agent containerization works. In general there's really not a lot of complexity there at all.

If one wants, one can just (ask Claude to) add whatever functionality, or (and that's what I did) just use Claude skills (without adapting NanoClaw any further) and be done with.

What is annoying is that their policy is instead of integrating extra functionality upstream, they prefer you to keep it for yourself. That means I have to either not update from upstream or I am the king of the (useless so far--just rearranging the deck chairs) merge conflicts every single time. So one of the main reasons for contributing to upstream is gone and you keep having to re-integrate stuff into your fork.

Of course. Also with regular customer projects. Even without AI--but of course having an idiot be able to execute commands on your PC makes the risk higher.

> If so, why doesn’t Anthropic / AI code gen providers offer this type of service?

Why? Separate the concerns. Isolation is a concern depending on my own risk appetite. I do not want stuff to decide on my behalf what's inside the container and what's outside. That said, they do have devcontainer support (like the article says).

>Hard to believe Anthropic is not secure in some sense — like what if Claude Code is already inside some container-like thing?

It's a node program. It does ask you about every command it's gonna execute before it does it, though.

>Is it actually true that Claude cannot bust out of the container?

There are (sporadic) container escape exploits--but it's much harder than not having a container.

You can also use a qemu vm. Good luck escaping that.

Or an extra user account--I'm thinking of doing that next.

Bootstrapping everything is exactly how it's done correctly--and how it's actually done in practice in Guix.

I mean sure if you have a business to run you outsource this part to someone else--but you seem to think it's not done at all.

Supply chain attacks have been happening pretty much non-stop the past years. Think it's a good idea to use binary artifacts you don't know how they were made (and thus what's in them)? Especially for build tools, compilers and interpreters.

>And why is that location more valid of a decision than the one that doesn't require building the build system from source?

Because you only have to review a 250 Byte binary (implementing an assembler) manually. Everything else is indeed built from source, including make, all the way up to Pypy, Go, Java and .NET (and indeed Chromium).

What is inside the lambda is to the right of the ":". That is indeed evaluated only when you call it.

>But it is good that people are aware that it is an error in design, so new programming languages don't fall into the same error.

Python didn't "fall" into that "error". That was a deliberate design decision and in my opinion it is correct. Scheme is the same way, too.

Note that you only have a "problem" if you mutate the list (instead of functional programming) which would be weird to do in 2025.

>For an equivalent error that did get fixed, many Lisps used to have dynamic scoping for variables instead of lexical scoping. It was people critizing that decision that lead to pretty much all modern programming languages to use lexical scoping, including python.

Both are pretty useful (and both are still there, especially in Python and Lisp!). I see what you mean, though: lexical scoping is a better default for local variables.

But having weird lazy-sometimes evaluation would NOT be a better default.

If you had it, when exactly would it force the lazy evaluation?

    def g():
        print('HA')
        return 7

    def f(x=lazy: [g()]):
        pass

    def f(x=lazy: [g()]):
        print(x)

    def f(x=lazy: [g()]):
        if False:
            print(x)

    def f(x=lazy: [g()]):
        if random() > 42: # If random() returns a value from 0 to 1
            print(x)

    def f(x=lazy: [g()]):
        if random() > 42:
            print(x)
        else:
            print(x)
            print(x)

    def f(x=lazy: [g()]):
        x = 3
        if random() > 42:
            print(x)

Think about the implications of what you are suggesting.

Thankfully, we do have "lazy" and it's called "lambda" and it does what you would expect:

If you absolutely need it (you don't :P) you can do it explicitly:

    def f(x=None, x_defaulter=lambda: []):
        x = x if x is not None else x_defaulter()

    def f(x=None):
        x = x if x is not None else []

Guido van Rossum would (correctly) veto anything that hid control flow from the user like having a function call sometimes evaluate the defaulter and sometimes not.

The idea in Python is:

1. Statements are executed line by line in order (statement by statement).

2. One of the statements is "def", which executes a definition.

3. Whatever arguments you have are strictly evaluated. For example f(g(h([]))), it evaluates [] (yielding a new empty list), then evaluates h([]) (always, no matter whether g uses it), then evaluates g(...), then evaluates f(...).

So if you have

def foo(x = []): ...

that immediately defines

foo = (lambda x = []: ...)

For that, it has to immediately evaluate [] (like it always does anywhere!). So how is this not exactly what it should do?

Some people complain about the following:

    class A:
        x = 3
        y = x + 2

For example:

    a = A()
    assert a.__class__.x == 3
    assert a.x == 3
    a.__class__.x = 10
    b = A()
    assert b.x == 10

But it just evaluates each line in the class definition statement by statement when defining the class. Simple!

Complicating the Python evaluation model (that's in effect what you are implying) is not worth doing. And in any case, changing the evaluation model of the world's most used programming language (and in production in all countries of the world) in 2025 or any later date is a no go right there.

If you want a complicated (more featureful) evaluation model, just use C++ or Ruby. Sometimes they are the right choice.

    guix build --with-configure-flag="jq=CFLAGS=-O3" jq

    (define llama-tune
      (options->transformation `((tune . "znver3")))) ; Zen 3

    (home-environment
     (packages (list (llama-tune (specification->package "llama")))))

    (define jq-patch
      (options->transformation `((with-configure-flag . "jq=CFLAGS=-O3"))))

    (jq-patch (specification->package "jq"))

You can also write a 10 line guile script to automatically do it for all dependencies (I sometimes do--for example for emacs). That would cause a massive rebuild, though.

>The most pain-free option I can think of is the --tune flag (which is similar to applying -march=native), but

> packages have to be defined as tunable for it to work (and not many are).

We did it that way on purpose--from prior experience, otherwise, you would get a combinatorial explosion of different package combinations.

If it does help for some package X, please email us a 2 line patch adding (tunable? . #t) to that one package.

If you do use --tune, it will tune everything that is tuneable in the dependency graph. But at least all dependents (not dependencies) will be just grafted--not be rebuilt.

But: If you are LUCKY! The worse case is if you DON'T segfault by dereferencing invalid pointer.

So, the layout of Mutex is the same as T and then some lock (well, obviously).

>Rust introduces an extra layer of pointer indirection with Mutex, which can hurt performance significantly with cache misses.

Why would there be an extra pointer dereference? There isn't.

I don't like vscode extensions advertising to me every 5 seconds, auto-downgrading the free versions of extensions, auto-installing aux tools every 5 seconds, having a 400 MB RSS chromium runtime (remember Eight Megabytes And Constantly Swapping? VS code is much worse; and it's also just a plain text editor); nerfing the .net debugger and breaking hot reload on purpose in VSCodium; telemetry, .... it's so noisy all the time. You are using this? On purpose?!

VS code is basically the same idea as emacs, just the MVP variant and with a lot of questionable technology choices (Javascript? Electron? Then emulate terminal cells anyway and manually copy cell contents? uhhh. What is this? Retrofuturism?) and done with the usual Microsoft Embrace-Extend-Extinguish tactics (nerfing pylance, funny license terms on some extensions that the extensions are only allowed to be used in their vscode etc).

So if you didn't like emacs you probably wouldn't like vscode either.

Also, if you use anything BUT emacs for Lisp development, what do you use that doesn't have a jarring break between the Lisp image and you? vim seems weird for that use case :)

emacs is very very good for Lisp development.

On the other hand, VSCode for Lisp is very flaky and VSCode regularily breaks your Lisp projects. Did you try it?

Because of your comment I tried VSCode again and now about 20 extensions (one of them "Alive", a Lisp extension for vscode) complain about now missing

  "Dev container: Docker from Docker Compose"

>>./logs/20250112T181356/window1/exthost/ms-vscode-remote.remote-containers/remoteContainers-2025-01-12T17-13-58.234Z.log: >>>> Executing external compose provider "/home/dannym/.guix-home/profile/bin/podman-compose". Please see podman-compose(1) for how to disable this message. <<<< >a239310d8b933dc85cc7671d2c90a75580fc57a309905298170eac4e7618d0c1 >Error: statfs /var/run/docker.sock: no such file or directory >Error: no container with name or ID "serverdevcontainer_app_1" found: no such container

... because it's using podman (I didn't configure that--vscode did that on its own, incompletely. Also, it thinks that means having a docker/podman service running as root has to be a thing then (instead of rootless podman). Funny thing is I use podman extensively. I don't wanna know how bad it would be if I HADN'T set podman up already).

So it didn't actually fix anything, but it removed the error message. I see. And there's no REPL for the editor--so I can't actually find out details, let alone fix anything.

I had thought emacs DX was bad--but I've revised my opinion now: compared to vscode DX, emacs DX is great. You live with VSCode if you want to.

And note, vscode was made after emacs was made. There's no excuse for this.

I think this now was about all the time that I want to waste on this thing, again.

How is this a problem in 2025? shakes head

>VS Code managed to by-pass the qualitiy and amount of extensions/plugins in a fraction of time Emacs took decades.

Yeah? Seems to me these vscode extensions are written in crayon. Bad quality like that would never make it into emacs mainline. And it's not even strictly about that! I wonder who would write a developer tool that the developer can't easily debug its own extensions in (yes, I know about Ctrl-Shift-P). That flies about as well as a lead balloon.

For comparison, there's emacs bufferenv that does dev containerization like this and it works just fine. Configuration: 1 line--the names of the containerfiles one wants it to pick up. Also, if I wanted to debug what it did (which is rare) I could just evaluate any expression whatsoever in emacs. ("Alt-ESC : «expression»" anywhere)

PS. manually running "podman-compose up" in an example project as a regular user works just fine--starts up the project and everything needed. So what are they overcomplicating here? Pipes too hard?

PPS. I've read some blog article to make socket activation work for rootless podman[1] but it's not really talking about vscode. Instead, it talks how one would set up "linger" so that the container stays there when I'm logged out. So that's not for dev containers (why would I possibly want that there? I'm not ensuring Heisenbugs myself :P).

[1] https://github.com/containers/podman/blob/main/docs/tutorial...

  $ cat a.pp
  {$R+}
  var
    a: 1..12;
    b: 1..12;
    c: 1..12;
  begin
    a := 10;
    b := 11;
    c := a + b;
    Writeln(c)
  end.
  $ fpc a.pp
  Free Pascal Compiler version 3.2.2 [2021/05/19] for x86_64
  Copyright (c) 1993-2021 by Florian Klaempfl and others
  Target OS: Linux for x86-64
  Compiling a.pp
  Linking a
  12 lines compiled, 0.1 sec
  $ ./a
  Runtime error 201 at $00000000004010D8
    $00000000004010D8
    $0000000000422EEC

I'd say with the (few 100 million) Chromebooks it's an equal number of Windows devices to the sum of the other ones you listed.

P.S. What happened to Android in your list? That is like leaving out the 500 pound gorilla :)

It's true is that you have to trust your dependencies (unsafe or not). Not needing to trust at all that developers know what they are doing was never a thing a programming language could provide. We can only carve out some specific properties that we can machine-check in a limited way.

There are limits on what a type system can do (Rice's theorem, Gödel's incompleteness theorem), and in addition there are limits on what a non-dependent type system can do.

Therefore, you either need unsafe (something that adds operations that the type system doesn't model) or you can't write some perfectly OK programs.

Basically, the Rust type system is a toy model of your computer's abilities and the domain you want to model. And so is any other type system. The type systems of systems languages at least have some inkling of the actual machine--which is not necessarily the case in non-systems languages.

Ask a computer engineer what he thinks about this toy model's misconceptions, like that reading and writing from the same location via the memory bus affect the same thing, or reading the same memory location twice in a row when there's only one cpu is guaranteed to give you the same value, or that reading a memory location can't change it, or that writing to some memory location can't automatically change some other aliased memory location, or that writing some memory location from cpu 1 means cpu 2 can immediately read that new value out etcetc. I could go on (memory barriers, cache coherency, paging, ...).

This is not specific to Rust.

I'm not sure why we are having new "unsafe" discussions lately. Java and .NET have unsafe as well. Didn't we have that discussion already in ca. year 2000 and everyone arranged themselves with it? What changed? Are there new arguments?

If you want to have some empirical tests if the unsafe blocks are broken, run your program under miri.

Now you could say that you could just make better and better type systems that encompass everything as it really is. To that I say (1) you can't do that in principle and (2) if you could, humans wouldn't be able to practically use it anymore and (3) It would be too much effort for something that only a tiny minority of programs need in some places. The toy model is pretty good 95% of the time!

I've set it (emacs 29.4) up like that (LSP mode (including rust), DAP mode, 160 emacs packages, daemon mode) and it works very fast for me. It can do project tree, intellisense, refactoring, macro-expansion and auto-implementation that way.

Opening a new document takes about 75ms for me.

Modern emacs has native compilation via gccjit.

package specification: https://github.com/daym/guix-config/

emacs config: https://github.com/daym/emacs-config/

    x = tf.constant(([1, 2, 3, 4]))
    tf.math.multiply(x, x)
    

So let's look at tensorflow some more:

The tensorflow tensors should transform like vectors would under change of coordinate system.

In order to see that, let's do a change of coordinate system. To summarize the stuff below: If L1 and W12 are indeed tensors, it should be true that A L1 W12 A^-1 = L1 W12.

Try it (in tensorflow) and see whether the new tensor obeys the tensor laws after the transformation. Interpret the changes to the nodes as covariant and the changes to the weights as contravariant:

    import tensorflow as tf
    # Initial outputs of one layer of nodes in your neural network
    L1 = tf.constant([2.5, 4, 1.2], dtype=tf.float32)
    # Our evil transformation matrix (coordinate system change)
    A = tf.constant([[2, 0, 0], [0, 1, 0], [0, 0, 0.2]], dtype=tf.float32)
    # Weights (no particular values; "random")
    W12 = tf.constant(
        [[-1, 0.4, 1.5],
         [0.8, 0.5, 0.75],
         [0.2, -0.3, 1]], dtype=tf.float32
    )
    # Covariant tensor nature; varying with the nodes
    L1_covariant = tf.matmul(A, tf.reshape(L1, [3, 1]))
    A_inverse = tf.linalg.inv(A)
    # Contravariant tensor nature; varying against the nodes
    W12_contravariant = tf.matmul(W12, A_inverse)
    # Now derive the inputs for the next layer using the transformed node outputs and weights
    L2 = tf.matmul(W12_contravariant, L1_covariant)
    # Compare to the direct way
    L2s = tf.matmul(W12, tf.reshape(L1, [3, 1]))
    #assert L2 == L2s

In comparison, a matrix is rank 2 (and not all matrices represent tensors). That's it. No rank 3, rank 4, rank 1 (!!). So what does a matrix help you, really?

If you mean that the operations in tensorflow (and numpy before it) aren't beautiful or natural, I agree. It still works, though. If you want to stick to ascii and have no indices on names, you can't do much better (otherwise, use Cadabra[1]--which is great). For example, it was really difficult to write the stuff above without using indices and it's really not beautiful this way :(

More detail on https://medium.com/@quantumsteinke/whats-the-difference-betw...

See also http://singhal.info/ieee2001.pdf for a primer on information science, including its references, for vector spaces with an inner product that are usually used in ML. The latter are definitely geometry.

[1] https://cadabra.science/ (also in mogan or texmacs) - Einstein field equations also work there and are beautiful