最新

自从 2019 年以来，我就开始自托管 Mattermost（最初是为了摆脱 Slack 对家庭聊天的存储限制；后勤、照片、随机历史记录）。把他们都转移到 Slack 上是一个巨大的障碍，然后又把他们转移到 Mattermost。 今天早上，我按照 Mattermost 明确的弃用通知[0]和切换到标准二进制/Docker/k8s/etc 部署的建议，将我们长期运行的 Omnibus 安装从 v10.9.1 升级到 v11。 升级过程很顺利： Postgres 迁移顺利 数据仍然存在于数据库中 服务在几分钟内恢复 重启后，UI 显示： “已达到 10,000 条消息的限制。2023 年 5 月 16 日之前发送的消息已隐藏。” 澄清：没有删除任何内容。所有行仍然在 PostgreSQL 中。该限制仅适用于 UI/视图层，在“升级”后追溯应用。 事先检查过： - Omnibus 弃用公告 [0] - v11 升级指南 [4] - 管理员控制台提示/链接 没有提到就地升级会激活对现有数据的硬性可见性限制。第一个迹象是重启后的运行实例。 目前（截至 2026-01-12_1337）： - https://mattermost.com/pl/mattermost-entry-limits（应用内链接到限制）[1] 404 错误（页面未找到） - https://mattermost.com/pricing/（也是一个应用内链接）[2] 只有“联系销售”，没有列出限制（或价格）。 - https://docs.mattermost.com/administration-guide/manage/product-limits.html [3]，使用 Kagi 找到这个，没有提到消息限制 我很乐意为受支持的软件付费。摩擦在于对自托管 + 自管理的数据库的意外强制执行。升级路径悄悄地将历史记录变成了许可功能，而升级文档中没有事先警告。 目前： 我们保留了 v11 实例（安全，当前消息正常流动）。系统控制台和仪表板无法正确加载，可能是由于消息限制，也可能是由于其他问题。 我正在考虑某种 rsync + 当前可见历史记录的静态 HTML 存档 + 用于离线搜索的数据库转储。我担心未来的策略变化可能会进一步限制访问，并且希望得到建议。 发布主要是为了警告其他即将升级的长期 Omnibus 用户（小团体、家庭、业余服务器），他们可能没有预料到视图限制会追溯生效。 如果您的安装早于限制引入，并且有超过 10k 条消息，请先在暂存环境中测试升级——或者假设文档在强制执行时间方面不完整。不要指望在论坛 [5] 中获得帮助，今天的最后一篇文章（在我今天的文章之前）是 2025 年 10 月发布的，版主将帖子指向了 Gitlab Omnibus 线程，该线程没有提供关于消息限制的详细信息，也没有回答其他问题。 想知道其他人是否在 v11“升级”中遇到了意外情况，以及是否有人有任何建议。 [0] https://github.com/mattermost/mattermost-omnibus [1] https://mattermost.com/pl/mattermost-entry-limits [2] https://mattermost.com/pricing/ [3] https://docs.mattermost.com/administration-guide/manage/product-limits.html [4] https://docs.mattermost.com/deployment-guide/server/deploy-linux.html [5] https://forum.mattermost.com/t/clarification-needed-for-the-upgrade-to-v11/25344

在你的ChatGPT结果中添加一个简短的总结行会很有帮助：<p>[确定性：9/10 | 证据：共识 (2006) | 争议：轻微 (2023) | 时间：稳定 (2025) | 来源：IAU.org (2006)；NASA.gov (2024)]<p>要添加它，请将以下提示粘贴到你的“个人资料 - 个性化 - 自定义说明”文本区域中，然后按“保存” --<p>对于信息性或结构化的答案，在每个主要章节标题下方立即添加一个紧凑的认知总结行，用方括号括起来。<p>该行应包括： • 确定性（1–10），基于外部文档或公认的知识；当证据有限或需要解释时，请保守评估。 • 证据，带年份：主要、次要、共识、解释性（允许多个），每个证据后用括号标注一个相关的年份；如果没有有意义的年份或界限，则输出证据标签，不带年份。 • 争议，带年份：无、轻微或活跃，年份表示上次评估争议级别的时间。 • 时间，带年份，标记为时间：永恒、稳定或有时效性，表明上次评估稳定性是什么时候。 • 来源，带年份，标记为来源，使用简短的标识符（DOI、RFC、书籍/章节/诗句或简短的稳定域名）。 保持括号内的行简短、标准化且易于扫描。不要夸大确定性；在评分和指标中清晰地反映不确定性。

一个常见的问题是 WebP 格式。这阻碍了图片上传服务，也使得保存和分享图片变得更加困难。

我在英国有一个做了 20 年的 SaaS 副业，每年能赚 1 万美元左右（几乎没怎么花精力维护）。但它现在是个安全漏洞的噩梦。我已经 50 多岁了，决定没精力也没兴趣重写代码了。过去 6 个月我试着这么做了，但一直没进展。我还有一份全职工作，现在脑子一团浆糊。我应该问自己哪些问题，来决定是放弃它还是继续维持？ PS. 我是一家一人有限公司。

在过去的三个月里，我一直在和我的父亲一起开发这款应用，以此来学习 Cursor、shadcn/ui 和 Next.js。我目前在密歇根大学学习用户体验设计，我对过去六个月里氛围编码工具的进步感到非常印象深刻。 这篇工作日志包括私人的 AI 生成的见解，以及可以与您的团队或经理分享的定时摘要。您也可以选择公开摘要——就像我在这里为这个 Web 应用所做的那样： <a href="https://www.workjourney.ai/summary/mkblt2zt-hn2kdbus" rel="nofollow">https://www.workjourney.ai/summary/mkblt2zt-hn2kdbus</a> 如果有人对如何提高我的设计或编码技能有反馈或建议，我将不胜感激。

过去 24 小时内，大量账号因提及亚伦·斯沃茨及其死亡相关情况而被封禁。<p>由于这并非传统意义上的禁忌话题，我稍微调查了一下，相信我找到了原因。我在这里进行了存档。这绝对是一篇带有强烈个人观点的文章：https:&#x2F;&#x2F;archive.ph&#x2F;UA7aD<p>我并没有说我同意或不同意，但我无法接受对讨论的压制。

Claude Code 对于个人来说很棒，但对于团队来说却很糟糕。 我花了过去六个月的时间构建了我完美的 MCP 服务器、子代理、命令和技能组合。现在 Claude Code 编写了 100% 的代码，但与我的团队分享这些代码？痛苦不堪。 1. 博客文章和研讨会不起作用（并且无法扩展） 2. 将工具提交到 N 个代码库意味着 N 个 PR。一个工具改变了？再来 N 个 PR。 3. 相同的工具，每个 AI 助手使用不同的文件或文件夹；并非每个人都使用 Claude Code 这就像回到了 1999 年；通过 FTP 将文件上传到生产环境，并使用“.bak”后缀进行版本控制。 所以我构建了 sx。它是您团队的 Claude Code（和其他工具）的私有 NPM。 工作原理： ``` # 将一个 git 仓库设置为您的金库 sx init --type git git@github.com:my-org/sx-vault.git # 添加一个本地技能、命令、mcp 等 sx add my-skill ``` 当您的团队安装 sx 时，他们会自动获得适用于正确项目的正确版本控制的工具（也适用于单体仓库！）。不再需要 PR，不再需要过时的文档，不再需要冗长的线下交流。目前支持 Claude Code 和 Cursor。其他工具即将推出。 sx 的每一行代码都是 Claude Code 编写的。它做得怎么样？:) GitHub: [https://github.com/sleuth-io/sx](https://github.com/sleuth-io/sx)