HackerTrans
トップ新着トレンドコメント過去質問紹介求人

harshdoesdev

no profile record

投稿

SETI Home, but for AI

github.com
2 ポイント·投稿者 harshdoesdev·3 か月前·1 コメント

[untitled]

1 ポイント·投稿者 harshdoesdev·3 か月前·0 コメント

Show HN: Run AI coding agents in real, local sandboxes, not Git worktrees

superhq.ai
6 ポイント·投稿者 harshdoesdev·3 か月前·3 コメント

Show HN: Local-First Linux MicroVMs for macOS

shuru.run
213 ポイント·投稿者 harshdoesdev·5 か月前·66 コメント

Show HN: Neko – AI agent runtime that fits on a Raspberry Pi Zero 2W

github.com
2 ポイント·投稿者 harshdoesdev·5 か月前·0 コメント

コメント

harshdoesdev
·3 か月前·議論
Hi guys, we are super excited about the launch of remote.superhq.ai - remote control for your dev environment. please do check it out and share your feedback.
harshdoesdev
·3 か月前·議論
i too wanted to purchase 5-6 3D printers and start a business - basically my version of goose farming after i leave the software dev space for the greater good of mankind :)
harshdoesdev
·3 か月前·議論
bhatti's cli looks very ergonomic! great job!

also, yes, shuru was (still) a wrapper over the Virtualization.framework, but it now supports Linux too (wrapper over KVM lol)
harshdoesdev
·3 か月前·議論
Someone built a project called AgentFM that tries to use a peer-to-peer network of everyday computers to run AI workloads, similar to what SETI@home used to do for crunching radio telescope data.
harshdoesdev
·3 か月前·議論
nice! for most local workloads, it is actually sufficient. so, do you ship a complete disk snapshot of the machines?
harshdoesdev
·3 か月前·議論
+1. i built something similar called shuru.run because i wanted an easy way to set up microVM sandboxes to run some of my AI apps, and firecracker wasn't available for macOS (and, as you said, it is just too heavy for normal user-level workloads).
harshdoesdev
·3 か月前·議論
its a really innovative idea! very interested in the subsecond coldstart claim, how does it achieve that?
harshdoesdev
·3 か月前·議論
had to wait for two minutes just to refresh the PR page. their UI was always a bit clanky, this new wave of "AI productivity" is just making it worse.
harshdoesdev
·3 か月前·議論
thanks! depends on your machine but it is surprisingly lightweight since it uses Apple's Virtualization.framework under the hood. I have comfortably run 3-4 sandboxes on an 8GB Mac. you can also configure CPUs, memory and disk per sandbox from the settings.
harshdoesdev
·5 か月前·議論
glad you liked it! I am currently exploring options for Linux support. will share an update soon.
harshdoesdev
·5 か月前·議論
lume is a much more full featured VM manager, macOS and Linux VMs, API server, prebuilt images, python SDK etc. shuru is intentionally minimal.
harshdoesdev
·5 か月前·議論
apple container is more of a docker-style workflow, OCI images, registries, etc. shuru is just micro VMs with checkpointing, much simpler scope.
harshdoesdev
·5 か月前·議論
cool, would love to see it!
harshdoesdev
·5 か月前·議論
glad to hear it, that's exactly the thinking behind it. alpine is the only option right now yeah. what kind of dependencies are you running into issues with? would help me figure out what to prioritize next.
harshdoesdev
·5 か月前·議論
thanks! let me know how it goes
harshdoesdev
·5 か月前·議論
haven't thought about multi-agent communication yet. each sandbox is fully isolated which is the point. checkpoints help a bit here though, you can branch multiple agents from the same checkpoint so they all start from the same state.
harshdoesdev
·5 か月前·議論
OrbStack is great but it is solving a different problem. it's a full Docker Desktop replacement. shuru is just a thin layer over Virtualization.framework for spinning up throwaway sandboxes.
harshdoesdev
·5 か月前·議論
containers work fine for a lot of this. shuru is just what felt more natural to me. less config overhead and i wanted to learn by building it.
harshdoesdev
·5 か月前·議論
yeah, it just means everything runs on your machine. there are services like E2B, sprites.dev and others that give you sandboxes in the cloud. shuru runs VMs locally using Apple's Virtualization.framework, so nothing leaves your Mac.
harshdoesdev
·5 か月前·議論
Lima can do a lot of what shuru does if you set it up for it. the difference is mostly in defaults and how much you have to configure upfront. with shuru you get ephemeral VMs, no networking, and a clean rootfs on every run without touching a config file. shuru run and you're in. Checkpoints and branching are built into the CLI rather than being an experimental feature you have to figure out. Lima is a much bigger and more mature project though. Shuru is something I am building partly to learn and partly because I wanted something with saner defaults for this specific use case.