“中年男人，装备集齐！”

该渲染由 Kami API 生成，可能存在排版问题，最佳体验请前往：https://www.miaoer.net/notes/41

近日我买了酷态科 10 号 Plus 超级电能棒，终于补齐了我那中年男人“最后一块拼图”的 tags 即 —— 路由器、NAS、充电器，。我选择这款移动电源（充电宝）的理由是本人是一个偏执的数值怪秉承着 “不达目的不罢休”，这玩意不仅放电快用电也很快，真正的妥妥玩一天。（）

酷态科 10Plus
接口
此前我一直在用小米 lite 版 22.5w 充电宝，总感觉缺点啥。虽然很便携，但是充电速度实在感人，当时是为了上水课补电，小米 14 用起来唯一让我痛点就是续航太短了满电状态也仅仅能玩一个下午，而且也不是随时能充上电。当时就看上了酷态科的产品感觉猛是猛，作为学生党相比小米充电宝他不太实惠因为 zmi 那个时候也不算特别便宜了，而且我是不是真的能完全利用好这个产品这里要打大大的问号。

机缘巧合下，陆陆续续就收集了有几个 C 口的产品以及充电头数据线，以及群友送的桌充…就在半年前舍友换的酷态科 15SE 超级电能柱，我也稍微体验了一下，充电非常的快就是非常的沉。而且 iPad 那段时间也用的很多，就买了个酷态科 10 号超级闪充块。日常用起来就是插两口就全部快充走起来，很舒服。

喵二の充电头
小米 Lite
还买了个维简 cc1 U 表（数显表），看看功率是不是起来了，后面忍不住就每一个设备都去插测一下功率。这个表也不能推断准确的协议类型，也不能诱骗，只能去猜测，不过也足够使用了。

最近是不在常有电的地方了，恰好平台优惠力度比较大。说是领券下单 167 可以拿下 10 号 Plus 黑骑士，我一直很心水这个充电宝。因为旧的 Lite 他只能在 USB-A 口走私有的 Mi turbo charge 很是麻烦而且很慢。还是软包电芯自从家里那个老款小米 2c 移动电源鼓包以后就对软包电芯的充电宝有了嫌弃，顺带一口气全换 c 口的线和充电宝。 另外还给朋友也安利了一波酷态科 cp13 自带线一共 71 他对充电功率不敏感能用就行，我也没推荐软包电芯的。

包装
参数
数据线这里多多随便买的 1.5m c2l 的才 5.8，甚至还是是编织线，很轻，能跑满这个 iPad Mini 5 20w 的功率。

c2c 用的酷态科 10 号超级闪充块的 2m 线，我觉得可以入一个他们的磁吸编织线，这样方便收纳也美观。胶质的长时间会粘东西，于是就花了 5 折券，一共 25 拿下酷态科磁吸编织线。唯一感觉不好的一点是就是磁吸线太重了，很有分量感。 但是…但是他很好盘，没事就喜欢拆下来盘一圈。

百瓦自充
放电
c2l 数据线
花了一段时间体验这个酷态科 10 号 Plus 超级电能棒黑骑士版，重量适中和我预想中的大致，自充前 60-70w 都是 PD 100w 协议实际 94w 后面才变成 PPS 协议，逐渐变慢直到充满循环一次。给小米 14 从 20% 充到 70% 消耗 10Plus 了的23% 电量。也就是可以给小米 14 完整充满两次，而且基本上和插市电充电头功率一样，这就很爽了。 真的可以妥妥玩一天，并且用两天。而且他也带边充边放，可能是官方觉得这样伤电芯，也没做宣传。但是如果是旅行的时候应急使用充电宝接充电器，手机接充电宝，也是可以都充满的，尽量少用这个功能即可。

本篇非广，对此大家都完成了这个成就了吗？🤔

小米 Lite 相关阅读： https://www.miaoer.net/posts/blog/23-618

看完了？说点什么呢

via 喵二の小博客

MCP 协议与古茗排队事件解析 | 2025 年第 16 周草梅周报

本文在 草梅友仁的博客 发布和更新，并在多个平台同步发布。如有更新，以博客上的版本为准。您也可以通过文末的 原文链接 查看最新版本。

前言

欢迎来到草梅周报！这是一个由草梅友仁基于 AI 整理的周报，旨在为您提供最新的博客更新、GitHub 动态、个人动态和其他周刊文章推荐等内容。

----------------------

最新 AI 动态

最近研究了下 MCP（Model Context Protocol，模型上下文协议），发现一些有意思的东西。

MCP 虽然看上去高大上，实际上只是个封装调用函数给大模型的协议。简而言之，就是把函数和函数的介绍发送给大模型，让大模型来判断下一步要调用哪些函数，MCP 在这个过程中只是进行了一些规范。

