大道无形若水 关于“一定要迁就老的”，我觉得是对我的回复的一种误读
我举例发行版，新老世界都有提及，包括新世界的ArchLinux，arch上使用的也是loongarch
其实这个讨论，和新老没什么关系，也不存在新老世界发行版互相迁就的事情。
这其实只是个关于选择的讨论，但选择是要有出发点的！
同意你的一个观点，“不是为了做事情而做事情”
既然是为了LoongArch的生态，那么一些坚持和互相尊重也应该有所体现
杜比 更何况，内核和基础工具，已普遍采用loongarch，这不正说明loongarch接受度的普遍性么，这也是一种约定成俗，我个人希望开发者也要尊重这一点！
假如真的存在“普遍性”，那么上游社区就用会直接用loongarch了，而不是上游开发者们讨论后最后决定loong了
其实讨论到这里，大家估计也发现了，slackware ARCH选择的问题大家都知道，“长”这个问题是客观存在的，我们自己都能感觉到，同理来说上游社区的开发者也是能感受到。
其实LoongArch发行版的ARCH选择的问题很好，讨论中，其中有坚持loongarch64坚定者派、中立派(都还行，理解双方的坚持原因)、也有上游社区开发者派，但不管如何我们都是为了LoongArch生态做贡献，LoongArch加油！
大道无形若水
首先，上游社区对发行版的arch，是否有字符数限制，我了解到的，是没有！
如果某个上游，早已有字符限制，loongarch做为后进，遵守上游规范，做一些缩写上的折中，无可厚非。
其次，loongarch 这个字符串有点长，是现实，linux，binutils和gcc 接纳并使用了这个字符串，也是现实
起码说明，字符串的长度，不是上游社区的主要障碍。
最后，无论持哪种观点，属于哪个派别，关于ARCH的选择展开讨论，无疑对LoongArch的生态建设都是好事！
我喜欢这种讨论，比一言堂好太多了。
但讨论归讨论，最终还是要形成方案。
即已成事实的，就不要再追究当事人的责任，
形成方案的，对于没有接受的方案提案人也不要心生不满。
再者，毕竟不管开源社区如何开放，那也是别人的地盘，他们有强烈的倾向，不接受我们的提案，也就只能尊重他们了。
针对这些，就只能说，开源社区我们的 人多多，或者我们有自己的根社区。
再提一点吧。有人说“尊重龙芯的观点”，好像龙芯说这玩意叫 LoongArch 全世界软件就只能用这九个字母来称呼它了，那么两方面：
loongarch
本质上这个讨论已经和字符串长度没什么关系了，其实核心在于“对一个技术问题，A进了B项目的房间，说我想这么做；房间里其他人说这样可能不好，要不这样？A不同意”这个场景怎么解决。如果 A 说得本来就有道理，就不会起争端了。这里显然 A 初来乍到，不一定是对的，最终肯定是按事情本身的客观逻辑、“是非曲直”来解决的（显然也可能最后房间里的人发现 A 提出了一些新的有价值的东西，进而认同了，当然在架构名字这一方面龙芯并不能作出如此有说服力的辩论）。不能说因为 A 是龙芯公司，他的做法、做派就一定正确了。
xen0n
我和龙芯一毛钱关系没有，这是其一，能拿这个来质疑，我只能呵呵
第二，龙芯推出的这个指令集，它有名字，有中英文手册，而不是和社区说，“嗨，我弄了个指令集，名字大家随意叫”
第三，哪句话有民族情绪了？请指出，别乱扣帽子！
杜比 我和龙芯一毛钱关系没有，这是其一，能拿这个来质疑，我只能呵呵
我承认，这是辩论话术，因为你显得非常为龙芯辩护，尽管他在这一方面并不很受待见。并且似乎我和楼主从上游角度的解释仍然并不为你和你观点的支持者所认同，因此我觉得辩论不容易进行下去。
杜比 第二，龙芯推出的这个指令集，它有名字，有中英文手册，而不是和社区说，“嗨，我弄了个指令集，名字大家随意叫”
前面应该已经提到至少两三遍了，默认大家也都是叫全称的。本身目前现状也是只有在上游已有命名规范的时候，才不叫 loongarch。目前所有不叫全称的地方都是因为上游有明确观点不支持长名字。没喷点
杜比 第三，哪句话有民族情绪了？请指出，别乱扣帽子！
这是针对 @龙芯中科 的，不是针对你。放轻松。
回到主题，关于ARCH的选择，我依然是这样的一个观点：
尊重龙芯，尊重上游，求同存异！
既然龙芯有手册，有官方的中英文名称，那么要做基于loongarch的发行版，就尽量到上游去争取使用这个名字。
开源社区本身就是在不断的争执和竞争中发展起来的，有理有据争取也是对技术的尊重。
所以，期望参与讨论的开源爱好者们，别带情绪，据理力争，有事说事，共建社区交流氛围
毕竟，沟通，是求同存异，消弭误解的有效桥梁！
杜比 赞同了。
再次重复一遍，目前据我所知，即使利益无关的第三方开发者对 LoongArch 的移植行动，就架构命名而言，也以 loongarch / LoongArch / LOONGARCH 为优先，但上游明确表示需要较短名称的情况除外，此时会一致选择尊重上游现存代码风格。
loongarch / LoongArch / LOONGARCH
至于龙芯员工向上游提交代码的情况，先前确实存在有不尊重上游现状，甚至明显错误（例如认为所有 MIPS 都是龙芯，抄 MIPS 做 LoongArch 移植，认为只要 LoongArch 就是 64 位，等等）的情况存在，这些只要被发现，无一例外都会被以相同标准，一视同仁地被要求修改，当然最后谁有道理听谁的。不要对这个情况有微词，社区开发者往龙芯的库提交代码被无理由驳回甚至直接晾一边的情况也不少，彼此彼此而已。
最后，吵起来可比一声不吭、闭门造车、自绝于群众（不光国际群众，中国群众之前他们也绝）好太多了。珍惜现状并基于此再向前进才是好的。
很喜欢最后大家的意见。有争吵比没争吵绝对要好很多。一定要放下傲慢的态度，也不要用国产情怀当盾牌，关起门自己玩。技术的事情最后一定要归技术。
其实我不明白为什么不学习arm，使用LArch这种名称呢
lingfengzhe 看完整个帖子，你就会发现，有些东西xen0n已经说得很清楚了。有些东西就是中英文习惯的问题。就像表头是架构名（类型），里面其他是ARM，X86，MIPS，Loong，这样就感觉很正常。你叫Loongarch就显得冗长 。所以我个人的建议，能完整用的时候就Loongarch，需要缩写的时候就Loong。
PS：感觉大家对完整写法没有意见，现在成了讨论缩写规范了。
lingfengzhe 其实我不明白为什么不学习arm，使用LArch这种名称呢
曾经就是 larch，有的地方现在还是：例如工具链里的重定位类型。（没错，龙芯中科自己就搞不一致，一边 loongarch 一边又 LARCH。之前跟他们提过要不要改 LOONGARCH 或者 LOONG 被明确拒绝了，而且没实质理由。说法大致是“工具链项目统一使用 larch”但没有给出其他原因。）
larch
LARCH
LOONGARCH
LOONG
至于曾经使用过 larch 的证据，在极早期的一些龙芯工具链 fork 项目中可以窥见端倪：例如龙芯的 Go 1.15.6 fork，第一个 fork 提交使用的名字就是 GOARCH=larch64。
GOARCH=larch64
后边直到提交上游前夕，才批量替换成 loongarch64。再后来的事情大家也都知道了，他们批量替换了第三次。。
loongarch64
按说，龙芯注册了 LArch 的商标，应该用起来，或者至少早些时候就开始宣传以此作为 LoongArch 的简称才对。结果他们并没有。。LArch 也基本被世人遗忘。现在已经没有机会回去了，较短名称已经到处都在用 loong 了。从推广中国龙文化（Loong != Dragon）的角度，倒也是一件好事。。
LArch
REDEAST 感觉大家对完整写法没有意见，现在成了讨论缩写规范了。
这个也是没办法的事情，他们工具链上提前占位了 loongarch64-unknown-linux-gnu 了，unknown 的部分大家都一样（历史原因），后边大家也一样，就是前面太 tm 长了。可能是搞 mips64el 多了不觉得 loongarch64 长了，毕竟 MIPS R6 更长：mipsisa64r6el 表示 MIPS64r6 小端。除此之外，差不多长的架构也就 microblaze 这种了，LA 绝对是可预见的未来“常见”架构里名字最长的了。
loongarch64-unknown-linux-gnu
mips64el
mipsisa64r6el
microblaze
既然 GNU target tuple 事实上已经定下来了，那为了一致，只好尽量在别的地方厚着脸皮往里推了。当时在 review systemd 代码的时候，纠结半天，还是用 ARCHITECTURE_LOONGARCH64，很难绷住，最后整个文件一大片定义都重新做了遍垂直对齐。。
ARCHITECTURE_LOONGARCH64
https://github.com/loongarch64/systemd/pull/5
https://github.com/systemd/systemd/pull/21288/files
Larch 替换了三次说明他们在做之前都没想好，或者公司宣传口的变化，或者没有意识到这是个问题。
至于对齐，其实不算个事，这个对齐都是长的加进来慢慢变的。
大道无形若水 龙芯64位架构
lx64类比 sw64
时空质能 下划线发不出来
5.LoongArch Slackware current bootstrap项目源码地址：https://github.com/shipujin/slackware-loongarch64
6.发布v0.1:LoongArch-slackware64-current-bootstrap-20220708：详细信息请看 Release v0.1
LoongArch slackware64 current系统使用的核心基础软件三件套(除glibc使用的是github下的loongson/glibc)，像gcc、binutils、linux-headers都是使用上有社区release版本，具体软件版本可查阅项目的Release/v0.1
最近我在玩LoongArch Slackware，都想仰天长啸，太爽了
因为Slackwae是一个编译打包（编译过程中缺失会正常输出缺失的东西）、安装、移除软件不提示依赖关系的
所以在构建LoongArch Slackware64 current bootstrap时，我想编译啥编译啥，完全不像移植其他distro时被发行版自身识别的依赖搞得烦躁，
构建LoongArch Slackware完全随身所欲(个人需谨慎(狗头，自我发挥性高，让我有种回到了LFS时期，但又有简单的包管理器去控制系统，真的太爽啦！！！
大道无形若水 软件依赖问题怎么解决？还有大佬，你的自动交叉编译工具能放出来吗？学习学习
本站文章除其作者特殊声明外，一律采用CC BY-NC-SA 4.0许可协议进行授权。进行转载或二次创作时务必以相同协议进行共享，严禁用于商业用途。
