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

Verify steps

[X]  我已经在 Issue Tracker 中找过我要提出的请求 I have searched on the issue tracker for a related feature request.
[X]  我已经仔细看过 Documentation 并无法找到这个功能 I have read the documentation and was unable to solve the issue.

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 。

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

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

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

@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😏

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

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

@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的约定，其他发行版都遵守这个约定了。

@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 命名

@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 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系。其他的架构名，amd64、ppc64、mips64el、x86_64、rv64、arm64、sw64等等，哪个傻屄到命名为amdarch64、ppcarch64、mipsarch64el、x86arch_64、rvarch64、armarch64、swarch64？
loongnix架构名为loongarch64，大概率是为了体现出来loongarch是龙芯中科的商标，其实这种命名很傻屄。

@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 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。

这个命名规则有官方文档来约束没？

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

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

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

目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是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/

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

目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是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/

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

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

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

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

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

目前没有，现在只有默认的做法，并且已经开始混乱了。
不过，可以确定的是，所有旧世界架构名都是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的架构名作为包架构名，并且喜欢和商标一致。

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

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

目前龙芯官方还未在新世界中提供显卡驱动，所以旧世界也还会在未来存在一段时间。
况且新旧世界的区分从来就不是用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和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命名的包，和其他的并存。
明明是很容易能做到 简洁，优雅，一致的事情， 真不至于

对于社区，龙芯的标准好，就采用，不好，就不采用。
对于龙芯： “只要你说的对，我们就改正，只要你说的对人民有好处，我们就照你说的办”
loong64已经是板上钉钉了，没有讨论余地了。
本来就是试错改错的过程，没必要一条路走到底

但是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: @.***>

哥们呀，哥们

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

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

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

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

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

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，这是问题的根源

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

目前命名方式造成的主要问题是编译clash-verge-rev的时候抓不到包，无论是abi1/2的命名方式还是loong64/looangarch64的方式，并无法解决这一核心问题，仍然需要编译的时候patch
现在clash-verge-rev默认抓包是loong64规则的包，这个之前已经merge了。clash-verge-rev是没有问题的。

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

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

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

是从这个commit起，加的loong64-abi-1/2.
其中构建过程抓go包，抓的不是go官方的包，而是提交者自己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

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

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

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

是从这个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有问题吗，更何况这是龙芯自己的命名

是从这个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版本

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

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

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只有新世界包，此后增加了旧世界包，因此出现了区分新旧世界的需求

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

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

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

mihomo增加abi1/2是因为此issue #1062
在此之前mihomo只有新世界包，此后增加了旧世界包，因此出现了区分新旧世界的需求

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

        if [ "${{matrix.jobs.goarch}}" = "loong64" ]; then
          ARCH=loongarch64
        else
          ARCH=${{matrix.jobs.goarch}}
        fi

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

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

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

老哥，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: @.***>

那么能建议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: @.***>

怎么就独一个了？据我所知还有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: @.>

那么能建议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），反而是旧世界没有，也不可能有包，这里发布的旧世界包反而更有价值。

这软件根本就没有官方发行龙架构二进制吧？你见到的是其他人编译的吧？
---原始邮件---
发件人: @.>
发送时间: 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是独一个。
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 凌晨0:47
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: 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: @.&gt;
—
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: @.***>

旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。
相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。
---原始邮件---
发件人: @.>
发送时间: 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: @.***>

但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？
---原始邮件---
发件人: @.>
发送时间: 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: @.>

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)
旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。
相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午7:12
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
…
---原始邮件--- 发件人: @.&gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&gt;; 抄送: @.@.&gt;; 主题: 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: @.***&gt;
这样不好，新世界发行版很多都有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: @.&gt;
—
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: @.***>

核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售
---原始邮件---
发件人: @.>
发送时间: 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)
但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午7:16
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。
相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。
---原始邮件---
发件人: @.&amp;gt;
发送时间: 2024年4月26日(周五) 上午7:12
收件人: @.&amp;gt;;
抄送: @.@.&amp;gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
…
---原始邮件--- 发件人: @.&amp;gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&amp;gt;; 抄送: @.@.&amp;gt;; 主题: 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: @.***&amp;gt;
这样不好，新世界发行版很多都有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: @.&amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.&gt;
—
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: @.>

龙芯又不是没在开发上游显卡驱动。还是那个问题，Linux用户应该有配合AMD显卡的常识。至于厂商搭载什么显卡，自有厂商提供售后，你买了整机有问题找厂家，你没买就不需要操心。这一切都不是旧世界要消亡新世界要推开的理由。
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午7:51
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午7:47
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
LonngArchLinux，deepin v23，aosc等主流新世界已支持龙芯核显。
至于买摩尔线程显卡的人，是少数。Linux用户不应该有Linux与AMD显卡的兼容性更好的常识吗？而且摩尔线程用户不应该抱怨系统不支持摩尔线程，而是应该去催促摩尔线程开发上油Linux内核驱动。要不然，Linus Torvalds为什么要fuck NVIDIA呢？
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午7:19
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？
---原始邮件---
发件人: @.&amp;gt;
发送时间: 2024年4月26日(周五) 上午7:16
收件人: @.&amp;gt;;
抄送: @.@.&amp;gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
旧世界是不久就要消亡的，而且旧世界用户有相关需求的不多，或者说不应该培养旧世界用户的有关需求。
相反，社区开发者都在用新世界，没有一个社区开发者喜欢旧世界。为了促进旧世界的消亡，尽快建立新世界，不应该支持旧世界软件。

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

那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
 …
 ---原始邮件--- 发件人: @.&amp;amp;amp;gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&amp;amp;amp;gt;; 抄送: @.@.&amp;amp;amp;gt;; 主题: 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: @.***&amp;amp;amp;gt;

这样不好，新世界发行版很多都有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: ***@***.***&amp;amp;amp;gt;

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.&amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.&gt;
—
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: @.>