当然了，虽然实现方案就是这么的简单直接，但这并不代表 MCP 就不好用。

实际上，MCP 最大的意义就是统一了 AI 大模型和外部系统的连接方式，让系统对接 AI 大模型更加方便。

其次，通过预先确定函数，则可以更好的管控权限问题，在最极端的情况下，大模型也无法调用 MCP 没有提供的功能，在权限和安全问题上更加可控。

对开发者而言，通过 MCP 协议，可以简化开发所需的代码量，可复用他人的 MCP 集成（例如 GitHub/Google Drive 等。

此外，通过跨多步任务保持上下文连续性，避免了传统 RAG 的单次检索局限，增强了上下文感知能力。

当然了，最好的是，通过统一的 MCP 协议，可以兼容不同 LLM 厂商（如 OpenAI、Anthropic、DeepSeek 等），极大的降低开发压力。

MCP 现有的生态在快速爆发，发布仅一个季度，MCP Server 数量已接近 5000 个，主流厂商（如 OpenAI、腾讯云、阿里云）纷纷支持，东方超算等国内企业推出第三方服务平台。

甚至还出现了类似 MCPFlow 这样的 MCP 聚合搜索平台，更加方便快捷的对接 MCP。

虽然现在 MCP 生态还不是特别成熟，但在可预见的未来内，MCP 会成为调用 AI 大模型的主要方式之一。

----------------------

古茗排队事件解析

最近参加了下古茗×崩坏星穹铁道联动的活动，抛开一些业务上的问题不谈，今天只从技术上谈这次联动存在的问题。

首先，最抽象的事情就是那最逆天的全国用户一起排队了。

喜欢我一百万用户一起排队吗？

此事在微博热搜亦有记载

我来帮各位理一下这里的逻辑。

由于用户量过大，所以要排队，这个逻辑很合理，但不合理的地方在于全国只有一个队列。

一个很显然的事情是：用户是全国分散的，也只会就近参与门店点单，所以，按门店来排队是最优解。如果说为了缓解各门店的压力，则至少该按区县排队，从而减少门店查询的压力。

而古茗程序员选择了最差的做法，将全国用户放在一个队列里，轮到之后才能去选择到店自取或者外送。

然而就算是这样，这个排队功能依旧存在 bug，用户可以点进历史订单再下单，就可以卡进门店……

第二个抽象的事情就是，古茗的地图 API 调用量达到了上限。

可见到底有多少人

这里的问题就是古茗作为使用方，是向腾讯位置服务这边购买了一定额度的接口调用量，只不过联动的时候调用次数过多，超过了额度，被腾讯这边拦截了。

这个问题其实也不算技术问题，更多的是业务上没想到还有这样的问题，只能说没有备用方案。

第三个抽象的事情就是无法支付了。

一般而言，订单系统都会把生成订单和支付分开，并且会在生成订单这一步锁定库存，然后走支付流程。

在这个过程中，在生成订单这一步承受流量是比在支付这一步承受流量来的方便的，因为订单系统一般是内部的，更加可控，支付系统是外部的，不一定可控（同时，一般还要处理来自支付系统的回调）。

不过，古茗没有在生成订单的时候就锁定库存，而是等到支付的时候再判断，此时就导致大量用户堵在支付步骤，导致支付业务崩溃。

不少用户（包括笔者）都是在反复支付失败后回到了点单页面，而此时联动套餐早已售罄……

当然，不锁库存对于非秒杀系统其实是有好处的，那就是不会因为用户进了订单而没有支付导致库存被无端锁住。

当然了，其实古茗程序员对于系统可用性还是做了一点优化的，比如说接口降级、刷新提示等

当然，代价就是用户会时不时看到等待刷新的提示，用户体验极差。

虽然上面从技术上分析了很多，但从技术上解决远不如从业务上解决。

本次联动最大的问题就是把来自线上的高额流量，直接击穿到了线下的门店，导致各家门店都爆满，而数量极少的主题店更是直接爆单，订单数奔着 2000+ 去了。

如果要解决问题，最好的方式就是开预售，售卖兑换券，让线上的流量在线上承担，然后线下承受的流量就会大大下降。

此时用户量已经被兑换券筛过一遍，上限不会超过兑换券数量，摊到每个门店之后就到了可控范围内。

如果要进一步优化的话就是线下门店也预定，事先知道有多少用户来点餐的话，那么也方便饮品和周边的准备。

总之，这次 古茗×崩坏星穹铁道联动 的本质还是流量分配失衡，将线上的高额流量直接击穿到线下，导致门店实际服务能力与线上流量严重不匹配。

由此引发的一些问题，值得业务方和技术方思考。

作为一个普通的玩家兼程序员，只希望后续的联动都能吸取下这次的教训。

最新 GitHub 加星仓库

