早在4年前刚开始搭建本博客时，我曾写过一篇简短的文章，介绍了我建站时使用的一些工具。如今，那篇文章中提到的很多工具都已过时。加之本次博客整体迁移，又使用了全新的 PaperMod 主题，很多功能的配置方式都发生了变化。于是我决定重新写一篇文章，记录一下我在折腾这个新主题过程中的一些技术细节。 配置文件语法 Hugo 同时支持3钟配置文件语法，分别为 YAML、TOML和JSON。它们都是常用的数据序列化和配置文件格式，且各有特点和适用场景。 YAML (YAML Ain’t Markup Language) YAML是一种人类可读的数据序列化格式，常用于配置文件和数据交换，它的语法格式为： name: John Doe age: 30 city: New York hobbies: - reading - traveling 它的特点为： 语法简洁，易于阅读和编写 支持注释、多行字符串和复杂的数据结构 使用缩进表示层级关系 TOML (Tom’s Obvious, Minimal Language) TOML是一种旨在成为最小配置文件格式的语言，设计目标是易于阅读和编写，它的语法格式为： [person] name = "John Doe" age = 30 city = "New York" [person.hobbies] favorite = "reading" others = ["traveling", "photography"] 它的特点为： 语法直观，易于理解 支持注释 支持多种数据类型，包括日期时间 允许创建嵌套的数据结构 JSON (JavaScript Object Notation) JSON是一种轻量级的数据交换格式，最初源于JavaScript，但现在已广泛应用于各种编程语言，它的语法格式为： { "name": "John Doe", "age": 30, "city": "New York" } 它的特点为： 简洁易读 解析速度快 与JavaScript高度兼容 支持基本数据类型：字符串、数字、布尔值、null、对象和数组 综合考虑易读性及与当前主题的兼容性，我选择的配置文件语法为YAML，以下所有配置命令，都将以YAML格式呈现。值得注意的是，YAML对缩进非常敏感，在利用 Hugo 进行渲染时，哪怕某一行少了一个空格，都会渲染失败，所以要特别注意。 ...