至少现在新世界中还缺少显卡驱动，况且又不是所有人都有搭配独显的需求，还有也不要有这种Linux用户应该有配合AMD显卡的常识的常识了，总会有那么一群人没有的。所以旧世界还会存在一段时间的，不然龙芯、uos和麒麟大可不必继续维护旧世界了
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:08
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
龙芯又不是没在开发上游显卡驱动。还是那个问题，Linux用户应该有配合AMD显卡的常识。至于厂商搭载什么显卡，自有厂商提供售后，你买了整机有问题找厂家，你没买就不需要操心。这一切都不是旧世界要消亡新世界要推开的理由。
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午7:51
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午7:47
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
LonngArchLinux，deepin v23，aosc等主流新世界已支持龙芯核显。
至于买摩尔线程显卡的人，是少数。Linux用户不应该有Linux与AMD显卡的兼容性更好的常识吗？而且摩尔线程用户不应该抱怨系统不支持摩尔线程，而是应该去催促摩尔线程开发上油Linux内核驱动。要不然，Linus Torvalds为什么要fuck NVIDIA呢？
---原始邮件---
发件人: @.&amp;gt;
发送时间: 2024年4月26日(周五) 上午7:19
收件人: @.&amp;gt;;
抄送: @.@.&amp;gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
但是目前旧世界还依旧存在啊？新世界中目前显卡驱动还不全，有些用户只能待在旧世界中，你让那些用户怎么办？比如购买了摩尔显卡和使用核显的那些用户？

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

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

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

 那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
  …
  ---原始邮件--- 发件人: @.&amp;amp;amp;amp;gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&amp;amp;amp;amp;gt;; 抄送: @.@.&amp;amp;amp;amp;gt;; 主题: 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: @.***&amp;amp;amp;amp;gt;

 这样不好，新世界发行版很多都有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: ***@***.***&amp;amp;amp;amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***&amp;amp;amp;gt;

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.&amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.&gt;
—
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: @.>

你不知道信创桌面机器一般就带着R5-230这种低端独显吗？旧世界的确有一年的寿命，这不是需要支持旧世界的理由。一个马上就死的人，还需要给他买新款式的衣服吗？旧世界的应用主要在体制内，有使用mihomo需求的人不多，他们要是有需求可以让他们自己解决。
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:16
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
至少现在新世界中还缺少显卡驱动，况且又不是所有人都有搭配独显的需求，还有也不要有这种Linux用户应该有配合AMD显卡的常识的常识了，总会有那么一群人没有的。所以旧世界还会存在一段时间的，不然龙芯、uos和麒麟大可不必继续维护旧世界了
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:08
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
龙芯又不是没在开发上游显卡驱动。还是那个问题，Linux用户应该有配合AMD显卡的常识。至于厂商搭载什么显卡，自有厂商提供售后，你买了整机有问题找厂家，你没买就不需要操心。这一切都不是旧世界要消亡新世界要推开的理由。
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午7:51
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售
---原始邮件---
发件人: @.&amp;gt;
发送时间: 2024年4月26日(周五) 上午7:47
收件人: @.&amp;gt;;
抄送: @.@.&amp;gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
LonngArchLinux，deepin v23，aosc等主流新世界已支持龙芯核显。
至于买摩尔线程显卡的人，是少数。Linux用户不应该有Linux与AMD显卡的兼容性更好的常识吗？而且摩尔线程用户不应该抱怨系统不支持摩尔线程，而是应该去催促摩尔线程开发上油Linux内核驱动。要不然，Linus Torvalds为什么要fuck NVIDIA呢？

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

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

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

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

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

  那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
   …
   ---原始邮件--- 发件人: @.&amp;amp;amp;amp;amp;gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&amp;amp;amp;amp;amp;gt;; 抄送: @.@.&amp;amp;amp;amp;amp;gt;; 主题: 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: @.***&amp;amp;amp;amp;amp;gt;

  这样不好，新世界发行版很多都有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: ***@***.***&amp;amp;amp;amp;amp;gt;
 —
 Reply to this email directly, view it on GitHub, or unsubscribe.
 You are receiving this because you commented.Message ID: ***@***.***&amp;amp;amp;amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***&amp;amp;amp;gt;

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.&amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.&gt;
—
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: @.>

旧世界还缺少RX5000系及以上显卡以及更多新硬件的驱动呢，比如没有WiFi6，WiFi7网卡驱动等等。这部分用户只能上新世界来解决，你怎么不考虑这些用户的需求呢？
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:16
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
至少现在新世界中还缺少显卡驱动，况且又不是所有人都有搭配独显的需求，还有也不要有这种Linux用户应该有配合AMD显卡的常识的常识了，总会有那么一群人没有的。所以旧世界还会存在一段时间的，不然龙芯、uos和麒麟大可不必继续维护旧世界了
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:08
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
龙芯又不是没在开发上游显卡驱动。还是那个问题，Linux用户应该有配合AMD显卡的常识。至于厂商搭载什么显卡，自有厂商提供售后，你买了整机有问题找厂家，你没买就不需要操心。这一切都不是旧世界要消亡新世界要推开的理由。
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午7:51
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售
---原始邮件---
发件人: @.&amp;gt;
发送时间: 2024年4月26日(周五) 上午7:47
收件人: @.&amp;gt;;
抄送: @.@.&amp;gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
LonngArchLinux，deepin v23，aosc等主流新世界已支持龙芯核显。
至于买摩尔线程显卡的人，是少数。Linux用户不应该有Linux与AMD显卡的兼容性更好的常识吗？而且摩尔线程用户不应该抱怨系统不支持摩尔线程，而是应该去催促摩尔线程开发上油Linux内核驱动。要不然，Linus Torvalds为什么要fuck NVIDIA呢？

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

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

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

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

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

  那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
   …
   ---原始邮件--- 发件人: @.&amp;amp;amp;amp;amp;gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&amp;amp;amp;amp;amp;gt;; 抄送: @.@.&amp;amp;amp;amp;amp;gt;; 主题: 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: @.***&amp;amp;amp;amp;amp;gt;

  这样不好，新世界发行版很多都有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: ***@***.***&amp;amp;amp;amp;amp;gt;
 —
 Reply to this email directly, view it on GitHub, or unsubscribe.
 You are receiving this because you commented.Message ID: ***@***.***&amp;amp;amp;amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***&amp;amp;amp;gt;

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.&amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.&gt;
—
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: @.>