● CaoMeiYouRen starred afdian-linker - 2025-04-20 17:17:13
爱发电 API 集成旨在提供统一的订单管理和外部查询功能。该项目主要使用 Vue 语言开发，目前有 1 个星标。
● CaoMeiYouRen starred easevoice-trainer - 2025-04-20 17:16:34
EaseVoice Trainer 是一款简单易用的语音克隆和语音模型训练工具，主要使用 Python 语言开发，目前在 GitHub 上获得了 188 个星标。
● CaoMeiYouRen starred lexe - 2025-04-20 17:16:26
将 Node.js 应用程序打包成单个可执行文件，且文件大小限制在 10MB 以内。主要使用 Rust 语言实现，项目在 GitHub 上获得了 300 个星标。

其他博客或周刊推荐

阮一峰的网络日志

● 科技爱好者周刊（第 345 期）：HDMI 2.2 影音可能到头了 - 2025-04-18 08:07:46

HelloGitHub 热点速览

● 7 个最近很火的开源项目「GitHub 热点速览」 - 2025-04-15 10:12:27

阿猫的博客

● 猫鱼周刊 vol. 062 AI 旅游攻略 - 2025-04-20 18:48:11

潮流周刊

● 第 218 期 - 勾狗可爱 - 2025-04-14 08:00:00

二丫讲梵的学习周刊

● 学习周刊-总第 207 期-2025 年第 16 周 - 2025-04-17 21:14:15

总结

本周的更新和动态如上所示。感谢您的阅读！
您可以通过以下方式订阅草梅周报的更新：

● 博客：草梅友仁的博客
● RSS：草梅周报
● 公众号：草梅友仁的后花园
● 邮箱订阅：草梅友仁的博客订阅

往期回顾

● AI 开发 afdian-linker 与 GitHub 加星仓库推荐 | 2025 年第 15 周草梅周报 - 2025-04-13 18:53:48
● ComfyUI 使用指南：AI 图像生成工作流详解 | 2025 年第 14 周草梅周报 - 2025-04-06 17:40:54
● GPT-4o 多模态图像生成功能解析 | 2025 年第 13 周草梅周报 - 2025-03-30 20:04:29

本文作者：草梅友仁
本文地址： https://blog.cmyr.ltd/archives/2025-16-caomei-weekly-mcp-protocol-guming-queue-analysis-.html
版权声明：本文采用 CC BY-NC-SA 4.0 协议 进行分发，转载请注明出处！

via 草梅友仁的博客

#155 – 助聽器體驗 / ChatGPT 工作術 / AI 自製課程倒數計時器®️雷蒙週報

via 雷蒙三十｜幫助忙碌現代人的聰明工作、好好生活的生產力指南 (author: 侯智薰 （雷蒙）)

来个openmanus的浅入门

前阵子一个manus在目前的所谓人工智能圈子里甚至普通人视野里都很火了，宣称是什么中国的下一个deepseek时刻，首先deepseek是经过了v1，v2等一系列版本的迭代之后，并且一直是在技术上非常花功夫的，有种宝剑锋从磨砺出的感觉，而这个manus听着更像是个蹭热度的

via Nicksxs's Blog

使用 Dokploy 部署网站服务

via oldj's blog

X Window 与 Wayland 的深度对比

X Window 与 Wayland 不仅代表了图形界面技术不同发展阶段，更体现了设计理念、架构模式及应用场景的显著差异。本文将从历史背景、技术特点、应用场景及未来展望等多个维度，对 X Window 和 Wayland 进行深入剖析。

历史背景演变

X11 诞生于 1984 年，由麻省理工学院 MIT 开发，旨在满足分布式计算环境下图形界面需求。其设计哲学强调网络透明性，允许用户在远程服务器运行应用程序，并在本地终端显示结果，极大地拓展 GUI 的可用性和灵活性。随着时间推移，X11 凭借其广泛的硬件和软件支持，逐渐成为 Linux 桌面环境的标准图形界面后端。

随着计算需求增长，X11 的一些设计局限逐渐显现，例如架构复杂、性能瓶颈和安全性问题。2008 年，Kristian 提出 Wayland 项目，旨在创建一个更加现代、高效窗口系统。Wayland 的设计重点在于简化架构、提高性能和增强安全性，采用客户端 Compositor 通信模型，减少了中间层，提升了效率和响应速度。

技术特点比较

X11 采用 C/S 模型，客户端通过 X 协议与服务器通信，而 X 服务器负责处理所有图形和输入事件。相比之下，Wayland 采用了客户端 Compositor 模型，客户端可直接与 Compositor 通信，Compositor 负责了窗口管理、合成、输出。Wayland 的架构更加贴合现代图形硬件特性，可以更高效地利用 GPU 和现代显示技术。

