6 ms·

The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it

by kd913 6y ago

The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to spend. Not even Mint operate run or operate their own launchpad infrastructure. They experienced large backlash back then, open sourced it and nobody contributed. The same problem applies here. Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Such a cost operating would benefit nobody but Canonical because nobody else is bothering footing the bill to run an instance. Second aspect that they wanted to avoid was the same pitfalls that they experienced previously with ppas and now being experienced with flatpak. Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. That and the whole aspects of malware/trust goes out the window. I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.

blendergeek 6y ago
> Namely that it would be expensive to open source it with little benefit in return. Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? > Namely they want one location to find software, and one location to serve software. And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. > That and the whole aspects of malware/trust goes out the window. Malware has already been successfully pushed to the Snap Store. The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
- kd913 6y ago
  >Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker. >And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store. >Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware. There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed. >The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.
  - commoner 6y ago
    > However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is to lock its users into a proprietary and centralized system that it has full control over. This strategy is no different from Apple disallowing installations outside of the App Store on iOS, and Google disallowing alternative app stores in Google Play.
madeofpalk 6y ago
> The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. I just think it's weird that a supposedly open source company like Canonical would build close source infrastructure. Like, just develop it in the open to begin with?
- berkes 6y ago
  Better even: design it to be self-hostable from scratch. Edit: by making it a self-contained executable, a .deb or even a set of ansible scripts. I understand that some complex interconnected ball-of-spaghetti of microservices makes little sense to open-source, b/c no-one can run it. But that is essentially saying: we never wanted people to run it themselves, and now we are at a point that no-one can run it, so why bother?
  - madeofpalk 6y ago
    Sure, there's "even better" ways to go above what they did, but it seems to be than an open source company would at least by default develop open source software. They had to have actively chosen to build this closed-source software, no.
    - berkes 6y ago
      I agree entirely. My point was only that I expect an company like Canonical to not just open source everything, but to design it in such a way that it is useful for third parties. To make the distinction with "open source waste", where companies Open Source the software they no longer want, maintain or monetize.
stonogo 6y ago
None of these arguments are convincing. > Namely that it would be expensive to open source it with little benefit in return. I don't think that's the real reason; I think it's that Canonical wants to maintain control. Their dream of being the App Store of linux isn't working out. > Canonical already spent a large amount of investment opensourcing launchpad If their development practices make open-source development expensive, that's Canonical's problem, not anyone else's. Nobody else uses Launchpad because Launchpad is not a compelling platform. It's still tied to bazaar, which frankly lost the version-control wars. Treating git as a second-class citizen is not how to engender contributors. > Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Another example of having to choose: did Canonical engineer themselves into a corner, causing all of Launchpad to become technical debt from under which Snap cannot escape? Or was it a deliberate business decision to try to maintain control of the store? An affirmative conclusion in either case doesn't look good for Snap. > Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system; I'd argue that it directly caused Fedora's COPR system to exist because of the user demand. There's no mandate that PPA installation require command-line configuration; it would be trivial to create a bespoke per-PPA using e.g. Vala. Synaptic already allows configuration of PPAs via GUI. It's total non-issue. > That and the whole aspects of malware/trust goes out the window. They're already out the window. Snap packages are not reviewed for content and anyone can just cram software into it from random GitHub repositories. Wouldn't it be nice if it were possible to set up a 'curated' Snap store with strong promises of software quality and review? We can't, because it's apparently too hard to run. Another drag on Snap. I'll not bother to respond to the whataboutism regarding PPAs. Literally the only difference between "a giant PPA that Canonical hosts" and the Snap store is that anyone can upload to the Snap store. None of the problems Snap store purports to solve are compelling, so these explanations don't really further the cause.
- Grimm665 6y ago
  > Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system Agreed. This is one feature of Ubuntu I miss sorely after leaving it behind for other distros.
