Linus 可能对潜水更有兴趣

> cli 的各种功能是堆出来的
不仅限于 Git ，可以参考下这个 https://danluu.com/cli-complexity The growth of command line options, 1979-Present

> 实际上，工具越出名，越底层，改进的空间越小。

其实我觉得抛开原 Git CLI 那一套东西，有没有一种可能，我是说，有没有一种可能，包装出适用于特定工作流的工具，无论是 CLI 还是 GUI 。可能没法很好兼容 GitHub 等现有工具，但是至少做到单独使用比较流畅。类似的想法楼上也有，但是我觉得目前大多数基于 Git 的工具，都还是需要对 Git 的底层原理有一定理解，最后导致多少还是不得不尝尝 Git CLI 的美味。如果只是针对特定工作流做，或许能把原理也给简化掉。

不要 assume“时代在进步”，很多东西不倒车已经是不错的了。
SSD 虽然快，但是不同 SSD 的速度也是参差不齐（特别是“便宜”的）。
软件就更别提了，放眼现在的主流文件系统，除了 APFS 之外，所有其他项目的底子都是上古时代的。APFS 倒是够“新”，所以 APFS 有个功能叫“Fast Directory Sizing”，可以直接从文件系统层获得文件夹的大小，不过就连这个好像也是需要手动启用，并且 Finder 自己也没有用上。
而且现在文件系统的痛点不是大文件，而是大量小文件。经过软件抽象后，SSD 把大量小文件操作的速度提升了 1-3 个数量级，但是还不够。我 du 了一下 home 目录下的几个大文件夹，大概需要的时间在 5s-30s 以内。Windows 下用 explorer 看 C:\Windows 文件夹属性，统计大小花了 2 分 15 秒，换了一台 Windows 需要大概 1 分钟。无论是十秒钟还是一分钟都不是 UI 上能接受的量级。当然这么巨大的文件夹是少数（虽然我每次打开 home 或者 C:\ 都会看到 ...），但是问题在于那么程序呐，就都不知道，自己就不可以预料，一个文件夹到底有多大，需要花多长时间，这是个 O(n) 而非 O(1) 的过程。
可以通过缓存把这个过程变成 O(1) 的，比如 Finder 会把算好的文件大小放到 .DS_Store 里面去，不过既然涉及缓存，就必然会涉及到缓存如何更新的问题，这已经被证明是计算机科学中两大最困难的问题之一。比如 Finder 就没有处理好（我也不指望它能处理好）——我现在能看到有很多里面有一堆文件的文件夹大小显示 "Zero byte"，但是这个功能依然是我认为 Finder 是最好的文件管理器之一的最重要原因之一。Finder 并不是唯一一个可以直接显示文件夹大小的本地文件管理器，KDE 套件的 Konqueror 也可以，这货保持了 KDE 的一贯作风，把这个功能藏在了设置深处，但是它是有限制的，如果目录嵌套超过一定的层级就不会显示，而这个阈值可以调整，这倒也是 KDE 的一贯作风。至于 Konqueror 有没有缓存就不清楚了。Konqueror 还有很多有趣的设计，比如和上古时期的 Windows 一样，把文件管理器和浏览器放在一块，它的“收藏夹”菜单（虽然现在貌似流行叫“书签”，但是作为从上古 Windows 玩过来的我还是更喜欢“收藏夹”）既可以放 HTTP URL ，也可以放本地文件夹。可惜这东西现在好像已经基本是被抛弃的状态。还有个比较勉强的是 Midnight Commander ，这货是个 TUI 界面，选中文件夹按 <C-Space> 会现场计算大小并显示在 size 那一列里，多选可以批量做，但是切出去这个信息就没了。

Konqueror 我倒是一般不会用，我日常用的还是 Finder 和 Dolphin ，对比之下发现 Finder 这个功能不仅 bug 多，还有额外的一些代价——比如在访问 HDD （包括使用 HDD 的 NAS ）时，由于 Finder 一直在试图统计文件夹大小（部分情况还会涉及到生成媒体预览图），而 HDD 现在作为仓库盘一般什么乱七八糟的东西都有，就会让 HDD 一直处于忙的状态，很吵，Dolphin 就十分安静。额外生成的 .DS_Store 文件也会有麻烦——做个 Git 仓库，打个压缩包之类的都会掺合进来（ OS X 有个开关可以禁止在网络磁盘上生成 .DS_Store ，但是这不解决根本问题）。另外如果是个移动设备，统计文件夹大小占用的额外资源可能会增大耗电量。从这些角度来说，认为“始终统计文件夹大小”在现行软件栈中有百利而无一害的大概跟喜欢用 Electron 的是一种生物，不是蠢就是坏。

