就算是单机，要保证 monotonic time 也不是一件容易的事情。

非常糟糕的的做法，Linux 的设计本来就是基于 you know what you're doing 的 assumption ，而不是像某些**一样把用户当巨婴，只给个 y/n 甚至不给提示都合理，何况让你打那么一段，很多服务注销账户等操作也是这样，那造成的后果当然完全是用户的责任。
至于卸载 essential 的用例，最常见的如替换，我要安装 systemd-git ，或者 uselessd 等 drop in replacement ，自动通过冲突包卸载才是正确的行为。
包括其他的内核、bootloader 等，要是 gui 相关也算上，场景就更多了。比如旧笔记本不用了当服务器使卸载掉 GUI 等等。

著名的 Android internals http://newandroidbook.com/TOC.html
其实一般 aosp 官网文档就很丰富了，主要看你想要干什么。

不会 cpp 就别用了，封装 ffi 用你会的语言做。

dism 备份，完事以后在虚拟机里面恢复。需要什么数据打开就能用。

overlay fs

veracrypt ，truecrypt 的 fork 。这玩意是对抗刑侦取证的利器，一般人用 bitlocker/luks 就够了，被发现用了这个本身就很可疑。

@uTools #14
可以考虑沙盒打包发布到微软商店、flathub 、MAS 上，需要哪些权限由用户主动授予，可以打消隐私方面的顾虑。

那就 go 就好了，很多场景 rust 由于复杂度导致实际应用性能还不如 go 。
go 的简单性是掩盖了很多 edge cases 才做到的，你要即像 go 一样的简单设计，又能精细化的控制，那就看看 zig ，库是别想有，包管理都还没做完。
另外 Simplicity is not easiness.

@liuhan907 同步还是异步是由调用方决定的，方法本身只要实现好自己的逻辑，不用关心自己被如何调用啊。
kotlin 的方式更直白，suspend 表明该函数内部存在 suspend point ，要同步调用那就直接调用，要异步调用那就 async 包一层再调用。从另一个角度来说，可以看作是 async 每次被调用时自动添加了 await ，平时 async 紧跟 await 的是最常见的，这样反而减少了很多输入。scope 的存在也让细粒度的控制（包括调度、取消等）变得更加容易。zig 也采用了类似的方式，同时创造性地解决了 colored function 问题（ async 在同步环境中自动变成 noop ）。
像 go 那样干脆把异步调用砍掉，只能写“同步”代码，也不失为一种不错的方式，在其目标领域表现良好。

@liuhan907 插桩（构造 task ）只是插桩，和调度（执行 task ）没有关系的啊。
关于区分，你可以隐式 suspend(await)，但显式 async ，kotlin 就是这样子。go 则是只能写“同步”的代码。

所有时间的处理永远用 UTC ，只在显示的时候根据 locale 格式化成对应的时区和格式。

@liuhan907 async/await 是显式标明 suspend point 的一种方式，相对应的是隐式插入 suspend point 。你要具体控制调度只要 spawn 的时候能提供参数就好了，不依赖显式或者隐式。

我觉得语言设计还是要尽量专注，不应该追求满足所有需求。开一些 unsafe 的后门倒也没啥，有需要可以用，不用时也不会有影响。但整体设计上有开销时同时导致不必要的复杂性，就不算良好的设计了。

@ncepuzs release 里的 source tarball 是根据 tag 自动生成的吧，和仓库内容一样。

go 类型系统残废，写 parser 太费劲。
并且你这需求真的有必要弄个 dsl 出来？写个前端让非技术人员点几下生成 json schema 就行了。

@liuhan907 当然，我只是说既然接受了 GC 更容易接受其他具有一定 overhead 但降低复杂度的方式。
orleans 是分布式的东西么，那就理解了，分布式有什么需求我都不奇怪。erlang/elixir 就是 green thread 和 actor model ，需不需要自定义调度器我不清楚，不过显然与 async/await 没啥关系。

@leoskey await 会把函数挂起控制流还给 runtime ，当然不会阻塞。我说的是调用同步操作，如 Thread.sleep 。