从这些个角度看呢：

翻译机虽然可以解决一些交流问题但是没法用于生活的方方面面，比如你去意大利旅游看菜单，翻译机准确的显示出“提拉米苏”，但是从没学过外语的人要是不知道提拉米苏是什么呢？学习一门外语的时候还要学习当地的风土人情、菜肴物产、常见机构，这些是翻译机无法代劳的。

反讽、谐音梗、潜台词、成语是非常难以翻译的，通常需要听者自己判断说话人是想表达哪种意思，翻译机不可能像字典一样把每一种可能的释义都列出来。比如说中文里出现 114514 、520 等，是翻译还是不翻译？

语序不同的语言翻译以后和手势无法对应、单模翻译系统无法捕捉表情和手势。

最后文盲的标准是不识字，很多情况下不能快速阅读文字就无法工作。现在的 OCR 式翻译机对上下文的处理非常差，经常动一下摄像头就是完全不同翻译，遇到滚动字幕等更是错误百出。另外字母文字都会有很多缩写，需要有上下文和专业领域的熟悉度。

你就不怕 5 年以后你被“毕业”了，然后再被当成低端人口清运走？

另外地方财政靠土地经济，所以才把房市炒高，但同时租房价格贴近真实生活水平，甚至有房租和月供倒挂的。

除非你买的房子可以在里面养老（当地户口+当地社保），要不然不要这个时候当接盘侠。

@lekai63 赞同你的说法。现在经济的最大问题就是供给过剩、有效需求不足，推出国补就是想促进需求。这里面无所谓补商家还是补消费者，效果是一样的，就是要消耗掉国内过剩的产能。

另一方面中国已经有进入通缩漩涡的迹象，如果国补造成物价继续下行反而会加剧通缩，所以从长远考虑，商家涨价来应对国补其实是增强了这个刺激政策的效果。

@PainAndLove 我觉得苹果电脑的 AC 已经被玩坏了，自付比例巨高，Mini 反正不会拿出去用，还不如赌它不会在 3 年内坏。

1. 自动安装远端的逻辑没有考虑很多问题，比如我的远端只有内网没有公网，这 JB 都不考虑一个让我指定离线安装包地址的功能，最后远端版本我只能手动维护，体验远不如 vscode 。
2. 断线重连逻辑不好，经常失败，甚至会尝试在远端重复开 IDE 实例。
3. 有功能不支持远程，有时会尝试在服务端本地显示 UI ，显示不出来不停地在服务端抛 exception ，浪费 CPU 。同时本地不显示，你也不知那个功能是个啥
4. 即使是内网，跟手度随缘

我大学有个哥们就是搞储能电池的，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++模板，你只能靠变量名猜这代码是在干啥，至于对不对是完全无法确定。