4 ms·

> Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?) Flatpak CAN support the scenario, where each app can have it's own repo

> Is flatpack promoting each app will have it's own repo(Skype.Dropbox,Slack,Discord?) Flatpak CAN support the scenario, where each app can have it's own repo. It's an option, not forced down your throat. Or you can self-host your private repo (e.g. applications used inside your network) IN ADDITION to public repos. > Seems to me that you want a way to have applications and updates installed by people and bypass the review process? Yes, I want to have Canonical out of the way. They can have their own repo if they really want; those who want curation by Canonical are free to use it. But I want to have options of different repos, with different curators. Canonical doesn't deserve to be the single gatekeeper between me and the apps. > If you are a distro maintainer you can change the hardcoded values before you build(distros always change this stuff) but if you are not a distro then you should either submit the app for review or do what other apps do and prompt a notification that a new update is available with a link to a download page. And this attitude is going to be a major reason why most distributions and users won't adopt snap. It will die the same way as other Canonical dead-ends did, while damaging the Linux ecosystems for a few years.

simion314 6y ago
if you are a user then you use a distribution, say Debian,Arch. This distro could setup whatever store, repo and keys they want and Canonical is not forcing themselves on other distributions (it is not systemd). I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. The article mentions Canonical did this mistake in the past with Launchpad and it was for nothing. The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. After you work as a developer and see many bugs or problems you look at things differently, for example as a dev I could allow access to an advanced feature in my app, it seems to be just a few lines of extra code. But the reality is that this costs more - maintenance cost as the software evolves and things under the hood change - this new feature needs to be documented, someone needs to write documentation, maybe record videos so the minimum number of people contacts support for help - people don't read documentation so people will contact support and complain that the feature is not working as they expected or that is should have more X or Y - since is an advanced feature some people might break their stuff and then complain and make a lot of noise and as a dev I need to go and add many checks in the code to prevent people breaking their shit.
- vetinari 6y ago
  > This distro could setup whatever store, repo and keys But only one. And changing it is a matter of replacing binary/entire package. If is a far cry from `flatpak remote-add $url`. > Canonical is not forcing themselves on other distributions (it is not systemd) Systemd did not force itself on distribution either. Systemd was solving real problems distributions had, and others were ignoring them. Including Upstart, which only made it worse. It's not like systemd had easy start. Even Redhat's management didn't see the point (Lennart P. couldn't work on it during his working hours). It took adoption by Arch to change Redhat's position. > I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. How do you know? Did you do any research among users, or it is just against Canonical modus operandi, where they try to insert themselves as gatekeeper in some layer of Linux community and be the single entity that can be approached for a given topic? For many, it has much higher priority than forced updates, enforcing a single signing key or paid custom stores for FOSS. > The article mentions The article does not make honest arguments, it often misdirects. It is an apologia piece. > Canonical did this mistake in the past with Launchpad and it was for nothing Canonical did many more, more serious mistakes with Launchpad. Yes, PPAs were a dead-end, but for other reasons, that are for a separate debate. > The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. The code is a mess from the start. Somebody didn't do their homework what their users will be interested in, but only what they are interested in (see gatekeeping above). > Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. On the client we can see that they tried to do MVP, be first on "the market" and capture it. It is full of user visible annoyances that are not going to be solved (polluting mount namespace, visible snap dir in user homedir, no dedup, etc). They did quick and dirty job to be first, instead of doing it properly, like the Flatpak guys did. > But the reality is that this costs more So drop the things that make it complicated, such as routing separate stores through Canonical... The reality is, that this is just an excuse to do what Canonical wants, not what their users want.
  - simion314 6y ago
xet7 6y ago
> a major reason why most distributions and users won't adopt snap What "most distributions" you mean? Snap is already available for many distros.
- vetinari 6y ago
  And the ones based on Ubuntu are removing it. On the rest, available doesn't mean anything, it is a low quality packaging. On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.
  - galgalesh 6y ago
    Linux Mint put in an apt rule to avoid it installing as a dependency of other apps. This decision was triggered by Canonical's announcement to stop maintaining the Chromium deb package. Linux Mint was pissed they had to either switch to the Debian version or to the Snap, so they made some fuss. I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users. > On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments. Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement. The main limitation is that Snap can't run when SELinux is running at the same time. Canonical is working with a bunch of other people on LSM stacking in order to make that work. > That's not something you would use outside of experiments. That might not be something you use outside of experiments, but don't generalize statements like that.
    - vetinari 6y ago
      > I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users. Pop!_OS doesn't install snap by default, but it does Flatpak. > Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement Just because it is in upstream kernel, does not mean it is used by other distributions. Only that it can be used. But so can be SELinux, which is also in upstream kernel. > The main limitation is that Snap can't run when SELinux is running at the same time. Exactly, different distributions have chosen different LSMs in the past and they are going to stick with them. RHEL or Fedora are not going to switch to AppArmor anytime soon. > Canonical is working with a bunch of other people on LSM stacking in order to make that work. Good for them that they are realizing this is a problem. Flatpak was developed from the start with the different LSMs in mind. > That might not be something you use outside of experiments, but don't generalize statements like that. OK, some people might be too brave ;)