X11 在安全性方面存在了固有弱点，其复杂协议和广泛权限易被恶意利用。Wayland 通过限制客户端权限以及简化通信模型，显著提高了安全性。例如，Wayland 禁止了应用程序直接访问底层硬件，只允许了它们与 Compositor 通信，从而增强系统的安全性。

Wayland 的协议设计更加高效，减少了延迟和带宽消耗。在移动设备和资源受限的环境中，Wayland 的优势尤为明显。此外，Wayland 避免了不必要的复杂性和额外处理，使得其在性能上优于 X11。尤其是在窗口大小调整以及拖动等操作中，Wayland 显得更加的平滑流畅。

X11 拥有庞大的生态系统，支持大量的应用程序和工具，几乎所有 Linux 发行版默认都使用 X11。然而，Wayland 的生态系统正在快速发展，主要桌面环境如 GNOME 和 KDE 已全面支持 Wayland。尽管如此，一些特定应用程序和工具可能仍需要额外的兼容层或补丁才能在 Wayland 下运行。

应用场景

在桌面环境中，X11 凭借其广泛的兼容性和成熟度，仍然是许多用户的首选。但随着硬件技术的进步和用户对高性能图形渲染的需求增加，Wayland 正在逐渐成为主流的选择。

越来越多的 Linux 发行版开始默认支持 Wayland，例如 Fedora 和 Ubuntu 等。

在移动设备和嵌入式系统中，资源受限是一个普遍的问题。Wayland 的低功耗以及高性能特性使其成为这些场景下的理想选择。

例如，Android 系统中的 SurfaceFlinger 就是基于 Wayland 的原理设计，用于图形显示以及窗口管理。

在虚拟化和云计算的环境中，图形性能以及网络传输效率至关重要。

虽然 X11 的网络透明性在某些场景下仍有些优势，但 Wayland 通过优化的协议和架构，正在成为虚拟桌面基础设施 VDI 和云桌面解决方案的首选，特别在需要高性能图形渲染的场景中。

未来展望

随着 GPU 技术的成熟以及高性能计算需求的增长，图形界面的渲染以及交互将变得更加复杂和多样化。

X11 和 Wayland 都在积极的探索与 Direct Rendering Manager、Mesa 等图形驱动框架的更紧密集成，以实现更高效的图形渲染和硬件加速。

此外，Wayland 还在研究如何更好地支持多显示器配置、高分辨率显示、触控输入，以满足未来计算环境多样化需求。

最后说两句题外话，近一个月杜老师因为工作的原因，拖更了很多篇文章，感谢小伙伴们的关注和催更，近期会大批量发表一些技术文章，欢迎大家关注。

via 杜老师说

Android Weekly 2025-15 期

via Android Performance

Garmin Forerunner 265S Charging Problem

A Disappointing Problem for an Expensive Watch

via Lei Mao's Log Book

使用 Python 脚本下载指定网页的图片文件

有小伙伴反馈说侧边栏随机图出现了重复，有些审美疲劳，要求杜老师再更新一些图片，正好聊天广场有小伙伴分享了一个美图的网址。本文分享如何使用 Python 脚本下载指定网页的图片文件，需要的小伙伴可以参考文中代码。

代码需求

使用 Python 的语言编写一个脚本，下载指定网址中包含的多种格式图片文件，如 JPG 和 PNG 格式图片。

将图片保存至指定的目录中，可以指定绝对路径，或者相对路径。

并用随机数重命名，防止同名图片触发覆盖事件。

尽可能使用 Python 的标准库，尽量避免使用第三方库。

变更解释

1. 导入必要的库：包括 os/requests/re 以及 random；
2. 定义函数：download_images 函数可用于下载图片；
3. 获取图片链接：使用正则表达式从网页内容中提取图片 URL；
4. 下载保存图片：使用 requests 库下载图片，并且使用 random 库生成随机数作为文件名；
5. 指定目录：确保保存目录存在，如果不存在则创建；
6. 获取内容：使用 requests 库获取网页内容。

功能代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

import os
import requests
import re
import random

def download_images(url, save_folder):
    # 确保保存目录存在
    if not os.path.exists(save_folder):
        os.makedirs(save_folder)

    # 发送HTTP请求获取网页内容
    response = requests.get(url)
    if response.status_code != 200:
        print(f"Failed to retrieve the webpage. Status code: {response.status_code}")
        return

    # 使用正则表达式查找所有的图片URL
    image_urls = re.findall(r'&LTimg[^>]+src=["\'](.*?)["\']', response.text)

    for img_url in image_urls:
        # 处理相对路径的URL
        if not img_url.startswith(('http://', 'https://')):
            img_url = os.path.join(url, img_url)

        # 下载图片
        img_response = requests.get(img_url)
        if img_response.status_code == 200:
            # 生成随机文件名
            random_filename = f"{random.randint(10000, 99999)}.jpg"
            save_path = os.path.join(save_folder, random_filename)

            # 保存图片
            with open(save_path, 'wb') as f:
                f.write(img_response.content)
            print(f"Downloaded and saved {img_url} as {save_path}")
        else:
            print(f"Failed to download {img_url}. Status code: {img_response.status_code}")

