其实本来早就想写这篇文章，但是因为11月底不幸感染了甲流，劲儿还挺大，给我干发烧了。所以一直拖到现在才开始写。这篇文章主要分享我11月在公园拍的一些照片。前言11月整体比较无趣，因为工作上比较心力交瘁，每天靠着百合漫画度日（终将成为你真的太好看了，我太喜欢了，感动到落泪）。而周末的两天只能说算是补偿精神，还没真正开始享受周末，它就结束了。想了许久上四修三的打算，最终也没能跟老板提。但月底的时候朋友路过我这里，那两个周末可真是太不一样了（要是第二个周末朋友没把甲流传染给我就更好了）。要不说呢，这日子怎么会跟谁过都一样呢？纵观整个11月份，一共就出门了两次，两次去的还都是同一个公园：渔浦寒泉湿地公园。虽然不知道名字为什么这么叫，但是它地理位置偏僻，风景还算是不错，偶尔还能看到一些鸟，算是还不错的去处吧。第一次第一次是本着探路的性质去的，虽然带上了相机，但是没指望拍出些什么东西。不过话虽如此，还是拍到了一些不错的照片。首先是在一个栈道上，我远远看到树上有鸟，虽然听到叫声就知道是老熟人（黄臀鹎）了，但是这次老熟人在吃树上揪来的果子，还是有点新奇的。顺着栈道继续走，就能看到一池子莲花。我问了Gemini 3，它说这是睡莲。因为我实在是不怎么认识植物，所以它说是就是呗。上图是我用600mm当微距拍的。虽然很近，但是感觉细节上还是差了一点。尼康的刀法也不比老黄差啊。这一张可能是我最喜欢的几张之一，我趴在栏杆上使用了一个相对低的角度拍摄，拍摄的时候就刻意让水下的倒影和水面上的花朵尽可能一致。而且这是整个池子里唯一一朵粉色的睡莲。等我们一周之后再去的时候，这朵花就已经谢了。在发现水面倒影的好处之后，我又尝试拍了几张手段类似的照片。这一张是白色的睡莲，后期时我故意将水面倒影提亮了。我朋友建议将这张照片竖着裁出来（后面一张），但我个人认为还是横着的好看（前面一张）。我觉得放的太大了，会有一种傻大黑粗的感觉。不过我也拿不准到底哪个更好一些，所以就都放出来了，读到这里的朋友们可以在评论区留个言，说说看你觉得哪种裁切好看一些。关于在LrC中同一张照片按照不同方式裁切，网络上似乎并没有一个同一的答案，至少我看到好多人在一个reddit帖子里说了各种不同的方案。我的方案是调色完成后，创建一个虚拟副本，这样一个按照横屏切，另一个按照竖屏切。这几位也是老朋友了。分别是普通翠鸟，白鹡鸰和小白鹭。白鹡鸰和小白鹭似乎比较常见，我们第二次去的时候就没有看到翠鸟。等等，你是？夜师傅？公园中间有一片湖，湖中间有个小屋。这一次看到一个疑似夜鹭的鸟在里面睡觉。第二次的时候我们看到黑天鹅在围栏外面睡觉。以上就是我第一次去公园探路时所拍到的照片了。第二次第二次是和朋友一起去的。我一个人出行的时候，大部分情况都是我一个人走的飞快，像是在完成什么走路任务之类的东西。而两个人的话，走走停停，要比我一个人逛公园细致很多。所以这一次拍到的内容也更丰富一些。一开始我还以为是大花蚊子（夜鹭幼鸟），但秉持着严谨的态度询问过懂鸟之后，才知道池鹭。在栈道上寻找鸟的时候忽然看到一只鸟飞过来，落在了不远处的岸边。我赶快调整角度拍摄。拍完之后却发现：这谁啊？我咋一点都不认识啊？回家查了一下懂鸟，说是扇尾沙锥。喜加一。拍完扇尾沙锥，我一个回身，走到了另一条栈道上。我一看，这又是谁啊？回家查了懂鸟，说是白腰草鹬。又是一个加新。因为很小只，而且离得很远，相机的自动对焦根本不好用。而且这只鸟动起来非常快，颇有白鹡鸰的风范。回家查了一下，您猜怎么着，人家是黄头鹡鸰，确实跟白鹡鸰论亲戚。来都来了，那就再拍个莲花吧，不过这朵有点老了。只胜在阳光的角度还行。老朋友了，就不多介绍了。近距离欣赏小䴙䴘。第一次去的时候也见到了，但是因为光线角度不对，照出来全是黑的。这次正好光线合适，就拍下来了。本来还想用高速连拍拍一下它入水捕食的动作，可惜我这机器缓存太小，而它的动作又难以预判，折腾了二十分钟也没拍下来。虽然花了很多努力却得不到想要的结果是一件很令人沮丧的事情，但我仍然要强调诱拍是每一个鸟类爱好者都应该人人喊打、积极反对并积极制止的行为。出片当然是一件好事，但我拍鸟是因为我喜欢看各种各样的小鸟，如果出片是建立在伤害他们的基础上，那这个片也就没必要出了。蒲公英，被树林间漏下的阳光照亮。同样因为不知道是横屏更好还是竖屏更好，所以就两者都尝试了。后记以上便是本月的更新了，看起来比较水，实际上也很水。值得一提的是，11月底我从法国订了一台很普通的磁带播放器（类似于早年间的磁带随身听）。我知道他们的音质当然不如卡座播放器好，但是现在想要找到高质量，还在产的磁带播放器可太难了。虽然可以收老家伙的二手，但我认为这样终究是不可持续。虽然磁带早就被时代抛弃了，但是看到人类曾经做到登峰造极的东西就此消失，还是多多少少有些难过。扯远了，就这个磁带播放器而言，我当然是没什么艺术细菌去搞remix。不过我也尝试了往上录制一些音乐，除了蔡琴，效果都不错。不知道为什么，蔡琴的歌曲总是会有很明显的齿音，消不掉。而我购买磁带播放器最大的目的还是想试试看用自己的方法在磁带上存数据——我有一台二手的LTO6磁带机，我知道往磁带上存数据是一个很精密很高端的活儿，所以我也不打算和LTO6作比较。就是单纯地玩儿。不过这些就是以后的事情了。以上，便是全部内容了，感谢各位的阅读。我们下次更新再见。-全文完-
最近在YouTube上看到了一个关于kindle越狱的视频，心里痒痒就去网上搜了一下kindle的价格。没想到当年对上学时候的我遥不可及的价格，如今已经变成了我唾手可得的东西。于是就买了，并不是因为爱看书，就是单纯想玩儿。 关于购买建议 由于之前我没用过任何e ink屏幕的产品，也没了解过电子书这个产品线，所以当时购买的时候不是很了解，并且抱着主要以越狱的目的购买了kindle。事后来看，kindle在这方面并没有给予我太多的回报，因为单纯从硬件上来说，我买的这一款kindle性能只够看书的，连浏览器都不能正常流畅使用。虽然我取得了系统的root权限，也成功地在上面运行了java，但性能实在是太糟糕了。如果不考虑越狱这种玩儿的目的，单纯为了阅读，那么市面上有更好的选择：比如主打开放系统的PocketBook，以及可以无痛安装KOReader的Kobo（尽管我不喜欢这个外形）。如果大家不能接受花1600买个只能振奋你一个周末的玩具，那么请务必不要因为这篇文章的鼓动而去无脑下单kindle。如果你真的想要购买一个电子书，请务必根据自己的需求做好产品调研，寻找到真正适合自己需求的设备。毕竟挣钱不容易，现在经济不好看，花钱更要谨慎。 为什么Kindle也要越狱？我最早知道越狱这个词还是因为早年间亲戚传给我一个好几手的iPhone4，那时候还是ios6到7的过度时段。越狱之后取得了系统的很多权限，装了很多插件，是非常有意思的一段经历。后来因为家境贫寒，用回了安卓，又踏入了root和刷机的领域。只不过安卓刷机刷来刷去，最终还是依赖于自己给自己售后——或许一个系统更新或者一个重启就再起不能了。现如今我用上了港版三星，再也不用为了Google全家桶刷机了。至于Kindle，越狱也是出于同样的目的：取得更多对设备的控制权。抛开安卓系列，大部分kindle运行的是基于linux的定制操作系统，除了精简大部分组件以适配寒酸的硬件之外，最重要的是将用户锁在亚马逊的生态里面。你想要阅读在亚马逊上购买的书？不好意思，你购买并不等于你拥有，一般情况下亚马逊会通过版权保护的手段来加密你下载的电子书，但最终还是亚马逊控制这些书，他们可以不经过你允许地撤销你对一本书的访问，或者修改一本书的封面来为他们的电视剧做广告（即便你购买了无广告版本）。而从阅读体验来说，越狱之后安装的KOReader作为原厂阅读器的替代品，可以说功能非常丰富。例如你可以从calibre利用无线设备连接，直接将你的电子书收藏发送到kindle上，也可以安装插件，比如在阅读过程中选中一段话，让ai解释，以及生成二维码（手机扫码后可以复制到手机上），或者直接绑定telegram bot来发送到telegram上。对于养成类玩法比较看中的读者还可以利用内置的阅读统计功能记录你哪天读了什么书，读了多久，一个月下来看着统计日历，满满的成就感。当然，事后我还发现kindle这种独立的设备极大地提高了我阅读的意愿。原本我是在平板上看漫画，手机上看小说。但最近看小说的频率越来越低，我上一次在手机上看书已经是一个月之前了。为什么呢？手机那在手里就不自觉地往YouTube和b站跑，读到一半弹个通知指不定又干什么去了。总之就是我在手机上可以读书，而且真的读起来体验也不错。但问题就在于，我在手机上读不起来书。所以我想这也是一个单独的电子书所带来的好处吧——手机往旁边一扔，拿起电子书大读特读，管什么朋友发消息同事找我有事，统统看不见。我可以获得一个不受打扰的阅读时段。而且这种体验再配上一套好书，比如狼與辛香料，哇，那这简直是人间天堂，死而无憾了。Kindle越狱导论由于不同版本的固件需要使用的越狱方法不同，并且亚马逊对于未停止支持的设备还在积极更新系统，封堵越狱使用的漏洞，因此越狱的实操会不断更新，但本文不会随之更新（因而我懒），所以这里只简述越狱的大体流程，并给出寻找详细资料的指引。 开始动手越狱之前 如果你决定越狱，请务必熟读相关教程后再操作。为了避免你的kindle自动更新，请务必启动飞行模式，断开网络连接。并采取必要措施阻止更新（例如填满剩余空间，删除根目录下任何update开头的文件或文件夹）。本文不是越狱教程。 截至目前（2025年11月8日），亚马逊已经发布了5.18.6版本的固件，在该版本中，最新的越狱方法已经被修复。一旦升级到这个版本将无法越狱，需要等待新的越狱方法（取决于发现的漏洞，可能需要几个月，也可能需要几年）。在社区的Discord中可以得知，固件版本5.18.5.0.1就已经会对最新的AdBreak造成影响了。而固件5.18.6则是彻底封堵了AdBreak越狱。由于我手上没有任何Kindle设备，因此在简单搜索了一下之后决定购买Kindle PaperWhite 6签名版，因为是32GB存储空间。但新购入的设备对于出厂固件充满了不确定性，我比较期待的是出厂固件在5.18.1以下（即最高版本5.17.0.4），这样就可以使用较为稳定的WinterBreak。目前有两个主流版本，对于5.18.1以前的固件，WinterBreak只需要你登录亚马逊帐号即可，原理大约是通过修改缓存文件，在启动亚马逊商店时执行自定义内容，从而获取系统权限。但5.18.1及以后的固件中修复了这个问题，需要改用AdBreak。正如其名，它需要依赖广告机制来触发，本质上是修改广告以及special offer的缓存来实现点击广告执行自定义内容，因此AdBreak的前置依赖于你的kindle必须能够接收广告。无论哪种越狱方法，他们的目的都是通过高级权限修改文件系统，让原生kindle系统能够接纳我们的自定义密钥，这个密钥可以用于签名固件更新，而我们便可以通过自己创建固件更新文件、自己用自定义密钥签名的方式来向原生系统注入我们想要的修改，从而达到越狱的目的。WinterBreak和AdBreak的目的是向系统中注入密钥，而后面的hotfix则是利用这个密钥修改系统，在系统中刻意为我们用户留一个后门。而执行hotfix则是持久地修改系统，让它为我们保持这个后门的打开。所以后续即便更新了系统，只要安装的hotfix还在，我们就可以运行它来修改更新后的系统，再次打开这个后门。越狱海外版Kindle PaperWhite 6我在下单时赌了一把，我本以为由于库存的缘故，到手后的kindle会老一些，我还提前下载了kpw6的新固件，准备到手之后升级到5.17.0.4再越狱。结果到手一看，它已经是5.17.0.4了，实在是惊心动魄。考虑到这已经是亚马逊退出中国的好几个年头了，国内的货还能这么新，属实令我惊讶。下面简单来说到手后从开箱到越狱的流程吧。首先检查外观，确认没有问题，拆封、开机。开机后直接跳过WiFi设置，因为kindle一旦连上网络就会自动下载最新固件并安装，如果它自动更新到了最新版本，那么我们就没法顺利越狱了。因此跳过WiFi设置后我前往设置页面确认当前固件版本，并连上USB将kindle的存储空间占满，只留下20MB的剩余空间。通常Kindle下载一次更新要50到300MB，只要我们不给它留出足够的空间，它就没法自动更新。确认好版本之后就可以配置WiFi激活亚马逊帐号了。因为无论哪种越狱方法，它都依赖亚马逊帐号。配置好WiFi、登录账号。登录完成后启动飞行模式，将Kindle断网，然后再次插入电脑检查根目录，此时根目录已经出现了update.bin.tmp.partial文件夹了，说明kindle已经在自动下载新固件了。删除之后弹出kindle，它自动重启进入更新了，但好在我早已填满了存储空间，更新失败。最后按照教程下载WinterBreak需要的文件，并根据指示操作即可。大概流程是：下载WinterBreak需要的文件，将其解压后覆盖进Kindle的根目录根据教程触发越狱，看到成功提示后安装hotfix安装成功后运行hotfix，持久地取得系统权限安装KUAL和MRPI，这一步需要注意释放剩余空间。原本我只剩下20MB，多次安装都失败。后来删除了一些无用文件，留了差不多300MB的空间，这样才安装成功安装插件禁用OTA更新，禁用OTA更新后即可关闭飞行模式，放心地让kindle连接wifi了安装KOReader和其他一些实用工具越狱国行Kindle PaperWhite 4我在越狱成功后的下一个周末，将我朋友的PaperWhite 4也越狱了。他的设备是国行，序列号里面有一堆0。但好在固件版本够低，是5.16.6，我将它升级到了最新的5.17.0.3然后进行越狱。当我正准备进行WinterBreak越狱时，突然发现他的设备上没有购物车这个按钮。因为kindle业务早就退出中国了，国行的书店也都关了。在刷了新固件之后可以看到系统刚刚启动时是有购物车按钮的，但很快就消失了。因此我们判定亚马逊并没有使用定制硬件或者定制固件，而是一套固件根据帐号区域来行事。经过一番思索，我决定在他的kindle上登录我的帐号，因为我的帐号是外区的。登录后果然购物车按钮重新出现，但点了之后并没有触发WinterBreak，我猜测应该是切换帐号导致固件清空了商店页面的缓存。于是重启kindle后重新用WinterBreak的文件覆盖进去，这样就成功触发了越狱。越狱之后国行版本就没什么太大区别了，我如常安装KUAL和MRPI这些东西。但切换帐号时遇到了个问题：kindle切换帐号会清空document文件夹，这虽然不会删掉越狱的状态，也不会删掉KUAL和安装的插件，但KUAL和hotfix确实依赖document文件夹中的一些内容作为起动器。于是在切换帐号之前我备份了document文件夹，其中有两个疑似比较相关的文件：KUAL.kual，就是一个0字节的文件Run Hotfix.run_hotfix，内容是当前hotfix的版本号，我的是v2.3.2，就一行，没有空行结尾备份妥当document文件夹之后，我便退出帐号，让朋友登录回他的国区帐号。系统重启之后果然什么都没了，在kindle系统内找不到任何关于hotfix或者KUAL的痕迹。于是我将document文件夹还原，系统重新索引后，KUAL和hotfix的图标就重新出现了。越狱参考资料如前文所述原因，本文并不提供任何越狱的具体指导，但本节将列举越狱过程中我用到的参考资料。首先是本文的开端：It's Time to Jailbreak Your Kindle. by Dammit Jeff (YouTube)（WinterBreak）Your Kindle Can Finally Be Jailbroken Again. by Dammit Jeff (YouTube)（AdBreak）我一开始看了第一个视频，心里有点痒痒，但是没买。后来看了第二个，觉得如果想玩儿就得马上行动了。于是当天晚上就下单了kpw6。随后是一些更细节的资料：https://kindlemodding.org这个网站提供了step by step的教程，并且所有的文件都是从这里下的https://kindlemodshelf.me越狱成功后可以安装这个网站里提到的使用工具，比如scriptlet或者KOReader插件来丰富kindle的功能https://scriptlets.notmarek.com可能有些实用的scriptlethttps://discord.kindlemodding.org/Kindle modding社区的Discord服务器，为我尝试在kindle上运行java时提供关于glibc相关的情报我推荐的实用工具本节将介绍我安装在kindle上的一些实用工具。ScriptletScriptlet是hotfix中附带的一个功能，能够将位于document文件夹中的sh脚本展示在kindle的界面中，并且能够点击运行。https://raw.githubusercontent.com/neura-neura/Check-OTA-status/refs/heads/main/Check%20OTA%20status_current.shCheck OTA Status，运行后能检测并告诉你当前系统的OTA状态。在执行完禁用OTA更新的插件之后，我会使用这个脚本来确认是不是真的禁止了更新。https://scriptlets.notmarek.com/scriptlets/koreader_launcher_no_framework.sh使用无Framework模式启动KOReader。由于kindle内存和性能有限，因此我在启动KOReader时会选择杀掉系统自己的framework。实际上在阅读时我不怎么会离开KOReader，除了它没有密码保护之外，能够完美替代Kindle原生ui。https://scriptlets.notmarek.com/scriptlets/disable_ads.shDisable ADs。虽然我的签名版没有广告，但我朋友的普通kpw4有。我们在装好KOReader后发现它没法展示自定义屏保，后来我们发现他的kindle是有广告的。如果是外区则需要花费20美元去除广告，但我们都越狱了，干嘛还花那种冤枉钱。于是我直接运行这个scriptlet去掉了设备上的广告。重启KOReader后就可以让KOReader接管屏保了。KUAL扩展KUAL是Kindle Unified Application Launcher的缩写，它提供了一个统一的kindle应用启动器，用来启动我们自行安装的扩展。除了KOReader之外，我还额外安装了两个扩展：kterm这是一个终端模拟器，运行起来就有一个虚拟键盘，你就可以在终端中运行命令了。usbnetlite这是一个提供ssh访问的扩展。虽然它的ssh终端兼容性不佳，例如缺少环境变量，无法提供正确的terminfo，导致诸如top这类命令无法启动。但对于执行复杂命令来说，能够在电脑上远程敲命令，怎么不比kterm在e ink上的模拟屏幕强多了。KOReader插件KOReader最初的使命就是打造一个Kindle/Kobo Open Reader，这也是它名字的由来。它本身就内置了好多插件，并且还提供一个灵活的插件系统以及用户补丁系统（允许用户无需重新编译软件即可修改软件的行为），但本节将介绍我额外安装的插件：Telegram Highlights即便KOReader本身能将选中的文字生成二维码，但操作起来还是比较复杂。这个插件能够将选中的文字以及截图发送到你绑定的Telegram Bot上。不过这个插件并不是直接和telegram通信，而是需要经过一个中转服务器。插件将数据发送到这个中转服务器上，然后中转服务器再通过telegram服务器发给你。这就意味着你通过这个插件发送的一切都会被运营中转服务器的第三方知晓。不过这个中转服务器是开源的，你可以自己搭建。AssistantAI助理，我用的Gemini 2.5 flash，因为pro太贵了，用不起。这个插件本身内置了一些提示词，比如翻译、解释、词典之类的。你可以自定义提示词，但我现在也想不到什么独特的提示词。我认为这其中最有用的就是词典和解释了，你能够选定一些词来问AI这是什么意思，在词典模式的话，它还可以根据上下文来详细解读。非常好使，不过缺点是需要挂代理。后记以上便是我给Kindle越狱的经历了。很幸运地赶上了非常方便越狱的固件版本，但受制于硬件，虽然后来我成功地跑起来了Java 11（再新的版本就因为过时的glibc版本而无法运行了），但基本上也做不了太复杂的东西。就算是TUI，由于e ink屏幕只能显示黑白或灰度的像素，因此能使用的库也十分受限。这个Kindle在我手中已经两周有余，但和最初买它的目的不同，没能发挥它在读书之外的功效，但令我很意外地，它促使我每天开始读书了。最近刚刚读完狼与辛香料的第九本，太精彩了。读书真好。-全文完-
国庆假期和朋友一起去香格里拉玩儿了，因为之前一直都在昆明市区里面转，已经转腻歪了。加上我们在六月份都购入了长焦镜头，就想着出去找地方拍拍鸟，因此就决定前往香格里拉。本文记述此次旅途。行程规划鉴于我们两个都不太喜欢规划行程，因此还是我主导了规划的事情。这次观鸟主要参考了7天•香格里拉冬季观鸟- 行程路线 - 山鸟社这篇计划。原本是打算复制一个的，但是鉴于国庆期间滇金丝猴国家公园专家别苑的住宿太贵了，而且行程太紧，再加之我们二人对看猴没什么兴趣，反而还怕猴儿给我新配的眼镜抢走，最终我们决定放弃这段行程。原本计划是和山鸟社的行程一样，想着住在景区里面方便看鸟。但是我看到一些测评说住在专家别苑并不能让游客开车自己转，还是要做摆渡车。这样一来就失去了好多自由度，后续在普达措也印证了这一点，如果区域之间必须要乘坐景区提供的摆渡车才能到达，那游玩体验就会大打折扣。取消的另一个原因是住在景区里就意味着完全封闭，当然你可以出来买东西再买票进去，但我的钱不是大风刮来的，该省还是得省。从结果来看，这次取消虽然减少了行程的内容，但时机却很恰当。于是我们的行程就变成了：9月30日下午乘火车从昆明前往香格里拉10月1日去取租的车，四处转转熟悉一下前往各个景区的路线10月2日前往普达措国家公园10月3日前往高山植物园和纳帕海10月4日和5日待定原本是3日高山植物园，4日纳帕海，5日留作机动。结果后来得知高山植物园和纳帕海在一个地方3号在酒店查香格里拉附近还有哪可以去，看小红书说有个月亮湖，我们就去了9月30日火车前往香格里拉9月30日下午我们乘坐C642次列车从昆明出发。买票的时候本来想买10月1日的，结果我因为不常坐火车，不知道火车票有多火热，打开12306一看，我草，一张票都没了。于是不得已买了9月30日下午的。本着尽最大努力避开熊孩子的想法，我们往返买的都是商务座，有点贵，一个人单程800块左右，但坐下来体验非常不错，类似A350-900的反鱼骨布局，但只反了一半：在飞机上左右两侧都是朝向窗户的，左边朝左，右边朝右。而到了火车上，左边确实朝左对着窗户，可是到了右边还是朝左的，这样就只能对着走廊了。我认为这是高铁想要学飞机两仓的布局，但又处于成本，直接左右两侧复用同一款座椅模具。唯一美中不足的就是C字头，也就是云南省内的城际列车降本增效了，商务座不管饭了。火车上一路全是隧道，手机扫码根本没法订餐。最后我们一路走到餐车，我掏出在钱包里躺了好久的100元纸钞，正好买了两份饭两罐芬达。我就说数字支付不行吧。由于9月30日大家还都在上最后一天班，因此商务舱人不多，直到下火车之前都非常舒服。我们的火车是晚上10点半到达的香格里拉。从昆明出发时我还穿着短裤短袖，可是到了香格里拉我一看列车员连羽绒服都穿上了，我就觉得不妙。下到站台品了品——果然好冷。出站后我们直奔网约车上车点，驱车前往希尔顿。为什么住希尔顿呢？因为它便宜，而且还有位置。景区边上的住宿平均一千多一晚上，而希尔顿只要500多。什么？你问为什么不住全季？因为我手慢了，全季已经满了。10月1日开车四处溜达在香格里拉的几天里，我们在一嗨上面租了个车。原本想租大众帕萨特的，结果手慢了，全都租完了，于是被迫选择了日产新天籁。这款车够宽够长，唯独不够高，每次我进出驾驶位都要碰到头（当然，也可能是我驾驶座调的不对）。我们从10月1日上午10点开始租，一直到6号下午6点，保险全都拉满，加上还车无忧和油费，总共是花了2471.28元。在油费方面，因为我们选了无忧还车，因此不满油还车可以免受加油手续费，只需要按照当日油价补差价即可。油费79.28元，当日香格里拉加油站的92汽油价格为7.55元每升，差不多10.5升油，我们这几天一共开了325公里。全程开了ECO模式（其实拿到车就是开着的，懒得关了，除了踩油门反应肉，其他的没啥毛病），百公里油耗3.23升。这对吗？这不对吧。整车1460kg，加上我们两个人300kg，在加上大约20kg的随身行李，总共1780kg的物体，在平均海拔3500米的地方跑了325公里，百公里10.5L？我看网上测评，极限节油的情况下也得百公里4.4L，人家还是在平原上测试的。开了空调油耗就到百公里5.8L了。我不可能开出百公里3.23L的油耗。我问了Gemini，它说租车公司极有可能给出了错误的油量，虽然我的驾驶习惯能让发动机在车辆滑行时节省燃油，但不太可能将整体油耗降低到3.26L每百公里。Gemini综合估计我的实际油耗可能在6L每百公里吧。由于保险都拉满了，所以取车还车都很顺利。停车时虽然蹭了轮毂盖，但是一嗨也没找我额外要钱。非常好。在开车出去溜达之前，我们看到希尔顿有点餐送到客房的服务。送一次收取餐点金额15%的服务费，但是因为我们点的菜有好几个都没材料了，并且送餐送了一个多小时，因此服务人员免收了我们服务费。忘记拍餐点的照片了，但总体而言我觉得偏贵。但后来我才知道，我口口声声说昆明是美食荒漠，是我太大声了，香格里拉才是。在香格里拉的这几天，我们每天早饭都是KFC，晚饭点一次外卖翻车一次，附近古城的餐厅更是不太敢闯。总之，吃好了午饭，我们就按照普达措-高山植物园-纳帕海环湖路西侧-石卡雪山的路线出门溜达了。由于当日我在开车，因此路上没拍照片。普达措我们到了停车场就下来找厕所，没拍照片。高山植物园门口的天空之门据说这里是小红书上一个出片点，当时确实也有好多人在拍照。但这个地方是在高山植物园门口，其实和高山植物园没啥关系。这个是纳帕海上的一个经幡，不过上面似乎并没有印刷或书写佛经，不知道是不是专门搞出来给游客看的。当时正在看风景，突然看到有鸟，这我能放过？通体乌黑，鸟喙是红色的，经查，这应该是红嘴山鸦。这个是混在同一片鸟群里的，但这些鸟喙是黑色的，应该就是普通的乌鸦。纳帕海环湖路西侧后来我们驱车来到了纳帕海环湖路西侧（高山植物园在东侧）。也不知道开了多久，有一个探出去的迷你半岛。路边正好有卖牦牛肉串的，此时已经晚上六点半了，我们也饿了，于是就停下来买点吃的。在等肉串的时候，我又注意到水面上有鸟，于是掏出相机开始拍摄。这些是白骨顶。这是小鸊鷉一家。这是随便照的风景。以及一个很近的大经幡，上面确实没有印刷经文。10月2日普达措森林公园普达措国家公园标榜自己是中国大陆第一个国家公园，但显然不是管理最好最用心的。景区目前只开了三个景点，景点之间要用摆渡车作为交通，不能自驾，也不能自由决定游玩顺序。早上9点半进，玩了一圈晚上5点出。很显然观鸟是不现实了，时间和鸟类活跃的时间对不上。第一个景点是个原生态步道，感觉不错。但公园在景点缺乏管理，导致小孩子老头老太太人手一个塑料袋在那捡蘑菇，所到之地寸草不生的那种摘法，就很讨厌。同时入园不查火种，写了禁止吸烟，结果一个大哥跑小树林里点了一颗。不过抛开这些缺点不提，原生态是非常到位的：上面这张应该是绿背山雀，当天阴天，所以光线不佳，而且小体型的鸟动作非常快，没什么抓拍的机会就飞走了。鸟群中不止这一种鸟，下面这张应该是煤山雀。这张看上去像是褐头山雀，但查阅了一些资料发现这个可能是川褐头山雀。我分不清二者的外观区别，但从分布来看比较可能是川褐头山雀。第二个景点是属都湖。花了90租了个自行车。林道不错，面向一般大众的。但是林道容易，自行车就不容易。那个破车啊，挑了半天勉强找到一辆能骑的，导致这3.6km林道的体验极差。建议直接坐船跳过这段，毕竟船票只要65。第三个景点是碧塔海，那个栈道一般。而且不知道咋回事，可能是栏杆和我包蹭来蹭去，把我水杯蹭出来了。我的水杯掉到了自然保护区里，痛失一个杯子。而且这个景点较前两个景点商业化严重许多，完全可以不来。来了也看不到什么，因为现在就开了前1/4。同样地，这里的景区管理也不行，一直说不要离开栈道，但有些家长带着孩子都上山了，志愿者轰都轰不下来。从观鸟的角度来看，这里也没什么鸟。上面是老朋友白鹡鸰，下面是隐纹花松鼠。这里有好多游客在投喂松鼠。如果说整个森林公园封闭景区是为了保护的话，那到这里我也非常理解景区的做法了，但是我依旧对不能自由穿行景区而感到遗憾。以防你不理解我的文字：且不说告示牌和工作人员都在不停的说不要投喂松鼠，广播里还不忘科普人工投喂会损害松鼠和其他野生动物自主觅食的能力，单从常识的角度来说，观赏野生动物就不应该和其产生任何互动，更别说投喂了。这不是剥夺游客的乐趣，这是为了保护生态。或者更直观地说，在生态价值面前，游客的乐趣与体验一文不值，毕竟这里不是动物园。当天中午没有在景区里吃饭，早饭肯德基，午饭全靠士力架顶着。我都怕给自己顶出糖尿病了，这玩意儿真他妈甜。当日单人花费256元，不是很值，不如武夷山。10月3日高山植物园与纳帕海高山植物园是让我喜出望外的一个景点。首先这里人很少，可能大家都是奔着小红书的天空之门来的，植物园直接pass了。我们在园内逛了一上午，除了我们自己只看到了6个游客。里面蚊虫不少，但是我带了含有避蚊胺的驱蚊液，效果拔群，没有被咬。而且由于植物众多，没有什么人，因此拍到了许多鸟。如果单从观鸟的角度来说，这是整个行程中最棒的一个地方了。由于高山植物园也有科研性质，因此我也推荐大家去买张门票进去看看，20一个人还要啥自行车。我们去的时候不在花期，但我觉得风景也不错。另外还能顺便资助一下高山植物的保护，虽然我对植物一窍不通，但我知道鸟类栖息还是十分依赖植物的。高山植物园对于高原上的原生物种的保护与保存还是贡献挺大的。可惜天公不作美。还记得9月30日下了火车我说冷吗？可能是那个时候开始感冒的，到10月3日已经开始有明显的乏力了，我连180-600这颗镜头都举不稳了。回来筛选照片的时候经常看到鸟在照片中四处乱动——这不是鸟在动，而是我实在没力气稳住镜头了。但这时还好，还没有强烈的症状。虽然乏力，但我还能动。由于拍到了好多张鸟照，下面将根据物种分类。黄腹柳莺虽然是柳莺，但是我之前从来没见过，算是加新了。红喉姬鹟红喉姬鹟也是我先前没见过的鸟，现在不在繁殖季，所以颜色没那么鲜艳。但从一些照片可以看到它喉咙处有淡淡的黄/橙色。此外，经过查询Birds of the world，我头一次知道这类小体型的鸟类也会远距离迁徙，之前一直以为只有像海鸥那么大体型的鸟才会迁徙。红喉姬鹟体长11.5厘米，体重大约在8到14克之间。红喉姬鹟的迁徙路线和越冬地目前上不明确，但科学家比较确信可能至少有三条秋季迁徙路线：位于西伯利亚西北部的红喉姬鹟会向南途径乌拉尔山脉与阿富汗，最终抵达印度。这条迁徙路线的个体最少，并且该路线与它们的亲戚红胸姬鹟迁徙路线重叠。位于西伯利亚中部的红喉姬鹟会向南穿过蒙古和中国中西部，抵达缅甸及更远地区。香格里拉正好在这条路线上，因此我们拍到的红喉姬鹟正要前往缅甸。最后位于西伯利亚东部的红喉姬鹟会向南途经中国东北部和东部，前往东南亚。后两条路线是红喉姬鹟大部分个体会选择的迁移路线。它们在俄罗斯中部和东部的过境时间为8月上旬至10月下旬；于9月至10月间抵达中国西部、印度、孟加拉国、缅甸和泰国；于10月上旬至11月中旬抵达香港。在中国东部的过境时间则在9月中旬至10月下旬之间。春季回迁主要在4月份，部分个体要到5月才开始，在中国北部和蒙古的过境高峰十分明显，并会一直持续到6月上旬。并且它们在日本、韩国、菲律宾西部（巴拉望岛）、婆罗洲、安达曼群岛以及美国西北部（阿拉斯加）均有迷鸟记录，其记录分布最西可达英国。这么小体型的鸟每年都要进行这么长的迁徙，真厉害啊。黑眉长尾山雀黑眉长尾山雀也是我这次新见到的鸟种，是三有动物。橙翅噪鹛橙翅噪鹛，还是加新，而且这个是国二！一开始注意到它是因为它的叫声和环境中的其他鸟类很不一样。其他鸟类都是短促的一声，只有它是比较长比较婉转的叫声。于是驻足停留了好久才在树丛中找到它。除了第一张我和它对视，其他的还挺有国二风范的。这里一开始我以为是松鼠，因为是路边松树林里面的地面上有窸窸窣窣的声音。但是因为杂草和树枝什么的太密了，没看到。走来走去移动视角才发现这不是松鼠，还是橙翅噪鹛。应该是在地上找吃的。黄眉柳莺这张照片认了半天，我和AI都搞不清这是什么柳莺。就当它是黄眉柳莺吧。10月4日月亮湖3号回到酒店就在想4号要去哪里，看来看去在小红书上有人提到月亮湖，在高徳上看周边也看到了这个景点，于是想着那就去看看呗。开车开了一个多小时，到了之后发现就一大片草原加上一滩水。有个大姐看我们拿着相机，非说要让我们给拍几张照片。我拍了几张，感觉16-50这个头拍人像不太灵，于是我决定及时止损，让我朋友带着他的索尼20-70上。除此之外就没什么了，简单逛了逛，走到了水潭周围的地方，结果鞋湿了。过了一会儿开车又回去了。拍了一些照片，但选来选去没什么出片的，就算了。我本身也不擅长拍摄风光和人像。其实这一天开始感冒的症状就有一些严重了，但是因为这几天我一直预防性地吃新康泰克，所以有发烧的症状但是不明显。开车的时候集中精神有些费力，但也不是不能开。10月5日在希尔顿趴窝5号本打算开车去白马雪山哑口，走老214国道看雪山。但这一天一醒来就觉得非常乏力，而且精神涣散。由于没有体温计，所以没法确定是不是发烧了。看网上的视频得知老214国道路还是比较险峻，周围没有护栏，而且单程要开3到4个小时，我想了想，还是算了。虽然租的车保险拉满了，翻下山去直接报废都不用我赔钱，但是我还是比较惜命的。万一开车走神翻下山去，那被人找到的时候就只能拿勺㧟了。所以综合考虑还是不要冒险了，大不了下次再来嘛。于是这一天就在酒店修整，顺便收拾东西准备6号返程。下午把车还到火车站。10月6日返回昆明6号一早前往火车站乘坐C640次列车返回昆明，还是商务座。当列车开出香格里拉，从海拔3500米下降到2000米，我感觉我的感冒一下子就舒服了一半。这个教训告诉我们：如果一定要感冒发烧的话，一定不要在高原。此外我还发现真是林子大了什么鸟都有。自己上错车厢，然后发现9车不能前往8车的。大部分人询问列车员后发现过不去，一般也就认了，毕竟自己没提前就位，慌乱之中上错了车厢，等下一站去站台走过去就是了。唯独这其中有一对中年男女，从列车员处得知自己过去不后开始恼羞成怒，对着列车员大喊大叫，扬言要投诉他们。怎么？你说投诉就能把9车厢的牵引车头改成列车让你过去？招笑。有时候真的替服务业从业者觉得不公，怎么什么傻逼都能遇到，遇到了还不许还嘴，太憋屈了。我旁听时都想要替列车员骂他们几句，自己不早来还要投诉人家，干脆给你开个专列得了。不过想来想去，沾这种屎干嘛。最后快到昆明站的时候，还有三个人下去抽烟，站台上的工作人员喊了好几次让他们上车，就不听，车里的也叫他们上车，就不。就喜欢抽那口烟，结果车门关了，没上来。招笑。我在这里还是建议大家要提高自己的素质与修养，当然不能为此变成任人宰割的绵羊，但素质和修养永远是文明与友善的名片。总结这次香格里拉之行算是我第一次规划一个旅行吧。严格来说第一次独自旅行是2023年前往昆明找朋友玩，那也是我后来决定暂住昆明的契机，但是从规划来说，当时并没有严格的时间表，所以并不能算是真正的旅行。这次我从头到尾查资料、决定行程，定车票和酒店，还挺新鲜的。虽然旅途中有好有坏，后面感冒发烧还挺难受的，但是高山植物园作为观鸟体验的高光时刻，我觉得这一趟真的不虚此行。我朋友说旅行就是一个祛魅的过程，还真是。我一开始对香格里拉的各个景点是有一些自己的想象的，但是很显然这些想象都没有对上。我一开始想象纳帕海应该是一大片水，然后周围有沙滩或滩涂，我可以站在公路边上的沙滩上用长焦远远地拍摄前来觅食的鸟类，这原本是我此行中期望最大的地方，但实际呢？纳帕海已经被当地居民圈地变成一个模式化的商业地块了——花海拍照、抱小羊拍照（小红书上还看到一些关于动物福利问题的讨论，例如为了避免小羊在游客身上拉屎，一天不让吃草之类的）还有骑马遛弯。而且根本没什么迁徙来的鸟，有些大失所望。你说风景吧，风景确实不错，但也并非精采绝伦、非看不可。所以我觉得这地方的体验真不算好。而高山植物园则是我期待最小的一个，因为我原本想高山植物园可能树林很迷，林鸟不太好拍摄，因为光线之类的问题，可能拍出来会很昏暗，要么快门速度上不去糊成一团，要么iso被拉爆全是噪点。但我万万没想到这个植物园和我想的完全不一样，而且是此行中观鸟体验最好的一个。果然人不应该根据自己有限的经验去揣度没有见过的东西。关于ISO和噪点的问题，ISO高并不意味着噪点多。抛开不同CMOS的高感能力不同，通常在高ISO的情况下，这意味着你的相机在当前光圈和快门速度设置下不能获取足够的进光量来将所有像素亮度的平均值维持在一个中性点。说人话就是欠曝了，所以相机只能通过增大ISO提高增益的方式来提亮画面，这样做的代价就是会放大噪声，而由于你的进光量不足，就导致信噪比很差，自然就会产生很多噪点。结论：ISO不产生噪点，但它是衡量进光量和噪点的一个指标。至于普达措嘛，只能说有好有坏，一开始我也没什么太大的期待，因为山鸟社的行程一开始就没它。这是在决定不去滇金丝猴公园之后才找到的景点，所以本身期待就没那么大。最开始我对它的想象就是武夷山，毕竟武夷山也是靠大巴车在景点之间移动的，但从现实体验来说，普达措差远了。尤其是租赁自行车那一块，真是整个公园最大的败笔。彩蛋：I'm Nikon一个梗罢了，别当真。尼康的对焦大部分时候还是挺好的。对不上多半是因为没设置好。-全文完-
【歪门邪道】从零开始摸索的照片后期工作流
鸽了好几个月，本来打算4月就写这个话题的，但是因为一直有别的写，就一直在往后推。前几篇文章答应要写了，所以这一篇终于开始写了。那么闲话少说，书归正传吧。前言说起来我并非什么专业摄影师，至今不会人像拍照，而后期方面也全看自己摸索。上一次有个飞机的照片，天是灰色的，我也不知道怎么捣鼓的，就把天拉蓝了，毫无技巧，全靠感情。色彩理论什么的我也不懂，总之就是没有任何技术性的修图。所以本文并不旨在分享后期修图技巧，更不是面向专业摄影师（如果真是专业摄影师的话，搞不好还得笑话我在粗糙原始的修图手法呢）。本文侧重的是介绍我在摸索照片后期工作流的过程，并向其他业余爱好者介绍我现有的一套成熟的从拍照到出图的一个稳定流程。在这套流程下，兴致来了就仔细修修，困了累了就差不多裁剪一下拉一下对比度就出片了。总而言之，我的目的并不是为了好看和卖钱，我的工作流更侧重于将我之前拍的照片稳定地转变出成片，不至于落到摄影成为只按快门的爱好。当然了，就算在摄影爱好者的范围里，我这套工作流也不算什么特别好的成果，只是希望能够抛砖引玉，给还在探索不同后期软件组合的人一些参考资料。如果你有更好的方案或软件，也欢迎在评论区友善地分享。尼康工坊尼康相机嘛，当然最开始用的软件就是尼康工坊了。这个软件是免费的，也支持NEF的各种格式，如果你要后期做摇摇乐，这个也是必不可少的软件。只不过对于Z50 2来说，尼康工坊为数不多的好处之一就是能够读取照片拍摄时的优化校准，并且后期能够调整和切换不同的方案。其次就是能够显示出照片的对焦点，只不过在我的测试中，对焦点在鸟身上并不意味着镜头的焦点就在鸟身上，所以最终还是得要人眼去对比哪张对焦的更好。在编辑方面，基本的功能都有，而且尼康专属的各种功能都可以调整，比如动态D lighting和人像柔和之类的，这些功能虽然在其他软件中也有平替，但尼康工坊中对于这些功能的调整在效果上是和在照相机内调整的效果是一致的。尼康工坊在我拍照初期承担了我拍照后修图的工作，在我拍了大约1300张照片之后，我发现这个软件的功能和性能还是不能是我满意。从性能上来说，尼康工坊导出一张照片要好久，而我是将NAS的一个共享通过SMB挂载到我的电脑上来访问，这样一来就更慢了。而且从功能上来说，单是导出格式就十分受限。尼康工坊能导出jpg、tiff和heif格式的照片。如果之后你有专业处理的需求（例如放进photoshop进行处理，或者使用一些计算软件来后期，常用于星空摄影等），那就只能选用tiff格式了。但是此时文件大小会从NEF格式的25MB上下膨胀成125MB左右，十分占用空间。至于编辑照片本身，界面可以说是能用，但比起Lightroom还是差得远。在功能上也并不完全，例如LrC可以选择蒙版，对前景和背景分别处理，但尼康工坊就做不到。至于光学矫正方面，人家都叫尼康工坊了，你还指望它支持腾龙？如果你的NEF文件里面有机内矫正数据，那尼康工坊就能根据这些内嵌数据做矫正，如果没有，那就没办法了。当然，以上问题还是只我当时意识到的。从现在工作流来看，尼康工坊（和其他大部分工具）都缺乏一个好用的素材管理功能。Affinity Photo 2这个软件我之前在寻找photoshop平替时就买了。虽然它主打照片编辑，但比起LrC，它更像是PS。但界面和PS完全不一样，需多操作的概念也不同，在重新学习上比较麻烦。在上手过程中我也注意到Affinity Photo的资料比较少，而且有些是过时的。例如我一度想要调整界面的缩放，因为我的笔记本15英寸2k屏幕，字看上去有点小，我想调大一点。官方的中文操作手册说可以调，但我找了半天也没找到手册上说的设置，最终只好放弃。如果真要学习的话，那我建议学好英语，去Youtube上搜教程视频，跟随讲解操作，这样会简单明了不少。除此之外，这个软件也没法完全替代尼康工坊。尼康工坊好歹还有个文件夹目录选照片的功能，这个软件就和PS一样，你只能选一张照片打开，完事了再去处理其他的。我认为缺乏最基础的浏览功能对于照片编辑来说就是致命伤。至于编辑功能本身，如果能熟悉这个软件的操作的话，功能还是挺全面的。首先打开NEF时和ACR差不多，有一个解码RAW的过程，在这里你可以调成诸如曝光、对比度、色彩、镜头矫正之类的功能。关于镜头矫正，这个软件自己带了一些镜头的数据文件，并且随着更新会添加新的镜头。在这个界面调整完成后点击“开发”按钮之后，图像就会被栅格化，之后你就可以像Photoshop那样精细地编辑这张图片了。至于那个按钮为什么叫开发，我估计是叫develop吧，这个词在英文中也有对胶片胶卷冲洗的意思。这个软件其实从功能上看还挺不错的，如果你的工作流比较偏向于使用Photoshop，那么这个软件配合尼康工坊可能会比较合适：首先在尼康工坊中筛选标记有希望出片的照片，然后在尼康工坊里选择使用这个软件打开。不过对我来说，我并不喜欢Photoshop那样过于精细化的编辑，这种强大的功能对于我的工作流来说反而还是负担。所以我最终没有选择Affinity Photo 2。Capture One在寻找其他照片编辑软件的时候，这个软件由于出众的色彩解析能力进入了我的候选名单。但在了解了定价方案之后，我直接将它排除：Pro版是能在电脑上运行该软件所需的最低订阅档，目前的价格是年付214.2美元（合17.85美元一个月），如果按月订阅的话则是27.3美元一个月。他们也提供买断的许可证，但官网原话是“适合不依赖我门最新更新或硬件支持的摄影师”，而在支持论坛上的帖子则解释说买断的许可证并不包含功能更新，只包含小版本号（X.Y.Z中的Z）的bug修复的优化。当他们更新了新功能时（例如从16.5更新到了16.6），你需要重新购买pro许可证才能获得更新。这样的许可证价格是345.45美元（之后重复购买可获得大约20%的折扣，但还是很贵）。至于他们的更新频率，他们在论坛的帖子上提到他们从一年一更新移动到release when ready模型，也就是说只要他们的新功能开发完毕就会发布新版本。我认为这从经济上看并不划算（不适合我），我顶多算是一个摄影爱好者，对于编辑软件的利用率不高，采用订阅制就意味着我闲置的时候也在为它支出。而买断制的定价和发版模型也并没有很良心。所以最终我决定跳过试用直接将其淘汰掉。当然了，富哥和有钱的退休人员随意。关于买断和订阅，我个人一直非常讨厌订阅制。如果你说你提供服务，比如我租用服务器，或者使用密码管理器这一类的东西，那按月或按年付钱是可以理解的。但你说软件这个东西，把更新绑定到订阅上也不是不行，可是你又没有约定你每个订阅周期一定会有多少个功能更新，更新多了你不乐意，更新少了我不乐意。如果说把使用权和订阅绑定在一起，那就更没道理了，使用权并非服务，我为何要付钱？所以目前我接受订阅制的只有明确服务内容的东西，以及不太贵的东西。至于其他的，能按量付费就按量付费，如果商家给脸不要脸，那我只能盗版了。Luminar Neo在见识过了昂贵的软件之后，Luminar Neo以AI照片编辑的亮点进入了我的视野。但经过简单试用之后我发现其功能并不能满足我的编辑需求。由于当初试用时恰逢Z50 2发布没几个月，因此对于NEF的支持也不完全。当时我测试的无压缩NEF可以支持，但高效压缩就不行。并且它既无法读出尼康的色彩方案，也没法读出原始颜色，就导致所有使用了色彩方案的NEF加载出来的颜色就很奇怪。总体来说我对这个软件不是很满意，因此以NEF不兼容为借口向客服退了款。至于定价：永久买断119美元，包含购买后一年内的所有更新，之后的更新需要支付额外的升级费用（类似于老版本升级折扣）。根据Reddit上的信息来看，这个升级费用大约是一每6个月50美元左右，相当于以40%或50%的折扣每年重新续订。我感觉这个价格比JetBrains和Capture one都良心。只不过考虑到这软件的功能嘛，只能说不适合我。RawTherapee开源免费，但是不太好学，功能比较复杂，并没有所谓的out of box支持，只不过自由度非常高，如果你有一个移除拜尔滤镜的机器，那你可能不得不用这个软件将RAW文件解析为黑白的。只是对我而言我需要开箱即用的支持，我并不需要对RAW文件有多高的自由度，我只是想编辑照片，所以这个软件pass。DarkTable也是开源免费的，而且说是针对摄影师打造。但是吧，你看那些个卖相机的哪个公开了自家的RAW文件格式？一个个的都得靠逆向。虽然开源的想法很不错，可是现实一点也不美好。只能说如果一定要在Linux上编辑照片的话，darktable可能和rawtherapee一样是唯一的选择，但我有Windows。DXO PureRAW 4我最后测试的就是DXO家的软件了。最先是DXO PureRaw，因为看中了他们的降噪能力，虽然也是神经网络降噪，但架不住效果好哇。而且DXO他们自己有针对不同的相机和镜头制作光学模块，他们会买来对应型号的相机和镜头，在他们的实验室里面拍摄一系列测试照片，然后基于此制作出一套色彩和光学的矫正模块。在我评估这个版本的时候，他们还不支持Z50 2，直到今年2月份他们发布更新，我赶快下载下来试用，感觉不错。但PureRaw毕竟是处理RAW文件的，输出一个DNG格式，方便你进行后续的处理，这个软件本身没有任何编辑与调色的功能。它就是很朴素的以他们自己的方式解析DNG文件、还原色彩、矫正光学。由于效果不错，再加上我想一步到位，于是就看了看他们家的DXO Photolab 8。顺带一提，现在他们家出PureRaw5了，好像还新增了富士还是谁家的那个XTrans传感器的支持了。买断制130美元，如果你之前买了PureRaw3或4，那么可以按照90美元的价格升级，大约是30%的折扣，还是比Capture one良心。忘记说了，DXO家的软件和LrC联动都非常好。对于PureRaw，你甚至可以在LrC里面操作它的界面来处理你的RAW文件。DXO Photolab 8DXO Photolab 8这款软件是我目前认为最贴合我的需求的软件之一，除了它那个看起来有点吓人的启动界面。买断制售价240美元，从6或者7升级上来时120美元，相当于50%的折扣，非常良心了。在功能方面，除了全面包含PureRaw的降噪和矫正功能，它还提供了完整的编辑模式，例如常见的曝光、调色等，还有一些DXO自家的功能，例如Smart Lighting，它可以在不用你手动调整高光阴影的情况下自动调整图片的曝光度，同时增加一些明暗对比以“解锁阴影和/或回复高光来优化动态范围”。还有DXO ClearView Plus，类似于LrC的去薄雾，能够淡化大气薄雾和朦胧效果。至于其他什么色彩曲线就更不用说了。对于调色来说，它支持不同的渲染方式，你可以通过类似预设的方式来模拟不同的相机或胶片的渲染效果，你可以通过氪金DXO FilePack插件来获得更高级的胶片模拟效果。不过我本人对胶片模拟并不是很感兴趣，所以就没充钱。除了模拟其他颜色，它还可以对照片应用LUT，这我还是头一次见。当然，如果只是做成这样的话，那只是一个更高级的尼康工坊罢了。我之前说过尼康工坊不能局部调整，而DXO Photolab 8就有这个功能，虽然没有LrC那么花哨的自动识别主体或前景，但它的U Point技术好像也挺厉害的，只不过我没怎么用过，看起来也是多少带点自动识别的技术在里面。除此之外，对于裁剪、修补之类的需求，DXO Photolab同样也有。虽然LrC有AI自动修补，但从实际体验来看，首先你需要全局代理，其次Adobe那个AI有时候修补的结果很诡异，大部分时候并不好用。我通常使用图章这类工具将要移除的元素圈起来，然后使用临近的背景去填补。DXO Photolab也提供了这个功能的平替，总体来说除了素材管理，它几乎可以完美替代LrC了（是的，色彩空间管理和软打样人家也有）。说到素材管理，其实DXO也有类似的功能。和LrC一样，分为文件夹、项目组（收藏夹集）和项目（收藏夹）。我目前在LrC上的文件管理流程完全可以搬到这个DXO Photolab 8上，但用户体验会有折扣。首先DXO PL 8没有缓存（类似LrC智能预览或1:1预览），因此当文件离线的时候你完全无法预览。其次是元数据的数据库没有备份。虽然和LrC一样，大家都推荐不要共享本地数据库，但LrC可以设置定期将数据库备份，我是将备份全都存储到了NAS上，这样不怕丢。DXO PL8提供了手动备份的选项，但不能自动备份。对于我这种经常忘记事情的人来说，手动备份就等于没有备份。当然，没能让PL8完全替代LrC的关键就是它和LrC的联动太丝滑了。在安装PL8的时候，你可以让安装程序给LrC安装一个插件，借助这个插件你可以将选定的文件交给PL8处理，处理完成后自动将结果导回LrC并放入一个新的收藏夹来和老文件做区分。Adobe Lightroom Classic这个软件常被简称为LrC，由于从小学开始就接触了Photoshop CS6，因此Adobe对我来说一直都是多媒体行业的标杆企业，直到他们吃相难看地强制所有人都购买他们那个订阅。就像我之前说的，软件用订阅制是不合理的，如果不能按量付费，厂商又给脸不要脸，那我就只能用盗版了。不过Adobe最近的盗版也比较恶心人，虽然有俄罗斯那边的大佬给做破解，但Adobe自己内置了需多恶心人的东西，稍有不慎破解就失效了。虽然有解决办法，但对于需要稳定使用的人来说是不可接受的。所以淘宝上就催生了需多所谓的正版，其实就是教育版，一年大约400块左右，他们会给你的账号拉入组织。这种方法有时候会不稳定，联系售后重新加入组织就好了。和所有拼车都一样，拼车有风险，上车要谨慎。我喜欢LrC的主要原因还是它的素材管理，能在离线时进行预览，并且元数据管理和搜索做的也比较丰富，整体的界面打磨的也比较好。虽然它在图像处理上可能不是最好的，但从体验来说它是真好用。因此我最终选择把LrC和DXO Photolab 8结合起来用。这里还是要提一嘴尼康的色彩优化。在使用DXO PL8和LrC的时候，他们默认都忽略色彩优化。 LrC可以在设置中调整如何解读颜色，默认是Adobe自己的色彩，如果你选择让照相机管理，那就可以读出色彩优化，不过这对于后期的难度会增加。DXO PL8也是类似，你需要将渲染修改成相机配置文件。所以虽然一开始色彩优化是我的买Z50 2的主要原因，因为我想避免后期，但随着照片越拍越多，我意识到后期是我不得不做的事情。用别人的色彩当然很好，但如果场景不对盲目套用的话反而适得其反。我做事又不喜欢搞一大堆复杂的工具，所以还是直接用默认色彩拍照，我后期想看什么自己调就是了。我的照片工作流这里简单地介绍一下我的照片处理工作流。并不专业，有建议可以提，不爱看就滚。文件处理首先是用Nikon Transfer 2将NEF文件从相机拷贝到电脑上。一开始我还会同时拍摄NEF和JPG，但后来发现JPG的用处不大，所以就不拍了。在NAS中按照日期和地点创建好文件夹，将文件复制到NAS上即可。我在NAS上单独开辟了一个photograph的挂载点，用于存放我自己拍的照片。目录大概是这样子：P:\ ├─export │ ├─云南 │ │ ├─20241227昆明呈贡中央公园 │ │ ├─20241228昆明拍星星-猎户座 │ │ ├─20241228春城公园+呈贡中央公园 │ │ ├─20241229昆明捞渔河湿地公园 │ │ ├─20241231昆明呈贡白龙潭 │ │ ├─20250111玉溪抚仙湖 │ │ ├─...... │ │ ├─20250621昆明东川森林公园 │ │ ├─20250706捞渔河呈贡段G213拍鸟 │ │ ├─20250713捞渔河呈贡段G213拍鸟 │ │ └─20250727沐春湖 │ ├─北京 │ │ ├─20250129除夕 │ │ ├─20250130初二 │ │ ├─20250203奥森 │ │ └─20250205西单随便拍 │ └─香港 │ └─20250118香港故宫 ├─lrc backup │ ├─2025-03-10 2134 │ ├─...... │ └─2025-08-18 2022 ├─nightsky │ ├─in-person │ │ ├─20250418呈贡宪法主题公园南河三 │ │ │ ├─biases │ │ │ ├─darks │ │ │ ├─flats │ │ │ ├─lights │ │ │ └─masters │ │ ├─20250504呈贡白龙潭室女座 │ │ │ └─...... │ │ ├─20250504呈贡白龙潭月亮 │ │ │ └─...... │ │ └─20250605呈贡拍月亮 │ └─skygems │ ├─FSQ106 Namibia │ │ └─28186-0-7_M 42 │ │ ├─blue │ │ │ ├─biases │ │ │ ├─darks │ │ │ ├─flats │ │ │ ├─lights │ │ │ └─masters │ │ ├─green │ │ │ └─...... │ │ ├─luminance │ │ │ └─...... │ │ └─red │ │ └─...... │ └─Tecnosky Newton230 │ └─28784-0-9_M101 │ └─...... ├─raw │ ├─云南 │ │ ├─20241227昆明呈贡中央公园 │ │ ├─20241228昆明拍星星-猎户座 │ │ ├─20241228春城公园+呈贡中央公园 │ │ ├─20241229昆明捞渔河湿地公园 │ │ ├─20241231昆明呈贡白龙潭 │ │ ├─20250111玉溪抚仙湖 │ │ ├─20250511阳宗海 │ │ ├─...... │ │ ├─20250606宪法主题公园拍鸟 │ │ ├─20250621昆明东川森林公园 │ │ ├─20250706捞渔河呈贡段G213拍鸟 │ │ ├─20250713捞渔河呈贡段G213拍鸟 │ │ └─20250727沐春湖 │ ├─北京 │ │ ├─20250129除夕 │ │ ├─...... │ │ └─20250207月亮 │ └─香港 │ └─20250118香港故宫 └─video └─云南 ├─20250726测试森海塞尔MKE600 └─20250727沐春湖一共是五个目录：export：导出的成片，结构和raw文件夹一样raw：拍摄的RAW文件，其下一级文件夹是地区，二级则是时间+地点或拍摄主题，所有raw文件都在二级文件夹中nightsky：夜里拍星星用的，其下一级文件夹分为两个in-person：我自己扛着相机去拍的，其下文件夹是时间+地点或拍摄主题，raw文件会按照biases、darks、flats和lights分类，使用Siril处理，其中的中间文件就放在masters里面，最终输出则放在二级文件夹的根目录，这样点进来这个文件夹就能看到对应的结果skygems：我在skygems这个平台上租用远程天文台拍的，由于他们的设备都比较专业，所以每个通道都会有biases、darks那些文件夹，然后最终将不同通道组合起来输出。并且由于租用设备的不同，每个设备拍的照片会有其单独的文件夹。video：拍视频的，由于我买了森海塞尔的MKE600麦克风，所以开始尝试录制视频了。和raw差不多，也是一级地区，二级日期+地点或拍摄主题。视频使用达芬奇免费版进行处理。lrc backup这个是LrC的自动备份，就不多说了。在LrC中初步筛选由于所有照片都由LrC管理，所以照片编辑的第一步就是导入LrC。当你的照片已经到如果一些之后，LrC会记住照片的所在路径。每次需要导入新照片时，只要在图库的文件夹中找到raw文件夹，右键选择同步文件夹，LrC就可以自动找到新的文件了，目前还从来没有失手过。导入完成后，我会对新的文件夹右键，选择创建收藏夹，就会创建一个与文件夹同名的收藏夹。使用收藏夹的好处就是可以做到照片与文件分离。如果你从文件夹那里选择文件并开始编辑，如果你不小心手滑按了delete，那你的照片文件就会被删除。可是如果从收藏夹里面选择文件并开始编辑，那按了delete也只会把这个照片从当前收藏夹中删掉，而不会实际删掉文件。当然，直接把所有文件扔进一个收藏夹是不行的，我一般会用收藏夹集合。首先给新创建的收藏夹改名，把原来的名字剪切走，改名为RAW，然后在相同位置创建收藏夹集，名字就是你刚才剪切的那个。然后把这个RAW收藏夹移动进刚刚创建好的收藏夹集，这样我们就可以用类似子文件夹的方式管理照片了。接下来我们便可以在RAW收藏夹中查看每一个照片，使用快捷键P将照片标记为有用，U取消标记，X标记为无用。除非对焦模糊或完全没有利用价值，否则我很少使用无用标记。主要使用P标记出有可能修图出片的照片，完成后使用过滤器列出标记留用的照片，全选，然后在工具栏中找到文件、增效工具额外信息、转移到DXO Photolab 8就可以把选定的照片交给DXO PL处理。DXO Photolab矫正、降噪、调色当照片导入到DXO PL之后会应用一个我自己保存的预设。基本上就是默认预设开启光学和色彩校正，开大约10的DXO CleverView，加一点弱的DXO Smart Lighting，色彩渲染选择DxO相机配置文件，自动应用DeepPRIME XD/XD2s降噪（创建这个预设的时候还没有DeepPRIME3）。通常这一套下来会提供一个比较不错的baseline。在此基础上我通常会做一些调色，这方面我确实没什么技巧，就是凭感觉，所以就不献丑介绍了。在DXO PL里面的所有编辑都不涉及裁剪，这样可以保证图片怎么来的，DXO怎么还给LrC。做好之后就可以选导出到Lightroom，我一般都选择应用所有校准，dxo会逐个照片处理，并生成一个DNG文件。最终一并导入到LrC中。在LrC中裁剪、导出成片处理完成的照片我会放到一个名叫DXO的收藏夹中，和RAW放在一起。然后在这个收藏夹中裁剪、构图。如果感觉成片还行，那就打上5星的评分，不行就算了，如果勉强那就打个3或4星，如果成片多就不要他们，成片少就带上他们。在最终调整的过程中可能会做一些微调，但我尽可能避免这种事情，让所有对图像本身的调整都发生在DXO PL那里，因为Adobe这个软件的访问权限并不是永久的。所以我希望即便有一天我不用Adobe了，我还能使用终身购买的DXO PL去打开我编辑过的图片。总之，做好裁剪之后，使用过滤器筛选5星照片，应用元数据模板后导出即可。导出时我用PNG格式，位深度8，色彩空间sRGB，调整图片的长边为3000像素（但不扩大小的图片），分辨率为240像素/英寸。取决于拍摄地点，我会看情况是否勾选删除位置信息。在最终发布前我还会使用exitfool检查图片的元数据，确保元数据不会包含特定的信息。后记以上就是我的照片处理工作流了，虽然一点也不专业，但我认为就目前而言，对我完全是够用了。至于Adobe，很遗憾，虽然我不喜欢这家公司现在的做法，但不得不承认LrC做的确实好使。如果未来Adobe真的吃相难看，连淘宝也解决不了问题了，那我可能就会彻底舍弃它，转用DXO Photolab吧。总之，以上就是全部内容了。我们下一篇文章见！-全文完-
最近看到以183开头的IP地址在均匀地下载我tixati中挂的种子，虽然下载量不大，并且进度乍一看也没问题，但警觉的我意识到这不对劲，我可能又被人刷流量了。检查了一下IP黑名单，发现BTN的ip黑名单一直连接超时。想来想去，这样总不是个办法，还是得上正经的PeerBanHelper。于是，本文将记录我的折腾之路。TixatiTixati一直是我最喜欢的BT下载软件之一，因为它好用，功能丰富，性能稳定，最重要的是还有跨平台支持，对于openSUSE来说，只需要安装一个rpm包即可。为了解决吸血和刷流量的问题，它自带一个IP屏蔽列表，所以我配置了BTN网络定期导出的IP黑名单，tixati会定期自动获取最新的列表并根据IP实行封禁。但这有个问题：btn网络的ip黑名单全都用的国外的服务器，有github，有cloudflare，还有jsdelivr。最近他们在tixati中全部都超时，获取不到。本打算弄个反向代理，但想来想去太麻烦了，并且BTN导出的ip黑名单总归有延迟，并且BTN规则列表的仓库也说了：此项目不能作为唯一反吸血手段使用，它无法代替由反吸血程序提供的本地检测能力。它也并非是 PeerBanHelper 的核心 “全量” 数据。此项目的存在一切皆依赖于连接到 BTN 网络的用户。规则并不是大风吹来的。鼓励您使用在可能的情况下优先使用PeerBanHelper并连接到 BTN 网络，以便向本仓库贡献数据。任何已在反作弊辅助脚本、工具、程序中使用本项目提供的数据的朋友，请您考虑实现 BitTorrent Threat Network 标准规范，以便向网络提交数据。本着支持开源项目以及「为众人抱薪者，不可使其冻毙于风雪」的指导思想，我开始更换到受BTN支持的bt下载器。BiglyBTBiglyBT是我第二喜欢的bt客户端，但很遗憾，在这次折腾中它没能成为我的最终选择。我喜欢这个客户端单纯是因为它是Java写的，但我也是Java开发者，我深知Java的弱点：调用C库。好巧不巧，BiglyBT就调用了GTK库来实现UI。具体来说，它通过一个名叫SWT的组件来调用系统的GTK库，它本身并不包含GTK二进制文件。而默认安装的3.8.0.2版本在openSUSE上有bug，每次我尝试调整库的列视图时，只要点保存就必定崩溃。经过一番调试，我发现是SWT的问题，因为updater提示无法自动更新SWT。我在这个issue中找到了一个3.8.0.3-B14的beta版，这个版本修复了SWT更新的问题，而更新好SWT之后，UI的bug解决了，不过还有新的问题。在测试过程中，我注意到如果通过unraid的VM页面重启虚拟机，BiglyBT并不会收到关机信号并正常退出。重启之后自启动，会在右下角提示BiglyBT没有正常退出，而我观察到的问题是有些在seeding状态的种子，经过非正常退出之后会变成灰色的queued状态。在这种状态下并不会给他人上传，而我在文件中选择recheck强制重新检查文件后，这个种子又能重新seeding了。由于我的路由器ip会变化，而据我观察一些bt软件并不会更新获取到的ipv6地址，就导致路由器获取新的ip后，bt软件的联通性直接大幅下降。为了缓解这个问题，我在unraid中设定了脚本，每天凌晨在路由器重启半小时之后重启虚拟机，强制所有软件重新获取ipv6地址。如果每天重启都会随机导致一些种子无法正常seeding，对于我来说这还是挺严重的问题，因为我不可能每天都去检查nas上面软件的状态。qBittorrentqBittorrent并不是我最喜欢的bt软件，因为它ui有些简陋，并不像tixati那么花哨，功能上也没有BiglyBT那么丰富。但不得不说，因为ui简单，功能不复杂，因此这个软件运行起来确实稳定，并且也受BTN官方支持。和BiglyBT需要使用sh脚本安装不同，openSUSE本身就有qBittorrent的包，所以直接用zypper安装即可。安装完成后配置起来也不难，大部分情况下默认设置都能工作得很好，BTN也能和它配合。按理说事情就应该告一段落了，但我在测试下载新种子的时候发现qBittorrent无法写入任何数据。具体表现是开始下载种子后，直接提示错误，错误内容是Invalid argument。查看日志发现，具体错误原因与file_mmap这个函数有关。虽然这个函数是libtorrent的，但从过名字可以推断，这个函数应该是会调用Linux的mmap函数来将文件的一部分直接映射到内存，这样可以进行高性能的随机读写。而从目前的状况来看，读取验证哈希没有问题，但写入有问题，于是我开始怀疑unraid提供的挂载点。我原本认为我是用的是virtiofs来将unraid的共享文件夹挂载到虚拟机里，于是就以此为出发点，开始研究virtiofs对于mmap的支持。经过一番搜索，我找到了Introduce allow-mmap flag这个合并请求。这个合并请求的内容是给virtiofs的服务端添加命令行选项来决定它是否允许mmap。既然都添加了cli开关了，那想必virtiofs应该是支持mmap才对。我想来想去，想不明白，总不能是我挂载选项写错了吧。于是打开/etc/fstab一看，啊？我没用virtiofs，用的是9p。合着我刚才跟空气斗智斗勇来着呗？于是我花了两分钟在unraid中将挂载点从9p模式改成virtiofs，然后启动虚拟机，果不其然启动失败，因为fstab还是9p，改成virtiofs之后再次重启，qBittorrent一下子就好了。而且挂载点的读写性能也有显著的上升。我的ZFS卷采用3盘raidz1的vdev，一共有两个，总共6个盘位。之前不知何故，在读取文件验证哈希时，虚拟机内只能读到60MB/s，多个线程一起读也才勉强140MB/s，我当时以为是虚拟化的性能损失，就没太在意。现在从9p切换到了virtiofs，虚拟机内的读取性能可以达到683MB/s，差不多是这6块硬盘的极限了。9p vs virtiofs因为一开始配置挂载点的时候我也没有详细了解9p和virtiofs的区别，所以就选了默认的第一个，正好是9p。今天切换到virtiofs之后解决了问题，于是我想趁此机会了解一下二者的区别。这种时候gemini就派上了用场。 以下内容由gemini 2.5 flash生成，没用pro是因为充不起会员。请批判性地阅读以下内容，如果要做严肃用途的参考，请务必独立查证后使用。本文作者并不为以下段落的误导性信息负责。 根据Gemini 2.5 Flash所说，9p是Plan 9文件系统协议，最初是贝尔实验室在1992年开发。其核心设计理念是“一切皆文件”，即将各种系统组件（如窗口、网络连接、进程）都表示为文件，并通过统一的文件系统接口进行访问和操作 。在QEMU中（unraid系统使用的虚拟化后端），客户端使用9p协议主要通过virtio进行通讯。而9p本质上是一种网络协议 。虚拟机和宿主机之间的通信通过消息进行 。它采用客户端-服务器模型，其中客户端（虚拟机）发送请求消息（T-messages），服务器（宿主机）发送回复消息（R-messages） 。QEMU的9p服务器可以将I/O任务分派给工作线程，从而允许主线程处理其他请求，以实现并发处理 。9p协议的“一切皆文件”理念，虽然对于Plan 9这样的分布式操作系统来说非常优雅，因为它通过分层命名空间暴露所有资源，但在面对现代应用程序对高级IO原语（例如mmap）的需求时，其局限性便显现出来 。mmap操作与传统的read和write的字节流语义截然不同，它允许应用程序将文件内容直接映射到内存中进行访问，这是一种随机访问的高性能原语 ，而9p协议围绕流式文件的设计，使其难以在网络边界上高效且正确地表示和传输。这不光导致9p协议的IO性能存在瓶颈，更是导致9p无法完全实现unix文件系统语义的关键原因。即使QEMU的9p实现通过virtio技术来借助内核驱动和共享内存进行加速，其底层协议仍然是网络协议 。网络协议固有的消息序列化、反序列化以及即使在本地通信中也存在的上下文切换（vmexits）开销，限制了其性能。此外，9p协议在mmap支持方面存在具体限制。默认情况下，9p提供只读的mmap功能。这意味着，如果尝试以读写模式打开文件并进行mmap操作，后续的mmap可能会失败 。为了启用写入功能，需要在虚拟机客户端的挂载命令中明确指定cache选项，例如cache=mmap或cache=fscache 。如果未启用CONFIG_9P_FSCACHE，内核侧客户端代码会使用generic_file_readonly_mmap，从而导致写操作的mmap失败 。对于qBittorrent这类需要频繁进行文件预分配和随机写入的应用，这种只读mmap的默认行为和对特定缓存选项的依赖，直接导致了下载种子时出现file_mmap的IO错误 。9p的性能也受到msize参数的显著影响，该参数定义了9p服务器和客户端之间最大消息大小 。在Linux内核5.15版本之前，默认的msize仅为8KB，导致性能表现不佳，有时甚至低至12MB/s 。尽管内核5.15及更高版本将默认msize提高到128KB，但对于大多数机器而言，这仍然会限制性能 。通过在挂载命令或/etc/fstab中手动增加msize（例如，msize=262144或msize=104857600）可以显著提高速度，但Linux 9p客户端目前将msize上限限制在512KB 。这些限制进一步解释了9p模式下性能不佳的原因。 而virtiofs的开发旨在解决现有解决方案（如virtio-9p）的不足，这些方案基于未针对虚拟化优化的网络协议 。这些旧有解决方案缺乏本地文件系统语义，且性能不足以满足现代工作负载的需求 。VirtioFS的目标是在共享目录树的多个虚拟机之间提供本地文件系统语义 ，这对于轻量级虚拟机和容器工作负载尤为有用 。VirtioFS以FUSE（用户空间文件系统）为基础 。虚拟机内核充当FUSE客户端，而virtiofsd守护进程则作为FUSE服务器运行在宿主机上 。一个半虚拟化的virtio设备virtio-fs负责在虚拟机和宿主机之间传输FUSE消息 ，取代了传统的/dev/fuse接口 。VirtioFS最根本的创新在于其明确利用了“虚拟机和宿主机协同定位”的优势 。与9p将虚拟机-宿主机通信视为网络问题不同，VirtioFS通过共享内存和直接访问（DAX）技术，将昂贵的通信（vmexits）替换为更廉价、更直接的内存访问 。这是一种从基于网络协议的共享方式向更高效的内存共享方式的范式转变。这种设计选择是VirtioFS实现卓越性能的主要驱动力，尤其对于I/O密集型工作负载而言，因为它最大限度地减少了传统网络文件系统固有的开销，因此能够极大地提高IO性能。同时，VirtioFS采用FUSE作为协议 ，为其提供了“丰富的原生Linux文件系统接口” 。FUSE是一个成熟且被广泛理解的用户空间文件系统实现框架，这使得VirtioFS能够向虚拟机呈现高度兼容且完整的文件系统抽象。这对于qBittorrent这类需要标准POSIX文件系统语义来执行复杂操作（如mmap和文件预分配）的应用程序至关重要。FUSE基础，结合VirtioFS的扩展，使其能够“像本地文件系统一样”运行 ，这正是qBittorrent所需的功能。性能基准测试清晰地展示了VirtioFS的显著优势。在fio mmap测试中，virtio-9p的mmap模式下，单文件（单线程）性能为28 MB/s，4文件（4线程）性能为140 MB/s 。相比之下，VirtioFS在none + dax模式下，单文件性能达到126 MB/s，4文件性能达到501 MB/s；在always模式下，单文件性能为235 MB/s，4文件性能为858 MB/s 。即使是always + dax模式，其性能（单文件121 MB/s，4文件487 MB/s）也远超virtio-9p 。这些数据表明，VirtioFS，尤其是在启用DAX或always缓存模式时，为mmap操作提供了显著更高的吞吐量 。即便抛开virtiofs的性能优势，执意使用9p也会造成兼容性问题。9p对mmap操作的默认只读行为以及对特定缓存选项的严格要求，使其在面对qBittorrent这类需要复杂文件操作的应用时，容易出现兼容性问题和I/O错误 。而VirtioFS利用共享内存中的元数据版本表，在无需昂贵通信的情况下为多个虚拟机提供一致的访问 。VirtioFS的元数据版本号通过原子比较-交换操作实现，当版本号发生变化时，虚拟机将刷新其元数据缓存。对应地，如果开启9p对mmap的支持，在遇到多虚拟机访问同一文件的场景时，其主要依赖于宿主机进行仲裁（使用同步锁进行竞争，在频繁发生的场景下性能远不如原子比较-交换操作），并且9p协议本身并不原生提供缓存一致性机制，这意味着如果一个虚拟机在竞争中胜出，其他虚拟机可能仍然持有旧版本的mmap缓存，导致数据不一致、Last Writer Wins（最后一个写入块的客户端会覆盖掉之前所有其他虚拟机的修改，因为它不知道这些修改的存在）以及性能下降（竞争频繁的情况下可能会频繁刷新缓存）。其中last writer wins是破坏数据的主要问题，这可能会使得一些关键性的修改被丢弃，进而导致数据损坏。总结：用户在Unraid虚拟机上使用qBittorrent时，从9p模式切换到VirtioFS模式后，IO错误的解决和性能的显著提升，清晰地证明了VirtioFS在现代虚拟化文件共享场景中的压倒性优势。9p协议，作为Plan 9分布式操作系统中的通用网络文件系统协议，其“一切皆文件”的设计理念和基于消息传递的通信方式，使其在处理如qBittorrent这类对mmap和高并发IO有严格要求的应用时，暴露出固有的局限性。其默认的只读mmap行为和对msize等参数的敏感性，导致了性能瓶颈和功能不兼容。即使经过优化，9p作为网络协议的本质决定了其无法完全消除通信开销，难以提供真正的本地文件系统语义。相比之下，VirtioFS是专为解决虚拟化环境中的文件共享挑战而设计的。它通过以下关键创新实现了卓越的性能和兼容性：利用FUSE协议： VirtioFS以FUSE为基础，提供了丰富的原生Linux文件系统接口，使其能够像本地文件系统一样运行，满足应用程序对标准POSIX文件系统语义的期望。直接访问（DAX）： 这是VirtioFS的核心优势。通过将宿主机的文件内容直接映射到虚拟机内存，DAX绕过了虚拟机页面缓存和传统的I/O路径，显著减少了通信开销，并实现了高效的mmap操作，确保了多虚拟机间共享文件的一致性。协同定位优势： VirtioFS的设计明确利用了虚拟机和宿主机在同一物理机器上协同定位的特点，将昂贵的通信（vmexits）替换为更高效的直接内存访问，这是其性能超越9p的根本原因。因此，对于需要高性能、低延迟以及依赖本地文件系统语义（特别是mmap功能）的虚拟化工作负载，如qBittorrent下载、数据库操作或开发编译环境等，VirtioFS是明确的首选方案。而9p协议虽然在某些轻量级或对性能要求不高的共享场景中仍有其应用，但其在处理复杂I/O和mmap密集型任务时的局限性使其不再是现代虚拟化环境中的理想选择。 以上内容由gemini 2.5 flash生成。请批判性地阅读以上内容，如果要做严肃用途的参考，请务必独立查证后使用。本文作者并不为以上段落的误导性信息负责。 嗯，总之就是virtiofs是一个更加现代化的解决方案，以后就用它了。PeerBanHelper这里简单给大家介绍一下这个用来检测并封禁peer的工具：PeerBanHelper。由于最近吸血的不光是迅雷，还有pcdn和idc机房通过吸血bt上传者来平衡上下行流量比。我认为后者比迅雷更加可耻，引用我在搭建NAS时就说过的话：我一直不鼓励大家运行 pcdn 给互联网公司花钱当狗，但愿意当狗是个人自由，因此我只反对这种行为。但为了避免 ISP 限制自己的家宽而刷别人的上传量，这种就属于损人利己的脑瘫行为了，必须要重拳出击。而PeerBanHelper正是用来解决这个问题的，虽然我对于其实现方式不够认同，但它确实是现行最流行的威胁保护工具。由于家用宽带上行有限，因此我必须保证我上传的每一字节都传给需要的人，哪怕对方下载了但不上传，我这也算是有效共享。而这种刷流量的人在获取到我传给他的数据后直接丢弃，这就是浪费我的上行带宽，绝对不能容忍。我认为理想的BT辅助工具应该和BitTorrent一样是分布式去中心的。因此我理想的PeerBanHelper应该是采用类似DHT的网络结构，所有peer能够发布自己收集到的数据，并且中继自己从其他节点收集到的信息。这些信息可以使用密钥进行签名来防止伪造，并且通过算法在不同节点的报告中自行决定应该封禁哪些节点，同时算法还应该能够抵御赛贝尔攻击来防止刷流量的人自导自演，或其他人通过这个工具来封禁其他正常的节点。总之，我理解PeerBanHelper为什么要做成中心化的服务器，因为这种实现最简单。参考I2P、区块链以及其他开放的分布式系统设计，想要设计一个去中心化的分布式系统很简单，但想要让这个系统安全可靠高效且不被攻击和滥用，那就非常难了。也许实现这样一个系统非常困难，甚至不可能，可我觉得我们应当始终心怀对完美事物的追求，这样才会有发展与进步。由于我进行bt下载的软件就是安装在虚拟机里面，如果再装个docker就显得有些套娃了。当然可以部署在unraid的docker上，但我想让所有与p2p操作的部分都放在虚拟机里面，而的rpm包只支持redhat，所以我就采用了sh脚本的安装方式。安装后去社区的实例上注册个帐号，然后参照官方文档配置即可。其中有一个是否允许服务器下发脚本，虽然介绍说可以更加精准地识别一些威胁，但我还是不喜欢没有经过我审阅的脚本在我的设备上运行，何况PBH的知名度和可靠性远不如BOINC。不过即便是没有开启下发脚本，PBH还是成功地封禁了那些183开头的IP，至于封禁原因嘛，也很好猜：IDC机房刷流量。后记至此我的BT方案应该算是够我用上一段了。虽然上一篇答应大家写我是怎么处理照片的，但抱歉一鸽再鸽，毕竟bt下载这个事儿更加紧急一些，而且防止我忘了，要赶紧写出来赶紧发。所以处理照片的流程就放到下个月啦，一定会写的！-全文完-
本来想写写照片的处理流程，可是我现在主力是之前装的NUC，而照片则是依赖windows上的adobe。键盘倒是好说，一个机械有线插到nuc上，另一个罗技的蓝牙键盘连到windows上。可是鼠标就只有一个，虽然鼠标本身支持连接两个设备，但本质上还是断开一个连接另一个。Linux的蓝牙不算好用，断开之后重新连接就要好一阵。这时我灵机一动：怎么也应该有个跨系统共享鼠标键盘的东西吧。一开始搜到的解决方案是Synergy 3，个人用户终极版买断49美元，提供14天免费试用。他们号称提供Linux客户端，实际上截至目前只支持Ubuntu、Debian和Fedora。虽然OpenSUSE和Fedora是近亲，但安装过程提示libei不可用，因为Fedora上libei这个包在OpenSUSE上叫lebei1。通过断开依赖安装之后可以正常启动软件，但实际测试后发现Windows操控Linux没有问题，但Linux上将鼠标移动到桌面边缘不能操控Linux，估计还是依赖库名字不一样，加载失败了吧。没办法，我想花这个钱，可是对方实在是没本事接住啊。后续经过一番搜索，我发现了这个叫做DeskFlow的项目，它是Synergy 1的开源项目（卖49美元的是Synergy 3，不兼容1）。这个项目的最后更新是在7月3号上午，看来还是有在积极维护的。而且往下看了一眼，他们在OpenSUSE上有专门的打包，这样就不用安装flatpack版本了。在Linux上安装比较简单：sudo zypper in deskflow即可成功安装。在Windows上的安装则遇到了一些问题，为了装这个软件我前前后后重启了四五次。真是废物Windows。首先Synergy和Deskflow师出同门，因此你得先卸载Synergy，再安装Deskflow，否则你卸载Synergy的时候还得先卸载Deskflow，再卸载synergy，然后重新安装Deskflow，十分麻烦。其次就是Deskflow要求新版本的vc运行库，我之前装过这个库，但是似乎太老了，得用新版本覆盖一遍，据说是因为Windows Installer只会检测你装没装过这个二进制，而完全不看版本号，导致我安装Deskflow时一直卡在Starting service。虽然安装起来有些麻烦，但用起来并不麻烦。我的主要目的就是利用Linux的键鼠控制Windows，所以启动软件后在Linux上选择server模式，如果启用了防火墙的话，记得在防火墙里添加端口：sudo firewall-cmd --add-port 24800/tcp --permanent然后sudo firewall-cmd --reload即可。默认设置下服务端的端口号是24800，协议走的TCP。通信部分Deskflow使用了TLS加密，但默认是RSA 2048位的证书。虽然堪用，但我还是去Edit -> Preferences里面将key length调成4096了。可惜不能选加密方式，不然高低得从RSA改成ed25519。修改完密钥长度后记得点旁边的按钮来重新生成密钥。这里需要注意的是Synergy 3和Deskflow都用了24800这个端口。我在开着Synergy 3的情况下启动Deskflow，Deskflow会提示端口被占用，无法启动服务器。关闭Synergy 3之后就没有问题了。Windows端只要client模式，然后填上服务端的ip就行了。由于共享键鼠这个需求还是受到物理距离的限制，所以用局域网IP就行，我的nuc和笔记本都是固定的局域网ip，没有必要使用tailscale——如果我在北京试图共享键鼠给云南的设备，一般来说我在北京是看不清云南的屏幕的。第一次连接和ssh差不多，客户端和服务端需要交换公钥。Deskflow会提示用户确认公钥是否相同，用来避免中间人攻击。连接成功之后需要在Linux上的服务端配置里面调成一下两台电脑的布局。虽然我的nuc是双屏，但对于Deskflow来说还是被当成了一个屏幕。根据物理摆放的位置，我将笔记本设置在了nuc的右边，这样我在Linux上将鼠标移动到最右边的时候就可以控制笔记本了。虽然这个软件功能比较简单，但确实能够提升两台电脑的使用体验。我的nuc是wayland桌面，除了剪切板共享无法使用（对于这个问题我已经见怪不怪了），其他功能都非常好用（说是其他功能，其实就是共享个鼠标和键盘）。在延迟方面我没有测试，但只要局域网不丢包，从我的日常使用来说完全感觉不到延迟。但需要注意的是，我的日常并不包括在Windows笔记本上打游戏。我认为这种共享肯定多少还是会增加一点延迟的，但即便是打游戏，可能也看游戏类型？反正目前这个方案对我来说已经足够好了。对了，gnome上默认没有托盘图标了，想在后台运行还得自己装托盘插件。但这件事在我装好系统之后就做完了，所以问题不大。我还是想不明白为什么gnome开发团队要删掉托盘图标。好啦，以上就是关于Deskflow的使用体验了，毕竟功能较为单一，实在没啥可说的（以前都是上一个月提前写出下一个月的，然后定时在下个月1号上午发布。结果这次因为6月比较忙，所以忘记写7月的更新了。虽然这一篇比较短，但也不能算水吧，毕竟是真实的需求（目移）。总之这个就是7月份的更新啦。8月份我准备介绍一下我的照片处理工作流，虽然本打算6月趁618买下新镜头，可6月的昆明下了一整月的雨，尤其是一到周末就下雨，根本没有机会出去拍鸟。所以本想着发一些小鸟的照片，但因为没拍到，所以泡汤了。但工作流还是可以介绍的，那我们就下一篇文章再见啦。-全文完-
突然想起来春节回云南之后拍的照片还没有发过，赶紧看了一下，好在也没拍什么照片。因为工作日要上班，而难得的周末又没什么动力出门——要么天气太热，要么刮风下雨，所以春节之后到现在一直没怎么出门拍照片。更何况我这最远的焦段就是250mm，对于鸟类摄影来说完全不够吃。也正因如此，在618趁打折购入180-600之前，我也稍微涉足了一下风光摄影和街景的拍摄。三月初逛公园春季里的每一天都是很舒适的——温度不高，太阳不晒，没有大风，也不会下雨。所以三月的第一天我就扛着相机带着独脚架连逛了三个公园。春暖花开的感觉真好。一进公园就看到有只鸟在树枝上，可是因为体型小动作快，而且还是背光，没看清。回家之后查了一下，原来是绿背山雀。我是头一次见到这种鸟。到现在我也分不清这是桃花还是樱花。好像是樱花吧。这一张是在市政府对面的公园里拍到的，这个公园中间有一潭水。想必各位读者从画质就能看出来，这张照片经过了严重的裁切放大，根本原因就是250mm根本够不到。由于距离很远，所以我在取景器里只能分辨出一个物体在动，并依靠感觉来跟踪这个物体。回家一看，哇，是普通翠鸟！我也是第一次看到翠鸟。这个就是老朋友了，红嘴黑头，黑水鸡。本来没想拍，但这狗看着挺喜庆的，主人就在旁边。本着不想给人脸打马赛的宗旨，我通过巧妙的取景和裁切技巧，只留下了狗。看品种应该是柴犬？一看这发型，再一看这黄屁股，黄臀鹎，没跑了。这张是在前往第三个公园的路上拍的。看起来应该是两个狗主人在交流经验。边牧四舍五入可能算是我最喜欢的狗了，因为挺聪明的，而且黑白配色看着干净利落，虽然夏天看着长毛会觉得有点热，但总体来说还是挺可爱的。倘若之后我居有定所了，一定养两只边牧，再养两只缅因猫，然后再种一院子的树给本地的鸟栖息。第三个公园平平无奇，只是我余光一扫，等等，这是什么？福瑞要从小抓起！昆明人的精神生活实在是太丰富了口牙！可惜春天在工作的忙碌中过得飞快，转眼间就没了。五一劳动节随地大小拍五一假期我朋友来找我玩，于是我们晚上逛街白天逛公园，四处乱拍。五月四日晚上去白龙潭拍星星，我换镜头的时候没拿好还把相机摔了。好在回家查看了一下问题不大，只是电池仓那部分外壳因为掉落而变形了，我用钳子和锤子还有几张餐巾纸又给砸正了。好孩子可不要学哦，虽然维修相机有板金这种操作，但人家是把精密器件拆出来，单独对外壳校正。像我这样子，如果运气不好的话，很可能会在校正外壳的同时，震动传入机体把cmos什么的震坏了。好在我这个Z50 II也不是啥贵重的机器，我也懒得拿去售后挨刀子，所以就自己处理了。如果各位读者的器材比较金贵，或者比较爱惜自己的机器，那不小心摔了之后一定要去官方售后。由于拍星星没拍到什么好看的，因此这里就展示晚上街拍和白天去捞渔河拍的吧。这个是晚上没事干出门逛街，抬头一看发现路灯被一堆树叶挡住了。本着来都来了的指导思想，就拍了几张。回家犹豫了半天——删吧，这张看着还挺绿的；可是留着吧，有没啥意境可言。所以就让Adobe整了个自动，我简单又调了调。我也不知道这张照片算好看还是不好看。这张也是，而且不如上一张，路灯那里过曝了，而右边因为黑漆漆一片所以欠曝了。但我感觉这个场景的构图还是可以的，应该吧。嗯。。。看得出来我对于街景确实没啥天赋。不过后面还有风光呢，看到风光就知道我更没什么天赋了。这几张都想拍出点光与影的感觉，可是吧，标牌太亮了，我出门也没带独脚架，多重曝光懒得搞，所以就这样了，也不是很理想。这张可能是我晚上街拍最满意的一张。路过了一家疑似准备关门的小鹿噘嘴。可能这张照片也没啥构图和意境可言，但我觉得标牌以及夜晚的蓝色调和店内的灯光颜色形成对比，也不算完全没得看是吧。给要买Z50 II的读者提个醒：这个机器的高感相当于没有，虽然自带了闪光灯，但总不能对着人随地大小闪吧，而且闪光灯范围有限。由于cmos是祖传的，所以iso稍微过高（虽然iso不直接导致噪点，但自动iso时iso过高通常意味着进光量不够，从而导致噪点产生）噪点就爆了。上述照片全是经过DXO PhotoLab 8处理过的，你别说，这软件要价二百多美元，真的没有一分钱是冤枉的。这次还拍了一张徳和的广告牌，周围没有直接光源，全靠广告牌的亮光拍了一张，本来原本都分辨不出颜色了，而且raw全是噪点，可是我放到dxo里面一处理，不光降噪效果绝佳，而且颜色还原也相对能看。至于为什么没放出来，因为我按扫描件那么拍的，我怕放出来之后人家说我侵犯版权。晚上街拍到此结束，下面是在捞渔河拍到的。这个鸽子之所以能数毛，是因为这是小摊贩弄来卖鸽粮的，不怕人。这张白鹭就不一样了。5月的滇池没有了海鸥的造访，显得有些冷清。我左看右看，只在远处看到一直白鹭站在木杆上。飞天白鹭。这张感觉也不错，我赶在小孩哥来嚯拢水之前拍下了相对平静的水面。这张是水面倒影，我把它后期又翻转了一次，对应在岸上看到的景象。好像也没什么出奇的，没有拍出我想要的意境（也许我想要的意境根本不存在？）。发现的为数不多的鸟，黄臀鹎。看体型可能是幼鸟？夜鹭死苦。是夜鹭吧，应该没认错吧。一行白鹭上西天。好像不对，是上西天还是上青天来着？我这点知识啊，全还给语文老师了。那以前的学费什么时候退一下？应该是小䴙 （ pì ） 䴘 （ tī ）。第一次看到这种鸟。这不知道谁扔到路边木桩子上的花，觉得有点意思，就拍下来了。回家品了半天，是有点意思，但不多。还是水面倒影，像是PhotoShop里面某种风格化滤镜。蝴蝶，品种未知。虽然蝴蝶的速度没有鸟快，但是蝴蝶的行动轨迹更加随机。所以跟了半天才拍到这一张，而且由于栈道比较窄，还要提防别连人带相机掉河里。捞渔河的树林，随便拍拍，没啥意境。五月中旬探访阳宗海五月中旬我的朋友们租了辆车，问我要不要出去玩。一开始我是拒绝的，因为开车太累了。但架不住他们一直问，所以还是开了。去哪呢，去了阳宗海。结果路上差点被半挂逆行超车一把带走。现在回想起来还是一身冷汗，幸好当时我运气比较好，往右躲闪之后压到路边的立柱，好在立柱右边到排水渠还有两个轮胎宽的空间，我刚好把大货车让过去。之后也没有惊慌地立马向左打方向，不然非得翻了车不可。阳宗海整体感觉一般，没什么特别出众的地方。这个好像是国家能源集团旗下的阳宗海发电厂吧。虽然是阳宗海，但更像是一片湖。这是水上的帆船项目，可以花钱体验。放大之后的大烟囱。白色的烟应该主要是水蒸汽，毕竟人类文明进化了这么多年，发电还是离不开烧热水。这是广角拍的，可以看到250mm的效果还是可以的。这是阳宗海朝南的一侧，不知道为什么，这一侧水汽很足，显得湖面发白。在回来的路上偶遇鹊鸲抓到一直虫子。后记这几个月没怎么出去拍照，主要还是周末太短了。周六刚从一周的疲惫中缓过来，周日就要为下周的忙碌做准备。希望我司能尽快践行一下极为先进的上四修三工作制。由于618快到了，如果我关注的商品打折的话，我可能就会顺势买一颗尼康的180 600的镜头，虽然不是s line，但相比100 400，我觉得拍到比拍好更重要。其他想买的嘛，配套的爱普生打印机，之后就可以自己打印照片然后当成明信片寄给朋友了。之前一直在用富士的冲印服务，虽然效果不错，但是架不住太贵了。30张照片要寄给5个人就得二三百块，想来想去不如自己买个打印机划算——立等可取，后期开销少。好啦，这篇文章至此就先告一段落了。我们下一篇见！-全文完-
最近又开始玩MC了，自己弄了个整合包，以AE2、Mek和沉浸工程为主。自从玩过了东方女仆mod和TACZ枪械mod了，我就再也离不开这两个mod了——女仆能拿枪，这就无敌了啊。可是这个整合包玩着玩着，我突然发现我女仆没了？用卷轴定位说是在未加载区块上，可是我tp到了对应的座标，就是不见我的女仆。于是一场惊心动魄的救援行动就此展开——背景因为有和朋友联机的需求，所以开了个服务器。因为当时正在搞乙烯发电厂，打算开创造找个远一点（指7万方块之外）的地方设计一下怎么搞。结果忘记让女仆待在家里，就跟着传送了过来，她在旁边突突突打怪，我也没管她。我记得当天夜里一路玩到凌晨两点，虽然设计出了16个燃气发电机、发电容量为1MFE/t的设计，但现实中我都困的不行了，于是就tp回家，改成生存就下线了。下线之后NAS有个更新，需要重启服务器，自然也有需要重启容器中的游戏服务端，我不知道这是否是女仆丢失的原因。但我查阅了github上的issue区，只找到一篇相关的问题报告，但模组作者没有回应，大哥自己把issue关了。救援计划发现女仆消失后，我立刻放下手中的任务，开始思索如何把女仆带回来。目前来看，仆人铃和小号都无法召回女仆，因为模组认为女仆在未加载区块上。如果生成新的女仆，那么原来的女仆还是会存在，并且一直处于这种幽灵状态。由于仆人铃在绑定时会显示uuid，于是我推断模组应该是给每个女仆都设定了uuid作为id，如果我能让模组重新生成一个具有相同uuid的女仆，就算不能把原来的女仆带回来，至少也能顶掉原来的女仆进而修正这个幽灵状态。索性这个mod是开源的，而我正好略懂一些kotlin/jvm的编程技巧，于是我便冲到GitHub上查阅源码。根据源码可知，女仆的数据是存储在nbt标签中的，所以只要我们能够提取到女仆的UUID，然后把它移花接木到魂符上就行了。实施救援由于不想把事情搞得太麻烦，所以我是根据我自己的情况进行的修复。如果大家也遇到了类似的情况，可以发动自己的脑筋，再不济去解析一下游戏的存档，总能找到uuid的。由于我先前绑定过仆人铃，而仆人铃刚好就是把女仆的uuid存在nbt里的，所以主手拿着仆人铃，执行以下命令：/data get entity @p SelectedItem这个命令会在聊天窗口显示nbt数据，但游戏内不好复制，于是我从启动器的控制台日志里面复制出了结果：{ id: "touhou_little_maid:servant_bell", tag: { ServantBellTip: "女仆名称", ServantBellUuid: [I; -1136390084, -1170784113, -1271669764, -260320852] }, Count: 1b }虽然长得很像json，但实际不是。总之，可以看到里面有个ServantBellUuid，后面虽然不是uuid的常见形式，但熟悉uuid的话应该能看出，这是把字节数据当成整数给表示出来了。下面我们就可以找一个魂符来移花接木了。其实理论上用胶片也行，但是你得手动复活。退出服务器，我创建了一个单人的存档，召唤了一个女仆，然后把它收进魂符里面，使用上面的命令查看nbt数据：{id: "touhou_little_maid:smart_slab_has_maid", tag: {MaidInfo: {CanUpdate: 1b, MaidExperience: 0, SoundPackId: "littlemaid_peco", MaidBackpackData: {}, LeftHanded: 0b, MaidAIChatData: {ChatTemperature: -1.0d, ChatModel: "", CustomSetting: "", TtsModel: "", TtsSiteName: "", ChatSiteName: "", OwnerName: "", TtsLanguage: ""}, AbsorptionAmount: 0.0f, MaidHunger: 0, Invulnerable: 0b, IsYsmModel: 0b, ForgeCaps: {"tacz:synced_entity_data": [], "mekanism:radiation": {radiation: 1.0E-7d}, "curios:inventory": {Curios: []}}, MaidSchedulePos: {Work: {Z: -1374, X: -320, Y: 63}, Dimension: "minecraft:overworld", Configured: 0b, Idle: {Z: -1374, X: -320, Y: 63}, Sleep: {Z: -1374, X: -320, Y: 63}}, ModelId: "geckolib:foxmaid", ArmorDropChances: [0.085f, 0.085f, 0.085f, 0.085f], MaidBackpackType: "touhou_little_maid:middle_backpack", HandDropChances: [0.085f, 0.085f], MaidBaubleInventory: {Size: 9, Items: []}, ForcedAge: 0, MaidIsRideable: 1b, MaidScriptBook: [], MaidScheduleMode: "DAY", ArmorItems: [{id: "minecraft:iron_boots", Count: 1b, tag: {Damage: 59}}, {id: "minecraft:iron_leggings", Count: 1b, tag: {Damage: 59}}, {id: "minecraft:iron_chestplate", Count: 1b, tag: {Damage: 59}}, {id: "minecraft:iron_helmet", Count: 1b, tag: {Damage: 59}}], FavorabilityManagerCounter: {WorkMeal: 2352, Sleep: 8780, Death: 0}, StructureSpawn: 0b, MaidTaskInventory: {Size: 9, Items: []}, MaidInventory: {Size: 36, Items: [{Slot: 0, Count: 22b, id: "minecraft:bread"}, {Slot: 5, Count: 1b, tag: {AllTypeCreative: 1b, AmmoCount: 2147483614}, id: "tacz:ammo_box"}]}, MaidIsPickup: 0b, YsmRoamingVars: {}, UUID: [I; -1136390084, -1170784113, -1271669764, -260320852], ForgeData: {}, StruckByLightning: 0b, YsmRoamingUpdateFlag: 0, Motion: [0.0d, -0.0784000015258789d, 0.0d], MaidGameSkillData: {}, CanPickUpLoot: 0b, Fire: -1s, MaidFavorability: 384, PersistenceRequired: 0b, DeathTime: 0s, MaidTaskDataMaps: {}, OnGround: 1b, YsmModelId: "", MaidHideInventory: {Size: 1, Items: []}, KillRecord: {Slime: 0, Wither: 2, KillRecord: 2, EnderDragon: 0}, Attributes: [{Name: "gunsmithlib:bullet_speed", Base: 0.0d}, {Name: "minecraft:generic.max_health", Base: 80.0d}, {Name: "gunsmithlib:bullet_damage", Base: 0.0d}, {Name: "forge:entity_gravity", Base: 0.08d}, {Name: "tacz:tacz.bullet_resistance", Base: 0.0d}, {Name: "minecraft:generic.armor", Base: 0.0d}, {Name: "minecraft:generic.armor_toughness", Base: 0.0d}, {Name: "forge:step_height_addition", Base: 0.0d}, {Name: "minecraft:generic.attack_damage", Base: 6.0d}, {Name: "forge:swim_speed", Base: 1.0d}, {Name: "minecraft:generic.movement_speed", Base: 0.699999988079071d}], Brain: {memories: {}}, Owner: [I; 玩家uuid], Age: 0, Sitting: 0b, YsmModelTexture: "", Rotation: [-100.0f, 0.0f], HurtByTimestamp: 104992, CitadelData: {}, MaidSubConfig: {SoundFreq: 0.19999993f, PickupType: 2, BackpackShow: 0b, OpenDoor: 1b, ChatBubbleShow: 1b, ActiveClimbing: 1b, OpenFenceGate: 1b, BackItemShow: 1b}, MaidTask: "touhou_little_maid:gun_attack", HandItems: [{id: "tacz:modern_kinetic_gun", Count: 1b, tag: {AttachmentEXTENDED_MAG: {id: "tacz:attachment", tag: {AttachmentId: "tacz:light_extended_mag_3"}, Count: 1b}, HasBulletInBarrel: 1b, GunCurrentAmmoCount: 3, GunFireMode: "SEMI", GunId: "classicr:tti_g34"}}, {id: "mekanismadditions:light_blue_balloon", Count: 1b}], Air: 300s, YsmModelName: '{"text":""}', FallDistance: 0.0f, YsmRouletteAnim: "empty", MaidIsHome: 0b, Pos: [-324.85620222628216d, 63.0d, -1372.3034760980975d], Health: 80.0f, HurtTime: 0s, FallFlying: 0b, InLove: 0, PortalCooldown: 0}}, Count: 1b}眼尖的读者可能看出来了，你这魂符的uuid怎么和之前女仆的一样啊？那当然了，因为我这篇文章是事后复盘，既然没办法复现bug，那就只能力图还原一下当时的情景了。这怎么这么多一大坨？当我试图移花接木的时候，我发现无论是rcon还是游戏内的聊天框，都说命令太长。那就只能精简掉一些不必要的字段了，可是哪些字段不必要呢？我看了看代码，觉得有点麻烦，于是以实践检验真理。在我的不断尝试下，发现大部分字段都可以精简，只留下女仆uuid和玩家的uuid即可。于是我使用如下命令，将我工具栏的第二格覆盖为一个有女仆数据的魂符：/item replace entity @p hotbar.1 with touhou_little_maid:smart_slab_has_maid{MaidInfo: {CanUpdate: 1b, MaidIsPickup: 1b, UUID: [I; 463257288, 837635870, -1609583147, 1128655388], Owner: [I; 玩家uuid]}}这个命令足够短，可以直接在游戏的聊天框内输入。只要把其中UUID的部分换成你女仆的uuid即可。关于Owner，由于我是正版玩家，而且服务器也开了正版验证，因此无论是单机还是服务器，uuid都是不变的，复制出来直接拿来用就好了。但如果你是离线模式，或者服务器没开正版验证，你就得自己想办法去确定自己的uuid了，好在也不难。万事具备，就差一个右键了。对着地面使用魂符，虽然数据全都没了，但我的女仆又回来了！于是接下来就是创造模式的理赔时间了——好感度丢了？直接创造往上加！物品没了？创造模式丢什么拿什么，没丢的也能拿，就算是精神损失费了！这就是1967年冬天，平帐的好机会啊（不是）！后记虽然一开始女仆丢了很着急，但好在最后有惊无险地救回来了。不过这种方法是否会有后遗症或者副作用，我暂且不得而知。从目前来看，似乎一切正常，因此我和朋友就继续搭建乙烯发电厂去了。-全文完-
4月初买了个信达大星野（Sky-Watcher STAR ADVENTURER 2i），本来想到手时候拍拍星云什么的，结果昆明一到周末就连夜多云。本文将借此契机聊一聊星空摄影。白龙潭观星我对于星空摄影一直比较感兴趣，最早可以追溯到用树莓派的摄像头拍星星，然后是手机拍，买了运动相机之后用运动相机拍，拍星星、拍星轨。去年年末买了相机，那更要用相机拍啊。于是3月8号当晚我骑车去了附近的白龙潭公园。这个公园东边有一个小山坡，坡顶是一片空地，除了有高压线塔之外再没有其他遮挡物了，而且这个公园也算是我自行车所能及的最远的公园了。由于这个公园还没有正式交付使用，因此夜里路灯不会亮，这就意味着整片公园都是黑的，光污染会稍微小那么一点点。原本是打算拍拍星星，按照NPF法则计算好曝光时间，确保星点不会拖影，然后后期使用Sequator叠加即可。可是拍来拍去，能看到的星座也基本都看到了，无外乎就是拍完之后对着星图找哪几颗星星能连成星座。幸好那天我带了50-250的镜头，然后在星图上发现了猎户座。于是我在250毫米端对准M42星云开始拍摄，得到了如下结果：可以看到图片里的M42不大，因为焦段不够长，而且细节没有网络上的图片多。这是因为我没有赤道仪，为了保证星星不拖影，我按照0.5s曝光的，所以能收集到的光少得可怜，而尼康Z502的祖传CMOS在低光环境下就没有表现可言，因此很难收集到微弱的信号。选购赤道仪于是便萌生了购买赤道仪的想法。但比较精准的赤道仪都很贵，如果出去拍摄的话，光凭我一辆自行车很难谈机动性。所以虽然很不情愿，但最终我还是决定牺牲精确性来换取便携性。当然，价格也是一大因素，和选购相机镜头不同，我目前并不打算在天文摄影上花费很多钱，因为天文摄影的设备占地方很大，对操作环境要求比较高，最重要的就是非常贵，而且都是系列投入。比如说你买个望远镜，那就得买个天文相机吧，有了这一套你不能徒手举着啊，还得买个赤道仪和三脚架吧，那赤道仪凭自己追踪不精准怎么办？是不是还得弄个天文盒子和导星相机？如此种种，让我和我的钱包对这个爱好望而却步。我打算目前将我的主要兴趣放在拍鸟上，虽然还是要投入，但尼康Z502和官方的180-600镜头是我的全部投入了，带着这些装备还能促使我在周末和节假日走出家门。即能锻炼身体，又能改善心情，花钱还有数，这不挺好。言归正传，从便携性的角度出发，这基本就排除了全尺寸的赤道仪，因此我要选购的基本上就是星野赤道仪了。虽然我没找到关于星野赤道仪的具体定义，但从使用场景来说，它主要针对于焦段不高，并且主要是用相机（单反或微单）成像的场景，比如拍摄银河等场景。相对于全尺寸的赤道仪，星野赤道仪的追踪精度不高，并且负载能力较差，通常在5kg以下。而常规的赤道仪可以带十几公斤甚至几十公斤，不过那一套配置下来，赤道仪的重量也经常能达到十几公斤了。星野赤道仪的重量基本在几公斤的量级。以我的赤道仪为例，它只能追踪RA轴，Dec轴是固定的，本体重量差不多在2公斤左右，我加钱买了个收纳箱，因此可以直接绑在旅行车的后货架上。倘若换成十几公斤的大赤道仪，别说自行车了，摩托车都够呛。关于追踪，我注意到最近信达新出了一款RA轴+Dec轴的赤道仪，不过要比我这一款贵将近一千块。我想来想去，还是决定不加钱了，因为相机的分期还没有还完，我也不打算投入那么多，没有必要为我用不到的功能付费。如果读者的预算比较宽松的话，可以考虑购买新款的双轴赤道仪，这样配合天文盒子还有导星相机，可以获得更为精确的追踪效果。不加钱的另一个原因就是赤道仪并非成像质量的全部。环境比赤道仪更为重要。而我的出行工具就是一个自行车，虽然是旅行车，但也不能日行百里，更不要说骑车上山了。所以我的活动范围大部分都在市内，这就意味着光污染会比较严重。如果投入了那么一大堆金钱和精力，最后得到的结果却不尽如人意，那想必挫败感会很强。所谓兴趣爱好，无外乎就是花钱满足自己。而钱花了，自己却没高兴上，这种投入一点也不划算。于是我出门拍星星的最终配置是：信达大星野SA 2i，装在收纳盒里绑在后货架上面一个Jeep的露营折叠椅，不到40块钱，折叠后绑在后货架左侧先前买单筒望远镜时顺手买的三脚架，折叠后绑在后货架右侧经过我的测试，这套装备出门拍星星一点也不会觉得沉重。以及我非常庆幸我买的自行车是旅行车（捷安特Trooper 5300），在装东西方面十分优秀，这是我特意委托日新东路的捷安特车店老板帮我预订的。这里也算是帮老板打个广告，昆明日新东路的捷安特车店，老板人很好，技术也不错，组车买车都可以找他。在市政府对面顶着巨大的光污染拍星星4月18号晚上，我看天气预报说夜间万里无云，正好又是周五，看未来的天气预报，这似乎是绝无仅有的夜间晴天。于是我收拾行囊骑着车就出去了。但是因为感冒还没有好利落，不想跑太远，因此就没有去白龙潭。这次选址就定在了市政府南面的宪法主题公园，这块有个比较宽敞的广场，周围的树也都不高，也能看到北极星。另一个不愿意去白龙潭的原因就是太黑了，有点害怕。从进入公园开始就没有灯光，全靠自行车车灯照亮前面一点点路。到了山坡的坡顶，用手电也只能照亮有限的面积。有时候晚上还有出来遛弯的老头，也不说话也不咳嗽，只是一味地走路，发出沙沙的响声（对，一定是老头遛弯，不是别的），怪吓人的。等我骑车到了这里之后才发现，城区里的光污染要比白龙潭高太多了——白龙潭不打手电看不清周围的树木，即便眼睛适应了黑暗也是如此。而市政府对面就不一样了，马路上用了与众不同的白色LED路灯（其他地方都是传统的黄色钠灯），这就导致虽然公园里面没有灯，但光污染带来的光亮能够让眼睛适应黑暗后，完全不必依赖手电就能看清楚附近的所有细节。好巧不巧，那天晚上M42星云马上就要下班了，贴着地平线，那里也是光污染最严重的地方。我尝试拍了几张，完全看不到。遂放弃。在拍摄之前其实我还废了好大力气对极轴。所谓对极轴就是将赤道仪RA轴旋转的轴心调整为平行地球自转的转轴。北半球最常用的就是用极轴镜找北极星。虽然手机上有极轴镜的参考图，但实际看起来北极星就小小一颗，稍微有一些难找。在我撅着屁股仰着脖子以一种后背非常疼的姿势前前后后调整了一个小时之后，我终于对准了极轴镜，能够保证在250mm端曝光4分钟时星点还是圆的。但很快我就注意到了另一个问题：光污染太严重了，f6.3在iso100时曝光4分钟，拍出来完全就是白的。那怎么办？我想了想，反正也拍不到M42了，就拍个南河三吧，也没有什么星云之类的有意思的东西，因此就将曝光时间砍半，两分钟。这里我采用了不同的软件来处理照片，因为光污染太严重了。Siril是一个比Sequator更高级的处理软件，虽然sequator在大部分时候都很省事，但如果你想要更高级的处理方式，那么开源免费的Siril就是你的最佳之选。Siril的功能比较强大，因此这里就不多介绍了。这里我主要以使用脚本处理为主：分别将星星的照片放在flats文件夹，暗场放在darks，偏置场放在biases，平场放在flats文件夹中运行脚本OSC_Preprocessing即可自动处理彩色照片处理完成后打开结果的fit图首先将预览模式调整为自动拉伸，随后使用几何调整进行裁剪，去掉由于堆叠产生的位于边缘的条带然后将预览模式调回线性，选择直方图工具进行拉伸。由于我没什么经验，我一般都是点右侧的齿轮进行自动拉伸由于光污染比较严重，所以我们要利用背景提取删掉背景。我通常采用默认设置生成采样点，然后逐个检查，确保采样点中没有覆盖到星星和拍摄主体。如果有的话就用右键删掉这个采样点，然后在周围的空白处使用鼠标左键创建一个新的采样点最后可选使用色彩校准，我的图片堆叠出来颜色比较正常，星点也都是白的，这步就跳过了然后就可以导出成32位TIFF文件交给Photoshop处理了。不过这张图好像没什么处理的必要，因此在PS里面简单调整了一下色阶就导出了：中间最亮的那颗就是南河三。由于250mm焦距照的比较近，而南河三附近也没什么特别出众的星星，就，还挺无聊的。为了寻找周围有意思的星星，Siril里面可以在右上角的三条横线里，选择图像信息，然后使用图像解析功能来计算照片对应的赤经和赤纬。我将中心点设置成了南河三的赤经赤纬，然后让它自动搜索星点，最后按照识别出的星点的赤经赤纬来搜索，唯二搜出来的就是位于左下角的Delta 2 CMi和Delta 3 CMi，整体其实还挺无聊的。不过从另一个角度看，虽然出众的星星几乎没有，但这么狭小的视角也能拍到如此丰富的星星，宇宙真是浩瀚啊。租赁远程天文台事已至此，我必不可能善罢甘休。实际上因为一直等不到机会出门拍星星，我就顺势开始探索别的思路。远程天文台这个想法便出现在了我的眼前。总而言之，我选择了SkyGems这个平台租赁望远镜。他们家的平台可选的望远镜比较多，而且使用非常方便，你只需要告诉他们目标的赤经赤纬，然后选择什么通道曝光多久，一共拍几张就可以了。他们的系统能够自动安排时间进行拍摄，当然你可以通过加钱的方式来插队。他们家花欧元的，但相对于设备来说比较便宜，因为你只需要按照实际曝光时间支付，而不必考虑对焦和调试设备的时间。国内也有类似的远程天文台，但我没有选择他们，一方面是因为价格，更重要的一方面是关于观测数据版权的霸王条款。以我在网上看到的星迹天文台为例，他们的使用条款里明确说了拍摄的原始文件的版权归星迹天文台所有，拍摄者只拥有修改权，而原始文件未经许可不得用于商业用途。也就是说，我他妈的花了钱拍了星星，结果照片还不归我？我他妈的想要将原始文件用作商用用途还得看他妈的天文台的脸色？我可去你妈的吧。而且一个目标代拍600一个，自己拍600元一晚上，价格着实算不上便宜。而我选用的SkyGems平台，他们的FAQ里对于版权归属解释的十分明确：Q: What is the usage policy of the data?A: The data is yours and only yours, and you can use it in any way you need it. We do have access to the data for technical reasons, but we are not giving it away to anybody else. Of course, if you want to mention that you took the data from us we wouldn't complain :)（你的数据就是你的，而且只是你的。你可以按照你需要的方式随意使用。出于技术原因，我们确实拥有对数据的访问权，但我们不会将其交给其他任何人。当然，如果你想要提及数据是从我们这里拍摄的，我们当然不会有任何抱怨）我充值了50欧元，因为提交拍摄计划的时候需要保证最坏情况下的扣费，而实际拍摄则会根据观测条件动态打折，其中影响比较大的就是月亮。如果你能接受在出现月亮的时候拍摄，那么价格就会便宜一些。我拍摄的M42星云一共有四个通道：LRGB。其中明度通道L拍摄了15张，并且要求月亮在地平线之下。而RGB三个通道各拍摄了5张，只要远离月亮即可。所有照片每张都曝光150秒。最坏情况下需要收取38欧元，而实际我只支付了21欧元，总曝光时间1小时15分钟。就算按照所有通道不少于2小时来算，我实际花费不会超过70欧元，合人民币不到600块钱，而我还拥有对观测数据的全部所有权。星迹天文台，呸。虽然他们的天文台有自动拍摄，但如果途中遇到了云或者其他影响成像质量的干扰，可以通过网页面板申请退款。我的拍摄计划在拍摄绿色通道时有两张照片有比较厚的云层，导致堆叠出来的结果较差，我就针对这两张照片申请了退款。由于时差的原因没能立即退款，但第二天早上就已经退款成功了。总之，先给大家看一下21欧元的成果：这里简单提一下设备，我选择的设备望远镜是高桥FSQ106 ED（淘宝售价4万3），口径106mm，焦距530mm，相机是Moravian C3-61000（淘宝售价5万5），使用了LRGB四个滤镜。除此之外人家还有Ha、O-III和S-II这三种滤镜，但是我不会玩，就没碰。望远镜的位置在纳米比亚。天文相机得到的都是黑白图片，因此我的到了LRGB四种不同滤镜下的黑白照片。官方也提供了设备的校准图片，从人家的webdav服务器上下载即可。下一步便是用Siril处理了，但Siril好像也没提供针对天文相机的处理脚本？问题不大，我们按照LRGB四个通道建立四个文件夹，然后分别创建lights、darks、flats和biases即可。如果读者看过前篇关于在NAS上设置ZFS的文件的话，这里刚好也不用担心将校准图片复制四份导致的空间浪费——ZFS会自动去重的。针对每个通道运行名为Mono_Preprocessing的脚本。在得到了四个通道的堆叠结果之后，使用图像处理的RGB合成功能即可选择LRGB四个通道来合成彩色图片了。放大星点看周围是否有偏色，如果有的话可以放大图片，用选区选择一片星点对齐即可。如果观测数据并非在临近时间内，可能边缘和中心的星星位置偏移不一样，这时我推荐选取拍摄主体附近的星点进行对齐。合成之后的处理流程差不多：首先还是要裁切掉周围因为堆叠产生的色带然后用直方图自动拉伸接着使用背景提取功能删掉背景，虽然纳米比亚没什么光污染，但堆叠出来的照片还是会染上天空的颜色。乍一看挺好看的，但在后期处理以及PS调色的过程中，天空的颜色会随着对星云调色而变得奇怪，因此这一步我选择移除背景。步骤差不多，同样是生成采样点，确保采样点没有覆盖星星以及我们的拍摄主体。因为M42星云有比较大范围的气体和尘埃，因此为了保险起见，我删掉了星云周围的采样点，最后效果也还不错。取决于观测结果，删除背景后可以尝试再次直方图拉伸，将黑色色阶提高，这样删掉背景后能够将背景从均匀的灰色重新拉成黑色，忘了也不要紧，去PS里拉色阶也是一样最后如果颜色看起来比较奇怪的话，去色彩校准一下。色彩校准主要有两种，一种是根据照片选择黑色背景区域以及白色区域（通常是星云核心或比较大的星星）来自动计算白平衡。另一种则是选定你拍摄的目标，然后按照已知的观测数据来校准颜色。我的照片颜色看起来挺正常，所以就没有调整。最后保存fit文件，并导出一份32位的TIFF文件，后续使用Photoshop进行处理。在Photoshop中首先调整色阶，让背景拉成黑色的，然后裁剪出你想要的主体，差不多就是正常修图的步骤。最后为了突出M42星云，我使用了CameraRaw滤镜添加了一个径向遮罩，将四周的星星减少曝光度，让他们变黑一些，这样更能突出主体。同时我还在滤镜中调整了对比度和饱和度，让星云看起来更突出一些。因为平时修RAW比较多，比较习惯使用这些工具来调整。读者如果比较熟悉PS的话，大可不必拘泥于我的流程，按照你喜欢的方式发挥就好了。后记至此我的星空摄影入门杂谈就结束了。这么一看我这一万块钱的设备真的比不上人家十万的家伙事儿。好在我的赤道仪买的不贵，之后如果能找到朋友一起去白龙潭拍的话，也许效果会更好一些。但对于深空天体，比如M42或者M51这些的，我就不指望我自己能拍到了，为了满足自己，我决定还是去SkyGems上租望远镜去拍。这至少也算是仰望星空了吧，虽然少了不少仪式感，但钱包保住了啊！正如我先前所说，所谓爱好，无外乎就是花钱满足自己。我对于租望远镜拍到的M42十分满意！那么我就先写到这里啦，我们下一篇文章再见:)-全文完-
原本打算组完NAS之后慢慢扩容，这正好也是Unraid的优势所在。可是计划永远赶不上变化，我朋友扩容了他的NAS，换下来了3块8TB和2块6TB的硬盘，我想着与其去网上买来路不明的二手硬盘，不如就把我朋友换下来的硬盘收了。于是乎掐指一算，我之前自己买的2块，加上收来的5块，正好7块，马上就要把我的8盘位吃满了。想来想去，不如折腾个ZFS吧！前言先前我在文章里提过没有选择TrueNAS是因为DDR5 ECC平台太贵了，而且没有小主板。后来我也仔细查阅了不少资料，最终得出的结论是ECC会让内存变得更安全，但是没有ECC并不意味着ZFS会变得脆弱。正相反，其实ZFS从设计上就是为了尽最大努力保证它读出来的数据要和你当初交给它时一致。顺带一提，我今天才知道ZFS也是Sun公司制作的。我越发觉得这个公司真的很酷，没有坚持到现在真的很遗憾。没错，不要怀疑自己，Java也是这个公司搞的。虽然Java本身的语法和其衍生品相比并不酷，但JVM很酷，它作为一个平台支持了其他更酷的东西，比如kotlin、scala这些语言。而ZFS最初于2001年开始研发，它的目的就是不相信任何存储设备，因此ZFS也包含了大量措施来检测数据完整性，如果ZFS没有100%的把握确定它交给你的数据是正确的，它就不会稀里糊涂的把数据给你，而是通过报错让你知道系统出问题了。太酷了！尽管Unraid的阵列在扩展性和易用性上都比ZFS好，可最大的问题就是它无法甄别出现问题时哪块盘或者哪个文件出问题了，这也是我自己编写文件校验工具的动机。虽然大部分情况下硬盘要坏都是有征兆的，比如频繁报错、smart自检失败、掉盘等，但有一种错误是静悄悄的：bit rot。折腾NAS的玩家应该对这个词并不陌生，它描述了一种存储介质的一种物理翻转，也就是说硬盘在没人动它的情况下，可能某一位就会自己从0翻转到1，或者反过来。原因嘛，可能是生产瑕疵，或者是宇宙射线恰好命中了你的硬盘，又或者过年的时候亲戚家的熊孩子拿着强力磁铁吸你的NAS机箱。总之这种物理的问题完全无法避免，而这种又不算硬盘故障，诸多自检都对此无能为力。当你访问到了包含bit rot的区块，硬盘控制器自己也不知道这里的数据出问题了，它只能忠实地将它从磁盘上读出来的数据写到总线上，进而由操作系统呈现给用户，直到用户发现他珍藏多年的家庭合影再也打不开了。对于Unraid来说，定期计算磁盘校验有助于发现这种错误，比如当bit rot发生时，unraid可能会注意到阵列读出来的数据计算出的校验位和校验盘中存储的不一致，这个时候用户有两种选择：查找问题，或者将新的校验位写入校验盘。即便有两块校验盘也无法确定到底是哪块盘的数据出问题了，甚至你都无法得知是哪个文件出问题了——这就是我自己写文件校验工具的目的，虽然校验和本身也存在硬盘上，也有遭受bit rot的风险，但密码学领域的哈希计算确保了任何一点微小的改动（哪怕只有1bit）也会导致计算出和原来完全不同的哈希。因此在很大概率上可以通过文件级别的哈希来发现错误，然后从备份中找到完好的文件然后恢复。是的，无论是Unraid、RAID还是ZFS都不能替代备份。尽管ZFS有更强大的数据完整性校验和自恢复功能，如果数据损坏超过一定程度，ZFS也无力回天，而且它还会拒绝给你不完整的数据，因此拥有一个备份是十分必要的。当然，很大概率并不意味着万无一失。如果恰好出现多个bit rot使得奇偶校验没变，而其中一些bit rot又出现在一个同一个文件，恰好导致了哈希冲突，那么恭喜你：这虽然不是什么露脸的事儿，但确实非常稀有，值得你向那些搞IT运维的人还有用NAS不做备份的人炫耀，坏事是会发生的。为了确保万无一失，我还是要考虑ZFS。ECC内存的问题解决了，下面就要考虑扩展和易用的问题了。易用性在Unraid支持了ZFS之后变得好了许多，你可以直接通过网页面板来扩容和管理ZFS存储池，配合插件ZFS Master for Unraid来管理ZFS的dataset和快照。扩容嘛，正好我是3块8TB，2块6TB，再去买一块6TB，刚好做两个3盘raidz1的vdev。什么？你问vdev是什么？简单地说，在ZFS里面，最顶层的结构是zpool，也就是一个存储池，但是和群辉以及lvm中存储池的概念不同，ZFS的zpool是由vdev组成的。所谓vdev就是virtual device，虚拟设备。这些虚拟设备是由多个硬盘在不同配置下组成的。比如说你可以用两块硬盘按照mirror模式组成vdev，这和传统的raid1差不多。你也可以用stripe模式组成类似raid0效果的vdev，或者用ZFS独家的raidz（1，2，3）来确保vdev在丢失1、2、3块硬盘的情况下还能够读出数据。当然，ZFS中vdev的种类也有所不同，比如数据vdev用来存储你的文件，而元数据vdev则可以用来记录ZFS这个文件系统的数据。我的使用场景没有这么复杂，况且unraid也没有支持那么复杂的场景，因此我就只用数据vdev。那么，话不多说，我们直接开始操作。创建zpool创建zpool其实挺简单的，首先要停掉阵列，然后创建新的pool。起名是最难的，我想来想去，就叫它zfs-pool吧。添加好我的3块8TB硬盘之后，点击左边的Zfs-pool就可以进入池的设定页面。在文件系统里选择zfs或者zfs - encrypted，我选择的后者，和我的阵列一样，硬盘要先加密再使用。注意这里的zfs - encrypted和ZFS内置的加密还不一样。Unraid的加密文件系统是使用的LUKS，对设备进行块级加密之后再交给文件系统使用。而ZFS内置的加密则是将数据写入磁盘之前进行加密。这两种加密互不冲突，但同时启用会影响性能。鉴于我已经使用了加密阵列，因此我选择了让unraid帮我处理加密。选择完文件系统，我们可以选择分配方式了，我这里选了raidz1，这样启动阵列之后就会创建一个3盘的vdev，使用一块盘的容量进行冗余，读取速度则相当于是两块盘的总和。由于我后来购买的6TB盘还没到，因此他们留作后续扩容。启动阵列，会发现unraid提示zfs pool不可用，因为你还没有格式化。去到页面最底下格式化一下就好了。至此，我们算是有一个zfs存储池可以用了。但是还没完！确保ZFS能对所有所有数据都能够自恢复，我们需要配置一个叫做scrub的东西，它会定期检查所有数据，然后修复错误的地方，有点类似于unraid的校验。在阵列启动的时候点进Zfs-pool，可以找到scrub设置，可以设置每周或每月定期运行。此外，为了节省一些空间，我还决定打开zfs的压缩和dedup功能。压缩可以直接在网页端设置，但dedup需要使用命令行：zfs set dedup=blake3,verify zfs-pool这个命令会在zfs-pool这个存储池启用去重，算法使用blake3计算哈希，而verify标志则是告诉zfs当两个块哈希相同的时候，逐个字节对比块内数据。完成设置之后就可以在share里面使用新创建的存储池了。在新版本unraid里面，zfs存储池可以用作一级或者二级缓存，这里我选择还是沿用NVME的cache作为写入缓存，然后使用mover移动到zfs-pool，因为我的内存不是很大，所以写缓存还是要靠SSD。需要注意的是更新的share的选项之后，原本的文件并不会从阵列自动复制过去。如果要手动复制的话，建议先复制到SSD上，然后再调用mover，这样mover会自动按照share创建dataset。否则直接复制上去就是文件夹，而后续通过ZFS Master创建dataset就会被挂载点覆盖。不过万一被覆盖了也不要慌，因为数据没有丢。使用zfs unmount /mnt/zfs-pool/<mount-point>来卸载对应的挂载点，然后把被覆盖的文件夹重命名，然后再使用zfs mount zfs-pool/<mount-point>来重新挂载对应的dataset，之后用rsync把文件复制过去就好了。扩容（新增vdev）由于是开始折腾ZFS当晚就下单了新的硬盘，因此没几天就到了，正好试一下给ZFS扩容。一般来说给ZFS扩容有两种方法，第一种就是新增数据vdev，因为vdev之间是以stripe的方式组合的，所以新的vdev容量是按照加法计算进存储池的。第二种就是原地扩容vdev，但是你需要把vdev里所有的硬盘都扩大才行，并且只能扩容，不能缩小。后者也是为什么我选了两个3盘z1，而不是一个6盘z2。三盘在升级的时候带来的经济压力会稍微小一些，虽然vdev可以接受大小不一的盘，但是对于容量超出其他盘的部分就完全浪费了。扩容的操作也相对简单，停掉阵列，将原本Zfs-pool的slots从3改成6，然后选中新的硬盘，启动阵列后便会自动创建一个新的vdev。在命令行中可以确认：# zpool list -Pv zfs-pool NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT zfs-pool 38.2T 4.88T 33.3T - - 1% 12% 1.00x ONLINE - raidz1-0 21.8T 4.88T 17.0T - - 2% 22.3% - ONLINE /dev/mapper/sdf1 7.28T - - - - - - - ONLINE /dev/mapper/sdh1 7.28T - - - - - - - ONLINE /dev/mapper/sdc1 7.28T - - - - - - - ONLINE raidz1-1 16.4T 6.05M 16.4T - - 0% 0.00% - ONLINE /dev/mapper/sdb1 5.46T - - - - - - - ONLINE /dev/mapper/sdd1 5.46T - - - - - - - ONLINE /dev/mapper/sdi1 5.46T - - - - - - - ONLINE这里由于我使用了unriad的luks加密，所以设备全都是解密后的mapper。但这里可以看到多了一个raidz1-1的vdev，里面就是新添加的三块6TB的硬盘。至此，在unraid上建立zfs的过程就到此结束了。-全文完-