2024年12月25日上午9点25分，一架载有67人的飞机，在哈萨克斯坦阿克套国际机场附近发生坠毁。事故导致38人遇难，震惊全球。直到目前，事故背后的真相仍未完全揭开，迷雾笼罩之下，事故的原因、影响以及后续正吸引着全世界的目光。 事故背景 事发地点阿克套，位于哈萨克斯坦西部、里海沿岸。这个城市的名字在哈萨克语中意为“白色山地”，因为从里海望去，阿克套的地貌和城市景色呈现出一片苍白的色调。根据2019年的统计数据，阿克套的常住人口仅为18万人。起初，这里因石油开采而兴起，直到如今，仍带有浓厚的工业气息。然而，正是在这座湖滨小城，一场突如其来的灾难打破了宁静。 发生事故的J2-8243航班，是阿塞拜疆航空公司的一趟国际航班，由阿塞拜疆首都巴库飞往俄罗斯的格罗兹尼国际机场。航班的机型为巴西航空工业生产的E190AR型客机，是一款中短程窄体客机。飞机长36米，能够容纳98~114人。 12月25日清晨，巴库国际机场，航班的起飞时间已临近，乘客们陆续登上飞机。随着塔台的指令，飞机开始滑行进入跑道。此时，乘客们或许并未意识到，这趟本应平凡无奇的航班，正朝着一个充满未知与危机的方向飞去。 事故经过 简单看一眼地图就会发现，这趟航班从阿塞拜疆的巴库起飞，目的地是西北方的格罗兹尼。然而飞机最终跨越了一整个里海，飞向了远在湖对岸阿克套，明显不符合常理。航班追踪网站 Flightrader24 显示，事发航班从巴库飞往格罗兹尼的途中，在跨越俄罗斯国境线时，GPS 信号受到异常干扰。紧接着，航班开始偏离原定航线，先是朝向西方，而后又180度掉头，朝向东边的里海飞去。最终来到里海对岸的阿克套，向当地塔台请求迫降。 根据纽约时报对一位空难幸存者的采访，当时航班上，起初的一切如常。然而，随着飞行的继续，一些乘客开始察觉到异样的震动——最初是一阵轻微的颠簸，几乎无人注意；接着是更加剧烈的颤动，窗外的云层翻滚，机舱内传来细碎的杂音。接着，剧烈的震动几乎把所有人从座位上抛起。氧气面罩从头顶掉落，机舱内响起了混乱的呼喊声。乘客们慌乱地抓住面罩，试图恢复平静。机组人员的声音此刻也变得急促，但不完全清晰。在这一瞬间，他们意识到，这并不是一次简单的气流颠簸，而是某种更加致命的威胁。 从当地居民拍摄的视频中不难看出，在飞机迫降的过程中，尽管驾驶员竭尽全力想要控制飞机的降落姿势，但巨大的冲击力和瞬间的失速已经使飞机机身失去平衡。最终，飞机以过大的角度俯冲向地面，右翼先触地，随后翻滚爆炸，机体分裂为两部分。机头部分在触地瞬间被爆炸摧毁，尾部则倒置在主要残骸之外。 公开数据显示，事故航班上共有67人，其中来自阿塞拜疆的有37人，占比一半以上；其次是俄罗斯16人，哈萨克斯坦6人、吉尔吉斯斯坦3人。事故发生前一刻，有乘客用手机拍下了机舱内的情况。 这是一起极其严重的空难事故，机上67人中，有38人遇难。最后生还者中也不乏颅脑损伤、脑震荡、胸部损伤及创伤性休克等重伤患者。事故发生次日，阿塞拜疆总统宣布进行全国哀悼。 事故原因分析 事故发生后，俄罗斯联邦航空运输署发表声明称，初步相信飞机遭遇鸟群撞击，因机上紧急情况，机长决定改道飞往阿克套机场。然而事实真的如此吗？ 从事故现场的拍摄的视频中不难看出，事发飞机的残骸上，存在多处类似单孔的痕迹。结合 Flightrader24 网站上显示的异常 GPS 干扰信息，我们不得不怀疑，此次事故是否与俄罗斯境内的防空系统有关。 自从2022年2月俄乌战争爆发以来，俄罗斯在中亚和东欧的国境线附近一直都火药味十足。就在事故发生前的12月21日，乌克兰对俄罗斯境内的喀山市发动无人机空袭，造成市内两栋高层住宅楼受损，这是战争爆发以来，乌克兰罕见地对俄罗斯境内城市发动空袭。在这种情况下，俄罗斯的防空系统一直处于高度警戒状态。 因此，此次的阿航8243航班，很可能是被俄罗斯的防空系统所击落。飞机在飞跃俄罗斯国境线附近时，被俄罗斯防空系统误认，进而发生 GPS 干扰和防空射击。又由于附近机场因大雾天气而无法降落，机长不得不调转方向，操控着受损的机身朝东边的里海飞去。最后在里海沿岸的哈萨克斯坦境内迫降失败，导致飞机坠落。 路透社的几篇报道也有相同观点。该社援引部分事故幸存者的说法称，当飞机接近最初目的地格罗兹尼时，他们听到几声巨响；四名了解事故调查初步结果的消息人士称，事故飞机是被俄军的铠甲-S（Pantsir-S）地对空导弹系统击中。飞机在接近格罗兹尼时，机上的通讯系统被电子战系统瘫痪。 虽然截至目前，事故的最终调查报告还未发布，我们无法100%断言此次事故就是与俄罗斯有关。但在历史上，俄罗斯已经不止一次地与民航空难产生联系。 类似事故 早在10年前，彼时正值乌克兰克里米亚危机时期。2014年7月17日，中午12点15分，马来西亚航空MH17航班从荷兰阿姆斯特丹机场起飞，飞往马来西亚吉隆坡。下午16点20分，执飞该航班的波音777-200ER型客机在乌克兰东部空域巡航时突然坠毁，机上283名乘客和15名机组成员全部遇难。事故调查报告表明，马航MH17航班是被俄军发射的山毛榉导弹摧毁。然而，俄罗斯官方至今都否认这起空难是俄军攻击导致，并声称乌克兰空军才是事故的真正元凶。 自从人类发明民航飞机以来，大大小小的空难便从未停歇。不论是这次的阿航8243空难、还是十年前的马航MH17空难，都是一次深刻的警示。无论是因技术故障、恶劣天气，还是因人为错误，空难的发生无一不带来深刻的痛苦和反思。然而，有些空难的背后，隐藏着更为沉重的代价——战争、恐怖袭击、政治斗争。这些无辜的生命，因全球纷争和冲突而被夺去，他们不仅是航班上的乘客，更是和你我一样的普通人，他们也曾有过梦想、有过家人、有过属于自己的生活轨迹。 我们对逝者的缅怀，同时也是对自己的缅怀，丧钟正为每个人而孤鸣。未来，我们必须呼吁和平的声音，寻求一种更理性、更宽容的世界秩序。让那些逝去的灵魂得到安宁，让所有家庭不再因纷争而遭受无辜的破坏。 来源链接 阿塞拜疆航空8243号班机空难 - 维基百科，自由的百科全书 阿克套 - 维基百科，自由的百科全书 巴西航空工业E系列 - 维基百科，自由的百科全书 Flight history for Azerbaijan Airlines flight J28243 Kazakhstan Plane Crash Survivors Describe Chaos on Azerbaijan Airlines Flight - The New York Times 阿塞拜疆航空客机坠毁　俄监管机构相信与鸟群相撞后出现紧急情况 - RTHK ...

