三星 G7 ，狗东价 4000 。32 寸 4K165Hz miniled

我这边和你类似，只是基本都打成了 docker ，方便部署和迁移。debian 软路由是好文明。

@laminux29 这个逻辑不一定对，无论是从提高效率避免资源浪费还是软件工程的 zero cost 角度，降低空载功耗都是有意义的。它是一种更完美的形态，不是钱的问题。

用 jwt 不是挺好嘛，格式标准，自带可被校验的元信息。对于只依赖这部分信息的中间件可以省去捞缓存/数据库的开销和瓶颈。不想用户可读，payload 还是可以存放某种 id ，后端再去自己捞。需要即时过期，可以对 payload 做额外后段验证，或者签发时效较短的 jwt 。尽信书不如无书，原理很简单，看情况用即可。

建议先想清楚目标是啥，读研多大概率能达成这个目标，以及不读研有多大概率能达成。——来自贵旦读研半路跑路的

1. 搭建 v**(三层的那种)并做策略路由，或者分应用路由，远程开转发和 Masquerade
2. iptables/nftables DNAT(可选，可连接更多类型的 peer)，在 bt 软件中配置一段端口，对这段端口做 DNAT 就行

顺便问个问题，解 BL 对安全性有多大影响？

机器故障不得安检员处理？让他们给你捞出来。

有个疑问：收入数额会影响量刑吗？

要是我，宁可牺牲性能换稳定性，virtio 一下也还好。以前用树莓派的时候我写坏过几张 tf 卡，搞数据恢复很难受。

我也思考过类似的问题。
在程序员视角里，你觉得某个软件做了太多你用不着的功能，并为此付出了大量性能开销，虽然你用不上，但不得不付出代价；此时你可以按照自己的需求开发一个新的，和你类似需求的人就多了一种选择。
社会模式的选择和这个是类似的问题。可能一个人愿意为效率牺牲自由，也有人愿意过物质条件相对差但管制更松散的生活。两种方向都没有错，非要凑一起才是问题。
然而我们在此问题上的选择权并不多。一是从 A 软件切换到 B 软件存在非常大的困难，另外是创建一个新的 C 软件几乎是不可能的事情——因为没有无主之地了。联邦制我觉得是一个很好的 workaround ，既可以基于较小的一部分人中的大多数人的共同意志决定这一部分人的生活方式；又有一个大的框架避免搞的太离谱，并允许其中的人们更容易地迁移。更偏集体的制度往往会强制把另外那群人拉下水，但这个行为本身是自洽的——它会更大程度地牺牲少数人来成全大多数(或者大多数的代表)，这也是为什么我认为保障基本权利是一件重要的事，因为这可以避免在你成为需要被牺牲的少数人的时候太惨。
ps: 在看一本书《独裁者手册》还不错，推荐一下，虽然与本问题关系不是很大。

@ke1e > 他们的 rsproxy.cn 还是很好用的
谢谢！公网 mirror 这个主要是我负责，当前其实还有一些问题，比如 git index 不稳定和执行 x.py 的时候 hash 校验问题，有时间会继续提升用户体验，也欢迎你遇到问题时在群里反馈。

@datou552211 > 署名都没给，太惨了，你叫（ 13 位） 吗
你就说有啥办法吧，it's not the first time

office 使用体验更好，而且你在 IT Service 小程序申请一下就有了，不用自己购买。

本地有后门的话，怎么搞都没用，毕竟截屏万能。非要做的话，可以清理掉后门再操作。
基于流量的分析不太能看出来，流量本身是加密的并且上行并不很大。

我来澄清几个事情，以下发言仅代表个人：
1. 关于小册的事，对于是抄袭还是忘记著名我无权发表意见；但除了当事人的部分以外，可能写的烂，但至少我们都没原样抄袭。这是读书人的底线，也是公司三令五申过的。
2. 关于对吴迪个人的评价大家可能有些偏颇，技术能力我不做评价，但“横向运作能力”确实很强（这个也是当事人的招聘帖里提出的要求，这是正面评价）。代码层面贡献不多但项目参与感可以拉满，这也是前面评论里称其为 kitex 之父的原因。
3. 我负责的项目在开发时便会与所有人讲明白，对于有开源计划的项目（比如上面评论里提到的几个项目，最初就有开源计划），开源部分与内部部分拆分，开源部分在开源时保留所有 commit 记录。
对于实在是 commit 太乱拆不出的，也会在多处明确注明（包括但不限于 commit 的 co-author 、LICENSE 文件和 README 文件以及代码文件头），并由主要贡献者提交。字节的开源项目很多也是这么做的。
公司政策并不是挡箭牌，这个做法分享给大家可以借鉴（如果想的话）。

最后，我觉得无论是对内还是对外，保质都是要优先于保量的，要讲武德守规矩，这样大家和社区才能一起良性发展。特别是挂公司 title 卖钱的东西，得对得起公司背书、别人的知识版权、认真共事的其他同学们和收的钱。

利益相关：我是当事人现同组平级同事，也是小册作者之一。

我的经验是，不要急于求成，首先要好奇，搞清楚原理；其次是努力让它又用，写一个你觉得有意义的东西。

debian 旁路+nftables