从另一个角度来说，统计文件夹大小真的是那么常用的需求么？对于服务器或者大多数命令行场景来说，一般不是，服务器要想干这个有 du 。如果按照现有体系，O(n) 遍历统计，就意味着你随手敲一个 ls ，就有一定机率需要等 10-20 秒，盲盒在 70 年代被提早发明了！如果把文件夹大小存在文件系统里，那每一次 IO 操作都会附带更新这个信息的开销，而如果这个信息只是偶尔使用，很明显不值得。所以为服务器设计的软件肯定不会考虑这个问题。这个东西在消费者那可能用处稍微多一点，但也不是那么多。要想看谁占磁盘多有 QDirStat 这样的专门软件，并不一定非要文件管理器或文件系统来兼职。一个好用的磁盘占用分析工具实现上可能会涉及到一些优化技巧，不是简单的递归遍历能解决的。作为一个 Linux 用户，从各方面平衡的角度来说，我还是更偏向于 Konqueror 那样的做法，成本大的功能默认不打开，打开之后可以自定义。

再往远处说，“文件”这个抽象，过时了！淘汰了！（ https://zhihu.com/question/472997775 ）上面的讨论已经很清楚了，“文件系统”以及 OS 的文件操作 API ，既需要处理少量大文件也需要处理大量小文件，既包含 sysfs ，也包含 RAM Disk ，Optane ，SSD ，还包含 HDD ，网络，和 5.25 寸软盘。而现在一般用户还有多少机会直接和“文件”打交道呢？ iOS 从发布时就直接隔开了不同 App 的文件存储，用户在笔记软件里的“笔记”也是直接在相关的软件里面访问的，Office 现在也在往云端发展，小而美倒是好像能把聊天记录备份成文件，不过也不能直接看，而且相信我如果小而美有个网盘业务的话，大概不会允许你直接往本地备份。
抽象总是有代价的，专门的需求就需要抛开通用的抽象，用专用的工具解决，比如做 Web 服务器用的是数据库，不是直接把数据 write 到文件里面。

当然这是本地的问题，至于为啥云端的东西不给你看，那答案倒是很简单，因为这些产品和“小而美”的设计思路，精神内核都是高度一致的，都是把用户当 ...

比起这个，我觉得给 Finder 和 Explorer 加上分屏功能倒是更有用。

函数不需要复制啊，一个东西需要区分“复制”和“引用”，是因为这东西可以修改，或者需要管理内存。函数没法修改，内存管理 JS 帮你干了，就不需要复制了。

A 站这评测早就说了，得有一个半月了 https://www.anandtech.com/show/17024/apple-m1-max-performance-review/2

TIL star-history.com

这些函数一般是软件中使用数值算法实现的（有些架构连乘除都软件实现），不同的算法可以有不同的结果，类似的算法，精度要求不同结果也可以不同。但是好像标准上没有硬性要求。
浮点计算要做到一致还是不那么简单的事情。

你用到了 sin 、cos 、sqrt 等库函数，这些函数 Python 应该是调 C 库对应的函数。C 库是平台相关的。

维基那张图上不仅有差半个小时的时区，还有差四分之三个小时的 ...

现在一般都喜欢看这个 https://www.backblaze.com/b2/hard-drive-test-data.html

主题说放到 UI 里面，我不是很清楚具体是怎么一个用法
比如你做图标的话就直接调好参数渲出来就行了，我头像就是个 3D 模型渲染图。
理论上你还可以转成 SVG ，不过没试过。

直接在现有的 UI 里面渲染 3D 模型，除了 DCC 和游戏之外我能想到的就只有用于作为“主展示区”一种用途，比如电商预览商品，或者苹果之前搞得什么 Memoji （当然还有更冷门的 3D UI 和 AR 之类的，那是另一个话题）。

首先你要了解实时渲染一个模型，并且渲染得好看，不是那么容易的事情。Cycles 渲染出来可以比较精致，但是那需要大量的计算量堆起来，游戏可以做得看上去真实，但是需要使用各种乱七八糟的算法+稍微少一点的算力，不用现成的渲染引擎的话，灯光、阴影、反射、全局照明、表面凹凸、动画之类的都需要逐个实现（而现成的渲染引擎一般不小）。
所以如果可以的话用 2D 图（或者 2D 图序列）要比实时渲染 3D 好做，而且处理 2D 图更方便，更灵活。你在电影和游戏里面看到的许多东西其实不是模型渲染出来的，是后期合成加上去的。简单裸写实时渲染能写到什么程度，你可以以“opengl beginner demo”为关键字搜索。