所以目前的状态还是新旧世界共存啊，我也没说要旧不要新，要新不要旧吧
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:35
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
旧世界还缺少RX5000系及以上显卡以及更多新硬件的驱动呢，比如没有WiFi6，WiFi7网卡驱动等等。这部分用户只能上新世界来解决，你怎么不考虑这些用户的需求呢？
---原始邮件---
发件人: @.>
发送时间: 2024年4月26日(周五) 上午8:16
收件人: @.>;
抄送: @.@.>;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
至少现在新世界中还缺少显卡驱动，况且又不是所有人都有搭配独显的需求，还有也不要有这种Linux用户应该有配合AMD显卡的常识的常识了，总会有那么一群人没有的。所以旧世界还会存在一段时间的，不然龙芯、uos和麒麟大可不必继续维护旧世界了
---原始邮件---
发件人: @.&gt;
发送时间: 2024年4月26日(周五) 上午8:08
收件人: @.&gt;;
抄送: @.@.&gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
龙芯又不是没在开发上游显卡驱动。还是那个问题，Linux用户应该有配合AMD显卡的常识。至于厂商搭载什么显卡，自有厂商提供售后，你买了整机有问题找厂家，你没买就不需要操心。这一切都不是旧世界要消亡新世界要推开的理由。
---原始邮件---
发件人: @.&amp;gt;
发送时间: 2024年4月26日(周五) 上午7:51
收件人: @.&amp;gt;;
抄送: @.@.&amp;gt;;
主题: Re: [MetaCubeX/mihomo] [Feature] 关于龙架构二进制文件名的建议 (Issue #1141)
核显在新世界中能亮是一回事，但是没有驱动卡的要死……，而现在也有一些厂商同时搭配了摩尔线程进行整机出售

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

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

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

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

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

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

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

   那么能建议mihomo也放弃对旧世界的支持吗？开源软件发行旧世界二进制的，好像mihomo是独一个。
    …
    ---原始邮件--- 发件人: @.&amp;amp;amp;amp;amp;amp;gt; 发送时间: 2024年4月26日(周五) 凌晨0:47 收件人: @.&amp;amp;amp;amp;amp;amp;gt;; 抄送: @.@.&amp;amp;amp;amp;amp;amp;gt;; 主题: 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: @.***&amp;amp;amp;amp;amp;amp;gt;

   这样不好，新世界发行版很多都有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: ***@***.***&amp;amp;amp;amp;amp;amp;gt;
  —
  Reply to this email directly, view it on GitHub, or unsubscribe.
  You are receiving this because you commented.Message ID: ***@***.***&amp;amp;amp;amp;amp;gt;
 —
 Reply to this email directly, view it on GitHub, or unsubscribe.
 You are receiving this because you were mentioned.Message ID: ***@***.***&amp;amp;amp;amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***&amp;amp;amp;gt;

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.&amp;gt;
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.&gt;
—
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: @.>

非要那么极端吗？非要在二者中选一个吗？
有时候真替龙芯感到悲哀，自己对自己家产品的命名权还得不到尊重，非要外来者进行横插一杠、指手画脚。这就相当于明明你有正式的名字，但别人非给你再取个绰号，还美其名曰名字太长了，不够显眼，然后就这么一直这么地叫你

旧世界爱叫啥叫啥，不会有历史包袱。
新世界统一loong64，尊重社区主流。
社区绝大多数是用爱发电，可不拿工资

authors: Kiri2002 LinuxResearcher MystiPanda ToKingl TurnOffNOD xishang0128 ziqi-cn

repo: MetaCubeX/mihomo


text:
lookupNetwork: Drop mutex; bail on network change

Description

If the network is changed multiple times in quick succession, multiple "instances" of lookupNetwork can get run simultaneously. This happens because each time the network is changed, lookupNetwork is called. Because we do not expect lookupNetwork to run synchronously — it makes HTTP requests and waits for them to complete — and because it makes changes to the state, this creates a race condition where the state may not reflect the last network that was selected.
Currently, to resolve this problem, lookupNetwork makes use of a mutex. This ensures that only one "instance" of lookupNetwork is running at a given time. However, this trades one problem for another, because as a result, on mobile, the UI will be slow to update, as the network controller has to "process" all of the network changes one at a time.
So instead of using a mutex, a better solution is to copy the extension, which makes it such if the network is changed while HTTP requests are being awaited, no state changes will occur. This still guarantees that later network changes override earlier ones while removing the bottleneck.
Notable changes that I found while adding tests for this new behavior:

When on an Infura network and the network is switched to a non-Infura network during a request for net_version or eth_getBlockByNumber, and Infura is blocking requests, infuraIsBlocked will no longer be emitted.
Similarly, when on a non-Infura network and the network is switched to a Infura network during a request for net_version or eth_getBlockByNumber, and Infura is blocking requests, infuraIsUnblocked will no longer be emitted.

Changes

@metamask/network-controller

FIXED: Removed bottleneck on lookupNetwork so that it will no longer block on multiple simultaneous calls but will abort if a network change is detected midway through execution.

This means that clients are able to visually respond to rapid network switches more quickly.
This also has consequences for when infuraIsBlocked or infuraIsUnblocked is emitted. Notably, when on an Infura network and the network is switched to a non-Infura network during a request for net_version or eth_getBlockByNumber, and Infura is blocking requests, infuraIsBlocked will no longer be emitted. Similarly, when on a non-Infura network and the network is switched to a Infura network during a request for net_version or eth_getBlockByNumber, and Infura is blocking requests, infuraIsUnblocked will no longer be emitted.

References

Checklist

[x] I've updated the test suite for new or updated code as appropriate
[x] I've updated documentation for new or updated code as appropriate (note: this will usually be JSDoc)
[x] I've highlighted breaking changes using the "BREAKING" category above as appropriate

The bit about infuraIsUnblocked/infuraIsBlocked I left in the changelog may be a breaking change, but I wasn't sure.

Tests are failing for the gas fee controller, but it's not yet clear to me why

Tests are failing for the gas fee controller, but it's not yet clear to me why

The test failures are occurring because lookupNetwork now accesses the networkDidChange event, so it needs to be added to the allowlist. I've fixed that here: f52788c

The assets-controllers tests are now failing for a similar reason

source: gharchive/pull-request

authors: Gudahtt mcmire

repo: MetaMask/core

license: MIT

license_type: permissive

license_source: github-api


text:
[Experiment] - Ethereum Trie Heatmap

Include storage information per children all the way up to the root.
Do we have ways to infer which accounts are more popular?

Completed

source: gharchive/issue

repo: MetaMask/mustekala


text:
Update to Java 14

We are now using Java 14. Please check the pom.xml . For some I was not able to pull groovy 3 when using groovy.version, I had to use the number to get it work (see commented lines).

 [Detector] Move to Java 14

Your tip worked, I renamed groovy.version to custom-groovy.version and now the correct one is used.

repo: MetalDetectorRocks/metal-detector-main


text:
Review/organize the IB Dockerfile template

Summary

We need to ensure that the Dockerfile is streamlined and is organized in a reasonable manner. Benefits may include increased build speed, making it easier to read and easier to debug.
Report results here.

We are going to use templates in the IB repo so they can be as disorganized as someone else wants.


text:
subprocess.CalledProcessError: Command '['nix-env', '--extra-experimental-features', 'no-url-literals', '--option', 'system', 'x86_64-linux', '-f', '/home/bbigras/.cache/nixpkgs-review/rev-c283f7a9891027c8809f08a618b97cbf01ab90b7-1/nixpkgs', '-qaP', '--xml', '--out-path', '--show-trace', '--no-allow-import-from-derivation']' returned non-zero exit status 1.

❯ nix run github:Mic92/nixpkgs-review rev HEAD
$ git -c fetch.prune=false fetch --no-tags --force https://github.com/NixOS/nixpkgs master:refs/nixpkgs-review/0
$ git worktree add /home/bbigras/.cache/nixpkgs-review/rev-c283f7a9891027c8809f08a618b97cbf01ab90b7-1/nixpkgs b04b3345f16716f7289724286cdc8474d4758a41
Préparation de l'arbre de travail (HEAD détachée b04b3345f16)
Mise à jour des fichiers: 100% (34789/34789), fait.
HEAD est maintenant à b04b3345f16 Merge pull request #195082 from cmm/system76-scheduler
$ nix-env --extra-experimental-features no-url-literals --option system x86_64-linux -f /home/bbigras/.cache/nixpkgs-review/rev-c283f7a9891027c8809f08a618b97cbf01ab90b7-1/nixpkgs -qaP --xml --out-path --show-trace --no-allow-import-from-derivation
        error: interrupted by the user
$ git worktree prune
Traceback (most recent call last):
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/bin/.nixpkgs-review-wrapped", line 9, in <module>
    sys.exit(main())
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/__init__.py", line 10, in main
    cli.main(command, args)
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/cli/__init__.py", line 304, in main
    return cast(str, args.func(args))
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/cli/rev.py", line 14, in rev_command
    return review_local_revision(
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/review.py", line 538, in review_local_revision
    review.review_commit(builddir.path, args.branch, commit, staged, print_result)
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/review.py", line 291, in review_commit
    self.build_commit(branch_rev, reviewed_commit, staged),
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/review.py", line 153, in build_commit
    base_packages = list_packages(
  File "/nix/store/z662qs4n292mysbcxhzds8979glh1fc1-nixpkgs-review/lib/python3.10/site-packages/nixpkgs_review/review.py", line 371, in list_packages
    subprocess.run(cmd, stdout=tmp, check=True)
  File "/nix/store/abax98471z8fshv4b9p46bkh3lxmpy0z-python3-3.10.9/lib/python3.10/subprocess.py", line 526, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['nix-env', '--extra-experimental-features', 'no-url-literals', '--option', 'system', 'x86_64-linux', '-f', '/home/bbigras/.cache/nixpkgs-review/rev-c283f7a9891027c8809f08a618b97cbf01ab90b7-1/nixpkgs', '-qaP', '--xml', '--out-path', '--show-trace', '--no-allow-import-from-derivation']' returned non-zero exit status 1.

    error: interrupted by the user

Did you press ctrl-c on accident? If not, can you try to reproduce this error?

oh sorry I missed that. I actually ran out of ram.
I'll reopen if I really have this problem.

I've been getting this same issue while trying to review PRs from nixpkgs, I have plenty of RAM so that shouldn't be a limitation of why it keeps hanging on this command. Had to stop the program as it was freezing my system.

authors: bbigras figsoda itslychee


text:
Uploading

When CircleCI is busy running the NCFTP upload job, a message should appear accross the top of every page, stating that this is in progress and may cause errors. This will need to be setup as part of the CircleCI update_site job, alongside a HTML header included with iframe.

Alternatively, we could work out a better way of updating the content, such that it is transferred to the server in a separate directory to the hosted files - then http://kolechia.heliohost.org/micathon_zeus/site/ somehow points to the new directory.

Option 1 is easier, in my opinion

NcFTP has a -S .tmp option, which uploads files into temporary files - before transferring them into the main file when done. This would be useful instead of a UI message, and much easier.

Fixed in d14b0b80ddd3f8828021e8ec00b51b93a6da2fc2.

license: mit

license_source: bigquery


text:
how the mirror is contolled

Please only submit reproducible issues.
If you're not sure if it's a real bug or if it's just you, please open a topic on the forum: https://forum.magicmirror.builders/category/15/bug-hunt
Problems installing or configuring your MagicMirror? Check out: https://forum.magicmirror.builders/category/10/troubleshooting
When submitting a new issue, please supply the following information:
Platform: Place your platform here... give us your web browser/Electron version and your hardware (Raspberry Pi 2/3, Windows, Mac, Linux, System V UNIX).
Node Version: Make sure it's version 0.12.13 or later.
MagicMirror Version: Now that the versions have split, tell us if you are using the PHP version (v1) or the newer JavaScript version (v2).
Description: Provide a detailed description about the issue and include specific details to help us understand the problem. Adding screenshots will help describing the problem.
Steps to Reproduce: List the step by step process to reproduce the issue.
Expected Results: Describe what you expected to see.
Actual Results: Describe what you actually saw.
Configuration: What does the used config.js file look like? Don't forget to remove any sensitive information!
Additional Notes: Provide any other relevant notes not previously mentioned. This is optional.

what do you mean by controlled?   by default each module has an update cycle and injects updated content into the page. there is no built in user interaction with the application..
there are modules that provide different types of interaction, voice, mouse, remote. see the 3rd party list in the readme

Please refer to http://forum.magicmirror.builders for support and troubleshooting.
I'm closing this issue for now. If you feel this issue should remain open, please let me know.

authors: MichMich sdetweil vaishali-ag

repo: MichMich/MagicMirror


text:
Feature: Change background from black to image/slideshow

I saw this project (https://dakboard.com/site) which looks to be exactly magic mirror2  the only difference is the interface to customize the modules and the ability to select the background.
I am very interested in finding/creating a module that would allow the ability change background from black to slideshow(dropbox possibly or local). I am also learning javascript, but know some html/css.  Does this feature exist or any tips on getting started creating it?
Thanks!

There are several modules that will show photos from various locations. You can see them here, https://github.com/MichMich/MagicMirror/wiki/MagicMirror²-Modules#3rd-party-modules. I personally use the MMM-RandomPhoto module and it works really well.

@metalshreds To me sound and will be nice if we can add a feature like this.
Should be as simplest possible and with a non break change in the core. If you can add and maintenance in the future.
The last word if we can include some like this... comes from @MichMich

That would be great if it was added to core. I'd be happy to help but as I said before, I have limited knowledge of JS, just starting to pick it up and figured working on a module would be a good starting place :) I'm still trying to see how all the files are working together.

I'd prefer to stick with a custom module and not add it to the core

Sounds good, I'll take a crack at creating the module. Thanks!

In case anybody else is looking for this functionality. I found this module which is working really well!
https://github.com/Ultimatum22/MMM-RandomBackground

authors: ToddKlindt fewieden metalshreds roramirez


text:
Add in temperature degree label to Current Weather module

This pull request solves #753. It simply adds a label to the temperature if the configuration option is set.

Guess whet I'm about to ask: could you fix the conflicts? 😂 Thanks!

At least all of these conflicts are with the changelog and not the code!

authors: MichMich amcolash


text:
Inserting item with sub-millisecond expiration time causes problems on get (redis backend)

I think I have found a corner case in the Redis code that causes problems where items are inserted with really low durations.
Consider the following code:
var item = new CacheItem<object>("foo", "bar", sliding ExpirationMode.Absolute, TimeSpan.FromTicks(1));
cache.Put(item);

This will enter CacheItem's constructor, where TimeSpan will be checked if it is > 0 at CacheItem.cs line 133
if (ExpirationMode != ExpirationMode.Default && ExpirationMode != ExpirationMode.None && ExpirationTimeout <= TimeSpan.Zero)
{
    throw new ArgumentOutOfRangeException(nameof(timeout), "Expiration timeout must be greater than zero if expiration mode is defined.");
}

When cache items are stored into Redis, their duration is converted into a millisecond value (RedisCacheHandle.cs line 833 and other places). If this value is lower than 1 ms, this will end up being stored as 0. Later, inside GetCacheItemAndVersion() in RedisCacheHandle.cs, at line 499+, CacheItem's constructor is called with this value, which is now 0, which causes the constructor to throw an exception.
I am unsure what the fix for this is, else I would submit a proper patch for it. I will gladly submit a patch if we can figure out what the fix should be.

@ahockersten question is, why would you want to store items in Redis for less than 1 millisecond? That wouldn't do anything as the transport from client to server might already takes longer ;)
In general, this is an intentional limitation. The fact that the exception occurs later when the cache item gets retrieved is not really friendly. I'll add a check that expiration timeout is at least 1ms.

Oh I agree, it was an issue in my code that it was saving things with a sub-millisecond duration, which I have now fixed. :) In this case it was caused by subtracting two datetimes that sometimes happened to be very close to each other in time.
Thank you for the prompt response, and the bugfix.

authors: MichaCo ahockersten

repo: MichaCo/CacheManager


text:
For consistencey could we add :codesource to Aside

Docile.Collector.Aside
ERROR: LoadError: KeyError: codesource not found
being the same as the opening [

Their is no code related to an Aside so this doesn't really make such sense to store. Just check whether it's an Aside and don't display codesource in that case?

Just to go a bit further: my thinking is that Aside will be used mostly for "internals" documentation, kind of like a map to the source code and would be generated in a separate section/page of the resulting manual.


text:
Using restapi call to get the device properties (GCM).

I was trying for a method to see if GCM bit is set on a device or to list devices which has gcm bit is set. Does anyone know if there is an option for this please?
Thanks in advance.

Anish,
This is not possible with the API, GCM is generally only set on a very small set of devices when there is a migration between V2 and V3 using SRDF and the source volume has a uneven number of tracks that can’t align to the 128KB track size of V3 and PowerMax.  You can search for these with the cli and depending on the OS and Filesystem expand the device to be an even size to remove the GCM bit this is generally a recommended practice providing the OS using the volume can support an online volume expansion.
Please see the following technical note on the GCM bit
https://www.emc.com/collateral/technical-document/h14030-understanding-vmax3-srdf-n-1-device-compatibility-technical-note.pdf
restrictions on what can and can’t be done with GCM bit have lifted over the releases, so please check release notes for the level of PowerMax OS.  If you are running PowerMax 5978 GCM is not an issue when using NDM metro or other SRDF actions.
Regards,
Paul Martin
Senior Principal Engineer
Technical marketing Engineering
DellEMC | Enterprise Software and Storage - PowerMax and VMAX
•Office +353 21 4938979
Cell +35387 696 0621
Timezone GMT
Follow me on Twitter @rawstorage
Blog https://rawstorage.wordpress.com/
WhitePapers and Resources - http://dell.com/storageresources
https://www.dellemc.com/en-us/storage/storage-automation-and-developer-resources/index.htm
http://www.emc.com/collateral/faq/timefinder-snapvx-faqs.pdf
https://www.emc.com/collateral/technical-documentation/h13697-emc-vmax3-local-replication.pdf
[0_Specialist_Logo_-_Web,_PowerPoint,_Email][cid:image003.png@01CCA385.0F79A530]
Confidentiality Notice: This email message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential or proprietary information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, immediately contact the sender by reply e-mail and destroy all copies of the original message.
From: anishxv notifications@github.com
Sent: Wednesday 28 August 2019 15:22
To: MichaelMcAleer/PyU4V
Cc: Subscribed
Subject: [MichaelMcAleer/PyU4V] Using restapi call to get the device properties (GCM). (#56)
[EXTERNAL EMAIL]
I was trying for a method to see if GCM bit is set on a device or to list devices which has gcm bit is set. Does anyone know if there is an option for this please?
Thanks in advance.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/MichaelMcAleer/PyU4V/issues/56?email_source=notifications&email_token=AF7FWPL7H2UCCE5PBFTFJI3QG2CX3A5CNFSM4IRIN7A2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HH6DE5A, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AF7FWPKIIQWUEW6P6ZISNI3QG2CX3ANCNFSM4IRIN7AQ.

authors: anishxv rawstorage


text:
Back-end planning.

This will be used as conversation on how the back-end will be structured and will reference other issues pertaining to more specific bugs/enhancements. The specific issues that will be referenced here can then be assigned individually.
Issues to tackle:

[ ] #5
[ ] #4
[ ] #14

Assigned #5 to @Dex-theDev

added #14 so we can decide oh which free hosting provider to choose.

I would like to tackle the implementation of the API, I would love to delve more into the backend this way and I am currently looking into the APIs available for the memory game. Naturally, I will come to the group for any issues I cannot solve or do not understand after all this is a learning experience. The API would return certain data based on what we are developing the memory game over, whether it is the pokemon card's in general or pokemon types, and that data would be returned into JSON format. This is open to discussion.

If you'd like to tackle the api you can. The api needs to return Pokemon cards. I think an array that randomizes the order of the cards is best. I'm thinking 8 different cards, and each one will need to be in the array twice in a different order. It should also return a singular picture that will act as the back of the card. Does this sound like what were you thinking?

Sounds about right, I'll first do some testing with what is returned from the API, update you all on the process as I work on it.

Added #18, this is a issue to further help with readability, doesn't need a proposal since its a small change in code and I have outline the changes i would like have done.

I would like to tackle the implementation of the API, I would love to delve more into the backend this way and I am currently looking into the APIs available for the memory game. Naturally, I will come to the group for any issues I cannot solve or do not understand after all this is a learning experience. The API would return certain data based on what we are developing the memory game over, whether it is the pokemon card's in general or pokemon types, and that data would be returned into JSON format. This is open to discussion.

thanks for the proposal, and it sounds like you got the ok from @jericashall. The further clarification from her did help me understand. If you can further break down theses tasks in #4 that would be helpful. If not then not a big deal.

Ive talked to the front end group on vc chat and also wrote a message here once the front end devs decide on what they data they want from you the backend group, make sure you decide if you need any data from the client. This group needs to define what input you need from the front-end to achieve the desired outcome that front-end devs want.
going from what i wrote in the message i assume you need you need a couple of parameters
    name="name of the player"
    // AFAIK parameters sent from the client should be done with an underscore
   // should be false or true
    pause_state = true
    // make sure to check if this is empty, as that means the game just started,
    // otherwise it will have a array value which is picked by the user
    choice=""

this is a mockup of #15 and its a rough idea of what if i was in your situation i would ask from the front-end. Of course i would wait from the front-end devs to finalize a specification.

Currently, I have decided with the Pokemon TCG API, it is a private API, I spent the day looking for better APIs, however for the desired data it is the best choice, it is a private API so I will be setting up an account and acquiring a key and will send it in the discord chat, there are a few questions with implementing it using the key within the header that I am not familiar with, so I will contact you tomorrow regarding that @MichaelPachec0

Happy to help with any backend issue you guys assign to me!

Happy to help with any backend issue you guys assign to me!

Before that Is there a way I can reach you on discord? My discord is m1chael#3550

Happy to help with any backend issue you guys assign to me!

Before that Is there a way I can reach you on discord? My discord is m1chael#3550 feel free to add me as a friend so i can discuss some specifics of this repository/project.

Just sent a friend request!


text:
Fix bloat of dependencies

I am not particularly sure which dependencies bloated, but I was just going to install sass-loader and I found it already installed despite we haven't used it at all before.
We should absolutely make a clean-up to package.json. Also which is redecide on which deps are development and which are production

I think it's just fine for now

repo: MicroDroid/vue-materialize-datatable


text:
huntr - Cross-site Request Forgery (CSRF) Fix

https://app.huntr.dev/users/anandtiwarics has fixed a security vulnerability (Cross-site Request Forgery (CSRF)) :hammer:. anandtiwarics has been awarded $25 for fixing the vulnerability through the huntr bug bounty program :dollar:. Think you could fix a vulnerability like this? Get involved at https://huntr.dev/!Q | AVersion Affected | ALLBug Fix | YESOriginal Pull Request | https://github.com/418sec/Django-CRM/pull/1

fix conflicts and open new pull request

repo: MicroPyramid/Django-CRM


text:
Multiple Authentication Providers

Description

This change adds support for multiple authentication providers in the virtual assistant and skills.
Expected Behavior

If user is not logged in to any provider, they will be prompted to add an account from the supported providers list
If the user has already connected 1 account, that account will be used by default
If the user has multiple accounts configured (only possible with Linked Accounts for now) they will be prompted to choose which of their accounts to user
Supported providers are configured per skill

Related Issue

 fixes #19
Testing Steps

Register a google app - instructions here (instead of the Google+ API, enable the Google Calendar API)
Collect the clientId and clientSecret
Add the google auth provider in the Azure Bot Settings with the clientId and secret, and set the scopes to https://www.googleapis.com/auth/calendar
Add the appName, ClientId, ClientSecret, and scopes for your google app to the appsettings files
Say "logout" to ensure no tokens are cached
Say "what's on my calendar"
See the auth provider prompt

Changed to used connectionName to drive choices. This allows for the bot dev to create more meaningful names for the connections, and allows user to have multiple connections of the same type (i.e. personal Microsoft account and corporate 0365 account)

repo: Microsoft/AI


text:
How to "generate" "NAV App xxx" table content

I have recently tried to deploy an extension to a (NAV2018 CU4) database created from scratch using the "New Database" option of finsql.exe. Then I imported the base application via import and created a company. But now I find myself with the [NAV App xxx] tables all empty and therefore deploying an extension to this database does not work. The error I get is that the symbols for "Microsoft.System" and "Application" cannot be found.
I have then tried to generate symbol references by running finsql.exe with command=generatesymbolreference and it exited without error, stating that the command completed sucessfully after 227 seconds. But the records in theese tables did not appear. I don't even know if they are supposed to?
Anyway: how am I supposed to generate those records when NOT starting from a CRONUS database?

Hi @hemisphera,
In general, the [Nav App] tables are populated when you publish the extensions using Publish-NavApp cmdlet (or when you publish from VSCode).
The System and Test symbol package can be found in program files as described here.
Now, the Application symbols you have generated yourself using finsql.exe command=generatesymbolreference. In this case, the Application symbols are not persisted in the [Nav App] table, but they are available at runtime on the server (physically individual symbols are stored in [Object Metadata].[Symbol Reference] column).
So if you enable the setting EnableSymbolLoadingAtServerStartup as described here, you should be able to publish extensions.

Please have a look at the upgrade checklist, Task 18:
https://docs.microsoft.com/en-us/dynamics-nav/upgrading-the-data

repo: Microsoft/AL


text:
Extend existing dataset of any report

Is your feature request related to a problem? Please describe.
At this moment there is now way to add new field inside the existing report.
Describe the solution you'd like
As a Business Central dev I would like:

Extend existing dataset of any report (standard and own maded) as we do with pages and tables.

I would recommend split AL report object to dataset object and layout object
Eg: dataset Id MyExtension extends MyTargeDataset
{
fields
{
// Add changes to datasset fields here
}
var
myInt: Integer;
}

After extending the dataset I would like to add new custom field to report layout with DEV tools or with business central report layout designer

Describe alternatives you've considered
As a business Central dev I would like to set up dataset extensions:

I would like to use Business Central and extend or add new datasets inside applications without any coding. More like the click and point.
I would like to make those datasets also available to AL developer.
After defining the dataset inside Business central I would like to add new custom field to report layout with DEV tools or with business central report layout designer

Additional context
Sorry if it sounds like a dublicate!

see Report extendibility #1452

Thanks @gudrunleos, I'll close this as a duplicate of #1452.


text:
Field "Creditor Identifier" in table "Bank Account" and field "Direct Debit Mandate ID" in table "Customer Bank Account" not available in Visual Studio Code

Field "Creditor Identifier" in table "Bank Account" and field "Direct Debit Mandate ID" in table "Customer Bank Account" are not availabe in Visual Studio Code. Docker container is CU14 and AL Language is from CU13. The fields are available in the webclient on de Customer Bank Account Card and Bank Account Card.

@StanislawStempin @JesperSchulz, can someone elaborate on this issue?
Thank you in advance.

I just checked our latest code and cannot find any Creditor Identifier field. What version are you using? Which country? In which version did you last see the field? Do they maybe come from an extension?

Thank you for the quick response.
I believe the fields are part of the dutch localization.
Version: 11.0.26893, Netherlands.
AL Language version: 0.13.68736
Docker container version: microsoft/dynamics-nav:2018-nl-ltsc2019
Object versions:
Table 270, Bank Account, NAVW111.00.00.26893,NAVNL11.00.00.26893
Table 287, Customer Bank Account, NAVW111.00.00.26893,NAVNL11.00.00.26893

I just checked the latest build of version 11.0 of our Dutch application. Both fields exist and should be available for extension development. @atoader, any idea what's going on here?

@atoader , have you had te time to take a look?
Thank you in advance.

Hi! It seems that you are not using the latest developer preview. Could you please open a support case with CSS? They will guide you through the process of reproducing this issue and they will open a request for hotfix with us.

authors: Chingyz JesperSchulz atoader


text:
[Event Request] Table 5005351 / 5876  - CalcQtyAndTrackLinesExpected

Since the target table was renumbered/renamed between BC 13.0 and BC 14.0, this request applies to both

BC DACH 13.0 --> table 5005351
BC W1 14.0 --> table 5876

BC DACH 13.0, table 5005351 Phys. Inventory Order Line
In function CalcQtyAndTrackLinesExpected, please add the following publishers

OnCalcQtyAndTrackLinesExpectedOnBeforeInsertFromItemLedgEntry
OnCalcQtyAndTrackLinesExpectedOnBeforeInsertFromWhseEntry

[…]
          ExpectPhysInvtTrackLine."Quantity (Base)" := ItemLedgEntry.Quantity;
          // >> NEW
          OnCalcQtyAndTrackLinesExpectedOnBeforeInsertFromItemLedgEntry(VAR ExpectPhysInvtTrackLine,ItemLedgEntry);
          // << NEW
          ExpectPhysInvtTrackLine.INSERT;
[…]
            ExpectPhysInvtTrackLine."Quantity (Base)" := WhseEntry."Qty. (Base)";
            // >> NEW
            OnCalcQtyAndTrackLinesExpectedOnBeforeInsertFromWhseEntry(VAR ExpectPhysInvtTrackLine,WhseEntry);
            // << NEW
            ExpectPhysInvtTrackLine.INSERT;
[…]

BC W1 14.0, table 5876 Phys. Invt. Order Line
In function CalcQtyAndTrackLinesExpected, please add the following publishers

OnCalcQtyAndTrackLinesExpectedOnBeforeModifyFromItemLedgEntry
OnCalcQtyAndTrackLinesExpectedOnBeforeModifyFromWhseEntry

[…]
          ExpPhysInvtTracking."Quantity (Base)" += ItemLedgEntry.Quantity;
          // >> NEW
          OnCalcQtyAndTrackLinesExpectedOnBeforeModifyFromItemLedgEntry(VAR ExpPhysInvtTracking,ItemLedgEntry);
          // << NEW
          ExpPhysInvtTracking.MODIFY;
[…]
            ExpPhysInvtTracking."Quantity (Base)" += WhseEntry."Qty. (Base)";
            // >> NEW
            OnCalcQtyAndTrackLinesExpectedOnBeforeModifyFromWhseEntry(VAR ExpPhysInvtTracking,WhseEntry);
            // << NEW
            ExpPhysInvtTracking.MODIFY;
[…]

Note: added in BC 14. as

OnCalcQtyAndTrackLinesExpectedOnBeforeModifyFromItemLedgEntry
OnCalcQtyAndTrackLinesExpectedOnBeforeInsertFromWhseEntry

repo: Microsoft/ALAppExtensions


text:
Support hyperlink markdown syntax in TextBlock

Opening discussion about this. If anyone has scenarios that they feel would strongly benefit from this please let us know
Current state
TextBlock currently supports advanced formatting via a limited set of markdown and formatting functions. One of the current markdown restrictions is hyperlinks.
Proposed change
Enable markdown hyperlink formatting in TextBlock.
[Bing](http://www.bing.com)

This is already supported in the TypeScript renderer.

authors: dclaux matthidinger

repo: Microsoft/AdaptiveCards


text:
autoscroll when new message appears

Yet another change to the paradigm. This is the simple approach:

when a new message comes in, scroll to the bottom.

Fixes #190

I'm not sold on this paradigm. For bots, especially, there will be times I want to scroll back and look at previous results. I don't want the system scrolling me to the end every time something new comes in. Consider a bot that sends me updates on server issues even minute. If I'm looking at a big problem that happened an hour ago, I really want to keep looking at it.

Ok. As @jecristi has pointed out- we should also add a Toast mechanism telling the user that there are new messages. I will retract this PR.

authors: billba danmarshall

repo: Microsoft/BotFramework-WebChat


text:
SIGILL when throwing an exception

Hi,
We found an odd crash of the ChakraCore interpreter (ch) when you "throw a float". It was tested in ArchLinux using revision 627e01bc65455b2dad495bd311a2eced7417e97f.
To reproduce:
$ echo "throw 1.1;" > sigill.js
$ gdb --args ./ch sigill.js
...
Thread 1 "ch" received signal SIGILL, Illegal instruction.
0x00007ffff48832fd in Js::FDblToRgbFast (dbl=1.1000000000000001,
    prgb=0x7fffffffd5a0 "\001\001\377\377\377\177", pwExp10=0x7fffffffd5e0, ppbLim=0x7fffffffd598,
    nDigits=-1) at /home/g/Work/Code/ChakraCore/lib/Common/Common/NumberUtilities_strtod.cpp:1592
1592	        if (wExp2 >= 1023 && wExp2 <= 1075 && dbl == floor(dbl))
(gdb) bt
#0  0x00007ffff48832fd in Js::FDblToRgbFast (dbl=1.1000000000000001,
    prgb=0x7fffffffd5a0 "\001\001\377\377\377\177", pwExp10=0x7fffffffd5e0, ppbLim=0x7fffffffd598,
    nDigits=-1) at /home/g/Work/Code/ChakraCore/lib/Common/Common/NumberUtilities_strtod.cpp:1592
#1  0x00007ffff4888483 in Js::NumberUtilities::FNonZeroFiniteDblToStr (dbl=1.1000000000000001,
    pchDst=0x7fffffffd610 u"1.1", cchDst=256)
    at /home/g/Work/Code/ChakraCore/lib/Common/Common/NumberUtilities_strtod.cpp:2452
#2  0x00007ffff51c14b1 in Js::JavascriptNumber::ToStringRadix10 (value=1.1000000000000001,
    scriptContext=0x555555910d10)
    at /home/g/Work/Code/ChakraCore/lib/Runtime/Library/JavascriptNumber.cpp:928
#3  0x00007ffff4eece7c in Js::JavascriptConversion::ToString (aValue=0xc00d99999999999a,
    scriptContext=0x555555910d10)
    at /home/g/Work/Code/ChakraCore/lib/Runtime/Language/JavascriptConversion.cpp:621
#4  0x00007ffff4424c17 in JsConvertValueToString::$_21::operator() (this=0x7fffffffdba8,
    scriptContext=0x555555910d10) at /home/g/Work/Code/ChakraCore/lib/Jsrt/Jsrt.cpp:1139
#5  0x00007ffff440026a in ContextAPIWrapper<true, JsConvertValueToString::$_21> (fn=...)
    at /home/g/Work/Code/ChakraCore/lib/Jsrt/JsrtInternal.h:139
#6  0x00007ffff440016d in JsConvertValueToString (value=0xc00d99999999999a, result=0x7fffffffdfd0)
    at /home/g/Work/Code/ChakraCore/lib/Jsrt/Jsrt.cpp:1132
#7  0x00005555555685a8 in ChakraRTInterface::JsConvertValueToString (value=0xc00d99999999999a,
    stringValue=0x7fffffffdfd0) at /home/g/Work/Code/ChakraCore/bin/ch/ChakraRtInterface.h:304
