最新

Drop 是一款专注于高效本地工作流程的 Linux 沙箱工具。它在尽可能保留工作环境的各个方面的同时，隔离程序和代理。 该工作流程的灵感来自 Python 的 virtualenv：创建一个环境，进入其中，正常工作——但同时强制实施沙箱。要创建一个新的 Drop 环境并运行一个沙箱化的 shell，您只需： ``` alice@zax:~/project$ drop init Drop 环境已创建，配置文件位于 /home/alice/.config/drop/home-alice-project.toml alice@zax:~/project$ drop run (drop) alice@zax:~/project$ cat ~/.ssh/id_rsa cat: /home/alice/.ssh/id_rsa: 没有那个文件或目录 ``` 每个 Drop 环境都有自己独立且易于处理的主目录。为了确保沙箱与您的实际工作环境相匹配，原主目录中选定的文件和目录会被挂载到沙箱中，其中大多数是只读的。 我对像 Drop 这样的工具的需求已经存在很长时间了。我对安装和运行那些具有庞大依赖树且没有隔离的非发行版程序感到不安。另一方面，我又对裸露的 root@b0fecb:~# Docker shell 感到畏惧。Docker 在部署软件时的主要优点——可重现的、最小的环境——却妨碍了高效的开发工作：容器中缺少工具；配置文件和环境变量都不可用。 促使我开始构建 Drop 的最后一根稻草是 LLM 代理。为了良好工作——编译代码、运行测试、分析 git 日志——代理需要访问安装在机器上的工具。但给予代理无限制的访问权限显然是有风险的，因此几乎每次关于代理工作流程的讨论中都会提到缺乏沙箱化的抱怨。 谢谢，我很想听听您的想法。

最近，关于开发者去世的帖子在HN上频繁出现，这让我不得不思考不仅是我自己的生命有限性，还有我的数字基础设施以及其他我可能唯一拥有或知道的数字资产/内容（例如，密钥、密码等）的有限性。 似乎如果我们能够设计一种“活着证明”，使其可以进行加密验证，以便于继承过程，那将会非常有用。基本上，这样可以让你的受托人在RUFADAA下执行事务，确实会很方便。 但随后我意识到，这种证明也可以应用于其他情况，比如在你的在线帖子、互动和参与中放置某种“肉的印记”，这也会非常有用——只要它不能被轻易操控（至少不是“轻松”操控）。 “活着证明”当然是一个非常困难（甚至不可能？）的问题……或者说不是吗？我很想知道HN认为可能有哪些可行的解决方案来解决这个显然需要一个好解决方案的问题。