Canonical Releases "Ubuntu on Windows Community Preview"

[evasb]

The Snap-Flatpak war is the stupidest war ever.

[nado]

The Snap-Flatpak war is the stupidest war ever.

well one is trying to create a walled and curated garden to attract developers and the other is completely open... i can understand both approaches even if I donæt agree.

[evasb]

well one is trying to create a walled and curated garden to attract developers and the other is completely open... i can understand both approaches even if I donæt agree.

Agreed, but is not like Flatpak cover all snap user cases and neither looks like they are trying to do so^[1].

[1]: https://github.com/flatpak/flatpak/issues/1188

[nado]

Agreed, but is not like Flatpak cover all snap user cases and neither looks like they are trying to do so^[1].

[1]: https://github.com/flatpak/flatpak/issues/1188

Agreed, but I hope they will solve these issues over time. Firefox flatpak does not work with the gnome extensions site due to missing support for native messaging, same as with KeePassXC. These are deal breakers for many

https://bugzilla.mozilla.org/show_bug.cgi?id=1621763

https://bugzilla.mozilla.org/show_bug.cgi?id=1633206

https://gitlab.gnome.org/GNOME/chrom...ell/-/issues/5

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2689

[jo-erlend]

Yeah, but the whole point of Snap and Flatpak is to avoid dealing with multiple packaging systems. So the presence of two big ones forces some devs with limited resources to choose between them. And given that Snaps is only pre-installed and supported on Ubuntu systems, it means that if developers choose Snap, that application is only easily installable on Ubuntu.

Whereas if it was Flatpak, it's installable on almost any Linux distro.

Your assumptions are wrong and your conclusion is illogical. Flatpak is designed in a way that makes it impossible for Flatpak users to avoid dealing with multiple packaging systems. With Snap you can, but only in an atomic host like Ubuntu Core. However, in this context, we're talking about using it in a classic distro, where you are going to have another packaging format anyway. Another assumption is that using snaps are difficult if snapd is not installed by default, but installing snapd is very simple unless the distribution you're using is making it difficult.

You conclude that if you want to minimize the number of package formats you want to use, you should choose Flatpak because it _requires_ multiple package formats, is self-contraditory.

[jo-erlend]

well one is trying to create a walled and curated garden to attract developers and the other is completely open... i can understand both approaches even if I donæt agree.

It is better to say that Snap tries to fix problems with the traditional distro, whereas Flatpak tries to improve app delivery. You might not want to decentralize access to patch your kernel, for instance. You could use Flatpaks in a Snap-only system, because they're not conflicting. When you use Debian as a non-walled garden, meaning that you just add an apt repo to install an icon pack, for instance, you're in a security nightmare. That's not because the system is bad, but because it's really intended to be a centralized distro: when you use Debian, you're supposed to trust Debian developers.

[nado]

It is better to say that Snap tries to fix problems with the traditional distro, whereas Flatpak tries to improve app delivery. You might not want to decentralize access to patch your kernel, for instance. You could use Flatpaks in a Snap-only system, because they're not conflicting. When you use Debian as a non-walled garden, meaning that you just add an apt repo to install an icon pack, for instance, you're in a security nightmare. That's not because the system is bad, but because it's really intended to be a centralized distro: when you use Debian, you're supposed to trust Debian developers.

With that mind set we might as well just stick to Windows and other proprietary solutions that aren't open for review. No thanks, if I'm using Linux I don't want to support a centralized back-end solution that's propietary. There is a trade off of course, but that's will be the case with anything.

[Charlie68]

One of the reasons I left Windows 15 years ago (fully for my personal use) is because of bundled packages and how much of a hassle it was to manage them and what a waste of resources they are.
Being caught up by that terrible concept in Linux feels like going back to the middle age of computing for me.

I could tolerate snaps/flatpaks for my use in the case of big players as an easy way to offer a Linux version of their apps. Between not offering a Linux version because they don't feel like dealing with each package-style versus offering a snapflak, I'd still pick the latter. But after a while, I expect them to embrace package managers in order to mutualize resources for users and have a clean system not going in all directions. And to solve theming issues (no, installing the snapflak version is not enough) and all the weird folder locations that sandboxing brings. I am not obsessed by security and it's not worth justifying the "back to the middle age of computing" design from my point of view.

If I really had to pick one, I would go for snap (just to avoid the Red Hat dependence).

Each package system has its pros and cons. Sure it is convenient to have a large base of rpm or deb packages, however it is becoming more and more problematic.
Fix distributions often have old applications, often vulnerable, because the backport of security updates is done only on the main applications. This is becoming more and more of a problem, adding repositories or ppa is not a solution, because regressions are often introduced.
I believe that in the near future the distributions will switch to having the system partition / mounted read-only and the rest managed by flatpak and snap etc.
In this way the core with the DE could always be updated, and the applications will have a good isolation.
Some distributions are already working on this as an option, but in a few years I guess that's the rule.
Also don't forget the fact that distributing software in the traditional deb / rpm method comes at a high cost for maintenance and packaging deployments.

[nado]

One of the reasons I left Windows 15 years ago (fully for my personal use) is because of bundled packages and how much of a hassle it was to manage them and what a waste of resources they are.
Being caught up by that terrible concept in Linux feels like going back to the middle age of computing for me.

I could tolerate snaps/flatpaks for my use in the case of big players as an easy way to offer a Linux version of their apps. Between not offering a Linux version because they don't feel like dealing with each package-style versus offering a snapflak, I'd still pick the latter. But after a while, I expect them to embrace package managers in order to mutualize resources for users and have a clean system not going in all directions. And to solve theming issues (no, installing the snapflak version is not enough) and all the weird folder locations that sandboxing brings. I am not obsessed by security and it's not worth justifying the "back to the middle age of computing" design from my point of view.