#8  0x000055555556e2cb in WScriptJsrt::PrintException (fileName=0x5555558db860 "sigill.js",
    jsErrorCode=JsErrorScriptException) at /home/g/Work/Code/ChakraCore/bin/ch/WScriptJsrt.cpp:1006
#9  0x000055555555e34c in RunScript (fileName=0x5555558db860 "sigill.js",
    fileContents=0x5555558cfc10 "throw 1.1;\n", bcBuffer=0x0,
---Type <return> to continue, or q <return> to quit---
    fullPath=0x7fffffffe520 "/home/g/work/code/chakracore/buildlinux/debug/sigill.js")
    at /home/g/Work/Code/ChakraCore/bin/ch/ch.cpp:342
#10 0x000055555555f4f6 in ExecuteTest (fileName=0x5555558db860 "sigill.js")
    at /home/g/Work/Code/ChakraCore/bin/ch/ch.cpp:587
#11 0x000055555555f5e0 in ExecuteTestWithMemoryCheck (fileName=0x5555558db860 "sigill.js")
    at /home/g/Work/Code/ChakraCore/bin/ch/ch.cpp:635
#12 0x000055555555fb20 in main (argc=2, c_argv=0x7fffffffe868)
    at /home/g/Work/Code/ChakraCore/bin/ch/ch.cpp:862

