search

MetaCubeX / mihomo

A simple Python Pydantic model for Honkai: Star Rail parsed data from the Mihomo API.
https://wiki.metacubex.one
MIT License
15.74k stars 2.57k forks source link

[Feature] 关于龙架构二进制文件名的建议 #1141

Open LinuxResearcher opened 6 months ago

LinuxResearcher commented 6 months ago

Verify steps

Description

现在mihomo已经同时支持龙架构的新世界和旧世界并且提供二进制了，但是二进制的文件名不是很优雅。比如新世界的deb包叫 mihomo-linux-loong64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loong64-abi1-v1.18.2.deb ，比其他架构多出来个abi1和abi2，丑，并且在编译clash-verge-rev的时候会带来一些问题，需要改代码。所以建议改名。 目前，新世界和旧世界发行版的命名规则是有不同的，新世界的架构名为loong64，旧世界为loongarch64。 按照这个规则，建议把旧世界文件名 mihomo-linux-loong64-abi1-v1.18.2.deb 改为 mihomo-linux-loongarch64-v1.18.2.deb ，把新世界文件名 mihomo-linux-loong64-abi2-v1.18.2.deb 改为 mihomo-linux-loong64-v1.18.2.deb 。这样，就和其他架构统一了，玩龙芯的也能一眼看出来哪个是新世界的二进制，哪个是旧世界的二进制。

Possible Solution

建议把旧世界文件名 mihomo-linux-loong64-abi1-v1.18.2.deb 改为 mihomo-linux-loongarch64-v1.18.2.deb ，把新世界文件名 mihomo-linux-loong64-abi2-v1.18.2.deb 改为 mihomo-linux-loong64-v1.18.2.deb 。 把旧世界文件名 mihomo-linux-loong64-abi1-alpha-0b4662e.deb 改为 mihomo-linux-loongarch64-alpha-0b4662e.deb ，把新世界文件名 mihomo-linux-loong64-abi2-alpha-0b4662e.gz 改为 mihomo-linux-loong64-alpha-0b4662e.gz 。

xishang0128 commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

LinuxResearcher commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

ToKingl commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

ToKingl commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

大大，可以考虑一下按照龙芯官方的loongarch64-abi1和loongarch64-abi2命名法进行命名吗？

LinuxResearcher commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。

ToKingl commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。

这倒是，目前只有 AOSC OS 和 RPM 系均采用全称 loongarch64 的命名，其他的则是采用 loong 或 loong64 命名

ToKingl commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。

有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？

LinuxResearcher commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。

有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？

你这真是不成熟的想法。为什么一定要叫loongarch64？因为loongnix这样叫吗？实际上，龙架构的架构名是龙，也就是loong，最多在loong后面加上32或者64表示位数。叫loongarch64，第一太长，第二表达上有重复（龙架构架构）。这种重复的表达不觉得很傻屄吗？架构名后面带arch的只有arm（rpm系的aarch64），还仅限于rpm系，并且也对arm进行了缩写。哦，还有个ia64，是intel architecture的缩写，不过人家缩写了，当然现在这个架构已经没有了。现存的其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？ loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。

ToKingl commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。

有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？

你这真是不成熟的想法。为什么一定要叫loongarch64？因为loongnix这样叫吗？实际上，龙架构的架构名是龙，也就是loong，最多在loong后面加上32或者64表示位数。叫loongarch64，第一太长，第二表达上有重复（龙架构架构）。这种重复的表达不觉得很傻屄吗？架构名后面带arch的只有arm（rpm系的aarch64），还仅限于rpm系，并且也对arm进行了缩写。哦，还有个ia64，是intel architecture的缩写，不过人家缩写了，当然现在这个架构已经没有了。现存的其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？ loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。

但是已经有 loongson2f 与 loongson3 两个架构名了，再用 loong64 不会觉得……。

LinuxResearcher commented 6 months ago

