libook

招聘和求职是双向选择，你可以选择不提供银行流水信息，这种单位估计也是欺负员工欺负惯了，不去也罢。

我尝试理解一下，目前楼主是有 2 个需求：
1. 可以使用某种同步机制在多台设备间同步一些文件。
2. 不希望敏感文件直接原样进入同步机制的数据流，以防止意外造成的数据泄露。

需求 1 楼主已经解决了，在解决需求 2 的时候，楼主想到可以不把这些敏感配置文件直接放在文件系统里，文件系统里没有文件，那么同步的时候就自然不会把这些文件传到同步数据流中。

把敏感文件放到 Bitwarden 里，像同步安全笔记和密码一样在各个设备间同步。

但软件还是要读取文件的，那么就可以在文件系统上加个 hook，当任何程序尝试读取特定路径的时候，hook 拦截到请求，然后问用户是否授权，用户不授权的话就返回给软件一个 permission denied，如果用户授权了就在 Bitwarden 里读这个文件的数据，然后直接以 buffer 或者 stream 的形式从内存里提供给这个软件读取，对于软件来说就好像是真的读到了这个文件一样

@ErenJaeger #8 其他楼都提到了，抓包其实本质上就是中间人攻击，就是你在 A 、C 通信的时候中间加了个 B，就变成了 A 到 B，然后 B 到 C，B 就是这个抓包工具，A 到 B 是使用 B 的证书来通信的，B 到 C 是使用 C 的证书来通信的，大多数 A 都不会管通信时是用谁的证书，只要有证书就行，所以大多情况你可以直接在设备上装抓包软件的证书就可以直接抓包，但是你目前遇到的情况可能是 A 只认 C 的证书，你让 A 用 B 的证书被 A 拒绝了，所以抓不到数据。

要想解决问题只能让 A 接受 B 的证书，这个涉及到破解 A 的程序，修改算法让其接受 B 的证书，这个属于逆向工程的领域，技术门槛比较高。

可以设计成可恢复（或回滚重做）的事务，即便不主动杀 pod 也可能会存在程序崩溃的问题，这时候新运行的程序能够继续做完之前没做完的任务就行了。

只要你最终是用官方的证书来发起 HTTPS 请求的，理论上服务端是无法知道你有没有做抓包的。

那么就只能是客户端不认自签证书，这个只要你破解了客户端，服务端应该是一点办法都没有。

TLS 只能解决 TLS 通信过程中的中间人问题，不能解决 TLS 通信之前的中间人问题。

那种可以用文字简单直接说明白的信息，如果是以视频的形式提供我基本不会看，特别是通勤的时候，听旁白还要找耳机。

视频作为一种媒体形式是可以承载文字难以承载的内容的，比如动画演示和实验实拍，这种得自己能看懂视频的 AI 才能转换成文字描述。

所以现阶段能实现的就是把音频进行语音识别，不过考虑到我关注的视频号都是能充分发挥视频媒体特性的，估计这种功能对我来说没啥用。

首先，多数通用快充协议的设计目标之一就是通用性，通俗点说就是一个充电头可以给多种设备用。

主流快充都是有协商协议的，可以根据设备与充电头的额定设计参数来商定使用什么功率充电，比如最高支持 45WPD 的设备和最高支持 100WPD 的充电头，最终会协商使用 45W 的功率来进行充电，此时充电头的功率也是 45W，反过来也一样，所以 MBP 虽然原装充电器是 85W 的，但是你用 45W 的手机 PD 快充头也是可以给 MBP 充电的，只不过速度慢而已。

发热和用料以及工艺有关，我用 MBP 原装充电器在高负载计算的情况下也会很烫，毕竟导体（和半导体）除非超导态，都是有电阻的，有电阻就会发热，只不过有些材料和工艺和显著降低发热。

我是用的 J4105 自建的 NAS，硬件上和群辉的 x86 系列基本一致，只不过性能比群辉好一些。

没记错的话用了大概两三年吧，装的 OMV，既做 NAS 又跑 Docker，感受是这个配置跑一些镜像撑不住，比如 GitLab 和 Photoprism，以及自己做的而一些基于 Puppeteer 的爬虫，后来是在不行，我就把淘汰下来的 4790k 扔到弱电柜里，专门用来跑容器，NAS 上只跑那些对文件系统实时性要求比较高的，4790k 那台上用 vieux/sshfs 这个插件可以挂载 SSHFS 作为 Volume，目前用了几个月没啥问题。

看需求吧，加载时间、消耗流量、精细度，可以迭代着来。

有的 CDN 支持动态压缩和裁剪，上传原画质量文件，只需要在请求资源的时候带上相应的 querystring 或者 header 就可以。