一个奇怪的小测试
这里有一个奇怪的小测试w
目前一共只有四关；如果你对 tg 较为熟悉，应当可以在 30-60 秒内通关整个测试。
注：1%的情况下破烂的 tg 客户端可能导致卡关（绝大部分情况下无此问题）。如果确实卡关的话可以试试换个端。

点我开始

不带转发重新发一下，这样不会暴露大号（虽说早就暴露了

Discord 的开发者文档，不仅下 Snow 还下 Snowflake （
谐音梗，扣钱（

好了 这下到新年了
那 il 就在这里祝大家新年快乐喵~

新年新气象！整个集群炸完啦！

緒山かやね @nidbch - 2025.1.4
かやね可爱喵~

- 您觉得今天的面面怎么样？满意请给我们五分好评哦！
- 一百分好评~

#群友交汇

对dan先生的崇拜+1
不过dan先生似乎删掉了他的Twitter账号，看了Web Archive上也没留下来，还是有点可惜的
全文摘抄一下好了

If you add TypeScript I will applaud you.
If you remove TypeScript I will applaud you.
What matters is that you're changing the code, not what those lines of code do.
Change means life, you're living it.

来对最近的破事进行一个盘点，顺便再批判一下摇摇欲坠的现代科技

前两天要把简历打包成zip，需求很简单，简历.zip里只放一个简历.pdf，然后给zip加个备注就行。
快速Google完了解到分别用zip和zipnote两个工具即可搞定，然而接下来却遇到了不少问题：

1. 首先在Linux上运行zip，发现报了奇奇怪怪的错误：

*** buffer overflow detected ***: terminated

上网搜了一圈只知道这是libstdc++的某个报错；咨询群友后得知这是zip 3.0-6版本的一个bug，只要文件里含有中文就会报错。直接apt upgrade到3.0-8版本就可以了。

2. 无奈把文件复制到Windows上运行zip，成功。接下来运行zipnote，但又报错了；

zipnote error: Bad file descriptor
*** glibc detected *** zipnote: free(): corrupted unsorted chunks: 0x00000000 ***
*** glibc detected *** zipnote: malloc(): memory corruption: 0x00000000 ***

继续上网搜，得知这也是一个bug；最早提出问题的帖子是在2011年，帖子里有人给出了完整的源码patch文件，只需要改一行即可修复。
另一个2014年的帖子里，有人联系了zip的开发者；很快，开发者回复了邮件，表示已经在3.1 beta里修复了。
而2025年的今天，zip的最新版仍然是2008年发布的3.0，而3.1或者3.1 beta版本仍然不见踪影（

3. 没办法，只好把zip文件复制回Linux使用zipnote，没想到竟然成功了。
好奇查找为什么Linux上成功，一通搜索后最终找到了Launchpad，这里有一名Debian雇员和一名Ubuntu雇员分别负责zip在两个发行版上的维护。zip本身自2008年发版以后就没有再更新，Debian和Ubuntu上的zip包都是两人修了各种bug的版本。Debian最新版本已经来到了3.0-14，而Ubuntu在Debian的基础上还会修更多的bug，最新版本是3.0-14ubuntu1。

Debian和Ubuntu已经是比较好的情况了，虽然维护者只有一人但勉强能够算持续维护；Windows上msys2的zip包则是完全没有人维护，zip和zipnote的bug也不会有人来修了；在Windows上遇到这种情况，只能放弃包源里的zip包，手动从svn（zip的源码没有git）里下载zip的源码，从LinuxQuestions论坛和Launchpad里搜集到一打patch后自己apply编译。

虽然现在Windows上几乎没有人用infozip了，但我相信Linux上zip还是会有不少每日使用量的；连「zip」这样常用的包都如此破烂，会发生xz那样的事件好像也不奇怪了（望天

怎么Helm Chart又跟docker绑上了
脑袋要炸了 又得找怎么做镜像
这帮人天天喊着脱Docker，折腾了几年，好不容易脱完Docker了，又要迁回Docker了
基金会工资全拿来干这种事了

---
更新：helm pull oci://xxxxx，pull下来的就是原来的tgz文件，暂时就用这种方法下载tgz文件再手动安装了

不知道是哪个版本开始，VMWare会有奇怪的bug，打开我的Ubuntu以后有概率卡死整个电脑，也就是十几年前常说的「死机」——鼠标都卡得几乎无法移动。
鼠标卡死之后，我下意识地艰难移动鼠标到VMWare的「关机」按钮旁，按下了「关机」按钮。
按下之后我才意识到不对——我按的是「关闭客户机」按钮而不是「关掉电源」，在客户机装了VMWare Tools的情况下，VMWare会优先和VMWare Tools通信，告知其需要关机。然而里面的Ubuntu早就整个死机了，当然没法响应VMWare的请求。于是这里就出现了令人哭笑不得的场景：
1. VMWare没对软关机模式做timeout；可能是觉得这里不管给多少的timeout都不太对，毕竟在装有很多负载的Linux上，执行整个关机流程很可能达到半小时或者更久；
2. 但与此同时，VMWare给所有状态切换按钮加了锁，在任意操作完成之前，都不能对虚拟机执行更多操作。
于是死角出现了：虽然虚拟机已经卡死了，但外面的我没办法执行任何操作；唯一正在执行的上锁操作在等待卡死的虚拟机给出响应。
等了五六分钟还是没有任何恢复的迹象，无奈打开任务管理器，艰难移动鼠标找到VMX，最后结束进程。
结论：VMWare也是破烂软件（
现代软件里具有极高稳定性和可用性的软件越来越少了，现代科技什么时候彻底倒塌（

破烂还在继续……给集群里的gitea做升级，gitea新依赖了Bitnami出的redis-cluster，但部署好以后就出现了cluster无法创建的问题
Google以后发现了好几个issue，从2022年一直讨论到现在，盖了150多楼：
https://github.com/bitnami/charts/issues/10172
https://github.com/bitnami/charts/issues/12901
issue里好多人都给出了自己的解决方法，还有很多人去看了源码，然后觉得应该是源码里有bug
但爬完所有楼以后我突然意识到了问题：redis-cluster这个破烂，至少需要3个节点，并且三个节点需要一起启动
第一次部署的时候我只部署了一个，启动失败了；后面我又把replicas增加到3个，这么做是不行的，需要把replicas归零以后再瞬间提升到3，redis就能正常启动了
一种难以言说的破烂涌上心头……

不过gitea升级完毕了，今日收工
今天运维一天，感觉TODO的50%都没做完；不过已经困得不行了，只能明天再继续了（

今日离谱小知识：

const int a = 1, b = a + 1;

在 gcc 8.1（2018-05-02）才加入支持，这之前的版本是不支持的

可以用下面两句话快速在你的电脑上试试看：

echo 'const int a = 1, b = a + 1;' > aa.c
gcc aa.c

伊妹儿出现以前的世界，是什么样的呢

#妹儿