@ipwx

其实软件工程从一开始就是试图用更高层的抽象去封装更复杂的显示细节。
---
这一点你说的没错，事实上从抽象这个功能来讲，C++既需要做抽象，又要放不下底层，还要兼顾各种特性，于是造成了本身无比的复杂。现在普遍引入了 MBSE，基于 UML/SysML 在更高层级上建模，然后直接生成 C 代码，最终编译成机器码直接执行。这种模式已经是大的趋势了。UML/SysML 专门负责抽象，C 负责底层，就这样两层就够了。所以这样看，C++就没什么意义了，两头兼顾两头都做不好。这也注定了即使用 C++，也是在某个领域某个模块（比如图像视频处理）非用不可的情况下，才会使用，而且限制及其严格。

还有就是 NASA 并不慢，一套系统不是只要搞软件就能 run 起来的，在软件上面还有更高层的系统级的考量。基本的飞行系统架构，最顶层是飞行器系统，然后分解为推进子系统，动力控制子系统，环境控制子系统，电气子系统，电子子系统等等，这些子系统里面再进一步细分为机械模块，硬件模块，软件模块等模块，所以至少是三个层级。比如推进子系统，机械模块分为发动机喷嘴，燃料阀门，点火装置，压力检测等子模块; 硬件模块对应有发动机喷嘴控制器，燃料阀门控制器，点火装置控制器，压力检测传感器等硬件设备;然后才是运行在这些控制器里的软件模块。所以整体是一个非常庞大的系统，不止一个 CPU，不止一种 CPU，不像做个 App 什么的打开 IDE 就能写。

NASA 的系统工程和软件工程都是一流的，很多软件领域的概念和方法都是由 NASA 或者其他航空航天巨头首先提出，然后才慢慢引入到软件领域的，特别是测试领域，比如 MC/DC 。Elon Musk 纯粹是莽，没把安全性放在首位，如果一定要类比，我觉得 NASA 是传统类型的软件厂商，SpaceX 是互联网厂商。

@ipwx

芯片不是太弱，性能根本不是优先考虑的选项，首先要考虑的就是尽可能不出错，当前芯片性能完全是过剩的。但是地球上普通的芯片是不能直接拿去用的，需要定制耐高温，抗辐射等特殊设计的 CPU 。

https://en.wikipedia.org/wiki/RAD750

@ipwx

SpaceX 毕竟刚刚出大气层，还没遭受火星上各种宇宙射线，各种高能粒子轰炸，Elon Musk 本身把安全性看的也不高，成本和快速迭代占了较高的优先级，所以 Falcon 初期会各种炸，直到迭代出一个稳定的版本，NASA 经过了火箭，载人，登月，火星等各种毒打，思路是稳定优先。所以才会有 SpaceX 用 x86 来搞，NASA 坚持用 Radiation Hardened CPU，同样 Tesla 的车和丰田的车也可以类比。

外太空有很多其他因素要考虑，温差大（零下几百度到零上几百度），震动大，辐射大要防 SEU 处理，还要尽可能省电，优先保证安全性，还要绝对的稳定，还要做 N 多冗余设计，这么多东西要考虑，整个系统设计思路跟地球上其他系统完全不一样。

当然，随着发射成本的降低，现在也有把 HP 的高性能计算集群发射到空间站进行就地处理的实验了，好像已经有初步的结果，不知道没经过上述处理，只是简单的做 ECC 是否能保证结果的正确性。

@ipwx 很多代码都是自动生成的，还有很多是复用以前经过 certification 的老项目代码，测试的时候需要的人多。要想系统可靠，就必须尽量使用简单的基础模块，然后尽可能复用，宁可简单的东西复用几万遍，也不会为了省事儿弄个新轮子，NASA 自己造内存管理的轮子是迫不得已，不然也不会用的。

这些项目里面，R&D 的 effort 只占 30%，剩下的几乎全部是 Documentation，Test，Certifiction 。

