logoalt Hacker News

fwlrtoday at 10:24 AM6 repliesview on HN

So this product is a thin wrapper over a remote virtual machine, a new name for remote virtual machines, and an exhortation to not look inside or reason about remote virtual machines?

I feel like up until recently this would been pitched as “the missing UX/DX for cloud compute”, or something. But instead now it’s marketed to this new trend where one should aggressively not understand the tower of abstractions one is standing on. Odd.


Replies

dbmikustoday at 2:56 PM

I haven't paid super close attention to Orbs, but I also build an agent runtime + orchestration layer on top of remote VMs (https://github.com/gofixpoint/amika). I do think it's smart marketing to name the concept. And for coding agents, there's a lot of annoying fiddly stuff you have to do to get the experience to work well:

    1. auto-refresh base VM snapshots with latest delta of git commit changes
    2. extend the VM lifetime when it receives an interaction (chat, HTTP request, etc.) and sleep it when inactive
    3. oauth refresh of MCP servers, coding agent subscriptions, etc.
    4. support inter-VM and communication for agents and exec commands
    5. keeping track of agent work across VMs

That said, I think it's important to not hide the VM and computer from the agents. The user should have total control to put 1 or more agents on a VM, to make VMs ephemeral or permanent, to manage the network access of VMs, etc. It's basically a networking + VM scheduling problem, for which there's a ton of prior art since the 90s (or earlier).

A few examples:

Many remote agents products have a "one agent per VM" restriction, but it's better to have N agents across M VMs. For example, I have agents work on a singular VM in parallel worktrees and then stack the worktrees at the end on that VM for the final change.

Just give me OpenSSH with normal SSH key management. Lets you manage VM access the same way we've done it since the 90s.

Connect VMs in a network topology: we build our VM/agent scheduling + remote control product inside itself, so we often test interactions between user, control plane, and sandbox(es). If you can directly control VM creation and lifecycle, it's easy to spin this structure up and let agents work across it.

I should be able to use whichever coding agents I want, connected to the VM. Whether that's OpenCode or Pi Web in the browser, or loading the VM into Cursor or Codex app, or using the TUI or sending messages to agent(s) via API.

misternuggettoday at 2:34 PM

Hey! Author of the post here. Sounds like I failed my mission with the post then :)

Yes, like many things, Orbs are "wrappers" around VMs, but the point is that some wrappers enable new ways to hold and use and reuse the thing they wrap, and even give you a different perspective on it.

That's what happened with our team once we had Orbs working. We knew beforehand all the things they're made of (fast to start sandboxes, scale to zero, live streaming updates on all clients, one machine per conversation, etc) but what really surprised us was how it changed our workflow by removing friction we didn't even know was there. The friction of creating new checkouts and worktrees and managing local resources -- it sounds trite, of course, but man, once you can stop thinking about it, it's so much better.

So, yes, maybe they're wrappers but hey, some people say the tortilla is what makes it a burrito, you know?

andaitoday at 10:43 AM

This is Apple's entire business model.

Also most proprietary software, also most web-based software, also most APIs... also what my plumber does when I call him over!

(Also most hardware?)

show 1 reply
chanuxtoday at 2:08 PM

I kept reading (I mean scanning) to see if it uses orb stack[1] locally.

[1] https://orbstack.dev/

dist-epochtoday at 1:10 PM

yes, just like Dropbox is just FTP and rsync

davidbalberttoday at 12:49 PM

https://slashdot.org/story/01/10/23/1816257/apple-releases-i...

> No wireless. Less space than a nomad. Lame.

https://news.ycombinator.com/item?id=8863

> I have a few qualms with this app:

> 1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software

Obviously I'm not claiming that this will be anywhere near as successful as the iPod or Dropbox. It might not succeed at all. But I would have thought we'd be past this sort of dismissal by now.