@LinuxResearcher loongarch64和loong64的区分不够清晰,不如abi1/2

的确，abi1/2非常清晰。主要是龙架构旧世界的软件包架构名都是loongarch64，新架构都是loong64。关于这一点，龙芯用户是能区分的，其他用户无需关注。其他架构都不带abi1/2，龙架构的带着很不顺眼啊。

并不是所有的新世界架构名都是loong64，还有部分新世界的发行版依然采用龙芯官方的loongarch64的架构命名，怎么不说新世界的deb包叫 mihomo-linux-loongarch64-abi2-v1.18.2.deb ，旧世界的deb包叫 mihomo-linux-loongarch64-abi1-v1.18.2.deb😏

新世界叫loongarch64的只有AOSC OS一家，叫loong64是Debian的约定，其他发行版都遵守这个约定了。

有个不成熟的想法，能否把文件名用全称loongarch64-abi1/2来区分，然后在新世界中的control文件里把loong、loong64、loongarch64这几个架构名都同时加上呢？

你这真是不成熟的想法。为什么一定要叫loongarch64？因为loongnix这样叫吗？实际上，龙架构的架构名是龙，也就是loong，最多在loong后面加上32或者64表示位数。叫loongarch64，第一太长，第二表达上有重复（龙架构架构）。这种重复的表达不觉得很傻屄吗？架构名后面带arch的只有arm（rpm系的aarch64），还仅限于rpm系，并且也对arm进行了缩写。哦，还有个ia64，是intel architecture的缩写，不过人家缩写了，当然现在这个架构已经没有了。现存的其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？ loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。

但是已经有 loongson2f 与 loongson3 两个架构名了，再用 loong64 不会觉得……。

loongson2f是处理器的名字，loongson3也是，在gcc里面是cpu类型，不是软件包名里面的架构名。loongson2f的架构名是mipsel，loongson3是mips64el。

TurnOffNOD commented 6 months ago

这个命名规则，龙芯那边有官方文档来约束没？

LinuxResearcher commented 6 months ago

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。

不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch

ToKingl commented 6 months ago

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。

不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch

http://mirrors.tencent.com/loongson/install/ image

LinuxResearcher commented 6 months ago

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。 不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch

http://mirrors.tencent.com/loongson/install/ image

这个目录是刘工移植的龙芯2F安装方式，刘工自己打包的debian系统。这个loongarch64是刘工起的文件名，架构名还是loong64。不信你安装上去看看，里面的软件包是不是带loong64后缀。还有，这里的软件包全部来自http://ftp.ports.debian.org/debian-ports/pool-loong64/main/

TurnOffNOD commented 5 months ago

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。

不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch

官方不说话，那就一定会混乱了。

LinuxResearcher commented 5 months ago

这个命名规则，龙芯那边有官方文档来约束没？

目前没有，现在只有默认的做法，并且已经开始混乱了。 不过，可以确定的是，所有旧世界架构名都是loongarch64。而新世界这方面，debian是发行版的重要标准参考，debian是把架构名定为loong64的，已经进dpkg上游了。更早的gentoo也是loong64，龙芯官方的新世界发行版LoongArchLinux也是loong64。 https://wiki.debian.org/Ports/loong64 https://wiki.debian.org/LoongArch

官方不说话，那就一定会混乱了。

这个混乱，问题不大，因为发行版本来就是包不能互相安装的。但是，起码rpm和deb得分别对应起来。新世界的rpm都是loongarch64，好像rpm喜欢用cpu的架构名作为包架构名，并且喜欢和商标一致。

Kiri2002 commented 5 months ago

强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。

  1. loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。
  2. 旧世界将缓慢淘汰。
  3. mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。
  4. 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。
ToKingl commented 5 months ago

目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。

况且新旧世界的区分从来就不是用loong64和loongarch64进行区分，而是通过abi1/abi2进行区分，这点龙芯有说到过。

