git-lfs 服从 HTTPS_PROXY 环境变量
其实吧一般不需要完整 git 仓库的可以考虑网页直链单独下载大文件，这样就可以套用浏览器能用的扶墙方案了，其他小文件可以继续用 git 拉下来，clone 之前设置环境变量 GIT_LFS_SKIP_SMUDGE=1 可以避免下载 lfs 文件

你如果是说当个 openai 搬运工的，大把，我差不多天天都能看到。
至于真搞训练的，不是要大把钱就是大把数据，跟小创业者也没啥关系。
而且你看那些追这波热潮的，哪怕是大厂，都是顶多换皮微调级别，真搞训练的怕不是连融资都拿不到。

真想这样你还不如不开源。
为啥要开源？白嫖贡献者吗？

理论上如果知道配置参数，就是 VLAN ID 和 LOID 之类的，可以在同是 EPON 的其他运营商 PON 接入用。
不过问题是哪家运营商会让你自备光猫的。

直通=Guest 独占 PCI 设备。能把一张卡掰到几个 Guest 用的不叫直通，那叫 vGPU 。
linux 的话有个内核 patch 可以把伪装硬件 id 改成支持 vGPU 的 GRID 计算卡。
Windows Hyper-V 也有一个 GPU 分区的跨厂商方案。
这两种方法都有很多坑，只能实测。

别的地方不知道，广东省内迁户口早就可以这样了。
主要看两地户政系统有没有打通而已。

考虑到 TX 云的出过 CDN 边缘节点预热也给用户算费用的蠢事，就算便宜也得怀疑它的可靠性。

分频命名的理由 1：因为多数手机在接入信号良好的 2.4G BSSID 后不会主动切换至 5G BSSID ，然而后者覆盖范围肯定小于前者，不手动切换的话 5G BSSID 就成了摆设；
分频命名的理由 2：部分老旧型号手机/使用过时驱动的 PC 网卡无法连接 WPA2-PSK/WPA3-SAE 混合模式 SSID ，估计是对 802.11w 支持有问题；

不分频命名的理由：WiFi7 MLO 可以将 2.4G/5.2G/5.8G 三个频段捆绑一起用

我对 WiFi7 是没啥指望，6GHz 国内没戏，没了这个 MLO 实测带宽并无明显提升，远不如让手机支持 2x2MIMO 160MHz （高档 SoC 标配）
实际上我建议分享网络就分享 5G SSID ，反正现在只有 IoT 和超低端/过时手机才会不支持 5GHz 。

知道你想吐槽老版 golang 不支持泛型了

不同网段不代表不互通哦！
有没有防火墙隔离是公司网管决定的事。

如果是说 NV 支持最佳的，那就是 NV 官方提供 CUDA 软件源的那些发行版，例如 Ubuntu LTS 、Debian 、Fedora 等。

不过对于笔记本，通常是核显驱动决定内显支持情况，那就是能提供最新 Linux kernel 的版本，这个大部分面向桌面的滚动发行版都算可以。
初期版本的 gpu 驱动可能不支持新硬件的全部功能。那我的联想 Renoir R5 集显本来说，Linux 5.4 开始提供 initial support ，但过了好几个版本之后背光控制才能用。

RPL 的设备 id 在 2023.8 才加到内核中，离现在不远，那就是越新越好了。

1. 就算是浏览器也会在启用代理的时候禁用 HTTP3/QUIC ，因为并不能受益于 HTTP3 的改进
2. curl 可以编译为使用 schannel ，这时就用系统证书了

对 x86 来说就是更多可用的寄存器，以及可以在关键路径上使用启用新的 AVX/AVX2 指令来优化。虽然说同一个程序可以同时为新旧 cpu 提供多个执行路径，但编译器自动优化未必会这样做。
ARM 的问题是现在有不支持 AArch32 模式的 ARMv9 处理器核了，换句话说不能保证 ARMv5/v7 目标的程序可以在所有处理器上运行。出于兼容，或者就是懒，以及减小程序体积，不在乎性能，是大部分消极跟进 64 位应用的原因。

看上去好像是你用了 ssh 客户端不支持服务器允许的密码套件？
例如 ssh 版本过旧。

请再认真了解下中间人攻击，主动攻击的情形，ECDHE 防范的是被动攻击。
如果从头到尾跟你通信的就是猩巴客，你怎么发现对面不是星巴克？

1. 照片视频啥的，定期转移到 PC/云存储或者删，别扔在手机上代代相传
2. 不管是 QQ 还是小而美，聊天记录定期清理，只保留文字信息立省 80%以上的空间
3. 一键换机是爽，冗余数据就代代相传了，能不用就不用
4. 不管是 qq 还是小而美，下载的文件都没法不依赖外部手段从应用存储中删掉，所以定期做一次 refresh 是个好主意（备份/转移聊天记录至 pc/另一台手机->清空应用数据->还原聊天记录）
5. 这些超级 APP 普遍有热更机制，还会留下几个版本的运行库和一揽子运行数据占空间，还容易触发换机的 bug ，所以需要步骤 4 来做个了断

虽然我觉得以上要求超出大部分用户的能力了，所以还是多氪金买大容量手机和云服务吧。

ios 应用如果内存使用超额是直接 oom 没商量的，前台应用如果没超限那就是没问题。
另外 ios 的所谓多应用后台是十分有限的，哪怕真有大内存也只有前台应用受益，例如 3d 游戏是非常容易获益的。
而且不知道为啥你会觉得手机的 flash 质量好的？不管是 i 还是 a ，搞 swap 我都视为计划报废的阴谋。

因为 h3/quic over tcp 会丢失 h3 集成流控所带来的好处，因为被代理隧道封装之后很多流控信息都丢失了，例如重传情况、PMTU 等，还不如就用 http connect/socks tcp,把流控的事完全交给隧道来做，例如让隧道本身使用 h3