建议主题标题写明“APM 工具”，因为“性能工具”的种类很多。
并且我认为这两篇文章更像是在解释你解决问题的方法论，至于产品看起来更像“一堆 script”而不是“一套工具”😂

我想问一下现在 rvm 是凉了么 ...

https://github.com/rvm/rvm/issues/5096
官网安装教程的 keyserver 早就没了，好像最近一个月才更新
并且按照这个教程安装的 rvm stable 版本的 known list 是没有 Ruby 3.1 的，这货去年天主教圣诞就发布了 ...

看到楼主举的例子，我想说 我发现用 Flutter 写的项目性能都挺好的 ←_←

我也想劝退，其实没啥大问题，就是对于楼主的需求而言，ITX 可能一直有一种“凑合”的妥协感。

ITX 只有两根 DIMM 槽，加到 32GB 是可以，再往上好像就不好加了。我现在回帖用的就是 32GB RAM 的 ITX ，这还是几年前 DDR4 比较贵的时候买的，要不是没插槽了照现在这行情我早加到 64GB 然后各种 vmtouch ，tmpfs ，ARC 塞满了。当然好像是有单条 32GB 的，不过这就意味着我现在的条子就没用了，懒得折腾
追求极限体积的话散热也要妥协，我现在是下压式的，效果和噪音都没有塔式的好。
另外如果性价比是重要因素的话，ITX 和高性价比基本就不挂钩。

打算等疫情过去鸟枪换炮换 ATX 了 ...

一直不太习惯 VSCode 左边那个粗大的 Activity Bar ，太占地方了，从来都是关掉然后装 Activitus Bar 这个扩展代替，我觉得 Visual Studio 那种竖排文字就挺好
其实要论 UI 我最喜欢 Xcode 的。elementary 有个 Code 应用，抄的就很明显，虽然和大多数 elementary 应用一样，基本没啥用 ...

有可能是你刚好碰到了几个 React 的例子而已。就算是同一个大厂里面，不同的部门可能有的用 React ，有的用 Vue 。

当然不可否认 React 社区比 Vue 更繁荣一些，用的人会相对更多一些，不过 Vue 的社区体量也完全足够了。这个其实就是像鼠标有的人用罗技有的人用雷蛇，其实区别不大。

本来就没有负优化，“负优化”只是开发新版本时不重视非目标硬件性能的做法导致的副作用而已。

作者最近又在手撸编程语言 ...
博客： https://awesomekling.github.io/

很多这种场景用脚注会更易读，并且也更好玩

好玩在哪？这里有个极端的例子： https://mp.weixin.qq.com/s/KR7wG1Mtd5ng6wCcGv7ZUg? 手机厂商「见不得人」的小秘密，都隐藏在详情页的小字里[1]

其实不止赚钱的喜欢这么干，不赚钱的也喜欢，比如 https://github.com/travisdowns/travisdowns.github.io/commit/cb7ecd21a9c067ecff422339e9abc82058da899b#diff-df0b3d6b9752e1b0627d6ae9a6e74ef6a220b9273f32e390e2d0867210228af1L28 [2]

[1]: 我不喜欢发这个域名的链接，但是 iFanr 官网的那个版本貌似把最底下的灰色部分省略了，这就没有灵魂了
[2]: 原文在 https://travisdowns.github.io/blog/2020/01/17/avxfreq1.html ，不过这个 commit 把 L28 那段删了，又没有灵魂了 ...

这不是最可怕的，最可怕的是明明写着 route 结果读成了 router ...

联动 https://v2ex.com/t/854292

这要说的话肯定是“架构编程”最难，这个“架构编程”指的是“决定你的程序该干什么事情”，虽然程序也不一定是，甚至一般不是你写的，但是哪怕写得烂也没关系，这一层的东西直接决定了项目的前途。换句话说就是战略级别的“对人编程”。
不过这个一般是姓 C 的人考虑的事情，跟大多数人没啥关系。要说工程层面的话，我认为是“know-how”，先帝懂王普的时代，这个词经常出现在大明的新闻里，不知道还有没有人有印象。
各种领域的原理、公式、算法，这些写在教科书、论文里的东西，正常人只要肯下功夫，大多数都能搞懂。但是看完之后再用到 non-trivial 的项目里面经常会发现和书上写得不完全一样，这才是真傻眼的时候。
举个例子吧，比如前端做个页面效果，虽然做完交差了，但是自己看着总“差那么一点意思”，怎么折腾都调不好，虽然别人可能不会在意，但是事后想起来总有一种便秘的感觉。前端库很多，资料教程很多，你技术都掌握了，但是就 TM 差这么一点 ...