---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上10:35 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。

loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。

旧世界将缓慢淘汰。

mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。

许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

Kiri2002 commented 5 months ago

目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。 况且新旧世界的区分从来就不是用loong64和loongarch64进行区分，而是通过abi1/abi2进行区分，这点龙芯有说到过。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上10:35 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) 强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。 loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。 旧世界将缓慢淘汰。 mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

现在不是说，龙芯定啥标准，社区就怎么去干。

  1. 现在的既定事实是社区广泛支持loong64命名。
  2. 开源/自由软件社区主要就是为新世界打包的，是去适配新世界的。
  3. 用loong64的命名方案已经是主流的支持了，简洁优雅

如果非要辩论很久，完全可以考虑单独提供mihomo-linux-loong64-alpha-0b4662e.gz命名的包，和其他的并存。

明明是很容易能做到 简洁，优雅，一致的事情， 真不至于

Kiri2002 commented 5 months ago

补充一下，绝大多数的开源社区维护新世界包，没有采用abi1/abi2的命名规则，真没必要再弄一套小众规则了

ToKingl commented 5 months ago

跑开龙芯不谈是不是就有点过河拆桥卸磨杀驴了？那么龙芯定的标准还有什么意思？

---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上11:18 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。 况且新旧世界的区分从来就不是用loong64和loongarch64进行区分，而是通过abi1/abi2进行区分，这点龙芯有说到过。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上10:35 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) 强烈请求支持新世界的的命名： mihomo-linux-loong64-alpha-0b4662e.gz 如果需要保留abi的写法，可以单独添加一个上面名称的包。 loong64是主流的新世界叫法，毋庸置疑了。没有讨论的余地了。 旧世界将缓慢淘汰。 mihomo作为上游包，被下游依赖。小改动可能会影响很大，希望慎重，不要留下历史包袱和遗憾。 许多下游包遵循了默认的命名格式，抓mihomo。如（clash-verge） abi格式的抓不到，干脆先单独加个经典格式的loong64包，稳定下游，再慢慢讨论。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

现在不是说，龙芯定啥标准，社区就怎么去干。

现在的既定事实是社区广泛支持loong64命名。

开源/自由软件社区主要就是为新世界打包的，是去适配新世界的。

用loong64的命名方案已经是主流的支持了，简洁优雅

如果非要辩论很久，完全可以考虑单独提供mihomo-linux-loong64-alpha-0b4662e.gz命名的包，和其他的并存。

明明是很容易能做到 简洁，优雅，一致的事情， 真不至于

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

Kiri2002 commented 5 months ago

对于社区，龙芯的标准好，就采用，不好，就不采用。

对于龙芯： “只要你说的对，我们就改正，只要你说的对人民有好处，我们就照你说的办”

loong64已经是板上钉钉了，没有讨论余地了。 本来就是试错改错的过程，没必要一条路走到底

ToKingl commented 5 months ago

但是AOSC也还在使用loongarch64作为架构名，社区并不只有debian，这两个也都是根社区，并且使用AOSC的人也并不少

---原始邮件--- 发件人: @.> 发送时间: 2024年4月25日(周四) 晚上11:39 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

对于社区，龙芯的标准好，就采用，不好，就不采用。

对于龙芯： “只要你说的对，我们就改正，只要你说的对人民有好处，我们就照你说的办”

loong64已经是板上钉钉了，没有讨论余地了。 本来就是试错改错的过程，没必要一条路走到底

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

Kiri2002 commented 5 months ago

哥们呀，哥们

  1. 对于发行版： Arch系，debian系，Fedora，Geentoo, FreeBSD, Slackware 等都没惯着, 都用的loong64.
  2. 对于软件包，除了和gcc绑死的一些软件，绝大多数的软件都是loong64

求同存异，AOSC用loongarch64，这是极少数的例子。不至于打破现有的共识啊！