agentx3r 6y ago
Disclaimer, I like the snap packaging format, and I'm not familiar with the history of launchpad. Operationally: - I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages. - I can't do the same with snaps. So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.
commoner 6y ago
There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. GNOME Software and KDE Discover both set Flathub as the default repository, which serves as the primary software source, and users can optionally add more repositories if they choose to do so. Users who don't want additional repositories can simply stay with Flathub without having to do anything. The Snap server's closed-source nature is not a benefit to users, and there is no excuse that can justify this from the users' perspective.
- kd913 6y ago
  >There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories. You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious. Which is why I brought up the webupd8 java instance having root access to thousands of machines. >users can optionally add more repositories if they choose to do so. Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors. It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
  - commoner 6y ago
    > You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious. > Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors. By default, GNOME Software and KDE Discover only use the Flathub repository. Your grandmother won't be adding other repositories to the Flatpak client. Users who don't add any extra repositories will use Flathub, which is a trusted source of software that runs on an open source server. > It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak. https://www.flathub.org/apps/details/com.visualstudio.code https://www.flathub.org/apps/details/com.visualstudio.code https://www.flathub.org/apps/details/com.spotify.Client https://www.flathub.org/apps/details/com.spotify.Client https://www.flathub.org/apps/details/com.jetbrains.IntelliJ-IDEA-Community https://www.flathub.org/apps/details/com.jetbrains.IntelliJ-...
ufo 6y ago
I'm curious... what is that Java PPA that you are talking about? I tried searching for it but I couldn't find anywhere that had a list of the most downloaded PPAs.
- kd913 6y ago
  This is the PPA. https://launchpad.net/%7Ewebupd8team/+archive/ubuntu/java https://launchpad.net/%7Ewebupd8team/+archive/ubuntu/java For years it has been recommended as the mechanism for installing Java on Ubuntu installs.
  - andrewshadura 6y ago
    Why would anyone use this instead of distro packages?
    - boring_twenties 6y ago
      Distros (at least Debian and Ubuntu) don't package Oracle Java AFAIK.
      - andrewshadura 6y ago
        Oracle Java cannot be packaged or used in any but personal setup, and there’s no need for it these days when OpenJDK is the official Java implementation.
    - kd913 6y ago
      Because SO/Google told them in 2012 to do it that way. Suddenly the sysadmins in charge have forgotten they used this mechanism to install it on their ancient linux boxes.
    - alyandon 6y ago
      The short story is - developers typically need to target more than one version of Java and the long lifetime of LTS releases don't line of up very well with that. Canonical historically provided a single "system" version of Java (meaning any system packages that depends on Java depended on this package) which meant that that was the version of Java that you got with Ubuntu XX.XX - even for LTS releases which had a 5 year lifespan. Ubuntu 16.04 - which is still in support came with openjdk-7 and Canonical refused to provide an openjdk-8 package for it despite Java 8 being the prevalent development platform from late 2016 onwards and despite numerous requests to do so. No one was expecting Canonical to replace openjdk-7 with openjdk-8 - they only wanted to be able to install openjdk-8 along side the existing openjdk-7 system Java. Ubuntu 18.04 - slightly different scenario but still the same problem - openjdk-8 and openjdk-11 are available but that still doesn't cover all development use cases. Thus, people add the PPA and install the openjdk from there because someone currently is doing the work of keeping the PPA up to date.
curt15 6y ago
>The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Perhaps a business reason left unsaid is that an open source snap store would undermine Canonical's paid "enterprise edition" snap store. Why would an organization pay $30000 (https://ubuntu.com/internet-of-things https://ubuntu.com/internet-of-things) for a private app store if they could easily set up their own snap store?
- BruiseLee 6y ago
  And that is exactly why it would be very expensive to open source it. All this revenue ($30000 * number of paying organizations) would then be gone.
- xet7 6y ago
  That revenue funds bandwidth, server etc costs of those downloading Snap packages for free.
ocdtrekkie 6y ago
> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. I posit that this doesn't matter. Presumably Ubuntu's infrastructure should be open source so that it can be inspected if necessary, for security reasons. It shouldn't matter if nobody else is actually hosting an alternative copy... it is still important that their copy be open source.
michaelmrose 6y ago
Nearly every packaging system is able to successfully divorce building of software from offering artifacts for download let alone ops. This is arguing that having failed to design their system appropriately we ought to accept the fruits of that bad design instead of dumping Ubuntu. Compare this with apt. Second what you describe as a defect. There being multiple sources of software is a plus it means the power is in the hands of the user to decide whom to trust. What you don't want is a situation where people must configure additional sources just to have commonly needed software. The example you provide about the Java PPA is apt, pun intended, ideally commonly required software would be provided by the vendor instead of siloed in a third party source. Of course the vendor and the license must make this possible.
johannes1234321 6y ago
> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Launchpad has a weird user experience and was for a long time too much focussed on bazaar when git won. At work we used bazaar and lp for a while, but still I always have to search for the right path for getting to a project's code. The bug tracker was more useful than GitHub's but that didn't help ... Aside from that there are the legal implications of AfferoGPL which prevent many people from touching it. But yes, doing infrastructures is hard. I however don't know how complicated hosting is and how well it's packaged. For software starting for in-house use this often is a mess ...
rdschouw 6y ago
I do not think anyone disputes Ubuntu's goals or intentions. The problem is that the snap store is managed by Ubuntu without any community oversight. By not releasing source code to the store, other distributions cannot create their own. These are the reasons what is holding snap back for broader adoption.
- kd913 6y ago
  >The problem is that the snap store is managed by Ubuntu without any community oversight. That is already the case for most repos/launchpad on Ubuntu but people don't really have too much problems with that. >By not releasing source code to the store, other distributions cannot create their own. Other distributions wouldn't because the operational cost of operating it is too high. >These are the reasons what is holding snap back for broader adoption. Snap isn't being held back by adoption. It has more first party publisher support and more installs.