背景 我在2022年4月的一篇文章中介绍了 Home Assistant 的安装与配置方法。彼时，要将小米的众多智能家居接入 HA，我们必须安装一个第三方 HA 集成，即 Hass-Xiaomi-Miot。它由个人开发者 al-one 在 Github 上发布，一直以来都是我们将米家接入 HA 的唯一选择。直到最近，小米在 Github 上发布了官方的 HA 集成：HA_Xiaomi_Home，填补了米家接入 HA 的空白。 虽然这又是一个“官方逼死同人”的故事，但小米的开源精神仍然值得称赞。与第三方集成相比，小米官方的集成对自家产品支持更好， 能够帮助我们更加轻松地将米家接入 HA，进而实现米家与 Homekit 生态的互联互通。今天，我们将跟随 HA_Xiaomi_Home 的官方文档，详细介绍一下这个集成的安装及使用方法。 通过 HASC 安装米家官方集成 米家官方集成有多种安装方式，其中最简单，也是最新手友好的方式，就是通过 HACS 进行安装。HASC 的安装方法详见我的这篇文章，此处不再赘述。由于米家官方集成暂未加入 HASC 的官方库，我们需要通过添加自定义库链接的方式，将米家官方集成的库链接添加到 HASC 目录。登入 HA 后台，点击左侧的HASC，再点右上角的三个点，选择Custom Repositories，新建一个自定义库链接，如下图所示。 库类型（Catagory）选择Integration；库链接填写下面的链接： https://github.com/XiaoMi/ha_xiaomi_home.git 最后点击ADD按钮，如果网络没有问题的话，米家官方集成的安装链接就会被添加到 HASC 的自定目录中。再依次点击设置—设备与集成—添加集成，在搜索框中输入Xiaomi，在弹出的结果中选择XIaomi Home。接下来，按照提示登录米家账号即可。 注意⚠️：如果你和我一样，使用 Docker 作为 HA 的安装环境，那么大概率会在米家账号验证时遇到无法跳转的问题。无法跳转的核心原因在于，米家官方集成默认使用 homeassistant.local:8123这个本地域名来跳转回 HA 页面，而 Docker 容器中的 HA 无法在本地局域网中广播.local本地域名。因此，在验证米家账号并跳转回 HA 页面时，我们需要手动将浏览器地址栏中的homeassistant.local:8123改为IP:8123。这样就能完成米家账号的验证工作。以上方法参考自米家集成仓库的 Issue#8。 停用多余的米家实体 当我们安装好米家官方集成并完成账号验证后，HA 就会自动搜索并添加米家的各种设备。同时，我们的家庭中会出现一堆乱七八糟的实体。所谓实体（Unit）是 HA 用来定义设备最小子功能单元的概念。通常一个设备会对应多个实体。例如，一台『热水器』设备，可以同时拥有『当前水温』、『目标水温』、『预热开关』、『增压开关』等多个实体。 然而在日常使用过程中，我们并不需要将每一个设备都拆分成诸多零碎的子功能单元，这样不仅使人迷惑，还会让我们的家庭界面变得极其繁琐。因此，在将 HA 链接到 Homekit 之前，我们需要对米家集成添加进来的众多实体进行筛选，仅保留我们日常使用过程中最需要的开关和数值即可。 ...