Kiri2002 commented 5 months ago

将心比心，AOSC用户喜欢用loongarch64, 那我Arch用户也同样喜欢loong64喜欢的不得了。 意见不同是正常的啊，但要发展，要求同存异啊哥们。 已经有既定的事实了，主流社区已经焊死在loong64了，至于再搅一次吗

ziqi-cn commented 5 months ago

目前命名方式造成的主要问题是编译clash-verge-rev的时候抓不到包，无论是abi1/2的命名方式还是loong64/looangarch64的方式，并无法解决这一核心问题，仍然需要编译的时候patch

MystiPanda commented 5 months ago

verge还没有正式支持loong64，check脚本里写的只是之前遗留的，在正式支持loong64的时候verge会按照mihomo的命名进行修改，所以verge那边怎么写不应该是mihomo这边是否应该修改的论据，如果要请求mihomo修改命名应该从其他方面举证。

ziqi-cn commented 5 months ago 
const ARCH_MAP = {
  "x86_64-pc-windows-msvc": "x64",
  "i686-pc-windows-msvc": "ia32",
  "aarch64-pc-windows-msvc": "arm64",
  "x86_64-apple-darwin": "x64",
  "aarch64-apple-darwin": "arm64",
  "x86_64-unknown-linux-gnu": "x64",
  "i686-unknown-linux-gnu": "ia32",
  "aarch64-unknown-linux-gnu": "arm64",
  "armv7-unknown-linux-gnueabihf": "arm",
  "riscv64gc-unknown-linux-gnu": "riscv64",
  "loongarch64-unknown-linux-gnu": "loong64",
};

在此处clash-verge-rev的代码中，无论新旧世界都会映射为loong64，这是问题的根源

ziqi-cn commented 5 months ago

建议去clash-verge-rev那边讨论如何在check脚本中区分新旧世界

Kiri2002 commented 5 months ago

目前命名方式造成的主要问题是编译clash-verge-rev的时候抓不到包，无论是abi1/2的命名方式还是loong64/looangarch64的方式，并无法解决这一核心问题，仍然需要编译的时候patch

现在clash-verge-rev默认抓包是loong64规则的包，这个之前已经merge了。clash-verge-rev是没有问题的。

建议去clash-verge-rev那边讨论如何在check脚本中区分新旧世界

我个人认为，目前clash-verge-rev对于新世界loong64的做法是没有问题的。 至于如果要增加旧世界支持，建议千万不要像mihomo一样，改掉新世界loong64了

MystiPanda commented 5 months ago

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

ziqi-cn commented 5 months ago

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。

由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

Kiri2002 commented 5 months ago

是从这个commit起，加的loong64-abi-1/2.

其中构建过程抓go包，抓的不是go官方的包，而是提交者@xishang0128自己github fork的go包，这真的好吗？

    - name: Set up Go1.21 loongarch abi1
      if: ${{ matrix.jobs.goarch == 'loong64' && matrix.jobs.abi == '1' }}
      run: |
        wget -q https://github.com/xishang0128/loongarch64-golang/releases/download/1.21.5/go1.21.5.linux-amd64-abi1.tar.gz

旧世界这么抓，是因为go没提供旧世界的包，没有办法。新世界为什么不用go官方的包？从第三方私人的仓库抓，我认为这不是个好的做法，也不安全

Kiri2002 commented 5 months ago

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。

由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

正如您说的，“作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。”，从这个commit前，mihomo一直是loong64的规范命名规则，当时也能打出来老版本的clash-verge。后面为什么突然改了？

建议mihomo先解决争议，稳定命名后，下游再更。总不能上游反复改，下游跟着遭殃

xishang0128 commented 5 months ago

是从这个commit起，加的loong64-abi-1/2.

