计算机是有寿命的，把重要数据都放到云端，然后在电脑使用期内最大化发挥它的价值就可以了。

不离谱，我的开机一、两个星期已经上百 TB 读写 IO 了。

还有就是请假，请假理由发挥想象力。

传导压力给上层：“在 deadline 之内可能完不成，预计延期 x 天，原因是：（发挥想象力）。”
输出文字，说话，闲聊，通过这种方式分散注意力。

请搜索 Linux From Scratch project.

@sbilly #11 只要 netns 的隔离就够了，docker 还要自己做 image, docker 还虚拟了其它类型的 ns （等于是 docker 起了新的 netns + 其它各种各样 ns ），用 docker 配置量几乎不变，但是资源 overhead 增加了。

地址在这： https://k8slens.dev/

可以在集群上安装一个 metrics-server, 再安装一个 Lens.app 客户端。

其实还有另外一种观点，与这种 "内容为王” 的观点相左的观点，是说：博客的价值是依附于个人 IP 的价值而存在的，即用户访问这个博客是因为博主他个人而非博主写了什么，所以在这种观点下，打造和提升个人 IP ，加强个人品牌存在感，也是一种策略吧我觉得。

我可能有点偏题。我觉得今后博客，尤其是那种普普通通的技术博客，不会像以前那样有吸引力了，因为难的东西/有趣的发现不是谁任何时候都能写/写得出；而那种显然的东西，比如搜索引擎能直接搜到或者 llm 能轻易答对的，也不再有写出来的必要了。由此推出普通博客的内容吸引力降低。

在结合一点假设就是：用户是为内容吸引而来的，所以导致普通博客更难做。得需要一些足够闪光的点才能吸引人。

我不是针对特定的人具体哪个博客，我觉得今后普通博客都如此。

往好的方向想，相当于云厂商带头把“用户”往 IPv6 上赶。

至于说封装请求的代码怎么找，那就顺着事件/组件生命周期去找呗，比如说一个加入购物车/点赞/关注的操作，比如说一个组件加载过程中的各种钩子函数，一层一层“转到定义”，“查找引用”这样找下去，总会涉及到和后端交互、拉取数据的吧？你组件初始化过程中不得涉及到拉取数据？用户对另一个用户点击了“关注”按钮，app 它不得构造一个相应的 request 至少包含那个被点赞用户的 uid 发给后端？顺着事件的逻辑去看代码，这一切都是自然而然的吧。

不是，我吐槽一句。虽然我对 iOS 也不太懂。

但是，从常识来说，怎么封装请求，一般不都是 library, framework 负责的事吗？一般就是你传一个 URL, 一个方法一个 Payload, 构造一个 Request 对象，然后再在一个 context/client 里边去 do （执行）这个 request, 请求就发出了啊？不同语言、框架实现不同，但是大同小异吧？

至于怎么加密？这一般来说也不是你应用层负责的事吧？按理说一般都是 TLS （传输层安全机制）自动加密的，现在还有应用开发者自己造一套轮子对传输数据实现加解密的？就安全性能来说不是一般都不提倡自己造轮子么？

Windows, 因为网吧都用 Windows, 去网吧的人基本都是打游戏的，很少见网吧客户机用 Mac 或者 Linux 的。

没有做环境复现和抓包，下列是我的猜测，仅供参考：

假设有下列环境：

- 外网主机 ext: 203.0.113.101
- 光猫 gateway：WAN IP: 198.51.100.101 ，LAN IP: 192.168.1.1
- 你的内网手机 phone：LAN IP: 192.168.1.101
- 你的内网 srv: Web Server: LAN IP: 192.168.1.102

光猫配置的 DNAT: 198.51.100.101:28080 -> 192.168.1.102:80

从外网主机 ext 连接内网 srv:

1. ext 发出封包给有公网 IP 的光猫 gateway：

IP[SRC=203.0.113.101(ext), DST=198.51.100.101(gateway)] TCP[SPORT=53103(random), DPORT=28080]

2. gateway 收到封包，做 DNAT 修改目的 IP 地址和目的端口，然后发给 srv：

IP[SRC=203.0.113.101(ext), DST=192.168.1.102(srv)] TCP[SPORT=53103, DPORT=80]

3. srv 收到封包，然后回复：

IP[SRC=192.168.1.102(srv), DST=203.0.113.101(ext)] TCP[SPORT=80, DPORT=53103]

4. srv 发出的 reply packet 首先到达 gateway ，gateway 默认对 LAN-to-WAN 流量做 SNAT ，因为这个封包的地址匹配一条之前配置的端口转发规则，所以 SPORT 也会改回去：

IP[SRC=198.51.100.101(gateway), DST=203.0.113.101(ext)] TCP[SPORT=28080, DPORT=53103]

5. 外网主机 ext 收到 reply packet, 在它看来这就好像是 gateway 的 28080 端口直接发给它的，根本感觉不到内网 srv 的存在。

从内网主机 phone 通过公网 IP 198.51.100.101 和映射端口 28080 连接内网 srv:

1. phone 发出封包给 gateway:

IP[SRC=192.168.1.101(phone), DST=198.51.100.101(gateway)] TCP[SPORT=48131(random), DPORT=28080]

2. gateway 收到封包，修改目的地址，然后发给 srv:

IP[SRC=192.168.1.101(phone), DST=192.168.1.102(srv)] TCP[SPORT=48131, DPORT=80]

3. srv 收到封包，然后回复：

IP[SRC=192.168.1.102(srv), DST=192.168.1.101(phone)] TCP[SPORT=80, DPORT=48131]

4. 根据 srv 的路由规则，这个封包不需交给 gateway 转发，可以直接通过以太网发给 phone, srv 对 phone 的 IP 地址做 ARP 解析，然后构造以太帧交给网卡.

5. phone 收到这个封包，TCP session 由一个四元组 （ SRC_IP, DST_IP, SRC_PORT, DST_PORT ）确定，由于 sender 和最初的 DST 198.51.100.101 (gateway) 不一致，所以 phone 的 os 不认为这是之前那个 TCP session 的 reply ，所以丢弃封包。

解决方法其一，配置光猫（网关设备）的 hairpin NAT ，什么是 hairpin NAT: https://help.mikrotik.com/docs/display/ROS/NAT#NAT-HairpinNAT

hairpin NAT 正确配置之后，在以上的第二步 (gateway to srv) 的过程中，封包的 SRC IP 也会被修改，那么 srv 的 reply 封包的 DST IP 就会变成 gateway 的，而不是最初的 real sender, 再由 gateway 发给 real sender.

在家的时候用你本地电脑 mtr 那个公网 IP 试试看看输出，另外不知道是否方便提供一下网络拓扑（包括群晖接的是光猫 LAN 口还是路由器的 LAN 口，光猫是否工作在桥接模式，各个机器的 IP 地址等）。

线下聊，用方言沟通，会比较安全。

你的这种状态，事出有因，主要是因为每次（假设你有正当理由）请假的时候领导总是为难你，再加上从字里行间中看起来你自己性格稍微有点软弱。

我的看法，该请的请，尤其是重要的事，尤其是家人需要你陪伴过节的时候。你努力工作，不就是为了自己能过得开心一些吗？切勿舍近求远，忘记本心。我们公司的保洁每天都需要来清理垃圾，她请假都完全没问题，任何人都可以在自己需要的时候请假，如果公司少了你就不转了，那不是你的问题。