关于博客迁移 由于一些个人原因，我在今年年中时注销了我的Google账号。这导致我的原 Github 账号无法进行 2FA 认证，也就无法继续在原博客地址更新文章。于是我重新申请了新的 Github 账号，并将之前的文章都迁移到了这里。 不知道有多少人收藏了我的原博客地址？可能从他们的视角看来，我已经永久停更了吧。在弱社交的静态博客平台发布个人文章，最大的弊端就是无法与读者取得联系。我无法将这篇博客迁移的通知转发给任何老读者，实在非常遗憾😞。 既然同时更换了 Github 账号和博客地址，我索性把自己的笔名也从 Bright 变为了 Mason。说起来，Bright 这个看上去并不那么 Native 的名字，其实来源于一款我最喜欢的电子游戏——《英雄传说：空之轨迹》（Bright 是游戏主角一家的姓）。在我读研期间，我的 Legal English 老师，一位名叫 David 的旧金山老男孩，曾委婉地告诉我，Bright这个名字并不适合我。于是我启用了 Mason 这个更加 Native 的名字，虽然我依然非常喜欢 Bright 这个词🙂。 我说这些，是想告诉那些碰巧发现这篇新博客的老读者们：Bright 和 Mason 其实是同一个人。不过说这些大概也是徒劳，就让一切都随风吧👋。 关于博客主题更换 一直以来，我都用 Hugo 生成自己的静态博客（具体方法可以参考我的这篇文章），使用的主题是一位国人开发者写的 Hugo-fuji。这款主题非常简洁，我很喜欢。可惜 Hugo 的更新版本弃用了几个 Hugo-fuji 所依赖的模块，导致这一主题无法兼容当前版本的 Hugo。而该主题的作者似乎早在两三年前就停止了对项目的维护。因此，我不得不更换博客主题。 搜了一圈，发现简洁好看的主题实在很少，最终我选择了 Hugo-papermod，也就是大家现在看到的这个主题。这个主题支持更多的自定义功能，对各平台的适应性支持也做得很好，只不过用起来不如 Hugo-fuji 那样简单。 以上就是关于博客迁移和主题更换的絮叨，希望你没有不耐烦。后面，我会继续在这里更新文章，并稍微提高一点更新频率。致于 YouTube 和播客，我也想重启更新。不知这次又能坚持多久？

