@systemcall
我说的是上游 Type-C 下游全 Type-A 的，例如这三个绿联的：
( https://item.jd.com/100014988912.html ) 没有额外供电
( https://item.jd.com/100009223647.html ) micro-USB 单纯给下游独立供电
( https://item.jd.com/100008889013.html ) 下游 Type-C 用来向上游供电，要多几个芯片

下游提供 Type-C 分线意义有限，因为这种下游接口只能支持 USB，如果还要给下游 PD 供电那方案会复杂很多，价格估计要翻倍。如果不给下游提供 PD，那用 Type-A 还省事些，反正通常会用 AtoC 的线来连接，而且 Type-A 免得用户迷惑

只提供 USB 的那种叫集线器(USB Hub)，绿联就有卖（绿联 10916 ），只要 56 。
更多口的通常就是全 Type-A 的，反正就是 4 口基础上套多个芯片的事。

用 powershell
例如导出当前用户所有个人证书

Get-ChildItem -Path "Cert:\CurrentUser\My" | Export-Certificate -FilePath "C:\Temp\export.p7b" -Type p7b

然后用 openssl 转成 Base64 编码的 PEM

openssl pkcs7 -inform der -in "C:\Temp\export.p7b" -print_certs -out "C:\Temp\export.pem"

关于 Fedora 怎么考虑这个问题的建议直接看社区 wiki 的解释，关心这个的应该能看懂 wiki 在说啥。（ https://fedoraproject.org/wiki/Changes/BtrfsByDefault ）

打听薪资这事肯定是有利于劳动者的，劳资市场谈判上的信息不对称本身就不利于劳动者。
担心打听周围同事的可以考虑找联系较远职级相同的人问，要么去匿名社区调查，反正在哪里都得考虑说谎的问题，至少关系远的人不大可能影响你自己，但这个的参考价值就低了。
或者还有种特别麻烦的方法，没事投投简历面试，看人家开多少待遇。

Trending 早就不靠谱了，一堆人短时间 fork 的项目就能上榜。
这就是所谓的中立的榜单，要怪就怪排序规则吧。

不知道会不会是动态码率的问题,试下指定 128k 码率
另外用 MP4 串流建议开启 faststart 。
ffmpeg -i input.mkv -vcodec copy -acodec aac -b:a 128k -movflags +faststart output.mp4
这里假设视频流没有问题，使用复制流。

@hantsuki 我说的那些当然是你来做啦，对方只要会开虚拟机就行，最好开个快照。

@qiaogaohhb dd 写零这个方法不一定有效，建议用 zerofree+qemu-img convert -O，或者 virt-sparsify

Alpine 因为涉及切换 musl 的问题，除非不依赖 libc，否则没测试过不建议直接上。

打错了，强类型语言基本没有内置支持自动适应的数值类型

不是所有语言都像 Python 和 JS 那样内置自动适应的数值类型，基本上强类型语言都有内置支持。
实际上这类强类型语言的 JSON 库都会提供多个函数输出数值类型，使用者需要自行保证不会出现溢出和预期之外的精度损失。
通常认为 double 取值范围最大，但这是以损失部分精度为代价的，浮点精度损失问题是包括 JS 在内的所有语言都存在的问题，追求字面量精确的应该用字符串。

你都不想想社交平台封链接有多乱来（互联网已死），百度只对企业开放，微博是白名单，微信是发的多就封域名，如果是友商还要搞个复制粘贴恶心用户。

而且缩短网址是有意义的，短信和 IM 软件里加一个几行的网址很影响观感。

像 bit.ly 那种就是赚点广告费，还算无伤大雅。

@pwli 操作有点复杂，参考这个 ( https://tldp.org/HOWTO/Glibc2-HOWTO-6.html )
通过 -nostdinc -nostdlib 等开关禁止自动引入基础库，然后手动加入旧版 glibc 的包含目录和链接库。
一般还是用 docker 或者 chroot 解决比较省事

系统调用(System Call Interface)是比较稳定的，也就是说你用到的系统调用大概率在十年前的内核上都有。这也是 docker 能好用的原因之一。

目前看来比较容易影响的是 glibc，因为它不推荐使用静态链接，主要涉及 libc.so.6 和 ld.so ，前者必须跟后者版本严格一致，后者通常通过 interpreter path 显式指定使用系统提供的版本。你也没法控制编译器不使用新版 glibc 新增的符号。

另外两个基础库 libstdc++.so 和 libgcc_s.so 倒是可以选择静态链接，问题不大。

如果能用 musl-staic 或者像 go 那样完全不依赖 glibc 也是很好移植的。

所以通常做可移植的做法是把所有用到的 so(包括 glibc)全打包到程序目录下，用 patchelf 修改 interpreter path 和 rpath 。

查了下好像 cloud image 并没有本质区别。
删掉不用的服务，例如 open-iscsi 、cryptsetup 、cloud-init 之类的，用 apt purge 删除。
编译完的中间产物、源码、工具链删掉，引用的 libXXX-dev 也删掉。
装软件加个 --no-install-recommends，通常可以省掉安装 XXX-doc 文档。

放虚拟机的考虑下用 ubuntu cloud image 做基线？

一方面不知道优先级。
大公司反馈系统感觉都不会认真看的，晾着凑够一定的复现率才会去看，就算修了也要等发布流程。
要修也挑简单的修，好刷工作量。
反正微软已经是这样了，不指望国内大厂能反应快些。

比较烦的是浏览器没缩放但系统有缩放也会出这个提示。
非得我一个高分屏的用 100%缩放看小字？
我也没觉得不缩放的页面是正常的，两头一大片空白你管那叫正常？