当他不存在就行

我现在用 code-server，能用，但是 bug 有点多
理论上 xpra 也能用，不过公司服务器环境有点复杂，暂时没配起来
再之前用的是 VNC

直接跑在远程，不折腾

hardware raytracing 这个，AMD 应该也会有跟进。不过我对这货短期内的前途不太看好，普通用户应用场景不多

专业卡貌似对 CG 加成不多，对老黄的钱包加成倒是绝对不少，专业卡对我唯一不可替代的价值就是有很多专业卡都是单槽的，省空间。另外国内卖的非公版游戏卡普遍外观都很“ Gaming ”，好像台湾厂商认为大陆只配这种审美似的

另外楼主既然是搞渲染的就不考虑下 hardware raytracing 的问题？理论上 20 系卡对离线渲染也有帮助（参见 https://code.blender.org/2019/07/accelerating-cycles-using-nvidia-rtx/）

Blender 的 Cycles 貌似对 OpenCL 有支持，效果似乎还可以。AMD 自己也出了个 ProRender 渲染器

Optane 这种明显是给老爷们用的不考虑这个很正常

@comi 那你直接买群晖不就得了 ...

了解下 tiling window manager

@chmlai 专业名词叫 Whataboutism

X79 ？不过好像现在靠谱的 X79 都不便宜

那叫包浆

用黑的就行了

@lblblong Qt 和 Flutter 有一定相似之处，都是在不同平台上自己画一个界面模拟 native 控件
不过 Flutter 貌似 Android 和 iOS 的控件是分开的，Qt 就完全是一套代码可以直接跨平台，并且是 native look & feel

但是我觉得从使用层面，Qt 与现在互联网流行的这些花里胡哨的东西是没有什么直接的可比性的。首先我觉得 Qt 社区还是桌面时代的思维多一点，务实一点，并且貌似很少用整套的第三方控件的（当然肯定是会有第三方控件提供官方没有的功能，不过不会整个重造轮子），然后 Qt 历史其实很曲折，历史包袱很大，内部还有 Qt4，Qt5，Qt Quick 之类的分野（虽然 Web 的历史包袱好像也不轻），最后现在他们面向的群体貌似是完全 disjoint 的 ...（ electron 可能有点交集）

我 Qt 和 Flutter 都只做到 Hello World 水平，所以我说的仅供参考 ...

@whywhywhy 因为这些框架的开发思路都被互联网行业的某些垃圾思维毒害了，他们觉得自己折腾一点视觉上的 trick，学习一个最新的历史进程，搞一个什么设计语言就能真的给客户带来价值（至少说是这么说的，不过 anyway，KPI 是拿到手了），呵呵

以前做 naive 平台专业软件的那种效率至上的思路已经很少见了

https://d2wvmrjymyrujw.cloudfront.net/media/uploads/products/overview/character_houdini_ui.jpg
https://vfxblog.com/wp-content/uploads/2016/08/pyro_sim.jpg

特效软件 Houdini 的截图，应该是 Qt 写的

当然这种界面要想高效使用是有门槛的（和 Vim 一样），不过现在做框架的都把用户当傻逼，当然不可能这么做

我觉得吧，前端没有一个组件库的“认同度”能赶上 naive 平台的 Qt，楼主这个报道有点偏差

@gramyang 正常的 String 不会有对其他对象的引用，但是正常的其他对象可能有和其他对象之间的互相引用
正常的序列化应该做一个 pointer swizzling，而不是直接转 json

另外我觉得 OCaml 还是低调一点 ... 一粉顶十黑的客观真理已经在这几楼开始发挥作用了，我可不想哪天 OCaml 变成人人喊打的东西

说起来，我之前用 PHP 重新实现了一个系统，结果发现 PHP 的实现比原来的 C 语言实现快了 50 倍。经过 C 语言的那个小组对算法多次的优化，PHP 的版本还是快好几倍。（转移话题

我看 flipboard 那个文章的意思就是他主要是为了性能做的

这个问题我觉得可以换一个角度看

根据我的观察，UI 库（指广义的 UI 库，不是前端一亩三分地里面的那几个）按照其绘制界面的方式可以分为两个流派
一个是用更高（或不同）的抽象包装平台提供的 GUI 相关的 API 和控件，比如 Windows 平台的原生 API 是 Win32，微软就有 MFC、WinForms 等一堆库来做这个包装，Borland 的 VCL 应该也算（没记错的话应该是）。这种做的比较大的，跨平台的我就知道一个 wxWidget。还有 SwiftUI，按照 Apple 的说法（ SwiftUI 使用了 UIKit/AppKit ）。
SwiftUI 是属于这一类的，另外 UIKit 和 AppKit 的基本思路一样，但是确实是两套不同的 API，所以如果 SwiftUI 能实现一套代码在不同 Apple 平台上跑（这个我没了解过，我主要对框架设计思路感兴趣），那勉强也算个跨平台吧 ...
我们把这一种框架称为“老实人框架”

