“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
一个令人难以置信的演示：当 Sun 的“新品”其实是我自己的开源脚本
Sun Microsystems 在一次内部演示中展示的“全新 DTrace 产品”，实际上全部由作者 Brendan Gregg 自己此前开源的 DTraceToolkit 脚本拼凑而成——而 Sun 的工程师不仅不知道作者是谁，还删除了脚本中的原作者署名。
一个令人难以置信的演示
原文链接：An Unbelievable Demo
作者：Brendan Gregg（系统性能专家，DTrace 工具集作者，后加入 Netflix/Intel）
写在前面
这是 Brendan Gregg 在 2021 年回忆自己在 2005 年亲身经历的一个故事——一个用他自己的话说，“你编都编不出来”的开源世界真实事件。它关乎身份错认、代码所有权、大公司内部的无知与傲慢，以及一个独立顾问在一个“飓风眼”里的奇特遭遇。
如果你做过开源软件，或者在大公司里做过内部工具，你会发现这个故事里的每一个细节都既荒诞又真实——尤其是当一个项目里充满了别人的代码，而项目负责人却根本不知道这些代码来自哪里时会发生什么。
背景：我在 DTrace 的飓风眼里
时间回到 2005 年。Brendan 当时是澳大利亚悉尼的一位独立性能顾问——专门帮人做系统性能分析和调优。当时 Sun Microsystems 刚刚发布了 DTrace，一个能够动态探查和跟踪所有软件行为的工具，这对于性能分析师来说简直就像获得了“X 光视力”一样。
DTrace 是如此强大，以至于 Brendan 几乎把所有精力都投入到了研究和开发基于 DTrace 的工具上。他写了大量脚本，并且把它们开源——这就是后来广为人知的 DTraceToolkit。
但奇怪的事情来了：Brendan 发现，自己一个人产出的 DTrace 工具，竟然比 Sun 公司内部整个团队公开发布的工具还要多。一个正常的世界级科技公司，应该拥有比一个独立顾问更多的资源和工程师——除非他们正在忙着做某个“内部项目”。
神秘的 VIP：世界巡演的 DTrace 专家
因为在给 Sun 做培训和咨询，Brendan 有时会被邀请参加 Sun 的客户会议或内部活动。某天他接到一个消息：有一位来自美国的重要人物（Very Important Person）会到访悉尼办公室，据说这位是 Sun 内部的 DTrace 专家兼开发者，正在做全球巡演，展示 Sun 的新产品——一个基于 DTrace 的工具集。
听到这个消息，Brendan 明白过来了：这一定就是那个“内部项目”！毕竟，Sun 不可能放着这么多 DTrace 人才不用——原来他们是在准备一个大新闻。Brendan 当时还很期待：“这种量级的发布，多半会把我之前的工作比下去。”
然而见面之后，一切并没有想象中那么隆重。这位 VIP 穿着商务休闲装，带着浓重的美国口音，显然因为长时间的巡演显得有些疲惫。他刚刚从南非和新西兰赶过来，接下来还要去更多城市，走完澳洲还有其他洲。
当时在场的还有两位 Sun 澳大利亚分部的员工。其中一位用一种典型澳洲式低调的口吻介绍 Brendan：“这位是 Brendan，他给我们上过一些课，也搞过一些 DTrace 的东西。”
这种“话越少越好”的风格在澳洲算是常态，但 Brendan 心里明白：在美国文化里，自我介绍讲究“有分量”，而在澳大利亚，你这么压低自己可能会让对方觉得你确实没什么本事。
当年的澳大利亚工程师有个尴尬处境：2005 年，澳洲几乎没有真正的研发类工程岗位——Sun 澳大利亚这边全是技术支持岗，连一个开发岗都没有。美国科技巨头也未大规模进驻。所以那会儿在澳大利亚，你可能会看到极其厉害的工程师窝在技术支持、售前甚至更边缘的岗位上，这并不是因为他们不够强，而是因为没地方去。
Brendan 试着多介绍自己一点：“我写过 DTraceToolkit。”
然而，那位 DTrace 专家并没有任何反应。他不知道 Brendan 的名字，也没听说过 DTraceToolkit——对他来说，Brendan 就是一个“偶然参与会议的路人甲”。
显然，他不是来看 Brendan 炫技的。他更赶时间。
演示开始：Sun 的“大新闻”让我大失所望
那位专家（姑且称他为 VIP 工程师）给 Brendan 做了一次快速的产品演示。
嗯，准确说，这是一个 Sun 大型 GUI 套件的“插件包”——加载完成后，你可以通过双击图标来运行一系列 DTrace 工具。输出的原始文本会显示在独立窗口中，或者以折线图呈现。
Brendan 看到这里心凉了半截：GUI 本身早已具备这些功能——显示文本或画图，根本不新鲜。所谓“新产品”，其实只是往已有的 GUI 上加了一套预设工具脚本而已，而他自己的 DTraceToolkit 里已经实现了类似甚至更丰富的功能。
VIP 工程师又做了一段销售话术，说这套工具提供了多么“新”“惊人”的观测能力——显然这套台词他已经讲过很多次了，用来打动客户。但在 Brendan 这样一个已经写过类似工具的人面前，这段话反而显得空洞。
更尴尬的场面出现了。Brendan 直接说：“这些脚本我都写过——我自己早就实现过类似功能了。”
对方虽然没有说出口，但脸上的表情显然写着：“这话谁信？”
——一个来自市值十亿美元级美国公司、正在做全球巡演的 DTrace 专家，对一个“路边冒出来的澳洲工程师”表示高度怀疑，完全合理。
Socket 跟踪：我曾经未完成的工具
Brendan 没有放弃，他开始在 GUI 图标里寻找真正感兴趣的东西。其中有一个让他非常在意：Socket I/O 跟踪工具。
为什么在意？因为 Brendan 在 2004 年就尝试写过这样一个工具（socketsnoop.d），并且开源发布过——但那个工具从未完工：
- Brendan 当时拿不到内核源代码，只能靠“黑盒分析”硬猜。
- 它对大多数 TCP 流量都能工作，但对某些流量类型不适用。
- 他在脚本注释里注明了这一点，也因此始终没有把它纳入 DTraceToolkit，因为自认为还不成熟。
换句话说：这是一个他没完成的半成品。
而现在，Sun 这位专家手里有一个可能就是“同一目标、但打磨完整”的版本——Sun 员工能直接读到内核源码，照着写肯定能补全。Brendan 当然想看。
"Can I see the socket I/O script?"
他打开了一个终端。
VIP 工程师先是一惊——那表情像是“你怎么能看底层”！然后立刻反应过来，这其实也是个卖点：“当然可以——而且你甚至还可以往 GUI 里添加更多工具。”他停了一下，补了一句：“如果你有的话。”
——那语气分明是在说：“你这种街头散修能有什么正经工具。”
不可能：屏幕上的代码是我写的
VIP 工程师给了 Brendan 一个在文件系统里查找工具的路径。在终端里翻了一会儿之后，Brendan 找到了目录，里面全是这位“专家”在演示中用到的脚本。
工具的名字看起来极其熟悉，其中一个就叫 socketsnoop.d。
一种不祥的预感油然而生。
“不会吧。”
Brendan 立即执行了 cat（打印文件内容）。
屏幕上出现的，是他自己的脚本。
每一行都对得上——包括那些年他自己都觉得“有点怪”的编码方式，比如 PFORMAT 的使用（那是 defaultargs 之前的写法），以及在脚本中只有他自己能看懂的注释、特殊变量名和代码风格。
这就是那个他一年前被迫用“黑盒”方式拼命写出来的、连他自己都觉得没完成的半成品脚本。
Brendan 当时看到的，就是自己写过的代码，一字不差。
他又查看了其他几个工具，结果一模一样——全部都是他写的脚本。
这个VIP在世界各国巡回展演的“新潮 Sun 产品”，内核不过是他个人开源的一堆旧工具，被重新包装进了 GUI。
Brendan 的眼睛瞪得老大，下巴基本已经掉在地上了。
而对方，依然用一种“你到底在胡说什么”的神情看着他。
无法证明的证据：我的名字被删除了
为了让质疑荡然无存，Brendan 直接使用 grep 在这位专家的全部工具目录里搜索自己名字。
他的每一个脚本，头部注释里都会写：
Author: Brendan Gregg
就像所有正经开源项目一样。
这次全盘搜索的结果是：零命中。
他的名字在这个产品中被彻底清除了。
没有“作者：Brendan Gregg”——没有任何踪迹留下。对于一个开源于澳大利亚个人项目的代码，这绝不可能是无心之举；这是一次有意的“署名清洗”。也许是为了让这个产品显得像 Sun 的“原创”，也许是为了避免不必要的追溯，但这些代码的作者，被完完全全从世界面前抹去了。
技术背景解释：为什么 Brendan 能认出自己的“笔迹”？
从这个故事，普通读者可能最不解的一个问题是：代码还能被认出来“这的确是我写的”？
答案是肯定的，这是一层“技术笔迹”。Brendan 在 2005 年写的 DTrace 脚本里，有几处特征极其鲜明：
- 使用
PFORMAT而非defaultargs：这两个都用于声明脚本参数，但PFORMAT是老式写法。2005 年前的 DTrace 脚本是各自独立的 shell 风格式的处理方式，之后 DTrace 才支持defaultargs（默认参数）。Brendan 用旧式语法，是因为他写这批脚本时，DTrace 的新特性尚未发布。这相当于每个人敲代码用了自己固定的缩进方式、命名习惯和防御性检查。 - 注释和个人笔记：他会在脚本里写下自己的专有缩写、TODO、备注等。外人即使看了也不会明白其中深意，但他自己能够一眼认出。
- 未完成的 bug 风格：比如 socketsnoop.d 中他对某些 TCP 回环 / 非回环流量有判断逻辑，但因为无法查看内核源码，只能靠实测环境反复测试来猜测。这套判断逻辑里带着一种非常“个人化”的补丁痕迹。
这些类似于“文本指纹”的元素，构成了一种可以无损识别身份的个人代码风格。
另外，从工程流程上看（放到今天完全一样）：
- Brendan 把不完整工具以开源方式发布（2004）
- 某些人或组织下载它、剥离作者信息、封装到商业 GUI（2005）
- 然后作为“新产品”公开展示
本质上，这是一个“开源代码被商业收编并去除版权”的经典案例——而且此事发生于近二十年前，说明这一现象早已有之。
讽刺与转折
故事到这不是高潮。在那次会面中，真正荒诞的地方在于：那位专家自始至终没打算相信 Brendan。
“这确实是我写的代码。” Brendan 说。
“嗯，当然。”（不，他压根没信。）
真正的荒唐点是：Brendan 无法证明什么。说是他写的，没有任何后台背书；Sun 员工、市场包装，乃至整个世界所能看到的都是——一个来自澳大利亚的“独立顾问”，胆敢声称 Sun Microsystems 的官方演示工具来自他的手笔。
如果不是 Brendan 自己在 GitHub / 个人主页有存档，几乎没有人会知道这些工具的真实来历。
但这则故事最深刻的讽刺可能是：Brendan 一直以为 Sun 内部有一个他看不到的“天才项目组”，日夜打磨着 DTrace 工具的终局形态。到头来，那个“神秘项目”根本就是个空壳，而且里头的每一份重量，都是他自己扛上去的。
也就是说：他可以顺手自嘲一句——在整个 DTrace 早期生态里，最活跃的“Sun 内部人”可能从未存在过；真正推出最多工具的，是一个从未领取 Sun 工牌的外部顾问。
这个故事为什么在 2021 年再次爆火？
这篇文章发布于 Brendan Gregg 的个人博客（2021 年 6 月），后来于 HN 上引起大量讨论（热度 2339 分，463 条评论）。人们之所以如此热衷，是因为这件事对技术人员来说几乎击中了所有痛点：
- 开源许可：如果你把自己的代码放在网上，而公司 A 拿去直接作为产品核心并在世界里兜售——就算他们不赚钱，至少也应该保留你的名字，这是开源许可（比如 GPL/BSD）最基本的底线。
- 公司里“大新闻”的真实面貌：很多公司/团队所谓的“重大创新”，往往不过是一锅剩饭。这个故事揭示了技术世界里“营销包装 vs 真实工程”之间的巨大落差。
- 个人身份与工程价值的不匹配：一个写出核心内容的人在正式场合被当作路人，这大概也是最极致的“社畜瞬间”了。
- DTrace 当年刚发布：DTrace 是 Solaris/ illumos 等系统中的重要观测工具，它提供了动态跟踪（dynamic tracing) 的能力，程序员可以在生产环境中探测任意内核/应用函数，且损耗极低。Brendan Gregg 后来的 DTraceToolkit 和之后的多本经典书籍（如 BPF Performance Tools, Systems Performance, Linux Perf），都是他在这个生态中深耕多年的结果。对 DTrace 历史稍加了解，就会理解这次事件的“行业级讽刺”。
对今天的启示
即便到今天，类似故事也不断在开源界上演。许多在开源软件上建立商业产品的大厂，经常因为内部人员“不了解上游”而重复造轮子、或是没保持归属信息。
这件事也给了独立开发者一个提醒：
- 永远要在源代码里留下清晰的作者元数据（头部注释），这是最容易被剔除但最基础的“所有权标识”。
- 永远保存你自己的工作副本，无论是否有版本控制系统（2005 年 Brendan 应该就是用邮件/移动硬盘来维护自己的历史版本，所以今天他还能证明自己写过这段脚本）。
- 不要盲目迷信“公司庞大即创新”：真正决定一个工具深浅的，是背后写代码的人，不是贴了多少层品牌标签。
当然，这个故事也有它的另一面：能被别人拿去，某种程度上说明你写的东西真的有用。 只是，如果你根本不知道对方核心产品就是你的代码时，那种感觉，可能远谈不上荣幸。
最后一句
Brendan 在文章末尾写道：
我把其他工具都打印出来，它们全都是我的。—— 他的下巴在地上，而对面那位专家的眼神显然在说：你个澳洲人少来碰瓷。
这是一个关于代码所有权、对大公司叙事的祛魅、以及“眼见即为真实”的开源界经典事故。若再把后来 Brendan 加入 Netflix 领导性能工程团队、推动 eBPF/火焰图在全球普及的背景叠加起来，这个“澳大利亚小角色”成色几何，历史已有答案。