inode 是没变（如果不跨文件系统）。ctime 是文件系统驱动在 rename 调用里自己改的。

overlayfs 。

一边 if err!=nil 一边玩这种魔法吗？风格上完全两个极端啊...

最初号称强项是 sdn，现在应该没什么优势了。

GIL 锁住了什么？
字节码解释循环。多个线程在任意时刻，只有一个线程能运行字节码，除非字节码调用的 C 扩展显式释放了 GIL 。

GIL 的作用：
防止多线程的字节码恰好访问同一 Python 对象造成 crash 。GIL 使得多线程的纯 Python 程序不可能（因为 race condition ）在 VM 的 C 代码里 crash 。
如果 C 扩展要显式释放 GIL，那么该扩展就需要自行保证线程安全。

如果直接去掉 GIL 会怎样：
多线程 Python 程序的 bug 会 crash 在 VM 的 C 代码里。

@RedrumSherlock 就像楼上说的，你两个微服务用了相同的日志库，难道它们就耦合了？显然不是。只要微服务 A 不依赖于微服务 B 用了和自己一样的日志库，那用哪个日志库就是实现细节。同样的，你的微服务依赖于别的微服务内部用了同一个公共模块么？不依赖，那就没有耦合。

@James369 它讲的东西这十多年没什么变化。未来十多年可能也没什么变化。
倒是楼上 effective c++这种，变化很快，务必看最新版。

微服务是一种架构和部署方式，不是一种源代码组织方式。谁规定一个 source tree 只能 build 出一个微服务的？
服务间不要依赖对方的实现细节，和服务间不要共用代码，也是两回事。

@zhoudaiyu systemd 有(dbus) api 。systemctl 就是通过它操作 systemd 的。
但是，显然 supervisord 简单得多。

很多选择。比如 supervisord 。
你想直接在容器里跑 systemd 也可以啊。podman 默认支持。docker 需要设置一下。

绝大部分时间都在 firefox, vscode, 终端和文件管理器这四个应用里打转，不太能理解各平台在“颜值和稳定”上有什么差别。前俩应用各平台长得都一样，后俩像 konsole/dolphin 明显强于其它平台的...

@BeautifulSoap 其实你很不想 rebuild 镜像的话也没关系。以 vscode 的 python container 为例，它的 dockerfile 里有一句 pip3 install -r requirements.txt 。你如果往 requirements.txt 里增加了新的依赖，也可以不 rebuild，直接进到容器里运行一下 pip3 install -r requirements.txt 就好了嘛。

@BeautifulSoap 开发过程中直接在容器里装，提交代码前再去改 Dockerfile 。vscode remote container 也是这样开发。如果你的项目本来就打算 docker 部署，那就应该这样。否则，就直接运行。

其实远程是 linux 的话，你一直都可以用 Xwindow (ssh -X)。本质上都是远程绘制。
不过 X 协议延迟稍高就很卡，一方面所有输入都要发到远程去处理，一方面协议本身没对高延迟优化。这方面 vscode remote 基于 web 优势就很大。
不知道这个 projector 更接近哪一方，也就是说，有多少交互逻辑在本地处理。

@cathedrel 全部流量那你 vpn 呀。

大部分个人开发者的开源，只是我写了代码给自己用，传 github 上给自己作备份的同时，举手之劳也可能帮到别人。
打个比方，好比经过商场弹簧门时给后面的人带一下门。
楼主呢，看很多人这样做，就专门跑商场去帮人开门，当免费门童。
应不应该放弃？大部分情况下应该放弃。

@cshwen 重启，别插usb线。