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

  • RahulSundaram
    replied
    Originally posted by jo-erlend View Post

    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.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by mppix View Post
    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.

    Leave a comment:


  • jo-erlend
    replied
    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.
    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?

    Leave a comment:


  • mppix
    replied
    Originally posted by jo-erlend View Post
    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.


    Originally posted by jo-erlend View Post
    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?

    Originally posted by jo-erlend View Post
    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...

    Leave a comment:


  • RahulSundaram
    replied
    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.
    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.

    Leave a comment:


  • jo-erlend
    replied
    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.
    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.

    Leave a comment:


  • RahulSundaram
    replied
    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.

    Leave a comment:


  • jo-erlend
    replied
    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.

    Leave a comment:


  • jo-erlend
    replied
    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.

    Leave a comment:


  • mppix
    replied
    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).

    Leave a comment:

Working...
X