loongarch64 or loong64? 不仅需要共识，更需要规范

sarto

从 Golang 引入 loong64 之后，loong64 被许多社区广泛采纳，诚然这是因为 loong64 更简洁，但目前使用 loongarch64 还是 loong64 仍然没有较为正式的规范，依然是不同 commiter 和不同的社区自行磋商，甚至产生了 debian 从 loongarch64 转为 loong64 的情况。所以希望能有一份正式的规范，给开发者提供一个参考是使用 loongarch64 或者 loong64。

ghw

😀 明显la64或者loongarch64好看，但是社区不认呀

xen0n

您可以将对《如何称呼龙架构？》一文的修改意见直接提交~

sarto

我阅读了《如何称呼龙架构》，除了早期 gnu target triples 已经成为事实规范而确实无法变更之外，其他的社区因为进度问题还存在商议的空间，例如 asoc，rpm，alpine系，目前均未正式发布系统，而统一采用 loong64 带来的好处是显而易见的。我个人的看法是：

asco 因为曾经有 loongson2f 等原因希望沿用 loongarch64 ，可以进行一些意向调查，毕竟在没有大范围采用的实践的情况下，改用 loong64 与 debian 和其他社区保持一致或许更合适。
rpm，alpine 和上面的问题一样，甚至仅提交了包管理架构约束部分，还没有正式开发操作系统，而提交者并没有过多的考虑 loongarch64 or loong64，仅仅是可以接受，如此而已。
loongarch64 是唯一的官方名称，而 loong64 在社区中出现之后，因为其更简约不断被社区认可采纳，病毒式的扩散或许当时 golang 使用 loong64 的时候也没有想到影响能如此深远。
loong64 是趋势，其扩散性不可限制，而 loongarch64 却可以被限制在已经形成事实标准的项目中，统一架构名称的时间不多了，当然前提是你认可架构名称应该统一。

xen0n

sarto
aosc 因为曾经有 loongson2f 等原因希望沿用 loongarch64 ，可以进行一些意向调查，毕竟在没有大范围采用的实践的情况下，改用 loong64 与 debian 和其他社区保持一致或许更合适。

这个是项目维护者亲自解释的：跟随龙芯官方立场

rpm，alpine 和上面的问题一样，甚至仅提交了包管理架构约束部分，还没有正式开发操作系统，而提交者并没有过多的考虑 loongarch64 or loong64，仅仅是可以接受，如此而已。

改不了了，Fedora LoongArch Remix、ALT 都已经有可用版本了，Alpine 也过了比较久。当年马上发现并修改可能可行，现在这么做只会让所有人都要重新打一遍包

loongarch64 是唯一的官方名称，而 loong64 在社区中出现之后，因为其更简约不断被社区认可采纳，病毒式的扩散或许当时 golang 使用 loong64 的时候也没有想到影响能如此深远。
loong64 是趋势，其扩散性不可限制，而 loongarch64 却可以被限制在已经形成事实标准的项目中，统一架构名称的时间不多了，当然前提是你认可架构名称应该统一。

遗憾的是，虚指的“你”“我”说了不算，这不能代表共识。确实不是所有人都认可“架构名称应该统一”。

REDEAST

个人支持使用loong64

driver1998

xen0n 这个是项目维护者亲自解释的：跟随龙芯官方立场

这个会导致AOSC用不了给Debian打的deb包吧？不过这也许是合理的？两个发行版的软件包依赖树也不一样。

sarto

xen0n 改不了了，Fedora LoongArch Remix、ALT 都已经有可用版本了，Alpine 也过了比较久。当年马上发现并修改可能可行，现在这么做只会让所有人都要重新打一遍包

Fedora 和 ALT 是爱好者自发的版本，不影响他们已经发布的系统和版本，也并不需要重新打包，我意思是如果要向上游（官方）推动的时候，是否可以考虑统一切回 loong64

xen0n 遗憾的是，虚指的“你”“我”说了不算，这不能代表共识。确实不是所有人都认可“架构名称应该统一”。

确实不是所有人都认可“架构名称应该统一”，就像不是所有人都认可“架构名称不应该统一” 一样，需要更多的沟通

xen0n

driver1998 这个会导致AOSC用不了给Debian打的deb包吧？不过这也许是合理的？两个发行版的软件包依赖树也不一样。

正是如此。AOSC属于所谓“根发行版”，不追随任何其他发行版。近期它对deb格式的使用也仅仅是借用这一容器格式了

farter

个人支持统一loong64

说的越多，拖得越久，这个事感觉可能只有干脆表态比较利于发展【捂脸】就很尴尬

理由很简单，短，不重复“arch”】

反aarch64，赞成arm64，但x86老坑就不想管了【

yuokor

同样建议使用 loongarch64 作为架构名！

AOSC OS 不也是使用的loongarch64作为架构名吗，也没见人家哪里不好用了，其软件生态也可以说是目前几个发行版里算好的那几个之一了吧（不敢说最好），而且如果修改成loongarch64作为架构名还能够直接使用上 AOSC OS 所提供的软件生态（不确定，应该可以吧，因为龙芯应用合作社里打包的软件就可以在loongnix、kylinos、uos里面通用的）

（请勿喷，多说一句）而且后续龙芯的loongninx应该也会从旧世界迁入到新世界版本的吧，他们应该更愿统一采用loongarch64作为架构名吧，统一架构名loongarch64为的话，后续龙芯有没有可能实现从loongnix旧世界无缝迁入到新世界版本？

yuokor

而且目前看来，deepin V23 for loongarch 并没有做到之前 deepin 社区所说的要做自己的根社区，而是继续在做 debian 的下游社区，这一点很可惜，目前看来 deepin 社区的开发者们还没有 AOSC OS 开发者们有魄力，至少 AOSC OS 是着手做根社区了。

yuokor

对了，还有一点就是，使用 loong64 作为架构名的话，会不会容易把龙芯的嵌入式信息系统LoongOS 搞混？

误以为是工控类操作系统LoongOS 专用的

hanzn-zzx

支持loong64，用loong64和loongarch64区分新旧世界其实不错

还有deepin23RC的龙芯版本也用的是loong64（有些用loongarch标的软件装不进去……就非得用ACE

yuokor

hanzn-zzx 可以使用AOSC OS 😄

支持loong64不动摇

moxqq

貌似现在ArchLinux系统就是loong64的了。。。搞得钉钉之类的都用不了。。。

yuokor

moxqq 建议可以使用AOSC OS 😀

fqucuo

叫loongarch64吧，这样龙芯的死的快一点，明明龙芯全公司都没想过还可以叫loong64，但为啥最后叫了loong64你自己心里没点b数吗？这事都多少年了换各种渠道反复当新问题提你什么目的？当然，这个争论最开始就是龙芯的人挑起来的，我记得好像说了句“龙芯高层领导最终决定叫loongarch64”，真tm恶心到我了，还真有中国特色，丢人丢到海外去，说实话叫loongarch64还是loong64真无所谓，但别把事做的那么恶心，更别恶心到国外去！我现在看到loongarch64这个名字就能想起这事，真tm丢人，写这些不算是冲你，就是看到这恶心的标题就想起这恶心的事进来吐一下

REDEAST

fqucuo 坚决不用叫loongarch64的系统，哈哈哈哈。

本站文章除其作者特殊声明外，一律采用CC BY-NC-SA 4.0许可协议进行授权。
进行转载或二次创作时务必以相同协议进行共享，严禁用于商业用途。