出口转内销了属于是

原来事 Asahi Linux 的开发者

新的冷知识“I can get these stats because the NVMe controller is integrated into the SoC and 'drive cache' is just normal memory (it's unified just like GPU memory), and Apple have very good instrumentation of things like DRAM bandwidth utilization from different SoC agents.”

"If you run a durable database on an M1 today, try a cheap flash drive."这下金士顿了

RTS 群里的人表示好像好像更像 4X ...

理论上当然可行，但是你在什么场景下用呢，比如你要放 Linux 服务器上跑那可能有些库就没法用

> 那这么说来中望 CAD 2022 原生版是假的。我最近还经常用它对比测试移植的 Windows CAD 相关软件呢。
还真不知道 Linux 居然真的有能用的商业 CAD 软件，涨姿势了

> 你开心就好，毕竟喷 Linux 开发者不懂产品已经政治正确了。
是啊，你看现在居然都在做 Linux 软件，这个世界还能不能好了。

对我这个已经多年不搞前端的人来说，楼主的文章提供了 React 状态管理现状不错的 overview 。

虽然 Web 前端暂时怎么不搞了，但广义的前端还是一直在关注的。补充一下，楼主“自创”的“贪婪更新”和“惰性更新”已经是有点年头的概念了，这东西一般叫“incremental computation”。所以大概可以叫“增量渲染”和“全量重渲染”。

Incremental Computation 的关键是构建一个 dependency graph ，当数据发生改变时程序只会运行其中 dirty 的部分。它的用途很广泛，是指令乱序执行、编译器优化、Spreadsheet 、包管理器、构建系统以及许多类似的任务系统的核心。

类似的方法在其他 UI 框架中早就有应用，比如 Cocoa 有 KVO ，WPF 有 INotifyPropertyChanged ，GTK 和 Qt 等框架也有一点 MVC 的意思，他们的列表会有个 model ，接受变化的通知。
但是可能是由于建立在 imperative 语言的基础上，这些较传统的框架并不适合操作复杂的 dependency graph 。给我的感觉是，它们“incremental”的地方主要集中在“界面 - 代码的接口”上，使用简单的数据绑定实现。界面本身不是 incremental 的，incremental 的方法也很难渗透到代码逻辑里面。数据绑定可以解决一些数据和简单属性的更新，但是“UI 操作”依然需要额外手写，而这一过程依然非常麻烦并且容易出错。

React 的流行普及了一种新方法，React 鼓励用户尽可能用数据表示 UI ，淘汰“UI 操作”的概念，以“数据变换”来取代。这并不是性能上最优的方式，原始的 React 并不是很重视 incremental ，基本仅仅体现在一个偶尔用一下的 shouldComponentUpdate 和 virtual DOM diffing 上。后者基本上也就相当于“React - Renderer 接口”，不用 shouldComponentUpdate 的话，React 里面这一层其实是有意设计得 brute force 的，但是确实很大程度上简化了问题。

React 这一步的一个副作用是，由于数据变换可以以更简单的纯函数来表示，现在 UI 全链路都可以 incremental 了。我不知道这一点当年 React 的设计者们有没有想到，但是后来者有不少想到了。更新的框架不少都是以 Declarative + Incremental 的思路设计的。比如 Web 这里比较典型的是 Svelte ，作为 React 竞品直接说 virtual DOM diffing “eat into your frame budget and tax the garbage collector”，而 SwiftUI 里面干脆就有个 dependency graph 模块，React 的状态管理也在往这个方向走。

上面有人说原始 React 更加“函数式”，实际上搞 incremental 的人不少也搞 FP——在一个 dependency graph 中，明确能具有“状态”的基本只有叶子节点，从叶子节点到最后要求的值，依然是一个纯函数。非要说的话只能说一个是比较“粗放”的函数式，一个是比较“精细”的函数式。要说起来的话 FB （现在应该叫 Meta ？）粗放不是第一次了，FB 用 OCaml 是吧？ OCaml 自己是不支持共享内存并行的（即将发布的 OCaml 5.0 将会开始完善这一能力），结果 FB 自己 hack 出来一个库给自己项目用 ...
我其实是从 Jane Street 那边了解的 Incremental Computation ，在 OCaml 社区这是与 FB 齐名的公司。他们自己做了个库就叫 Incremental ，需要注意的是在这个下面他们还自己实现了一套 Virtual DOM 解决 Incremental 不太好处理的问题，也就是说他们是两个都在用，和现在 React 有点类似。关于这个他们发了一堆的博客：
blog.janestreet.com/introducing-incremental Jane Street Tech Blog - Introducing Incremental
blog.janestreet.com/incrementality-and-the-web Jane Street Tech Blog - Incremental computation and the web
blog.janestreet.com/self-adjusting-dom Jane Street Tech Blog - Self Adjusting DOM
blog.janestreet.com/self-adjusting-dom-and-diffable-data Jane Street Tech Blog - Self Adjusting DOM and Diffable Data
blog.janestreet.com/seven-implementations-of-incremental Jane Street Tech Blog - Seven Implementations of Incremental

这写的是代码还是大字报啊
以后也别 hello world 了，直接上手一个炮打白宫

hype-v 可真的太典了

另外还真别嫌 Shapr3D 贵，你看看竞品都啥价格。
便宜 /免费的的可以试试 Fusion 360 ，MoI3D 。

两者其实不是一个定位的，Blender 是做游戏、可视化和 VFX 的，Shapr3D 偏 CAD ，是做量产的实物的。

典中典面函数 ...
不过楼主思路是对的，各种花样折腾来折腾去效果和传参是一样的

推荐两个历史类的英文 podcast ，Patrick Wyman 主讲的 Fall of Rome 和 Tides of History ，有广告。
前者讲古典时代晚期西罗马帝国的崩溃（先落个泪），也是这老哥的 PhD 研究方向。讨论了西罗马帝国为何灭亡，东罗马帝国为何存续，几个 barbarian kingdom 的来历和特点，在这一过程中社会产生了怎样的变化。
后者分两季，第一季讲从奥斯曼的崛起（又要落泪了）到勒班陀之战的 Late Medieval 和 Early Modern Period 的欧洲，正在进行中的第二季则是 Prehistory ，从人类的起源讲到 Late Bronze Age Collapse 。
他的特点是喜欢引用一些“最新”的书和 paper ，也有很多是请的教授做相关话题的 interview 。很多问题并没有定论，他会列出有哪些假说，然后选择他偏好的那一种展开。

我听下来最大的收获是“Linear ideas about the natural evolution of societies over time are simply wrong.”，用程序员的语言来说，对历史的认识从一个“List”变成了“Graph”。比如讲 hunter-gatherer 群体，他会给你讲不存在理想的，伟光正的模型，只有具体的人适应具体的环境，而 foraging 和 farming 也并不是互斥的策略。和很多人一样，他把“文明”拆解为城市、阶级、社会分工、文字、国家等元素，但是又强调这些元素并不是全都会出现。讲阿拉里克洗劫罗马时，他更多是在讲罗方如何“导致”了这一事件的发生，而非简单的“蛮族入侵”视角。

这种现象的另一个体现是，最实用的 Linux 社区往往同样是以非 Linux 的角度切入的。比如搜索引擎很有用，但是哪个搜索引擎很“Linux”？ StackExchange 和 Reddit 都很有用，哪个又 Linux 了？

我倒是有一个网站非常接近楼主想要的东西，但却又能很真实地说明 Linux 的现状，楼主可能还很熟悉，它就是（当当当当~） store.steampowered.com 。这个网站里面有各个平台的软件（别笑，Steam 真的有“Software”区），有类别，有 Tag ，有详细的介绍，甚至还有图片和视频，个性推荐，用户评价。推荐搭配 steamdb.info 使用。这个网站甚至能让你把一些 Windows “独占”的“软件”放到 Linux 上跑，而 protondb.com 会告诉你哪些能，哪些不能，可能会出现什么问题，出现问题能不能解决，该怎么解决。可以说非常接近楼主的想像了，唯一的缺点大概就是会定期伤害你的肢体。

Steam 对 Linux 支持相对来说非常好，以至于现在几乎成为了想让 Linux Desktop 走向“主流”那部分人的一根救命稻草。但是它又是那么的“不 Linux”——它本身和里面的大部分“软件”都不开源，收不少税，它折腾了半天 Proton ，就为了 Linux 能和 Windows 一样跑一些特定的用 DirectX （而不是 Vulkan ）写的 exe ，它的整个模式就基本是从 App Store 照搬过来的 ... 这些倒不是最关键的，最关键的是它特么的在积极地“反碎片化”——Linux 版本的 Steam 会带一个叫“Steam Runtime”的东西，等于给你弄了个容器，不管你跑的是什么 Linux ，在 Steam 里面点“Launch”时都统一到这个容器下面的环境。你在 ProtonDB 里面看到的那些报告，也全是建立在这个 Runtime 和统一的，固定的 Proton 版本上的。
而如果不这么做会有什么问题？我这个假期正好就遇到了，更新玩系统之后突然就无法启动，还好找到了有类似的问题： https://github.com/ValveSoftware/steam-for-linux/issues/5014 。
解决方案居然是要安装一个 lib32-libnm 的包？！我到现在没想明白到底出了啥问题。

我现在觉得绝大多数 Linux 发行版还能统一到 ELF 作为可执行文件格式上简直是个奇迹。

作为同样日常主力使用 Linux 的用户，我最近正好没事的时候会关注一下 Linux Desktop 相关的东西，主要是 G 胖又准备出个新玩具，LTT 最近也出了这么一个 Linux Daily Driver 系列视频 https://www.youtube.com/watch?v=0506yDSgU7M （有人说 LTT 越来越水，但是就这个项目和最近的新 Lab 来说，说他们的内容更“两极分化”可能更合适），而国内也有政府机关在推行基于 Linux 的国产桌面系统的新闻。国外 Linux 社区有一些讨论（你问国内 Linux 社区？国内没有 Linux 社区），楼主这个主题也反应出了 Linux 圈子里面经常被讨论的一些问题：

> 如何知道哪些软件支持 linux 平台，有没有类似 windows 平台下的软件下载站？？？或者查询站，知道哪个软件有支持 LINUX 平台的？？

首先，严格来说不存在“Linux 平台”这么一个东西，如果用二分查找的思想来 partition “平台”的话，那就是 硬件-内核-用户软件，Linux 只管中间的内核，它可以跑在很多硬件上，也可以搭配不同的用户态软件环境。换句话说 Linux 只构成平台的一部分，没有真正的“Linux 平台”。

> 如果有人或者网站能提供一个 catalog ，安装前稍稍花点时间调查一番，可以节省新手很多精力。有人冷嘲热讽说用搜索引擎，问题是我在问这个问题之前肯定搜索过类似的问题，时间也是金钱。我有一次在安装一个虚拟机的时候，出现了无数的错误代码和依赖库。百度搜出来的问题要么版本太老，要么搜出来的结果差强人意。

当然我们可以假设楼主所说的“Linux 平台”指的是“跑在 x86 PC 上的以 Linux 为内核的兼容 POSIX 标准的系统”，因为这个最接近 Windows 的角色。但这依然不能称为单一的一个“平台”，变量太多了，直接跑在硬件上的还是虚拟机里的还是容器里的？内核版本是啥？ Debian 还是 RHEL ？ systemd 还是 SysV init ？ Python 2 还是 Python 3 ？ glibc 还是 musl ？ dash 还是 bash ？要是涉及到 GUI 就更离谱了。
你知道学 Linux 该学命令行，但不知道碎片化是 Linux 生态的基本特征。这种碎片化从硬件到内核再到基础软件再到用户软件最后到使用场景，每一个层级都存在，如同分形一般。要以一个普通 Windows 用户的视角来看那大概只有一句话：庙小妖风大，池浅王八多。
楼主如果能理解这一点，那我想也不难理解楼主想要的真空中的球形软件网站在 Linux 世界中不可能存在。楼主一方面想要学 Linux ，另一方面却又举了 App Store 这个典型的“不 Linux”的例子，本来就是个很矛盾的事情。Linux 圈其实不缺技术，但是至少直到现在为止，一直很缺少所谓“集中力量办大事”的能力。这方面的能力缺失主要在非关键领域上，比如 Linux 内核大家都能达成共识很关键，所以总体比较健康，而至于楼主说的软件站，只能说很不关键。
所以只要楼主使用的软件数量超过了一个并不高的阈值，数学上就必然会遇到“无数的错误代码和依赖库”，有时可以通过搜索引擎简单解决，但是数量再高一点就必然会遇到搜索引擎无法轻易解决的问题 ... 并且 Linux 上必然无法存在单一的类似 App Store 的傻瓜解决方案，哪怕是基于社区的——因为必然会有多个，并且其中的每一个都必然会是 suboptimal 的。
这就是楼上很多人劝你放弃的根本逻辑。

这东西能简单能复杂，看你想要简单的还是要麻烦的
randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition Comparing Floating Point Numbers, 2012 Edition | Random ASCII – tech blog of Bruce Dawson

不超频可以，超频有点够呛。
那个什么最大功耗是官方预设值，你超频的话是不按那个来的。12900K 超频能跑到三四百瓦，你细品。

@kkocdko #14 这个说到点子上了，现在大多数主流 IM 是不认同用户对自己数据的所有权的，也不会重视用户对数据的备份、检索、管理等功能。
另一个因素是移动设备和笔记本取代桌面 PC 成为主流，实现以上功能有一定技术上的限制。

十年前 Windows 版的 QQ 是可以把聊天记录导出为 mht 文件的（现在还能不能不知道，很久不用 Windows QQ 了），可以直接处理和检索。
现在哪怕 Telegram 云端保存了记录，但是至少官方客户端是不提供导出到本地的功能的（其实桌面客户端有，但量一大导出时间就很长，基本不能用）。IM 官方云端储存不是合适的解决方案，云端的数据不是你的，因为你不能直接访问它的数据库写条件查询，做正则匹配，只能在手机上不断擦玻璃加载，然后用眼强行模式识别。

但是只要移动设备还是主流，普及较复杂的聊天记录管理功能的条件就不成熟——因为移动设备和笔记本通常只有一个持久存储器，并且一般是 NAND Flash ，单价较贵。而聊天记录的特性决定了它的体积必然是随时间单调递增的，本地只能存储一部分。并且由于缺乏冗余和备份，安全性是不如云端的。大多数只使用移动设备和笔记本的人根本就没有可以导出聊天记录的地方（还有一堆上了 NAS 的仍然在把 RAID 当备份手段），于是就只能“每半年清空一次应用数据”。但凡有个像样的 4TB 以上的 HDD ，以正常人聊天记录的规模根本就不是问题。
对于有硬件条件的人，理论上可以通过 IM 的 API 手动获取并备份，不过目前这个也存在若干问题，这一行为要求你能以一个正常用户，也就是你日常使用的账户的身份使用 API ，不是 Bot ，Bot 帐号无法获取到你个人帐号的数据，所以你的备份程序事实上成为了一个“Bot 控制的使用人类帐号的第三方客户端”，在目前的环境下这是个非常异端的事情。首先一些 IM 没有 API ，你私自用是违反 ToS ，然后一些 IM 虽然有 API 但不鼓励第三方客户端，有些 IM 要求 Bot 必须使用专用的 Bot 帐号和 Bot API 。最后这一行为获取到的聊天记录不具备法律效力，因为很容易伪造（或许你可以把和服务器的握手包啥的都记录下来 ...）。
（最后还有个让人抓狂的事情，有些软件有登录限制，比如 QQ 同一个帐号移动端只能登录一个设备，桌面端只能登录一个设备，就是说如果你用 Android API 做这个事情的话，那你的 QQ App 就没法用了 ...（小而美好像也有，不过我不怎么用））

你可以换一种思路：键盘是 iPad 的一部分，一个“完整”的 iPad 本来就是包含各种配件的。你能单独买机器则是一种价格歧视策略。
大多数电子产品本来就没法升级，就好像你不能把老手机的屏幕换到新手机上。