taoky

Results 129 comments of taoky

@XuehaiPan any interest in investigating this issue? This bug seems to affect all homebrew bottles mirrors.

另外如果要上线服务,还需要申请一个新的三级域名(比如说 registry.mirrors.ustc.edu.cn?)。因为尽管 [Docker Registry 支持 prefix](https://docs.docker.com/registry/configuration/#http:~:text=If%20the%20server%20does%20not%20run,such%20as%20in%20the%20example%20%2Fpath%2F),[`docker pull` 命令目前却不支持](https://github.com/moby/moby/issues/7067)。 此外还有一个问题是是否打开 `--scope` 选项。如果启用的话,获取镜像的命令就类似于: ``` docker pull example.com/registry.hub.docker.com/library/hello-world:latest ``` 这样不会出现可能的命名冲突,但是看起来比较麻烦,并且没有办法作为 Docker 的 `registry-mirrors` 的参数。 如果不启用,命令就是: ``` docker pull example.com/library/hello-world:latest ```

把 YAML 配置提出来了。另外因为 `skopeo sync` 的 `--all` 参数不在最新的稳定 releases 里面,所以如果需要同步非 Linux 和非 x86 的容器的话,还要等到更新的版本发布。

> 或者设置一个 exec command 也行,比 jinja 更灵活 最好有办法限制这个属性只能做纯计算,否则感觉会有点危险。

现有代码里面最复杂的应该就是 rclone 了: ```go case "rclone": remoteType := envs["RCLONE_CONFIG_REMOTE_TYPE"] path := envs["RCLONE_PATH"] domain := "" if remoteType == "swift" { domain = envs["RCLONE_SWIFT_STORAGE_URL"] + "/" } else if remoteType ==...

现在 planet 内容还是太少了,而且很久都没更新了。 我的想法是,我们可以让大家提供自己的 RSS 源,然后我们**手动**来挑文章、审稿。这样的话: > 1. 安全性不好:一旦某个文章有攻击代码,这个代码很容易被扩散到整个 LUG 博客的读者群体。 > 2. 审核不便:现有的新闻聚合程序无法进行审核。无法保证文章整体质量。 > 3. 呈现效果不佳:不同的博客使用不同的风格主题,且过滤不安全代码后也容易出现风格不一致的情况。 > 4. 文章的修改与删除:修改没有明确标识,删除后则「人间蒸发」,不能由 LUG 这边很好地控制。 > 5. 版权与授权不明确,需要 LUG 方面逐一确认。 前四个问题可以得到缓解,因为我的想法是初期我们尽可能在保证质量的情况下先增加内容的数量,像审核平台之类的可以以后再说。 我个人还是很希望 planet...

昨天晚上 LUG 活跃成员开了一次会,讨论了关于 [planet](https://planet.ustclug.org) 和 [blogs](https://github.com/ustclug/blogs) 等的事项,结果如下: - [黑板报](https://servers.ustclug.org/)作为服务通知的功能不变。 - 推送渠道(如 QQ、微信公众号等)推送活动通知,同学投稿的文章,和我们发布的技术文章。 - Planets 是我们自己的技术博客,接受征文(我们觉得有意思的),加上 blogs 列表作为友链。也接受同学的推送。 - Blogs 整合同学们的博客(作为列表)。

咨询了一下 NJU mirrors,如果只同步 rv64 的话目前占用的空间是 121G。

尽管我不太同意 @iBug 的理由,但是一个现状是,和 https://github.com/tuna/issues/issues/1728 类似,我们的剩余空间也不太够在保证 IO 性能的前提下添加新的镜像了。

> 个人认为如果未来有足够多的用户需要,当设备条件合适时可以考虑增加。毕竟镜像站存在的初衷是为了方便用户使用开源软件,对上游的贡献或是商业化程度并不是决定性因素。将其改为 needvote 标签或许更合适一些 OK,我和 @iBug 讨论了一下,先 reopen + needvote 吧。