dilandau 6y ago
>snapd not open-source. Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user. >I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines. Imagine strawman-ing this hard.
- kd913 6y ago
  >Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user. Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. I could remove snapd there without people making that decision for me. Worse would be Mint's decision of removing the only FOSS built version of chromium without offering an alternative in place. Canonical only installed the chromium snap because they did not have the resources to support a deb version instead. >Imagine strawman-ing this hard. It isn't a strawman. It is precisely what their reasoning was and it makes perfect sense. The snap store has already seen people attempt to install cryptominers. There is no way in Flatpak of banning known malicious flathub repos.
  - the_af 6y ago
    > Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. If I understood the issue correctly (and I may very well be mistaken!) the problem Mint has with Canonical is that Ubuntu has "hijacked" (for lack of a better term) some apt packages so that they now actually install snapd and the snap. So you think you're opting out of snap, but when you use apt to install Chromium you end up using snap anyway. If I understand correctly, this is Mint's main complaint: that Ubuntu seems to be hijacking apt packages with snap.
    - kd913 6y ago
      There is no apt package with Chromium. https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-transition https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-trans... Canonical couldn't afford the maintenance costs for it. On Ubuntu distributions it's either the snap or you have to create some weird frankendeb aspect by pulling from Debian. They explained it better than I would. In other cases, I don't think of a case where apt installs snaps over apt. I think the only priority for the decision choice was based on most recent version. Although this aspect I am slightly unclear.
einpoklum 6y ago
> Namely that it would be expensive to open source it with little benefit in return. Ok, so the whole technology is irrelevant and should not be used then. > Canonical already spent a large amount of investment opensourcing launchpad Why develop it as non-open-source to begin with?

by kd913 6y ago

blendergeek 6y ago

> Namely that it would be expensive to open source it with little benefit in return. Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? > Namely they want one location to find software, and one location to serve software. And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. > That and the whole aspects of malware/trust goes out the window. Malware has already been successfully pushed to the Snap Store. The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.

kd913 6y ago
>Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker. >And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software. Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store. >Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware. There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed. >The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.
- commoner 6y ago
  > However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is to lock its users into a proprietary and centralized system that it has full control over. This strategy is no different from Apple disallowing installations outside of the App Store on iOS, and Google disallowing alternative app stores in Google Play.

madeofpalk 6y ago

> The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. I just think it's weird that a supposedly open source company like Canonical would build close source infrastructure. Like, just develop it in the open to begin with?

berkes 6y ago
Better even: design it to be self-hostable from scratch. Edit: by making it a self-contained executable, a .deb or even a set of ansible scripts. I understand that some complex interconnected ball-of-spaghetti of microservices makes little sense to open-source, b/c no-one can run it. But that is essentially saying: we never wanted people to run it themselves, and now we are at a point that no-one can run it, so why bother?
- madeofpalk 6y ago
  Sure, there's "even better" ways to go above what they did, but it seems to be than an open source company would at least by default develop open source software. They had to have actively chosen to build this closed-source software, no.
  - berkes 6y ago
    I agree entirely. My point was only that I expect an company like Canonical to not just open source everything, but to design it in such a way that it is useful for third parties. To make the distinction with "open source waste", where companies Open Source the software they no longer want, maintain or monetize.

stonogo 6y ago

