最新

我自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多岁，决定没有精力或兴趣去重写代码。在过去的六个月里，我尝试过，但始终没有进展。我有一份全职工作，脑子里一团糟。我应该问自己哪些问题，以决定是结束这个项目还是继续下去？ 附言：我是一家独资有限公司的唯一成员。