谁组织
这个组织叫Linux发行版
一般来说,跟 Debian 的比较多
这个组织叫Linux发行版
一般来说,跟 Debian 的比较多
emm...怎么说呢,我的意思是像一个框架一样组织起来,不是零散的,一个库不能好几个版本共存,只能存在唯一 的一个版本,
像conda那样的
然后弄一个总的-dev或者framework之类的
想法挺好的,但是实现起来估计不太容易
emm...怎么说呢,我的意思是像一个框架一样组织起来,不是零散的,一个库不能好几个版本共存,只能存在唯一 的一个版本,
像conda那样的
然后弄一个总的-dev或者framework之类的
那就是好几个库共存咯
并不难,只是发行版不愿意维护ABI不再更新的旧版
比如libicu63,其实完全可以和新的libicu共存,但是发行版就是要把这个去掉
所以呢,都让玲珑了
你要找的是不是发行版(fixed release)
你要找的是不是flatpak
所以呢,都让玲珑了
是的,玲珑是这个思路,但是玲珑控不住开发端那边用的版本诶
那就是好几个库共存咯
并不难,只是发行版不愿意维护ABI不再更新的旧版
比如libicu63,其实完全可以和新的libicu共存,但是发行版就是要把这个去掉
是这样,
但我的重点就是在于开发端那边,让开发者跟着用
给出限定的东西,限制住开发者,开发端,不太给太多的版本给开发者,
就好像在win上,开发者开发的软件明确表示不支持xp及以下的系统就是不支持,因为我使用了2027-dev的开发框架或者组件,你想要用这个软件,麻烦增加一个你的linuxlock2027大版本库,哪怕是两年出一个大版本,2024,2026然后每6年淘汰一个最旧的版本,也就是到2028版本的时候,淘汰掉2024的版本,也就是我系统包默认不自带2024了,带的是2026,这样就可以保证了系统包所需要的库和开发者的软件的库不容易冲突了,不是吗?更不需要用户一个一个的依赖库去安装,
就好像把所有细小的耦合变成聚合。
这个东西,听着和flatpak很像
你说的东西很好,但有一个最大的问题,就是deepin的号召力和威望!
这个世界需要权威,那就是deepin定下规矩就是规矩,不要反驳,只能接受,可需要deepin在操作系统上有非常多的市占率,才能有这样的威望。就想苹果一样,微信不听话,可以不让你更新,交30%的税才可以,这就是规矩。
现在的deepin,只能建议,号召,目前只能这样。
其实,再好的说法不如买一块龙芯主板,把国产系统的市占率实实在在的提上去,只有市占率上去了,才有市场话语权,其他都是空话。
这里的码农起码10万,有5万码农买一块龙芯主板,作为家庭主力机,什么生态都可以解决了,最起码,常用的商业软件都健全了,这才是最好的生态建设,如果有10万个人消费者用户主动购买,那deepin想不发展都要发展起来了,再加上跟风进入的,那在世界上的普及率都会一发不可收拾。
实际行动才是最可贵的,建议就是不痛不痒,没实际作用。
谁弄
您说的这个组织,它是不是叫工信部?它的规范目前锁死了 deepin 23/25 的 glibc / gcc / llvm / binutils 这些基础库的版本
参考资料:https://github.com/deepin-community/infra-settings/issues/134
Popular Events
More
如题,为什么不能建立一个组织,这个组织(暂且叫为linuxlock,下称lock组织)让大家来提交自己的库的版本(暂且要求为大版本号,当然也可以是截止到提交时间的版本)
假如2024年这个lock组织,让大家固定在某一天,例如1月1号提交自己的版本库上来,假设有5000个库提交上来了,
那好,这个组织就出一个总的版本叫做Linuxlock2024版本库,同时也让他们提交对应的开发库,出一个总的开发库叫做Linuxlock2024-dev,
周期更新定一个时间,可以为三年,四年等等。
开发者直接用2024-dev的版本去开发,这样系统支不支持,开发者一看这个系统是否有Linuxlock2024版本库不就高效很多了吗?
这样开发者舒服,使用者也舒服,依赖问题也减少很多了,不是吗?
至于怎么组织起来让大家提交?那这个得达成共识了。