This issue was found using QuickFuzz.
Regards,
Gustavo.

@gaa-cifasis I'm unable to reproduce this issue on Ubuntu, OSX, Fedora.
From your comment; looks like it fails on floor call.
It might be because of the OS itself ?

I dont know. Just in case, i'm compiling using gcc 6.2.1 and ChakraCore is failing here:
(gdb) x/i $rip
=> 0x7ffff48832fd <Js::FDblToRgbFast(double, unsigned char*, int*, unsigned char**, int)+509>:
roundsd $0x9,%xmm1,%xmm2

Could you please send the outputs for the commands below;
/sbin/ldconfig -p

cat /proc/version

Thanks

Sure thing!
ldconfig.txt
proc-version.txt

I have installed arch-linux during the weekend and tested the case above.
It works without a problem. I also see ChakraCore tests cases are passing on Arch-Linux.
I'm really happy to see ChakraCore works on one another Linux distro.
Linux version 4.8.6-1-ARCH (builduser@tobias) (gcc version 6.2.1 20160830 (GCC) ) #1 SMP PREEMPT Mon Oct 31 18:51:30 CET 2016

One thing for sure, ArchLinux (latest) defaults to clang 3.9 on pacman.
We have a compatibility issue with Clang 3.9 and I'm about to send a PR for that fix.
Thanks for the report. At this point I'm unable to do anything else. I suggest you to update to latest Arch-Linux (if it is possible and sync to latest master after the Clang 3.9 PR)

