Announcement

Collapse
No announcement yet.

Snapcraft 6.0 Coming To Finally Move From Ubuntu 18.04 To 20.04 LTS Base, Phase Out i386

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by tomas View Post

    Exactly. Flathubs infrastructure is all 100% open source an anyone can in fact easily host flatpaks on other sites which is already done today. Why should snaps infrastructure be any different? Are any snaps available from other sources than Canonicals snap store?
    Flatpaks don't host your kernel. They are very different systems. There are snaps from other sources, yes. There is a snap of VCMI with the proprietary arts from HOMM3, for instance. That's obviously not legal, so it can't be hosted on Canonical's service. They obviously aren't signed by Canonical, so you have to trust the source of the package.

    Comment


    • #42
      Originally posted by jo-erlend View Post

      Flatpaks don't host your kernel. They are very different systems.
      From a licensing perspective, they are very much comparable systems and has overlap in functionality as well. Flatpak has a fully free and open source backend. Snap doesn't. If the reasons for that is because somehow they are hardcoding passwords, accounts and so forth in their backend, that seems pretty awful for security nevertheless and that's not typical.

      Comment


      • #43
        Originally posted by jo-erlend View Post

        All traditional distros are closed ecosystems. There is nothing special about that. Debian has supported software like alien forever, allowing users to install packages from other closed ecosystems, like Fedora. I think that Debian only cares that the software is Free Software. Snap is GPLv3 and Debian shouldn't mind it at all. There are even Debian repositories that only serves proprietary software and they don't ban those, so what's different?
        You are describing the flatpak model.
        Snap has only _one_ server/hub (I assume with the intent to 'rule them all' but we saw the end of lord of the rings already so .. - someone should tell Canonical )
        Last edited by mppix; 22 September 2021, 06:40 PM.

        Comment


        • #44
          Originally posted by RahulSundaram View Post

          From a licensing perspective, they are very much comparable systems and has overlap in functionality as well. Flatpak has a fully free and open source backend. Snap doesn't. If the reasons for that is because somehow they are hardcoding passwords, accounts and so forth in their backend, that seems pretty awful for security nevertheless and that's not typical.
          It is very typical to use passwords in launch scripts, yes. There is nothing insecure about that, but obviously, it was only an example. I have no knowledge of how Canonical has setup their internal network. All I know is that there would never be a reason for me to care.

          The snap backend is just a normal web server. It doesn't matter what's happening on the inside of a web server and you must have root access to the server to know how it's really configured anyway. i just don't understand why so many people are so fanatical about knowing how Canonical's web server fetches the files you're downloading. i've never heard this in any other situation in the Free Software community in all my life and we are both currently using such a proprietary web service, since we don't have root access to Phoronix' servers. For some reason, that doesn't seem to bother you.

          If you want to download a Debian package from http://example.com/deb/vlc.deb, for instance,you would not complain about the fact that you don't know where vlc.deb _actually_ exists on the server system. All you care about is that you get the file you're asking for. Why should this be different just because the file has a snap extension?

          Comment


          • #45
            Originally posted by mppix View Post
            You are describing the flatpak model.
            Snap has only _one_ server/hub (I assume with the intent to 'rule them all' but we saw the end of lord of the rings already so .. - someone should tell Canonical )
            You know that you can install snaps from any source you want, right? Packages doesn't have to come from Canonical's snap store. You can easily envelope them in a Deb or an RPM , for instance, or receive one in an email or download one from a Google Disk share. And obviously, even though snapd only supports one snap store at a time, there is no issue with each distro running its own snap store, because it's 100% Free Software.

            There is a fundamental difference between Flatpak and Snap in that Snap is used for whole systems and not just apps. You can have different versions of an app coming from different repos, but you can't do that with your kernel. Well, you can, but it's an obvious security nightmare. I'm not comfortable with the fact that installing Google Chrome gives Google the right to patch my kernel at will, for instance. That is not an issue with Flatpak, because it only deals with desktop apps and not system stuff.

            So if you want to add multi-service support to snapd, that would be great, but you would have to figure out how to deal with that issue. It's not unsolvable, but Canonical has no incentive to invest in that, because they intend to run their service. The way Free Software and Open Source works and has always worked, is that it is the person who wants a feature that should develop that feature. Claiming that a GPL product is proprietary because the upstream hasn't developed some feature that you want, is misrepresenting what Free Software is and how it works.

            It would be great to see someone implementing support for multi-service on snapd. Do it and then criticize Canonical if they refuse to accept your great patch. That's how it works. When they chose to license this product under the GNU Public License, they explicitly gave you permission to do this. To say that they used the GPL because they wanted to ensure that the system would be proprietary, is to misrepresent the GPL, with all the implications that comes with it.

            Comment


            • #46
              Originally posted by jo-erlend View Post

              It is very typical to use passwords in launch scripts, yes. There is nothing insecure about that, but obviously, it was only an example. I have no knowledge of how Canonical has setup their internal network. All I know is that there would never be a reason for me to care.
              ...
              The snap backend is just a normal web server.
              You didn't stop at passwords, you also mentioned bank accounts, for a backend server to hardcode any of that is not typical at all and yes of course hardcoding passwords in plain scripts this way is obviously insecure and I very much doubt that's how they maintain their infrastructure. You admit you have no idea about what their backend looks like, so no reason to assume they are scripts or just a normal web server either.

              FYI, from what we do know from elsewhere it is a Django application, not some janky scripts with hardcoded passwords.

              https://forum.snapcraft.io/t/is-the-...-source/9202/2

              "AFAIK the store is a python+django-based application. It is currently proprietary and there haven’t been any announcements about whether the source is going to be opened or not. There used to be a third-party application that re-implemented the APIs and the source code to that application was available, but it has since been abandoned and is no-longer compatible with the current store APIs."

              I will wait for someone with a more informed understanding of what the backend looks like to chime in.

              Comment


              • #47
                Originally posted by jo-erlend View Post
                You know that you can install snaps from any source you want, right? Packages doesn't have to come from Canonical's snap store. You can easily envelope them in a Deb or an RPM , for instance, or receive one in an email or download one from a Google Disk share. And obviously, even though snapd only supports one snap store at a time, there is no issue with each distro running its own snap store, because it's 100% Free Software.
                Can you point me to the open-source code of the snap store?
                Also, it would be helpful if you could post a tutorial (or link to a tutorial) how to setup our own snap store.

                Originally posted by jo-erlend View Post
                There is a fundamental difference between Flatpak and Snap in that Snap is used for whole systems and not just apps. You can have different versions of an app coming from different repos, but you can't do that with your kernel. Well, you can, but it's an obvious security nightmare. I'm not comfortable with the fact that installing Google Chrome gives Google the right to patch my kernel at will, for instance. That is not an issue with Flatpak, because it only deals with desktop apps and not system stuff.
                Can you please reference who uses "snap for whole systems"?
                Both flatpak and snap can be used in the command line and in theory to setup an entire system. I would not recommend that ... for different reasons.
                Fundamentally, the main problem with both is that that you don't want to sandbox everything... User apps (gui and terminal), sure. System apps, no.


                Originally posted by jo-erlend View Post
                So if you want to add multi-service support to snapd, that would be great, but you would have to figure out how to deal with that issue. It's not unsolvable, but Canonical has no incentive to invest in that, because they intend to run their service. The way Free Software and Open Source works and has always worked, is that it is the person who wants a feature that should develop that feature. Claiming that a GPL product is proprietary because the upstream hasn't developed some feature that you want, is misrepresenting what Free Software is and how it works.

                It would be great to see someone implementing support for multi-service on snapd. Do it and then criticize Canonical if they refuse to accept your great patch. That's how it works. When they chose to license this product under the GNU Public License, they explicitly gave you permission to do this. To say that they used the GPL because they wanted to ensure that the system would be proprietary, is to misrepresent the GPL, with all the implications that comes with it.
                Now, why would anyone do this?
                One would need to write an open-source server, convince canonical to allow it, maintain it, etc.
                And for what? Flatpak has this already (and more).

                Comment


                • #48
                  Originally posted by RahulSundaram View Post
                  You didn't stop at passwords, you also mentioned bank accounts, for a backend server to hardcode any
                  The only point is that their internal server configuration is of no use to anyone else.

                  Implementing a simple jSON API is child's play and if you did need Canonical to understand how to do it, you should obviously not be a software distributor to begin with.

                  Comment


                  • #49
                    Originally posted by mppix View Post
                    Can you point me to the open-source code of the snap store?
                    Also, it would be helpful if you could post a tutorial (or link to a tutorial) how to setup our own snap store.
                    It's a quick Google search. You can find documentation on the API in the snap documentation. it's a very simple thing to implement it, unless you need to setup an advanced setup like Canonical's,with Landscape integration, etc.

                    Can you please reference who uses "snap for whole systems"?
                    Ubuntu Core is used in many embedded products and by Raspberry Pi users, for instance.

                    Both flatpak and snap can be used in the command line and in theory to setup an entire system. I would not recommend that ... for different reasons.
                    Fundamentally, the main problem with both is that that you don't want to sandbox everything... User apps (gui and terminal), sure. System apps, no.
                    It has nothing to do with command lines, but the fact that Flatpak requires a running desktop by design.

                    Now, why would anyone do this?
                    One would need to write an open-source server, convince canonical to allow it, maintain it, etc.
                    And for what? Flatpak has this already (and more).
                    Writing the "server" is obviously very basic stuff. Canonical would not have to allow it, since it is GPLv3 and they would not have to maintain your server or even the client, since as a software distributor, you are perfectly able to do that yourself.

                    https://flatpak.org/faq/#Can_Flatpak...n_servers_too_

                    Comment


                    • #50
                      Originally posted by jo-erlend View Post

                      The only point is that their internal server configuration is of no use to anyone else.

                      Implementing a simple jSON API is child's play and if you did need Canonical to understand how to do it, you should obviously not be a software distributor to begin with.
                      Nobody asked for their internal configuration. It's a misdirection. Also a backend isn't just a "simple json api", it includes a db, caching layer, categorization, search. auth and so on.

                      Comment

                      Working...
                      X