If I really had to pick one, I would go for snap (just to avoid the Red Hat dependence).

Can I ask why you dislike Red Hat more than say, Intel, Samsung, SUSE, Google, Microsoft etc? Like it or not, the biggest contributors to Linux are mostly large companies... whether they are altruistic or not is immaterial in my opinion, as it benefits the community at large in the end. Developers need to earn a living and there are far worse actors out there than Red Hat. I am glad it isn't Facebook at least.

If enough people don't want/like something then they are free to fork it or use something else. We should be glad that Red Hat is still around and contributing.

Edit: It was wrong of me to even single out Facebook, their contributions are also very much welcome in my opinion.

[Mez']

I don't see any issue with managing Flatpak applications vs native packages for a distro. Sure there are some teething problems, but that's normal for a lot of software in general.

Well for Gnome there is no such thing as a theme really, it's a hack for better or worse. As far as resources are concerned I'd say it's the opposite, maintaining a package across distros requires more disros if you use the native package manager in the distro. Flatpaks, like Electron, can be made once and will work across distributions.

Also Charlie68
I see sandboxing leading to different issues (theming, save locations or thumbnails). Issue I don't have otherwise. I'm not obsessed with security and the trade-off is not worth it for me. Plus, I haven't had one security issue with PPAs in 15 years, not a single one.
I see several versions of the same libraries multiplying over time (not in the short term as packages can reuse a version already present when possible) depending on the frequency of app updates, and on which versions they are relying. This will go in many directions and bloat the system somehow. Storage costs being lower (yet quite high) is no excuse to stop mutualizing and to do something less clean. Even if "clean" means a bit more difficult to maintain.
It has worked for 20+ years, I don't see why all of a sudden when more tools are available to reduce packaging time or manual intervention, we should go back to a mediocre one size fits all Windows approach. It's the same as that trend to progressively reduce speed limits on roads everywhere when technology has evolved. It's a regression to a previous state that entirely denies everything has changed in the meantime and can be done faster and with less intervention. Like going back in time.

There is such thing as a theme, even as a hack, given how ugly adwaita is (the GTK part). It's the lamest default theme there is, the Citroën CX or the Fiat Multipla of GTK themes, it already was 15-20 years ago (Gnome 2), still was 10 years ago (Gnome 3), and is even more so today (Gnome 40). Anything is better basically and justifies hacking. Every time I use it for 10 seconds to refresh a modification I made to another (modern) theme, I feel like going from a mid-segment 2020's Mercedes/Volvo to a 15 years old Dacia, suddenly I get a rough edges and cheap feeling, as if there were no finishing touches, no attention to details. The typical Red Hat half-baked design.
User themes is typically your first extension, although most distros already do that job for you.

I'm not really sure how Red Hat is worse than Canonical, they don't force a proprietary distribution model on you (Canonical's Snap server implementation is closed source) or gate you into their app store.

I would love to be free of all large corporations having significant control over Linux, but that's a pipe dream at this point. There wouldn't be enough resources to manage Linux and its accompanying software such as Firefox in the constantly changing nature of internet and software.

Red Hat is worse than Canonical to me because they impose you their stuff (that they designed unilaterally, with no user feedback taken into account). They give you no choice, no alternative and even discourage them. If that's not your usual way of executing your workflow or use case, you're screwed and have to do stuff in a counter-intuitive (and/or less productive) way for you because they don't empower you to pick your own preferred way. It's an arrogant mindset (we know better than yourself) and I don't want to be trapped in that, because tomorrow they will force me again to change something else and be less productive with their different way. I'm really not against change, but I like to decide and weigh in if and when it's worth changing my way for a different one. I want to make the change because I think it's better for me, not because I was forced to. The Red Hat way works for good soldiers, yes men, obedient unquestioning followers, but people who decide for themselves and have better ways for them to satisfy their workflow are often left without the possibility to decide anything (except through 3rd party unsupported extensions).
Although Canonical and Ubuntu are much more user-centric and focused on satisfying the variety of workflows and use cases, they might sometimes force you into something as well, and to get back (slightly) to the topic, snap is indeed an example of that, as they try to blur the frontier and to install snap without you always being aware of it. Which is why I have used "apt-mark hold snapd" so as not to be bothered. It might seem paradoxical with what I said above, but I stress this because I'm not always in line with what they do, I'm not following them blindly. Never have, never will. I'm not convinced by their every move. Yet, in general (beside some exceptions) they try to empower their users and offer them options so that they can decide for themselves. I've never felt trapped with them the way I am when using Gnome or wayland (both RH babies).
It's not about big corporations in my case. It really is about the Red Hat mindset. It's contrary to my principles (everyone should be empowered to decide what is best for him/her, even if I don't like something, e.g. desktop icons, I still expect others who need it to have it). That's also why I like Canonical, they're the only ones standing up against the Red Hat dictatorship tendencies. They don't have the same financial means, so they can't completely oppose. But at least they have the balls to take a different path and pull their design from users when Red Hat is not being pragmatic and is trying to push their dev-centric approach to everyone.

We don't know if Flatpak/Snaps/AppImage are the way forward yet, just like we don't know if Wayland will be the true succesor to X, but the work and research done implementing these solutions is valuable regardless - the knowledge and experiences gained will be useful for evaluating future solutions.

I could agree with these if Red Hat was giving a choice. They don't. At some point you will have no choice but to do things their way, because they're gonna cut down everything standing in the way, disregarding entirely what users would have preferred.