# 读取网址列表文件
def read_urls_from_file(file_path):
    with open(file_path, 'r') as file:
        urls = file.readlines()
    return [url.strip() for url in urls]

# 示例调用
if __name__ == "__main__":
    urls_file = 'f:\\代码\\urls.txt'  # 包含网址的文件路径
    save_folder = 'f:\\代码\\images'  # 保存图片的目录路径

    urls = read_urls_from_file(urls_file)
    for url in urls:
        download_images(url, save_folder)

注意：本示例代码仅适用于 Python 3.x 版本，运行于 Windows 系统。如使用 Linux 系统，可能需要进行相应修改。

使用说明

将上述的代码保存为 download_images.py 文件。

在运行脚本时，传入目标网页的 URL 和保存图片的目录路径。

脚本会自动下载网页中所有图片，并且以随机数命名保存到指定目录中。

打开的网址保存在一个文件，每行一个网址。

via 杜老师说

PIVOT Vol.15

via Another Dayu

k8s强制删除hang死状态pod

最近在 Kubernetes 使用中，有个 Pod 一直处于 Terminating 状态，通常原因是 Pod 占用的某些资源未被正确释放（如 Finalizers、Volume 挂载、网络资源、节点状态为NotReady等），强制删除也一直卡住，尝试了各种姿势，最后不得不去 ETCD 删除 Pod 数据解决，mark一下。

1. 检查 Finalizers

Finalizers 是 Kubernetes 中用于控制资源删除、防止资源被意外删除的保护机制。如果 Pod 的 metadata.finalizers 字段不为空，Kubernetes 会等待这些 Finalizers 被清除后才能删除 Pod。

解决方法：

● 手动编辑 Pod，移除 Finalizers：

kubectl edit pod &LTpod-name> -n &LTnamespace>

找到 metadata.finalizers 字段，将其设置为空数组 []，然后保存退出。

● 或者使用 patch 命令直接移除 Finalizers：

# 查看 Pod 的 Finalizers
kubectl get pod &LTpod-name> -n &LTnamespace> -o jsonpath='{.metadata.finalizers}'

# 移除 Pod 的 Finalizers
kubectl patch pod &LTpod-name> -n &LTnamespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

2. 检查节点状态

如果 Pod 所在的节点（Node）出现问题（如节点宕机或网络断开），Pod 可能会一直卡在 Terminating 状态。

方法：

● 检查节点状态：

kubectl get nodes

如果节点状态为 NotReady，尝试重启节点或修复节点问题，通常包括。

1. 检查节点硬件资源，确保资源充足。
2. 检查节点网络状态，确保节点能够正常通信。
3. 检查节点上的容器运行状态，确保容器正常运行。

3. 检查 Volume 挂载

如果 Pod 使用了持久卷（Persistent Volume，PV），并且 PV 无法卸载，可能会导致 Pod 卡在 Terminating 状态。

方法：

● 检查 PV 和 PVC 的状态：

kubectl get pv
kubectl get pvc -n &LTnamespace>

如果 PV 或 PVC 处于异常状态，尝试手动修复或删除它们。

4. 重启 Kubelet

如果问题依然存在，可能与节点上的 Kubelet 有关，可以查看异常Pod 所在节点 Kubelet日志并尝试重启 Kubelet：

# 查看 kubelet 日志
journalctl -u kubelet -f

# 重启 kubelet
systemctl restart kubelet

5. 检查 API Server 日志

如果问题仍然存在，可以检查 Kubernetes API Server 的日志，查看是否有相关错误信息。

方法：

● 查看 API Server 日志：

kubectl logs -n kube-system kube-apiserver-&LTnode-name>

kubectl logs -n kube-system -l &LTlabel-name>=kube-apiserver

6. 强制删除 Pod

如果 Finalizers 已经移除，但 Pod 仍然卡在 Terminating 状态，可以尝试强制删除。

解决方法：

● 使用 kubectl delete 的 --force --grace-period=0 参数：

kubectl delete pod &LTpod-name> -n &LTnamespace> --force --grace-period=0

这会立即强制删除 Pod，但可能会留下一些未清理的资源。如果还是hang住无法删除，可以尝试直接删除 ETCD 中 Pod 记录。

7. 直接删除 ETCD 中的记录

