@libook Win7 以后的 RDP 都是默认要求“网络级别身份验证”（其实就是 TLS ）的，可以算是默认带有传输安全了。

另外 UDS 除了 STREAM 和 DGRAM 以外，还支持 SEQPACKET, RDM 等等 TCP/IP 通常情况下不支持的 socket 类型。
(只针对类 UNIX 系统，Windows 10 新增的 UDS 支持在这方面还是有限的)

loopback 接口不走网卡，但是仍要走 TCP/IP 协议栈，还是有一定性能损失的。而且 loopback 接口设计的本意是让开发者可以方便地本地测试网络应用，支持 IPC 只是副产品。UDS 就是专门做本地 IPC 的，更简单纯粹。

@julyclyde 因为 UDS 本身就是内核级 IPC 机制，完全不走 TCP/IP 协议栈，内核里缓冲区拷贝一下就完事的东西，本来就应该和 pipe 不相上下的。

如果觉得默认的 48 位数字恢复代码不安全的话，可以配置组策略，改成使用 256 位 U 盘文件恢复密钥。

Bitlocker 在有 TPM 的时候也是会创建数字恢复代码的。TPM 仅仅是一种免人工干预的解锁手段而已。

@Rheinmetal 现在 node 好像是官方钦定 build tools，没装的话安装向导里还会提示你要装

另外，安全方面还有 ptrace, seccomp 等传统方法。

非主流方法：如果评测机用的是 Ubuntu 等自带 AppArmor 的系统的话，倒是可以不用容器，通过 AppArmor 来实现安全加固。

内存和时间限制，一般来说是联用轮询和 rlimit 系统资源限制：
1 ）定时器限制时间+轮询采样内存消耗情况作为主要监控手段，用于反馈 TLE/MLE
2 ） rlimit 系统限制设得比题面描述高一些，用来保底
（不单用 rlimit 是因为超限程序会被直接杀死，从而无法区分 RE, TLE 和 MLE ；而且无法限制程序的非用户态时间）

@systemcall

Keil 礦 ision 纯粹是教材坑爹而已。

本来 ST 官方就有基于 Eclipse 的 STM32 开发环境 TrueStudio 和 SW4STM32 （前者是新出的，后者是早期就有的开源方案；不想用打包好的想用纯开源的也可以自己在 Eclipse 上装插件配环境）。现在 JB 家的 CLion （收费软件，学生可申请免费授权）也支持 STM32 开发。
就算是更廉价的 51 单片机也有 sdcc 之类的开源免费开发工具。

奈何国内有些辣鸡教材非要搞一些蛋疼老版本盗版软件。

再加一个花钱换机的解决方案：把你的 XDR 换成 NETGEAR 或者 LinkSys Velop 的 MESH 路由，它们都原生支持 AP 模式做 Mesh 。（国内品牌 Mesh 路由几乎都不原生支持 AP 模式 Mesh ）

你是用 TP-Link 路由器不插 WAN 口只插 LAN 口关闭 DHCP 强行当 AP 用吗？

TP 家的家用路由最大特点就是万年不出 AP 模式，只有它做主路由才保证 Mesh 功能是正常的。

你这样接确实可能会有环路问题，你的两个 XDR 做了 Mesh，又通过 LAN 口上联，本身 TP 家的路由就是不原生支持 AP 模式的，接 LAN 口关 DHCP 只能说是一种奇技淫巧，它有可能不认为这个 LAN 口是回程线路，强行通过无线 Mesh 回程，就成环了。

几种解决方法：
1. 两个 XDR 不做 Mesh，独立当成两个“AP”用
2. 断开一个 XDR 的网线，强制只用无线 Mesh
3. 其中一个 XDR 断开目前的 LAN 口上联，用 WAN 口上联另一个 XDR，强制 Mesh 回程线路只在两个 XDR 之间建立

如果你要 AP 模式的话不建议 TP-Link 。

TP-Link 路由万年不出 AP 模式，你要做 AP 只能用“关闭 WAN 口自适应+关闭 DHCP+接 LAN 口”这种变通方式，很不方便。

更正一下，“以后的浏览器都要原生支持的”不准确。谷歌的这个认证是同属于 FIDO2 协议的，但更类似于 Windows Hello 这种平台相关的虚拟密钥（和原来就有的蓝牙物理密钥反而关系不大）。这样看来别的浏览器应该没法支持。

这个是 FIDO2 WebAuthn 认证，是新的 Web 标准里东西。相应的物理密钥设备本身就包含 usb, nfc 和蓝牙三种形式，同时还支持非物理密钥比如 Windows Hello，以后的浏览器都要原生支持的。

根本不是什么 js 直接读蓝牙。

@sasalemma 这个和 iptables 没什么关系，ipv6 默认纯路由模式不经过 NAT，是不涉及 iptables 的（当然，如果有防火墙的话还是要用到 iptables ）。涉及到的是 DHCPv6 Server 的工作逻辑，对于 PD 请求是“创建新的 VLAN”，还是和 NA 请求一视同仁直接从 LAN 里挖。这两种在路由表上都是很容易实现的。就看 DHCPv6 软件的开发者的选择了。

@cwbsw 这个是我阅读 odhcpd 的源码和查询相关资料得出的结论。OpenWRT 在处理 PD 请求的时候似乎是从已经配置到 LAN 的前缀上挖出一块向下分发的，而不是从闲置地址里分发。