其实只有一个问题需要关心：

你可以从老板那收到订金再开工，但我是你团队里的人，你怎么保证我能收到你发给我的两万薪水？

我遇到了跟这个问题完全一致的现象：

https://askubuntu.com/questions/799669/etc-sudoers-file-corrupted-and-i-cant-run-pkexec-visudo-over-ssh

在单会话 SSH 中 auth 失败。
但 systemctl 这样的提权命令又是能成功通过验证的


sudo pkexec 正常

@Livid 作为一个 98 年家里就有电脑的沿海大城市小孩子，连我都直到上初中玩到同学的 ipod 才对 apple 这家公司产生印象，PC 产品始终是当传说来听的，完全没机会见。

我对 mac os 早期产品的唯一印象是 photosho 5.0 ，那时候有些教材会提到 mac 版的操作，上面有 mac 的界面图……

看来 mac os 也进入 "retro GAMES" 的范畴了

但那个年代国内用 apple 的绝无仅有吧，怕是很难形成爱好者群体

@loveumozart 申请期有多个 round ，first round 10 月左右开放所以建议 9 月份就开始准备

@woyao

HK 学校大多数都是自主招生，不是所有学校都同时截止的。而且还有些差一点的学校，或者非本科院校，截止时间都更晚一些。（基本上越差的学校截止越晚，跟内地规律一致）

@loveumozart
咨询、代理申请、研究生择校，相关需求都可以加我微信来了解哈

@TomVista

context 中从来就没提过内地成本，而且单位始终是 HK$，你是怎么把「 HK 的普通学校」理解成「内地普通大学」的。

这个成本是面向内地学生的成本，本地人的成本就跟你内地生上本地学校差不多，学费会便宜不少。HK 本地一两万的学费可能内地择校就七八万。

然后房租（住校忽略）、生活费，基本要对齐北京上海（工作后的水平），这应该就不难估算了。

我不太懂 ios

但我知道在 swift 之前 ios 用 object-c 来开发……这是一门极 tricky 的语言，除了相当 native 外还在语法上就增加了大量给编译器而不是给人看的要素

所以我对 ios app 的印象一直是与 qt 类似，是一堆 C runtime 的程序。

所以你说什么内存地址线程什么的，那不就是 C runtime 的必备信息，必要时还得看得懂汇编，空指针空的是哪个内存，对应什么变量，访问违规发生在哪个指针上，是因为引用无效还是 use after free……


swift 也是直接编译到 LLVM IR 的，所以我猜现代 ios app 应该也仍然没有托管环境，而是直接运行的 native machine code

我 6 岁的时候就已经很牛逼了——也算个小神童了

但说实话我真没信心再过 18 年后重新学会那些「高等数学」……

@maxssy
@zed1018
@alexsz
@wangerka

可以参考我在 wsl2 里挂 pt 的玩法历程：
https://zybuluo.com/pnck/note/2512441



systemd 和 固定 IP 都是很好解决的问题，相比之下，我用 wsl2 遇到的最大问题是：
https://github.com/microsoft/WSL/issues/4177#issuecomment-1500147196


在一台你需要打游戏、又开着自动更新的台式机上，你需要隔三岔五运行一下刷新 LSP 黑名单的脚本

OP 跳过了一个时代： https://www.proxifier.com/

曾经是搭配 shadowsocks 的推荐方案。



后来……它联网验证了。

我觉得一般，作为反讽，有些思路又过于建设性了，比如那几种「 const 类型」，虽然关键字看起来蠢，但值类型的划分可真挺严谨的，在其它语言里都难得一见。

不如考虑 hk2+2 留港，反正广东

看了半天在吵什么……

> 普通的 token 无任何有效信息, 只是一个唯一值, JWT 的话可以通过 秘钥 从 token 里解析出 uid 之类的, 这样子有些场景只有 uid 就不用查数据库
原来还就是车轱辘话翻来覆去讲，说到底 OP 发现的「优势」也就是 jwt 带信息，随机 token 不带信息而已，这不就是废话……


> 至于常见的 JWT 诟病解决方案
OP 的这段发散了这么多，加上他楼下的回复，其实就一句话： 退化成普通 session / token 方案


> 为什么要用 JWT ?
> - 使用 token 会有千万级用户请求 * (存 token + 查 token redis)... 用户名,xxx 存储,
文不达意。 根本原因其实就是 jwt 携带的信息可以短路一部分查库判断而已




我来替 OP 总结一下他的看法：
1. 在最坏场景下，jwt 退化成普通 session/token 方案，此时主要缺陷是 jwt 数据量引入的内存浪费，但即使在极大并发量条件下 redis 的性能也完全够用，所以可以忽略不计
2. 在典型场景下，jwt 自带 session/token 方案需要查库才能获得的关联信息，如用户 id 等，在这些场合下能节省大量数据库连接资源


所以这不就是什么「初识」、「入门」文章里就提到的东西么……