@gaa-cifasis FYI; https://github.com/Microsoft/ChakraCore/pull/1930

authors: gaa-cifasis obastemur

repo: Microsoft/ChakraCore


text:
crash: es6/default-splitscope.js crashes randomly [master]

CCRobot found an issue on master branch;
command line;
out/Test/ch -WERExceptionSupport -ExtendedErrorStackForTestHost -BaselineMode -forceNative -off:simpleJit -bgJitDelay:0 -dynamicprofileinput:profile.dpl.2047 -force:deferparse -args summary -endargs /home/helixbot/dotnetbuild/work/f4c635b9-0126-4e05-bca5-b9d29a52af95test/es6/default-splitscope.js

Output:
----------------------------

----------------------------
exit code: -11

It is hard to repro. The bug possibly introduced into master branch late last week.

Turning off automated issue closing for this one on CCRobot repo. Details : https://github.com/CCRobot/TestResults/issues/116

It's been 2 months and no repro. closing


text:
Reorder the ByteCodeUse and Cm/Br(Sr)?[GL][te] instructions in the unsigned compare peep

This helps avoid situations in which the arguments to the compare op
would get optimized out too aggressively, and are then unavailable in
exceptional cases.

Hi @Penguinwizzard, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Derek Morris). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Fixes https://github.com/Microsoft/ChakraCore/issues/1627. @rajatd please review.

:shipit:

authors: Penguinwizzard msftclas rajatd


text:
Disabling StackArgs when the source is inside eval expression

This is a bug fix - where one of the assumptions was failing as an
assertion failure - This is true only when the source is inside an eval
expression.
Though the fix for this bug is really straight forward, I have decided to
disable the optimization when the source is inside an eval expression - to
minimize risk.

@aneeshdk @pleath : Can you please take a look ?

LGTM. BTW, I assume that we don't attempt stack args when "arguments" appears at global scope in eval?

:shipit:

LGTM

@pleath : Yeah. Just verified. Looks like we are good in the scenario that you mentioned.

@dotnet-bot please test osx_osx_test

@dotnet-bot : please test OSX

authors: aneeshdk kunalspathak pleath satheeshravi