fp 估计暂停了

个人觉得flatpak还是很优秀的

现在很多软件都使用AppImage打包，里面自带依赖，在大多数Linux发行版上都能运行，下载后可直接运行，我一般是给它写一个.desktop文件放在启动器里用。

本帖最后由 duanquanyong 于 2020-4-4 12:39 编辑

deb包的依赖问题太恶心了.
缺少依赖,层层依赖,小白不会装
依赖冲突,只能二选一
不同架构平台还不一样
...用deb包就是把这些问题全丢给用户. 普通小白用户直接劝退.

flatpak 这些就是让开发者把依赖都打包进去, 用户只管安装就行了. windows的安装包大多是这种模式.
你可能会说,那不要安装外面直接下载的deb包,到深度商店安装不就行了?
第一, 深度商店应用太少, 很多时候不得不取软件官网下载deb包,第二,  深度商店下载的deb包应用很多我现在也用不了,比如mysqlworkbech我现在使用geo功能,就提示缺少依赖
如果深度只想面向开发者,这些可能不是什么问题,但是如果要成为windows那样面向所有普通用户的操作系统,那不得不解决这个问题, deb包当然可以继续支持,但是应该提供一套更现代的应用打包机制.
就像mac操作系统, 支持pkg安装包,也支持.app单文件应用.  

本帖最后由 abcfy2 于 2020-4-4 12:46 编辑

瞎扯淡，依赖问题都是小白照着网上不知道哪抄来的文章瞎搞一通，不乱搞仓库依赖会搞坏？可笑不？

依赖的设计就是为了优雅的解决软件安装问题，有效利用系统资源，让啥都不懂的人乱喷一通简直醉了
如果flatpak这么牛逼，你告诉我为啥没有一个发行版会以flatpak作为包管理器？说到底就是它根本没能解决系统的依赖，反而自己又搞一套更复杂的依赖管理，造成绝大多数应用程序根本没办法在这种奇怪的沙箱环境运行，造成了更大的开发难度。而且由于各种隔离问题造成了更复杂的使用，奇奇怪怪的权限和沙箱目录结构。你自己开发一个flatpak应用就知道了，我可是给flatpak应用提交过源码的，用过之后再也不想写第二个flatpak

我知道deb有规范，但问题是依赖问题很难搞，我以Firefox为例就是想让官方看看能不能试着解决依赖问题，我们可以自己试着解决看看，而不是等着国外的flatpak之类的解决方案。深度是面向普通用户的，要是更新个软件系统依赖挂了就好玩了；又或者等官方打包应用，更新不及时又消耗很多人力物力。

不觉得手动生成desktop文件是很low的操作吗？制订一套macos的app打包机制很难吗？

还得自己写desktop文件，差评

我的意思是深度商店安装，你点一下安装按钮，商店自动下载解压应用，同时在开始菜单生成desktop文件，不是自己写，这是针对Firefox这种压缩包

以下是深度大神老王的简书，我复制了一段，你自己看看，不懂别装懂
FlatPak vs Snap
Linux桌面发展到今天依然无法和微软以及苹果系统本身竞争的一个重要原因就是，Linux系统软件包之间的依赖问题，系统和应用之间的紧耦合，应用和应用之间的依赖库紧耦合，只要底层库升级了，系统升级有可能会把应用升级挂，一个应用升级很有可能会导致另外一个应用无法使用。
如果把系统所有的软件包和应用的依赖打印出来，你会发现整个桌面Linux操作系统就像一张巨大的错综复杂的蜘蛛网，蜘蛛网的任何一环坏掉都会引起系统和应用不稳定甚至无法使用的问题，同时应用厂商为了开源社区的诸多底层库升级疲于奔命, 最后的结果是，Linux操作系统在底层5万个软件包，2000多个应用，700个精品应用的时候，就已经非常非常的不稳定了，如果有一天Linux平台有上十万个应用的时候，系统和应用一定是崩溃的，因为任何底层的技术革新都会带来应用厂商的应用会失效或者因为API不兼容最后无法运行。
所以，为了迎接将来Linux操作系统应用生态爆发的那一天，Linux操作系统必须像微软和苹果那样，在系统和应用之间构建一条抽象API层，有点类似微软的 Win32 API和.Net 的意思，只要应用遵守中间层的运行时API和接口以及应用之间做到互相隔离开，应用升级就不会影响到其他应用，系统底层做再多规模的底层库革新，只要革新完以后保证中间层调用接口不要变，系统的升级就完全不会影响到应用的稳定。
举一个最简单的例子，微软从Windows XP开始，操作系统底层技术一直在变，但是你会发现十几年前应用厂商为Windows XP开发的应用依然可以在Windows 10最新的操作系统上运行，这种类型的兼容性才是桌面应用生态赖以生存的重要技术保障。
这是原文链接：https://www.jianshu.com/p/86dd6e34ce91