None of these arguments are convincing. > Namely that it would be expensive to open source it with little benefit in return. I don't think that's the real reason; I think it's that Canonical wants to maintain control. Their dream of being the App Store of linux isn't working out. > Canonical already spent a large amount of investment opensourcing launchpad If their development practices make open-source development expensive, that's Canonical's problem, not anyone else's. Nobody else uses Launchpad because Launchpad is not a compelling platform. It's still tied to bazaar, which frankly lost the version-control wars. Treating git as a second-class citizen is not how to engender contributors. > Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Another example of having to choose: did Canonical engineer themselves into a corner, causing all of Launchpad to become technical debt from under which Snap cannot escape? Or was it a deliberate business decision to try to maintain control of the store? An affirmative conclusion in either case doesn't look good for Snap. > Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system; I'd argue that it directly caused Fedora's COPR system to exist because of the user demand. There's no mandate that PPA installation require command-line configuration; it would be trivial to create a bespoke per-PPA using e.g. Vala. Synaptic already allows configuration of PPAs via GUI. It's total non-issue. > That and the whole aspects of malware/trust goes out the window. They're already out the window. Snap packages are not reviewed for content and anyone can just cram software into it from random GitHub repositories. Wouldn't it be nice if it were possible to set up a 'curated' Snap store with strong promises of software quality and review? We can't, because it's apparently too hard to run. Another drag on Snap. I'll not bother to respond to the whataboutism regarding PPAs. Literally the only difference between "a giant PPA that Canonical hosts" and the Snap store is that anyone can upload to the Snap store. None of the problems Snap store purports to solve are compelling, so these explanations don't really further the cause.

Grimm665 6y ago
> Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system Agreed. This is one feature of Ubuntu I miss sorely after leaving it behind for other distros.

agentx3r 6y ago

Disclaimer, I like the snap packaging format, and I'm not familiar with the history of launchpad. Operationally: - I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages. - I can't do the same with snaps. So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.

commoner 6y ago

There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. GNOME Software and KDE Discover both set Flathub as the default repository, which serves as the primary software source, and users can optionally add more repositories if they choose to do so. Users who don't want additional repositories can simply stay with Flathub without having to do anything. The Snap server's closed-source nature is not a benefit to users, and there is no excuse that can justify this from the users' perspective.

kd913 6y ago
>There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories. You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious. Which is why I brought up the webupd8 java instance having root access to thousands of machines. >users can optionally add more repositories if they choose to do so. Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors. It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
- commoner 6y ago
  > You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious. > Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors. By default, GNOME Software and KDE Discover only use the Flathub repository. Your grandmother won't be adding other repositories to the Flatpak client. Users who don't add any extra repositories will use Flathub, which is a trusted source of software that runs on an open source server. > It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak. https://www.flathub.org/apps/details/com.visualstudio.code https://www.flathub.org/apps/details/com.visualstudio.code https://www.flathub.org/apps/details/com.spotify.Client https://www.flathub.org/apps/details/com.spotify.Client https://www.flathub.org/apps/details/com.jetbrains.IntelliJ-IDEA-Community https://www.flathub.org/apps/details/com.jetbrains.IntelliJ-...

ufo 6y ago

I'm curious... what is that Java PPA that you are talking about? I tried searching for it but I couldn't find anywhere that had a list of the most downloaded PPAs.

kd913 6y ago
This is the PPA. https://launchpad.net/%7Ewebupd8team/+archive/ubuntu/java https://launchpad.net/%7Ewebupd8team/+archive/ubuntu/java For years it has been recommended as the mechanism for installing Java on Ubuntu installs.
- andrewshadura 6y ago
  Why would anyone use this instead of distro packages?
  - boring_twenties 6y ago
    Distros (at least Debian and Ubuntu) don't package Oracle Java AFAIK.
    - andrewshadura 6y ago
      Oracle Java cannot be packaged or used in any but personal setup, and there’s no need for it these days when OpenJDK is the official Java implementation.
  - kd913 6y ago
    Because SO/Google told them in 2012 to do it that way. Suddenly the sysadmins in charge have forgotten they used this mechanism to install it on their ancient linux boxes.
  - alyandon 6y ago
    The short story is - developers typically need to target more than one version of Java and the long lifetime of LTS releases don't line of up very well with that. Canonical historically provided a single "system" version of Java (meaning any system packages that depends on Java depended on this package) which meant that that was the version of Java that you got with Ubuntu XX.XX - even for LTS releases which had a 5 year lifespan. Ubuntu 16.04 - which is still in support came with openjdk-7 and Canonical refused to provide an openjdk-8 package for it despite Java 8 being the prevalent development platform from late 2016 onwards and despite numerous requests to do so. No one was expecting Canonical to replace openjdk-7 with openjdk-8 - they only wanted to be able to install openjdk-8 along side the existing openjdk-7 system Java. Ubuntu 18.04 - slightly different scenario but still the same problem - openjdk-8 and openjdk-11 are available but that still doesn't cover all development use cases. Thus, people add the PPA and install the openjdk from there because someone currently is doing the work of keeping the PPA up to date.

