Windows 和 linux 的分区本来就没有区别，区别的是路径的传统。c:\user d:\其实就是/c/user 和/d/而已，只是 Windows 把根目录隐藏了，并且不适合自由选择挂载点。
Windows 记得是有 lvm 一样的动态磁盘的，可能是有什么限制或者易用性的原因，PC 很少见到实际使用，使用 lvm 的情况下分区想怎么调就怎么调。

没人用 foxyproxy 吗，一直都被 Mozilla 扩展商店推荐，也支持 mv3 。
不过 Firefox 下为 container 配置代理用的更舒服。

以前还在用 Windows 的时候用的 idm ，现在很少用浏览器下载了，基本上都是复制链接后在终端里用 wget ，大文件就 axel/aria2c ，浏览器默认只能下到 Downloads 下，下完还得 mv 走，选其他目录也麻烦。

@XiLingHost #1 怕不是要被手机管家标记为恶意软件给自动卸载掉，然后真正的恶意软件就可以被诱导安装了。

直接用就行，不需要配置和插件，vscode 是开箱即用的前端 ide ，就像 idea 是开箱即用的 Java ide 一样。

试试 zig ，把 zig cc 作为 c 编译器和链接器，可以开箱即用无配置的交叉编译到大部分主流平台。
https://dev.to/kristoff/zig-makes-go-cross-compilation-just-work-29ho

你说的那叫 sdk ，封装好了的 rest/ws api 而已，热门的交易所往往也有非官方维护的 sdk 。
数据分析不一定必须要用 Python ，Julia 和 R 也不错，当然你要是已经 Java 入脑很深了，还是用 Python 更合适。

很怀疑微信究竟会不会真正允许在 bwrap 里面使用。
如果没有 exploit 的话，理论上微信在沙箱里是获取不到任何外部信息的。比如在外面运行屏幕识别/自动化的微信机器人，或者通过容器或虚拟机批量运行，微信是没有办法可靠识别的。即使不是直接封号，至少账号的风控可疑等级也要被拉满了。
就怕以后微信真正适配（国产） Linux 后需要加载 Tencent Protect ™️ 内核模块才能运行。

Android 有 gadgetbridge, 可以在不使用官方 App 、不上传数据到云端的情况下使用各种手表/手环，只要在支持列表里选一个购买就行。
https://gadgetbridge.org/

你不会觉得 GPU 直通和 usb 直通一样简单吧。
https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Setting_up_IOMMU

Cow == copy on write
指的是 write 的过程中会发生 copy （一般来说即把覆盖写入已有数据的请求重定向到空白区块）
而不是 copy 的过程中有什么特别的行为。snapshot/dedup/cp -reflink 等等是根据这种特性（被覆盖的数据仍然存在、且是 immutable 的）实现的不同的功能。
显然不是每个 Cow 的文件系统都实现了每个 Cow 可能实现的功能。如果你要 shallow copy,硬链接或许就足够；如果你要以 copy on write 的语义创建文件的多个副本，snapshot 也可以达到。

@Tumblr #4 OP 的需求如果没有理解错的话，是要在服务器上运行只支持 Windows 的客户端软件，而并非是使用 Windows 服务器。
基于这种需求，找一个裁剪的、无更新、EOL 的镜像是合理的，只要目标软件能运行就可以。

你对 Windows 服务器的建议是正确的，Windows 服务器确实不适合大部分人 OP 一样的普通服务器用户，没有 gui 的 Linux 服务器谁都能用的来，没有 gui 的 Windows 服务器能用的来的就不多了。

现在这个时代，没有什么代码有被逆向的价值。反编译保护几乎是 malware only 的需求。

@fluffyfoxxo #121 这个声明总体来看还行，tldr：
1.作者声称删文件是威胁和玩笑，没有真正实行，并且可以反编译验证弹窗的这个函数中没有调用其他的行为。
2.作者声称访问邮箱是错误的指控，访问邮箱是曾经的行为，现在是 dead code ，并且可以验证现在的版本访问邮箱的字符串没有被引用。

还有一点小问题：
1. 没有解释在最开始的时候不承认推脱到第三方来源，这种文案写过不可能忘了。
2. 不了解 macos 逆向不确定这种方式验证是否可靠，并且即使可靠，也只能确定：
2.1. 弹窗的这个函数没有其他操作，不能确定软件的其他部分没有恶意行为。
2.2. 作者承认过去版本曾经有过访问邮箱的行为，现在不再这么做了。

这个激活码是购买的时候唯一对应一份授权的吧，那么绑定邮箱的要求就没有任何意义，只会给原 OP 一样的在不同场景都使用不同邮箱的人造成困扰。如果共享激活码会造成盗版，共享激活码连同邮箱没有任何区别。

原 OP 在这里填虚假邮箱是很正常的，因为不需要收信。如果是需要接受邮件的场景那就填临时邮箱，如果需要收信和回复就填隐私转发邮箱，如果还需要主动发送再填正常邮箱的 alias ，主邮箱从来不用做任何地方。这是关心隐私的用户的常规实践。

@DIYgods #31 尺寸好解决，构建的时候只包含用户需要的路由模块就行吧。还是说请求/相应体的尺寸也不够？我感觉纯文本的服务应该不至于不够吧。

不可能避免，专有软件就是这样的。如果他不是弹窗“威胁”而是真的悄悄这么做的话，几乎不太可能被发现，因为这是针对特定用户的行为。
专有软件 === RCE

既然重构，可以考虑一下适配 cloudflare workers 等 serverless 云平台上，这些平台提供的免费额度通常都足够用户自己部署个人使用，并且 cf 的 ip 发出的请求更难被 ban 吧。