Manjusaka

Python 3.12 已经发布了一段时间，所以写篇水文来聊一聊这个常常被人忽略的史诗级版本。 正文Python 3.12 绝对是一个史诗级版本，在我心目中，它对于 Python 的意义，大于 “async/await” 的 Python 3.5 和 “Type Hint” 的 Python 3.6 对于 Python 的意义。 或者我们可以这么说在未来数年的时间里，Python 后续的很多意义重大的变更，其都能上溯到 Python 3.12。 理解我这一个观点，我们来说一下 Python 的几大痛点： Python 的可调式性，可观测性问题。历史上 Python 中做 Cost 的消耗极大，同时没有足够的手段可以从旁路去观察 Python 的运行时行为 Python GIL 问题，这个老生长谈了，不多说 Python 的 C API/ABI 问题，之前暴露的 C API/ABI 通常和 CPython VM 实现细节耦合，导致跨版本兼容性会是一个问题 而这样一些问题，Python 3.12 上都有了极大的进步 PEP 669， GH-96143 极大提升了 Python 的可观 ...

去参与社区？难吗？其实不难，只是你想的很难，或者说难是你给自己找的借口 正文很多人觉得参与进开源社区很难，无外乎几个原因 觉得自己技术栈不符合 觉得没啥事可以做 觉得太难了 我自己对于这个观点表示不太认可，所以我从九月中旬开始，用了一个月时间，利用 incubator-opendal 做了一个实验，为什么会选择这个项目？原因以下几点 Rust 对于我来说是一门我非常不熟悉的语言，相当于我跨技术栈去做一些事情 我自己之前是做网关和容器相关的偏多，存储方面对于我来说不是在我的好球区 所以我想看一下，我自己作为 fresh man 能在这个社区里面做什么事 截止到今天，我整体的提交记录如下 整体的花费的时间接近34h 整体工作内容横跨了几个方面 多个 Service 的支持（MySQL/Sqlite/MongoDB） 拾掇拾掇了 CI，参与 Action 的重构 把整体 Layer 的文档覆盖了 把可观测性的部分做了不少改进 而截止到目前，还有很多工作需要去继续跟进，比如 基于 DTrace 的进程调试支持 可观测性的几个 Layer 的完善 Layer 的测试补全 ...

好久没写 Python 相关的文章了，但是 Python 3.12 perf 原生支持的这个特性非常的棒，思路又新又好了属于是，所以写篇水文来聊聊这个特性 正文先聊聊 Python 的栈帧在聊今天的正式内容之前我们需要理解 Python 在内存中的布局 对于传统的 native application 而言，大家对于其内存布局应该是比较熟悉的，这里以 x86-64 的一张图来说明其栈帧结构 但是对于 CPython 来说，其 Native Code 执行的只是 VM 一层的代码。其在 VM 内单独抽象了一套类似 native 的栈帧结构。 其核心结构如下 1234567891011121314151617181920212223242526272829303132333435363738struct _frame { PyObject_HEAD PyFrameObject *f_back; /* previous frame, or NULL */ struct _PyInterpreterFrame *f_frame; /* points t ...

深夜看群友聊的我实在焦虑，起来随便写个水文压压惊 正文写这篇文章的原因是之前给 runc 提的 CPU Burst 支持的 PR [Carry #3205] libct/cg: add CFS bandwidth burst for CPU 终于开始有了新的动静了，这次换了一个国人的 reviewer，感觉要是运气好能在9月开始合并这个 PR。 如果这个 PR 被合并了，那么在 containerd/nerdctl 等其余项目上支持 CPU Burst 的工作就可以开始了。所以这篇文章就是想记录下我对于 CPU Burst 在 Kubernetes 内实现的一些想法，差不多可以当作自己写正式的 KEP(Kubernetes Enhancement Proposal) 草稿 主要分为两个部分来聊一下 CPU Burst 的一些背景 目前 Kubernetes 对于 CPU 资源切分的设计概要 CPU Burst 在 Kubernetes 中的一些设计想法 CPU Burst 的一些背景聊 CPU Burst 之前必须要先聊一下 Linux 里面关于 CGroup 的一些背景知识 提 ...

随手记录一些关于用户态栈回溯（Unwind）的一些杂记和想法。 正文昨晚三点过刚吃完药躺在床上休息的时候，突然想到了 @yihong0618 的之前在群里的一个想法 我在想 eBPF 能不能 trace libpq 的协议，好像还没有人做过 我最开始的一个想法是 现在主流做法还是 ptrace 系的东西（gdb 那套），你要用 eBPF 去 trace libpq 肯定没问题，就和 Grey 用 uprobe 去 trace go 一样，手算 cast。但是这里另外一个问题是 libpq 的符号信息不一定够。我倾向你可以这样试一下，你改一下 libpq 源码，关键地方走 USDT（我看你之前用过） 不过后续我师父出来有了一个提醒 如果目标是 trace libpq.so 的调用情况，那应该目前就可以做到。.so 相比 executable 有几个优势： 它一定有动态符号表 它一定有 .eh_frameuprobe 恰好又是 attach to the binary offset 而不是 process address，所以第一个优势完美匹配 uprobe，甚至绕开了 ex ...

最近工作强度有点大，写篇 Linux 相关的水文放松下 这个问题实际上是来源于在群里和人的一个讨论。一个基本常识是，子进程退出后，父进程会收到 SIGCHLD 信号，然后父进程可以通过 wait 或者 waitpid 等系统调用来获取子进程的退出状态。那么，子进程退出后，父进程有可能会收不到信号吗？答案毫无疑问是 yes 的 本文就来聊个其中一个比较好理解的场景 BTW 本文代码都基于最新分支的 Linux 源码 正文先来看一段代码Fuck，哦不，Shut up，我们先来看一段代码 123456789101112131415161718192021222324252627import osimport timeimport signalcount = 20result = 0print(os.getpid())def sigc_handler(*args): global result result+=1 os.waitpid(-1, 0) time.sleep(1)def sig_int(*args): passdef abc(): for _ ...

很多时候，帮助人不需要那么多理由

優しさを失わないでくれ。弱い者を労り互いに助け合い。

人生嘛，Homelab 图个乐子

实际上 IaC 这个概念的出现已经很久了，所以写篇水文来简单聊聊 IaC 的过去，现在，和将来 IaC 的过去实际上 IaC 的历史其实足够悠久。首先来看一下 IaC 的核心的特征 最终的产物是 machine readable 的的产物。可能是一份代码，也可能是一份配制文件 基于 machine readable 的产物，可以进一步依赖已有的 VCS 系统（SVN，Git）等做版本管理 基于 machine readable 的产物，可以进一步依赖已有的 CI/CD 系统（Jenkins，Travis CI）等做持续集成/持续交付 状态的一致性，或者称为幂等性。即理论上来讲，基于同样一份 Code，同一套参数构建出的产物，其最终的行为应该是一致的 实际上通过 IaC 这样的一些核心特征，我们现在能明白 IaC 兴起的原因。IaC 实际上的兴起，大背景是在千禧年之后，互联网世界迭代的速度愈发的快速，这个时候传统的手工式的维护面临着几个问题 交互式变更所引入的人的因素太大，导致了变更的不可控性 人工变更面对愈发快速的 Infra 迭代力有不逮 交互式的变更导致管控的难做，让版本控 ...