另一种就是我用平台原生的 API 帮我创建一个窗口，再让平台帮我在窗口里面搞一个 canvas （指代任意图形 API 的 context ），跑一个 event loop，然后就变身渣男把平台给踹飞了。窗口里面的控件则完全由 UI 库自己模拟出来。这种做的比较有名的，远有微软的 WPF ——虽然只能在一个平台上面跑，但是还是自己把 Ｗ in32 控件重新做了一遍 ... 然后到死都还有性能问题，近有 Flutter （ Flutter 用的应该是 Skia，Chrome 的 UI 应该也是这么画的，所以 Chrome 也 ...）
实际上 Qt、GTK、Swing、JavaFX 都是这种方式，几乎所有的游戏也是这种方式（ Apple 甚至默认了游戏可以随便折腾不用管他那一套理论）
我们把这一种框架称为“渣男框架”

现在我们来证明“老实人框架”和“渣男框架”是可以无限互相嵌套的 ...

说到平台，这里的平台 API，在 Windows 指的是 Win32 那一套（ CreateWindow 之类的），在 Mac/iOS 指的是 Cocoa/CocoaTouch，在 Android 指的是 ... 好吧就是 Android 那个 ... 我也不知道叫什么，可能谷歌起名部需要努把力了
Linux 不存在（至少是不存在唯一的）平台原生 GUI API，非要说的话 libX11 算一个？好吧这个还是以你用 X 为前提的 ...

这里有意思的是，如果你把 GTK 看成“ Linux 原生 API ”的话（毕竟 GTK 在其他平台使用的很少），那 GTK 就可以被归类为“老实人框架”了 ... 其实还是有一点区别的，因为这种情况下你就是在直接调原生 API，而没有在用额外的 UI 框架 ... 所以应该说是 gtkmm 属于“老实人框架” ... 不过 anyway，这里的启发是，Cocoa 和 Android 这些框架在 UI 方面的内部实现实际上可能和“渣男框架”区别并不大，只是人为原因（官方钦定硬点）把它放到了“平台原生”这一层里面

有了上面的思考，现在我们就把 Android API 本身当成一个“第三方 UI 框架”，然后你写了个 Flutter 程序跑在 Android 上面，这就相当于你在一个“渣男框架”里面嵌套了另一个“渣男框架”
你写了个 React Native 程序跑在 Android 上面，React Native 是创建 native 控件的，因此属于“老实人框架”，这个相当于你在“渣男框架”里面嵌套了一个“老实人框架”

回到楼主的问题，首先 Web 这个东西可以被认为是一个拙劣的“渣男框架”
这个和计算机中另外一个规律，“ Greenspun ’ 10th rule ” 是异曲同工的：“任何 C 或 Fortran 程序复杂到一定程度之后，都会包含一个临时开发的、只有一半功能的、不完全符合规格的、到处都是 bug 的、运行速度很慢的 Common Lisp 实现。”
做过前端应该明白为什么 Web 可以被称为“拙劣的‘渣男框架’” ...

DOM+CSS 可以被看作是 Web Native API，从这个角度讲，Angular/React/Vue 这些可以被视为建构于 Web 之上的“老实人框架”

然后你在 Android 上面跑的 React Native 程序里面嵌套了一个 WebView，里面放了一个 React 应用，现在你在：
一个渣男框架里面 （ Android API ）
嵌套了一个老实人框架 （ React Native ）
里面又嵌套了一个渣男框架 （ Web ）
里面又嵌套了一个老实人框架 （ React ）

有没有一点 “ Java 应用调用栈”（ https://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack1.png ）的意思？

楼主的意思就是，我能不能在一个“渣男框架”里面再嵌套一个“渣男框架”，理论上显然是可以的，你甚至可以继续嵌套 ...
至于实际有多大意义，那就是另一个话题了

“这两天有心再阅读，网上搜索相当困难，若干已经消失” 等等他也删文章的么？不会是跟某中文博主学的吧

OCaml 的编译器实现确实很高效，不过这个“高效”更适合用来指代该编译器本身，而不是编译器生成的代码。这么说把，OCaml 的编译器的**编译速度**，和 C++/Haskell 的编译器相比是两个极端

不过鉴于 OCaml 的编译器是 OCaml 写的，所以你说 OCaml 运行时性能高效，也还凑合，不过和 C/C++ 比性能上限还是算了吧

个人见解，OCaml 编译器本身能做的如此高效，一个重要原因是坚持了四项，啊不四字基本原则，即 KISS。另外 OCaml 编译器对所生成代码进行的优化，相比于各大 C/C++ 编译器来说是很少的，flambda 什么的也是最近才开始搞（效果貌似也没好到哪去）。对于 C/C++ 编译器来说，如果你把优化开满，编译是很耗时的

某中文博主的文章里面应该也有一部分这个意思，但是他吹过头了