可能和 Ubuntu 自己作死，强制 firefox 等多款软件使用 Snap 沙盒安装有关系。

@coredumpling 旧手机系统升级上来的不强制。比如 OPPO Find X3 ，现在是安卓 12 ，但它是 A-only 的，OTA 都要进 recovery 。

WSL2 和 Docker Desktop for Windows 都支持（ Docker Desktop for Windows 需要设置使用 WSL2 后端）

去掉“地址信息是否通过 DHCP 获取”的勾。这个开了之后会使用有状态 DHCPv6 分配 v6 地址（不建议使用这种模式，不兼容安卓），然后上面的 DHCPv6 服务器又是关闭的，自然就不能分配 IPv6 地址了。

另外下面的“SLAAC 前缀使能”应该要打勾。

256bit 只是方便保存的，实际实现上有一个 clamping 操作把数值限制在合法范围内。

utmp 是登录信息相关的记录（而且也不是所有方式登录都会记录，比如 ssh 非交互式登录就不会记录），和终端没有关系。Linux 里完全可以绕过登录流程创建虚拟终端（ pty ）。

非交互式登录的 session ，utmp 里没有，也不代表完全追踪不到，比如使用 systemd 的发行版里用 loginctl 或者 systemctl status 还是能看到 vscode-remote 的 session 。

应该是 vscode-remote 通过 notty 的方式登录的之后，自己另外启动了一个 non-login 的 shell 。

就像你直接在 Linux 的图形界面里启动多个 GUI 的终端模拟器，w 和 last 里也不会多出东西来一样。

应该是和 go 的调用约定有关，只保存被调用者保存（ callee-saved ）的寄存器，调用者保存（ caller-saved ）的寄存器是由函数本身生成的代码自己负责的。

因为协程不是像线程那样由 OS 强行抢占的，是只有在特定的切换点才能切换，可以把这个切换的过程理解成一个特殊的函数调用 [而且 go 里面就有这么一个函数 runtime.Gosched()] 。caller-saved 寄存器如果需要保存的话，编译器会生成相应的代码，不用协程调度器保存。

@statumer 非整数倍缩放的情况就反过来了。

Windows 里主流软件基本都兼容系统的缩放（不分整数倍和非整数倍）。

Linux 里 Xorg 对非整数倍缩放的支持度几乎为 0 （不考虑先 2 倍整数缩放再 xrandr --scale 这种方式，这样相当于全局强行插值，所有程序都是模糊的，Windows 至少兼容的程序可以很清晰）。

Wayland 现在兼容性又不是很好，用个 Chrome 都容易出问题。

NetworkManager 的网络配置项是分用户级配置和系统级配置的。

你把 NetworkManager 里的 WiFi 配置设置成“所有人都可以连接”就可以不用登录也能自动连接了。（唯一缺点是 WiFi 密码会变成明文存储）

del 不是删除对象，是删除变量。可以近似理解成，语义上相当于一个更强的"=null"（和 Java ，C#等语言相比）.
就和你在 Java 里写如下代码一样：
AppConfig app = AppConfig.getInstance();
app = null;
这样做显然不会销毁单例。和 Python 里的这种情况是一回事。

@qbqbqbqb 再补充一下，PC 相对寻址其实是 64 位引入的，32 位里 offset(%eip)只能用在跳转语句上，所以 32 位里用的比较多的还是绝对寻址的方式。而 64 位的话就因为寻址范围的原因，PC 相对寻址更常用。

@qbqbqbqb 更正一下，偏移量是有符号的，所以 R_X86_64_32 的范围只有 2G ，上面错写成 4G 了

补充一下 x86 的几种内存寻址方式，总体上其实就 2 种（这里不讨论寄存器寻址和立即数寻址）：

寄存器相对寻址，AT&T 汇编写法是 offset(base, index, scale)
1 ）地址计算方法是 base + index*scale + offset
2 ） base 和 index 是寄存器，offset 是 32 位立即数（直接写在指令里的常数），scale 是 1,2,4,8 中的一个
3 ） scale, index, base 可以依次省略（ scale 默认为 1 ，其它默认为 0 ，有 base 的时候不能省略括号，否则省略括号），不省略 base 的时候可以省略 offset

程序计数器(PC)相对寻址，32 位写法 offset(%eip)，64 位写法 offset(%rip)
1) 中间那个特殊的寄存器是程序计数器（ Program counter, PC ），代表的是将要执行的下一条指令的地址。
2) 只能指定一个 32 位立即数偏移量，不能做其它计算。

全局变量的地址一般是写在 offset 的位置的。这就是为什么 x86 的 ELF 里就这几种寻址方式的原因。

@LotusChuan 你说的这种是基于 PLT 的相对寻址（ R_X86_64_PLT32 ），用于 shared 库的。

OP 说的 R_X86_64_PC32 是基于程序计数器（当前代码执行地址）的相对寻址，是用于可执行文件内部的，这种相对寻址不用修改任何东西。用这个的原因主要有两部分
1. 现在的操作系统为了安全，不仅 shared 库是随机地址加载（基于 PLT ，动态链接的时候需要修改程序里的基地址；这个特性称为 Position-independent code, PIC ），就连可执行文件本身的代码段、数据段也是随机加载（整体上加了一个随机偏移量，相对当前执行代码的位置不变，所以可以用基于 PC 的相对寻址，不用修改任何基地址；这个特性称为 Position-independent executable, PIE ）
2. R_X86_64_32 绝对寻址，全称是 32 位绝对寻址，使用的地址长度只有 32 位，能寻址的范围定死在 0x0~0xffffffff ，如果用这种的话程序的全局部分（代码段+数据段）就只能使用低 4G 的虚拟地址空间了；而 R_X86_64_PC32 虽然寻址范围也只有这么大，但它的寻址窗口是随着当前执行代码的位置滑动的，整体上可以寻址范围更大。

至于为什么只有这几种寻址方式，是因为 x86 指令集里寻址的偏移量就只有 32 位。
如果需要用 64 位绝对寻址的话，就需要通过寄存器来相对寻址，原来 1 条指令变成 2 条（先把 64 位地址加载到某个通用寄存器，再执行想要的计算），效率比较低，所以只有必要的情况才会用这种方式。默认情况下程序都是用的上述几种 32 位偏移量的方式。

@zlstone 现在 GitHub 账号设置里面有一个是否允许用自己的代码仓库训练 Copilot 的选项

@css3 有的插件的格式化功能直接 new 的文件里是没有效果的（设置了语言也不行，比如 Python ），必须先保存一下才能用。