simion314 6y ago

if you are a user then you use a distribution, say Debian,Arch. This distro could setup whatever store, repo and keys they want and Canonical is not forcing themselves on other distributions (it is not systemd). I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. The article mentions Canonical did this mistake in the past with Launchpad and it was for nothing. The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. After you work as a developer and see many bugs or problems you look at things differently, for example as a dev I could allow access to an advanced feature in my app, it seems to be just a few lines of extra code. But the reality is that this costs more - maintenance cost as the software evolves and things under the hood change - this new feature needs to be documented, someone needs to write documentation, maybe record videos so the minimum number of people contacts support for help - people don't read documentation so people will contact support and complain that the feature is not working as they expected or that is should have more X or Y - since is an advanced feature some people might break their stuff and then complain and make a lot of noise and as a dev I need to go and add many checks in the code to prevent people breaking their shit.

vetinari 6y ago
> This distro could setup whatever store, repo and keys But only one. And changing it is a matter of replacing binary/entire package. If is a far cry from `flatpak remote-add $url`. > Canonical is not forcing themselves on other distributions (it is not systemd) Systemd did not force itself on distribution either. Systemd was solving real problems distributions had, and others were ignoring them. Including Upstart, which only made it worse. It's not like systemd had easy start. Even Redhat's management didn't see the point (Lennart P. couldn't work on it during his working hours). It took adoption by Arch to change Redhat's position. > I am looking at this from a dev point of view, you are asking to prioritize a feature that almost nobody will use over other high priority tasks. How do you know? Did you do any research among users, or it is just against Canonical modus operandi, where they try to insert themselves as gatekeeper in some layer of Linux community and be the single entity that can be approached for a given topic? For many, it has much higher priority than forced updates, enforcing a single signing key or paid custom stores for FOSS. > The article mentions The article does not make honest arguments, it often misdirects. It is an apologia piece. > Canonical did this mistake in the past with Launchpad and it was for nothing Canonical did many more, more serious mistakes with Launchpad. Yes, PPAs were a dead-end, but for other reasons, that are for a separate debate. > The store code seems to be a mess and you can't just drop the code and GitHub and you are done, it is a lot of work to refactor the code. The code is a mess from the start. Somebody didn't do their homework what their users will be interested in, but only what they are interested in (see gatekeeping above). > Same for the client, it is a of work to correctly add the feature to support multiple repositories, if it was only 1 day work somebody would have forked the client, patch it and published it already. On the client we can see that they tried to do MVP, be first on "the market" and capture it. It is full of user visible annoyances that are not going to be solved (polluting mount namespace, visible snap dir in user homedir, no dedup, etc). They did quick and dirty job to be first, instead of doing it properly, like the Flatpak guys did. > But the reality is that this costs more So drop the things that make it complicated, such as routing separate stores through Canonical... The reality is, that this is just an excuse to do what Canonical wants, not what their users want.
- simion314 6y ago

xet7 6y ago

> a major reason why most distributions and users won't adopt snap What "most distributions" you mean? Snap is already available for many distros.

vetinari 6y ago
And the ones based on Ubuntu are removing it. On the rest, available doesn't mean anything, it is a low quality packaging. On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments.
- galgalesh 6y ago
  Linux Mint put in an apt rule to avoid it installing as a dependency of other apps. This decision was triggered by Canonical's announcement to stop maintaining the Chromium deb package. Linux Mint was pissed they had to either switch to the Debian version or to the Snap, so they made some fuss. I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users. > On any distro that doesn't run apparmor, the snap sandbox doesn't work, for example. That's not something you would use outside of experiments. Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement. The main limitation is that Snap can't run when SELinux is running at the same time. Canonical is working with a bunch of other people on LSM stacking in order to make that work. > That's not something you would use outside of experiments. That might not be something you use outside of experiments, but don't generalize statements like that.
  - vetinari 6y ago
    > I know of at least three Ubuntu derivatives who have Snap preinstalled and every snap I maintain has between 5% and 10% non-Ubuntu users. Pop!_OS doesn't install snap by default, but it does Flatpak. > Given that every AppArmor thing Snap needs is in the upstream kernel, any distribution with a fairly recent kernel an userspace has full confinement Just because it is in upstream kernel, does not mean it is used by other distributions. Only that it can be used. But so can be SELinux, which is also in upstream kernel. > The main limitation is that Snap can't run when SELinux is running at the same time. Exactly, different distributions have chosen different LSMs in the past and they are going to stick with them. RHEL or Fedora are not going to switch to AppArmor anytime soon. > Canonical is working with a bunch of other people on LSM stacking in order to make that work. Good for them that they are realizing this is a problem. Flatpak was developed from the start with the different LSMs in mind. > That might not be something you use outside of experiments, but don't generalize statements like that. OK, some people might be too brave ;)