笑死，把自己截图的控件也丢里面去了

uefi 的话，引导可能得重写一下）

用 webrtc datachannel 实现信息传输还是挺不错的，不知道在没有信令服务器的前提下能不能直接建立连接就是了

可以试试
flag := unix.SIGHUP
if err := unix.Prctl(unix.PR_SET_PDEATHSIG, uintptr(flag), 0, 0, 0); err != nil {
return
}

@shijingshijing #41 （问题也没用上那些技术啊（见过不少甚至还用 gdi 截屏做的，高级点的才会用桌面复制 api ，但是显然都没显卡直接压缩成流的方案快，甚至这里的差距和网络条件的差距都大的多

用来保持后台运行的？

原则上你可以直接用 /proc/xxx/root/ 来访问镜像内的根（记得不要 follow symlink ），然后到里面找 sys/cgroup/memory 看（

就是 app 写的烂，官方的 splash 从来不会有这个问题（

@haoliang 即使 tmux 它不显示，也需要计算屏幕的显示内容才知道下次连接的时候需要哪些信息才能恢复（（考虑 vim 这样复杂的界面，显然没办法简单的记录输出内容来恢复屏幕

不只是转发，tmux 还要自己缓存屏幕内容（基本上也在做另一个终端模拟器要做的事，只是不直接渲染到屏幕上），还会在输出过快的时候截断（并且丢弃输出内容！这个设置还不能调）如果终端模拟器自己做的话，这部分工作就可以少一份，终端模拟器支持的情况下，单纯为了分页和 split 上 tmux 确实是可以说是浪费（

公钥无论如何都得公开，这里的问题是，私钥也是公开的（直接从公开的教程 /文档里复制）

@FrankHB #56 然后呢，你是要设计一个新语言还是在“现有语言的约束下”寻找比较好的方案呢？
现有 go 的约束，就是没有办法去充分表达错误分支和正常分支的互斥性，而想自动传播异常用 panic+recover 也不是推荐的方案，因此这个情况只能靠开发者自己的规范，那这里的选择，就是用最不容易让其他开发者犯错的方法，使用上述策略，然后在要搞特殊处理的时候再单独写文档说明为什么要这样做。
这帖子是在讨论“已经在用 go”的情况下如何尽可能避免踩坑，而不是来讨论 go 语言设计的哪里不好，也不是来搞语言鄙视链的。（而且 c++异常的喷点也不少，缺少 checked exception （ throws 被移除，noexcept 只能用来标记永远不抛出异常的函数，这个特性好不好另说）或者 effect 机制等类似机制，导致实际上很多时候是开发者忘记处理异常（和标记在文档里），而不是注意到不要 catch ，特别是 call graph 复杂了之后，很难发现某个调用路径下有可能会抛出哪些异常（例如人均忘记的 bad_alloc ，和流处理会遇到的 std::ios_base::failure ），这导致异常本身经常会由于上述疏忽变成实现细节——只有崩了才知道啊原来这个函数会抛出这个异常）

@ryalu 可以容忍不代表你就得惯着（忽略错误然后假装无事发生肯定不是正确的行为）要么你就加个接口不返回 err 的，来明确表达这个目的
万一出现一个真的需要区分的时候，漏判断 err 还没测试出来，生产环境把错误内容写入数据库（或者别的危险操作，如权限判断默认值啥的地方），不就留了漏洞了？

有 err 的情况还这样用？
那只能掩盖漏洞了

@ColinZeb #4 那也不行，这个菜单定制能力很弱，只有单行文字+图标，然后顶级菜单也只能是静态的（子菜单内容可以动态决定）

顶部的就是系统独占的（

最简单的就是直接套 iframe （