我大学有个哥们就是搞储能电池的，1000A 早不是技术问题而是工程问题：
1.最大的问题是散热，从变流器到充电桩到车身内全都会变成电炉，固定的设备容易散热，车内散热比较困难。除了车内要全程水冷以外，不排除冷却水也要通过充电插头循环到外面
2. 高电流=效率低
3. 复杂性高，可靠性低
4. 电网配套困难，要直接接到变电站，而且要是多台车同时开始/停止充电能对局部电网形成冲击。可行的技术方案是要在这个充电站里配电池缓冲，那效率更低而且成本很高。

综上：如果大多数时候不需要这么快充那这么一套设备就不合算

你 lspci 输出里没有 ARI 所以是不可能开 SR-IOV ，你要先确保网卡固件支持 SR-IOV 然后 BIOS 里打开 ARI 。

我遇到过，疑似是 IDE 内部的编译器超时/挂掉或者解析不出模版，你手动编译一下试试看看出什么提示？

这里面有几个问题，你要把它分别弄清：
0 、找到真正 C 盘的 UUID ，这是你正确修复的基础，因为你 Win to go 的盘也做过 C 盘，所以有些设置里可能混淆了。Win 系统用 mountvol 命令不加参数可以看到各个盘的 UUID 。
1 、注册表里的盘符只需要把 C 盘的修好，其他可以导出 reg 文件以后删除，等进入系统以后再重建。C 盘对应的二进制信息里面就有 UUID ，但是因为 endianess ，部分字段的字节顺序和 mountvol 看到的是反的。
2 、我猜导致你问题的是 KB5034441 更新，它需要扩容 Recovery 分区，但是错误的操作了内置硬盘而不是你的优盘。我有个印象是 recovery 分区不对的话即使不需要 recovery 也无法正常启动，你可以尝试从 BCD 里把 recovery 信息暂时删掉。
3 、其实 BCD 重建比修起来更方便，把 EFI 系统分区挂载以后把里面的 EFI 文件夹改名（或者备份到其他地方)，然后用这里面的命令： https://www.tiger2doudou.com/doku.php/windows:os:reinstall_efi_partion_via_bcd_command 。注意 PE 系统里的盘符是无所谓的，BCD 里面记录的都是 UUID ，重建好以后用 bcdedit /enum /raw 命令可以确认系统盘的 UUID 是正确的。

可以进系统以后你可以参照 KB5028997 重建 recovery 分区。

我觉得要重点提出 1 楼说的“这中间有可能从有竞争变为无竞争（ volatile ）”，我觉了楼主可能犯了并发编程里一个常见是思维错误就是我“刚刚” 判断了一个条件，后面就不用判断了。

当你看到这些国产 app 安装包小则几百兆，大则直奔 3A 休闲游戏的时候，你就知道里面屎山堆得多高，出这些 bug 都不奇怪。

要知道 Windows 98 的安装盘也就 700MB ，里面还带了几千个设备的驱动,虽然 98 经常蓝屏，但是人家好歹是有优化的。

压缩空气效果好，一定要在屋外弄，最好带上 n95 和护目镜。这个气体很冷的，吹一下换一个地方，否则会有冷凝水。

除非全密封的氦气盘，盘体本身不要碰压缩空气，拿拧很干的布擦擦除电路板的几面是可以的。

吸尘器我试过效果不好，因为嘴太大了，压力不够。

@paopjian 这个问题到现在还有啊，比如嵌入式系统 32 位的已经很高级了，用 8 位机的也大有人在，很多机器连整数除法都做不了，这也是 C/C++最大的客户群。

@cnbatch 我发出来才看见你的，我觉得你说的“int 必须比 short 宽，long 必须比 int 宽”虽然让部分初学者可以更清楚的了解这些类型的区别，但是与系统编程语言的定位不符合。比如说我记得早期的 64 位机就有完全不支持 16 位长度的指令集，这样 short 也必须是至少 32 位，那么 int 就得 64 位，long 不能 128 位吧？

