Originally posted by jo-erlend
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 mppix View PostI'm not asking about the API, or documentation. I'm asking you to post the link to the _open_source_snap_server_ repository that you claim exists.
Also keep in mind that when Launchpad was criticized for not being released as an Open Source product, Canonical invested heavily in making it suitable as a general product for other organizations and then released it as an Open Source product. But the Open Source world doesn't use it, because they prefer the proprietary Microsoft GitHub service. Why should they repeat that mistake and waste a lot of money on something nobody really cares about, but only uses as an excuse to rage on about something?
I'd prefer the link to Canonical's server that is used with the snap packages in ubuntu.
You would spend a great deal more time installing Canonical's snap store than you would creating your own.
Are you saying that Ubuntu Core is built exclusively on snap and completely without deb?
My personal opinion is that the Ubuntu convergence story was very well designed and if we could've had Gadget Snaps for all modern Android phones, I think that the world of Linux phones would've been greatly advanced. Canonical could've released Ubuntu Core images for Samsung phones, for instance, signing all the necessary NDAs to be allowed to provide the proprietary drivers for those phones, and then they could've supported Linux on those phones long after they were EOLed by manufacturers.
I sometimes get the impression that people who most love to hate snaps, haven't really paid any attention to the reasoning behind the system.
why are you linking flatpak here?
No, ubuntu would not need to allow a new snap server.
However, they would need to ship snap client packages and the gnome-software-snap plugin that have they support enabled or it is a nonstarter.
This is very unlikely so it is flatpak in the long run...
Again; FlatPak cannot replace Snap. I linked to the FlatPak documentation so you would hear it from FlatPak developers instead of me.
Leave a comment:
-
Originally posted by RahulSundaram View Post
We have been through this before. Absolutely no reason at all for this is highly integrated into their internal setup. You already admitted you have no specific awareness of their internal setup and you are just making assumptions, so there is no reason for you to continue to claim this now. Frankly, this is a terrible point.
Leave a comment:
-
Originally posted by jo-erlend View PostIt'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.
I'd prefer the link to Canonical's server that is used with the snap packages in ubuntu.
Originally posted by jo-erlend View PostUbuntu Core is used in many embedded products and by Raspberry Pi users, for instance.
Originally posted by jo-erlend View PostWriting 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_
No, ubuntu would not need to allow a new snap server.
However, they would need to ship snap client packages and the gnome-software-snap plugin that have they support enabled or it is a nonstarter.
This is very unlikely so it is flatpak in the long run...
Leave a comment:
-
Originally posted by jo-erlend View Post
Exactly. Since in the case of Canonical that is highly integrated with their internal _setup_, since you object to the word "configuration", you would not be able to use their implementation. That is the entire point.
No modern application would mix code and configuration. It wouldn't pass muster on even a basic review. Frameworks like Django make this very natural. All internal configuration would be completely separate from code without any special effort.
Leave a comment:
-
Originally posted by RahulSundaram View Post
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.
i don't understand why people are so desperate for Canonical to ship a product that nobody else would ever use.
Leave a 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.
Leave a 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).
Leave a 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.
Leave a 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).
Leave a comment:
Leave a comment: