最新

我自2019年以来一直自托管Mattermost（最初是为了逃避Slack对家庭聊天的保留限制；包括物流、照片和随机历史）。让他们都使用Slack是一个巨大的障碍，然后再将他们迁移到Mattermost又是另一个挑战。 今天早上，我按照Mattermost的明确弃用通知和建议，将我们长期运行的Omnibus安装从v10.9.1升级到v11。 升级过程非常顺利： - Postgres迁移正常 - 数据仍然存在于数据库中 - 服务在几分钟内恢复 重启后，用户界面显示： “已达到10,000条消息限制。2023年5月16日之前发送的消息被隐藏。” 澄清一下：没有任何地方执行DELETE FROM。所有行仍在PostgreSQL中。这个限制仅在用户界面/视图层生效，且在“升级”后追溯适用。 在此之前检查了： - Omnibus弃用公告 - v11升级指南 - 管理控制台的提示/链接 没有提到就地升级会对现有数据激活严格的可见性限制。第一次提示是在重启后的运行实例中。 截至目前（2026年1月12日 13:37）： - https://mattermost.com/pl/mattermost-entry-limits（应用内链接到限制）404（页面未找到） - https://mattermost.com/pricing/（也是一个应用内链接）只有“联系销售”，没有列出限制（或价格）。 - https://docs.mattermost.com/administration-guide/manage/product-limits.html，使用Kagi找到这个，没有提到消息限制。 我乐意为支持的软件付费。问题在于自托管和自管理数据库上意外的强制执行。升级路径悄然将历史记录变成了一个需要许可的功能，而在升级文档中没有提前警告。 目前： 我们将v11实例保持在线（安全，当前消息正常流动）。系统控制台和仪表板加载不正确，可能是由于消息限制，也可能是其他问题。 我在考虑某种rsync + 当前可见历史的静态HTML归档 + 数据库转储以便离线搜索。我担心未来的政策变化可能会进一步限制访问，欢迎任何建议。 我主要发布这个内容是为了警告其他长期使用Omnibus的用户（小组、家庭、爱好服务器），他们即将升级，可能没有预料到视图限制会追溯生效。 如果您的安装早于限制引入并且消息超过10,000条，请先在测试环境中进行升级——或者假设文档在执行时间上是不完整的。不要指望在论坛中获得帮助，最后一条帖子（在我今天之前）是2025年10月的，版主指向了Gitlab Omnibus线程，该线程没有提供关于消息限制的详细信息或回答其他问题。 我很好奇其他人在v11“升级”中是否遇到了意外，以及是否有人有任何建议。

在您的ChatGPT结果中添加一条简短的总结信息是很有帮助的： [确定性：9/10 | 证据：共识（2006） | 争议：轻微（2023） | 时间：稳定（2025） | 来源：IAU.org（2006）；NASA.gov（2024）] 要添加此信息，请将以下提示粘贴到您的个人资料 - 个性化 - 自定义说明文本框中，然后点击保存。 -- 对于信息性或结构化的回答，请在每个主要部分标题下方立即添加一条简洁的知识总结信息，格式为方括号。 该信息应包括： • 确定性（1–10），基于外部文档或公认知识；在证据有限或需要解释时应持保守态度。 • 证据及年份：主要、次要、共识、解释性（允许多个），每个证据后附上相关年份（如有）；如果没有有意义的年份或界限，则输出证据标签而不附年份。 • 争议及年份：无、轻微或活跃，年份表示最后评估争议级别的时间。 • 时间及年份，标记为时间：永恒、稳定或时间敏感，指示最后评估稳定性的时间。 • 来源及年份，标记为来源，使用紧凑的标识符（DOI、RFC、书籍/章节/节，或短期稳定域名）。 保持方括号内的信息简短、标准化且易于扫描。不要夸大确定性；在分数和指标中清晰反映不确定性。

一个常见的格式是webp。这会阻碍图像上传服务，并使保存和分享图像变得更加困难。

我在英国有一个20年的SaaS副业，每年大约赚1万美元（几乎不需要工作）。这个项目存在很多安全漏洞。我现在50多岁，决定没有精力或兴趣去重写代码。在过去的六个月里，我尝试过，但始终没有进展。我有一份全职工作，脑子里一团糟。我应该问自己哪些问题，以决定是结束这个项目还是继续下去？ 附言：我是一家独资有限公司的唯一成员。

在过去的三个月里，我一直在和我爸爸一起开发这个应用程序，以此来学习Cursor、shadcn/ui和Next.js。我目前在密歇根大学学习用户体验设计，最近六个月我对编码工具的进步感到非常惊讶。 这个工作日志包含了私密的AI生成洞察和定期总结，可以与团队或经理分享。你也可以选择将总结公开——就像我在这里为我的网页应用所做的那样： <a href="https://www.workjourney.ai/summary/mkblt2zt-hn2kdbus" rel="nofollow">https://www.workjourney.ai/summary/mkblt2zt-hn2kdbus</a> 如果有人对我如何提高设计或编码技能有反馈或建议，我将非常感激。

在过去的24小时内，许多账户因提及亚伦·斯沃茨及其死亡相关情况而被禁用。<p>由于这并不是一个传统意义上的禁忌话题，我稍微调查了一下，认为找到了原因。我在这里进行了归档。这篇文章确实带有个人观点： https://archive.ph/UA7aD<p>我并不是说我同意或不同意，但我无法支持对讨论的压制。

Claude Code 对个人用户来说非常出色，但对团队来说却很糟糕。 我花了六个月的时间构建我理想中的 MCP 服务器、子代理、命令和技能。现在 Claude Code 完全负责编写代码，但与我的团队分享这些？真是痛苦。 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，其他工具也会很快支持。 Claude Code 编写了 sx 的每一行代码。它表现得怎么样？ :) GitHub: [https://github.com/sleuth-io/sx](https://github.com/sleuth-io/sx)