然后是把模型导出成一个文件，一般每个 DCC 有自己的文件格式，比如 Blender 是 .blend ，Maya 是 .ma 和 .mb 。这种文件一般没法直接用，因为他是根据 DCC 的需求来设计的。业界有若干种比较通用的格式用来 interoperate：Wavefront OBJ ，非常古老又非常简单的一种格式，因为完全是文本，很简单就能写个 parser 。3DS ，老 3D Studio 的格式，也很老（从这货单个 mesh 限制 65536 面你就大概能民白发生了什么 ...）。FBX ，后来自动麻将桌重新弄来的一个格式，所有自动麻将桌产品都支持，实际上非自动麻将桌软件也支持。COLLADA 和 glTF ，俩 Khronos 的开放标准，我没咋用过，具体好不好用要看软件支持情况。Alembic ，VFX 现在的业界标准。
不过这些主要是作为转换的中间格式，渲染引擎可能会直接支持这种中间格式，也可能有自己的专有格式。这里的问题其实主要还是 DCC 和渲染引擎支持的功能可能是完全不同的，两边的语义并不对应，而中间格式作为一个类似 LSP 一样的角色更没办法完美耦合这两者。

最后是渲染引擎。现在主要实用中是使用 GPU 渲染（ CPU 渲染并不是没有用，据说 ZBrush 就是 CPU 渲染）。GPU 渲染依赖于使用特定的 API 调用 GPU 中的相关专用硬件（当然理论上你也可以使用 GPGPU 来模拟这一过程，不过这依然是非主流做法，能写 CPU 渲染器或者 GPGPU 渲染器的大概不会问这个问题）。目前图形 API 发展大致可以分成三个阶段，第一个阶段是完全固定的原始阶段，只能按照硬件设定好的方式去渲染，程序员只能调几个参数；第二阶段是从 D3D8 ，GL1.4 开始引入 shader 之后的可编程阶段，程序员可以对 GPU 编程来自定义渲染过程，大大增强了灵活性，并且派生出很多意想不到的应用（包括最原始的 GPGPU ）；第三阶段是从 Mantle 开始，以 D3D12 ，Vulkan 和 Metal 为代表的将更多 GPU 底层细节开放给开发者，并全面支持多线程的低开销阶段，但是写起来就跟汇编一样，太麻烦。

从目前情况来看，第一阶段的已经彻底淘汰，第二阶段的总体支持较好，第三阶段一些老硬件和老软件不支持，并且由于比较底层，需要折腾的东西比较多。所以现在入门的话推荐从第二阶段开始，需要注意的是如果不考虑性能和具体实现的坑的话，理论上第二阶段和第三阶段 API 的渲染能力，以及不同厂商 API 的能力是一样的，只是调的接口不太一样，因为算法是你自己写的，所以出来的结果只取决于你程序怎么写。

楼主问这三个平台有没有通用的技术，首先仨平台的开发语言就不一样，Android 和 iOS 好歹还都能用 C/C++，Web 直接锁死了 JavaScript 。API 支持方面，Android 可以支持 GLES 和 Vulkan ，但是鉴于 Android 大区优秀的设备和驱动支持情况，Vulkan 貌似现在总体还不是很稳定，iOS 也支持 GLES ，不过是 deprecate 状态，现在推荐 Metal ，Web 是基于 GLES2 的 WebGL ，这个属于第二代 API 中比较老的一种了，还有比较新的基于 GLES3 的 WebGL2 ，这个其实依然比较老 ... 但是最近两年才得到全面支持，对应第三代 API 的 WebGPU 现在貌似有安全问题难产，现在 Web 连做 GPGPU 都得用十多年前的老 trick ...
所以 API 层面大概能统一到 GLES2 或者 GLES3 这个层面，语言还是得自己想办法。由于很多程序需要支持很多硬件和软件，而不同的 API 能力是差不多的，为了解决 API 支持问题，一般会做一个通用的接口将他们抽象掉，应用不依赖于底层 API 。比如 bgfx 就声称支持各种平台和各种 API （在 Web 使用 Emscripten 解决）。另外个别情况下还会涉及到的一种做法是不同 API 之间互相转换，比如 Apple 强推 Metal 不做 Vulkan 支持，有个 MoltenVK 项目是用 Metal 实现 Vulkan API 。这个 Linux 和开放社区玩得最欢，有用 D3D/Vulkan/Metal 实现 GLES 的 ANGLE ，用 Vulkan 实现 GL 的 Zink ，Vulkan 实现 D3D 的 DXVK 和 vkd3d 。微软还给 WSL 搞了个 D3D12 实现。
当然，这些 API ，无论是哪个阶段，都属于用户所能直接接触的最底层 API （注意 Console 不包含在内，Console 是单独的一个故事），总是非常底层的，也就是不存在调一个函数就帮你把模型渲染出来这种事情。所以再上层还会做一个抽象，实现类似“调一个函数把模型渲染出来”的效果（实际依然没那么简单，渲染一个模型需要考虑投影、灯光、材质、半透明等各种问题，只是这些问题直接用底层 API 来处理只会更麻烦），这才有 Ogre ，OpenSceneGraph ，Three.js 等。
Unity 之类的游戏引擎是比较高层的抽象，因为一般“游戏”是一种各方面都比较特殊的应用，就连 iOS App Store 对游戏也有不同的审核要求。特别是公开可用的游戏引擎，大多会有广泛的平台支持需求，以及 Console 支持的需求（不过相关的东西应该要 NDA ）。in-house 的则是各有各的需求。一般游戏引擎会做成“框架”式的东西，也就是他会直接接管你的整个程序，想要把一个游戏引擎和另外的应用集成起来可能成本会比较高。我认为可能的 sweet spot 还是在上一层，也就是渲染引擎上。