于我而言，2023无疑是漫长的一年。年底时，各大媒体和自媒体照例都会制作一些“年度总结“式的专题。每当我看到这些专题，并且恰好读到2023年初的新闻回顾，都会惊讶于它居然发生在2023，而不是更早的2022或2021。这对于一个即将步入30年的我来说很不寻常，因为在我的印象里，只有身处迷茫而无所事事的童年时代，才会觉得时间过得太慢。 为什么要对抗虚无 2023年，我经历了工作与感情方面的许多变故。虽然好在事情基本都已解决，但新的问题仍然层出不穷。我没法断定自己乃至整个时代是否还在走上坡路，未来的巨大不确定性也无时无刻不将我推向虚无。我是一个不想苟活的人，但是随着时间的推移，我越来越感受到世界的荒诞，以及身为这荒诞世界一部分的人生的虚无。 就在2023年的最后一个工作日，我发了一条朋友圈，将过去一年的经历草草总结为“工伤、手术、换房、买车、求婚”。就像在编写另一个时空中与我无关的某个人的编年史一般，我的经历也不过是寥寥几个简单的词汇。过去的我总是傲慢地将这些毫无重要性可言的经历视为自己重要历史的一部分，甚至在一篇又一篇潦草的“年末总结”中对它们加以记录，似乎是想要对抗人生的这种无意义性。但我渐渐发现，人生的虚无并非仅限于叙述层面，它是结结实实的存在。这种存在远高于我们本身的存在，也远早于我们本身的历史。 那我们是否就要因此接受这种虚无呢？我们在进行人生的某些看似重要的选择时，是否还需要认真对待？既然世界本就荒诞，人生也本就虚无，那我们还为什么要挣扎着做出选择？对于这个问题，我思考了很久，尤其是车祸受伤后躺在医院病床上的时候。尽管现在仍然没有确切的答案，但一个模糊的想法已经出现在我脑中：我要对抗虚无。 世界的荒诞性也许无法被撼动，但这不影响我们对抗人生的虚无。所谓“人生的虚无”，是结果论上的说法，即无论我们如何努力挣扎，从结果上都不会有任何意义。但我们出生在这世上，可能并非为了追求某种结果，也并非为了创造某种意义。我们存在的过程本身才应该是我们所追求的。 多年以前，有人和我严肃地讨论过这样一个问题：如果事先知道一段感情最终不会有任何好的结果，那我们是否还要坚持维护这段感情？当时的我对这个问题模棱两可，不知道其中的深意在哪。现在想去，它刚好诠释了我们对抗虚无的理由。一段感情存在的意义并不在于它是否能有一个好的结果，而在于它是否给身处其中的人带来片刻的平静与喜悦。即使事先知道一段感情没有结果，我也应该努力接受、维护并享受它。这既是对抗虚无的过程，也是对抗虚无的理由。 即使我们已经走向一个动荡的时代，即使未来的巨大风险无可避免，即使我可能会遭遇更多的苦难，我也要尽全力挣扎，并享这一挣扎的过程。对抗虚无的目的不是消灭虚无，而是接受虚无、享受虚无。我就是要在大厦崩塌前追求内心的平静与灵魂的自由，这样才能在最后审判来临时，带着微笑与世界一起毁灭。 如何对抗虚无 既然要对抗虚无，那就要找到正确的方式。我成长在一个对先秦儒家高度污名化的时代，从官方到民间，大多数人要么是在篡改和利用儒家思想，要么是在攻击和否定儒家思想。儒家告诉我们，要先修身、再齐家、再治国、再平天下。而我们的教科书却告诉我们要反过来，要先人后己、先国后家，要向雷锋同志学习。这种过于”现代性“的方式摧毁了原本的社会结构，使所有人都脱离原本的小共同体，转而服从于一个被构建出来的大共同体。荒诞性与虚无感借此变得更加凸显，笼罩在所有人的头顶，渐渐蚕食了所有人的生活。 要对抗这种现代的、被强加的虚无感，就要回到老地方，回到原本“自然”的社会结构，回到扎根于这种”自然“的社会结构中的思想，那就是最初的、被融合或篡改前的儒家思想。要对抗虚无，就要先修身、再齐家，先使自己平静而充盈，再让家庭和睦而富足，最后再考虑那些被构建出来的概念。在面对诸多复杂的社会事件时，以上思路同样适用。我们都要先尊重和关心”人“本身，然后再关注由一个个“人”所组成的其他东西。我想如果每个人都愿意这样思考并采取行动，世界肯定会变得更好。 2023年，我仍然在修身、齐家的道路上，在对抗虚无的道路上挣扎。我努力做了很多事，也做砸了很多事。2024年，这依然是我的主题。在这其中，于我而言的重中之重，是修身。更具体地说，是保持谦逊。