本帖最后由 duanquanyong 于 2020-4-4 14:30 编辑

我也是开发者,但是我的观点是一款系统要成功,  宁可对开发者复杂,也不要对用户复杂. 只要有了大量用户,后期对开发者的复杂都是可以通过工具解决的. 至于依赖的问题我觉得你可能没有理解, 你没有经历安装一款软件要更新依赖到最新版本,一更新,其他依赖这个库的软件打不开了,对于开发者来说这都很头疼,何况普通用户, 至于有效利用系统资源,现在系统硬盘都是TB级的了,这个已经不是重点了吧

本帖最后由 abcfy2 于 2020-4-4 17:32 编辑

想要成功至少伺候好开发者或用户任意一方，如果两方都伺候好再好不过。

而我用过flatpak和snap来说，我感觉对于用户都没有什么讨好的地方，至少是目前。目前它们两家共同的问题就在于想打造中央仓库，但是分发协议不允许镜像，造成了大面积无法被仓库CDN覆盖的区域分发极其困难，比如我朝。抛开下载速度慢这个问题不谈，单就我的体验上来说，他并没有给用户太大的体验改善。

他们俩的做法大同小异，用法上都跟docker中运行图形界面程序的体验差不多，只不过没有docker那么重量级的搞法而已，所以docker运行图形界面的弊端他俩都有。之前我还搞过在Docker中跑各种图形化程序，后来基本放弃。

1. 启动速度慢，性能低。跟docker一样是隔离的环境运行，启动的时候需要加载沙箱环境，非常类似于docker的aufs的那一套，这种方案本身就是写入性能差，启动速度慢的方案。这种方案对于长时间运行的服务来说自然没什么影响。但是对于强调响应速度的桌面级客户端程序来说就要命了，用户会明显感觉启动速度慢很多。
2. 强调隔离性，导致桌面集成度差。这个也好理解，差不多运行效果相当于Virtualbox虚拟机的无缝模式的效果。由于桌面特性（比如主题，比如样式，比如DPI等等参数）无法传递给沙箱环境，导致桌面集成效果很差。比如在snap安装chromium，你会发现DPI，以及鼠标样式移入浏览器中样式就变了，还有托盘图标样式等等都跟桌面环境不匹配。甚至某些应用程序还无法使用输入法。
3. 复杂的权限对于普通用户并不友好。不像deb安装还有个postinstall脚本可以帮助用户做很多初始化操作，flatpak和snap都会要求用户手工改一些权限，才能让软件正常使用。比如remmina你看看安装说明，装完之后得用户自己去赋权限，否则没法使用系统的远程连接。

目前来看他俩都没有对用户体验上太友好。尤其是前两条——启动慢、桌面集成度差就非常影响普通用户体验了。

制定简单易用的包机制，不在商店安装的也能支持才是王道，macos的机制就是很好的借鉴啊。为啥不能弄一套？有那么难？还是懒得弄

程序可以自动创建desktop文件，只是开发者没做罢了。不是AppImage的锅