@zhea55
@Showfom 我去试试 rime

@harwck 没有改变分辨率，一直是开笔记本屏幕用，没有外接显示器。

@fortree 硬件工程师转程序员其实是有优势的，毕竟对底层比较熟悉。

个人建议一个程序员起码要配置三套语言：一门解释型脚本语言，两门编译型语言。

解释型语言推荐 Python，编译型语言推荐 C 和 Java，C 是面向过程语言，覆盖实时性高的应用，Java 是面向对象编程语言，后端开发，Android 开发，中间件开发甚至桌面应用开发都可以覆盖到。

如果是彻底不做硬件，一心转互联网，脚本语言换成 JavaScript，学点前端框架 Vue 什么的，这样也可以做全栈。

@fortree 原帖被删了，我在消息里面找到了原文，希望对你有帮助：

zion03 感谢了你在主题 › 想进大厂嵌入式方面实习岗位(18 年毕业)，求 V 友帮忙指点下简历，看得上的直接带着。 里的回复 338 天前 删除
项目经历很不错，应届身份进大厂你的学历和学校吃亏。

几点建议：
1，大的方向：整个嵌入式目前方向越来越集中了，简单的系统用 PIC 和 C51，不用操作系统；稍微复杂的直接上 ARM，走嵌入式 Linux 了；更复杂的基本上都是 Android 天下了。随着 Cortex-M 系列的普及，以后对实时性要求稍微低一点都会上 ARM 和嵌入式 Linux 组合。所以，现在的嵌入式远不是以前 PIC，C51，MSP430，STM 系列，AVR 系列，摩托罗拉系列，ARM 系列，CPLD，FPGA，等等百花齐放的场景了，未来的方向将高度集中化。这个趋势也可以从最近几年大的半导体公司合并中可以看出，Intel 收了 Altera，NXP 收了 Freescale 又被高通收了，现在高通又面领着被 Broadcom 收购，以后这个行业将是高度集中深度整合，大玩家就那么几个了，SoC 是未来的主流。

2，个人的发展一定要符合历史潮流：高度集中后，半导体器件的生产成本会不断下降，因为半导体的成本是按规模摊薄的，生产数量越多，成本越低。所以，以后即使是一个 C51 能搞定的事情，也会上个 Cortex-M，因为达到一定规模后，后者成本更低，而且方便日后扩展。因此对个人来说，深入学习嵌入式操作系统是迟早的事情，晚学不如早学，尽快往上层发展。应该尽早放弃底层的纯指令集编程的平台，比如 PIC，了解即可。如果对指令集编程深度痴迷，建议认真研究 ARM 和 Intel 的 ISA，不要在 PowerPC 、MIPS 等上面浪费时间，不建议深入研究任何 DSP （如果 GPU 也算的话，GPU 除外）。

3，个人技能树要多开分支。不要绑定到某几款硬件 Device 上，不要绑定到 C 语言上，不要绑定到面向过程的编程上。做到最顶级的嵌入式，面向对象、设计模式、操作系统、算法与数据结构、控制理论、数学一个都不会少。

如果个人技能树要往偏工程方向发展的话，请尽快补足操作系统、面向对象、设计模式方面的知识。操作系统可以以 Linux 为主（不是嵌入式定制的实时 Linux，是通用的），深度了解分页机制、内核调度、内存管理等知识；面向对象以 C#为主（ C++的坑比较大，没必要），好处是一是可以写上位机的应用，二是以后转互联网、转桌面应用也有退路；设计模式没什么好说的，C#顺带的事情，拼命做项目，不断寻找 Best Practices 吧。

如果个人技能树要往偏系统设计和算法研究方向发展的话，请补足数学和控制方面的知识。Matlab 和 Simulink 要玩的烂熟，做系统架构和实现的时候，面向对象编程和 UML 是不可避免的，大厂一般都会用到。

最后，大厂的套路跟自己单打独斗完全不一样，焊板子写代码做系统只是其中一部分。如果是系统大厂比如汽车行业的 Ford，Tesla Motors，Honda ；家电行业的 Panasonic，SONY，Philips ；工控行业的 Siemens，GE，ABB ；航空航天的 Boeing，GE，Honeywell 都是需要按照上面第 3 条的第二个方向发展，这种大厂对学历和学位要求比较高，应届的话上面一堆 985 的硕士博士，你基本上没有可能，这种公司你工作个三五年之后，拿个在职硕士可以试一试。如果是元件或者子系统大厂，除了知识面要广，还会对你在某一个方向有非常高的要求，比如操作系统，一般最低要求都需要你能独立编写一个 Driver 。因为大厂都是团队上阵，团队的每个人都要能独立 cover 某个具体的方面，其他人碰到这一块的问题时都会来问你，你要做到问不倒。知识面广的意思是，你硬件设计、软件设计都要会流程了解，I2C，USB，CAN，TCP/IP 这些协议要熟悉，硬件栈软件栈实现要熟，不管哪个方向都要能稍微翻翻就上手做事。

最最后，你的简历还要再改改，我记得我当初的简历起码改了上百遍了，多写项目相关的东西，少堆砌课本基础知识，多出现能让面试官兴奋的关键词。现在这个互联网一统天下的时代已经很难看到你这种对嵌入式有如此热血和执念的少年了，我作为一个过来人，已经见识过这个行业最顶级的平台和系统，现在也逐渐由硬件转软件再转互联网，所以才有上述结论。务必要多学习多掌握通用技能，切忌绑定到某个固定的硬件平台上。嵌入式这条路并不好走，而且越走越窄，希望你能勇往直前。

If the problem persists, please contact the site's administrator.

@shijingshijing #49 说严谨一点吧，现代计算机的待机模式分为好几种，传统的 S3 待机模式下，PCH 里面 Controller 和 PMIC 联合控制，实现 Power Gateing 可以关闭 CPU 内部大部分模块的供电，这时候 Cache 和寄存器里面的数据是会被清除的；后来 Intel 为了实现手机熄屏之后继续接收短信和各种推送，播放音乐等功能，又推出了 S0 待机模式，也就是所谓的 Modern Standby，这个 S0 待机能够对 CPU 做 Clock Gating，能控制 CPU 的运行频率，使 CPU 以极低的时脉运行，但是问题也不少，很多人反映 S0 待机会让笔记本待机功耗大增，在背包里发烫，连微软自己的 Surface 系列都无法幸免。

@MakeItGreat 台式机的待机不会用到 CPU，是 PCH 里面的 Controller 和 PMIC 联合控制的。只有超级本的 S0ix 状态下，才会以极低时脉使用 CPU，主要是为了接收电子邮件，熄屏播放音乐准备的。

@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 干什么，有这功夫用来提升性能多好啊。。。