Page 7 of 7 FirstFirst ... 567
Results 61 to 67 of 67

Thread: What's the rationale that Ubuntu now wants to install everything in a snap package?

  1. #61
    Join Date
    Jun 2010
    Location
    London, England
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    Snaps depends on systemd, so a good way to avoid it long-term is to use a systemd-free distro
    Are you sure? Systemd is Redhat software. Debian developers working for Redhat pushed for its inclusion into Debian. As Ubuntu is based on Debian we get SystemD in Ubuntu.

    https://en.wikipedia.org/wiki/Systemd

    Snap applications need snapd which is installed by default in newer versions of Ubuntu

    https://snapcraft.io/docs/installing-snap-on-ubuntu

    The argument in Debian over SystemD was so fractious that a group of Debian developers who lost the argument left Debian and forked the code. Canonical employees working on Debian were ordered by Mark Shuttleworth not to get involved in the discussions. Even though it was Canonical code that was dropped from Debian in favour of SystemD Ubuntu continued to be built on Debian and so we are using a distribution that has SystemD by default. And now SnapD.

    Lets us not rewrite history. There is enough of that going on in the media.

    Regards
    It is a machine. It is more stupid than we are. It will not stop us from doing stupid things.
    Ubuntu user #33,200. Linux user #530,530


  2. #62
    Join Date
    Aug 2009
    Location
    Ireland / The Czech Repub
    Beans
    280
    Distro
    Ubuntu 20.04 Focal Fossa

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    So what you are saying is... snaps... are a conspiracy?
    __________________

  3. #63
    Join Date
    Apr 2008
    Location
    Southern California, USA
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    Quote Originally Posted by Artim View Post
    ... Snaps depends on systemd, so a good way to avoid it long-term is to use a systemd-free distro (Slackware, MX-Linux, antiX, or my favorite, PCLinuxOS).
    I'm using Arch Linux, it has systemd, and snaps are not installed by default

  4. #64
    Join Date
    Mar 2009
    Beans
    1,982

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    Snaps, docker and kubernetes (SDK from now on) all change the type of responsibility for the developer, and all require more space on the host to implement an application.

    They also, unlike a regular VM, use the kernel of the host. So all this talk of "any version, any age, any computer" is not really correct. There is a kernel compatibility level that must be met.

    Each app has its own toolchain, they may share a specific version of a library or they may have a separate one. This is the two-edged sword.

    On the one hand, each app developer can have the best tool chain to run their specific app without interference from some other app's requirements. If you're talking about a mission critical application with lots of development resources then that's great, because you could test the heck out of it, have a third party audit of your SDK container, and then certify that the container has a certain guaranteed quality. On the other hand, if the app developer drops the ball then it makes the app certifiably junk.

    SDK are all terrible in terms of an end user trying to do a security audit. If you're trying to get a web site up with, say, a credit card payment system, you need a certification for your site. You have third party audits, you need to answer questions that are difficult and irritating to answer on a traditional system, and a nightmare to answer when using SDK. But if the app developer certifies the container then suddenly it's all golden for the end user again.

  5. #65
    Join Date
    Nov 2009
    Location
    Texas
    Beans
    59
    Distro
    Ubuntu 18.04 Bionic Beaver

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    Quote Originally Posted by 1clue View Post
    all require more space on the host to implement an application.
    I don't think that this is really a major concern for server or desktop. Space is cheap.


    I think this is only really a problem for embedded which, I don't imagine Canonical is going to ship glibc as a snap anytime soon.

  6. #66
    Join Date
    Apr 2008
    Location
    Southern California, USA
    Beans
    Hidden!
    Distro
    Ubuntu Development Release

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    "Space is cheap." That's Windows motto for sure. My Windows install takes up 23 gigabytes. My snapless Arch less than 5 gigabytes. I have more tools on my Arch than my Windows has.
    Lots of redundant keepsake.

    Just because you have the space, doesn't mean you need to fill it. Years and years ago, I remember having limited filder names(8?). Once that was solved people got crazy with folder names.

    Guess I'm too old and conservative for that nonsense.

  7. #67
    Join Date
    Mar 2009
    Beans
    1,982

    Re: What's the rationale that Ubuntu now wants to install everything in a snap packag

    Quote Originally Posted by Hwęt View Post
    I don't think that this is really a major concern for server or desktop. Space is cheap.


    I think this is only really a problem for embedded which, I don't imagine Canonical is going to ship glibc as a snap anytime soon.
    You're right, space is cheap. But even embedded equipment has ridiculous storage capabilities right now. So my only disagreement is that "normal" new and future embedded systems will be every bit as capable of this type of thing.

    For the record, the thread is about snaps. Snaps are typically apps that people might see, where docker/kubernetes focuses on "invisible" services. Same idea, but embedded doesn't really do desktop stuff, so we're diverging the discussion by pursuing that line of thought.

    Quote Originally Posted by VMC View Post
    "Space is cheap." That's Windows motto for sure. My Windows install takes up 23 gigabytes. My snapless Arch less than 5 gigabytes. I have more tools on my Arch than my Windows has.
    Lots of redundant keepsake.

    Just because you have the space, doesn't mean you need to fill it. Years and years ago, I remember having limited filder names(8?). Once that was solved people got crazy with folder names.

    Guess I'm too old and conservative for that nonsense.
    I'm old and conservative too, and don't really see the need for all this on just somebody's pc.

    Back in the early days of DOS/Windows <99, every app shipped DLLs of a particular version, or hacked somewhat to make their app work. What sucked is that there was no mechanism to distinguish which DLL belonged to which app, and every app looking for a DLL with that name either got the right one, the wrong one or a bunch of them with no way to decide. So I'm saying that SDK (snaps, docker and kubernetes) solves this issue if no other.

    The real way to answer "snap or no snap" is to ask another question: What are you trying to accomplish?
    1. It is still possible to build most software traditionally, with very few apps requiring special versions or modifications to resources. The more apps your system has, the harder it is to achieve this because not all app developers are worried about keeping things up to date. Most modern operating systems have a way to specify specific libraries by version, and have multiple versions or even variants (modified code from standard) and keep track of all that.
    2. The traditional mechanism gives the app developer less control over the environment they're in. So that method makes testing more difficult for them.
    3. Full virtualization definitely has its place, especially if you need security between apps. It's a proven and ubiquitous technology.
    4. SDK offers a solution of a reliable, reproducible environment for the app developer and a simple black box packaging strategy for the end user.
    5. The problem with SDK is when you care what's in the box. We need better ways to control what goes in there and verify/certify what's inside for a particular use not anticipated by the app developer.


    This SDK approach is relatively new, and while I think it's ready for real work it's not completely ready for mission critical stuff unless the site implementers really know what they're doing.

    The elephant in the room is, what do we have to do differently in order to make this type of arrangement work? When is it worthwhile to do this, and when should we leave it alone?

    We also need to realize that each administrator will have different answers to these last questions and possibly each will have different answers depending on which system they're administering.

    All these things are likely here to stay in some form.

Page 7 of 7 FirstFirst ... 567

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •