@levelworm 其实我觉得这都算是比较传统的程序员了。毕竟那个年代选择做程序员的，多少都是有点爱好在里面的。等互联网兴起以后，大把的人只是为了这份工作赚钱才当程序员，那就没什么兴趣可言了。

有兴趣才能做出自己搞个模拟器出来这种事。不然肯定“你 CPU 都没有，我写个什么 Bootloader ？”，互相扯皮甩锅对其进度去了。

后面还有他用编译器给硬件打 patch ，这 patch 跑满了整个生命周期。。。。

所以说工程这种东西，就是能跑就行。

直接用 Ventoy ，把你要加的文件也放到 U 盘里，就能当正常 U 盘用。没必要非得去改 ISO 的。

@keengrass 是对红色成分的感知比较弱。主要是比较难分辨混色之间的区别。比如某种颜色混了一点红和混了一点绿，可能就看不太出来有啥不一样。
色盲是对某种颜色完全没有感知，和色弱是不一样的。就算严重色弱，也是能感知到纯红和纯绿的区别。但红色盲就只能从深浅去区分这俩颜色。

两条带子那种主力带不会影响手表；戴护腕或者厚的助力带，就把手表往上戴点，弄到小臂中间就行了。

TGA 和宇宙机器人值得一个诺贝尔和平奖。

不同管的作用是不一样的。有的带抗凝，有的带分离，有的带凝血。

所以你要化验的目的不一样，用的就是不同管里的血。

@cloudzhou 这个避免不了“模糊地带和寻租空间”的，只要你给我包了红包，那我就用固定组合模式给你。

而且问题在于不考虑寻租空间，这种东西也并没有比色卡好到哪去。色卡该有的问题一样有，即使你换成了交通这种简化情况特化的几种颜色。你也没法光靠色卡去筛选出来色盲和重度色弱无法应对的情况。

还是我前面说的，你模拟不了光照的复杂场景。

其实最简单的，而且也相对靠谱一点的，科目一最前面增加一项。直接用几张复杂场景的照片，不考虑位置，随机替换红绿灯颜色。几秒内判断不出来就算不过。但实际上做不到，因为还有地区在用纸质试卷，你总不能不让他们考试了。彻底取消纸质考试以前，这个根本不可能实行。

@cloudzhou 那你怎么看“背卡”的？

@cloudzhou 首先要明确一点，“色盲” 和 “色弱” 是两种完全不同的概念。“色弱” 并不是 “色盲” 的通俗性说法。色盲是真正的二元色觉，完全无法感知到某种颜色，而色弱并不是。但问题在于色觉异常大部分都是天生的，你是没办法理解你从没有见过的概念的。

比如红色盲虽然没法区分红色和绿色。但他还是能感觉到明暗的。这时候别人跟他说某个颜色其实是“红色”，他可能会把某种感知到的颜色加上它的明暗，认为是“红色”。从而和其它同类型的颜色，而明暗不同的区分开。但实际上他会把“红色”和“绿色”都感知成这“某种颜色”，而只靠明暗来分辨。从而觉得自己可能只是色弱，没办法在明暗相近的时候分辨颜色。

所以真要完全区分严重色弱和色盲，光靠那个图册是不行的。你要去做基因检测才行。那个图册的作用，只是能检测出来你是否是“色觉异常”。以及根据你的反应，大概推断个严重程度而已。

另外人类对色觉的感知很大程度上会被环境影响。而色盲或者色弱的人，对颜色的感知很大程度上依赖于明暗，但明暗是最容易被环境影响的。比如同样一个红绿灯，虽然他自身的亮度是一致的，但夜晚的光照条件，和被阳光直射时的光照条件是完全不同的。严重色弱的人平时可能可以分辨纯粹的红色或者绿色，但阳光直射红绿灯的时候，分辨不出红黄灯或者黄绿灯，只能靠位置分辨。或者一个灯颜色变化的时候，只能看出来明暗发生变化，但在阳光直射时这明暗变化又不容易分辨了。

再说回驾照这事。这就是经典的理论和实践的冲突。确实现行的图册并不是什么完美的办法，但也不存在可以**量化色弱程度，并且足够经济快捷**的检测办法。哪怕是眼底照片这种程度的东西都没有。之前有种用灯做的测试，但你很难模拟不同环境里，被不同光照射下这灯的状态。而且确实也导致过事故。而且你要知道每年考驾照的都有几千万人，这些人要交多少报名费才够这个成本？

哪怕就按你说的，通过统计来判断色弱（非红绿色盲）的风险。那么问题就来了，你不做基因检测，如何区分“红绿色盲” 和严重色弱？当然你可以不区分，全部作为色觉异常。但你把这些严重色觉异常的人，和轻度色觉异常的人放在一起统计吗？如果要区分的话，以什么标准进行区分？还是用图册？

总而言之，这世界并不是理想的非黑即白，很多事情本身标准就很难定，实施起来更是困难。所以有的国家逐渐放宽了，既然搞不明白，那就不测了。你敢不敢开车都靠自觉，剩下的大家全都上路赌命去吧。

你先看看国家的驾照申领规定吧。。。

跟“弱视”没有半毛钱关系。

@adwords 一根网线，说是大师开过光的，网速超快，而且还有方向性，卖你 8000 块钱，你会买吗？
但挂上“HiFi”的牌子，就有人会买。。。

@4ra1n 音色不行可以直接换音源吧，实在不行导出的 midi 应该也可以自己换。

只有投资才考虑涨跌，当时大家都说非刚需不要买，既然是刚需，就别考虑涨跌。

万年不动一次的那种数据，你可以考虑云厂商的冷备/归档存储。

上传基本免费，保存费用也很低，但数据提取比较贵，下载也需要流量费。

前提是你正常使用的数据有别的地方放，这个备份真的几乎没有读取的需要，只是保存以防万一。时不时就去翻腾一遍的话就不合适了。

1. 你公司给办工作居住证的话就可以直接摇号
2. 摇号指标有六成分配给“无车家庭”，你先看看你舅爷爷能不能满足条件
3. 今年一共两万个油车指标，上半年分配了 9200 个。这 9200 个指标，一共 62 万家庭，260 万个人在抢。下半年的估计也差不多。你先看看你舅爷爷能不能在这三百万里抢到那九千多个号吧。。。

存储不要用 UTC ，用 DatetimeOffset ，主要是相比 UTC ，它有个时区的偏移量。
这样你能知道你这条数据，是从哪个时区生成的。特别是你在同一个服务器中处理不同时区发过来的数据时，未来你如果想要显示这数据生成时的本地时间，那你存 offset 会省很多事。你如果只存 UTC ，等你加了这需求的时候会有大把的数据显示不正常。所以如果你做跨国的应用，不如从开始就存 offset 。
然后所有程序中处理的时候都用它来做，最终显示的时候再转换回本地时区。