curt15 6y ago

>The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Perhaps a business reason left unsaid is that an open source snap store would undermine Canonical's paid "enterprise edition" snap store. Why would an organization pay $30000 (https://ubuntu.com/internet-of-things https://ubuntu.com/internet-of-things) for a private app store if they could easily set up their own snap store?

BruiseLee 6y ago
And that is exactly why it would be very expensive to open source it. All this revenue ($30000 * number of paying organizations) would then be gone.
xet7 6y ago
That revenue funds bandwidth, server etc costs of those downloading Snap packages for free.

ocdtrekkie 6y ago

> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. I posit that this doesn't matter. Presumably Ubuntu's infrastructure should be open source so that it can be inspected if necessary, for security reasons. It shouldn't matter if nobody else is actually hosting an alternative copy... it is still important that their copy be open source.

michaelmrose 6y ago

Nearly every packaging system is able to successfully divorce building of software from offering artifacts for download let alone ops. This is arguing that having failed to design their system appropriately we ought to accept the fruits of that bad design instead of dumping Ubuntu. Compare this with apt. Second what you describe as a defect. There being multiple sources of software is a plus it means the power is in the hands of the user to decide whom to trust. What you don't want is a situation where people must configure additional sources just to have commonly needed software. The example you provide about the Java PPA is apt, pun intended, ideally commonly required software would be provided by the vendor instead of siloed in a third party source. Of course the vendor and the license must make this possible.

johannes1234321 6y ago

> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Launchpad has a weird user experience and was for a long time too much focussed on bazaar when git won. At work we used bazaar and lp for a while, but still I always have to search for the right path for getting to a project's code. The bug tracker was more useful than GitHub's but that didn't help ... Aside from that there are the legal implications of AfferoGPL which prevent many people from touching it. But yes, doing infrastructures is hard. I however don't know how complicated hosting is and how well it's packaged. For software starting for in-house use this often is a mess ...

rdschouw 6y ago

I do not think anyone disputes Ubuntu's goals or intentions. The problem is that the snap store is managed by Ubuntu without any community oversight. By not releasing source code to the store, other distributions cannot create their own. These are the reasons what is holding snap back for broader adoption.

kd913 6y ago
>The problem is that the snap store is managed by Ubuntu without any community oversight. That is already the case for most repos/launchpad on Ubuntu but people don't really have too much problems with that. >By not releasing source code to the store, other distributions cannot create their own. Other distributions wouldn't because the operational cost of operating it is too high. >These are the reasons what is holding snap back for broader adoption. Snap isn't being held back by adoption. It has more first party publisher support and more installs.

dilandau 6y ago

>snapd not open-source. Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user. >I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines. Imagine strawman-ing this hard.

kd913 6y ago
>Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user. Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. I could remove snapd there without people making that decision for me. Worse would be Mint's decision of removing the only FOSS built version of chromium without offering an alternative in place. Canonical only installed the chromium snap because they did not have the resources to support a deb version instead. >Imagine strawman-ing this hard. It isn't a strawman. It is precisely what their reasoning was and it makes perfect sense. The snap store has already seen people attempt to install cryptominers. There is no way in Flatpak of banning known malicious flathub repos.
- the_af 6y ago
  > Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. If I understood the issue correctly (and I may very well be mistaken!) the problem Mint has with Canonical is that Ubuntu has "hijacked" (for lack of a better term) some apt packages so that they now actually install snapd and the snap. So you think you're opting out of snap, but when you use apt to install Chromium you end up using snap anyway. If I understand correctly, this is Mint's main complaint: that Ubuntu seems to be hijacking apt packages with snap.
  - kd913 6y ago
    There is no apt package with Chromium. https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-transition https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-trans... Canonical couldn't afford the maintenance costs for it. On Ubuntu distributions it's either the snap or you have to create some weird frankendeb aspect by pulling from Debian. They explained it better than I would. In other cases, I don't think of a case where apt installs snaps over apt. I think the only priority for the decision choice was based on most recent version. Although this aspect I am slightly unclear.

einpoklum 6y ago

> Namely that it would be expensive to open source it with little benefit in return. Ok, so the whole technology is irrelevant and should not be used then. > Canonical already spent a large amount of investment opensourcing launchpad Why develop it as non-open-source to begin with?