在 Kubernetes 中，etcdctl 是一个用于直接与 ETCD 交互的命令行工具。ETCD 是 Kubernetes 的后端存储，所有资源（如 Pod、Service、Deployment 等）都存储在 ETCD 中。如果以上方法都无效，可以尝试直接删除 ETCD 中该 Pod 的记录。注意：直接操作 ETCD 可能会破坏 Kubernetes 集群的状态，建议仅在万不得已时使用，请谨慎执行。

步骤：

1、在操作 ETCD 之前，建议先备份 ETCD 数据：

# 备份 ETCD 数据
etcdctl snapshot save snapshot.db

# 验证 ETCD 快照
etcdctl snapshot status snapshot.db

# 恢复 ETCD 数据
etcdctl snapshot restore snapshot.db --data-dir /var/lib/etcd

2、查看 Pod 的 ETCD 记录：

Kubernetes 资源在 ETCD 中的存储路径遵循以下格式：/registry/<资源类型>/&LTnamespace>/<资源名称>

例如：

● Pod：/registry/pods/default/my-pod
● Deployment：/registry/deployments/default/my-deploy
● Service：/registry/services/default/my-svc

Pod 的路径通常为：/registry/pods/&LTnamespace>/&LTpod-name>

# 查看某个 Pod 的详细信息
etcdctl get /registry/pods/&LTnamespace>/&LTpod-name>

# 列出所有 Pod 的键
etcdctl get /registry/pods --prefix --keys-only

3、删除 Pod 的 ETCD 记录：

# 使用 etcdctl del 命令删除 Pod 的记录
etcdctl del /registry/pods/&LTnamespace>/&LTpod-name>

4、验证删除 Pod 的 ETCD 记录：

# 删除后，可以通过以下命令验证 Pod 是否已从 ETCD 中移除
etcdctl get /registry/pods/&LTnamespace>/&LTpod-name>

如果返回为空，说明 Pod 已成功删除。

5、K8s资源 ETCD 增删改查操作(可选)：

# 列出所有 Pod 的键
etcdctl get /registry/pods --prefix --keys-only

# 列出所有资源键
etcdctl get / --prefix --keys-only | grep "/registry/"

# 修改资源（Update），导出资源为 JSON
etcdctl get /registry/pods/default/my-pod --print-value-only > pod-data.json

# 使用文本编辑器修改字段（如调整副本数、修复状态），重新写入 ETCD
etcdctl put /registry/pods/default/my-pod < pod-data.json

# 插入资源（Create），将 Kubernetes 资源 YAML 转换为 JSON，并确保符合 ETCD 存储格式
etcdctl put /registry/pods/default/new-pod < new-pod.json

# 删除某个命名空间下的所有 Pod
etcdctl del /registry/pods/&LTnamespace> --prefix

# 删除所有命名空间下的所有 Pod
etcdctl del /registry/pods --prefix

# 解码 Protobuf 数据，Kubernetes 默认使用 Protobuf 编码存储数据，可以通过 hexdump 或工具解码
etcdctl get /registry/pods/default/my-pod --print-value-only | hexdump -C

参考：

● Kubernetes 命令备忘清单

● etcd性能问题排查及解决方案
● k8s修改etcd 2379端口

via CHEGVA (author: anzhihe)

Go项目设计的“七宗罪”？警惕那些流行的“反模式”

via Tony Bai (author: bigwhite)

【日常碎碎念】珠江啤酒精酿品鉴会

via 7gugu's Blog

机器人半马，陪太子读书的可爱小个子，朱啸虎刚退出，松延动力机器人就在亦庄半马惊艳亮相！对比天工Ultra与宇树G1，探讨人形机器人步态控制与自主运行技术关键。

via 硕鼠的博客站 (author: Luke Fan)

动画刚开播就要消失的圣地：《时光流逝，饭菜依旧美味》圣地巡礼之高尾与西八王子

via 维基萌

Weekly Issue-吃早饭！

文章

技术

Why our 5.2k-star K8s platform struggles overseas while thriving in China? Need your brutal feedback : r/kubernetes

[[Rainbond]] 在海外推广遇到了困难，他们观察到的 3 个明显问题是：

● 声称自己是 “Heroku for Kubernetes” 替代品
● Open Source != Trust
● Deployment Culture Clash: 75% of Chinese clients demand air-gapped installs (even on edge nodes!), while Western teams expect SaaS-first. ● 这好像几乎是国内特有的情况了？

评论区中提到了 [[Harbor]] 在世界范围内被采用，是因为他们隐藏了是中国地区开发的。我觉得可能不是主要原因，当时 Harbor 是顶着 [[vmware]] 的光环在的，大家看重的更多应该是 [[vmware]]。对于评论区中的产品选型原因，感觉和行业或者技术壁垒有直接关系，比如 [[TiDB]] 那么多海外用户，[[Clickhouse]] 背后的投资人 [[Yandex]] 是俄罗斯公司，[[Deepseek]] 的开源项目引起的轰动，他们会没有考虑中国/俄罗斯的政治风险么？我觉得肯定考虑了。

