开头先看一下今年 Blog 更新计划完成咋样:
↘ | Category | Comment |
---|---|---|
✅ | Life | Project Home 3 其实不是很有营养,计划中的 Project Home 4 个人工作区介绍还缺点东西所以推迟了 |
❌ | My Own Hackday | 今年清明只有一天假,所以凉了(钓鱼去了),说起来这个 Flag 好几年都倒了,怠惰了啊 |
✅ | NAS and OpenWrt | Real NAS Project 2 虽然基本都是去年的活;Real NAS Project 3 突出一个灵车漂移,ZFS 能炸,Google Domains 也能关门 |
✅ | Gadgets | Gadgets 2023 加一个支线 Windows Dev Kit 2023 的介绍,近几年产出都比较稳定 |
✅ | Play Around | Vacation 2023、Vacation 2023.2 以及零零散散的很多很多地方,超额完成了 |
❌ | Technology | 虽然不在日常计划中,但确实一整年下来都没整出什么像样的活,怠惰了,怠惰了啊 |
其实从上面的统计或许也能看出来,今年草民突出一个高强度享受生活,其他方面从各种意义上都算得上平静无波,以至于刚开始写的时候都不知道开头该写什么。当然还是要(也许是被迫)关注这个世界的,如果一定说有什么事情要有(甚至说已经有了)足够大的影响。。。
今年大概任何一个跟互联网稍微沾点边的从业者都会被 AIGC 和 LLM 这两个东西轰炸,甚至催生了 Prompt 工程师这种抽象职业。。。
LLM 目前还是得有些钱才玩得起,但是感谢 Meta 的 llama,这个赛道现在也多少有些卷了。试了试 ChatGPT 3.5 Turbo(ChatGPT 4 不好白嫖,主要是付款方式多少有点费劲),在草民的工种里面最多只能说比智障好一些,现状是写 Prompt 要花费的精力比直接写代码要高得多,产出的东西也大概率不太靠谱,不过绝对不可否认能很明显看到发展的潜力,而且 LLM 发展极快并向多模态演进,能力越来越丰富,明年一定会掀起更大的风浪。
上面的问题是如何在 Rust 里面实现单例(具体点的场景是启动的时候读一个结构化的配置,但这个动作要由另一个封装好的包控制具体行为,所以有一点复杂),这个显然不在 std 里面的东西是 rust-lang-nursery/lazy-static.rs,草民最后是用了 OnceLock(Rust 1.70+)
至于 AIGC,这玩意儿现在已经事实上是个零门槛的东西,图片、音频、视频都已经有非常成熟的技术,甚至很多大厂比如网易之类已经多次声称在使用 AIGC 制造一些游戏内的美术资产之类,还在画师等圈子里引发了非常强烈的争议。草民也试玩了一下 Stable Diffusion 体验了一下真正的现代魔法吟唱,然后就一不小心沉迷了好几天,真的是魔法
上图草民不保留任何权利,Prompt:Civitai 131824 注意 NSFW,推理硬件是 2080 Ti,以及真的很努力避免露太多了可惜基础模型就这样
AIGC 做音频生成今年也是狠狠火了一把。除了草民一直在关注的 Synthesizer V AI,以及今年很热门的 ACE Studio(今年拜年纪的《人间游》就用了 ACE 家的虚拟歌姬「绮萱」,草民十分喜欢)这种专业的歌声合成引擎之外,也有 so-vits-svc 之类完全没有门槛没有管控、大家都在玩的社区项目(当然没人管的话就会跟 Stable Diffusion 一样很容易玩脱,case 不少这里就不举例子了。。。
总结一下就是,今年 AI 相关应用集中爆发,技术进步绝对是好事,但也会带来很多全新的挑战,无论是对一些人类工种的替代导致的冲击、AIGC 涉及到的内容法律风险、还是 LLM 越来越强甚至可能已经无限接近 AGI 的能力演进是否需要更进一步的管控,都是现阶段亟待解决的重大问题。这一轮科技革命已经开始,然而现阶段大力出奇迹之后的 AI 技术能带给人类的还尚未可知
今年大环境其实还是很不好(尤其地缘政治冲突严重加剧,导致很多行业日子都很更加难过),而且魔幻的事情越来越多。。。也不举例了
大环境不好反映在草民身上就是公司六月份又进行了一轮组织架构调整,现在的规模甚至收缩到了三年前的水平。虽然到年底似乎稍微看到了一丢丢行业回暖的迹象,但也很难说能不能持续,毕竟去年草民在「大环境」这件事上的判断目前似乎依然没有什么显著改观,暂且继续苟着。
考虑到上述原因和一些其他情况,今年除了把母亲的户口迁移过来,以及初步进行一部分石家庄的资产安排之外,没有继续推进主线。至于明年的打算,目前可以确定的是:成都的二手房行情目前也显然进入下行周期,这倒是符合草民的需求。目前估计不晚于明年完成这个阶段的资产配置,至于其他事情延续目前的保守策略,突出一个不莽、不立 Flag,一切随缘。
顺便还有一件主线之外的事儿:今年拖到差不多年底终于开始认真学车,然后科目二挂了两次 = = 感觉真的可以说至少来成都之后从来没遇到过这么大挫折
回想了一下今年工作上的事情,感觉大多水到渠成,除了一些上面提到的裁员(人话)导致的新锅旧锅一起背之外基本上没啥波澜。
去年做的基础建设按预期支撑起了几块核心业务,周边业务的建设也比较顺利,也多整了一些以前想整但是没整成的活(比如在 golang 服务里面嵌入 starlark 解释器做动态能力什么的)。算下来今年遇到的最难的活似乎还是在做人肉 Planner 的事情。业务多了数据源就多,但是机器资源又有限(就算无限也不可能想怎么搞怎么搞),同一个接口进来的请求要从各种场景考虑怎么样出得来,怎么样出的更快,怎么样避免客户发现有主从延迟,怎么样避免不必要的 Join 啥的。TiDB 的优化器又着实有点烂,总是要人工打很多 Hint 进去精细控制它的行为,做着做着就逐渐有了一点很烂的 RBO 的感觉,当然代码也是 Flag 越来越多,颇有一点「防御性编程」的感觉(绝非草民本意,甚至草民已经在尽量想办法让业务方自己来写查询逻辑、避免草民成为单点了,只是有些东西真是不好处理)。
业务更多关注成本、关注效率。抠细节的过程中也开始有一个新的判断:目前这套云计算的庞大叙事,或许跟讲过很多次的其他互联网故事一样,已经过了拐点
结合一些前同事的动作,逐渐开始觉得,相关从业者很可能之后要考虑往回归理性与传统的方向走。草民明年应该会在这个方向上多花一些时间。说起来好像各行各业都有那么一丢丢这样的趋势,或许这就是具像化的大环境吧(
当然这里一定要分清楚营销概念和真正的技术发展,技术是不会停止前进的(此处还是忍不住放一张堪称天道好轮回的图
最后还是要叠一下甲:上面都是草民毫无根据的暴论,看个乐子就行了,不要太认真。以及,上面也提到年底似乎也感受到了行业一定程度的回暖,希望明年一切顺利。
父亲的股骨头还是并不意外的有了坏死征兆,目前保守治疗中,不过估计是没啥用。疼的厉害了就换人工关节吧,也没什么更好的法子。赔偿的流程果然是并不顺利(要说这个流程也真是有意思。。。还是先不做展开,最后所有事项都处理的差不多的时候再另行介绍吧),看这流程估计要换了关节重新评估伤残等级一起算账了。
今年虽然还是没逃过固定日子看牙,还好牙齿没有什么大问题。但是非常令草民感到意外的是突然发现体重显著上升了,目前已经稳稳超过 80kg,比逃离帝都前涨了差不多 15kg。。。肚子已经鼓起一个大球,今年见到的所有前同事老同学全都在说草民明显胖了。。。真的活这么大从来没想过这种事情会发生在草民身上,太可怕了。。。
今年射箭的 Flag 又倒了,就算是为了控制体重上升这件事也不能再鸽了,明年一定一定要安排上。
去年有提到今年一定要多走走,于是今年出去玩的次数差不多得跟前面几年加起来一样多了。这个 Flag 差不多可以说超额完成?
爱桃人士狂喜()挺不错的,明年还去。
比较可惜的是今年七月没凑齐人再去摘一波桃子(刚裁了员加上确实有点热),明年尽量安排上吧
有些老物件确实很有意思,不过个人的感受倒是更多集中于城北的式微
当天晚上顺便去了博物馆,不过没拍什么图(有点太累了
清明只有一天假导致 My Own Hackday 咕咕咕了。被大学室友拉去提前感受一下中年男人的娱乐活动,新手光环拉满(
不过后面没再去了,草民还是宅属性更多。
时隔两年半(?)的大活,详情见 Vacation 2023
明年成都到昆明的高铁就通车了,这波高低得去泸沽湖呆两天。
虽然因为各种原因浪费了非常多的时间,但现摘的樱桃是真的太好吃了。
最经典的大概是这张《人不如鸡》
这个明年也一定会再安排上,而且必须超级加倍
前同事结婚 + ChiliChill 的巡演,这波必须得去。
羡慕前同事之余还是狠狠吐槽了一波长沙,之前不知道哪里来的似乎还不错的印象一点不剩,当然茶颜悦色是值得的。
上次去重庆得是五年多前了。连同上面长沙的详情见 Vacation 2023.2
不出意外的话明年可能还会去重庆看一两次巡演,可以再找几个前同事蹭饭(
回石家庄顺便去玩。这个上次来得是差不多二十年前了?
虽然城市界面焕然一新,但还是多少有些萧条之感。没办法,确实难。
考科目一完事儿顺便去转了一圈。环境不错,就是去一趟成本略高(什么时候高新区修个东西贯通的地铁啊
回来被同事拉着骑小黄骑了四分之一圈绿道,整个人都麻了。
突然有两个大佬就打算元旦来成都(勇气可嘉)。照着六年前的作业抄了一份七七八八的,不过大概是因为胖了,这次逛猴区时间就不太够
上次本来也想记录一下的,但是因为种种原因就咕咕咕了,这次的细节会放在后面 Vacation 2024.1 介绍,大概一月下旬发吧。
这一部分独立出来的原因是确实今年跑了好多场(虽然不如超话里面那些神仙,毕竟实在是没那么多假可以请
第四次来不才的线下了(后援会小伙伴已经成功混脸熟了
这次除了签名还有合影(但是草民太磕碜了就不放了
第一次见仙女好激动!
今年感觉体验最好的一场,各方面都可以说是完美,尤其《红白》现场版可以称之为震撼人心
草民是从《时光盲盒》认识这个组合的
听了这一场才知道冷辣椒还写了很多原神同人金曲。《我不曾忘记》劲儿是真大,草民这个从来没玩过原神的听一遍都没绷住
超级加倍就是了。
连同下面那一场在 Vacation 2023.2 里面也都有记录。已经在期待他们明年的大活了(
依然是超级加倍。
说起来因为上一场后劲儿太大草民甚至订了去郑州场的票,不过后来重庆加了一场 & 郑州场因不可抗力取消了。也是很有意思的经历(
你们可能不知道草民等这一天等了多久。。。
去年半梦因为各种原因只能眼馋,上面的巡演也很难挤出时间专门跑一趟杭州,但是这次终于!终于!!见到活的了!!!
今年最有参与感的一场(所有的歌都不知道循环了多少次而且全场几乎都这样(以及白嫖了好多东西,必须要认真感谢一下神仙们
以及顺便买到了这张图(西安场)里面的抱枕(说起来上半年不才杭州场嘉宾是银临,下半年银临西安场嘉宾是不才,双厨狂喜啊狂喜
签名合体四舍五入也就是见过现场合体了(
最后狠狠期待新专辑 + 明年二巡一切顺利!!!
巡演跑得多于是专辑什么的也买的多(其实压根没什么关系
今年买到的大部分都有签名就非常开心(
图上没有印出来的作者,只有签名:祈 Inory - 萌娘百科
同时有 CD 和数字版(盒子左上角的那个 U 盘,里面有 wav)就非常棒(毕竟现在想找个光驱是真的很难了
买来发现豪华版里面塞了一个简装版(刚好有个学弟没买到,简装不拆了回头给他
顺便补了一专实体,好耶
虽然今年黄黄的巡演都没安排签售,但可以靠爆表的运气补上(耶
豪华版里面附带了一盒磁带,就非常非常的有仪式感(当然也真的更难找到磁带机了
这次终于轮到草民拿着限量版的周边(指一专豪华版里的小册子《每到夜里我就写歌》)秀优越了,好开心
《V.T.A》一不小心就买了一大堆,跟不才的《山止川行》一样多了
其实就是没有签名的(
然后再专门吐槽一下《梦倾天下》这个实体版,就这个盒子质量还不错,但里面的东西吧,U 盘勉勉强强,歌词本印的糊成一坨,真的是,实在很难硬买好几盒。。。真不如成本高点,定价再高点。评价为格局小了,希望《兰·音》别这样,最好能再出个豪华一点的版本
除了签名碟之外还 merge 了一下塑料小人之类的收藏(可以从里面看到一些之前就出现过的东西,不过还没有全部带过来
今年买到的塑料小人主要是下面几个(一些小的盒蛋之类的就不列出来了):
下面还有不少设定集也是今年入手的,包括塞尔达、平安京、忘川风华录、长安三万里、星际争霸 2(玻璃渣生前算个体面人啊,不过这几天似乎又在传,微软收购完之后跟网易又重新谈好了)什么的。受限于空间目前能摆出来的基本就这些了(有一说一把它们都塞进去可真是费脑子,把它们的包装盒收好更是非常令人头疼,衣柜和床底下所有能用的地方都占上了),余下的可能就要人生主线推进之后再议
今年三次元的活整得多,二次元的活就比较少了,是好事。个人觉得电子那啥的水平基本维持住了吧(
什么破游戏能坚持玩七年多(其实已经 2600+ 签到了
结合之前数据看看其实真的人数越来越少,刚好最近一波大节奏(钞鬼王这活整的真不知道 Zen 是有多缺钱,还被骂到撤回一个 SSR
今年最大的意外是居然在一年内同时达成了「非洲大阴阳师」和「欧皇」两个纯看脸的成就,于是「人生赢家」日月同辉
全图还差最后一个嫩爹(SP 萤草),不知道啥时候能抽到,也不知道还能不能等到 3000 天了。最后紧那罗手办快端上来罢(敲碗
第一时间赶来得瑟刚刚抽到的阮 · 梅(毕竟有谁能拒绝阮饭呢
崩铁的内容实在是过于优秀,玩法简单(玩过阴阳师的话上手极快)且不肝,模拟宇宙很有意思,每个版本的活动更是非常顶(尤其是 1.5 这个活动,梗的密度大到简直离谱,令人不由得感叹这帮编剧冲浪速度着实非常快
甚至于有个说法:「你可以随便发表爆论,但你说的每一句话都会被改编进崩坏 · 星穹铁道」
跟这段时间的 YYS 对比下来。。。再加上年底一波节奏过来,已经有点想弃坑专心崩铁
王国之泪好玩捏,不过 Switch Lite 屏幕太瞎眼了。附一张颜艺(
目前地图开差不多,但眼睛真的遭不住,可能等到下一代 Switch 出来的时候直接二周目吧(
终于还是彻底凉凉(指整个公司都被收购)了,可惜就是死的不太体面,也没办法。
复活吧我的爱人(大雾),可惜这次真的已经结束了
说真的还真不如隔壁,起码人家混的真不错,今年《白荆回廊》都端上来了(有一说一司危和芙蕖确实,很有想法,虽然草民应该不会尝试
最后大概也就只能期待一下明年小六剧(说到这个害,也忍不住在想如果 7 的剧情还是沈瑢瑢上的话会不会。。。
除了上面说的小六剧之外,突然想起来破事 2 忘了看了草,过年的时候补一下吧
aka 腾讯三体。真的顶,太顶了,跟那个什么玩意儿比,真真一个天上一个地下
第二部不确定啥时候,但明年有球状闪电(草民觉得甚至比三体更适合拍剧,希望别浪费了)。至于 Netflix 的看不看的吧,不需要了感觉
就问太空电梯爽不爽,草民是真的看爽了。
虽然有一说一草民不是很吃数字生命这一套(个人觉得多少有点那种强行造神的感觉,数字生命是个筐什么都可以往里装),但还是看的非常爽,所以球 3 见(很急,但是先别急
评价为追光讲故事讲的最好的一次,超过姜子牙真的是实至名归,扬眉吐气。甚至真的上春晚了!!!(深海就边上稍稍就行了,懒得吐槽
以及可能是设定集到手最快的一次,好评(上面的 Collection 里面有可以找找看
虽然上面跑了那么多场巡演买了那么多碟,但是草民是!兰!音!的!狗!(骄傲
年度歌曲 | 年度总结 | 年度歌手 |
今年的年度歌曲还是《流年如歌》,虽然说来有点可惜 b 站今年年货里最期待的大菜无了(虽然兰音唱的《定影听潮起》也挺好听,但就是没有那味儿)。还好还有代餐:前方高燃!一首歌唱出中国科幻千年梦想《到深空更深处去》【星尘 Infinity】【2023 虚拟歌手贺岁纪单品】,有一说一这个所有东西都基本到位了,直接挤在《定影听潮起》前面多好。说起来这个视频甚至是今年草民 b 站刷的最多的视频(甚至央视网络春晚,不过不建议听,听完多少得回来洗洗耳朵
老二刺猿了啊( | 到深空更深处去 | 还是兰音的狗( |
明年年货也有点不确定了,虽然导演嘴上一直说要退休,但这一天真的到来的时候还是多少有点失落的
说起来真的从 2019 年开始再也没看过春晚,每年都在期待叔叔的年货,不知道一个多月之后的新导演会整个什么活
luci-app-xray 每年差不多 150 star 稳步提升,很神奇的是今年追着问问题的好像大部分都是外国友人(俄罗斯伊朗等等地方的 bro
今年主要做的能力除了 Issues 中经常提到的 IPv6 支持之外,重点是完善本地流量管理的能力,比如更完善的局域网设备策略、Dynamic Direct 和 FakeDNS 这些都是着重于本地入流量侧的体验提升。其他的点则是做了一些可观测性的优化,对包括 nftables 和 Xray 本身的一些关键指标做了更直观的展示。不过因为个人精力上的原因,草民明年应该会一定程度上降低在这件事上的投入,并且之后的主要方向应该会是做一些针对部分功能的解耦,最终期望的形态大概会有点像 Surge 那样(懂得都懂不懂就算了不多说了
Real NAS Project 2 的结尾其实也提到目前 NAS 的形态基本稳定,今年的迭代其实只有内网 HTTPS,结果没多久 Google Domains 就裂了,明年应该还会重新整一下(而且确实目前挂在 Xray 上这种形态不是很好用),以及一些原来放在 GitHub 上的东西挪到了自建 Gitea 上,还有自建推送通知设施 Bark 等。当然中间还遇上了 ZFS 爆炸这种节目效果拉满的事情,算个乐子(
家庭网络今年整的一个比较有意思的活:OpenWrt 年中支持了 Hostapd Radius 服务器,于是尝试了一下 EAP,不过目前暂时只用 PEAP + MSCHAPV2 做了身份认证。后面整 VLAN 绑定,搭配 OpenWrt 自身足够强大的 nftables 等组件做本地流量管理才是最有价值的功能,而且从日常使用的角度来说,这种方案还不需要开一堆 SSID,也不担心什么万能钥匙之类的把访客 WiFi 分享出去导致一系列不可控的安全风险
前面 Work 的部分有提到下云,明年也会更进一步尝试把更多目前依赖公有云 / 大企业的服务用自建服务代替,具体实践可以期待一下接下来的 Real NAS Project 2024(没错,既然迭代不会太频繁,之后编号也就跟其他 Category 同步了
草民做 luci-app-xray 的过程中逐渐觉得:路由器上做本地流量管理的一些常见 case,其实与 mesh sidecar 的能力有很多相似之处:
于是今年也产生了一个新的想法:打算进行一个拿来主义,把上面提到的一些很好用但分布在不同工具中的能力借用过来,使用 Rust 从头开始实现一个比较纯粹的本地流量管理工具,并且在保证纯粹的前提下,利用 starlark 这样的嵌入脚本引擎实现尽可能强的定制化能力,甚至在一定程度上接近业界常用 mesh sidecar 所具备的能力。这个项目大概会是未来相当长一段时间草民主要花时间的个人项目,会在适当的时候发出来。
端午节如期更新了 Gadgets 2023 ,到现在刚好又过了半年,可以盘一盘下半年入手的东西:
顺便一提,之前提到过的很箍头的音频眼镜在把主力机换到 iPhone 之后就彻底吃灰了。。。
下次例行更新就明年端午假期见,目前感觉这个节奏还是比较合适的。
扯到结尾其实确实今年个人只能评价为真没整出什么活,除了玩就是摆,确实是有点子怠惰了(但是确实挺开心的
按照惯例,结束之前还是:新的一年许个愿。
主线:
支线:
最后依然送上草民真的很喜欢的《流年如歌》,希望大家新的一年越来越好。
]]>前同事 9.16 结婚,刚好 9.15 晚上在梅溪湖有一场 ChiliChill 的 live,这肯定要一起安排上。
虽然是头一次来长沙,而且也想认真观察一下城市界面和产业等等各方面,不过时间关系(主要还是年假不够了)也就只能呆到周一,所以除此之外就很难有其他安排,基本上都是随缘了。
去程选了一趟很便宜的飞机,四百多的样子,当然很不意外的要从天府机场走。
十点一刻的飞机,草民差不多七点上了 5 号线,然后到孵化园换到 18 号线。虽然是周五不过早上 18 号线也差点没地方坐,9 号线就更别提了,着实令草民十分意外。
机场里面的设施倒是很有趣,比如出地铁之前就可以值机,以及户外小庭院和专门的户外吸烟区(里面有个小亭子装电子点烟器
登机口比较近,从出地铁到安检完走到登机口差不多只花了不到半个小时,远比之前预期要短。如果下次不是规避地铁早高峰,感觉提前一个半小时到机场都绰绰有余,但这波就只能干等差不多俩小时了。
这波第一天自己在长沙住,所以习惯性选了亚朵。梅溪湖那边还是亚朵 S,而且意外的便宜只要三百多(重庆都要五百多了还不是 S
从机场出来 6 号线坐了差不多一个小时出来,然后看到共享电动车,小开心,不过这边对头盔的要求很严格,戴上头盔车子才通电。有日子没住亚朵了,看见桌子下面的小冰箱感觉贼亲切 hhh
顺便在重庆的亚朵也见到这个小卡片了(不过没拍照片
本着一个来都来了的心态,打算特种兵一波,趁着晚上 LiveHouse 之前的三四个小时功夫转几个地方。为了顺便观察城市界面就还是计划骑共享电动车,但是整个这个道路交通体验就真的让人心态非常爆炸,在极差的道路交通体验下浪费了很多时间,也基本上没啥心情玩了,时间还很紧,结果是只在橘子洲呆了一小会儿。
这么出名的雕像高低得看看对吧。然后小火车花了四十块钱,以及这个景区商业化程度个人评价为离谱。。。
至于交通到底是怎么个让人心态爆炸:
坐了 40 块钱的小火车会送一张小卡片(这能评上 5A 草民表示很难评价
回来差不多五点半了,稍微恰点东西。能在长沙买到风花雪月还挺让人意外的(不过只见到了这一次
换掉衣服冲向场地。
冷辣椒这波也是二刷了。虽然下午体验很差,但是晚上还是很开心(夏老师太可爱了
这个场地比较小所以票也放的少了一些(虽然并不影响最后又找不到自己
本来想签一专的但是最后想了想没拆(VTA 买了不少,随便拆一个拿来签都行
婚礼在旁边宁乡,于是怎么过去就是个非常蛋疼的事情。正常来说坐城际比较省事,但梅溪湖已经在相当靠西边的地方了,坐城际还得先回到市区,太花时间。草民先是提前约了个 8 点的车,然后被放鸽子,后面又换了一辆张口就要一百块的返程费,令人吐血,最后干脆坐了一个小时公交到宁乡某个汽车站再打车到酒店。咱就是说这个地方的道路交通怎么就这么全方位血压爆炸的。。。
前同事安排了本地的高端酒店品牌(维纳斯维也纳傻傻分不清楚),房间甚至是小度的全屋智能,突然就有那么一点种草电动窗帘。这个电梯就很有意思,比如意义不明的跟 4 层同时出现的 3A(事实上同时还有 3 层,但好像 2 层不见了,这种讲究真的令人摸不到头脑),以及更加令人难绷的名为 Laundry 的健身房(当然实际人家真的是放在一间屋的所以也不算有问题
要说这位前同事也是着实令人羡慕,咱就没有一个能从初中延续到现在的爱情故事(
有时候也真的会想一想咱这个八字是不是起码得把笔拿起来啊。
仪式进行的很快(这点好评),于是下午安排大家一起去凉快凉快。湖南的这个龙泉过去还挺远的,大巴一个多小时。
前面有一点跟语言完全不通的嬢嬢因为十块钱吵了半天的小插曲,细节不表。漂流贼刺激,落差有点大,开局几分钟衣服直接全湿透,根本就不需要任何武器打水仗,比起多年前十渡那个漂流猛得多。比较难绷的是半途筏子被撞翻了,损失眼镜一副(什么叫墨菲定律啊,倒是无所谓,反正也该换了
当天晚上只好在宁乡用上次的验光结果加急整了一副,没想到差不多一个小时就配出来,而且各方面都意外的很不错,虽然价格只是之前那副 1/7,但甚至比之前的还舒服一些
回来看见银临的巡演终于官宣了,而且第一轮就有成都,突出一个激动,这波国庆回家该拿的东西都得拿过来
周日蹭某位大佬的特斯拉回到长沙市区小逛。午饭整到了第一杯茶颜悦色,味道甚好,要说人家这个火爆确实是有点东西的。
马王堆遗址三号坑跟湖南省人民医院共用入口大概是每个游客都会经历的一点小小震撼。
里面很小就一个坑,几分钟就看完了,于是前往湖南博物院。
博物院礼拜天真是人山人海,还好前一天晚上提前预约过,否则怕是门都进不来。这里的游览路线设计的确实不错
当然草民主要关注的肯定是这件非常出名的衣服
毕竟这才是代表了当时的顶尖科技和生产力水平。
前一天漂流把卡包也泡烂了,于是顺便买了个零钱包回来(这个吉祥物的画风咱反正是不太能欣赏得来
回宁乡之后又跟着大佬蹭了一顿人家的家宴(怪难为情的
见到了一位非常牛逼的长辈,虽然年纪大一点但跟草民这一辈交流起来几乎毫无代沟。然后被拉去尝试了一下黑色经典,事实证明这东西在嗅觉和味觉上保持了高度一致,草民确实完全没法接受。。。
完事儿只好再整一杯茶颜悦色缓一缓。要说宁乡这边建设的也真是不错,这个商圈挺大,该有的差不多都有。薅了两张小卡片
周一最后整一杯然后坐高铁回家。总结一下对长沙的印象:
到家之后买了前面提到过的智能音频眼镜(这玩意儿槽点主要在于特别箍脑袋,明年的 Gadgets 里面会简单介绍一下
卡点抢了银临的票,这波真是惊险,差一点没抢到。不出意外应该是今年赶的最后一场 LiveHouse
这波来二刷黄黄的巡演。因为上一次的后劲实在是太足,草民甚至订了二轮郑州场的票,但后来郑州场意外取消了,又在重庆加了一场。
刚好重庆也有前同事可以碰个面,也比较近,走起。
定了到沙坪坝的高铁,成都东站过去只要一个小时多一丢丢,相当方便。不过这个高铁票是真的可怕,本来以为跟北京到石家庄差不多的距离应该票也随便买,结果点开一看一大片都是售空,回来甚至只能从重庆北站走了。。。
住依然是习惯性选了最近的亚朵。从高铁站出来没几步居然又碰见了茶颜悦色,整(而且后来发现重庆到处都是,为什么成都没有
其实也不是第一次来重庆了,甚至场地还在磁器口里面,一想起那个地方挤的水泄不通的小路就感到害怕,不过实际到了之后发现这次场地很大,差不多是正常 LiveHouse 两倍大了,甚至排队都可以排三队
仙女依然发挥稳定,场地效果也很好,但是乐手老师们似乎有自己的想法(突出一个不看谱子瞎弹,Key 乱七八糟。。。
结束之后出来偶然看到头上的灯笼挺好看。
这次终于能勉强看到自己的半个脑袋了(这个场地是不是真的还挺大的,以及手动表白黄黄左边的二胡小姐姐
没有再错过气氛组中的小彩蛋。顺便一提现场还有两个版本的《见过》EP 在卖(哎呀是谁有签过名的典藏版呀真是让人羡慕呢
隔天约了另一个前同事吃饭。观音桥之前倒是没来过,既然来了就再整一杯。
中间贴了一个招聘广告,要说这个薪资其实还真不算低,当然累怕是真的累,一家店三四个店员,然后前面无论啥时候都排起码十几个人,平均一人两三杯,又不像霸王茶姬那种大部分工序全自动。。。
这位也是跟上面那位刚结婚的差不多:回到家乡找到了靠谱的工作,勾搭到了女票(当然这次这个还没到结婚的时候),之前买的房也交了装一装就准备住。。。周围全是人生赢家啊
吃完溜。目前看重庆可能一年会去那么一两次赶 LiveHouse,也可以趁机会再蹭几顿饭
今年数一数居然已经参加了五场 LiveHouse 了,还差最后银临的一场,也趁着这个机会出去走了走,见到了很多新老朋友,十分开心。可惜就是年假已经消耗殆尽,不出意外的话国庆之后不会再安排什么新的大活了。
下一篇应该是从石家庄回来之后的 Project Home 4 个人工作区介绍,应该会在十一月初左右发。
]]>至于为什么是 First Experience,主要是因为实际高强度使用它的时间太短,本身对大部分问题都不深入,而且后面又吃灰了很久,印象更浅了。。。
需要强调的是下面的内容基本都是基于 2023 年前两个月的体验完成,小部分为五六月份重新整理的时候补充,Windows on ARM 总体还是在逐渐完善的(比如近期 WSL2 有挺大更新),所以请注意信息时效性。
Surface Mini Project Volterra,微软官方出的一个面向开发者的 Windows on ARM 设备。32G + 512G 的价格是 4488,也算不上很贵,不过可能因为不能三包之类的问题吧,国内不能直接买,需要企业资质,当然草民直接摇了一个内部学长解决问题(
实际里面是 Surface Pro 9 5G(Qualcomm Snapdragon 8cx Gen 3,普通版是 Intel,几代忘了)的主板,拆掉 Modem 然后加一些转接板和一个螃蟹的 USB 有线网卡,再加一个相当大的散热器(然而它几乎不动,除非是负载很高的时候,所以外壳大部分时候还是温热的)。
虽然大塑料,但实际拿到手质感还行。
中间因为骷髅峡谷风扇坏了(那个风扇轴承是封死的,没法拆开上油,只好淘宝 50 块钱买了一个换上,很完美),拿它来干了大概三个礼拜左右的活,总体来说确实是没有 M1 迁移那次爽(当然平心而论两个设备做的事情难度也是有差距的),然后因为 Windows on ARM 有些小问题、WSL2 和 JetBrains Gateway 各种问题太多,而且骷髅峡谷已经修好,就又拿回家吃灰了。
其实大部分普通 Windows 程序都没遇到啥问题
NanaZip 是一个重新封装了一下并且上架 Microsoft Store 的 7-Zip,很好用,强烈推荐。
比较怪的也真的是有,主要似乎都是跟图形相关的,后面会举两个例子,下面先说一下干活的环境问题。
干活还是需要 Linux 环境以及图形界面。WSL2 + WSLg 功能上倒是没有什么问题,装 JetBrains 家 IDE 只需要先 apt 装 xterm 补一下基本的 X 环境依赖,再去官网下 arm64 的包就行了。本来是想直接用 snap 装的,但是 snap 上没有 arm64 的包,只能用官网的 tar.gz,总体还是稍有不便。Golang 工具链本身倒是有 arm64 的 snap(甚至 riscv64 的都有
一开始打算就直接 WSL2 + WSLg 了,用了一段时间发现不行。。。WSL2 最大的问题是 IRQ 会时不时卡住几秒甚至几十秒,这段时间整个 WSL2 是没任何反应的,其他时候倒是都很正常。但这随机卡几十秒这种事儿,干活的时候遇上的话是真的非常搞人心态
[24843.677056] rcu: INFO: rcu_sched self-detected stall on CPU
[24843.677682] rcu: 4-....: (14999 ticks this GP) idle=7df/1/0x4000000000000002 softirq=74545/74545 fqs=7288
[24843.678193] (t=15000 jiffies g=263025 q=37837)
[24843.678196] Task dump for CPU 4:
[24843.678197] task:fsnotifier state:R running task stack: 0 pid: 5381 ppid: 5243 flags:0x00000002
[24843.678201] Call trace:
[24843.678202] dump_backtrace+0x0/0x1c8
[24843.678208] show_stack+0x1c/0x28
[24843.678211] sched_show_task+0x14c/0x180
[24843.678215] dump_cpu_task+0x48/0x54
[24843.678218] rcu_dump_cpu_stacks+0xf4/0x138
[24843.678220] rcu_sched_clock_irq+0x938/0xaa0
[24843.678224] update_process_times+0x9c/0x2e0
[24843.678226] tick_sched_handle.isra.0+0x38/0x50
[24843.678229] tick_sched_timer+0x50/0xa0
[24843.678230] __hrtimer_run_queues+0x11c/0x328
[24843.678233] hrtimer_interrupt+0x118/0x300
[24843.678235] hv_stimer0_isr+0x28/0x30
[24843.678238] hv_stimer0_percpu_isr+0x14/0x20
[24843.678240] handle_percpu_devid_irq+0x8c/0x1c0
[24843.678243] handle_domain_irq+0x64/0x90
[24843.678246] gic_handle_irq+0xb8/0x128
[24843.678247] call_on_irq_stack+0x28/0x3c
[24843.678249] do_interrupt_handler+0x54/0x5c
[24843.678251] el1_interrupt+0x2c/0x40
[24843.678254] el1h_64_irq_handler+0x14/0x20
[24843.678256] el1h_64_irq+0x74/0x78
[24843.678257] filldir64+0x1fc/0x2d0
[24843.678259] call_filldir+0xa0/0x118
[24843.678262] ext4_readdir+0x548/0x810
[24843.678263] iterate_dir+0x168/0x1b8
[24843.678265] __arm64_sys_getdents64+0x6c/0x148
[24843.678267] invoke_syscall.constprop.0+0x50/0xd8
[24843.678269] do_el0_svc+0x54/0x150
[24843.678270] el0_svc+0x14/0x48
[24843.678271] el0t_64_sync_handler+0xa8/0xb0
[24843.678273] el0t_64_sync+0x158/0x15c
[24855.488319] hrtimer: interrupt took 43241303 ns
Update:等了一年似乎终于有人修这个问题了 https://github.com/microsoft/WSL/issues/10667
加上公司的网络环境有点复杂,会屏蔽 NAT 后面的设备(具体不知道是怎么做的),而且偶尔会需要 VPN 访问测试环境的数据库。草民之前的用法是通过一个 OpenWrt 虚拟机统一中转(顺便翻墙),但 WSL2 的交换机配起来有些麻烦,OpenVPN 弄起来也不方便,上面的卡顿问题也没法解决,最终还是放弃了。
WSL2 / WSLg 情况不乐观,那旧的方案呢?Hyper-V Ubuntu 22.04 的 Balloon 不能用,忍了,直接开机分 24G 内存给虚拟机,结果 Host 上 Edge 内存又不够了,只能再砍掉一些内存。。。
四月底那会儿本来想着 23.04 可能就修了,结果 23.04 最开始直接就启动不起来。。。还得接着忍。这几天翻出来一看又能起来了,但是动态内存还是不能用,明明已经装了 linux-azure 内核,都已经能从 Hyper-V 管理器上看到 Guest 的内存需求了,但还是不能动态扩充内存(当然了,缩也是不行的),不知道到底是缺了什么。
说起来 OpenWrt 的动态内存也一直不能用。这几天又研究了一下,得知要开几个内核选项:
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
CONFIG_MEMORY_HOTREMOVE=y
x86 的 OpenWrt 之前也是没开的,开了之后就没问题了,动态增减都一切正常。
但 ARM64 上开了还是完全没用,吐血,不过在内核日志里面发现一个报错
[ 0.084730] hv_utils: Registering HyperV Utility Driver
[ 0.084732] hv_vmbus: registering driver hv_utils
[ 0.084761] hv_vmbus: registering driver hv_balloon
[ 0.084867] drop_monitor: Initializing network drop monitor service
[ 0.085106] hv_utils: FCopy IC version 1.1
[ 0.085270] hv_utils: Heartbeat IC version 3.0
[ 0.086042] hv_utils: TimeSync IC version 4.0
[ 0.086161] hv_utils: Shutdown IC version 3.2
[ 0.086406] hv_utils: VSS IC version 5.0
[ 0.086763] hv_balloon: Using Dynamic Memory protocol version 2.0
[ 0.086768] hv_balloon: Memory hot add disabled on ARM64
对着报错又翻了一下内核代码,然后发现 hv_balloon.c 就直接是代码里面写死了在 ARM64 上禁用 Memery hot add,令人窒息。算了。回头研究一下能不能用传统一点的 balloon
除了动态内存的问题之外倒是没有别的问题,WSL 上 IRQ 迷之卡顿几十秒的情况从未出现过。
先说工作。JetBrains 家的 IDE 还是需要个图形界面,但这个怎么搞出来就很让人头疼。没有 WSLg 就还是得装一个 X Server,一开始打算还用 VcXsrv,但无论 32 位还是 64 位(都是 x86,没有找到 arm64 的)都非常卡,而且是持续非常卡,主要是上下滚动代码搓一下滚轮可能几百毫秒屏幕才会动,真没法用。换了几个不同的 X 服务器比如什么 Mobaxterm,都一样的卡。
于是回去又翻出来之前问题很多的 JetBrains Gateway,虽然之前用过,但是之前问题太严重了(终端不会自动 resize,Find Usages 之类的窗口渲染完全破碎),甚至还没高强度使用就直接劝退了。这次再翻出来,上面说的两个问题倒是已经修了,而且也没有更好的办法,进行了一波重度使用,然而问题还是非常多:
还有些 Go 调试器也会偶尔出问题(遇到的主要是断点里面的 Watch 到的变量一看就不对,甚至直接报错),总之真的很搞人心态。
摸鱼的过程中遇到的图形相关的怪问题就更多了,最让人裂开的是一些视频渲染的场景偶尔会变得非常离谱,会随机出现在任何地方,在 Unigram 和 Edge 里面都见到过(Edge 那次甚至还是全屏幕的,巨吓人
还有最近发现的一个怪问题:Type-C 口插显示器的时候在上面启动星穹铁道,登录进去之后三秒之内就会直接重启(甚至似乎不是 BSOD,事件日志里面找不到 BSOD 相关的内容,只能看到一个似乎是硬件 Watchdog 超时的记录,但系统又并未失去响应)。更怪的是如果走 RDP 的话,就完全不会有这个问题,这个大概只能是显卡的锅
用的不太多,只简单写一点印象。虚拟化性能感觉比起 x86 上转译(拿 Corsair One 来对比,9900K + 2080Ti)也没啥区别,主要是图形性能依然很烂,而且该怎么不稳定也还是怎么不稳定。
中间顺便编译了适用于 Hyper-V aarch64 的 OpenWrt 然后跟之前保持基本一样的用法,结果是大部分功能都基本正常,除了键盘死活没反应,初始配置绕了好大弯子。前几天又认真研究了一下,把 AT 这种老键盘的驱动加进去就一切正常了。。。
写到这儿时候的版本 OpenWrt SNAPSHOT r23352-3baa45fbd8
需要解决这些问题:
以上差不多是今年上半年的折腾记录,总体来看确实坑比较多,至于为什么拖到现在就是另一回事了。。。过去半年多也没有再高强度使用它了,现在摆在床头柜上吃灰
不过另一个方向却来了个新活:几个月之前吐槽过的 Photonicat 最近突然发了一个基于 6.1.40 内核的 Ubuntu 桌面版,相当完整,除了内核还是自己编译的之外也基本没什么定制的地方,最有意思的是它可以直接跑 ARM SystemReady 的 KVM,甚至可以正常跑上面那个给 Hyper-V 准备的 OpenWrt 同时直通 USB 设备(比如 5G 网卡)。可惜 sdio 的无线网卡没法通不然就很完美了。
下一步的计划是打算认真搞一搞 ARM SystemReady 和 RK3568 上的 OpenWrt,而且似乎已经有人做了 RK3568 的 UEFI 环境,或许会考虑拿来适配一下光影猫,这样两个 Topic 可以合并为一个。
]]>用了大半年,目前感觉比较稳定,除了感觉本地中枢现在来看没啥用之外基本没有什么问题
它的硬件实际上是一个联发科的无线网卡(虽然并不能拿来当无线网卡用,即便是 Linux 下面也不行
但是这玩意儿的驱动吧
实际它的信号比蓝牙稍好一点有限,隔一堵墙可用性已经比较差了,可能会随机断线。加上买电视这事儿一直被拖着,客厅串流就很难搞。还是回头把 Xbox One X 拿来放在客厅比较靠谱一些。
Flag 回收。网图一张,不自己搞了。这次买已经买不到狗东自营了,只能在第三方店铺买,不知道几年之后这副寄了该再买什么。
音质依然非常完美,不过最近越来越没有听歌的兴致了。
一个基于 RK3568 的便携路由。
两个千兆网口 + HDMI 输出 + USB 3.0 + 两个 PCIE M2 插槽(一个只能插 5G Modem,大概只有 USB 定义;另一个能插 PCIE 无线网卡)
草民选的配置是 4GB RAM + 64GB Flash 再加 RM500U-CN(不知道具体是哪家的 5G 方案,反正不是高通,不能用 QMI 所以之前的短信转发 Bot 也就不能用了
之前买来因为官方开源的 OpenWrt 是个基于 Lean 的魔改分支,草民自己的 luci-app-xray 没法用,加上很长一段时间内没啥需求所以就一直在吃灰。五一出门需要用所以就拿出来收拾了一下,刷了一下官方四月初的固件、装了 passwall 然后试着用了一下:
也试着折腾了一下官方开源出来的那个 OpenWrt,编译流程非常非常奇怪,魔改的地方非常多,各方面都很难搞。。。
总之总结为一次比较失败的购买经历,先吃灰或者可能刷个 Android 之类的吧,之后或许啥时候官方有了 RK3568 支持再看情况收拾收拾
这个一开始是打算专门拆出来一篇来介绍的,结果中间真的试着拿去干活,但是前后只坚持了三个星期。。。
后面吃灰了几个月又拿出来整理,结果又发现可以吐槽的比预想的多,所以最后还是打算单独写了(其实本来是打算在这篇之前发出来的,但是最近沉迷王国之泪和星穹铁道,所以咕咕咕
本来是准备给 R86s 用的,但后来换了外壳发现已经很不错了,而且之前的硅脂也是比较好的那种,于是就没有弄
这玩意儿相变 45 度,可能对于 R86s 来说大部分工作时间都在相变温度以下。。。所以可能回头会拿去给别的设备用,先扔着吧
没怎么用就丢在机场了。不知道为什么头昏了带去。
有一说一,这个价其实也基本就图一乐吧,没法太认真。
强迫症究极救星。很便宜,一包好像十几二十个,一个双人床肯定是绰绰有余了。草民是床头 7 个,两侧各 3 个,床尾因为经常要抬起来拿下面的东西所以没有固定,实际也用不到。
实际适合比较厚一点的床单,太薄或者太滑的话效果一般(比如上家某年过年发的那个深绿色四件套,里面的床单就不是很好
还有一个小技巧是它可以顺便用来固定一些充电线,进一步拯救强迫症
前面有说过 Windows Server 2022 蓝牙很难搞,草民偶尔开会之类还是需要无线耳机,然后这款耳机有一个用 2.4G 无线连接的模式(就是图上那个 USB 接口的东西,是个标准的 USB Audio Class 设备),宣传为游戏低延迟模式。当然草民主要看中这个模式不需要蓝牙,价格也不算贵(现在应该不到三百了),就买来试了试。
问题其实跟很多这个价位的 TWS 耳机差不多:
它的 USB 接收器下面那个小的部分可以拔出来得到一个 Type-C 接口的本体,不过体积偏大不能直接怼在骷髅峡谷后面的 Type-C 接口上,于是最终又是拿回家吃灰了。至于开会,还是接着用有线耳机好了,反正现在可能一两个星期都用不到一次
趁打折 499 入手。很不错的鼠标,尤其是那个惯性滚轮贼好玩。侧面滚轮确实还是挺有用的。比较可惜的是 Type-C 接口只能用来充电,不能真的用来临时作为有线鼠标使用。在公司用的时候偶尔会掉帧,需要开关一下鼠标电源,还不行就得充电了。
Flow 也确实好用,但就是 Options 那个程序资源占用有点多。顺便 M720 拿回家里了,但那玩意儿侧面胶皮太容易磨损了,现在已经是一个大坑,只能在上面贴一些遮盖胶带避免它进一步恶化。
R86s 原来的外壳风扇突然就寄了(就在骷髅峡谷的风扇寄了之后没多久,可能是因为那会儿买了除尘气罐,见啥喷啥,把灰尘喷进轴承里面了。说起来这俩风扇都是把轴承完全用硬塑料封死的,完全不能打开加油之类处理,看不懂为啥)。喷了一大堆松动剂进去效果一般,干脆直接整个上盖换掉。直接用一张旧图吧(除了颜色之外东西是一样的
换过外壳之后散热果然有非常显著的提升。刚好跟上次跑 aida64 的时间隔快一年了,气温差不多,直接上图对比
同样是 15 分钟烤鸡(两张图时间轴的比例尺不一样),换外壳之前一开始测试就直冲 90 度,然后很快开始过热降频;换壳之后最高温也不过刚刚 80 度,全程无过热降频,而且结束之后在很短的时间内就降到了 50 度左右,是不是立竿见影。
以及五月份官方出了新的 BIOS 更新了 CPU 微码,据说解决了虚拟机死机问题。虽然草民好像没有遇到过虚拟机死机的情况,但是偶尔会碰见 IOMMU 报错,不知道这个与微码有没有关系。
这个问题可怕就可怕在一旦发生,会直接把 OpenWrt 虚拟机连同穿进去的 QCA6391 一起带走,而且重启虚拟机并不会重置 QCA6391 的状态,甚至重启一次物理机可能也不够,需要重启两次物理机。。。因为这个问题草民近期一直在考虑 Router 和 AP 拆分为两个虚拟机避免无线网卡把整个路由一波带走的方案,如果确认下来后面会再介绍。
一个国产开源方案的硬件密钥,支持的特性很全,Fido2 / PIV / OpenPGP / TOTP / HOTP 啥的都支持,当然一般来说最常用的也就是 Fido2 和 TOTP。最大的槽点主要是 NFC 是真的不好用,需要在很严格的角度上才能识别出来,官方说是因为芯片功耗问题导致的,所以想用 NFC 的话只能用挂绳,不能直接栓在钥匙上。
一次买 5 个可以打 9 折,平均一个 150 多,飞天的一个可能接近 200(主要是国内没渠道不好买到)。两个同事每人带两个,剩一个自用
管理工具就是一个网页,所以可以非常方便的使用它的 TOTP 功能,当然要导入密钥进去是个挺麻烦的事情(简单的说扫那个绑定 TOTP 的二维码然后会看到链接里面有一个 Secret 由大写字母和数字组成,导入的话要一个一个把所有的密钥打进去)。
其他的跟飞天的 Key 差不多,User Precence(就是要摸一下的那个验证)反应速度快不少。
OpenSSH 某个版本之后直接支持 Fido2 了,这意味着 Git 什么的也可以绑在上面,不过用起来还是不那么直接,之后折腾一下。
其实是涡轮扇,风量确实很足,当然噪音也是真的大。
草民买来主要是除尘用,但跟压缩空气比还是有点差距,物体表面的灰尘还是很难全吹走,还得擦。目前基本用来辅助日常卫生打扫
之前很难买到,现在淘宝到处都是了,甚至跟 MT792x 一个价。草民买到的这一张卡蓝牙走 USB,驱动应该直接装就行了。
顺带一提 Windows Dev Kit 2023 里面也是这个无线方案,当然那个拆不下来,而且蓝牙是走 UART 的。在设备管理器里面按连接查看的话,走 UART 的蓝牙是直接跟所有 Platform Device 在一个层级上,而不是挂在某个 USB Root Hub 或 PCI Express Root Complex 下面的
OpenWrt Master 没法直接用,下载 WCN6855 最新的几个 Firmware 文件,放在 OpenWrt 的对应位置才能正常使用它。
实际用下来,Ping 比 QCA6391 慢大概 2ms 的样子,其他区别不大,比 MT792x 还是显著要好的,但是它的发射功率比起前面两张卡就要再小两三个 dB 了。具体的测试数据因为时间比较久了找不到了,也实在不想再拆开 R86s 重新折腾一遍(尤其是在 AP 和 Router 没有区分开的情况下,换无线网卡需要整个重新配 PCIE Passthrough 才能让虚拟机重新正常启动,真的很麻烦
这张卡支持 WiFi 6E 但是大家也懂这个国内频率没审批下来,暂时用不了。综合考虑,目前是换回了 QCA6391 接着用
大概是市面上为数不多满足以下所有条件的 RISC-V 开发板:
薅两张官方图,来自 https://mangopi.org/mangopi_mqpro
板子上有个 SPI Flash 焊盘(有一种可能这个 TF 卡也是跟老树莓派一样用 SPI 模式的所以特别慢),在想有没有可能焊一个上去,刚好 OpenWrt Master 有人提了 PR 支持这块儿板子,后面可以搭一个刚好塞得下的 OpenWrt 出来玩
草民的体验都基于两三个版本的 Ubuntu,没有用官方的 armbian 什么的(毕竟那种一般都不怎么靠谱)。拿到手一开始折腾起来还是有点痛苦,最大的槽点主要是无线驱动装起来实在是太麻烦了,而且 Ubuntu 官方那个 23.04 启动的时候拉不起来无线(22.04 & 22.10 没这问题),必须进了 shell 之后重新 netplan apply
,很怪。。。
装无线驱动的话,如果是官方的 22.10 就装 licheerv-rtl8723ds-dkms 一个包进去就行了,如果是 22.04 则需要先装 dkms,而 dkms 大家应该知道它是包括 build-essential 及其组成部分(gcc make 等等一大堆)的,这一堆依赖全手动处理的话着实比较酸爽,所以必须准备一个简单能用的 USB 网络连接:
如果实在不愿意搞的话就还是用 22.10,当然个人还是比较建议 22.04 的,毕竟 LTS 还是省心一些
这玩意儿还必须配一个 HDMI 否则真的搞不定初始设置。假如真的花很大力气都调好了的话稳定性还挺不错,包括无线信号也挺不错的(虽然板子上有一个 IPEX,但完全不用接外接天线,信号就很不错),比什么量子计划好太多了,不过不知道是哪里的问题,如果它连接的 AP 重启了它的重连会一直失败,挺奇怪的(个人感觉是螃蟹的锅)。然后最近可能大概也许是天热了,它的 WiFi 似乎也开始不稳定起来了,表现为 RouterOS 上看无线还连着但是 ping 已经不通了,或者能 ping 但是 ssh 没反应。遇到这种情况直接在 RouterOS 上把它踹了就行,过几秒它自动重连上来就恢复了。感觉可能还是螃蟹的锅(
性能只能说挺烂的,差不多就只能跟树莓派 Zero 打个有来有回(当然会被树莓派 Zero 2 或者树莓派 3 以后的版本吊打)那种,主要是 IO 性能真的是烂到离谱,无论是杂牌 C10 卡还是 SanDisk A2 卡都卡得一逼。至于其他的什么图形性能之类的都当不存在好了,总之买来尝鲜倒是也还行,反正没几个钱。油管上有个小评测个人觉得还能看看 https://www.youtube.com/watch?v=-g18PMjjlcc
比较有意思的大概算是这玩意儿居然用 UEFI 启动,虽然好像也不完全是,它还是要从 TF 卡上两个固定分区加载一些迷之二进制代码(loader1 不知道是什么,loader2 叫什么 OpenSBI)再切换到 UEFI 环境。UEFI 启动还是先启动 GRUB,以及安全启动无(这一点都不意外吧)。说起来前段时间见到 Fedora 不打算维护普通 BIOS 方式启动的内核了,打算改用 U-Boot 之类的提前搭一个 UEFI 环境出来再用它启动内核(https://www.phoronix.com/news/Fedora-U-Boot-x86-BIOS),有一说一草民觉得还挺合理的
后来又折腾了一下蓝牙,其实很简单,补两个固件就行(不知道为什么这两个没提交到 linux-firmware):
sudo wget -O /lib/firmware/rtl_bt/rtl8723ds_config.bin https://github.com/armbian/firmware/raw/master/rtl_bt/rtl8723ds_config.bin
sudo wget -O /lib/firmware/rtl_bt/rtl8723ds_fw.bin https://github.com/armbian/firmware/raw/master/rtl_bt/rtl8723ds_fw.bin
再装两个包就可以了。
sudo apt install bluez bluez-tools
之前想找一个靠谱 MP3 的后续。官网半死不活,不过固件居然还挺新的。。。
实际用下来,滚轮比 EROS TEN 还松(不过它起码可以用来滚动歌曲列表啥的了),底噪很大,随机播放不好用(上一曲居然是完全随机的,还不如 EROS TEN),然后屏幕盖板居然轻轻一按就裂了,于是吃灰。总之各方面都非常令人失望,又是一次比较失败的购买经历
三月份去龙泉赏桃花的时候 K30 Pro 寄了,当时急着用就只好随便买了一台。至于草民为什么选了一台线下 & 面向女性用户的手机,其实草民主要想的是,反正下半年 iPhone 8 -> iPhone 15,这台机器只要手感好、轻、能用就行(
实际买下来用了一段时间,个人感觉是手感确实不错,而且 120Hz 的屏幕确实是用过就回不去了。有一说一,这玩意儿居然有前置补光灯,而且还是左右各一个,还贼亮,简直离谱,但这玩意儿后置虽然凸起来那么多,其实甚至不如 K30 Pro
槽点主要是充电真的慢,亮屏充电几乎充不进去,然后屏幕默认颜色很怪严重偏蓝,开护眼也没用,需要进高级模式强行把蓝色降低。其他的很多地方感觉也有点卡,总体体验感觉甚至还不如几年前的 K30 Pro,以及指纹位置真的很靠下按起来挺别扭的。。。
买来十天就出了下面那个,结果血亏一千块转手了,前后加起来也没用几天,算逑
首发买了 16GB + 1TB 的(颜色也是下面这个图的),当然草民主要是奔着 16GB 内存去的,结果目前只能说 1TB 确实用不完了。各方面都还挺不错的,打星穹铁道比 iPad Mini 5 还要流畅许多,电池续航、充电那些也很好,还有外星科技 3.5mm 耳机接口。
虽然大家都在说扫码头,但个人觉得还行,除了感觉对焦略费劲之外没啥别的。当然槽点吧也有:
在酷安上见到几个机身弯了的,也不算太意外,反正再过几个月它的角色就是备用机了(
Plus³ 确实是跟 2³ 个小魔方堆起来基本一样大,然后就真的搞了个八合一。八合一盘起来手感明显是不如 Plus³ 的,而且组装很麻烦
友情出镜:服役五年半(其中高强度四年多吧),刚换完风扇继续高强度服役的骷髅峡谷
以前完全没留意过(因为基本都用第三方充电器),后来才知道就这里面弯弯绕绕还挺多的,65w 的,67w 的,普通接口魔改接口的。
上面三个都是小米魔改 Type-A,从左到右:K30 Pro 送的 33W,Civi 2 送的 67W,去年线下买的 67W
小米魔改的这种是在 Type-A 原来留给 USB 3.0 的那个位置的正中间额外加了一个 PD 用的 CC 引脚,需要搭配小米自己这个特殊的 Type-A 转 Type-C 线,就可以支持 PD 可以充 MacBook Pro,不过 33W 的看 https://www.chongdiantou.com/archives/56474.html 的介绍 PD 应该只有 27W,67W 的几个走 PD 应该最多只有 65W
上面两个就是比较平平无奇的 GAN 充电头了,线下买的,扔在公司用。虽然都有 Type-A 但是不像上面那些做了 Type-A 上的魔改,不过后面买的俩 Type-C 口的那个支持小米的私有 67W 协议(当然走 PD 也是只有 65W),前面那个就只有 PD 了。具体的输出功率什么的,充电头网上的相关数据相当全,草民自己现在手头就没有 USB 测试器了,回头再买一个搞搞
NAS 里面两块盘,一块 WD120EMAZ 三年多没停(30000 小时了),另一块 WD120EDAZ 18000+ 小时,也接近两年半(警觉)了。加上最近 WD 整了一个活说通电三年左右的盘建议更换,想来虽然这俩盘目前一切正常没有任何问题,但还是做好替换计划的好。
上面两块盘一看型号很明显就是老母鸡拆的。这两块盘虽然不知道型号上的区别到底代表什么,不过据说硬件上区别不大,都是企业级氦气盘降速。因为草民一直是 ZFS Mirror 所以实际用着也没感觉出过什么区别。前几天看了一下 Amazon 发现老母鸡似乎价格又还行,于是又收一块,这次就比较不幸抽中了 WD120EMFZ 这种 14TB 降容到 12TB 的盘。。。更难顶的是这块盘看贴纸,生产日期居然是差不多三年半以前了,不知道是堆了多久的库存货。不过要说也确实是非常巧,三个老母鸡刚好把 12TB 所有型号凑齐,不过鉴于这次买到的这个老母鸡,硬盘极为离谱、库存时间更离谱,以后应该不会再买老母鸡了。
因为这三个杀鸡取卵盘目前情况都比较难说,想了想为了求稳还是狗东又买了一块正常的 HC520(HGST HUH721212ALE600),这次拿到的是去年年底生产的一块很普通的盘。考虑到盘的情况和重建阵列太麻烦这件事,目前直接干脆组了 Mirror x4,过段时间可能会按照之前的计划那样从家里把冷盘拿来然后重建成 RAIDz2
> zpool status
pool: opt
state: ONLINE
scan: scrub repaired 0B in 11:53:54 with 0 errors on Tue Jun 20 13:00:12 2023
remove: Removal of vdev 3 copied 1.91M in 0h0m, completed on Sun Jun 18 12:40:59 2023
552 memory used for removed device mappings
config:
NAME STATE READ WRITE CKSUM
opt ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sdd ONLINE 0 0 0
logs
nvme0n1p3 ONLINE 0 0 0
cache
nvme0n1p4 ONLINE 0 0 0
errors: No known data errors
其实 12TB 就已经很难用完了,现在用了大概不到 5T,Scrub 一周跑一次,一次已经要十几个小时,近期大概率还是会再删一些没啥用的东西
近期打算买的:
在云南买的一个木头摆件,确实是十分可爱。
下次是 Windows Dev Kit 2023 折腾记录,大概七月中旬发。
]]>TL;DR: https://github.com/openzfs/zfs/issues/14753
下面草民自己排查问题的过程按实际操作时间来排序,所以会有些许混乱(这也是因为草民当时确实有点慌,真的是想到啥看啥
从 4 月 22 号开始,草民的例行 OpenWrt 编译就再也过不去了,会随机卡在一些难以理解的地方:
这个卡的形式着实很难以理解,而且还不固定,重复 make dirclean
再构建几次,每次卡的地方还都不一样,百思不得其解。
把日志级别调高之后再跑,然后抽了一次失败的构建仔细看了一下日志,发现似乎有问题的文件会变成全 0
进到构建目录里面简单看了一遍,过程中的中间产物要么全 0,要么完全正常。全 0 可能发生在过程中产生的任何文件上,包括源代码、通过工具生成的代码(比如什么 automake
出来的配置)、构建出来的中间产物(比如一些 .a
文件)和最终产物(比如 bison
或者 patch
)。有一说一,草民折腾电脑二十多年得有了,如此诡异的问题当真是头一次遇到。。。
一开始肯定会怀疑 OpenWrt Master 代码又炸了,但上面这个问题实在是过于离谱,真的很难这样怀疑:
前几天刚更新了 Manjaro,所以当时也在想是不是内核爆炸导致一些延缓写入产生问题,于是先装了个 6.2.x(原来是 6.1.25)的内核。
重新试了一下发现完全没变化,该怎么炸怎么炸。。。
前几天草民某台 VPS 被黑了(这又是另一个很有趣的事情,下面会简单说一下),那台 VPS 是接入到了草民的 Tinc 大局域网了的,而且草民这个 NAS 的密码也很弱(虽然跟上面那个 VPS 不一样),当时着实很担心黑客会不会顺着 Tinc 网络直接把草民整个内网淦翻。
今天遇到这个极其怪异的事儿之后忍不住会往被人搞了的方向去想,尤其草民之前还看到过一些替换 glibc 隐藏挖矿脚本之类的活儿,这个活儿如果整的不干净的话确实可能会导致系统出现各种各样奇奇怪怪的问题。但实在是没抓到任何证据(CPU 占用率,传感器之类都完全显示为空载状态,也没看到什么怪进程),很难确认或排除这个因素,所以这块儿也就只好先搁置了。
跟几位群友聊过之后也怀疑是不是盘坏了,但挨个看了 smart 和 zpool 状态,都一切正常,而且草民每周定时 scrub 完全没遇到过问题
但现在确实该怀疑一下文件系统或者磁盘了,于是开了个 zpool scrub
跑着。不过跑一遍要十来个小时,让它跑了一会儿(大概 10%)左右没看到任何异常,于是让它后台跑着,继续考虑其他可能的问题
虽然上面有说过 OpenWrt 自己炸的可能性着实不大,但查了一顿其他可能的地方实在是让人不得不怀疑是不是 Master 真的炸了,于是翻出了好长时间没动过的 OpenWrt 21.02,然后发现也炸了
跑了几次,跟 Master 的表现完全一样,也是中间产物会随机莫名其妙变成全 0,这足够说明不是 OpenWrt 自己代码的问题。开始感觉不对劲
为了进一步排除代码问题,把上面一直在爆炸的 OpenWrt Master 直接整个 rsync 到了另一台电脑上的 WSL 里面编译
除去一点环境问题之外一切正常,编译出来的东西也跑的很顺利
至此得到明确结论:排除 OpenWrt Master 代码自己的问题
此时有些开始怀疑有没有可能是 ZFS 的问题了,考虑到是写入场景的问题于是打算先把 SLOG 关掉,但是关的时候可能是因为还在同步跑 scrub,卡住了。。。等了好久终于关掉了。回过头来偶然看到 dmesg 上有一些 ZFS 的 task hung(什么 l2arc_feed 之类的),大喜过望,以为是 L2ARC 读的时候一致性爆炸导致的问题,立即关掉 L2ARC,然后马上试了一次。。。
还是没用,该怎么爆炸怎么爆炸。回过头来一想这些 task hung 应该是上面那个关 SLOG 的时候卡住的提示。。。
话说回来,以前有 L2ARC 的时候觉得也不是很有用,摘了发现嘿,没有 L2ARC 还真不行
虽然草民完全不相信内存可能出问题,但草民实在不知道会是什么问题了,就真的去跑了!
跑了快三个小时,结果也确实是完全没问题。。。
草民又回过头来去想会不会是 glibc 有问题,于是做了这样的操作:
到这一步应该可以 90% 以上排除 userspace 的问题了,问题要么是内核要么是文件系统
既然已经在怀疑可能是 ZFS 的问题,那就干脆整个别的文件系统,如此应该可以完全确认是不是 ZFS 带来的问题。
此时已经快凌晨五点了,于是随手搞了一个 ext2 的虚拟盘,并把刚才在 WSL 上确认过没问题的同一份代码复制上去,开起来编译就去睡了。
早上九点多醒过来看了一眼,果然一切正常
到这个时候其实差不多已经可以确认就是 ZFS 的问题了,但中间又有个小插曲:不知道是因为早上贼懵还是啥,草民配了一个(自以为)全部在 tmpfs 上的环境,结果它又爆炸了(当然后来一看是 OpenWrt 里面的 staging_dir 下面的一个目录没映射好
本来上面那个换文件系统的试验应该可以确认就是 ZFS 的问题了,但因为这个插曲草民又非常绝望的降了一下大版本内核(6.1.25 降到 5.15.108),然后发现没有任何用处
后来草民去看了一眼 kernel.org,非常不出意外 Stable 和几个 LongTerm 其实都在同一天有更新,所以其实上面提到的把内核从 6.1 降到 5.15 其实很大概率是没啥球用的
Manjaro 对一个大版本内核只留一个小版本,不像 Ubuntu 之类会留两三个,草民的 /boot 又没有放在 zfs 上(其实是可以放的但是有些麻烦,而且感觉没必要),查了半天也没查到要怎样在 Manjaro 上回退小版本内核(包括各种模块,嗯,比如 zfs)
跟群友们进行了进一步交流,群友建议要不要搞点 ebpf 看看具体坏掉的文件被谁操作过。虽然草民不完全确定这种大概率是文件系统爆炸的事情在内核里面的表现是怎么样的,但因为这个坏的表现又很奇怪(文件要么完全正常,要么全 0),感觉或许也能看到一些端倪,所以还是拿出了 strace
# original command: make V=99 -16
sudo strace -u yichya -ff -o ~/duplicate_test_2/strace.txt make V=99 -j16 > /home/yichya/duplicate_test_2/stdout.txt 2> /home/yichya/duplicate_test_2/stderr.txt
跑了两遍,然后得到了加起来 11G+,一共 360000+ 个文件(每一个文件对应一个过程中产生的 pid)的系统调用追踪,只能苦一苦 VSCode 了。
yichya@yichya-nas ~> du -hs duplicate_test*
8.0G duplicate_test
3.3G duplicate_test_2
yichya@yichya-nas ~> cd duplicate_test
yichya@yichya-nas ~/duplicate_test> ls -1 | wc -l
261035
yichya@yichya-nas ~/duplicate_test> cd ../duplicate_test_2/
yichya@yichya-nas ~/duplicate_test_2> ls -1 | wc -l
105193
对着报错日志里面异常的文件开始找对应的 strace,果然发现了奇怪的地方:问题出在复制文件的过程中,原文件明明存在、有内容(确认过了正常),openat
原文件都正常拿到 fd 了,lseek
却报了个非常怪异的错误,下面一步 ftruncate
直接在目标那儿写了一个全空的稀疏文件。。。
似乎遇到问题的都是在复制文件的过程中尝试了使用 SEEK_DATA
+ SEEK_HOLE
这种方式的,了解了一下,这个大致是一个用来复制稀疏文件的操作。
另外一次的情况略有不同:之前的文件都是全 0,这次的这一个文件是坏在 128K 开始的地方
但在对应的 strace 中也找到了完全匹配的记录:原来的文件是满满当当 4M 多大,复制的时候 SEEK_HOLE
硬说只有 128KB,于是目标文件就只有前面 128KB 内容,后面快 4M 都是空洞
试图使用对应的命令(实际上就是 coreutils 里面的 install
和 cp
)复现,没成功,但是得到了正常的 strace 结果,用于对比
跟群友们交流了一下上面的发现。就在草民还在想上面这个问题到底是内核炸了还是 zfs 炸了的时候,群友手速比我快,直接在 GitHub 上搜到了前面贴的那个 issue,确认就是 zfs 2.1.10 引入的严重 bug,为此专门发了一个 2.1.11 进行修复。问题确实只影响使用 SEEK_DATA
+ SEEK_HOLE
读文件的操作,而且是个 race condition,只在有比较明显 io 压力的时候容易复现,而且这个问题因为并不是盘上数据结构异常,ZFS 自带的 Checksum 和 Scrub 之类机制都没有办法检测到(话说回来,如果它们检测到了甚至开始主动尝试修复数据的话,说不定麻烦会更大)。反馈这个问题的大佬跟草民的使用场景十分相似,是构建 FreeBSD 软件包的过程中遇到随机失败。
至于构建过程中编译内核的部分为何保持稳定,其实很简单,它是整个过程中相对独立的一个步骤(不会被其他的 job 失败打断),并且它没有涉及到上面那种读取方式。
知道啥问题其实也就还好,对现有数据不会造成任何影响,只是复制的时候会有概率出问题,那对草民来说影响不大,等 Manjaro 升级到 zfs 2.1.11 就行了。于是终于睡了一个安稳觉。
下一个比较扯的问题就又不知道是谁的锅了:草民兴冲冲从 stable 切到 testing,装上 zfs 2.1.11,结果一重启 rootfs 挂不上了。。。苦哈哈拿出 LiveCD 一顿修,发现 initcpio 脚本文件名改了。。。。。。虽然这个比起上面那个问题就根本不算事,几分钟修好。但是最扯的是,这个问题甚至活到了 Manjaro 发 Stable,发出来又过了一天才修复,真真的开源灵车。。。
最终问题在 5 月 8 号完全解决,耗时差不多两个星期。
关于这个问题个人的一点思考
上面说被黑这个事情是怎么个经过呢?4.21 晚上发现草民某台新加坡 VPS 被黑进去了。这台机器吧
显然是个非常完美的靶子,而且完美到甚至不太确定是被弱密码淦进去还是被什么别的漏洞淦进去(也说不定是都被淦过了呢),不过大概率是弱密码
草民是怎么发现被黑了呢?这就非常搞笑了,这位大哥大摇大摆在 Edge 里面搜「download firefox」然后装了个 Firefox,然后注册了一个 Amazon 账号,绑了一张 Visa 卡,买了一根还没运费贵的激光笔……然后还没退出账号登录,甚至历史记录都没有清理。
本来想直接给他退了,但是 Amazon 没法直接取消订单,得人肉把商品寄回。。。不管了,小开个盒,虽然这卡大概率来路不正
后来又翻了翻 Windows Defender 的记录,起码清明节那会儿就已经被人搞进去了,害
粗看了一下除了被装了某个挖矿软件(正常操作,不过很搞笑的是因为不明原因它没能自动启动)之外似乎没发现其他行为,重装系统重打补丁改端口改默认用户完事。之后看了系统日志,天天都在被人扫 RDP,即使改了端口也是,十分头秃
所以对 VPS 的安全性还是得上点心,以及 Windows 什么时候能在不开 AD 的情况下支持稍微好一点的验证方式(尤其是硬件密钥
之前一直头疼怎样在家里路由器这种没有公网 IP 的环境下实现自动更新 LetsEncrypt 的 TLS 证书。
因为没有公网 IP,http 验证会相当麻烦(只能通过内网穿透的方式进行,但又觉得链路太长,很不稳定),而且 http 验证不能签发 wildcard 证书,所以最好还是用 DNS 方式。虽然也考虑过用 Cloudflare 的 API,但同样觉得很麻烦,而且 Cloudflare 已经设置了 Edge 证书,再额外弄一个别的证书似乎也有点怪。
草民这个 .dev 域名一开始是在 namecheap 上买的,后来为了方便使用邮件转发(以及为了续费省钱)挪到了 Google Domains,但之前 Google Domains 没个像样的 API 支持也就没办法通过 DNS 方式自动更新证书。前段时间突然发现 Google Domains 支持了 API,而且 OpenWrt 自带的 luci-app-acme 使用的 acme.sh 也合并了一个支持的插件(https://github.com/acmesh-official/acme.sh/pull/4542),看来这个问题可以得到解决了。
先在 Google Domains 这里申请一个 API Token
同时配置一下域名解析,比如下面都以 *.home.yichya.dev
为例,这里解析到家中 OpenWrt 的 Tinc 地址,这样所有接入 Tinc 大局域网的设备都可以直接在这个域名上正常使用 HTTPS 访问
从这里开始的操作在 OpenWrt 上完成。
出于安全考虑(SSRF),OpenWrt 的 dnsmasq 默认会阻止结果为内网地址的解析,所以需要把对应的域名过滤掉。省事儿一点就直接在这里写一个 yichya.dev
先安装 luci-app-acme,然后因为 OpenWrt 自带的 acme.sh 版本比较老,而且即使是 acme.sh 自己最新的 Release 也还没来得及包含这个脚本,所以需要把上面这个 pr 里面的脚本下载下来放在 /usr/lib/acme/client/dnsapi
下面
root@OpenWrt:/usr/lib/acme/client/dnsapi# ls -al
drwxr-xr-x 2 root root 43 May 14 20:45 .
drwxr-xr-x 3 root root 44 May 14 20:45 ..
-rwxr-xr-x 1 root root 4387 May 14 20:45 dns_googledomains.sh
在 LuCI 里面填一下对应内容(或者直接改 /etc/config/acme
)填写好对应的信息就行了,比如我这里是
config acme
option account_email 'yichya.2008@gmail.com'
option debug '1'
config cert 'wildcard_home_yichya_dev'
option enabled '1'
option staging '1'
option dns 'dns_googledomains'
option use_staging '0'
option keylength 'ec-256'
option update_uhttpd '0'
option validation_method 'dns'
list credentials 'GOOGLEDOMAINS_ACCESS_TOKEN=<redacted>'
list domains '*.home.yichya.dev'
运行一次 /etc/init.d/acme start
就会自动尝试签发证书,如果没什么问题的话就可以在 /etc/acme
下面看到每个域名的证书
root@OpenWrt:/etc/acme/*.home.yichya.dev_ecc# ls -al
-rw-r--r-- 1 root root 1578 May 10 11:42 *.home.yichya.dev.cer
-rw-r--r-- 1 root root 799 May 10 11:42 *.home.yichya.dev.conf
-rw-r--r-- 1 root root 432 May 10 11:41 *.home.yichya.dev.csr
-rw-r--r-- 1 root root 152 May 10 11:41 *.home.yichya.dev.csr.conf
-rw-r--r-- 1 root root 227 May 10 11:41 *.home.yichya.dev.key
drwxr-xr-x 2 root root 3488 May 14 21:08 .
drwxr-xr-x 1 root root 3488 May 14 21:08 ..
-rw-r--r-- 1 root root 3751 May 10 11:42 ca.cer
-rw------- 1 root root 5556 May 10 11:42 combined.cer
-rw-r--r-- 1 root root 5329 May 10 11:42 fullchain.cer
一般情况下证书用 fullchain.cer
,私钥就是唯一一个 .key
文件。建议在需要的地方建一个符号链接使用这两个文件,下面会以草民的用法为例
草民这里使用 Xray 直接做 SNI 分流转发,luci-app-xray 提供了很好的支持。
首先先把证书通过符号链接放到 luci-app-xray 要求的 /etc/luci-uploads/xray
下面
root@OpenWrt:/etc/luci-uploads/xray# ls -al
drwxr-xr-x 1 root root 3488 May 14 21:08 .
drwxr-xr-x 1 root root 3488 May 14 21:08 ..
lrwxrwxrwx 1 root root 45 May 14 21:08 server.crt -> /etc/acme/*.home.yichya.dev_ecc/fullchain.cer
lrwxrwxrwx 1 root root 53 May 14 21:08 server.key -> /etc/acme/*.home.yichya.dev_ecc/*.home.yichya.dev.key
在 luci-app-xray 的 HTTPS Server 这个 Tab 里面简单设置,使用一个支持 SNI 回落的协议(比如 VLESS)即可,当然也可以用它连回家庭网络
在下面的 Fallback 里面设置按照 SNI 进行转发即可,不在这个列表里面的 SNI 会被转发到上面的 Default Fallback HTTP Server
然后就可以在内网正常使用 Jenkins 了。
证书的更新是每天 0 点自动运行,当然每次 OpenWrt 启动的时候也会运行。不是每次运行都会实际去更新证书,应该会是到期之前一个月左右去实际进行更新。
虽然可能并非所有 HTTPS Server 都能不重启直接使用新的证书(比如 Xray 就草民没有实际确认过这块儿的行为),但对于草民自己来说,因为更新 OpenWrt 大概是每天或者每几天进行一次的操作,更新证书之后可能几个小时或者最多两三天就会重启然后加载到新的证书,所以这对草民来说完全不影响。
下一篇会是 Gadgets (2023),说好的个人工作区介绍因为一些咕咕咕的原因估计要拖到十月份,从石家庄拿回所有需要的东西之后了(
]]>今年五一假期是 4.29 - 5.3 嘛。本来草民是打算按之前的操作一样前面请两天假、后面在家休息一天半左右的节奏来安排,结果两个大佬订了 4.30 晚上的飞机(回来的时候才知道是因为有那种巨便宜的捡漏机会,帝都到昆明不算燃油和机场建设才不到二百块,路程是草民近三倍的同时总价才是草民的不到一半,属实是酸了),而且还打算 5.7 回去。想想也确实,这两年各种事情比较多,好久没整大的了不如狠狠浪一波,干脆同步一下行程安排,4.30 一早前往昆明。
说来很巧,草民恰好有个两年半(警觉)没见的前同事 4.29 从深圳跑来成都玩,住在牛王庙那边,真是差一点就错过了。于是顺便过去那边约了个饭。
猛追湾之前没去过,去了发现算是个网红打卡点吧(成华区这种地方蛮多的),人挺多。恰了好久没吃的竹涟(前同事视角,图上是草民)
闲逛的时候顺便入坑星穹铁道。三月七好可爱,但是这游戏抽卡爆率也太离谱了,毛都不出一根。UID 见图,欢迎加好友捏
今天也是三月七~
云南那边几个城市都在说干旱预警,说实话草民没当回事(这个预警持续了一整个假期)。
呆了几天发现确实很干旱。。。自从来了成都之后很久没有那么干的感觉了。但空气质量也确实不错,比成都这种莫名其妙很多灰尘的情况好不少
4.30 中午到 5.2 中午两天时间(草民比另外两位大佬多一下午)。草民是 8:00 双流 - 长水 9:30,然后差不多一个小时地铁到市区。
下了地铁发现有共享小电动车,贼开心,骑了几分钟到了住的地方。本来草民打算习惯性住亚朵,但确实挺贵,在大佬的建议下选了民宿。昆明这个是酒店式公寓,挺不错的。
中午简简单单恰了个炒饭外卖,味道一般
前一天晚上肝游戏 + 早上赶飞机没怎么睡,于是果断摆了起来。下午睡醒四点了,感觉左右无事,就去按个人喜好看看大水塘。
哈啰青桔美团都有在昆明大量投放共享电动车。骑小电动车去到那边,一边走一边随机下雨,体验不是很好 hhh 其实可以直接坐地铁的,但是感觉电动车会更快乐一点。
大坝那边挺不错的(后悔忘带无人机去了(带了也没用因为没带卡(其实后来又想起来 MP3 里面有个小容量的卡凑合用一下也行
南边的湿地公园比较辣鸡,虽然搭了栈道但是严重缺乏维护,而且经常遇到铁丝网拦路,水质也一般,没啥可看的。个人建议是大坝那边看了就行,也可以顺便在大坝那边坐个船溜一圈,南边那些什么湿地公园就不用太花时间去了
晚上差不多十点左右接到了两位大佬,去觅食。主要是吃小吃去的,被奇怪的调料拌水果摧毁了味觉(实在是太怪了!!!),以及还是完全欣赏不来鲜花饼
椰子蛋 get,很好喝,但吃起来一般般
5.1 上午人果然不少。
这个公园其实就是每个城市里面都会有的那种有点儿水的公园(而且实话实说水质也跟大部分公园一样不怎么样),没什么特别的,不过里面奇奇怪怪的花很多。
某个大佬来昆明的几乎唯一目的。人实在是太太太太多了,裂开。
从这里进去会先发现外面有很多很多大棚。实际都逛完之后个人觉得比起花市里面体验要好得多,适合真的去买花 / 多肉 / 其他什么植物。这里多肉真的种类非常非常多,完全刷新了草民对这种植物浅陋的认知
花市本身更像个景点(而且没什么看点,里面甚至会有那种所有景区都有的辣鸡珠宝、香水小样、其他的工艺品什么的,总之不是很建议往那个里面挤
有些干花制品倒是很值得欣赏。花市门口就有中通营业点,快递纸箱子都是花市定制的,想买干花完全可以直接寄回家
偶遇了一种名字很怪的多肉(
种草了这种看起来像矿石一样的多肉,真的晶莹剔透。某宝搜了一下贼便宜,几块钱(当然外面大棚比某宝可能还便宜),花市直接买可能要十几二十块,还不好带回去
小红书上看到这个品牌还不错。本来打算是从翠湖公园出来直接吃,不过那边的店爆满,于是改为逛完花市之后去那边的一家同品牌店。这家店的外面写的很有意思
吃野生菌火锅会有 SOP
干等十五分钟会很饿,建议顺便点一些马上能吃的东西。
具体有哪几种野生菌忘了,有认识的大佬们可以留言嗷。
一锅炖。其实实话说,野生菌味道咋样也忘了,但汤是真的好喝。
出来往古镇慢慢溜达,路上看到了很好看的云。
至于这个古镇,个人评价为非常辣鸡,除了东西竟然意外的不太贵之外毫无看点,不建议去浪费时间。
看在夜景还凑合的份儿上不再多喷了。
古镇出来随便在旁边找了一家云南菜,味道不错,不过不重要,跳过吧。
5.2 摆了一上午,十二点半差不多才退房,以及发现非常成功的晒伤了,贼疼(
因为摆了太久只好在昆明站吃点德克士(居然没有 kfc 是没想到的,而且这个车站很小还不太标准,感觉很像那种县级市车站。可能昆明南站是比较大的标准车站?
在昆明站第一次见到了适用于火车的隔离门,打开的时候是直接往上抬起来,可以说是非常实用且优雅的设计了。
这一部分完了说一点对昆明简单的个人印象:
5.2 下午 16:20 到了大理站,然后打车到民宿大概用了半个多小时。
某个民宿,就在古城边上。交通很方便(指蹦蹦很多),天台不错,视野贼好。当然从房间的角度评价,就完全农村自建房水平。
甚至偶遇彩虹(而且是两道捏,不过外面那圈太浅,需要努力一点看
头一次逛比较晚的。感觉晚上意外的很有气氛,街上全是拍照的,还有随处可见的塔罗牌,甚至还有马车(某个大佬很想坐马车,这就是节目效果过于离谱的部分了
城门楼子无论是被拍还是上去拍夜景都贼好看。
逛的时候遇到射箭体验店,射了几根箭,个人评价为又菜又爱玩(flag 需要收了
在古城里面随机看评价选择的一家菌火锅。一样是完全不记得都有什么了,认识的大佬可以评论。
汤比上一家淡一点,但还是好吃的。有很好的芝麻酱。另外,有了上次干等十五分钟的经验,提前点了干巴菌炒饭,真的赞,尤其是泡汤吃。
带领两位大佬解锁了生吃蔬菜的世界(
第二天又摆到了中午(准确的说下午才出门,正是太阳最毒的那会儿,doubleplus sunburn(新话
骑行算是保留节目。洱海边的设施显然是精心维护着的,骑车体验很好,不过实在是太晒了,晒伤程度雪上加霜。
但是在交通工具的选择上可以说踩了大坑,结果是又浪费钱(估计仨人自行车电动车摆渡车倒腾下来,总共得花了两百多吧)又浪费时间。强烈不建议租那种需要回去还的自行车(草民遇到的是二十一辆 + 押金一百),草民为此浪费了差不多一个半小时骑车回去。建议是
路上经过的某个咖啡馆,地垫相当符合打工人的心境
吃了才村里面的某个白族菜(好像叫小溪私房菜,高德上的评价很到位),石榴花炒蛋还挺好吃。
前面两位蜜汁欢乐的大佬(
恰好出去玩的几天是农历月中,月相甚好。而且云南的云确实好看
从洱海出来居然堵在了路上(还是坐的蹦蹦),见鬼,这帮人都不用上班的嘛
又逛了个比较晚的。买了传统艺能冰箱贴。晚上恰了一个老白族石板烧,个人评价一般般,不过他们家炒饭很好吃
也是运气好,在大理的最后半天刚好赶上传统民族节日。虽然。。。卧槽人太尼玛多了,比斗南花市都多。。。真真的是人挤人,什么赛马场之类的地方就直接限流,而且天还贼热
「苍山不墨千秋画,洱海无弦万古琴」(有点反光看不清
起晚了只赶上了开幕式的最后几分钟(不过反正早点也根本挤不进去,连能让无人机起飞的地方都没有,结果都是一样的啥也看不见
整个活动其实就是一个规模巨大的集市,比较有意思的是有一些中草药专区、长街宴、黄焖鸡专区啥的。中草药是不懂了(试图对着仙三找不过只看到了重楼和景天),长街宴要预约、是露天的、要顶着个巨大的太阳、而且还是跟陌生人拼桌,于是逛了一阵儿直奔黄焖鸡专区。
这边的黄焖鸡其实个人觉得更像去掉辣椒的辣子鸡,很小块、很油、有点干、有点辣,味道只能说还凑合。菜单是固定的几样
总之这个集市,个人评价是完全没必要去,非要去的话。。。还是别去了,真的。另外其实在三月街就见到风花雪月的摊儿了,不过当时一看是啤酒就没当回事。
因为就在三月街边儿上(其实主要是可以骑马过去 & 某个大佬非常想骑马)所以顺便去看了看。印象就仨字:好小啊
买的是 80 的带什么冰雪大世界的门票,被坑了,建议 40 的就行(谁看冰雪大世界啊(主要是时间也不够了
反正去看看也不是不行吧,本着一个来都来了的心态。比较意外的是角落上那个西夏王宫那里比较高,恰好可以看到洱海
还有一个比较坑的是从冰雪大世界那个口出来相当不好叫车。。。
从影视城出来都 16 点了,这个点儿才滚回民宿拿了所有的行李(此处对民宿老板表示深深的感谢
以及最后依然是个人印象:
丽江留的时间比较多,一晚上加两个整天。
下火车之前抢了玉龙雪山大索道 140 的票(其实过了假期一点都不难抢,当然也不是说想买就买那种了,还是要在前一天晚上八点左右尽量定下来的
这个客栈过于优秀了,老板娘更是太优秀了,下次还来照顾老板娘生意(但是下次会是啥时候呢
定了楼顶的两个房间。甚至有浴缸,为了保证卫生会有一个一次性的浴缸套子(就是一个巨大的塑料袋)。个人评价是泡一泡很解乏很爽
老板娘是个东北大妞,非常热情,拉着说了好长时间的注意事项。第二天要去玉龙雪山嘛,按照老板娘建议
如需老板娘联系方式,请通过三次元找草民
出来已经比较晚了,按老板娘推荐吃了渣渣米线,没想到的是这边的豪华米线套餐配料是真的多。味道很不错(甚至加了一份米线
回来买巧克力之类的时候看见桃花味的风花雪月,不知道为什么就突然想带一罐尝尝(可能因为草民真的很喜欢桃花),然后发现真香
索道是 12:00 - 12:30 的,考虑堵车之类叫了十点的出租过去。回过头来看,这个车就叫的又比较失败
索道票是包含了景区内的摆渡车的钱的,但是进入景区还需要每人一百块的门票,门口直接买就行,不需要预约之类的操作。
有 KFC 啥的,所以也不用带太多吃的上来,当然人很多。旁边有邮局,如果有那种收集邮戳的喜好的话不要错过。
还有个意义不明但有点好看的柱子
就是俗称的大索道(140 块那个)。索道起点是海拔 3356,上到 4560 的地方,然后要走几百米的楼梯到 4680
上面风贼大(前一天索道直接因为风太大停了),草民去的时候还下大雪(准确一点说,不是片状的雪,而是直径一两毫米甚至更大的小冰晶颗粒,还挺硬,风一吹砸在防寒服上啪啦啪啦响。。。但确实是白色,看起来很像那种塑料泡沫小球,暂且认为是雪吧),真的巨冷(居然真的有小姐姐光腿上去的,草民穿两条裤子都冷),所以一定要做好防寒
防寒上面说了非常重要,氧气倒其实确实无所谓(再次感谢老板娘帮草民省钱)。高反的体验个人是
结合个人感受,氧气这块儿,除了上面老板娘说的采购方式之外,数量上个人建议
上面建议是不要待超过一个小时,草民个人的体验是又冷又高反谁 tm 会想在上面呆超过一个小时,要不是人太多估计半个多小时就能转一圈下来了。下来之后草民吞了一粒布洛芬,然后睡了一觉(到第二天上午那种)身体就完全恢复了,不是很确定是哪个发挥了效果。
确实好看,最牛逼的是天气比较神奇,只有雪山那一片乌云密布(然后随机下雨),于是效果就是面对雪山 / 背对雪山几乎完全不一样,双倍快乐
据说建议早上去,草民是下午四点左右看的,感觉也很棒(此处上下照片基本在同一个地方拍的)。水很清,尤其上游清澈见底。比较怪的是几个池子怎么看怎么不像水池,水底光秃秃的,水生植物很少(但是有鱼,更怪了),反而会有些树干莫名其妙插在水里
但是因为持续高反很难顶。。。所以其实上面会说不如先去蓝月谷,最后去冰川公园,这样可以把高反导致的头疼啥的留给晚上回家之后的时间(睡一觉就好了反正
以及这里拍结婚照的人巨多,逛那么一两个小时遇上了起码十对
晚上闲逛,月色甚好。打卡了大水车,以及买了一大堆纪念品,有个香包不错
中间酒吧街的灯笼着实好看(风花雪月为了推广这个桃花味新品,直接每个酒吧定制一款带酒吧 logo 的粉红色灯笼,这很品牌广告
吃了最后一顿躺板板大餐(这么多顿吃下去也没真躺板板,小人都没见一个),这顿羊肚菌安排上,预算直接拉满。也点了炒饭,但是上的太慢结果没吃多少。
迎宾的小姐姐也过于好看了(没有图你们想象一下吧
因为大家都在高反 + 连轴转好几天很累,于是摆到了下午。
基本没干啥,去古城里面几个角落走了走
偶然走到了一个天上挂满伞的地方,有点惊艳(不要细看图案,有点出戏
顺便去外面骑了一会儿共享单车,稍微观察了下城市界面(但看到的也很少),感觉跟大理基本差不多
七号早上回家。丽江的机场确实很小 hhh
最后依然是个人印象:俩字,值得
回家之后的一个星期基本上都在晒伤后遗症,疯狂脱皮。。。胳膊脖子脑门都在脱,好在周六终于差不多掉完了。
疫情之后的第一个节假日,出门玩的人确实很多(尤其是草民的朋友圈,感觉真的好多好多人在云南),但与此同时疫情第二波也来了,草民回到公司发现周围同事阳了不少,十几个人的小组四分之一中招,不过大多数是第二次阳了,基本都是在家歇一天就完事。有一说一草民还挺希望赶紧阳了的,这样说不定可以再顶半年(
之前似乎是有提过,草民其实觉得最近跟之前的朋友之间的联系是在逐渐减弱的,不过这也是没有办法的事情。所以有机会的话,还是多跟小伙伴们一起玩玩捏。
还有一个悲伤的事情是这次假期被至少四个人说胖了,看来真的得注意一下了(
]]>这次涉及到的内容就会比较零散了,会分别对不同的几个点进行简单介绍。
这一年半发生的事情比较多,期间整套设备从帝都搬到成都,在成都从租的房子搬到买的房子,宽带运营商、接入设备都有更换,也添置了一些设备,使得网络结构等都发生了不小的变化。当然之前也有部分提到过。
Project Home 2 最后有提到后面会补电视柜那里的细节。其实 Project Home 3 结尾有简单介绍,因为确实感觉很不错所以再晒一下。
具体的网络结构、设备等可以参考上面两个链接中的内容。
之前 BROUNION R86S Experience 里面有提到要再尝试几张卡,这里也简单提一下。
买了 MT7922,但是只能说这钱浪费了。
也叫 AMD RZ616,比 RZ608 多了 160MHz
实际买到的卡在 OpenWrt 里面就显示成 Generic MAC80211,并不像 RZ608 那样会显示成 AMD RZ616,蓝牙驱动装上之后 Windows 里面显示的蓝牙控制器名字也是 MediaTek 啥的,不确定它跟 RZ616 是不是完全一样的产品。
这张卡在 linux-firmware 里面是跟 mt7921 分开的,所以硬件上应该也不完全一样
买它其实主要是期望它可能会在硬件上解决一些 MT7921 / MT7921K 不稳定的问题啥的,实际用下来,最严重的问题是 MT7922 对 PCIE Passthrough 非常不友好,表现为虚拟机重启的话,它这个 PCIE 设备就直接没了,然后必须重启物理机才能使用。像草民这种经常升级 OpenWrt 的场景,升级完虚拟机自动重启,然后 Hyper-V 找不到网卡直接拒绝启动虚拟机,宿主机直接断网得手动重启了,这一个问题就基本排除了拿它日常使用的可行性。
这张卡在它短暂的使用过程中的其他表现跟 MT7921K 基本上没区别,Ping 同样不稳定,吞吐量也基本上是一样的。至于 Timeout 的问题,在上面那个更严重的问题面前没有办法让它运行足够长的时间来确认。它比起 MT7921K 唯一多出来的 160MHz 之前也提到对环境要求严格,基本没有太大意义。
这张卡比烂大街的 MT7921K 还要贵上个几十块钱,结论是完全不值得考虑。
去年大概年底 OpenWrt 官方支持了 ath11k,年前试了一下,很惊喜的发现 QCA6391 能用了!!!使用的方式依然是跟之前一样通过 Hyper-V 做 PCIE Passthrough,但这次非常顺利,没有遇到任何问题,着实令人十分意外。
手头这张卡有点奇怪的是无论用哪个信道,发射功率只能设置到 21 dBm,不过它没有 MT7921 那个奇怪的 36 - 48 也要 DFS 的问题,即使设置了需要 DFS 的 48 - 64 信道也可以正常花一分钟时间完成 DFS,当然感觉没啥必要,所以还是按之前的习惯设置到 149 - 161 信道。
试用了几天,目前感觉 Ping 延迟比之前明显要好,但吞吐量有所降低。暂时没有遇到 MT7921 时有发生的整个无线失去响应的现象,也不需要那个延迟启动 WiFi 的 hack,所以说尽量不要碰联发科,会变得不幸。
对比之前 MT7921 的监控(10.32.15.186),可以看到 MT7921 即使是在没有出现原因不明的离谱延迟时,仍然有非常严重的毛刺,但 QCA6391 基本保持平稳,维持在 5ms 上下。
说到离谱延迟,在 QCA6391 上也会有一样的现象,个人目前倾向于认为是 M1 MacBook Pro 的 Broadcom WiFi 有什么节能模式之类的。
因为 QCA6391 测试结果不错,又买了高通家支持 WiFi6E 和 160MHz 的 WCN685x,但大概要下个月才能送过来了,到时候会再做测试。另外补充一点:Qualcomm 的这一代卡跟 MediaTek、Intel 一样都自带了蓝牙,但在有些卡上蓝牙似乎不走 USB,而是走 UART 的(比如草民这张卡就是),这种驱动起来可能会十分困难,甚至可能就没戏,如果对蓝牙有强烈需求的话需要仔细询问、考虑清楚。
之前 Manjaro 是装在 NVMe 固态上的,后来突然想干脆把整个系统盘也挪到 ZFS 上吧。这么干主要是出于几个考虑:
当然实际弄完之后发现慢得多,有一点点后悔。回头加点钱整一下 special metadata device 的活。
现在肯定都用 UEFI 启动了,所以至少还需要一个 FAT32 分区用来做 EFI System Partition 并且还要把 GRUB2 装进去,这里我们简单起见就是 /boot,以及为了省事儿,把内核和 initrd 也直接放到 /boot 里面,整个 /boot 是不会挪到 ZFS 上的。这部分启动完之后就用不到了,平时也几乎不会改到,不用 ZFS 也无所谓。
yichya@yichya-nas /boot> ls -al
total 231313
drwxr-xr-x 5 root root 4096 Jan 1 1970 ./
drwxr-xr-x 21 root root 29 Nov 2 17:14 ../
drwxr-xr-x 3 root root 512 Jan 1 1970 efi/
drwxr-xr-x 6 root root 4096 Jan 24 23:59 grub/
-rwxr-xr-x 1 root root 64812588 Jan 24 23:58 initramfs-5.15-x86_64-fallback.img*
-rwxr-xr-x 1 root root 39041844 Jan 24 23:58 initramfs-5.15-x86_64.img*
-rwxr-xr-x 1 root root 67339813 Jan 24 23:58 initramfs-6.1-x86_64-fallback.img*
-rwxr-xr-x 1 root root 37888134 Jan 24 23:58 initramfs-6.1-x86_64.img*
-rwxr-xr-x 1 root root 5678080 Nov 9 03:02 intel-ucode.img*
-rwxr-xr-x 1 root root 22 Jan 19 04:36 linux515-x86_64.kver*
-rwxr-xr-x 1 root root 20 Jan 19 04:36 linux61-x86_64.kver*
drwxr-xr-x 2 root root 4096 Jan 24 23:56 memtest86+/
-rwxr-xr-x 1 root root 10800032 Jan 24 23:57 vmlinuz-5.15-x86_64*
-rwxr-xr-x 1 root root 11258560 Jan 24 23:57 vmlinuz-6.1-x86_64*
剩下的都要从原来的文件系统里面复制出来。跨文件系统挪数据也没什么好办法,所以就建一个 dataset(类似于 btrfs 的 subvolume),然后在一个稳定的环境下(肯定不能挪正在运行的操作系统吧,随便找个 Live 系统,带 ZFS 的就行了)直接 rsync -av
,当然对于 podman 之类会利用文件系统特性的应用,需要使用它们的 export 和 import,不能直接 rsync
比如草民的 pool 叫 opt
(为了自动挂在 /opt
上,省事儿),数据挪完之后新的 dataset 叫 opt/Root
,顺便可以把 /home
之类的也建好单独的 dataset,这个看个人需求,之后搞也行。
yichya@yichya-nas ~> zfs list -d 1
NAME USED AVAIL REFER MOUNTPOINT
opt 5.42T 5.36T 3.07G /opt
opt/Containers 2.46G 9.68G 7.79M /var/lib/containers
opt/Critical 58.3G 967G 58.2G /mnt/Critical
opt/Home 69.6G 58.4G 63.9G /home
opt/Private 559G 520G 505G /mnt/Private
opt/Public 4.69T 5.36T 4.54T /mnt/Public
opt/Root 54.2G 9.81G 32.0G /new_root
挪文件系统很简单,从挪过去的文件系统上启动才是个麻烦事。
ZFS on Root 依赖的一个很关键的部分就是它实际上是把 ZFS 需要的内核模块都打在了 initrd 里面,以此绕过 CDDL 那个不能跟内核链接到一起的要求。虽然这样做是否违反 CDDL 还有待商榷,不过目前大多数发行版都在干这种事儿,其中甚至包括 TrueNAS Scale 这种会卖商业授权的发行版。
Manjaro 下面需要先更新 /etc/mkinitcpio.conf
加上 zfs hook,注意放在 block 后面和 filesystems 前面
HOOKS="base udev autodetect modconf block keyboard keymap zfs filesystems"
然后 sudo mkinitcpio -P
更新一下 initrd 就行了。因为 GRUB 跟内核没有放在 ZFS 上,所以不需要改变 GRUB 的模块设置。
做完上一步之后,先重启进 emergency 模式,方法是临时改 GRUB 启动参数。
root=<any>
删掉shell 出来之后手动 import zpool 并把 rootfs 挂到 /new_root
,如果打算给 zpool 改名也可以在这个时候操作(比如草民其实是在这里把 zpool 的名字从 nas 改成的 opt)
zfs import nas opt
zfs set canmount=noauto opt/Root
zfs set mountpoint=/new_root opt/Root
挂好了之后按下 Ctrl + D 退出 shell,然后系统应该会正常在新的 dataset 上启动。
启动完成后强制更新一下 zfs.cache,然后再更新一下 initrd
sudo zpool set cachefile=/etc/zfs/zpool.cache opt
sudo mkinitcpio -P
然后再按下面的步骤更新一下 GRUB 配置
GRUB 识别 rootfs 的脚本在 zpool 由好几个设备组成的情况下有 bug,因此要改一下 /etc/grub.d/10_linux
,才能正确拼上 root 参数。
--- a/etc/grub.d/10_linux
+++ b/etc/grub.d/10_linux
@@ -72,261 +76,17 @@
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
fi;;
xzfs)
- rpool=`${grub_probe} --device ${GRUB_DEVICE} --target=fs_label 2>/dev/null || true`
+ for rpooldev in ${GRUB_DEVICE}; do
+ rpool=`zdb -l ${rpooldev} | grep " name:" | cut -d\' -f2`
+ if [ ! -z ${rpool} ] ; then
+ break
+ fi
+ done
bootfs="`make_system_path_relative_to_its_root / | sed -e "s,@$,,"`"
LINUX_ROOT_DEVICE="ZFS=${rpool}${bootfs%/}"
;;
esac
改完之后 sudo update-grub
更新配置,并检查一下 /boot/grub/grub.cfg
里内核命令行上的对应参数 root=ZFS=opt/Root
,确认都正确之后重启,然后就可以把旧的系统盘清理掉了。
最后因为这个 grub.d 脚本会随 GRUB 更新,因此每次 pacman -Syyuu
之后也都需要检查一下 /boot/grub/grub.cfg
看看 zpool 是否还在,如果不在了的话就还得修改这个脚本文件并且重新更新 GRUB 的配置。
日常使用过程中还对 ZFS 做了一些小调整,其中包括一次误操作导致不得不整个重建 zpool,实惨
ZFS 除了 L2ARC 这种外部读缓存之外,还有 SLOG 这种延缓写入的能力。之前没开主要是因为没有 UPS,如果断电的话这部分写入可能会有问题。后来买了 UPS 就开了,但实际用下来发现没球用,尤其对草民这种除了编译 OpenWrt 和拖北邮人之外基本没什么持续写入的场景,真的是完全没用。目前似乎唯一真的用得上的情况是虚拟机磁盘的写入(装了 VirtualBox 之后发现的,KVM 不晓得)会真的用得上 SLOG
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
opt 10.9T 4.91T 5.99T - - 3% 45% 1.00x ONLINE -
mirror-0 10.9T 4.91T 5.99T - - 3% 45.0% - ONLINE
sda - - - - - - - - ONLINE
sdb - - - - - - - - ONLINE
logs - - - - - - - - -
nvme0n1p3 8G 1.47M 8.00G - - 0% 0.01% - ONLINE
cache - - - - - - - - -
nvme0n1p4 456G 406G 50.2G - - 0% 89.0% - ONLINE
分了 8G+,日常占用几 MB,还要为此冒丢掉这几 MB 数据的风险(虽然有 UPS 了这个风险很小,而且就算丢了也没啥影响),感觉其实没啥意义。
OpenZFS 2.1.4 开始直接提供 zfs-scrub-weekly@.timer
等几个 systemd 定时器,可以简单通过 systemctl enable zfs-scrub-weekly@opt.timer
这样的方式增加一个每周 scrub 一次的定时任务。
> sudo systemctl status zfs-scrub-weekly@opt.timer
● zfs-scrub-weekly@opt.timer - Weekly zpool scrub timer for opt
Loaded: loaded (/usr/lib/systemd/system/zfs-scrub-weekly@.timer; enabled; preset: disabled)
Active: active (waiting) since Mon 2022-08-29 19:12:46 CST; 3 days ago
Until: Mon 2022-08-29 19:12:46 CST; 3 days ago
Trigger: Mon 2022-09-05 00:45:42 CST; 2 days left
Triggers: ● zfs-scrub@opt.service
Docs: man:zpool-scrub(8)
Notice: journal has been rotated since unit was started, output may be incomplete.
定期 scrub 还是很关键的,比如加拿大白嫖王就翻了个大车(
ZFS 支持把一部分数据专门放在额外的速度更快的设备上加速访问。
Special Allocation Class
The allocations in the special class are dedicated to specific block types. By default this includes all metadata, the indirect blocks of user data, and any deduplication tables. The class can also be provisioned to accept small file blocks.
草民简单尝试了一下,把 Metadata 和小文件放在 SSD 上加速存取确实有用,而且确实是十分明显能感受到。但是这个草民还没折腾清楚,中途没有留意 Special 设备的一些重点注意事项,结果导致 Special 设备没有冗余而且摘不下来了,最终是直接重建了整个 zpool,花了很长时间。这部分等过段时间加点钱准备两块 SSD 再整吧,细节也就留作下次介绍,这里只提几点
ashift=12
,尤其是在机械硬盘上初始化 zpool 的时候,不然加 Special 能加,删就删不掉了未雨绸缪的必备品(当然对草民来说多少有点亡羊补牢的感觉)
某天中午无通知停电一个小时,完后
zfs scrub
跑了一天。
买的是狗东上比较热门的 SANTAK TG-BOX 850,其实主要是看中它插孔比较多,不用再在上面接一个插线板,显得稍微整齐一点
可以用 USB 跟它通信,然后装个软件就可以看到状态了,草民选的是 apcupsd
这台机器相对低端,apcupsd 能看到的数据很少,基本上只有容量、负载、剩余时间是比较有用的,电压和功率之类的都没有。平时负载 10% 能撑 40 分钟,编译 OpenWrt 之类拉高负载之后会到 20% - 25% 左右,完全够用。
一月初又遇上了一天内两次停电,好在完全不慌:
yichya@yichya-nas ~> sudo journalctl -u apcupsd -S "2023-01-11 11:00:00"
Jan 11 11:29:43 yichya-nas apcupsd[3026]: Power failure.
Jan 11 11:29:49 yichya-nas apcupsd[3026]: Running on UPS batteries.
Jan 11 11:29:50 yichya-nas apcupsd[1872581]: mail: Cannot start /usr/sbin/sendmail: executable not found (adjust *mta* variable)
Jan 11 11:29:50 yichya-nas apcupsd[1872581]: /root/dead.letter 41/999
Jan 11 11:29:50 yichya-nas apcupsd[1872581]: mail: ... message not sent
Jan 11 12:05:53 yichya-nas apcupsd[3026]: Battery power exhausted.
Jan 11 12:05:53 yichya-nas apcupsd[3026]: Initiating system shutdown!
Jan 11 12:05:53 yichya-nas apcupsd[3026]: User logins prohibited
Jan 11 12:05:53 yichya-nas systemd[1]: Stopping APC UPS Power Control Daemon for Linux...
Jan 11 12:05:53 yichya-nas apcupsd[3026]: apcupsd exiting, signal 15
Jan 11 12:05:53 yichya-nas apcupsd[3026]: apcupsd shutdown succeeded
Jan 11 12:05:54 yichya-nas systemd[1]: apcupsd.service: Deactivated successfully.
Jan 11 12:05:54 yichya-nas systemd[1]: Stopped APC UPS Power Control Daemon for Linux.
Jan 11 12:05:54 yichya-nas systemd[1]: apcupsd.service: Consumed 35.515s CPU time.
-- Boot be39038bd9534c1fb8e6d45974be00a4 --
Jan 11 14:05:17 yichya-nas systemd[1]: Starting APC UPS Power Control Daemon for Linux...
Jan 11 14:05:17 yichya-nas systemd[1]: Started APC UPS Power Control Daemon for Linux.
Jan 11 14:05:17 yichya-nas apcupsd[2736]: apcupsd 3.14.14 (31 May 2016) unknown startup succeeded
Jan 11 14:05:17 yichya-nas apcupsd[2736]: NIS server startup succeeded
Jan 11 17:16:27 yichya-nas apcupsd[2736]: Power failure.
Jan 11 17:16:33 yichya-nas apcupsd[2736]: Running on UPS batteries.
Jan 11 17:16:33 yichya-nas apcupsd[817393]: mail: Cannot start /usr/sbin/sendmail: executable not found (adjust *mta* variable)
Jan 11 17:16:33 yichya-nas apcupsd[817393]: /root/dead.letter 41/999
Jan 11 17:16:33 yichya-nas apcupsd[817393]: mail: ... message not sent
Jan 11 17:30:32 yichya-nas apcupsd[2736]: Battery power exhausted.
Jan 11 17:30:32 yichya-nas apcupsd[2736]: Initiating system shutdown!
Jan 11 17:30:32 yichya-nas apcupsd[2736]: User logins prohibited
Jan 11 17:30:33 yichya-nas apcupsd[2736]: apcupsd exiting, signal 15
Jan 11 17:30:33 yichya-nas apcupsd[2736]: apcupsd shutdown succeeded
Jan 11 17:30:33 yichya-nas systemd[1]: Stopping APC UPS Power Control Daemon for Linux...
Jan 11 17:30:34 yichya-nas systemd[1]: apcupsd.service: Deactivated successfully.
Jan 11 17:30:34 yichya-nas systemd[1]: Stopped APC UPS Power Control Daemon for Linux.
Jan 11 17:30:34 yichya-nas systemd[1]: apcupsd.service: Consumed 1.328s CPU time.
-- Boot 05edf4c49a5e43ccaccc1a1dd23c6ff7 --
Jan 11 17:52:05 yichya-nas systemd[1]: Starting APC UPS Power Control Daemon for Linux...
Jan 11 17:52:05 yichya-nas systemd[1]: Started APC UPS Power Control Daemon for Linux.
Jan 11 17:52:05 yichya-nas apcupsd[3037]: apcupsd 3.14.14 (31 May 2016) unknown startup succeeded
Jan 11 17:52:05 yichya-nas apcupsd[3037]: NIS server startup succeeded
同样接在 UPS 上的还有 R86s,装一个 Windows 版的 apcupsd 然后简单配置一下通过局域网连接 UPS 就行了。当然注意把网络设备(草民这里是 hap ac2)也接到 UPS 上,不然肯定是没法同步状态的。
一般来说宽带接入设备就不需要了,毕竟停电这种事儿,小区里面的运营商设备说不定凉的更早(上面那两次,看日志里面在 UPS 状态切换之前一两分钟很多 RSS bot 之类的请求都超时了,大概率是这样的)
这段时间把 RSS Bot 从 flowerss 换成了 https://github.com/Rongronggg9/RSS-to-Telegram-Bot,感觉更好用一些。
除此之外还有下面几个新服务
这个应该很多人用过了,拿来
建议在容器里面跑 Jenkins 本体,然后用 ssh 连到宿主机上跑 worker,方便升级什么的。
槽点主要在于内存占用过于离谱了。。。本体扔着不管一段时间能直接干到 13G+,worker 也能干出 1G+
咱也不知道是 JRE 的问题还是啥,不设置 -Xmx 就使劲儿往上吃,无论是本体还是 worker 都把内存当饭吃
很方便的监控,主要用来 fping 以及盯 ups 的状态。前面也出现过很多次了。
目前个人用 v1.35.1,因为 v1.36 开始加入了一个非常显眼而且关不掉的广告。。。为了方便控制版本,比较建议整个跑在容器里面,当然需要 --privileged
,还需要把宿主机上的一些目录挂进容器。
sudo podman run -d --name=netdata \
-p 19999:19999 \
-v /opt/persistent/netdata/etc:/etc/netdata \
-v /opt/persistent/netdata/lib:/var/lib/netdata \
-v /opt/persistent/netdata/cache:/var/cache/netdata \
-v /etc/passwd:/host/etc/passwd:ro \
-v /etc/group:/host/etc/group:ro \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /etc/os-release:/host/etc/os-release:ro \
--restart always \
--privileged --log-driver journald \
docker.io/netdata/netdata:v1.35.1
而且即使这样做了,有些比如磁盘剩余空间之类的也是看不到的,这个就是容器文件系统隔离的限制了。
netdata 比起自己搭一套 prometheus + grafana + node-exporter 之类的要方便很多,而且自带一个云,还不要钱,当然它自然也是有广告、不那么灵活、不好配置报警啥的,看个人需求,homelab 的话其实 netdata 完全足够了。
因为 KVM 的网络和显卡都不是很好使,还动不动就装个 dnsmasq 接管服务器的所有域名解析请求,很是让人心烦。干脆装了个 VirtualBox,然后发现用起来还不错,而且 Windows 7 可以开 Aero(后来某次版本更新之后又不能开了,迷)
目前遇到的最大的问题是 X Forwarding 太卡了。。。
Real NAS Project 目前感觉基本上趋于稳定了,草民目前的需求暂时不觉得会再有什么很大的调整。
下一篇应该是个人工作区(或者包括整个主卧)的介绍,不过目前还没有完全折腾完,估计起码三月份见了 hhh
]]>Yeelight 的灯可以用四种方式控制:
直接通断电自然很容易理解。好处是简单稳定,坏处自然是断电之后没办法遥控开灯了,所以才会有其他的几种控制方式。
Project Home 2 有介绍过,如果想要达到比较好的效果的话需要:
然而,即使这些都做了,因为 Yeelight 的吸顶灯只能通过 WiFi 控制,如果遇上家里路由器挂了还是开不了灯。
这个开关其实完全是一个非常非常普通的机械开关,然后在下半部分加一个弹簧。按下开关下半部分之后松手,弹簧会直接把下半部分弹起来恢复到上半部分按下的状态,实际把它变成一个按钮。
这个功能可以通过里面的一个小螺丝切换。
至于它控制智能灯的原理其实非常简单:灯里面用一个小电容之类,维持主控工作一小段时间,在这段时间内一次通断电视为对灯的状态切换。因为它实际的工作逻辑都在灯里面,所以也就只有支持这个功能的灯才能搭配这种开关使用。
一般按开关的时间也就几十到几百毫秒,Yeelight 的主控个人实测大约可以维持 3 秒左右。超过这个时间主控就寄了,再恢复通电的话灯会无条件亮起来。
这个功能默认不开启,需要在米家里面点一下。米家 UI 里面的这个梗过不去了(
以及,狗东自营那种最便宜的凌动™️开关(就是上面图上那种)大概到手三十来块钱一个,但说实话这个开关很拉,主要体现为机械结构碰撞的声音非常大,草民不太推荐。狗东还有些什么超薄款的,草民没有买,需要的话自行尝试。
这个就没啥好说的了,遥控器用的是蓝牙 4.2 不过是私有协议。
好处是十分稳定,不会有那种家里断网了就没法关灯的问题;坏处主要是没有任何定制空间,比如不能自定义按钮功能,也不能联动其他的传感器之类。当然,其实遥控器最大的麻烦还是容易随手往哪儿一扔就找不到了。
Yeelight 的这个智能调光开关分两种形态,一种是 86 盒那样直接装到墙上,以及另一种贴装的,功能基本一样。
就跟产品宣传图说的一样:这玩意儿看起来像个智能开关,但实际上是个遥控器,跟米家那种智能开关有本质区别:
当然 86 盒版下面有一个物理开关可以直接整个断电,偶尔需要重启 / 重置智能灯的时候用起来也挺方便。至于贴装版,就完全是一个换了换样子的遥控器,里面是装了一个跟遥控器里面一样的 CR2032 纽扣电池的。
既然是遥控器,遥控器的好处自然是都有,而且固定安装的话也不会有不知道扔到哪儿去了的问题,但是功能无法自定义的问题自然也保留了下来,比如草民的灯并没有调颜色的功能,这个开关的【长按】事件就等于无效了。
目前草民自己是把两个卧室的灯都换成了这种调光开关,客厅因为有遥控器所以是用凌动™️开关。这个调光开关的做工、手感之类都还可以,草民比较推荐。
之前一直是乱糟糟一大坨所以没晒图。趁周末认真收拾了下,目前看起来很清爽(因为大部分线都藏到下面去了
Real NAS Project 2 的坑还在慢慢填,春节一定补上(
]]>今年大事颇多,比 2020 年更深切体会到了什么叫【覆巢之下,焉有完卵】。
很多名声如雷贯耳的大佬离开了我们,比如长者。
网易新闻的年度总结很真实,真实到被全网下架,只能出去看了。Youtube
「人不是活一辈子,不是活几年、几月、几天,而是活几个瞬间」。致敬每一个扛住了生活的平凡人。
今年办了最重要的大事,基本上是按之前的预想完成了购房 + 户口迁移。除了随后的装修有些波折之外,总体还算比较顺利。
草民买在了高新区大源这边。选择这边的原因基本也是按之前的考虑:
虽然房子稍微老一点(十年多点),不过比起帝都那种比草民年纪都大的房子来说体验还是好非常多,而且这套房子以后是留给父母住的,加上预算有限,所以对房龄之类的要求没有那么高。
家具还没完全置办完成,回头会在 Project Home 里面单独做一次 Room Tour,现在只简单发一个工(游)作(戏)区 + 收藏区的图。
柜子送的灯很离谱,回头再换
今年经济形势显著变差,房地产市场更是不稳定,草民刚买完房就遇上年中的量价齐跌,到了年末政策又开始持续放松救市。说草民心情完全没有波动是不可能的,但认真考虑过,在这种不稳定的情况下试错的成本太高,与其搏一搏倒不如尽量在不确定性中多抓住一些确定的东西,苟过这一波之后再做更多考虑。而且就购房这一件事来讲,草民一个刚需,本身投入有限(而且还没有贷款,利率波动与我无关),实话说即使有些波动也没觉得太怎么样,没必要患得患失。
讲完房地产的事情,也从其他角度看看后续的情况。
今年各互联网公司的日子比去年显著的更难过了,砍 HC、冻结招聘、裁员等等都层出不穷。就目前这个情况来看,即使有各种政策试图提振经济,甚至到年底突然放松疫情管控,但就草民浅薄的认识来说也很难有什么实质性改变:
或许这就是经济危机了吧。还是上面那句话,在这种不稳定的情况下试错的成本太高,与其搏一搏倒不如尽量在不确定性中多抓住一些确定的东西,苟过这一波之后再做更多考虑。希望这一波快点过去。
父亲遭遇了交通事故,整了个股骨颈骨折,还是挺严重,打了四个钉子内固定。
大半年过去恢复的还行,目前自己出门买个菜啥的完全可以。遗留的问题是骨折的地方卡进去了一点,导致愈合有点错位,两腿差了大概一厘米的高度,对正常走路多少有点影响。
事故对方全责 + 因为在下班路上所以也判定为工伤。伤残鉴定流程全部走完,书面结果已出具,赔偿流程进行中。至于后续是否会出现股骨头坏死、需要做整个关节置换之类的事情,还需要以年为单位的长期观察,希望一切顺利。
这个事情对个人的教训大概是,意外和明天真的不知道哪个先来,真的还是有必要考虑买保险的。也作为明年的 Todo 之一吧。
今年像之前说的,在一家小一点的公司,回归到更纯粹的工程师角色。具体做的事情上,绝大部分时间都在跟 TiDB 斗智斗勇,其实算是圆了之前多用点 NewSQL 的心愿。工作节奏比起之前要缓和很多,终于不必再花巨量的精力来回做无用的沟通,能花更多精力在实际要解决的问题上。当然,面对的问题跟之前相比也更有挑战。
比如初始团队的技术选型。目前的业务实际上主库是 Mongo,初始团队比较熟这个,而且业务起步阶段 Schemaless 迭代比较快。但到了后面业务一复杂、人一多,问题就来了。暂且抛开 Schemaless 的弊端不谈,Mongo 这玩意儿遇到 join 就很难搞,有些其他的复杂查询,尤其是涉及到 OLAP 的场景也不太好支持。引入 TiDB 除了一些业务上对关系型数据库的需求之外,实际上更多的也是为了解决 OLAP 场景的问题(说到这个就很怪,公司还有一套 Doris / StarRocks 用来整这个,那个草民接触不多,听说又有些其他的坑)。但是这个过程就需要做 Mongo -> TiDB 的数据同步,这真的是个巨坑,基本上每一个步骤都会有意想不到的问题,延时、性能、一致性都充满挑战,比起同类型数据库的数据同步要困难太多太多了。好在对应团队比较有经验,今年做这一套数据同步方案的大佬深入交流了很多次,收获颇丰。
比如经济不好这种事情,草民这里也是难以避免的会受到影响,因此要想尽办法节约花在机器上的预算,但是 TiDB 尤其是 TiFlash 又贼耗资源,优化器又多少有点蠢,结果就是在钱没怎么充够的情况下不是很好用,稍不小心就会 IO 爆炸,只能当人形优化器。从用 TiKV 还是用 TiFlash,到执行时间限制,甚至到子查询要不要改写成 join 什么的都要人工指定,一条 SQL 起码三个 hint,还要花式拼分片键做分区裁剪。在这样一种情况下应对不算小的数据量(还要 join 来 join 去、各种花式排序什么的)着实有些棘手。
+----------------------------------------+---------+--------------+---------------+----------------------------------------------------+
| id | estRows | task | access object | operator info |
+----------------------------------------+---------+--------------+---------------+----------------------------------------------------+
| StreamAgg_14 | 1.00 | root | | funcs:count(1)->Column#7 |
| └─TableReader_48 | 9.00 | root | | data:ExchangeSender_47 |
| └─ExchangeSender_47 | 9.00 | cop[tiflash] | | ExchangeType: PassThrough |
| └─HashJoin_44 | 9.00 | cop[tiflash] | | inner join, equal:[eq(test.t1.id, test.t1.id)] |
| ├─ExchangeReceiver_19(Build) | 6.00 | cop[tiflash] | | |
| │ └─ExchangeSender_18 | 6.00 | cop[tiflash] | | ExchangeType: HashPartition, Hash Cols: test.t1.id |
| │ └─Selection_17 | 6.00 | cop[tiflash] | | not(isnull(test.t1.id)) |
| │ └─TableFullScan_16 | 6.00 | cop[tiflash] | table:a | keep order:false |
| └─ExchangeReceiver_23(Probe) | 6.00 | cop[tiflash] | | |
| └─ExchangeSender_22 | 6.00 | cop[tiflash] | | ExchangeType: HashPartition, Hash Cols: test.t1.id |
| └─Selection_21 | 6.00 | cop[tiflash] | | not(isnull(test.t1.id)) |
| └─TableFullScan_20 | 6.00 | cop[tiflash] | table:b | keep order:false |
+----------------------------------------+---------+--------------+---------------+----------------------------------------------------+
12 rows in set (0.00 sec)
看了一年这玩意儿。TiDB 的 EXPLAIN 比起 MySQL 的要详细许多,分析问题很有用,但是如果 Planner 能少整点问题出来就更好了
比如要协助不同业务做上面 Mongo -> TiDB 的迁移或者直接支持新业务在 TiDB 上的建设,过程中要深入理解整个公司不同团队的业务,以及基建还有很多缺乏,这一年又搞起了老本行之一的 Feature Flag,还有协助建设 GRPC 解决方案,等等。。。
总体感觉:
明年继续共同成长吧。
虽然身体健康情况总体向好,不过之前欠下的债还是要还。
连续三年,每年清明前后似乎都在补牙。这次更狠了,门牙脱矿太厉害,一把补了三个。。。好在瑞泰可以用医保个人账户支付,比起之前瑞尔还是要好些。
这次医生倒是说脱矿的原因主要是太经常用嘴呼吸,可乐虽然有影响但是比较有限。但还是尽量控制下少喝快乐水吧(难
十一月很怪,颞颌关节挂了几天。这个病可真是难瞧,华西口腔排号能排半年多,其他的很多医院压根没有关节科。回想起之前大半夜去北大口腔排队,关节科的号也是瞬间就没的那种。
好在这个病属于自限性,放在草民自己身上,理疗了几天也就恢复到了之前那种有移位但是不疼、不影响关节正常功能的状态。
然后就是新冠了。十二月上旬刚宣布放开,没过几天草民便全家中招,烧了好几天。仅就草民自己来说,真的想不起来上次发烧 39 度是啥时候了,但这次真的是极为痛苦。而且刚开始几天抗原检测试剂根本抢不到,请假都难,还是跟同事乞讨了几个度过难关。
前后过了一个星期,全家症状基本消失,目前只剩草民自己目前还在咳嗽,可能还要再过一段时间才能完全恢复吧。今天看到四川疾控的公众号文章,初步问卷调查感染率超过 60%,看来这一波大概快要过去了,希望下一波晚点来,来了也不要跟这次一样痛苦。
今年大部分的空闲时间基本上都用在收拾房子和转家居城了,再加上疫情影响,完全没有什么机会出门走一走。明年一定要补上。
遭遇了两次摇一摇。前面一次在公司 14 楼,当时整个楼都在上下晃。。。后一次封在家 5 楼,感觉比前面那次还猛,真的有点慌
2022.6.1 | 2022.9.5 |
今年成都的天气也着实有些反常,七八月份都没下多少雨导致严重缺电,甚至八月被迫节能(真·节能大厦
难得的比较开心的事情是见了几位大学室友,在当时那种不知道什么时候就会来一波封控的日子里实属难得。
头一次上到 IFS 顶上
因为上面提到的各种原因不能出去溜达,所以在家宅的事儿也多了起来(这跟在帝都的日子有啥区别啊
奔着七娘的颜值去的(有一说一真的好看),最后看完感觉也真的不错
这一幕深深的 emo 了
叔叔的年货(BV1q34y1271d)之一,每年最期待的节目。今年是散装忘川 + SV 苍穹(和苍穹 AI),都是老熟人了(
真心觉得今年的命题作文,从各方面讲,都比之前水平更高,尤其立意,三位一体,着实无敌。
可惜这个播放量就是上不去。今年奶一口星尘 Infinity,再过三周见分晓
从各方面来说,味儿都很正,尤其里面有太多老熟人了。
还没看完。年前事儿相对少一点,慢慢补。
年中迷上了这种特别的文体。
大部分人可能是从动物园接触到规则类怪谈的(草民也不例外),不过还是大洛山系列最让草民觉得印象深刻
https://www.bilibili.com/read/readlist/rl518702
虽然整个系列很长,但真的强烈推荐(会写就多写点嘛
电影里面有些设定很有意思(比如一本正经念文言的合成语音广播),但整体个人觉得不如小青(
中间依然银临献唱,加上那段舞蹈,真是美翻了。十月份杭州有银临的 live,因为疫情关系没去成,相当可惜。
懒得喷了,一图流。
今年还脑子一热买了《三体世界观》,啥破玩意儿,只想怒吼一声 RNM 退钱
现在这年头用爱发电着实不容易,支持优秀创作者也是一种投票的方式(不说别的,总比 jntm 好吧(虽然偶尔还是会踩雷
今年收的新专辑:
另外买了《成何体统》《有药》和《人匠》实体书,有一说一皇叔什么时候把人匠的坑填完啊(敲碗
还有今年最喜欢的周边之一,五维的几个小石头(2021 年就说好的赤羽大手办到现在还没个影子
最后春意红包终于拼了!
痒痒鼠今天刚好签到 2250 天了!有一说一,每天求到的这个签还真有那么一点点准的(
说到网易就不得不提辣鸡玻璃渣,再次怒吼 RNM 退钱(这个图梗太多了
今年买了 Switch,比去年稍微多玩了点游戏
另外专门提几个比较有意思的。
一个很 Meta 的小品游戏 Terrorbane,真·在 Bug 里找游戏
然后是期待已久的 P5R,虽然感觉第二学期最后那点剧情确实是有些强行造神了,导致之后节奏有些崩,但其他的部分真的很棒很棒
这个梗后面在剧情里起码又出现了两次,每次看到都忍不住笑
目前第三学期刚开始,后面应该还会开二周目认真搞 Cooperation
手办今年也到了不少,0617 / 彼岸花 / 说来就来的 42 姐
还有之前预定的仙四两把剑 1:1 模型也到货了。望舒是真的质感超好,羲和就稍微差点意思。现在十分头疼该放哪
明年大概会找个时间回庄再拿点宅物过来(醒醒,还有七八个大手办在路上,再拿怕是真没地方放了
今年填了 Gadgets (2022) ,虽然晚了一些。其他的还有
其他预计下次 Gadgets 会介绍的东西,目前手里攒的小玩意儿不多,到时候看情况:
这东西 WiFi 稳定性成谜,其他的倒是还行,虽然是 ARM64 设备,但是正常的 Windows 体验基本没啥问题。在考虑拿来干点重活试试
以及其他计划采购的:
今年的空闲时间大头基本都花在房子上了,所以 Projects 今年开的坑并不多。
luci-app-xray 今年持续迭代,支持了 OpenWrt 新的防火墙实现 fw4 和脚本引擎 ucode(终于不用写 lua 了)。Star 数 150+ -> 280+
其他项目加起来凑够了 400+ Star,还凑合。
顺便,今年开始用 GitHub Projects 记录自己的一些 idea 和进行中的 Projects,这样能够很好保留那些突然跳出来的灵感。
这里面要填的坑着实还是挺多的
新家的网络在 Project Home 2 跟智能家居一起做了介绍,目前的体验还是很不错的。
其实有写,但是一方面迭代不是很多(当然也不算少了,UPS、监控、Rootfs on ZFS 等等),另一方面今年杂事比较多,多少占据了些空闲时间。春节补上。
方便查看和裁剪 GeoIP / GeoSite 的两个小工具。GeoData Reader 是用 egui.rs 做的,顺便学了一丢丢 Rust,不过其实不值一提
比较有意思的是它可以编译到 wasm,这样可以直接把它嵌在 LuCI 或者类似的地方,说不定这会是未来 Web 前端的一种新玩法(
其实是去年 Odroid Go MP3 Player 的延续。本来是想在设备上把所有的活都干完,但发现 ESP32 内存着实有点小,不得不整个服务端搭配工作。结果这玩意儿现在最大的作用是爬喜马拉雅的 RSS 并转发到 Telegram(
既然用起来 GitHub Projects 了,照着填坑就是。
去年立的很多 flag 比如学车、耍弓箭、出去走走等,都翻车了。2023 年一定要补上。
那么新的一年许个愿:
最后送上一首今年真的很喜欢的《流年如歌》,希望大家新的一年越来越好。
]]>想来大家租房的时候都会因为扯来扯去的网线头疼。既然有了新家,那肯定是要仔细考虑一下如何建设家庭网络。
初步看了一下原来每个房间有哪些线连到弱电箱里面:
有线电视同轴线和电话线现在显然都没有任何用处了。之前的光纤是从沙发后面出来的,也十分不合理。改线方案初步考虑:
于是重新穿了到电视柜下面的光纤,并且其他室内的电话线和有线电视线全换成 Cat5E 网线(因为并不长所以没有搞更高标号的)
户型图肯定是简化了的,不过不要在意细节
然后跟规划对应,用的时候就是图上的主卧 1 和次卧两个口,主卧 2 虽然接了线,但因为大概会被柜子挡住,所以就先扔着不用了。不过后来买家具的时候重新考虑了一下房间布局,柜子改为放在了另一面墙上,而且弱电箱没有 220V,交换机虽然可以用 PoE 但终究是有些麻烦。于是干脆不再用主卧 1 了,弱电箱里面也不再装交换机而是直接把电视柜回来的线跟次卧那根线连起来。
搬家之前办了宽带,这次用了电信。
这次给的设备(还是叫光猫吧,叫习惯了)是 10G EPON,四个千兆口(一个给 IPTV),没有 WiFi,然后电信有一个骚操作是搭售了两个定制的小米 CR8809,本来是不打算用的,但是一看是高通方案的 11ax,想着说凑合用也行。结果装好之后去缴费,收费方式居然是每月每台十块钱。。。这 tm 过于离谱,直接退掉。
最后套餐是一个月 89
总体来看还是不错的。另外,因为 Tinc 已经整的比较好了,所以也懒得改桥接、整公网 IP,直接用。
搬进来之后就要考虑各种设备的连接了。主卧 2 和电视柜仅有一墙之隔(而且是那种比较薄的砖墙,基本不影响无线信号),但次卧就比较远,而且要考虑使用场景上的区分。简单说结论:
最终所有设备如图连接,区分开几个网段(用不同的线表示)
其中:
目前来看 PC、NAS 这些主要设备都没有更新的需求,网络方案应该在相当长一段时间内不会再有变动了。
既然终于有机会自己装修了,那肯定得整一套对不对。当然考虑到个人需求,第一次整这个没有整太多东西,主要就是灯。
预算不太多,所以客厅和卧室选了 Yeelight 的智能灯,其他的餐厅走廊阳台之类就随便买了些普通的 LED 吸顶灯,搭配小米的智能开关实现全屋所有灯接入米家控制。
除了灯之外还装了小米的指纹锁,不过那个就不涉及到什么智能之类的事情了。
买的是灵犀 Mini,24W Ra95 的智能灯,两个。各种参数和晒图之类到处都是,就不贴了。用起来还不错,除了两个槽点:
买的是跟卧室灯同一个系列的灵犀 Pro,除了功率(90W)和体积(客厅灯当然大很多,灯罩的形状和固定方式也变了)之外没啥区别。
安装的时候发现固定灯罩的卡扣断了三个。跟客服联系,客服一开始说补发一套卡扣,草民觉得时间太久就让客服直接走京东换货,客服也没说啥就安排了,结果换来的货卡扣断的更多了。
再次找客服直接问卡扣怎么回事,这次客服倒是直接说这一批卡扣都有问题,会补发一套改良的。居然一整批都是坏的,离谱……以及客服又顺便送了一个小夜灯。
除了卡扣问题之外倒是一切都很好。当然,既然是同一个系列,这个灯跟卧室灯一样也只能连 2.4GHz 的 WiFi 控制,也自带一个没啥用的蓝牙网关,跟卧室灯唯一一点不同是可以在米家里面把网关功能关掉。
还带一个遥控器,是跟卧室灯通用的,但是只能跟一个灯配对。
之前有介绍过小米这个智能开关搭配普通的灯使用的体验,确实效果很好。但现在有搭配智能灯使用的情况了,实际体验下来有些问题:智能灯是需要保持供电的,开关由灯自己决定。虽然小米这个开关也可以设置成【转换为无线开关】(也就是不再控制通断),但是这样的话,这个开关的事件只有【单击】一种,就很没用。
而且如果遇上固件升级之类重启,这个开关并不会恢复到默认导通的状态,还需要在米家里面手动先关闭【转换为无线开关】,再开启这个开关,再打开【转换为无线开关】,才能恢复正常使用。
目前感觉搭配智能灯的话,确实还是 Yeelight 的那种纯机械的凌动™️(就不知道为什么米家的 UI 上面要强调这是个商标)开关更好一点,也不会有上面提到的如果没有本地中枢网关(下面会提),或者小米云服务器寄了,或者自家网络出问题之类事情发生的时候,就没法通过自动化来开关灯的情况。希望后面有固件升级能支持双击之类的事件,并且能保持【转换为无线开关】之后的通断状态吧。当然哪天要是觉得心烦把这三个换成凌动™️开关也不一定(
小米这个蓝牙网关体系里面分中枢网关、从网关、盲网关。
走云端的自动化依赖网络和云服务器的可用性,但是呢:
父母抱怨了两三次灯关不上 / 打不开之类,确实觉得这样不太好所以还是买了中枢网关。
接上之后确实效果很好,原来走云端的自动化执行可能有一两秒的延迟,改为本地执行后感觉只有几十毫秒就能响应。但是这玩意儿除了这个之外着实没有啥别的功能了,而且好尼玛贵,三百多,还不支持 Zigbee,老设备都不能拿来用(好像也没什么老设备了
在米家里面可以看到某个特定自动化规则是在云端执行还是在本地执行。
一般来说不涉及到开关自动化 / 一些太复杂的动作之类都可以本地执行,当然如果是新接入了中枢网关的话,之前已有的规则需要重新保存一下才能重新判断是否在本地执行。中枢网关的固件也在持续更新,应该会逐渐支持更强大的本地执行能力。
有两个按键的蓝牙开关,搭配中枢网关可以得到几乎没有延迟的本地自动化。
这个开关支持的事件就比较多,如果米家智能开关也能支持长按 / 双击的事件就好了。
这个开关也是有 86 盒使用的固定螺丝孔位的,但可惜它是用 CR2032 纽扣电池工作,虽然换电池并不需要把开关拆下来(只要掀开按钮盖板就行了),但把这样一个东西几乎永久固定在墙上可能还是不太合适。
米家这个温湿度计其实 2020 年就买了一个,后来因为确实很便宜,加上成都冬天没暖气还是有点冷,就又买了俩。
实际这个因为温度上报频率太低、延迟太高而没什么用,看温度还行,用来比如触发空调自动开关之类就完全不可行。
门锁自然还是选了智能锁,主要确实懒的带家门钥匙(虽然还是要带自行车钥匙,不过那个就算忘带也无所谓,家门钥匙可不行)
1S 支持天地钩,不过天地钩其实没啥用。现在安装的时候,安装师傅基本都不会装这个了。虽然草民自己是国庆假期花了几天时间研究了下这个钩子怎么装,而且因为原来门上的天地钩有些变形、生锈,尺寸也有几毫米的差距,最终着实颇费了一番功夫才把它装上,当然细节就不说了,还是建议就不装天地钩(
这把锁支持指纹、NFC 和密码这三种解锁方式,也能通过蓝牙网关接入,但蓝牙网关能做的事情不多:
其他的添加用户之类都需要手机蓝牙直连才能进行。
Project Home 会跟 DIY / Real NAS Project 一样持续迭代。后续会做的一些事情包括
这个系列的内容大概很难称为经验分享(基本全是坑),有兴趣看下去的话就当图一乐嘛。
]]>