@mianlaodie 多巴胺嘛，激情付费哈哈

@mianlaodie 只能说因为他们思考的出人家个人 up 靠 C 端累死累活不如找 B 端赚得快。至于团队 up 就 toB 或者 toC （消费品）都很灵活了。
只能说虽然现在脑力劳动显得地位高，但整个市场还没有为知识付费的意愿，他们宁愿为知识凝结付费而不是为知识付费。

反正我理解开源的本质目的（或者说出发点）应该是：我自己要做个好东西，但觉得自己一个人力量不够还不够好，同时觉得需求把握还不够或者钱不够，就作为公共项目让大家提需求、共建。
因此开源应该是为了单纯获取，或者单纯为了这个在做的东西更好。

有些想法：开源是为了更安全（大众代码审查）、为了更吸引人来用，进而为了交易（付出并获取）。我是不认同的。

@thinkm 是的，关注下沉市场

@thinkm
大概是因为抖音低质量短视频能降智（或者本身受众就低智），嘬着奶头乐沉迷在里面。而 B 站相对而言没那么降智，高质量长视频是教人思考的，就不会盲目被割了。

@emma3 雀食，要是身处三番就买的便宜用 esim 了。OP 在北京真是可惜了

《 GB/T 25069-2022 信息安全技术 术语》
3.47 标识 identification


flag 暂时没找到。

@codehz
还没回复你，你为啥要说 114514 层混淆这种先自己杠自己的话呢……
个人从 0 手搓协议，完善性肯定有问题的。你不说我也认可，我相信每个人都认可。

但我只是说的一种可能性不是么？我一上来说的也是“并不绝对”，而不是“绝对安全”吧？
就比如 OpenSSL 也是肉体凡胎的人们写的，也出现过 Heartbleed 这样极为严重的 Bug 。也就是你即使不自己手搓，使用全球广泛使用被认可的现有协议实现，也依然不能绝对规避风险。

另外你提到证书链、代码这些，我是这个行业内的，所以这些很清楚。
即使你走 HTTPS 协议，浏览器也是通过 CSP 、KeyStore 、P11 这类接口调预先配置的证书链（受信根证书颁发机构），很多中间人攻击 HTTPS 协议，也是通过在客户端安装它的 CA 根证书实现的。
这些跟代码混淆不混淆这种前端技术没啥关系，因为 RSA 、SHA 这些 SSL/TLS 协议用到的密码算法套件实现可以完全公开，完全没必要混淆。至于公钥（证书）本身就是公开的，也没必要混淆。
SSL/TLS 协议本身保障能力也就是针对信道，无法保护终端。比如客户端篡改系统受信根证书颁发机构、客户端篡改代码让客户端不执行对服务端验证、客户端窃取已经解开的明文数据、（双向 SSL 情况下）客户端“骗签”这些，都不属于 SSL/TLS 保护范畴。仅仅靠标准浏览器+标准 HTTPS 协议本身（不添加其他 SSL/TLS 协议外的实现）也无法防范。

个人观点：
1 、任何自制密码算法都可以认为未经对其安全性的广泛验证，基本可以认为是不安全的。
（注：这种不安全是理论上的，有些人一说什么不安全就挑衅人去破解，前些天 v2 上有个搞前端加密的就这样）
2 、理论上应该把 ID 设置成低业务价值的。如果认为 ID 存在价值，首先就不该连续，甚至不应该包含时间戳或者顺序信息。这种情况可以考虑生成随机 ID ，或者非随机 ID 做 hash 。加密的话造成的不必要算法复杂度和性能损耗大于必要性。

仅代表个人观点：
1 、遵纪守法，请如实填写；
2 、保险的意义不是很大，没必要购买；

并不绝对。比如，你可以在 http 协议下，通过 body 依照 tls 协议实现一遍。

感觉这个方案有点像达文西的手电筒

社会化大分工，没有任何一个岗位不重要。
但论创业，你要是没全能团队，就需要你全能了。
研-管-销

是不是好主意完全因人而异。个人觉得 PVE 还是蛮稳定的（可能比不上 esxi ）。
如果是经常折腾的人，就开始折腾吧，大不了再折腾回来。
如果是对折腾不抵触的人，建议用另一台类似设备先练练手熟悉一下路径，觉得没问题再迁移。
如果是怕麻烦的人，建议不折腾。

要么是钓鱼，要么 10 后？

三星新出了 T9 ，不知道咋样