下面那篇 TiDB 的文章中，也提到了国际化：

“最好的国际化，就是本地化。”
不同地区的文化差异太大，技术再牛逼，客户支持做不好，客户一样骂你没商量。

----------------------

Storage suppliers stare down Trump slump after tariff mayhem – Blocks and Files

不确定性会阻碍公司进行长远计划（这句话印象中之前一直是用来描述大陆的），现在看由于关税影响，短期内的报价工作都无法正常进行了。。

----------------------

极限编程和命名

尝试去应对变化，而不是预测变化，因为你永远不知道明天的需求是什么。

----------------------

十年再出发：回顾我与 TiDB 的成长之旅

值得反复阅读的经验总结。

----------------------

《The Mom Test》读后感

关于如何做用户调研的一些技巧。我的总结是，如果带有预设的去聊，对方作为用户可能什么都要，但是这些并不是真正需要的，不能看对方说了什么，要看对方 做过 什么，从对方 做过 的事情来吸取经验。

----------------------

DuckDB’s CSV Reader and the Pollock Robustness Benchmark: Into the CSV Abyss – DuckDB

[[DuckDB]] 尽可能的以兼容方式来读取 [[CSV]] 的方法：

FROM read_csv('cafes.csv',
 strict_mode = false,
 null_padding = true,
 quote = '"',
 escape = '"'
);

想到之前帮朋友处理一个奇奇怪怪数据的 Excel 的痛苦，当时好像用 [[pandas]] 手动处理了很多边界场景。

----------------------

Building OpenAPI Based REST API In Go Using HUMA Framework, With SurrealDB | by Shiju Varghese | Apr, 2025 | Medium

这篇文章中推荐了 GitHub - danielgtaylor/huma: Huma REST/HTTP API Framework for Golang with OpenAPI 3.1 ，之前在做新项目的时候，考虑使用自动生成 [[openapi]] 文档的框架，不想在 Gin 里面手动写注释生成，当时的选型还有 GitHub - go-fuego/fuego: Golang Fuego - Web framework generating OpenAPI 3 spec from source code - Pluggable to existing Gin & Echo APIs，好像是因为在自定义错误码的处理上不灵活，最终都没有使用，选择了 [[grpc]] + grpc-gateway + buf 自动生成的方式。

----------------------

Automating Linux bare-metal server deployment in Hetzner with Ansible – Palark | Blog

最近因为一个内部 BeraMetal 相关项目的后续迭代方向进行了一些思考，做 BareMetal 太苦了，比如这篇文章中的实现方式，如果没有 [[Hetzner]] API，会非常痛苦。痛苦的点在于：

● 需要适配大量的服务器品牌（国内和国外是两套生态）
● 需要适配同一个服务器 BMC 的不同版本 ● 看似存在 Redfish 这样的通用协议，但是落地下来各有不同
● 需要支持多种引导方式：ISO、PXE、PXE with DHCP
● 很多操作需要重启才可生效，涉及到上层的业务交互

----------------------

生活

来美国的两年后 - GeekPlux

我发现我越来越喜欢用年为单位去描述事情，可能这就是时间加速感的体现。希望自己能在未来的日子里：

● 保持好奇，保持谦逊，保持怀疑精神
● 接受随机，接受老化，接受自我平庸

最近也在想，是否“需要”换一个城市生活，还没有想法。

----------------------

GitHub - jlevy/og-equity-compensation: Stock options, RSUs, taxes — read the latest edition: www.holloway.com/ec

[[股权]]激励指南。 有需要的朋友可以看看，避免发生 zhihu 惨案。

----------------------

2025 清明凤凰经重装徒步 | Xigou Blog

看着确实太苦了，平时我都不徒步，重装徒步就更不可能了。

----------------------

我们高估了智力的重要性 | Randy’s Blog

在知识获取越来越“容易”的时候，其他方面的影响被放大了。

----------------------

I’m Leaving Sentry | Armin Ronacher’s Thoughts and Writings

十年。

----------------------

书影

《火锅艺术家》，一部典型的东北喜剧人电影。

《饥饿站台 2》，和朋友聊到才发现《饥饿站台》出了第二部，能够感受到创作团队想要表达的内容很多，但是最终呈现出来的效果不好。

碎碎念

● 发现自己之前写的单测完全没生效。。
● 买了水月雨的 pill 耳机，第一次用耳夹式耳机，使用感觉上还不错，跑步也没有要掉的感觉。耳机壳是败笔，很多人吹有多好“耍”，可以作为解压玩具，但是平时放在包里和裤兜中，经常自己就打开了，缺少固定锁。
● 吃早饭！不管如何，要吃早饭！

via Yiran's Blog