其中构建过程抓go包，抓的不是go官方的包，而是提交者@xishang0128自己github fork的go包，这真的好吗？

    - name: Set up Go1.21 loongarch abi1
      if: ${{ matrix.jobs.goarch == 'loong64' && matrix.jobs.abi == '1' }}
      run: |
        wget -q https://github.com/xishang0128/loongarch64-golang/releases/download/1.21.5/go1.21.5.linux-amd64-abi1.tar.gz

龙芯自己的下载源太慢，所以存github有问题吗，更何况这是龙芯自己的命名，他自己区分的abi版本

image

Kiri2002 commented 5 months ago

是从这个commit起，加的loong64-abi-1/2. 其中构建过程抓go包，抓的不是go官方的包，而是提交者@xishang0128自己github fork的go包，这真的好吗？

    - name: Set up Go1.21 loongarch abi1
      if: ${{ matrix.jobs.goarch == 'loong64' && matrix.jobs.abi == '1' }}
      run: |
        wget -q https://github.com/xishang0128/loongarch64-golang/releases/download/1.21.5/go1.21.5.linux-amd64-abi1.tar.gz

龙芯自己的下载源太慢，所以存github有问题吗，更何况这是龙芯自己的命名，他自己区分的abi版本

image

新世界用go官方的loong64包就行：https://go.dev/dl/go1.22.2.linux-loong64.tar.gz image

这个commit本来只是增加旧世界的支持，为什么要改新世界的包源？ 有官方包支持的情况下不用三方包，（在这里包括龙芯公司的包）这是开源社区主流的共识。一方面统一版本，另一方面，安全问题，杜绝加料的风险。官方源有眼睛盯着，三方源没有那么多人关注！

另外，三方源有滞后性。这对滚动发行的发行版是致命的危险（如Archlinux）

ziqi-cn commented 5 months ago

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。 由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

正如您说的，“作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。”，从这个commit前，mihomo一直是loong64的规范命名规则，当时也能打出来老版本的clash-verge。后面为什么突然改了？

建议mihomo先解决争议，稳定命名后，下游再更。总不能上游反复改，下游跟着遭殃

mihomo增加abi1/2是因为此issue https://github.com/MetaCubeX/mihomo/issues/1062

在此之前mihomo只有新世界包，此后增加了旧世界包，因此出现了区分新旧世界的需求

Kiri2002 commented 5 months ago

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

既然如此，为何不将check脚本中的链接改为当前新世界版本的链接，至少在新世界编译时不需要patch了。 由于此处的包名不会造成实质性问题，建议先等待观察龙芯官方和新世界商业发行版动态，作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

正如您说的，“作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。”，从这个commit前，mihomo一直是loong64的规范命名规则，当时也能打出来老版本的clash-verge。后面为什么突然改了？ 建议mihomo先解决争议，稳定命名后，下游再更。总不能上游反复改，下游跟着遭殃

mihomo增加abi1/2是因为此issue #1062

在此之前mihomo只有新世界包，此后增加了旧世界包，因此出现了区分新旧世界的需求

同样的“在没有充分理由的情况下不应频繁更改命名规则”，完全可以用loongarch64或别的进行区分。完全可以不动新世界的loong64命名。这么一改，新世界的也用不了了。 不觉得这么做很过分吗？

ziqi-cn commented 5 months ago 
        if [ "${{matrix.jobs.goarch}}" = "loong64" ]; then
          ARCH=loongarch64
        else
          ARCH=${{matrix.jobs.goarch}}
        fi

我观察到这里不区分新旧世界架构名一律为loongarch64，是否有待商榷

Kiri2002 commented 5 months ago

我认为，采取新世界loong64，旧世界loongarch64这种最主流的办法是目前最好的办法 既支持了旧世界，又不影响新世界，还符合了主流惯例，并且优雅简洁美丽 PR在这https://github.com/MetaCubeX/mihomo/pull/1218 大佬@xishang0128，您觉得呢？

ToKingl commented 5 months ago

