差不多得了。你那几台移动设备天天待在同一个位置，想知道你是谁太容易了

3000 块钱够买 40T 存储了

额，时钟也要花钱找人做啊。这种应用能不能收回本？
放十年前生态收费都费劲，现在时钟应用还有市场？

我从开发者看其实是不介意的。作为作者闭源可能只是为了保护知识产权，发出来卖到钱就达到原始的目的了。
产品流到外网后，逆向这个事情本来就是不可避免的，你能逆出来提个 PR 之类的可以直接合并的，作为开发者能白嫖其实挺开心的。可以直接发邮件带附件试试，如果沟通出问题错不在你。

不过我仔细看了你的描述，应该只是改了某些语句，可能只有几行，这种直接跟作者说一声就行了，形成原因、解决方法在 issue 里说清楚就可以了，连 PR 都没必要提。

AI 版的“只缺一个程序员了”

病理性惊恐发作

这不就是经典 udp 反射 dos 。你机器中菜花了。抹掉重装，不要乱装不清楚的软件。

@julyclyde 那只能说 RTFM

@julyclyde 我觉得合适的手段就是在 README 里写清楚用哪几个参数或者哪个目录来配置/交换数据。这样已经将环境复杂性收缩到底了，因为归根结底特化使用者需要用 kv 一类的数据来指定配置内容。

容器是用来解决环境配置问题的，但不是魔法棒。easy 也需要用户理解。

@julyclyde 如果没有可配置项，是希望镜像作者/容器自启时猜你想如何特化容器吗？

compose 的主要优势在于记录了容器配置细节，而不是把容器启动配置写在随风飘散的命令行里。

另外 compose 相对 cli 在概念上可以将多个容器组合成一套服务，同一个配置文件中管理，相对零散的命令行更加有条理。

至于你从 cli 里看到底层加了什么东西，我只能说，眼不见为净，不直接接触就行了。如果真的介意，compose 配置里也可以改变此表现。

80 / 443 可以绕 ssh 审计。没有找到其它的端口可用，只能牺牲掉 80 了

难绷。开发就开发，别搞得像自己给自己写传记还要发出来给大家膜拜一样

@infinity2symbol 取决于公司合同具体条款约定

为什么不问问神奇的 gpt 呢