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

[jo-erlend]

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.

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. Even if you _could_, you simply wouldn't want to replicate Canonical's infrastructure just to run a simple web service. If you're a distributor with an existing infrastructure, you would want to use that. If you wanted something more like a simple apt repo, you would just run a simple service, that you can write in a weekend.

i don't understand why people are so desperate for Canonical to ship a product that nobody else would ever use.

[RahulSundaram]

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.

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.

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.

[mppix]

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.

I'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.
I'd prefer the link to Canonical's server that is used with the snap packages in ubuntu.

Ubuntu Core is used in many embedded products and by Raspberry Pi users, for instance.

Are you saying that Ubuntu Core is built exclusively on snap and completely without deb?

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_

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...

[jo-erlend]

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.

There is no reason for them to invest large sums of money making their internal business setup generalized. While it is true that I don't know where in their network files are stored or how their customer databases are setup, which CRM/ERP systems they use, etc, I do know that they have integrated both Launchpad and Landscape, along with their UbuntuSSO, a CDN, etc. In order for them to let you just use your own SSO implementation, your own payment systems, etc, they would have to invest a great deal of money. And for what? So that your enterprise should not have to integrate snap with your own pre-existing systems?

[jo-erlend]

I'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.

This is the Google search I used to find this link: "open source snap store github". For me, the first hit is the correct one. Did that really require my assistance? https://github.com/gjsman/snapstore. Look at the source and tell me you couldn't write that yourself.

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.

I just don't understand why. They've spent twenty years building their network and it would be an enormous mess of dependencies, many of which you cannot obtain and would have to rebuild in order to be compatible. It would be easier for you to start from scratch and only implement the ties you need. It simply wasn't built to be a general product. It relies on their UbuntuSSO, their Launchpad, Landscape, internal CRM/ERP systems, databases, storage systems, CDNs, etc, etc.

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?

Yes, Ubuntu Core is an atomic system with a read-only root filesystem, so debs or rpms cannot be used. Ubuntu Core would've formed the basic platform for the convergence platform, with Ubuntu Personal being provided as a platform snap providing a display server, etc, as a foundation for environments like Unity 8 or others. This is also the reason why Mir was designed for server-side buffer allocation, since it would be used on phones, where you rarely have more than one window visible and the importance of saving RAM and power is much greater than it is on a powerful desktop or laptop. Also, having a server-based DS allows for throttling so that for instance, a media player cannot paint video while the output is invisible to reality, like if your phones screen is shut off.

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?

I linked specifically to the official documentation of why Flatpaks are not suitable for servers, which was asked in this thread. If you're reacting to it, I'm guessing it was you.

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...

No they wouldn't. The way snap is designed, is for whole-system distribution, so if you were going to use it as-is, then it would be because you're currently running a distro and wanted to add snap to it. You could simply ship a fork of the client. If you wanted to use it more like FlatPak is used, then you could simply ship a fork that uses a different namespace. You could call it crackled and mount your Crackles in /crackle instead of /snap, for instance. That's really simple stuff.

Again; FlatPak cannot replace Snap. I linked to the FlatPak documentation so you would hear it from FlatPak developers instead of me.

[RahulSundaram]

While it is true that I don't know where in their network files are stored or how their customer databases are setup, which CRM/ERP systems they use, etc, I do know that they have integrated both Launchpad and Landscape, along with their UbuntuSSO, a CDN, etc

Yes, it is clear you don't know their internal setup but it seems you are also unaware that things like SSO and CDN etc you cite use standardized protocols and you can switch providers with a few lines of configuration. I would recommend reading up on them.

[jo-erlend]

Yes, it is clear you don't know their internal setup but it seems you are also unaware that things like SSO and CDN etc you cite use standardized protocols and you can switch providers with a few lines of configuration. I would recommend reading up on them.

Show me the source code to prove that claim.

[RahulSundaram]

Show me the source code to prove that claim.

You seem confused, the burden of proof here is entirely on you here since you are the one making positive claims about their proprietary software based on your own assumptions.

[mppix]

This is the Google search I used to find this link: "open source snap store github". For me, the first hit is the correct one. Did that really require my assistance? https://github.com/gjsman/snapstore. Look at the source and tell me you couldn't write that yourself.

Did you even read the first page of the project that you linked?
Quote: "Right now, installing snaps from this snapstore does not work."

And yes, it needs your assistance because you (as opposed to everybody else) seem to know that the snapstore is open source (it is not but feel free to try again).

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?

Most self respecting open-source projects moved to gitlab or are in transition. I don't know enough about launchpad to comment.

I just don't understand why. They've spent twenty years building their network and it would be an enormous mess of dependencies, many of which you cannot obtain and would have to rebuild in order to be compatible. It would be easier for you to start from scratch and only implement the ties you need. It simply wasn't built to be a general product. It relies on their UbuntuSSO, their Launchpad, Landscape, internal CRM/ERP systems, databases, storage systems, CDNs, etc, etc.

You would spend a great deal more time installing Canonical's snap store than you would creating your own.

Actually this is only true if the code is badly written.
Flatpak is capable of providing a functional server.
I kind of find this argument ridiculous because you could say this for almost anything, for example: you don't need nextcloud, you are faster setting up your only mail/calender/filesharing server.

