Canonical is doing the same thing Microsoft is doing with Edge - using its dominant position to push its other products and force out competition, and to lock users (and potentially developers) into its own ecosystem.
Saying that Edge is Chromium is like saying that Manjaro is Arch or diamond is just coal. They’re related, but there’s significant material difference.
When it was introduced in Windows 10, Edge had an immediate and massive surge in its adoption rate. That wasn’t natural growth based on the application’s merits – it was simply a result of Edge being present in new installs.
It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.
Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.
I’ll add that the ‘pseudo-sandbox’ is of some dubious value, as far as I can tell the app declares how much or little sandboxing it wants and the user doesn’t really get the opportunity to consent or even know that a snap has full access versus limited access.
I’ll also say that some functionality is broken in snaps (and flatpak). For example I used KeepPassXC browser integration, and then when snap was used instead of native, it broke. A number of extensions broke and the development attitude was everyone pointing fingers everywhere else and ultimately saying “just find a ppa with a browser ok?”
I’ll second the “screw it, I give up on packaging, my app is now a monolithic flatpak, snap, appimage, or docker container” mindset of a lot of developers.
Removed by mod
Canonical is doing the same thing Microsoft is doing with Edge - using its dominant position to push its other products and force out competition, and to lock users (and potentially developers) into its own ecosystem.
Removed by mod
Saying that Edge is Chromium is like saying that Manjaro is Arch or diamond is just coal. They’re related, but there’s significant material difference.
When it was introduced in Windows 10, Edge had an immediate and massive surge in its adoption rate. That wasn’t natural growth based on the application’s merits – it was simply a result of Edge being present in new installs.
Wait, but doesn’t it result in more copies of the dependencies being installed locally because they’re duplicated for each application?
Removed by mod
It’s actually less about the library being obscure, and more about version conflicts, which is actually more a problem with common libraries.
For example, let’s say you want to install applications A, B, and C, and they each depend on library L. If A depends on Lv1, and B depends on Lv2, and C depends on Lv3, with traditional package management, you’re in a predicament. You can only have one copy of L, and the versions of L may not be compatible.
Solutions like snap, flatpak, appimage, and even things like Docker and other containerization techniques, get around this issue by having applications ship the specific version of the library they need. You end up with more copies of the library, but every application has exactly the version it needs/the developer tested with.
Removed by mod
I’ll give flatpak and snap one thing: they did make some concession to avoiding duplication, unlike docker which utterly duplicates everything.
With flatpak and snap, applications can depend on/pull in a maintained external layer. So you might want ‘gnome environment, version 43’ and other applications that want that can all share. That layer can be updated independently of dependencies. You might have two instances of the gnome layers (say 43 and 44) due to different applications declaring different versions, but it’s not too bad.
Now there is some duplication, some libraries that an app says “oh, no particular layer for this one, fine I’ll just bundle it”. But at least there’s a mechanism to not necessarily do that for everything.
I’ll add that the ‘pseudo-sandbox’ is of some dubious value, as far as I can tell the app declares how much or little sandboxing it wants and the user doesn’t really get the opportunity to consent or even know that a snap has full access versus limited access.
I’ll also say that some functionality is broken in snaps (and flatpak). For example I used KeepPassXC browser integration, and then when snap was used instead of native, it broke. A number of extensions broke and the development attitude was everyone pointing fingers everywhere else and ultimately saying “just find a ppa with a browser ok?”
I’ll second the “screw it, I give up on packaging, my app is now a monolithic flatpak, snap, appimage, or docker container” mindset of a lot of developers.