@villivateur Code Review 这个过程本身和 VCS 工具，或者任何的外部工具没有必然关系啊 ... 就是你把一个 patch （或一组 patch ） share 给一组人，然后一起讨论改进的过程（也可以有机器跑一些自动化的流程），工具只是帮助 streamline 这个过程

要说工具的话，https://en.wikipedia.org/wiki/List_of_tools_for_code_review 这里面不是有不少工具声称支持 SVN 。我知道的里面 Phabricator 前段时间停止开发了，然而一些知名开源项目例如 Blender 和 LLVM 之类的目前还是在用，当然这俩现在都用 Git ，但是比如 LLVM 也是最近才完全用 Git ，之前好像有段时间是 Git 和 SVN 并用，再之前应该是 SVN 。这个上古 patch https://reviews.llvm.org/rL237708 现在打开 URL 会被 301 到一个 Git 的 Commit ID ，但是 commit message 还保留着 SVN 的 revision number 。Review Board 现在还在开发，应该也比较靠谱。然后我也是刚发现这页面里面甚至还有 GvR 的一个副业 Rietveld ，我没用过这东西，但是我用过它的 fork Gerrit （只支持 Git ），AOSP 和其他的一票 Google 项目好像也在用。

人家 Linux Kernel 和 GCC 用 mailing list 都好好的 ...

Windows 不也有这问题，也没折腾什么容器之类的，都有“绿色软件”之类的，搞一个猴版不就行了。我也用 RHEL ，不过没 root 不好折腾，解决方案：依赖一个一个下下来，一个一个编译，手动打一份“包”，哪台机器要用就解压到哪。
无非就是 Windows 东西都给你编译好了，Linux 需要你自己去编译。

大部分软件还好，依赖就这么多。个别巨型项目如浏览器内核和游戏引擎会涉及巨量依赖，不过还好我不搞这个（浏览器内核一般做得都很现代很炫酷很时髦，依赖需要你自己解决。游戏引擎大多不属于开源生态圈，比较实在，人家都直接把依赖的 binary 放 repo 里面的 ...）。

说起这个，我有个老机器，用老 Chrome ，开 steamcommunity.com 很卡。看了下发现只要我一动页面，整个网页都会重绘，CSS 把背景图关了就好了

简单，不就是摆 pose 么，把墙挖个洞，放个人进去摆就行了。

代码检视是什么奇葩翻译，还是说你想说的其实是 Code Review ？
没用过 SVN ，SVN 不能做 review 么？

另外 ZFS 在性能方面的 story 我一直不是很清楚，特别是在 NVMe 设备上的表现。可能可以做到比较好的性能，但是需要专门去调整。我没这本事，所以如果对性能有要求的话我不会用 ZFS 。

RAID 是为了提高可用性，备份是为了数据安全。

而且 Mac 逐渐 Apple Silicon 化之后，长期 x86 的 macOS 怕不是会变成比 GNUstep 还拉跨的东西
我现在就等着哪个秀儿把 Houdini 用在 macOS 上

Arch Linux 用户，个人项目需要，现在后台就开着一个 OSX-KVM 的 Bug Sur （其实还有一个 Win10 ，直接占掉我一半内存）

如果是偶尔用用或者是只用 CLI 跑测试那还凑合，因为 GPU 是软件模拟的，GUI 使用体验并不好。最明显的是最小化或恢复窗口的时候的特效根本渲染不出来，本来这个我也无所谓的，问题是他直接会把 GUI 卡住五秒，鼠标指针都不能动，而且还不知道如何禁用。这个大概是根本没有测试过这种情况，除此之外应该说老 OS X 底子还在，GUI 大多数的表现其实都是好于预期的，Launchpad ，Mission Control 之类的都没有明显问题，当然不管什么地方的帧率肯定都是比较怀旧的（和你分辨率也有关系，分辨率高了照样卡得不能用）。

大概半年前试过给一个 USB port 连 iOS 设备，未成功，可能是要单独 passthrough 一个 USB Controller 才可以。