我想在 mxlinux 上测试 anbox，看看它是否可以正常运行我使用的一些 Android 应用程序。问题是 anbox 使用 snapd，而这两个只能与 Systemd 一起使用。
我尝试使用 Systemd，但这是一场灾难。如果计算机由于某种原因意外关闭，下次启动时它甚至不会启动计算机。
因此，我想知道如何将 snapd 与 sysvinit 一起使用？
答案1
一点也不。 Snap 基于 systemd 提供的隔离、挂载和容器执行服务。
您需要一个管理 cgroup 的服务、协调共享命名空间的服务、使非特权用户能够挂载存档的服务以及管理这些容器化应用程序运行时的服务。 Systemd 提供了所有这些功能，sysvinit 是一个来自八十年代/九十年代的纯启动系统，并且不提供 snapd 所依赖的现代基于 Linux 的操作系统的这些功能。
您描述的症状不太可能与 systemd 有关，因此我认为在 2023 年采用 sysvinit 等利基 init 系统对于获得一个正常工作的系统来说可能有点适得其反。无论如何，snapd 的人一再公开表示，他们不打算支持非 systemd 系统，而且这并不是不可能的，他们预计所需的解决方法将是大量的，以接近重新实现 systemd 的部分内容。 。
这里只是发泄一下，绝对不是针对你个人。但研究开发人员关于该主题的实际言论让我想起了在互联网上随处可见的一种非常丑陋的模式。所以我不得不“写下这是我的胸部”：
当您阅读类似主题时这，您会注意到 snapd 人员非常友好且富有成效，并且喜欢帮助真正致力于使 snapd 功能子集在没有 systemd 的情况下也能实现的用户。但这似乎是互联网的一条法则，在每一个这样的线程中，那些只是要求某些软件能够在没有软件所依赖的依赖的情况下运行的人，在没有带来实际专业知识的情况下成为最响亮的声音。而开发人员，他们试图帮助人们真正尝试让一些东西发挥作用，而这些东西可能不具备运行集成良好的图形应用程序或隔离良好的服务器所需的完整功能集，但他们却无法跟上。 ，并失去与他们实际合作的能力。
这对非 systemd 人群来说是一种诅咒：如果 systemd 讨厌者对没有贡献的开发人员花费的时间少一点，那么很多有充分理由依赖于 systemd 的东西现在可能有可行的替代后端。一般来说，作为一名 FOSS 维护者，你的精力可能会因为人们试图让你支持他们的“特殊”系统而很快耗尽，从而消耗你本来可以构建一些可以帮助大多数人的东西的时间。
这绝对不是说我认为 MX Linux 和类似的努力不好 - 我认为我们不垄断 systemd 所扮演的角色非常重要。只是那是一个积极的这样做的理由——每当有人提到某些东西依赖于 systemd 时，一股消极情绪就会淹没他的收件箱。十年前，基本上所有主要发行版都认为这是正确的事情！