你看一下 /usr/sbin/ip 是不是链接到 /usr/bin/ip 的软链接。软链接上没法设置 capabilities ，得在实际的文件上设置。

其实这个就是常见的一种对 iptables 的误解：很多人认为 iptables 里的 NAT 规则（ SNAT 和 MASQUERADE ；这里先不讨论 DNAT ）是负责“转发”的。

实际上不是这样的，SNAT 和 MASQUERADE 规则，功能就仅仅是做 NAT ，也就是对从指定出口转发出去的数据包修改源 IP ，并且建立临时映射对返程数据包做对应的处理使其能被正确收到，仅此而已。
至于这个数据包会不会从“指定出口”出去，这个不归 iptables 管，归路由表管。

想实现这个需求需要用到“策略路由”，流程上大概是在 iptables 的 mangle 表里给数据包用 MARK 操作打上标签，然后再在 ip route 这边新建一个路由表 table 并且设定相应的路由，和主路由表区分开来（比如说你现在主路由表是默认走 tun0 ，就新建一张默认走 eth0 的路由表），最后再用 ip rule 里面提供的 fwmark 规则指定打了特定标签的数据包走新建的路由表。

首先很显然 (argv-1)[argc] 和 argv[argc-1]访问的是同一个东西。然后根据 C 语言数组下标操作的定义，(argv-1)[argc]和 argc[argv-1]又是等价的。

客户端设备是 Windows 吗？如果是的话，NAT 类型和 Windows 防火墙也有关系，防火墙没有放行传入连接测出来就是 PortRestrictedCone

@asanelder 这种应该属于某些题目的进阶要求吧，题目里也只是说如果你用的编程语言里字符串是可变数据类型的话可以尝试 inplace 做法，不用也能通过。想达成这个目标的话用 Java, Python 这些语言是没办法的，只能换成 C++.

@FenixVu dpkg 不是非要在同一个系统里用的。只要 recovery 启动盘里有 dpkg 程序，用参数指定一下 database location 就能读取硬盘上面的系统的软件包状态了

@mkmoon gnome 作为英文单词 g 不发音，但是 GNOME 作为软件名称，按照开发者的官方说法，G 是发音的，用来和原英文单词区分。相似的情况还有 GNU.

@areyouF TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t 可不是什么恶意合约，这就是 USDT 代币的合约。这种代币都内置了授权别人动用自己的币的功能（ DEX 去中心化交易必须依靠这种功能才能运作）。

这个合约没问题。但是 OP 的交易有问题。OP 这种很明显是被骗了授权。

@usb 典型小白被割韭菜的案例。玩币之前一定要搞清楚原理，不然分分钟完蛋。

这种 ERC20 合约虚拟币（其它的什么 BEP20 TRC20 等等都是同一个原理）都有一个叫授权（ Approve ）的功能，可以通过自己发起一笔特殊的交易来允许别人自由转走自己的一定数量（可以设置一个非常大的数相当于无限量）的币。你要是什么都不懂，别人发给你一个交易二维码，你扫了一下发现不用花钱就直接同意了，结果这个交易是授权，然后你的币就没了。

对应 45 楼里这个交易，你的授权操作是 5 天前的这笔： https://tronscan.org/#/transaction/08e3f4b3f0bf195f548bf905de42a4a835146b49423a5a0d2d4d0c570a02283b
你想想当时是不是扫了什么码或者点了什么链接，然后进行了一笔不要钱的交易。这笔交易本身不要钱，但是后续他就可以随便转走你的币。

另外除了普通的明晃晃骗授权的（因为现在钱包软件一般也有提示，稍微有点警惕也不好骗），还有一种骗签名。比如说有些币圈网站是用钱包登录，中间要通过“签名”来验证你的身份，因为不是交易，很多人可能就直接同意了。如果签名内容是文本一般都没有问题，但有时候签名内容是二进制数据，你根本一眼看不出是啥，结果实际上这段二进制数据就是一笔交易数据，你签名就相当于发出这笔交易了（区块链基本原理），然后币被转走。不了解技术的小白面对这种骗局防不胜防。

所以玩币之前一定要学习一些区块链技术。除非你只是纯在交易所炒币（当然这个坑也很多）。只要涉及钱包操作的，最基础的区块链交易、私钥、助记词、代币发行的原理一定要搞懂，进阶一点的最好学会阅读一些简单的智能合约代码。一点技术都不懂极易被骗。
另外币圈投机也是风险非常大的，看过新闻的都知道，什么土狗归零、杠杆爆仓，亏光家产跳楼的比比皆是（这种在币圈还属于相对上比较正规的玩法）。哪有像你这种按要求操作就可以稳赚的兼职？
你这根本就不是玩币，属于纯纯的电信诈骗。这种所谓“兼职”一般都是先用你的账号洗钱（这个阶段你会有一点“收益”），最后你没有利用价值了以后就是收网一波带走，骗走你剩下的所有财产。如果单纯是电诈受害者还好说，但你这都参与跑分洗钱了，可以说自己也有责任。

