算是见识了 2200 >> 4000 ，2900 >> 6000 了
这又一次佐证了我的理论：Apple 应该早日收购 Sony ，这样 Apple 不等式和神秘 SSD 强强联合，一定能获得地球上最好的 SSD 体验！

@czfy #5 这三个但凡有一个在使用范围内就应该反思自己为什么要买 Mac 了。M1 Ultra 的渲染速度大概是小于 3050 Laptop 大于 2050 的水平（这已经是在 Blender 适配它之后了，以前更是惨不忍睹），而游戏和炼丹别说速度了，能不能用都是个问题

@zhaoxin #23 Steam 分成 30%，App Store 也是 30%， 所以 Apple 的 30%小于 Steam 的 30%？另外生态这么好，iOS 上的原神这么火，想必 Mac 用户一定早就玩上流畅的原神了吧？

@1sm23 #15 从 2017 年发售开始（配合以 Bloomberg 为代表的媒体高频率编造的 fake news ）各种游戏论坛里面月月都有人问 Switch 是不是马上要出下一代了现在买这一代是不是很亏，可比那些年年都是过渡品的厉害多了：）

任选一个 Wacom EMR （或者专利过期后仿制的）设备。
其他的都是各种风味的屎，比如 Apple Pencil 就是一个手感极差的东西（然后我听说它在这类设备中已经算好的了，简直难以想象其他的要烂到什么程度……

@felixcode 怎么没有……多逛逛 a9 ，就能看到很多长篇大论证明为什么索尼是对的折扣价买会员活该是二等公民，然后昨天索尼悄悄改回去之后有的在装死，有的真心相信是技术故障，有的开始夸索尼知错就改丧事喜办，有的忙着肃反捉内奸，相当精彩
（另外价格只是一部分，升级会员必须把剩余时间全升级和见了鬼的游戏库（宣传的四百多款是 PS4/5 版本单算，不同语言单算的，还有离谱的 Day1 出库

PS 玩家的神经病浓度确实远高于另外两个平台的用户（想要阿卡姆一日游可以自行打开 bbs.a9vg.com ）
所以我真的很想看 Apple 收购 SIE ，这样就能见证人类历史上第一次两个大型宗教合并的过程了

@pastor 你往上翻一下#88 ，我在那里解释了为什么我管它叫 list_head （以及最大的问题并不是它叫什么，而是 target 因为 non-owning 的性质不应该用同样的类型）和为什么后来我觉得这个强制转换不是 UB 。
首先最快速验证正确性的话……你可以丢进 compiler explorer 里面看汇编。gcc 整蛊就不说了（在那个时候我这个版本生成更短的汇编，而主楼那个写法不知道为什么看起来循环被手动展开了一层），在 msvc 和 clang 下面都会生成跟主楼的写法一模一样的汇编。当然，编译语言不是实验科学，生成汇编一样也不一定语义上正确，所以还需要再解释一下这里在干什么：你不要想着谁是几级指针这种事，这里做的是把指向一个 struct 第一个元素的指针转化成了指向这个 struct 本身的指针，这个是 C/C++标准明确允许的指针转换，所以我才刻意把 next 放在 value 前面，并不是运气好，所有符合标准的编译器都会保证它是对的。在转换后我对那个指针的唯一用法是使用它所指的 struct 的第一个元素，而不是解引用之后对整个 object 做什么，这意味着我始终在用同样的类型访问同样的一块内存，不会产生 strict aliasing 的问题。
你后面打算把它写成 auto p = head;肯定是不对的，p 大概代表比原来链表的头更前的一个节点，你这么写是删不掉第一个节点的。你可以再跟#25 那个版本比较一下，主体是差不多的，我只不过是没有给那边的「头节点」分配不必要的内存而已。

@pastor 所以你真的是啥都不懂……这跟左值右值有什么关系？用引用传参代替指针传参不是 C++98 里面就有的东西？第一天学引用的人都能花 10 秒的时间把它改成用指针的版本，这种东西要花十年……你是不是以为引用的背后有个什么庞大的 runtime 在支持它所以只要用了引用就不可能改写成能进内核的版本了？

@pastor 难道你在舔 linus 之前不反思下自己连引用都整不明白有没有资格吗？

@FrankHB 然而我还真没看过国内流行的数据结构书（和受它影响写出来的任何东西）……我写那坨的唯一目的是说明它本可以写成不用让观众人肉解析几层指针的样子，其他和这个目的无关的地方都是能省就省（比如直接 using 而不是包一层 struct ）。至于为什么叫 list_head 可能是我当时在想 list 可以递归定义成 list = empty | (list, data)，所以就写成这样玩了（没直接叫 list 估计是当时想着这个是不 export 给用户的内部实现），我完全同意主楼那个代码已经是坨烂摊子了正经写肯定得从头开始重新设计……所以有啥类型系统和接口定义得比较讲究的链表实现适合参考么？
我刚写完的时候自己看着中间那个强转也恶心，总觉得有 strict aliasing 的问题，但后来感觉标准应该保证了 standard layout 的情况下指向第一个 non-static data member 的指针和指向整个 struct 的指针可以互转 + 我一直在用同样的类型来访问，看起来是不会出 UB 的（还是我漏了啥？）。另外我感觉那帮在 rust 里死活写不出来一个链表的是因为非得禁用 unsafe……
关于 ownership……为什么 target 调用后是 owning ？又不是 std::forward_list::erase_after （其实我也没太搞懂为什么 erase_after 传了个 const iterator 进去，好像 ownership 上也不对劲），这个里面的 target 只参与了比较（所以才很奇怪地在大概率已经在前面找到过前一个 node 了现在还得从头再搜一遍，我觉得性能上这个才是最烂的地方），一直都是 non-owning 的吧（然后我想起来我那坨代码最明显的问题是 target 的类型不对，应该换成一个明确显示是 non-owning 的）

我是没看出来 Linus 有啥 taste……正常人会写成这样，扫一眼就知道在干什么
https://i.imgur.com/qRxLIsu.png
（你说里面是不是有 UB ？反正出事也是 container_of 这种玩意比我先死）

@FryFryFry 这个就是按比例加粗的，你往下拉到 Fixation 就很明显了……

这玩意跟写个脚本把一个单词前一半左右（具体多少可以调）自动加粗有啥区别？英文又不涉及分词问题应该有手就能写出来吧……我感觉好久好久以前就看过它了，今天再看好像这么多年也没啥长进。
喜欢整蛊自己的话我推荐顺便试试 BeeLine Reader ，这个是给文字上色，四行一循环，每一行从左到右分别是{蓝→黑，黑→红，红→黑，黑→蓝}渐变，适用于任何语言

---

@shyrock https://github.com/ahrm/chrome-fastread