Originally posted by tomas
View Post
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
-
-
Originally posted by jo-erlend View Post
Flatpaks don't host your kernel. They are very different systems.
Comment
-
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?
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
-
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.
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
-
Originally posted by mppix View PostYou 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 )
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
-
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.
FYI, from what we do know from elsewhere it is a Django application, not some janky scripts with hardcoded passwords.
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.
"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
-
Originally posted by jo-erlend View PostYou 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.
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 PostThere 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.
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 PostSo 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.
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
-
Originally posted by RahulSundaram View PostYou didn't stop at passwords, you also mentioned bank accounts, for a backend server to hardcode any
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
-
Originally posted by mppix View PostCan 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.
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.
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
-
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.
Comment
Comment