@name1991 图像处理和路径规划用的“严格裁剪版 C++”，内存管理这一块 NASA 重新造了一套轮子，上两张图吧


https://i.imgur.com/E2E1WNd.png

https://i.imgur.com/rHpEZu6.png

@ipwx
@bruce0
@tianming1992

这里的 undeterministic 不仅仅是指技术上的，需要用 template 实现的函数大部分都是基础库之类的，实际作用是为了一次书写，适用多种类型，这种情况理论上是没问题的，可是在实际使用过程中，可能会碰到各种意想不到的问题，比如，嵌入式里面有很多 8 位，16 位，32 位不同类型的处理器，这时候假如函数里面使用了 Magic Number 作为参数，比如上限值，很有可能当参数为 32bit INT 类型没问题，但 8 位，16 位就会有问题。（你可以 Argue 说这是程序员素质的问题，但写函数的和用函数的人保不齐有一个没注意的，这样就会带来问题）

template 可以看作是一种语法糖，爽了开发，但是让后面的测试，追踪，certification 乃至出了问题做 Failiure Analysis 不确定性、复杂度和人力成本剧增，可能导致整个项目成本剧增，因此即使有这种场景，一般也是用宏定义来实现的，高可靠性的项目就是从技术上，管理上等各个方面来进行限制，尽最大能力保证不出问题，最好是从根本上消除产生问题的可能性。

这样来看，不能使用指针，不能动态分配内存，循环嵌套不能超过三层，不能使用递归等等神奇的限制也就合乎情理了。

@ipwx [潜在]

只能说隔行如隔山，我要是告诉你，循环嵌套还约定不超过三层嵌套，你会不会更惊奇？

这些行业的规定和经验，都是经过一条条人命累计出来的。

@ipwx 别说 template，连 malloc 和 new 都不能用的，所有可能潜在有 undeterministic 特性的功能都不会用的，程序运行所需的 CPU cycle，memory，communication 等资源占用都要事先明确计算好，不得超过 50%。基本上就是用做硬件的思维来写软件。

@Eagleyes 那个是用的 C，火星车上用 C++做的图像识别相关的，限制非常严格，几乎等同于带类的 C，不能用多态，不能用递归，不能用动态内存分配。

升级之后不知道为什么 docker 会变成 masked 状态，containerd 服务倒是还在正常运行。

@francis59 我试了啊，Tab 跟地址栏之间还是一条缝隙，只不过 Tab 变小了，我想要的是原帖里面第一张图的样子，这个 Compact 只是把第二张图的 Tab 弄得小一号，变窄了而已。。。

@francis59 实测 Firefox 91 版本不行，估计是以前的版本可以这样弄。

@dfkjgklfdjg 随便改动界面和显示风格对基于 UI 的测试影响最大，最严重的情况下需要对所有测试用例进行更新才能继续使用。Chrome 就是因为自动更新且很难禁止被我们抛弃了，Firefox 是可以禁止自动更新的，但是会提示你。

其实我个人感觉软件最重要的是安全和稳定性，UI 一旦成熟最好就不要动了，除非是出现了手机触控这种划时代的变革，否则所谓的提升生产力扯淡的成分居多，更大意义在于帮负责 UI 的刷 KPI 。

@chutsetien 我在 91 版的 about:config 里面还是能够禁用掉 Proton 的，界面和启用 Proton 时有明显区别，那个右键菜单就能看出来，禁用之后是没有前面的小图标的。所以应该是能禁用，但是 Tab 确实是回不去了。

性能方面也有明显区别，冷启动时，能够明显看到 Bookmark 从左到右刷新的过程，而不是以前那种秒开。右上角的面包菜单点击之后，也能明显看到图标刷新的过程。

不明白现在这些公司一天到晚折腾 UI 干什么，有这功夫用来提升性能多好啊。。。

@anubu 谢谢了，这个图标库真不错。

@anubu 这个 homer 做的挺好的，只需要改 config.yml 就 ok

@Smash 卡片感觉太占地方了，还是图标好点。。。