我认为，采取新世界loong64，旧世界loongarch64这种最主流的办法是目前最好的办法 既支持了旧世界，又不影响新世界，还符合了主流惯例，并且优雅简洁美丽 PR在这#1218 大佬@xishang0128，您觉得呢？

不是已经说了，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。作为上游，首要的是保持稳定，在没有充分理由的情况下不应频繁更改命名规则。

LinuxResearcher commented 5 months ago

老哥，rpm系不是的。rpm系尊重产品商标，所以选择了loongarch64作为架构名。另一方面，也跟开发者喜好有关，目前的龙架构rpm系开发者刚好喜欢长名，所以rpm系都保留了loongarch64。而debian社区不喜欢长名，所以倾向于loong64。

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:26 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

哥们呀，哥们

对于发行版： Arch系，debian系，Fedora，Geentoo, FreeBSD, Slackware 等都没惯着, 都用的loong64.

对于软件包，除了和gcc绑死的一些软件，绝大多数的软件都是loong64

求同存异，AOSC用loongarch64，这是极少数的例子。不至于打破现有的共识啊！

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

LinuxResearcher commented 5 months ago

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

ToKingl commented 5 months ago

怎么就独一个了？据我所知还有lxmusic、musicfree等一些开源软件

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:08 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>

ziqi-cn commented 5 months ago

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

这样不好，新世界发行版很多都有mihomo的包（AOSC，LoongArchLinux，Deepin），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

LinuxResearcher commented 5 months ago

这软件根本就没有官方发行龙架构二进制吧？你见到的是其他人编译的吧？

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:11 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

怎么就独一个了？据我所知还有lxmusic、musicfree等一些开源软件

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:08 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。

---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 凌晨0:47
收件人: @.>;
抄送: @.**@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

LinuxResearcher commented 5 months ago

旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。 相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:12 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

这样不好，新世界发行版很多都有mihomo的包（AOSC，LoongArchLinux，Deepin），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

ToKingl commented 5 months ago

但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:16 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。 相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:12 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。 … ---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

这样不好，新世界发行版很多都有mihomo的包（AOSC，LoongArchLinux，Deepin），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>

LinuxResearcher commented 5 months ago

LonngArchLinux，deepin v23，aosc等主流新世界已支持龙芯核显。 至于买摩尔线程显卡的人，是少数。Linux用户不应该有Linux与AMD显卡的兼容性更好的常识吗？而且摩尔线程用户不应该抱怨系统不支持摩尔线程，而是应该去催促摩尔线程开发上油Linux内核驱动。要不然，Linus Torvalds为什么要fuck NVIDIA呢？

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:19 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:16 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。
相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。

---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午7:12
收件人: @.>;
抄送: @.**@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
…
---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

这样不好，新世界发行版很多都有mihomo的包（AOSC，LoongArchLinux，Deepin），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

ToKingl commented 5 months ago

核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:47 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

LonngArchLinux，deepin v23，aosc等主流新世界已支持龙芯核显。 至于买摩尔线程显卡的人，是少数。Linux用户不应该有Linux与AMD显卡的兼容性更好的常识吗？而且摩尔线程用户不应该抱怨系统不支持摩尔线程，而是应该去催促摩尔线程开发上油Linux内核驱动。要不然，Linus Torvalds为什么要fuck NVIDIA呢？

---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 上午7:19 收件人: @.>; 抄送: @.**@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？

---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午7:16
收件人: @.>;
抄送: @.**@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。
相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。

---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午7:12
收件人: @.>;
抄送: @.**@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
…
---原始邮件--- 发件人: @.> 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.>; 抄送: @.@.>; 主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141) verge 不打算支持旧世界，verge 怎么写并不是问题的根源，因为 verge 还没正式支持 loong64，在正式支持的时候这里会对应 mihomo 中新世界的命名。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

这样不好，新世界发行版很多都有mihomo的包（AOSC，LoongArchLinux，Deepin），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.>
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.>