have you tried running android browsers ? we run RL workloads using android browsers. We are having to maintain a fork of https://github.com/budtmo/docker-android/ and android chrome on top. We would rather use browser-use if it had that support.
P.S. we do maintain our fork of a browser for rubric computation...but that is not relevant for this. The infrastructure is what we are looking for.
I've experimented with Android Browsers. The problem is that android VMs are super heavy compared to the resources needed to run just Chromium
Startups are absurdly slow, isolation is harder, etc...
Android bloat is insane, you need to run the entire Java VM to start the browser... It's also harder to fingerprint, and at scale that's something that we need for Browser Use
Cool experiment but not yet production ready, at least for us
actually this is not the reason - the harness is significantly better.
There is no comparable harness to Claude Code with skills, etc.
Opencode was getting there, but it seems the founders lost interest. Pi could be it, but its very focused on OpenClaw. Even Codex cli doesnt have all of it.
What's the issue with OC? I tried it a bit over 2 months ago, when I was still on Claude API, and it actually liked more that CC (i.e. the right sidebar with the plan and a tendency at asking less "security" questions that CC). Why is it so bad nowadays?
That's why the major Indian generics companies like Cipla have signed IP and branding exclusivity deals with Lilly and Novo so that they can continue to synthesize generic GLPs but Lilly and Novo can now export those to the US - it allows IP holders in the US to further enhancing margins while allowing Indian generics manufacturers to climb up the value chain thanks to transferred IP and knowhow.
At no point, have I invented a new/better method. Perhaps your way is better.
I just recognise that Docker Compose is loved by most open source developers. And invariably any project you touch will have a docker compose setup by default. And it isnt going away, no matter hard anyone tries to kill. Some things are just too well designed. Docker Compose is one of those things.
I'm just making it possible to run those on kubernetes seamlessly.
I'm not arguing for the relative superiority of jsonnet vs yaml vs anything else. I just recognise that Docker Compose is loved by most open source developers. And invariably any project you touch will have a docker compose setup by default.
I'm just making it possible to run those on kubernetes seamlessly.
docker compose is beautiful because it uses a simple elegant compose yml file - this is now an open standard. https://www.compose-spec.io/
the standard does not make it mandatory that underlying system should be docker compose (the reference server). it can be anything.
IMHO - kappal is the first project that takes your compose yml file and transparently/drop-in runs it on kubernetes. there is nothing extra you need. It is useful for people who want to maintain their stack as close to production as possible (kubernetes).
If that's not a big goal for you, then this is not very useful for you. But I'd argue ...why do you care if the compose yml is the only think you are using. you get all of kubernetes.
WSL2 is one of the best linux experience you can have.