水木社区手机版
- 主题:[转载]容器化打包格式不是 Linux 应用的未来
- 一个技术当然有它的定位和价值，容器在强调快速迭代的运维部署上用的就很舒服。
但如果因此导致泛滥了，以至于所有的东西都容器化打包，那这个就是邪路。
这个问题的关键就在于，“如果链接做的好其实没多大”这个前提不存在。我相信你和这里的很多人都能毫无问题的做到这点，但架不住千千万万的后来人做不到甚至是懒得考虑到这一点。因为容器化的本质是鼓励你不用在打包上花费太多心思。一个哲学上就走糙快猛的路线的方案是不会催生出精细的结果的。现实的结果就是大家都塞个浏览器进去当UI，都是起步就是100M，什么几M的web框架根本就不重要。
【 在 Knightmare 的大作中提到: 】
: 邪路吧，谈不上。
: 其实就是本来应该在编译期解决的问题丢给了部署期，最后就是看哪边能力强呗。
: 至于web框架，如果链接做的好其实没多大，可能也就几M。
: ...................
--
修改:lvsoft FROM 180.109.232.*
FROM 180.109.232.* - 【 在 lvsoft 的大作中提到: 】
: 打包地狱不就是另一个依赖地狱么？没区别的。
: 你这个例子属于quassel自己的问题。正常情况只会带上FFMPEG的包（libavformat,libavcodec等那几个），不可能把vlc也扯进来。除非quassel就是用system("vlc xxx.mp3")来给你发出咚的一声。
: 那这样容器化打包你一样得有vlc和ffmpeg。
: ...................
我觉得这个事你得问debian那个打包的是怎么想的，你想装quassel他就是会给你装vlc，不过有折衷的办法，就是你装一个虚拟的声音服务还是什么的，忘了，反正就挺麻烦
--
FROM 120.244.234.* - 这玩意只能在资源不要钱的情况下玩。
我们原来的开发服务器8g内存够跑应用服务加CI一整套，自打用了docker，内存翻倍还不够用。
【 在 hgoldfish 的大作中提到: 】
: 在 Linux 桌面上部署应用曾是一件难事，问题在于库兼容性。不同的发行版，或相同发行版的不同版本，都有着不兼容的库。Linux 桌面缺乏向后兼容的文化传统。但情况已经发生了改变。Linux 桌面的稳定性最近几年有了显著的改善，核心库的开发者终于看到了维护兼容性的好处。尽管如此，应用开发者并没有充分利用预装在发行版上的稳定库，而是转向了容器化打包格式 Flatpak、Snap、AppImage、Docker 和 Steam：运用容器技术将所需要的运行时库直接封装在应用内。Flatpak 自称是应用发行的未来，但容器化打包格式并不是 Linux 应用的未来。简单举一个例子，AppImage 的计算器应用 KCalc 高达 152 MB，Flatpak 的相同应用 KCalc 在系统上首次安装需要下载 900 MB，而事实上 KCalc 应用本身只有 4.4 MB，其余都是系统上已安装了的冗余库。再下载一个 GIMP，两个应用就占用了 3GB 磁盘空间。除了更大的磁盘空间外，容器化应用还会占用更多内存，启动时间也更慢。想象下，为了启动一个计算器应用你每次需要等待 7 秒钟。
: https://ludocode.com/blog/flatpak-is-not-the-future
--
FROM 119.130.231.* - 我看了下没有呀，而且尝试安装也没让我装vlc啊。
我觉得是你让它把某个依赖包的推荐包都装上了吧
【 在 ayaka 的大作中提到: 】
: 我觉得这个事你得问debian那个打包的是怎么想的，你想装quassel他就是会给你装vlc，不过有折衷的办法，就是你装一个虚拟的声音服务还是什么的，忘了，反正就挺麻烦
--
FROM 180.109.232.* - 【 在 lvsoft 的大作中提到: 】
: 首先，没有哪个发行版会把qt和kde捆上，更大的可能性是你装的那个东西依赖了kde的某个组件，顺带牵上了整个kde+qt。
: 讨论问题首先要基于一个正确的事实。不然你装啥都可以说成要下载200G依赖。毕竟所有的软件都要libc，按你的逻辑既然都能跟libc捆上，也就是任何包都能关联所有的包了。
: 其次，打包地狱和依赖地狱本质上是一回事。本质上是足够丰富足够庞大的生态自带的复杂现象。好比perl的哲学认为世界是复杂的，所以就应该There's more than one way to do it一样。这只是一种哲学路线的选择。所以既然打包地狱和依赖地狱没区别，那就选择依赖地狱，至少比打包地狱好一点。这也是我上次在这里发帖的时候说的不喜欢用docker的原因。因为打包地狱这种思路只是用起来爽，并不符合整个系统的设计哲学。
: ...................
正确的事实是正确的事实，实际的现象是实际的现象，对你来说可以分清，对其他人就不一定了，我要装一个东西，发行版的打包者决定的依赖造成的问题，有时候不是上游开发能决定的，你可以说我不需要XXX，我只要YYY，然而发行版打包的认为你YYY需要zzz，然后zzz强依赖XXX，到时候就是说不清的混乱，所以现在看见装软件包就发怵，到最后/usr/local里还是有一些自己编译的包，原因很简单，发行版的打包参数不符合自己的需求
--
FROM 120.244.234.* - 【 在 lvsoft 的大作中提到: 】
: 我看了下没有呀，而且尝试安装也没让我装vlc啊。
: 我觉得是你让它把某个依赖包的推荐包都装上了吧
: [upload=1][/upload]
这问题是很久之前，少说得三年以前的事情了，现在打包是不是改了依赖我也不知道，毕竟我又不是debian developer
--
FROM 120.244.234.* - 【 在 ayaka 的大作中提到: 】
: 这问题是很久之前，少说得三年以前的事情了，现在打包是不是改了依赖我也不知道，毕竟我又不是debian developer
--
FROM 120.244.234.* - 那我的观点就是，如果能力还不足以正确的解决这个问题，要么提升能力到能正确解决为止，要么就转行别走这条路，去做自己更擅长的事，然后雇个专业的人来解决这个问题。
能用发行版安装的包都不是事，不能用发行版安装的，有些复杂一点的大型系统，配一个月都是很正常的。你这里这些所谓的“说不清的混乱”，只是毛毛雨罢了。
【 在 ayaka 的大作中提到: 】
: 正确的事实是正确的事实，实际的现象是实际的现象，对你来说可以分清，对其他人就不一定了，我要装一个东西，发行版的打包者决定的依赖造成的问题，有时候不是上游开发能决定的，你可以说我不需要XXX，我只要YYY，然而发行版打包的认为你YYY需要zzz，然后zzz强依赖XXX，到时候就是说不清的混乱，所以现在看见装软件包就发怵，到最后/usr/local里还是有一些自己编译的包，原因很简单，发行版的打包参数不符合自己的需求
--
FROM 180.109.232.* - 某些东西依赖phonon4qt5，而这玩意需要有一个backend，它自动选上的
是backend-vlc，然后就依赖vlc了……如果先装backend-null就不会依赖
vlc，当然还有其它的见鬼依赖要解决……
Debian这个发行版的基本理念是可以完全通过二进制安装来搞定一切，
所以打包会有很多复杂的拆分，有互斥特性的就打包成不同的变体，
有动态可加载模块的就拆出模块，遇到实在拆不开的也不方便做变体的，
那就只好多依赖了。
跟Gentoo和Arch的玩法不太一样。基于源码编译（或者二进制/编译混合）
的发行版处理这种问题当然就好做得多。
【 在 ayaka (ayaka) 的大作中提到: 】
: 我觉得这个事你得问debian那个打包的是怎么想的，你想装quassel他就是会给你装vlc，不过有折衷的办法，就是你装一个虚拟的声音服务还是什么的，忘了，反正就挺麻烦
--
FROM 122.233.190.* - 你看，这不就有个推荐嘛，
debian这种又保守又严谨的风格，不太会出现这种乱七八糟的事情的。
【 在 ayaka 的大作中提到: 】
: [upload=1][/upload]
--
FROM 180.109.232.*