www.youtube.com/@AppleProgramming AppleProgramming - YouTube
油管上的老哥，教程从 C 出到 ObjC 再过渡到 Swift

@moonjourney 我不是说个别包里的个别 hack ，而是 nix 的整个 approach 像个 hack

ARK 上 QSV 是有的 www.intel.com/content/www/us/en/products/sku/80917/intel-xeon-processor-e31226-v3-8m-cache-3-30-ghz/specifications.html Intel® Xeon® Processor E3-1226 v3
可以多试几个软件看看

不同 distro 方向不同不能比较
比如对我更有吸引力的可能是 CachyOS 和 Clear Linux 这种

Nix 的问题我觉得是 UNIX 生态下很多程序是依赖于这套文件系统的，强行变成另一种模式让人觉得这玩意是一个巨大的 hack ，反而不 cool 了，所以我试了两天就不再用了。

@FightPig
说的是这个 world.hey.com/dhh/fonts-don-t-have-to-look-awful-on-windows-564c9d2f Fonts don't have to look awful on Windows 还有这个 twitter.com/dhh/status/1762595923857903860 DHH on X: "That crazy 8K Dell monitor came in, and the text is so fucking crisp, it's hard to convey in words. Substantial step up over the 6K Pro Display. But... there's a caveat. It basically doesn't work in dark mode. The thing is a mirror. Is this good enough to give up on dark mode? " / X ？

他的意思应该是 Retina 级别就可以了，他是先用的 Pro Display XDR ，然后觉得很不错，换了 8k 之后更好了由奢入俭难了。这个和楼主的看法是相反的，DHH 认为硬件到了一个 baseline 之后下两边是没啥差距的。对于桌面系统这个 baseline 就是苹果惯用的 218 dpi 左右（即 27 寸 5K ，32 寸 6K ），不难发现现在 PC 主流的 HiDPI 硬件比这个低了至少一个等级，但是还没到 8k 那么夸张。

不过这个说法也就仅供参考，毕竟他还说：
> I just spent last week using a PC on a 27" 4K monitor (163 PPI) where I accidentally committed the other common cardinal sin that make fonts look like shit on any system: Fractional scaling. I had the screen set to 150%. No wonder it looked offensively bad compared to the Mac! You can't split a pixel, so the system has to do all sorts of typographically nasty tricks when doing non-integer scaling, and the end result is awful font rendering.

我是看不出 fractional scaling 和字体渲染之间有啥必然联系，正确实现的 fractional scaling 不需要在字体渲染级别 split a pixel 。结合他给出的引用，他很有可能搞混了 fractional scaling 和 subpixel rendering 。

每个 ISA 都有自己的坑，不好说哪个编译起来更复杂。同一个编译器，不同后端下的功夫也不一样，你可以只做最基本的指令选择寄存器分配，不做优化，就说我编译没编译吧。就不说不同编译器版本和编译选项的坑了。这个还可以套娃：就是你编译器本身是怎么编译的？就不说拿 -O0 的编译器来跑这种老六行为，就现有主流编译器，过一遍 LTO+PGO 或者 post-link optimization 就能有两位数百分点的提升。

最好还是统一编译到同一架构来比较。
而这个图压根没有给出任何相关信息，作为性能比较是不合格的。


@agagega #6
> 编译时间绝对大头肯定是优化，这部分和目标平台没啥关系。
感觉真不一定，几个重量级：C++，Rust ，Haskell ，Scala

@james122333 他说的是不用折腾。
这也是 macOS 和 Windows 的问题——没有给出选择。HiDPI 下还不太明显，老设备下就各有各的问题了。

之前 OS X 的 System Preferences 里面有个 “Use LCD font smoothing when available”的选项，应该是影响是否使用 subpixel rendering ，打开之后会显著增强视觉字重，对就很类似 #23 那种胖了一圈的感觉。根据网上说法，macOS 后来不知道在什么版本里面，把 subpixel rendering 整个砍了，这个选项也没了，但是 defaults 里面还在，效果变成了让字体自动加粗一圈，但是这是两年前的说法，新版可能又不一样了，反正我复现不出来。
但是 anyway ，两个系统的 hinting 都是不给调的。

你给的这个配置 hinting 看上去直接满了，应该是更偏向 Windows 那种的。虽然我记得 KDE 好像默认就是这个风格，不过本贴里大部分人估计不怎么喜欢。不过问题就是，你不让用户配置就有一半用户不喜欢，你让用户配置用户就嫌麻烦。
而且我这 Qt 和 GTK3/4 程序的字体渲染好像有明显的不一致，这个倒是更加严重的问题 ...

@zhwguest 不是说"goto 导致反编译失败"，所有 control flow 到字节码里面都是 goto ，只是反编译器能不能从 goto 里面还原出原来的 control flow 来。

淘宝的生态位是多样性，鱼上甚至有卖光刻机零件的，真不真不知道，但是作为这一特色的极端体现，看个乐子还不错

大牌和爆款，确实京东和拼多多好，问题是这个世界不是只有大牌和爆款的
我估摸着淘宝自己也没搞清楚自己的核心竞争力在哪，体验也没见变好，他要硬跟其他两家拼我不觉得有胜算，以阿里的效率，光靠利基市场能不能养活自己也难说

逻辑可能是 locality ，你频繁使用的服务器能记住图标，不频繁使用的去找一下问题也不大，节省了 screen real estate
不过我本来用得就不多，我觉得 Discord 除了 Server-Channel 这个二级 hierarchy 的设计之外其他都挺烂的

改改 CSS 可能能部分解决

这个问题隔壁有过讨论 bbs.saraba1st.com/2b/thread-2166778-1-1.html 说起来，为什么国内 win7 仍然有如此高的占有率 - ＰＣ数码 - Stage1st - stage1/s1 游戏动漫论坛

本站看起来也没好到哪去，大多数回复 totally miss the point ...

C/C++ 反编译里面这种情况非常常见，比如你用 Hex Rays 或者 GHIDRA 反编译稍微复杂一点的函数很容易出现一堆 label+goto 的结果，虽然源代码 90% 不是这么写的。其实就是 C/C++ 编译器优化得多

这个看起来是 JVM 支持 goto ，但是 Java 不支持，然后你这个 bytecode 可能是 Kotlin 编译器生成的不是 Java 编译器生成的。你直接用 Java 构造可能会比较困难，但是对已有的 bytecode 做后处理达到这样的效果倒是有可能。

买 Studio 的默认不差钱，拿点零头出来捡个垃圾游戏用就行了。
Mac 和 PC 现在越来越不一样了，能分开还是分开。

rsync -x 把文件全都拷下来就行
不过我是把包列表 + /etc 下改过的东西备份，包重新装一遍配置一覆盖就行