没有银弹！说规划比较好，另一个说法就是“限制非常死”。

如果说敏捷是靠自己冲刺；那么后者就是踢一脚动一下。

而且，到时候你的焦点是：这规划真是💩！！

看了所有的留言，一点都不觉得意外。古往今来，新和旧的冲突一直是这样的。绝大部分的“旧”根本不愿意去了解一丁点“新”。反对 snap 的很多人真的去了解过为什么要有 snap 以及 apt 到底有什么问题吗？他们只是习惯性的抗拒新东西而已，甚至没有意识到他们讨厌的根本不是 snap ，而是 Canonical 的安装和更新政策！

回到 snap vs apt ，对我而言，就一个点我就很乐意接受 snap （但也可能是最为反对者所不喜的吧）：依赖一起打包。

全局依赖在“远古”硬盘和内存空间受限的时候是不得已的选择，Windows 上所谓的 dll 地狱；但是现在硬盘和内存相对充裕，我更关心方不方便，稳不稳定，安不安全。依赖一起打包虽然增大了安装包，运行时还会增加内存，但是不会受到其他安装包的影响，可以很容易实现：

* 沙盒，
* 原子安装和删除，
* 多版本并存。

这种趋势并不是 snap 独有，我同样很乐意使用 AppImage ，只是在 Ubuntu 上，snap 有“官方”支持。

这两个网站的内容要翻译还能理解，连界面都需要翻译，不知道是怎么想的……

因为新的 term 不需要 tmux ，他们准备颠覆它。😂

直接封号有点过了

绝大多数情况下，你这个是伪需求。每一层都有退出条件，退出时需要收尾，所以最内层退出后会自动一层层退出。

如果代码写得有漏洞 / 某些层条件没有配置好不能修改或者不想修改 / 想走特殊的逻辑而不是原来正常的逻辑，那就是异常情况，使用异常处理。

@mmdsun 这个是需要申请的吧？没申请之前好像只能调高。

@lithbitren 如果是“加密出来的串太长，同样不具有可读性”，可以考虑先用标准算法加密，然后用自制算法做规格化。

@mmdsun 默认就是最低的吧

你还是学原生吧

@msg7086 是的，它是运行在命令行终端的 gui 程序。

我已经爱上了手动屏蔽！多少有点打游戏的感觉了。:-D

这个破玩意居然月入 2k ，佩服得五体投地！！

"我有贵客，敲着瑟弹着笙。"
这明显不对嘛

Brave ，能解决广告问题

这个一般我用脚本来控制容器启动，而不是直接用原始命令

日历最重要的是日程安排，并能准时提醒。

为了保证能提醒，你可能需要常驻后台的服务甚至保活。
除了提醒，日程还需要能多设备同步。
不知道这一块你做得怎么样？

你有点把日历做成了一个信息中心了，比系统自带的走得更远。

你这个是农场，而不是家庭😂