Yes, Ubuntu Core is an atomic system with a read-only root filesystem, so debs or rpms cannot be used. Ubuntu Core would've formed the basic platform for the convergence platform, with Ubuntu Personal being provided as a platform snap providing a display server, etc, as a foundation for environments like Unity 8 or others. This is also the reason why Mir was designed for server-side buffer allocation, since it would be used on phones, where you rarely have more than one window visible and the importance of saving RAM and power is much greater than it is on a powerful desktop or laptop. Also, having a server-based DS allows for throttling so that for instance, a media player cannot paint video while the output is invisible to reality, like if your phones screen is shut off.

I don't know enough about Ubuntu Core. I do a lot of embedded Linux programming but I still have to come across Ubuntu Core. Maybe, I'm just in a different field. My first reaction is that it seems to break a lot of conventions that I happen to like even in embedded systems.

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 have no idea partially because ...

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.

... you are right, I don't care enough to learn Ubuntuisms there is a chance they get wider adoption in the ecosystem.

I linked specifically to the official documentation of why Flatpaks are not suitable for servers, which was asked in this thread. If you're reacting to it, I'm guessing it was you.

Thanks for explaining. However, no, sorry, was not me.

No they wouldn't. The way snap is designed, is for whole-system distribution, so if you were going to use it as-is, then it would be because you're currently running a distro and wanted to add snap to it. You could simply ship a fork of the client. If you wanted to use it more like FlatPak is used, then you could simply ship a fork that uses a different namespace. You could call it crackled and mount your Crackles in /crackle instead of /snap, for instance. That's really simple stuff.

Is it now?
I would really, really, like to see your distribution that runs every single repo in a sandbox.
At best it would be bloated and less efficient. More realistically, many packages would not work in sandboxes without major rewrites.
It is hard enough to get this to work for applications such that they don't need to rely on nasty Xorg hacks but can go through portals.
Good luck with simple, unless you are suggesting to blow every sandbox wide open (in which case, what is wrong with deb/rpm or if you like distribution of upstream packages: arch?).

Again; FlatPak cannot replace Snap. I linked to the FlatPak documentation so you would hear it from FlatPak developers instead of me.

Stating that 'FlatPak cannot replace Snap' is a complete misquote from the link but if it makes you happy

[jo-erlend]

Did you even read the first page of the project that you linked?
Quote: "Right now, installing snaps from this snapstore does not work."

Because the developer hasn't maintained it, so when the API was changed, it became incompatible. How does that change anything I wrote?

And yes, it needs your assistance because you (as opposed to everybody else) seem to know that the snapstore is open source (it is not but feel free to try again).

That is a pure lie. I have never in my life said that Canonical's snap store is open source. I have tried to explain their explanation for keeping it proprietary and why it shouldn't matter to you at all. All the parts that are relevant to you, are open source, meaning the client and the API.

Actually this is only true if the code is badly written.
Flatpak is capable of providing a functional server.

Flatpak is only used for apps. It is not a centralized software distribution. The similarities between Snap and FlatPak are superficial. They are very different things.

I kind of find this argument ridiculous because you could say this for almost anything, for example: you don't need nextcloud, you are faster setting up your only mail/calender/filesharing server.

internal systems that are never supposed to be used by anyone else, are usually "poorly written", in the sense that they're not designed for public use. it is totally normal that internal systems are not generalized, because generalizing a system is expensive and why would you pay for that when you know that nobody else will ever use the system?

I don't know enough about Ubuntu Core. I do a lot of embedded Linux programming but I still have to come across Ubuntu Core. Maybe, I'm just in a different field. My first reaction is that it seems to break a lot of conventions that I happen to like even in embedded systems.

I don't really see how that is relevant to anything in this context.

... you are right, I don't care enough to learn Ubuntuisms there is a chance they get wider adoption in the ecosystem.

Then I don't understand why you're so passionate about running a clone of Canonical's snap store. My point and pretty much my only point, is that you shouldn't. If you want to run your own Linux distribution, then you should figure out for yourself what features you want to provide and how you want to provide them.

I would really, really, like to see your distribution that runs every single repo in a sandbox.
At best it would be bloated and less efficient. More realistically, many packages would not work in sandboxes without major rewrites.
It is hard enough to get this to work for applications such that they don't need to rely on nasty Xorg hacks but can go through portals.
Good luck with simple, unless you are suggesting to blow every sandbox wide open (in which case, what is wrong with deb/rpm or if you like distribution of upstream packages: arch?).

Why would it be bloated? The packages are compressed and obviously, snap supports sharing dependencies. Snaps get access to whatever they need access to. That is what interfaces are for. You do not appear to know even the absolute basics of how snaps work and that puzzles me considering the enormously strong opinions you have. But this is all beside the point. I am not in any way trying make you like snaps. The only thing I'm saying, is that if you want to run a snap-based Linux distro or use snaps in your existing distro, then you should implement the API yourself.

Stating that 'FlatPak cannot replace Snap' is a complete misquote from the link but if it makes you happy

It wasn't a quote at all. The documentation tells you that FlatPak is designed for desktops. If you want to explain how you would build an entire Linux distro using FlatPak only, I'd bee interested in hearing it. Because that's what snaps are designed for.