Shane Yao

作者： shane

  • 致我自己和深受消费主义毒害的人

    自从19年疫情开始有意识的关注消费主义，最近又看到一个宝藏视频。里面的观点其实跟之前一部分有重合：拒绝消费主义强加到消费品的符号。不过还提出了一个更加有意义的观点：不要消费自己想要的，消费自己需要。里面提到一个需求清单，在下面摘录出来了。我觉得很多人（包括我自己在内）被消费主义麻痹了。过多的关注消费带来的符号，而不是自己基础的需求。

    消费主义的骗局！别被“断舍离”忽悠了！

    需求清单：

    1、身体健康有活力。

    2、身体机能正常。

    3、没有不必要的疼痛。

    4、情绪稳定。

    5、没有无来由的焦虑和怨恨。

    6、一定程度上不受他人干涉的自由。

    7、最基本的智力活动。

    8、参与正常的社交。

    9、最基本的财富、收入和经济保障。

    10、可接受的社会和物质环境。

  • 威联通NAS(QNAS)的DDNS域名在国内部分地区解析失败以及解决办法

    大概在半年前，发现手机的Joplin无法同步QNAS中的笔记。一顿排查后居然是5G的网络用的DNS服务器202.96.128.166和202.96.128.86这两个解析*.myqnapcloud.com失败，全部返回127.0.0.1，详情看这里。

    保障到中国电信，反馈该域名没有在白名单中，需要域名的拥有者申请。遂联络QNAP的HelpDesk，客服反馈很积极，但是由于这个只有部分地区有问题，而且他们也不清楚电信那边具体要做什么。他只能建议我用中国区的域名，问题是最近中国区的域名也不是很稳定，解析从myqnapcloud.cn切换到mycloudnas.com了。最后只能放弃。

    直到今天看到cloudlink的app更新了，看了一眼CL，其中有一条:

    Added support for adding 3 DDNS alias names using mycloudnas.com.

    是不是全球的也可以用mycloudnas.com这个域名了？加了一下别名，还真的生效了，而且电信也能正确解析了，而且let’s encrypt 的证书也支持两个别名，困扰半年的问题终于解决了。PS：反代也需要重新更新一下证书（重启就行）。

  • 关于国内新能源发展的一些想法

    最近看到B站有财经区UP主在讲《2024—2025年节能降碳行动方案》

    1. 大势不可逆，燃油车退出历史舞台的步伐会加快。不负责任的说，燃油车还有15-20年的寿命，然后逐步推出历史舞台，加入到博物馆行列。
    2. 电车用电成本低也随着燃油车退出舞台成为过去。以后公路的费用会由电车一起承担。
    3. 强迫生产端更新，取代化石燃料，工业用电需求会增加。电价肯定会涨，居民端应该不会有太激烈的调整幅度。生产端估计会成本增加不少。虽然不是直接传过来，但是物价涨估计在所难免。
    4. 用电的话，蓄能是一个大问题。对于农村地大，有条件自己建设蓄能设备，可以减少价差。现在的蓄能都是国家在搞，利用水利。城市的话各家各户自行建设蓄能不现实。那城市的蓄能会怎么发展呢？有没可能会统一在城市建蓄能站，然后由市场驱动低价电的买卖，形成市场化呢？这个是有可能的，另外还需要考虑峰谷电价差，只有足够大才有利润；另外蓄能的效率也是很讲究的，化学蓄能达不到水利蓄能的效率。

  • 中文的WordPress博客回来了！

    感谢阿里云的99计划，本来想试试阿里云的，但是发现要重新备案才能。现在阿里云备案（广东）要签承诺书，还要打手印，简直就像卖身。虽然我自己没什么不见得人的，但是就是不爽。还好腾讯也被卷起来了，99/年的轻量云还可以。带宽大一点，但是限流量（300G/月）还行吧。

    主机拿到手后本来想搭的dokuwiki做分享的，但是搜着搜着找到我以前在V2的一句留言:”wiki 是给大家一起编辑用的，不是给大家看的；要给大家看的，CMS 了解一下”

    对啊，既然我只是想整块分享内容，没有共享编辑的需求，为什么要用wiki呢？所以另辟蹊径，找到了Obsidian+Squartz的方案。跟jekyll类似，本质也是SSG。但是由于有Obsidian的Backlink加持，分享会更加成体系。目前的规划大概是Blog、数字花园（DigitalGarden）、首页。更新频率从高到低、内容质量从低到高这么一个规划。

    或许这里以后会变成一个高频率、吐槽、低容量的地方。但总比荒凉之地要好吧？

    Update:

    我的数字花园

  • GODOT引擎中的一些概念

    Server

    • 一个引擎内部代码组织代码概念，主要用途是用来将引擎内部一些比较独立系统组织起来。
    • 只是一个逻辑概念，代码上没有一个框架，都是每个Server按照自己的情况去创建。
    • 嵌入到引擎也是通过Hardcode（例如在main.cpp初始化某些Server）
    • 一般来说每个Server都是有自己一套线程运行，跟主逻辑线程主要依赖CommandQueue（引擎提供），主线程一般只在需要的跟Server做同步（例如物理、渲染）
    • Server本身是一个Object，可以发送信号到场景对象。

    Modules和GDExtensions

    • 两者都是C++扩展引擎的方式，主要区别是Modules是以静态方式编译进引擎，GDExtensions是动态库方式。
    • Modules功能更全，因为和引擎一起编译，可以访问所有的API。不过官方承诺如果发现GDExtensions实现不了的功能，可以提Ticket，尽量保证和Modules功能相近。
    • GDExtensions编译更快，Modules修改需要重新编译整个引擎（但是我觉得只要依赖正确，基本多不了多少时间）
    • GDExtensions由于是二进制，可以使用其他语言开发（社区有个Rust的）。大概只需要将引擎的API导出到Rust就可以（不过引擎API的二进制兼容性如何？）
    • iOS不支持动态库加载，GDExtensions似乎无法使用，也没法直接将GDExtensions静态连接到ios。

    参考：

  • 对个人知识库（PKM）的一些理解

    PKM

    PKM是Personal Knowledge Management的缩写。这个跟当时PIM（Personal Information Management）类似，核心都在Management上。
    实际上对于Information，使用管理的方法是没问题的。因为信息总类都基本是固定的（联系人，日程之类的）；而Knowledge的内容都是不固定的，而且是很难做到预先的层级划分。
    如果你使用传统的EverNote，Joplin等工具，对知识进行树形分类你会发现怎么都分不对；最后，为了分类的正确性，而不停调整分类。

    P.A.R.A.方法

    这个方法我实践下来，更像是PIM的管理方法，而不是PKM。虽然我觉得，将自己感兴趣的东西和正在做的东西分成AREA和PROJECT这种方式深得我心。但实际实践下来却发现，这个方法实际上更关心AREA和PROJECT，对RESOURCES的管理方式一点没有提及。或者说Resources实际上还是按照传统的进行树形分类。所以我觉得P.A.R.A.并不是一个个人知识管理的好办法。甚至说它不是一个PKM的方法，更像一个个人OKR系统。

    识别什么是Knowledge

    通过整理自己的笔记（从WIZ->NOTION->OBSIDIAN->OBSIDIAN+JOPLIN）发现自己这么多年所谓的”笔记”，其实大部分都这些类型：

    • 网上摘抄，参考之前自己写的：笔记整理、DataHoarder和NAS
      • Maybe Later类型，感觉可能会有用，想保留下来（Tab数量已经爆棚）
      • 操作手册类型的笔记。都是整篇内容取录下来
      • Awesome类笔记
    • 自己工作中总结出来的命令（Cheatsheet之类的）方便后面翻阅
    • 项目中的一些有用的信息之类（账号、地址）

    其实上面这些都不是你自己知识，只有当你对里面的一些内容有自己的看法、总结时，才是你真正的知识。虽然这些不是你的知识，但也是属于有用的东西。我觉得可以放到Joplin上，这类内容，其实很容易就会有一个归属的，而且这种归属还特别容易分类。

    Zettelkasten

    前面说了树形的分类会导致不停的要调整分类，会陷入类似满足数据库范式一些悖论，整个系统因为要满足范式规范而进行复杂的表设计。正如Mongo对范式的问题给出解法：既然要满足高范式设计这么麻烦，我干脆就只用最低的范式去做这个事情。Zettelkasten就是这么个方法：既然分类这么麻烦，我索性不分类了。所有的卡片都是一样处理，放到同样的地方。这里有两个重要的点：
    1. 我先不管分类，先把想法和东西先记录下来
    2. 后面需要回头对卡片用其他方法索引起来，并且索引的过程中其他相关内容进行回溯更新
    其中重点的是2：需要不停审视你的笔记、建立索引。意味着你的笔记要不停的被Review和更新，而不是躺在某个分类发臭。
    至于ZKID，其实我觉得对于Obsidian或者其他支持超链接的笔记，是不太重要的。对于卢曼那个用原始卡片盒，ZKID是索引主题的关键。

    References
    什么是 Zettelkasten 卡片盒笔记法？

  • HybridCLR浅析

    周日心血来潮开了一下Unity，突然想起之前有一个据说秒天秒地秒空气的热更框架huatuo，打算找来研究一下原理。

    搜索了一下，发现huatuo已经归给掌趣，作者后来自己开了一个HybridCLR。知乎、B站、Google搜了一圈，发现基本都是同样的内容，像极公关稿。说什么工作在IL2CPP层、没有虚拟机、性能牛B、开箱即用，玄乎到不行。好奇行心驱使下，看了一下源代码，大概明白工作原理：

    1. 在IL2CPP生成完Unity自身C#对应的C++代码之后，插入一些HybridCLR的C++代码，其中包含所谓的interpreter和transform。
    2. interpreter本质就是一个虚拟机，用来执行HiOpcode。
    3. transform就是用来做IL->HiOpCode转译
    4. interpreter传宣是register based，但是代码看来就是stack based。不知道作者是否有商业版本的实现
    5. HiOpCode就是基于Unity的一个特化指令集。只要指令集命中的执行效率肯定高，除此之外通用性能可见的不太理想。另外虚拟机的指令集是变长的，想要优化效率估计有困难。可以简单类比CISC和RISC的区别。
    6. 相比现有脚本解决方案，绕一层C#再到引擎接口，HybridCLR直接通过interpreter调用IL2CPP::vm接口，确实性能会有优势。还是那个前提，只要你的代码能命中特化的opcode。
    7. 这个方案的本质还是Unity不提供纯C++库的调用方式。IL2CPP::vm这个胶水层虽然比直接C#要薄，但是相对纯C++接口还是太厚了。如果Unity自己能提供一层C/C++的封装（类似fmod那样），对脚本接入就不用这么纠结。

    综上所述，HybridCLR所获得的性能提升主要在更薄的胶水层和特化的OpCode；相对应的通用解析性能可以预见的不高（盲猜，没有任何证据，不用杠。杠就是你对）。对于纯C#的项目，想获得一些热更修复的能力，可以考虑。如果是想达项目的脚本化，HybridCLR估计有难度。

    ILRuntime的原理其实也类似，只是我记得最早ILRuntime是直接运行IL OpCode的。今天看了，好像也用了类似的方式。

  • 入了一台官翻的Macbook pro M1

    最近把老婆的以前剩下的那台小米笔记本Air给了出去，就有理由重新买一台笔记本了。自我上一台Macbook pro 到现在估计已经有10年了吧。说来也巧，那台笔记本也是官翻的，从香港官网入手的。还记得到了之后的那天，激动的请了一天假，当天就去香港提回来。

    说回这台M1笔记本，是直接从大陆的官网下单的，多了消费税，比之前的从香港官网自提稍微贵了一点。配置选了32G + 512 的14寸8核的配置。总体感觉这个配置对我来说性价比是最高的。14寸刚好有XDR屏幕，32G内存也够用。因为macbook的内存不可以扩展，只能一步到位。512G硬盘相对勉强，但是我觉得差价1.5k的差价，够买个2TSSD扩展了。而且macbook还可以插SD卡，硬盘应该够用。处理器8核和10核的数据，纸面的数据是强了20%，但综合考虑了一下续航、实际的提升以及自身需求，8核的性价比会更高。图形核心更不用说了，我要图形性能不考虑台式机？

    曾经有考虑过，够买一些轻薄本（XPS之类的）或者游戏本（R9000K之类的）。游戏本那个重量和体积真的劝退；轻薄本的话，确实还可以。但是续航始终还是Mac更占优势，而且价格也没比Macbook便宜多少。

    其实从官网的货源来看，这款配置的缺货程度也是最高的，可见也是比较受欢迎。可惜没在M2 Macbook出来的时候快速反应，不然还可以去购买员工优惠，还能更便宜1.5K左右。目前来看这个Macbook Pro算是不错的选择。希望之后能再陪我下个10年吧LOL。

  • Cocos2D-X历史回顾

    今晚在整理以前的笔记，发现一篇关于cocos2dx renderer的设计摘录。cocos2dx可以说是我客户端之路的启蒙引擎，对我有很大的启发，也跟随着我经历过一段神奇的工作经历。好奇心驱使下，去搜了一下目前的状况。发现2018年基本已经停止更新，最新的版本也停留在v4.0(2019年)。后来的替代者是cocos-engine。简单的浏览了一下文档，虽然增加了不少新的特性，绑定语言也变成了TS，从代码树来看似乎也继承了cocos2dx部分代码。但是整体的功能和设计不要说跟双U比，就算跟目前的后起之秀GODOT也差了不少，论坛也比较冷清。

    这不禁使我思考，为什么当时如日中天的coco，为什么后来会掉队呢？

    崛起

    cocos2dx其实是从coco2d的’翻译’过来的（我记得后面甚至原作者也跳到cocos2d）。coco2d是一个基于ios objc的2D引擎，一开始定位就是做2D小游戏的。在这样的背景下，再加上钓鱼达人在手游的爆火，作为幕后功臣的cocos2dx自然得到更多人的关注，而当时正处于手游崛起时代，国内（国外）游戏引擎近乎空白。cocos2dx自然顺利成章的’补位’。

    转折

    对于cocos2d-x v2.2之前的历史我所知不多，但对于v2.2以后甚至v3.0的版本，可以说这个引擎的巅峰，时间大概是2012-2015年。伴随着各大传统厂商入局手游，市场迅速扩大。cocos2d-x可以当时游戏研发的唯一选择，当时的触控科技可以说是当红炸子鸡。触控当时也看到移动设备的性能不断攀升，推出了重构了渲染层、’支持’3D的v3版本。在我看来，正是这个风向的转变，让cocos2d-x从第一梯队掉队。我认为主要原因：

    1. 兼容性。V3当时的定位是V2的迭代，迭代了渲染队列和增加能显示3D的节点Node3D（如果我没记错的话？）这就导致花了大量时间的V3实际只是一个能显示3D模型的准2.5D引擎。从现在我个人的角度来看，如果要做3D的话，原有的引擎API根本不适合，单说场景管理这块就已经很头疼。另外3D引擎的工作流需要有很强的定义和整合能力，当时cocos2d-x也是一个渲染引擎，根本达不到这样的高度。与其从V2兼容迭代，不如另开炉灶，做一个领先时代的新的产品。事实上触控后面也开了Cocos Creator，UE3->UE4也是完全重写（虽然用了不少UE3的代码）。
    2. 稳定性。对当时cocos ui 编辑器的稳定性印象深刻。每天都会crash不少次，还会有一些性能问题。即便是后面的版本也基本没有太多改善。对于inhouse的工具，可以忍；作为一个产品几乎无法接受。
    3. 技术滞后性。cocos2dx很长一段时间都是以一个单独的渲染引擎+UI编辑器存在。直到后面Unity出来，才发现可以将所有东西整合在一起作为一个编辑器。这时候Unity已经以技术领先态势抢占市场份额。回头Unity在3D引擎的基础上开发出2D引擎的内容把cocos2d-x仅有的2D市场也吃掉。

    总结

    其实，无论你之前处于什么样的领导地位，只要一次没跟上时代的步伐、看清楚形势就会被时代抛弃。无论是对于个人或公司，触控如是，诺基亚如是。反观同样是有自己产品和引擎的E宝，在Unity已经抢占手游市场的大半江山，依然能通过开源占领市场，并利用自己技术优势和不断迭代，重夺引擎市场桂冠。可惜，触控始终不是Epic，时代总要翻篇。