NetCup复活节促销AMD4核8G内存512G NVMe盘8.24欧元月

NetCup的服务器性能一直不错，硬盘给的也比较高，这次促销的配置最低是4核8G512GnVME固态的服务器。 […]

via 柴郡猫

我们的纪念日

via obaby@mars

DMA拼接

涉及到DMA应用的场景中，往往一方（比如FPGA）以固定Packet大小向DMA写入数据，另一方（比如CPU）也以固定Packet大小读出（或直接在DMA上操作）数据。一般情况下，为了提高DMA利用率，CPU处理的数据结构不一定正好是Packet大小的因子（packed模式），在这种场景下会涉及到数据的拼接问题。

via Bing's Blog (author: 作者)

请求为什么超时了？

小明是一名网络工程师，有一天，同事报告问题说：自己的程序发送 HTTP 请求在测试环境好好的，但是在线上环境就总是超时，而且很容易复现，需要网络工程师的帮助。

这里的场景是，在线上运行环境，去用 HTTP 请求一个第三方（在这个例子中，是 example.com 提供的服务）。

首先，小明和同事一起复现了问题，确定超时确实存在，然后他们在请求发送方进行抓包，在抓包的同时又复现了一次超时的情况。拿到抓包文件，小明一看，立即就发现问题了所在了……
timeout-issue.pcap下载
请下载这个文件并分析超时问题的根因。（如果没有头绪，可以打开这个提示）

==计算机网络实用技术 目录==

这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。

如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！

没有链接的目录还没有写完，敬请期待……

1. 序章
2. 抓包技术以及技巧
3. 理解网络的分层模型
4. 数据是如何路由的
5. 网络问题排查的思路和技巧
6. 不可以用路由器？
7. 网工闯了什么祸？
8. 网络中的环路和防环技术
9. 延迟增加了多少？
10. TCP 延迟分析
11. 压测的时候 QPS 为什么上不去？
12. 压测的时候 QPS 为什么上不去？答案和解析
13. 重新认识 TCP 的握手和挥手
14. 重新认识 TCP 的握手和挥手：答案和解析
15. TCP 下载速度为什么这么慢？
16. TCP 长肥管道性能分析
17. 请求为什么超时了？
18. 请求为什么超时了？答案和解析
19. 后记：学习网络的一点经验分享

与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。

via 卡瓦邦噶！ (author: laixintao)

TVbox配置及使用指南，新手必看！

TVbox 全解析,配置教程轻松上手,保姆级教程。

配置数据源

1. 确保设备已安装 TVBox 打开应用如图操作
2. 配置接口源，重要！大部分人使用不了就是因为这里出错 手机扫码配置指南，确保扫码设备和安装应用的设备连接同一WiFi
3. 配置完毕，返回首页会自动加载数据

使用指南

1. 点击主页可以快捷切换首页数据源
2. 通过搜索页面可以搜索影视剧、动漫、综艺等内容
3. 首页点击直播，可以观看电视直播内容。如央视、卫视等内容

常用设置说明

1. 首页推荐，有豆瓣推荐，站点推荐，观看历史等，根据自己喜欢可以选择一下。
2. 首页多行，修改是，搜索展示，选择缩略图，这样界面更美观，图标形式展现，而不是文字。
3. 聚合搜索：可开启可关闭，搜索展示不太一样。去广告推荐开启，有些广告不能屏蔽，数据来源网络，使用时要找一下好的源。下次进入：默认打开软件进入影视点播还是电视直播
4. 渲染方式推荐SU的这个，缓存推荐开启，加载速度会快一些，后期如果播放卡顿，可以清理一下缓存。
5. 播放器，tvbox默认ijk，推荐EXO画质更好一些，有些设备如果选择系统播放会出现黑屏没有画面，修改一下播放器就行，自己可以测试一下。
6. 播放界面，遥控可以直接调出菜单，有些遥控按三横键，有些不一样，自己测试一下。一些选项，设置跳过片头，片尾，倍数播放，刷新等。

常见问题

Q：点播和直播有什么区别？

A：点播是说例如电影、电视剧、综艺动漫等内容，直播是原来那种卫视、央视电视直播内容。

Q：使用什么软件扫配置二维码？为什么扫了没反应？

A：使用微信扫码即可，没反应或者访问不了要确保手机和电视连接的同一个WIFI。

Q：为什么有的资源只有画面没有声音？

A：请换一下软硬解和播放器（Exo那个选项）试试。

Q：为什么看搜索结果里的4K资源会弹出输出框？

A：这些4K高清资源需要调用你的网盘。原理是把资源下载到你的云盘里进行播放。请按弹出界面的提示用UC浏览器或夸克App等对应软件扫码即可。

via 游魂博客

Invalid media:
image
image
image
image
image
image
image
image
image
image
image
image
image
image