其实可能就是哪一组参数不太合适的问题，但是怎么定位到问题？我找到了之后又该怎么调？
类似的例子还有很多，比如为啥某某软件很流畅，某某就很卡；挑个手机经常会看到什么屏幕 /摄像头 /续航的“调校”，手机是高科技产品，那你 TM 从技术的角度给我解释下这个“调校”是啥；基础算法大家都会，项目里面的实际问题需要设计新算法该咋办；一个 ML 的项目，选啥模型，怎么调 ...
这个也不局限于软件领域，做个饭都有刀工、火候、调味的讲究，同一所学校，有的人平常看着普普通通考试必然前三，有的人天天做题成绩也就那样。不过情况都是一样的，同样的工具，别人的结果比你的更好，你还不得不服。

所以某些公司喜欢折腾什么“XXX 原班人马打造”——人家之前搞出来过的 XXX 大家都知道，都能抄，但就是抄不出那个“味儿”，偏偏最关键的就是那个“味儿”。这就是我对“know-how”的理解，写在书上的都不是最难的，没写上去的，或者没法写上去的才最难。

@ferock
我并没有认同 #42 ，主要是想表达“根据个人情况不同，不同的工具可以用于不同的用途，并没有通用的‘最适合’”这么一个观点，我想在这上面咱们应该是有共识的。

我倒是觉得 #3 从一开始就没有专门开回复的意义 :)

@ferock 我说的是“回复”里的“最”，主题里的“最”只有“最开始”“最后”“最新”三种用法，表示价值判断的，你依然是第一个。
我认为你在 #1 就有把你认为“终端用 win 或者 mac 才是最顺滑的”的个人经验套在别人身上的倾向。很明显楼主和 #3 都不同意这个看法。

你说
> 某一件事情，哪个舒服用哪个不就完了
现在问题是楼主大概不认为 Windows 能用舒服，虽然他并没有正面回答这个问题。#3 也不这么认为，虽然举的一堆“例子”很蹩脚。

再往后就掉进了
> 做技术的总可以想到一些办法解决问题，那这样扯就没底了。
的坑了
包括就算是基于 Windows 想办法解决 Docker 的问题，也大概率会涉及到一堆比较主观和个人的东西。

@ferock #41
我认为每个人的偏好和情况是不一样的，不能用个人的情况去硬套他人的情况
比如对我来说，“原生”的游戏就基本不是个事，但是 Windows 和 Mac 没了 perf_events 之类的东西倒要考虑一下，所以你的例子在我看来有点奇怪

> 你自己心里有 “最棒”，“只配” 满世界都是 “最棒”，“只配”
不如搜索一下回复里面的第一个“最”字出现在哪 ...

@ferock
> 不要和我提 dxvk 、Wine ，当然说的是原生！扯太多太浪费时间
来浪费下时间：为什么非要“原生”？

我感觉你的主要问题是“做业务做烦了”吧
然而底层也一堆奇葩 bug ...

找几个最近用 Linux 遇到的吧：
https://bugs.kde.org/show_bug.cgi?id=377901 KDE 桌面环境在开机 49 天后准时坏掉，窗口只能切换不能移动，因为一个 timestamp 溢出了
https://github.com/ggreer/the_silver_searcher/issues/168 ag 搜啥都搜不出来，原因是我搜的 git 仓库在 .gitignore 里用了 ! pattern ，然而 ag 不支持（这个到现在居然还没 fix ，换 rg 了）
https://github.com/openzfs/zfs/issues/12971 ZFS 文件系统下的文件在新版 Linux 内核下调用 splice 和 sendfile 等系统调用会报 EINVAL ，原因大概是新版内核改了某个内部 API 的名字

我感觉很多事情并没有本质性的变化
不过一般不会周末丁你一下就是了，这算是个好处