[heroiccocoa]

It's a bad approach, it can still see the / directory, and eventually you want to give it sudo privilege or act as the root user to get anything done. Yet I really wouldn't trust these things as far as I could throw them, there is no "undo" button in the terminal.

I was like you with docker at the start of the week, I had managed to avoid it until now, but I didn't want to let agents do crazy sneaky stuff to my main system. VirtualBox, even with the guest additions just sucks as an environment to spend more than a few hours developing in, especially with how they take up precious RAM and VRAM that local LLMs need. Let me tell you: Docker for this use case at least turned out to be way easier than I thought! It only took me a few hours to really understand the main workflow for a basic project, docker is actually very nice to use, I should not have left it this long. With just a few commands I feel like I got enough sandboxing for my liking. For example, from my bash history yesterday:

    docker run -it --rm archlinux

this gives you an interactive archlinux container, and destroys itself when you exit with ctrl+d. If you want to re-enter where you left off, you can attach or start the container again if you omit the --rm flag.

    docker build -t flask_test .

this builds a container tagged "flask_test" using Dockerfile in the current directory. Dockerfiles are quite simple

    FROM python:3-alpine

    WORKDIR /my_app

    RUN pip install flask
    # copy app.py from the working directory to the container directory "."
    COPY app.py . 

    # Make port 5000 available to the world outside this container
    # this networking stuff is a bit of a mess to configure, you have to set it in flask, the Dockerfile, when you run the container, and you still get different URLs that the server is on, not all work on the host or the container, etc., it's a bit of a mess IMO. This turned out to not be necessary. 
    #EXPOSE 5000

    # Define environment variable for Flask
    ENV FLASK_APP=app.py

    ENV FLASK_RUN_HOST=0.0.0.0

    # run the command "flask" when the container starts with the "run" argument
    CMD ["flask", "run"]

The docs are very extensive, and feature a lot of (for me, anyway) useless commands like

    "docker ps"
    "docker images"

these are not that useful compared to this:

    docker container ls --all

which just shows everything.

Then, to restart from where you exited the next day:

    docker start -ia amazing_jemison 

This resumes the "amazing_jemison" (randomly assigned name) container. You see the name under column in the previous ls --all command. I don't get why they use CONTAINER IDs so much in the docs instead of NAMES, because they don't feature tab autocomplete, requiring wasted effort copying long hexadecimal strings.

I've been using throwaway archlinux docker containers all week, it's like a snappy VM, I just have to figure out how to launch graphics applications, although apparently that's an antipattern. I tried alpine, ubuntu, debian, etc., too, but archlinux is what I'm used to and the perfect balance between size and being feature-complete for me. Alpine boasts about the minimal image size but in reality you end up missing a lot of useful modern premium features that you have to redownload anyway. I never made a Dockerfile for it, it just downloaded the default archlinux image. After you exit out, and it selfdestructs with rm, and then you want to do it all again from scratch, as per the first command

    docker run -it --rm archlinux

and it will use a locally cached version, saving Docker from having to redownload

Overall a very good experience.

[giancarlostoro]

> It's a bad approach, it can still see the / directory, and eventually you want to give it sudo privilege or act as the root user to get anything done. Yet I really wouldn't trust these things as far as I could throw them, there is no "undo" button in the terminal.

Nah, if it needs sudo then I need to be 100% involved. I'm running Claude in dangerous mode without any "protection" just bare metal, but it doesn't ever do sudo. Python solved this need by giving us virtual environments, which is just installing packages locally instead of system wide, so zero need for sudo.

[andai]

It can still nuke your homedir if you're running it as the same user though. In my case, it can only nuke its own.

https://xkcd.com/1200/