这个问题的本质是 C/C++定位是系统编程语言，数字类型的是为了方便在不同指令集之间移植来设计的，比如说：

* 所有类型都只有最小宽度而没有绝对宽度，因为不是所有指令集都有操作各种宽度的指令
* int 就是在那个平台寻址范围内做下标比较合适的长度
* short 就是可能比 int 节省空间，但是至少有 16 位； long 就是至少有 32 位

当然我也觉得理想是美好的，现实是骨感的，这些语言出现不久互联网就爆发了，有了跨机型交换数据的需求，导致这些依平台而变的类型不好用。

理论上说交换格式可以和内存里的数据类型分离，比如内存里的 struct 用 int, long 等类型，交换时翻译到到固定长度的 char[]（这样还解决了 endianness ），但显然没有几个人这么勤快。

当然我觉得 long long 出现时，这个情况已经很明显了，应该直接定义 int64 而不是新增一个关键字。

@Sodacooky 我觉最好还是不要拿 C++的 auto 来比，因为写模板的时候很多中间值你都无法知道它类型是什么，如果不用 auto 就得声明一个新的类型参数，但有的时候又不能改变 API ，导致模板函数套模板函数，编译越来越慢。

Java 的 var 这个就是可有可无，因为类型永远是清楚的。

另外我觉得在 PR 里读到 var 很多的 Java 有点像读找不到实例的 C++模板，你只能靠变量名猜这代码是在干啥，至于对不对是完全无法确定。

@noErr 很多中小公司的系统管理员并不感冒命令行，也玩不转云 API ，他们就喜欢在一个图形界面里面反复点鼠标，Server 版几乎是他们唯一的选择。虽然 Server 版很贵（要按用户人头收费），但反正是公司出钱。

桌面版的 Windows 其实也只能从企业客户赚钱，你可以想象成定位已经变成“Office 官方运行环境”。但是只有持续培养非企业客户的使用习惯才能把持住企业市场，所以个人版还在做，困扰楼主的这些乱七八糟的功能都是在给充满广告的 msn.com 引流，这样可以补贴一点成本。

问题就来了，如果编程工具实现了自举，那每个客户订阅一个月自己写一个后面就不用再订阅了（至少可以直接接入最便宜的 AI API ），那这些做工具的就无法赚钱了。

就像我那天构思了个部分利用 AI 的代码优化系统，但转念一想它最有可能的作用是把我的部门搞失业，遂作罢。

同情楼主，但我觉得楼主把因果搞反了，据我的观察，大公司软件质量的堕落是面向 KPI 编程的结果。这个文化的初衷是好的，就是用科学和客观的方法评价工作，尽量避免人评价人容易产生的偏见，这恰恰是西方理想主义的思维，不是印度实用主义。

程序员的工作就是在既定的规则中游走和优化，无所谓是编程语言的规则还是评级系统的规则，而且这些大公司招的都是人精。真正花很多心思写良好的代码然后彻底测试的，多少是要靠情怀，对提升 KPI 帮助有限。我在西方工作很多年，接触到十几个国家的人，我觉得欧洲白人是最情怀的，印度人确实最功利，中国韩国人等差不多在中间（但是抱怨少，所以经常被用来成全别人的情怀）。

恶心的是这些公司的管理层多少清楚这一点，但他们自身也有非常明确的 KPI ，比如股价，这些和代码质量不是很挂钩，但是非常受功能数量和市场营销的影响，所以形成了这个局面。

@NoOneNoBody App 内自动更新的其实是个很不安全的设计，经常有 app 不用 HTTPS 也不验证包签名，下载完了就安装，你还得给各种 App 安装权限，下次后台安装个广告甚至病毒也没法知道，我父母手机就经常出现什么读小说软件安装了个浏览器，浏览器安装了个应用市场，如此往复。因此 Play 商店不允许 app 内置更新。

另外自从拼夕夕事件以后，凡是 Google play 不能上架的 app 我都换 iPhone 装或者模拟器，不会在主力机安装 APK ，因为利用漏洞攻击系统还不全网下架实给开了很不好的先例。