mixedbit explains technical decisions behind Drop's architecture
3 Sep 22 11:36 AM · 1d ago · 2 comments · 1 source · development 3 of 5
Creator clarifies why Drop was built as a standalone tool rather than layering on mature runtimes like runc or crun, citing scope limitations in OCI-compatible tools for Drop's specific requirements.
“These issues were certainly technically fixable, but it could be difficult for a new project with no usage to advocate for features in mature and widely adopted tools.”
mixedbitmixedbit (Jan) Drop creatorp2004a Drop early userrefibrillator Developer working on parallel solution
The whole story articlespostscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 2 voices · verbatim
-
Thanks! My initial approach and the first prototype was for Drop to be a Python script that generates config.json file for runc Docker runtime (I also tried crun). I ran into issues that prevented the sandbox from being set up with all the Drop-required properties. These issues were certainly technically fixable, but it could be difficult for a…
-
Thank you for building it! I started using Drop a few weeks ago, and I've been very happy with it so far (thanks again for quickly fixing a few issues I've reported :)!).For me, it nails the convenience vs isolation aspect quite well, and I would like to get to a point where I can use it for all my development by default.The main challenges that I…
All 5 developments of Drop: rootless Linux sandbox for safer third-party code… →
Hacker NewsNewswires