@vone PuTTY 自带的 agent 也是临时存储，但它用的是 pageant 协议，如果要和 git 一起用的话需要通过一些工具转接。

这里也需要考虑你的 SSH 客户端是什么版本，Win10 自带的 SSH 客户端无法使用 pageant agent ； git 自带的 SSH 客户端可以通过 git 内置的 ssh-pageant 工具来转接。另外就是安装 git for windows 的时候有一个选项是可以选择使用 PuTTY Plink 作为 ssh 客户端，这样就可以原生支持 pageant agent 了。

总而言之就是想要避开 Win32-OpenSSH 的 ssh-agent 永久保存私钥的坑点，最好还是卸掉系统自带的 SSH Client ，换用其它的 Windows 平台可用的 SSH 实现。

@vone 你说的这个问题只存在于 Win10 自带的 SSH 客户端。以前 Windows 不内置 SSH 客户端的时候，都是使用 git for windows 内置的 ssh （基于 msys2 ），它的用法和 Linux 里的差不多，不存在永久性保存私钥的问题。

在系统可选功能里卸掉 Windows 自带的 OpenSSH Client ，然后重新安装一遍 git for windows ，以后 VSCode 就会自动使用 git for windows 提供的 ssh 和 ssh-agent 了。（不过这个 ssh-agent 启动有些麻烦，并且使用的时候需要手动设置环境变量或者 ssh 的 IdentityAgent 选项）

@dingwen07 也不必抓包，桌面端的 WinAuth 就有完整的代替 Steam 手机令牌的功能（可以直接在电脑上假装手机绑定 Steam 令牌，现在还支持交易确认），然后通过它导出 secret ，添加到手机端的第三方生成器里就可以了。

@nothingistrue 微软 Authenticator 不完全是标准 TOTP 工具，还提供了微软一键认证（无密码登录）的功能，TOTP 只是顺带附带的。谷歌身份验证器现在也不太推荐使用了，主要是备份比较麻烦，而且谷歌自己现在也不主推这个 2FA 软件（谷歌账号现在需要先绑定其它 2FA 才能加绑 TOTP 为可选 2FA 登录选项）。

手机端标准 TOTP 2FA 更推荐一些开源软件，例如 Android 平台的 AndOTP 或者 Aegis Authenticator ，这些都标配导出加密备份的功能。

@vbxnxn 三星的 knox 熔断和 BL 解锁还是不太一样的。早期三星手机（ S3 、S4 那会儿）是有 knox 但没有 BL 的，后续才加上了 BL 。

单纯解锁 BL ，以及用 odin 通刷各地区官方 rom 都不会熔断。早期安卓有漏洞的时候通过漏洞 root （各种一键 root ）也有一定概率不会熔断。

只有刷入第三方 recovery 、改版内核（比如说 magisk root 就要 patch boot ，相当于刷内核）、第三方或改版 rom ，才会熔断。

@SupperMary 国内正常的 VISA 信用卡不存在有额度的时候无法消费美元的，不存在"自动扣人民币为美元"的问题，无论是美元记账还是人民币记账，只有还款的时候有区别（直接还人民币 or 必须在手机银行里操作购汇）。

你说的这种要购汇的只有两种情况，一种是 VISA 借记卡（根本不是信用卡），另外一种是信用额度为 0 元的 VISA 信用卡。正常有额度信用卡不存在消费时要手动购汇的情况。

@A3
@pppguest3962
OP 写的是“六万高端口转发 3389”，outside 不是 3389

这个需求在 TypeScript 里其实不好做。因为 ts 里有一种 literal type 的东西。比如你的例子里的 c 函数，如果不手动指定返回类型的话，你以为编译器推断出的类型是 string|number ，结果其实是"hello"|123 ，也是一种比 string|number 更窄的类型，那它该不该报错呢？ 按照你的需求应该是不报错，但是按照 ts 的类型系统"hello"|123 和 number 都是 extends string|number ，并不好区分。

@raykle OP 需求应该是想对 union type 返回值做反向的 exhaustiveness check.

正向的 exhaustiveness check 主要是针对这种值的读取的，比如说有些语言的 switch-case 或模式匹配如果缺了几个 case 又没有显式写 default case 的话编译器就会产生 warning 甚至 error 这样。一般不针对赋值、返回值等写入操作。

而 OP 希望对函数返回值的写入也可以进行这种 check 。就比如说你有一个类型
type X = string | number
然后定义一个函数
getStringOrNumber(): X
这时如果函数体内只有 return string 的语句而没有 return number 的语句， [也就是说这个 X 类型里有几种情况没有用到，可以改成 getStringOrNumber(): string 也不出错] ，OP 希望遇到这种情况编译器可以提供 warning 或者 error 。