![](https://ch3n9w.github.io/posts/tech-kubernetes-webhook/2024-05-05-18-14-26.png)
Kubernetes Admission Webhook 部署和调试
Deployment and Debugging of Admission Webhook in Kubernetes cluster Intro Dynamic admission control 允许开发者添加自己的逻辑代码来对提交给API Server的对象进行修改和验证, 是非常强大的功能. 本文将部署一组demo admission webhook, 包括一个validating webhook 和一个 mutating webhook, 并介绍webhook的调试方法. 本文主要使用和参考了从0到1开发K8S_Webhook最佳实践, 并通过查阅官方文档对其中的一些不适应新版本k8s的内容进行了修正. 本文使用的集群环境为Kubernetes v1.25.16, 使用minikube创建. 我所在的机器为Arch Linux. 代码仓库为 admission-webhook-example中的v1部分. 在开始之前, 请确保集群的API Server开启了MutatingAdmissionWebhook和ValidatingAdmissionWebhook (一般默认情况下都开启了). Deployment 创建 service account 创建一个用于webhook的service account kubectl apply -f deployment/rbac.yaml 创建证书 API Server调用Webhook的过程是需要HTTPS通信的(其实集群内的通信几乎都是HTTPS), 因此需要为webhook创建证书来对webhook的service进行域名认证. 原博客使用的webhook-create-signed-cert.sh已经过时, 不再适用于1.25.16版本的集群了, 主要出问题的地方如下: # create server cert/key CSR and send to k8s API cat <<EOF | kubectl create -f - apiVersion: certificates....
CVE-2023-26484 Kubevirt 权限提升漏洞复现
该漏洞是论文工作 “Take Over the Whole Cluster: Attacking Kubernetes via Excessive Permissions of Third-party Applications” 挖掘到的, 对其进行复现可以更好地理解rbac的潜在风险. ...
若为自由故, 软件皆可抛
借着"若为自由故"这本书, 读者可以更深刻地理解开源软件与自由软件的异同之处. 由于在实际情况中, 二者都开放了源代码, 大部分情况下也都会采用互相兼容甚至相同的协议, 因此其中的区别在越来越多人眼里逐渐模糊. 如今的软件行业, 大多数人在表达相同意思时更加倾向于使用"Open-source"而不是"Free"这个词, 不仅能够直观清晰地表达信息, 也能避免"Free"这个单词常用的"免费"之意 (为了人们认识到"Free software"中的Free不是免费而是自由的意思, Stallman 可强调了许多次, 但很遗憾, 大部分公司在听到他的强调前就会被吓跑). 但只要了解过自由软件和开源软件的历史, 就能发现其中差距并不在技术而是在道德层面上的分歧. 具体来说, 开源运动更加注重软件开发方式的开放性, 一种类似于集市场景中人人可参与的, 以软件质量为最终目标的倡议, 它关注的是软件本身, 因此颇具工程师的纯粹特性; 相反, 自由软件运动不仅仅注重软件开发方式, 更赋予软件本身以道德属性, 它更强调软件用户的自由修改和自由传播的权利, 以"人的自由"为中心, 任何限制软件用户这些权利的个人和组织都是"邪恶"且需要被抵制的, 这让它更像是一种社会运动. 有一句Stallman的话可以很好地阐释其意: “如果一个软件是不自由的, 哪怕它的技术非常先进, 我也不会去使用它”, 相反, 开源运动的代表人物Linus曾经在一次大会上公开表示自己是Microsoft Powerpoint的粉丝用户, 二者的冲突也由此而来: 在开源主义者眼中, 商业软件是一个不完美的解决方案, 但是在自由软件者眼中, 商业软件则是彻头彻尾的敌人. 两种运动并不是互相独立的, 相反, 开源运动脱胎于自由软件运动, 是后者为了适应软件行业商业发展的一种必然演变, 也是追求自由的理想主义者在现实屡屡碰壁后的一种妥协. 在今天, 尽管Stallman依旧在全球各地对着众多慕名而来的听众布道, 他也依旧能给人以震撼人心开悟明智的感觉, 但这种感觉过后又有谁会真的去追随他的步伐, 去将自己生活中的所有专有软件清除呢? 要知道, Stallman的攻击目标, 可不仅仅是个人计算机中的专有软件, 任何非自由软件, 不管是汽车上的, 飞机上的, 动车上的, 乃至收音机里的, 都是他的抵制对象. 而对于没有资源的普通人来说, 单是找一台彻头彻尾源码可见(指主板上的固件)的笔记本电脑, 就已经是一件非常困难且完全没有性价比的事情了. 从我的角度来看, 虽然很遗憾, 但是自开源运动成长起来后, 自由软件存在的意义就没有以前那么大了, 甚至说的不客气一些, 微乎其微....
![](https://ch3n9w.github.io/posts/ctf-k8s-lan-party/2024-03-26-21-02-36.png)
k8s lan party
Long time no CTF~~ RECON Just check the environment related to K8s using env and reconnoiter internal service using dnscan This blog is good written link Finding Neighbours According to the description, the sidecar container of current pod is sending some information (possibly flag) to remote server. So, the first step is digging the remote server like what we do in the first challenge, which leads me to reporting-service.k8s-lan-party.svc.cluster.local. As we all know, all containers within same pod share one network namespace, which means we can sniff the traffic from our current container....
2023年度总结
一事无成的一年, 但也算有所收获, 如果教训也算收获的话. ...
Learning eBPF
eBPF 是一项革命性的技术, 起源于Linux 内核, 它可以在特权上下文中(如操作系统内核)运行沙盒程序. 它用于安全有效地扩展内核的功能, 而无需通过更改内核源代码或加载内核模块的方式来实现. 从历史上看,由于内核具有监督和控制整个系统的特权,操作系统一直是实现可观测性, 安全性和网络功能的理想场所. 对ebpf慕名许久, 正好趁寒假拜读一下Learning eBPF, 虽然是基于略过时的框架bcc, 但是在这个过程中学到的知识想必依旧可以迁移到别的框架去. Background and pre-knowledge bcc bcc的ebpf c代码不是真正的C, 而是bcc自己定义的一种和C类似的语言. limitation of ebpf program eBPF 程序必须被验证器校验通过后才能执行,且不能包含无法到达的指令; eBPF 程序不能随意调用内核函数,只能调用在 API 中定义的辅助函数; eBPF 程序栈空间最多只有 512 字节,想要更大的存储,就必须要借助映射存储; 在内核 5.2 之前,eBPF 字节码最多只支持 4096 条指令,而 5.2 内核把这个限制提高到了 100 万条; 由于内核的快速变化,在不同版本内核中运行时,需要访问内核数据结构的 eBPF 程序很可能需要调整源码,并重新编译。 tracepoint and kprobe tracepoint其实就是在Linux内核的一些关键函数中埋下的hook点,这样在tracing的时候,我们就可以在这些固定的点上挂载调试的函数,然后查看内核的信息. Tracepoint是在内核中固定的hook点, 并不是在所有的函数中都有tracepoint. 这时候, 我们就需要用到kprobe了. kprobe可以动态地在所有的内核函数(除了inline函数)上挂载probe函数 eBPF virtual machine The ebpf virtual machine uses 10 general-purpose registers (0-9), and additional register 10 which was used as a stack frame pointer (can only be read but not written)....
![](https://ch3n9w.github.io/posts/gossip-rip-clash/404.png)
RIP Clash
2023年11初,简中互联网又发生了一出闹剧,不过于以往的过眼云烟所不同的是,这次的事件导致了一系列优秀开源软件的消亡. 起因 事件的经过其实并不复杂.11.2,clash for windows 的作者删除了github上用于发布的仓库中的信息,并在个人telegram频道上宣布不再开发.由于cfw的操作简单,对小白友好,因此其用户数量相当之大.删库的消息出来后,网友们纷纷开始关注作者的社交账号,对是否因信息泄露导致被抓加以猜测.其实对于一个网络代理软件来说,无论是因为被请喝茶还是因为作者不想干了而删库都是一件很正常的事情. 如果事情仅仅到这里就结束,那么大家顶多也就感慨一句过去说烂了的那些话,甚至对于开源主义者来说连感慨都没有,因为cfw本身就是一个闭源软件,而github仅仅是用来发布二进制包的. 但是事情没有那么简单. clash for windows是基于开源的clash core核心代码做的图形化客户端工具,而该核心代码同样是一系列类似软件(例如clash x, clash meta)的基础组件.或许是出于对clash core作者的尊重,这些项目的名称中也都包含了clash字样. 通常情况下,开发者并不会在意自己的软件被普通用户和其他clash相关软件搞混.而对于cfw用户,尤其是其中的小白用户来说,他们中的大部分仅仅接触过cfw,因此在口口相传中会自然而然地将clash这个有特征的词作为clash for windows的指代以节约沟通成本,cfw是clash, clash是cfw. 因此,cfw被删库后,消息通过互联网在用户群体之间开始广泛传播开来,很快就演变为了下面这张图上的消息. 假消息只是第一步.对于大部分cfw的用户来说,他们似乎并不知道此种软件的敏感程度和软件作者所面临的风险,他们只是在盲目地在各大社交媒体上发问,而很遗憾却也意料之中的,这其中,包括了微博. 前面提到,cfw的低门槛为它带来了众多的用户,而现在,这些用户将成为压死所有clash相关项目的稻草.由于提问和吃瓜的人太多,相关话题的热度不断上升,该话题很快出现在了微博的热搜上. 于是事情失控了. 结果 11月3号,出于对自身安全的考虑,几乎所有clash相关软件作者,包括clash内核项目作者,集体将代码库删除.一个持续了数年,帮助到许多网民的软件,却因为网民们的无知,在一天之间内尽数消亡.整个过程实在太快,快得根本不像有关部门的有组织行动.因为驱使项目消亡的,仅仅只是网民们的狂欢,和开源作者们的恐惧. 而可悲的是,在删库时间结束后,clash在微博的话题热度更高了,是的,没有人关心项目作者是否会因为这场风波而被捕入狱,他们只想四处打听,吃瓜,并迫切地希望看到血流成河. 一直到现在, 有关话题在telegram上还在被持续不断的争论中, 其中跳出了一些人来试图通过捏造事实抹黑多位作者来洗脱自身的责任. 可笑的是,当被要求放出对应的项目时,此人开始转移话题,并且在他臆想的情况下,对作者进行了人身攻击. 可悲的是,这种人在这场风波中并不少见,他们不仅仅是无知,更是无耻. 教训 其实单纯责怪用户并没有什么意义,毕竟像cfw这样方便的软件,其用户群体是鱼龙混杂的,要求他们集体提升相关的意识也是不现实的,所以很遗憾,尽管我们可以斥责部分的微博用户,但是归根到底,如何改变此类软件尤其是开源软件的危险现状,作者该做出什么样的改变来更好地保护自己,才是更有现实意义的话题. 具体来说, 对我而言, 除非开源软件合法合规,否则: 不要做windows平台下的软件 不要在项目中包含简体中文说明 不要取朗朗上口好记的项目名 控制推广范围,就是对作者最大的保护 尽管以上措施会限制软件的使用范围,但是对于此类软件来说,开发者的人身安全才是第一位的. 只是,这些教训,对于已经消亡的项目来说,已经太迟了. 参考 https://github.com/net4people/bbs/issues/303 https://www.eaimty.com/2023/opensource-project-based-on-hormone/
![](https://ch3n9w.github.io/posts/gossip-beijing-travel-2023-2/image-20231031004630871.png)
2023 记北京秋游
与所爱之人在一起的时光, 会生出互相的珍惜, 这份珍惜犹如风筝线一般, 即便对方远在云端, 依旧可以感知到其心念所动, 于是思念由此而生. 在yq成功上岸家乡的教师编后, 为了庆祝, 也为了缓解许久未见的相思之苦, 我匆忙计划了一下行程, 一边让她订来北京的车票, 一边思考附近哪里有卖香槟的. 颐和园 选择颐和园, 是因为离信工所比较近. 当日原本想带yq去我平时去的早餐店, 可惜我们出发之时, 已是中午十二点了, 于是带她吃之前推荐过的意大利沙县萨莉亚. 这是一个价格非常亲民的意大利西餐厅, 看了看菜单上十几二十元的菜品后, 我们彻底放下了对价格的顾虑, 仅仅考虑口味和胃口. 实际上这家店的口味确实不错, 特别是蘑菇浓汤, 虽然肯定不能说顶级, 但这种不用顾虑价格就享受西餐的轻松感, 独此一份 (说白了还是太穷). 阳光正好, 晒在身上暖洋洋的. 我们在下公交之后, 慢慢悠悠前往颐和园的入口, 路上落叶飞舞, 却无半点萧条, 行人来来往往, 一个婴儿车里的小孩指着另一个在妈妈自行车车筐里的小孩羡慕地哇哇直叫, 惹得两边的家长忍俊不禁. 走走停停之间, 我们时而在路边的亭子里歇脚, 时而在红砖绿瓦的不知名府门前驻足拍照, 心下一片闲适. 进入颐和园后才发现这里出乎意料的大, 但想想这毕竟是皇帝的游玩之地, 倒也算合理. 我们绕过威武的麒麟像, 路过皇帝慈禧临时听政的仁寿宫和一棵棵百年龙柏, 穿过城关, 来到谐趣园. 因为是秋天的缘故, 尽管气温并不让人觉得有秋意, 但是池中的荷花已经尽数枯萎, 风光不再, 宛如那个死去多时的王朝. 沿着回廊行走, 我恼于这行走的空间竟然如此狭窄, 古代的皇帝不与人并肩行走, 其他的人只能尾随, 因此凡是走廊一类的地方都可以设计地窄小一些, 只是我不禁开始无端思考, 长期地处于这样的空间里, 人的心胸眼界是否也会变得狭小呢? 一路上看到了许多格格打扮的女生在凹造型拍照, 纸扇轻摇, 回眸一笑, 气质优雅, 恬静端庄, 只是都没有我的身边人这般可爱. 来到苏州街, 我和yq沿河而行, 小心路过一间间无人的商铺....
![](https://ch3n9w.github.io/posts/tech-lineageos-md/image-20230814215125234.png)
lineageos使用体验
2024年7月更新: 经过了半年的时候, 遇到的问题包括但不限于 1) 微信卡顿 2) 银行类app无法使用 3) system UI经常崩溃 4) 快充消失. 出于可用性考虑, 已经转回coloros 2024年2月更新: Lsposed连同一系列root隐藏模块已经归档无法使用, 为了方便日常使用, 建议卸载magisk, 刷机的时代已经过去了. 不知道从什么时候开始, 往日被冠以高可玩性高自由度的安卓系统逐渐变得封闭, 一步步沦为资本市场的玩物和工具. MIUI也好, ColorOS也罢, 用户总能在使用系统的过程中发现一些去也去不掉的应用和小程序, 看到一些不想看也得看的广告, 而起初, 有些人尽管对此有所不满, 但基本都选择容忍的态度, 但这几年国内的趋势越来越不对劲: 先是某APP在全社会的宣传下或软性或硬性地被安装在了相当大一部分人的手机中监控个人信息(当然, 我理解打击诈骗行为, 保护平民百姓的钱包远比软件自由重要得多), 又是拼多多被爆出利用安卓手机的0day漏洞在所有用户的手机上进行多种恶意行为, 一直到最近, 一则某信部的发文通知将这种 我的手机不归我管 的焦虑感推向了新的高潮. 就目前来看, 这则通知的社会反响并不强烈, 不出意外应该可以顺利推行. 之后最直观的效果就是所有使用国内安卓系统的用户都只能安装指定的app, 不再具备安装推特等软件的能力, 这无异于干掉了安卓最大的特点, 使其沦落为全方位落后于苹果的手机系统. 作为一个经历过安卓app爆发式增长年代的玩家, 我很好奇现在新接触到手机的用户对自己掌中的设备是一个什么样的印象, 是一个拥有无限可能的工具? 还是一个用低质量内容, 广告和充满限制的操作系统来无限吸收注意力, 获取个人隐私并变相管理个人精神世界的资本和政府工具? 万幸的是, 安卓的开源属性为它保留下了一些自由的火种, 那边是第三方rom. 本文主要记录自己安装 lineageos, magisk, Lsposed 以及一些有用软件的过程. 购买机器 查看lineageos支持的设备列表, 出于对一加的偏好和对骁龙888发热的不放心, 我选择以一加8pro作为自己的新设备. 在咸鱼上逛了很久, 筛掉一大批机器贩子和低质量卖家后, 我看中了一位宝妈的二手机并下单. 机器到手后我非常满意, 因为成色实在是很好, 连维修店里给我手机换电池的工程师也赞叹保养得不错, 这1700虽然有点贵, 但还是值得的....
动荡时代
乱世之中, 唯有自我与我所爱值得珍惜 ...
我的neovim
现在回头看几年前自己写的插件配置文章, 看着那些曾经用过但后来都纷纷被替代的插件, 我会莫名怀念那段因计算机和终端而兴奋不已的自己. ...
2023 小游京城
难得黄小姐来一次北京, 作为肥宅的自己紧急规划了一下游玩路线, 发现北京可玩的地方相当的多, 这里仅仅记录这次游玩所经过的三个景区. ...
优化neovim markdown中的treesitter高亮
eye candy也是一种生产力! ...
树莓派搭载clash作为旁路由
“一个黑暗的形体,像一个匍匐的人一般大小,但是长着长长的蜘蛛一样的肢体……黑暗中的形体以惊人的速度向他奔来。当它靠近时,他看到那蹲坐着的乌黑身体上有一张脸,在身体底部那些多节的腿之间。那张面孔用一种怀疑和质问的可憎表情凝视着他;而当这个大胆的猎人与那小而狡诈的,四周全是毛发的眼睛对视时,恐惧流遍了他的每一根血管。” ...
![](https://ch3n9w.github.io/posts/tech-ext4-to-btrfs/btrfs.jpeg)
ext4到btrfs转换记录
这篇文章是对我从ext4文件系统转换到btrfs过程中的一些操作记录, 便于日后参考. 前置准备 制作arch linux 启动盘, 版本越新越好. 备份重要文件 我个人在转换前会把大文件(例如虚拟机文件)转移到移动硬盘里, 让转换过程更快一些 转换 进入LiveCD 系统, 对主分区进行转换 btrfs-convert /dev/nvme0n1p2 等待一段时间之后, 显示conversion complete就表示没有问题, 接下来还需要做三件事情才可以进入系统 修改fstab 首先将转换成功后的分区挂载到/mnt下 mount /dev/nvme0n1p2 /mnt 使用lsblk -f命令查看分区的UUID号, 拍个照片记一下 编辑/mnt/etc/fstab, 修改这个分区类型为btrfs, 将最后的两列数字都改成0, 保存退出 重建内存盘 先挂载, 然后进入chroot环境 mount -t proc none /mnt/proc mount -t sysfs none /mnt/sys mount -o bind /dev /mnt/dev chroot /mnt bash 然后执行下列命令来为所有内核重建内存盘 mkinitcpio -P 最后重建grub引导, 按照道理应该要把引导分区/dev/nvme0n1p1挂载到/mnt/boot之后才可以, 但是我记得自己执行的时候没有挂载? grub-mkconfig -o /boot/grub/grub.cfg 重建grub引导 在上一步的chroot环境中, 执行下列命令, 记得把引导分区挂载到/mnt/boot grub-mkconfig -o /boot/grub/grub.cfg 大功告成, 退出chroot, 重启电脑就可以进入你的系统了, 唯一的不同是它已经是btrfs了....
![](https://ch3n9w.github.io/posts/tech-translation-under-wayland/1.jpg)
wayland下的划词翻译解决方案
对于我这种英语不好的人来说, 翻译是离不开的工具, 但是众所周知, Linux的日用软件生态相比较windows和macos来说相差甚远, 别说目前正处于发展阶段的wayland, 就连成熟透了的x11下也没有拿得出手的翻译软件. 作为一个英语不好的Linux爱好者, 缺少翻译软件必定会对日常的使用造成一定的影响, 于是开始思考怎么样解决这个问题. 我的第一个思路, 也就是见到最多的划词翻译软件的样子, 选中文本之后, 在被选中的文本周围的某块区域中绘制一个窗口, 在其中展示翻译结果. 但是问题来了, 要如何绘制这样的窗口呢? 在wayland中, 窗口的位置交给了compositor进行管理, 这种能够自己决定显示位置的能力, 据我所知, 在wayland下仅有fcitx5做到了, 于是我翻阅了一下它的源代码, 并没有看懂, 但是应该没有借助于Qt和GTK来绘制, 而是使用wayland-client. 对我这样一个连Qt GTK开发经历都没有的人来说, 理解wayland编程开发中的那些概念实在有些困难. 于是紧接着又有一个问题出现了: 能否绕开wayland? 就我思考这个问题的时候, linux QQ给我发了一个系统通知, 我的电脑上的系统通知服务原先只是为了让linux qq不崩溃才安装的, 然而这个时候, 它给了我一个新的解决方案: 使用系统通知来呈现翻译结果. 于是搜了一下如何发送系统通知, 发现竟然意外的简单. notify-send "title" "content" 那么接下来的问题: 如何获取选中文本的内容? 这个问题, 我原本计划通过阅读wl-clipboard来学习的, 但是我想先尽快用上翻译, 把优化放到以后再说, 于是决定直接使用wl-clipboard来获取选中文本内容, 那么至此思路理清, 大致如下: 使用剪切板获取到选中文本的内容, 可以使用wl-paste -p来获取 获取文本之后, 将换行符替换成空格 (这块可以有更好的处理方法, 简单起见就全换掉了), 使用sed 文本处理完毕后, 将文本输入进translate.js中进行翻译, (这块可以使用别的现成工具) 翻译结果出来之后, 将结果以系统通知的形式呈现出来, 当然, 系统通知必须要有, 可以是dunst, mako, swaync, 以及kde或者gnome的桌面消息通知都可以....
![](https://ch3n9w.github.io/posts/tech-arm-firefox/image-20230109230723998.png)
武装火狐
不管火狐的市场份额多么拉胯, 对于Linux wayland用户来说, 目前体验最好的浏览器依旧是Firefox. 本篇记录我的FIrefox配置, 包括浏览器设置和插件设置. 外观 titlebar 为了让标题栏中的内容可以更加紧凑, 一个好办法是进入about:config, 设置browser.compactmode.show为true, 然后进入custom toolbar, 设置Density为Compact 对于wm用户, 一个推荐的设置是勾选上上图中的Title Bar选项, 为什么要这么设置呢, 因为这样子做, 那些按钮(最大最小化, 关闭窗口)就会出现到title bar中, 然后title bar会被wm吃掉, 这样就可以给火狐的标题栏留出更多的空间 ps: 我用的主题名字叫做tokyonight Firefox-UI-Fix 使用Firefox-UI-Fix来个性化Firefox的界面 Addon Vimium 该插件将vim的操作方式带入到浏览器中, 能够让用户更少依赖鼠标. 默认情况下, firefox出于安全考虑会在一些页面中禁用Addon, 为了让该插件能够在更多的页面上使用, 需要在about:config中进行以下设置 extensions.webextensions.restrictedDomains清空掉 privacy.resistFingerprinting.block_mozAddonManager设置为true,来让插件在所有页面上都可以使用 以下是我的Vimium键位设置. # Insert your preferred key mappings here. unmapAll map H previousTab map J previousTab map L nextTab map K nextTab map <c-j> scrollPageDown map <c-k> scrollPageUp map <c-o> goBack map <c-i> goForward map o Vomnibar....
2022年度总结
2022年是一个记得被纪念的年份, 不是因为它有多好, 而是因为它有多现实 ...
小阳人日记
生命本就如此脆弱 ...
![](https://ch3n9w.github.io/posts/tech-arch-sway/image-20221217132544646.png)
使用Arch Linux + Sway一年后
不知不觉使用sway已经整整一年了,于是来谈一谈自己这一年的使用感受,顺便回顾了一下过去。 起因 2019年,在一次编程作业的时候,同专业的另一个老哥向我展示了vim的代码h补全,我立刻被这种简陋但是扩展性极强的代码编辑器吸引了,于是当时还是个刚转入计算机专业的小白就开始哼哧哼哧地学习vim的配置和插件的安装。当然,这些都发生在我的Kali Linux虚拟机中。 那个时候我正接触CTF,很多时候都要开着虚拟机,于是有一天动起了把电脑系统直接装成linux的想法。因为自己的第一台笔记本是暗夜精灵2,游戏本装Linux,第一个要考虑的就是兼容性和稳定性,在权衡各个发行版的优势和流行程度后,我选择了ubuntu18.04。笔记本重装完毕后除了风扇转个不停竟然一切运行正常,这让我实在有些惊喜,而风扇问题是英伟达独显导致的,在ubuntu上,只需要一条sudo ubuntu-drivers autoinstall就完美解决了。当时的自己很开心,仿佛打开了一道新世界的大门。 后来,我去吉林参加了第一次线下赛,ubuntu没有掉链子,帮我拿了一个一血,我很满意。直到一次上课,手贱执行了apt upgrade,升级完电脑竟然无法开机了,一整个无语,而当时临近期末,我已经没有时间再去折腾系统了,于是紧急安装了windows应付期末复习,顺便下单了一台对Linux更加友好的笔记本Thinkpad T480。 期末考试结束后,我听说了Arch Linux 的大名,但是出于畏难情绪,我选择将ubuntu18.04安装在我的thinkpad t480上,然后去参加xman的夏令营。在夏令营期间,我的电脑在连接wifi一段时间后就再也连接不上了,第一次我选择了重装,但是第二次还是同样的问题,我只好绝望地回到windows10,事后分析的时候,我觉得应该是驱动的问题,thinkpad t480是2018年下半年发布的,ubuntu18.04的驱动可能确实没覆盖到它的网卡。 之后的好几个月里,我都乖乖用着windows10和WSL2,实习的时候全程在虚拟机里面写代码。等到实习结束、保研也结束的时候,我又开始了新一轮的折腾。 2020年下半年,我将自己的主力电脑全面迁移到了Manjaro Linux下,那个时候qv2ray还很活跃,我的科学上网也很依赖它,但是有好几次在更新的时候发生了Manjaro特有的问题:软件的版本更新上来了,但是软件的依赖没有更新上来,这种问题也影响了trilium等软件,虽然不能怪manjaro,但是我还是愤而转向了Arch Linux,一直到今天我也还在用。 转到Arch Linux之后,我基本上不再改变自己的发行版了,只是会在图形界面折腾一些。2020年-2021年上半年我使用的都是KDE,好看是真好看,但是Bug也是真的致命,这其中我亲身经历过的至少三次重复出现在不同电脑(thinkpad T480出现过,thinkbook 14p 出现过)的bug就是盒盖睡眠失败,我不知道是谁引起的,是plasma还是conky还是别的什么组件,我不知道,我在日志里也查不到。别看这个问题好像没什么,但是作为一个笔记本用户,盒盖后放进包里是一个非常自然的行为,回到宿舍没有第一时间拿出电脑而是休息一会也是很正常的行为,但是休息完后发现自己的电脑在包里变成了一个铁板烧就不是一个正常的现象了。嘴硬的人当然会说thinkpad不是有指示灯吗?你看指示灯判断是否睡眠成功不就行了?且不说我后来的电脑thinkbook 14p是没有指示灯的,单就系统质量而言,一个系统每次使用的时候都需要用户小心翼翼盯着指示灯看,是否已经说明了这是一个糟糕的系统了?为什么换成thinkbook?就是因为这个bug把我的thinkpad的主板烧坏了!我曾以为这是thinkpad独有的问题,可是当thinkbook也发生同样问题的时候我对KDE彻底失望了,是的,这是一个很漂亮的桌面环境,定制性强又有很多特效,可是这一切都建立在一些不稳定的bug上的时候,这些特效会更多扮演起bug的导火索角色。 经历过KDE的bug后,我对复杂的桌面环境产生了恐惧,他们就像是一枚不定时炸弹。在这个前提背景下,我接触并开始使用SwayWM,一直到今天,我也还在使用,而那个致命Bug,已经离我远去。 体验 得益于Arch Linux庞大的用户群,Arch 的软件包生态在一众发行版中可以说是称王称霸了,我举一个例子,你能想象在Linux的软件仓库中会出现deepin-wine魔改后的腾讯系软件吗? 每次看到其他发行版用户手动下载deb然后安装的时候,我都会产生一种他们是不是在用windows的错觉,并不是看不起别的发行版,只是各有分工和侧重点,比如Arch的定位是桌面端用户,而很多别的发行版的定位是服务器,我不会用别的发行版当作我的桌面系统,就像我不会把Arch装在服务器上一样。用统一的包管理器管理软件包肯定是有好处的,能够大大减轻用户的心智负担。 至于网络上提到的Arch Linux不稳定、容易滚挂的问题,不好意思,我用了两年Arch了,每天都执行yay -Syyu,从来没有出现滚挂的问题,相反,我目前所遇到的半数Linux相关问题,都是因为系统软件或者依赖库过于老旧而导致的,更新后就可以解决。Linux不是Windows,如果你不想要更新,那么有两种选择,第一种,锁定自己的软件版本,然后在每次安装新软件的时候单独解决依赖问题;第二种,回去用windows。 说完了Arch Linux,再来说说Sway,这是一个简单的wayland窗口管理器,为什么用wayland,因为我不希望自己的图形界面建立在一个老旧而难以维护的基础设施之上,那给我的感觉就好像我在使用另一个plasma。诚然,wayland还有很长的一段路要走,很多桌面软件都不得不借助xwayland才能在其上运行,经过实际使用,除了在4k屏幕上xwayland有问题之外,其他情况下还是可以完美工作的。当然,部分软件是有问题的,比如腾讯会议的桌面共享功能,但是也已经有了曲线救国的办法,所以现在wayland的生态已经比之前要好一些了,当我看到linux qq内测群里有人提出wayland下的问题以及要求兼容wayland的时候,我就相信未来还会更好。 Sway是一个窗口管理器,开发者做的事情是在wayland下复刻一个i3wm出来。窗口管理器的好处是我现在更多依赖键盘而不是鼠标了,可以减少对视觉聚焦于鼠标这种行为的依赖,转而更多依赖自己的触觉,另外,更少的特效和更简洁的设计不仅让我的系统大大增强了稳定性(据一位用KDE的同学说,直到今天,用KDE只要一周不关机就必定会崩溃),还让我自己更加专注于手头的工作(平铺式窗口管理器的统一好处)。不好的地方当然也有不少,比如初次接触的时候要花很多时间去配置和适应,比如每次修改操作键位的时候都需要一定时间去重新适应,比如fcitx5在某些软件下面无法工作或者是有缺陷(这不是fcitx5的锅),比如它让我认识到自己是一个很笨蛋的人,使用了一年了,让我时不时就发现自己的操作习惯可以有优化空间,比如: 在按win+数字键的时候,用大拇指去按是很扭曲的姿势,**一个更加自然的姿势是用左手的掌心左下(手背视角)的部分去压win键,然后用手指去按数字键。**如果要按ctrl+win,就用同样的部位压住两个键,这个难度会大一些,大概确实还可以优化的。 调整窗口大小的时候,进入resize模式然后用键盘去按是很低效的行为,相反,这种时候依赖鼠标不是什么坏事,通过把鼠标悬停在窗口上然后按住右键进行拖拽就可以实现快速的窗口大小调整。 scratchpad中更适合使用tab模式。 有的时候在两个workspace之间切换会很频繁,这个时候更适合用workspace back_and_forth而不是一直执着于用数字键去切换,或者使用鼠标的滚轮来切换,这也是一个不错的主意。 除此之外还有一个小的优点,在sway下可以给不同键盘换上不同的布局,这点对我而言是刚需,但是在xorg下面,这种操作往往只能将同一个布局应用于所有的键盘,一旦布局出现了问题导致键盘不可用,那么所有的键盘都会变得不可用。 最后,我和大部分的geek用户不一样,我比较笨,只是一个普通用户,我做不到也不想去和他们一样视鼠标如洪水猛兽,相反,sway下我还是会频繁使用鼠标,对我来说用鼠标去交互两个窗口的位置依旧是比用键盘更加高效的操作。所以我想说的是,追求属于自己的实用性,你可以去参考别人的建议,但是最终还是要找到属于你自己的习惯。 对于我个人来说, 我也完全不排除在plasma的bug修复后回到plasma的可能性,毕竟老牌桌面。 列出我使用的软件: 桌面环境 SwayWM(窗口管理) waybar(信息展示栏) 终端 alacritty 浏览器 firefox-developer-edition (主力) chrome 输入法 fcitx5 代码编辑 Neovim(主力) Vscode(副手) Jetbrains 做笔记 Neovim-qt zotero 文件浏览器 ranger dolphin 看论文 zotero okular 游戏 steam(泰拉瑞亚、黑暗之魂……) waydroid(明日方舟) HMCL(minecraft) 工具替代 exa 替代 ls zoxide 替代 cd scp 替代 cp Trouble Shooting 关机的时候出现 a stoping job is running for xxx hangout 修改/etc/systemd/system....