Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Ubuntu Linux

Ubuntu 18.04 LTS Could Come with Snap Apps Preinstalled (omgubuntu.co.uk) 139

Posted by msmash from the modest-proposal dept.
Ubuntu 18.04 LTS 'Bionic Beaver' could ship with Snap apps installed by default. From a report: A proposal from Ubuntu developer Steve Langasek suggests that Snapcraft now stand as a 'first-class' alternative to traditional packages, making them ripe for inclusion. "As more software becomes available as snaps, we want to take advantage of this body of packages as part of the default Ubuntu experience," he writes. As part of his proposal -- which is just a suggestion for the moment, so don't get excited/angry -- Langasek wants to iron out policy and rules around seeded snap app. This is to ensure they are updated and maintained accordingly, inline with Ubuntu practice. While Snaps by default would be something of a first for the regular version Ubuntu, it wouldn't be a first in general. That honour goes to Ubuntu MATE 17.10, the first distro to ship with a preinstalled Snap app.
This discussion has been archived. No new comments can be posted.

Ubuntu 18.04 LTS Could Come with Snap Apps Preinstalled More

Ubuntu 18.04 LTS Could Come with Snap Apps Preinstalled

Comments Filter:

  • Found the LUDDITE! (Score:1)

    by Anonymous Coward

    Snap App really means for LUDDITE software! Modern app appers only app APP apps, NOT LUDDITE Snap Apps!

    Apps!

  • I've been waiting for the next LTS release (which should be 18.04) before upgrading from 16.04. Unfortunately there is a bug in CUPS in the 16.04 LTS release that nobody cares about that causes CUPS to randomly die without warning or logging. I resolved this by having cron restart it every 5 minutes, but that is a bit sub-optimal.
  • I'm sure there's a snap for that...

  • Security concerns? (Score:1)

    by Anonymous Coward
    I'm curious what kind of horrendous security wholes this would open up? It seems like anything called Snap would probably want to install/upgrade itself without permission, potentially blowing a whole wide open for various malware and miscreant NSA stuff much like the Windows world users have to deal with currently. I did not move to Linux and sacrifice usability simply to be exposed to the same toxic cesspool of malware.

    • Re: (Score:2, Funny)

      by Anonymous Coward

      I'm curious what kind of horrendous security wholes this would open up?

      Is that better or worse than security halves?

    • Because if a shared library is updated for a security problem, the "app" doesn't get it until it is updated too.

    • I'm just glad I always stuck with a boring, business-friendly distro from the RedHat family.

      If you're wallowing in a toxic cesspool of malware, it is probably because you used the same distro as the Cool Kids(TM). And Cool Kids(TM) need a lot of code thrash. Security is that boring stuff that some killjoy adds right before the brogrammers get fed up and switch to New Black 0.1.

    • A Snap is a container package which runs in a confined space and includes both the binary and its dependencies. It doesn't have, or need, access to the rest of the system.

      It can run on any distribution because it isn't dependent on libraries installed in the district.

      There are some positives in terms of security. A snap application is in some ways isolated from the rest of the system, so a security issue with one snap app doesn't affect the rest of the system as much. In particular, just because you have

      • A Snap is a container package which runs in a confined space and includes both the binary and its dependencies. It doesn't have, or need, access to the rest of the system.

        Yes, they basically re-invented static linking, because disk space is now, apparently, cheap enough to waste and have multiple copies of every library used (updated independently). And, yes, I understand the (at least, supposed) benefits of containerized applications, but am still not sold on using snaps over traditionally packaged applications and actually shared libraries.

        • > have multiple copies of every library used (updated independently)

          Which, besides disk space, is good and bad for security.
          If an old program needs an old copy of a lib that old (insecure) lib is only used by that one snap. On the other hand, with shared libraries, updating the one system copy of the lib updates it for all applications. There is no reason to think that ALL snaps using a library will update every time the library is updated. Unless of course that were built into the system, but I don't t

      • To reduce disk space there are at least a KDE runtime and a GNOME runtime and perhaps others so they aren't necessarily self-contained anymore.

  • A Question on the Difference (Score:4)

    by ytene ( 4376651 ) on Friday February 09, 2018 @03:36PM (#56096659)
    In the linked article, the author seems to be making an argument that one benefit of using Snap Apps is that, particularly with LTS releases, there comes a point at which package maintainers simply stop providing "new" packages for a release which may have been generally available for two or more years.

    If I understand this particular argument, the author is making a case that "snap apps" have the ability to "stay current" - something which may be relevant for software packages on fairly short release cycles, such as browsers [Firefox] or office suites [LibreOffice].

    But what is not clear from this section of the article is whether snaps contain some inherent functionality that makes them more suitable for this than traditional Debian-pased .deb packages. Can anyone help clarify this, just to give the article some context please?

    Thanks.

    • I'm too lazy to look into it myself, but I would have to guess that each app would have to have a separate copy of every dependent library instead of using the system-wide one. Tons of disk space, slower loading, and more RAM usage would be the obvious side effects.

    • As far as I understood, snaps are similar to static linked software. Everything, or almost everything, that an application needs is package within the snap. So, if I got this right, it would look like two package managers in action: one for applications (snaps) and another for the OS (debs). Only the OS is LTS.

      You get, of course, all of the issues of out of date libraries being used by the snaps.

    • They can "stay current" as in upstream can release a snap for their new version that then every system using snap can use immediately. So upstream does not have to provide a separate version for Debian 7, Debian 8, 10 versions of Ubuntu, 2 versions of RHEL and so on. I.e devs and companies that are familiar with the Windows model wants this because they see the normal distribution model of Linux a fragmented and that fragmented is bad.

      I and lot's of other devs that are used to how things work in Linux-land

      • That's a silly claim. That isn't what it is for, obviously, because this expands the number of different packages that have to be maintained.

        Different distros use different packages for actual reasons.

        This is a new flavor for the debian family, which is already badly fragmented, and it expands their fragmentation. But don't expect RHEL to join them in that mess! That's a silly-sauce prediction.

        Upstream already doesn't provide the RHEL packages. That's what makes them "upstream."

        • This is exactly what it all is for. With snap you create a package that contains the application that you provide plus all it's dependencies in a self contained directory. Snapd is currently not available for RHEL afaik but they are working on it. Any snap can run on any system where snapd runs.

          And btw lot's of upstream does binary distribution, and many of them provide RHEL packages so I don't really get your point here.

    • Snaps runs in a "container" like environment, carrying all the required libraries. While they're huge (when compared to .debs), they can be updated without the dependency hell.

    • Re: (Score:2)

      by jrumney ( 197329 )
      Snap apps come with all their dependencies bundled into a huge monolithic Windows Installer like package. They are not dependent on the OS installed versions of libraries at all, which makes them well suited to apps developed by young ADHD developers who only build against git HEAD of their third party dependencies.

  • WTF is a snap app (Score:4)

    by HeckRuler ( 1369601 ) on Friday February 09, 2018 @03:38PM (#56096671)

    Presumably something that installs programs?

    But hip and new and calls them apps?

    Come on people, the world of tech is wide and deep. You don't have to define what Ubuntu is, but you do have to define what the hell this new thing is.

    • Re: (Score:2)

      by Hasaf ( 3744357 )

      From the webpage https://snapcraft.io/ [snapcraft.io]

      "Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification."

      • Re: (Score:3)

        by sinij ( 911942 )
        So they reinvented MSI installer, only on Linux?

      • "And because they bundle their dependencies..."

        This makes it sound almost as if we didn't already have static libraries. Or as if they were a good choice for things provided by the distro. Sure, stuffing all the dependencies into an application is fine if you're distributing it directly to customers, but for distros to do that for "upstream" packages is just insane bloat.

        And it seems easy and convenient until something like heartbleed happens and each application has its own bundled security hole. I'd much

    • where everything's included in the package. No library links so in theory it'll run on any Linux. It reminds me a bit of how Mac apps used to work where you just dragged a folder over and it was installed, as opposed to the Windows world of complex installers or the Linux world of dependency management via apt-get or RPM.

      If true it sounds like a holy grail. Build one package to run anywhere. No more Linux app fragmentation. No more dependency hell and all day games of hunt the repository. But it also so

      • Re: (Score:2)

        by dhaen ( 892570 )
        Indeed it would be a version of the holy grail. As a multi platform admin I find that mostly Mac applications are easiest to deal with. Their bundles are convenient and not that wasteful of space - the contained libraries are tiny and certainly dwarfed by comparison with leftover dregs I find on a certain other popular platform.

        • Re: (Score:2)

          by tepples ( 727027 )

          Their bundles are convenient and not that wasteful of space

          I remember reading horror stories of a "hello world" app written in the Swift language taking several megabytes because of the size of the required Swift runtime. The overhead per bundle would appear to encourage bigger, more complicated apps as opposed to the smaller, more focused apps associated with the UNIX philosophy.

      • That's what we started with, with static linked libraries, so if that was the Hole Grail then dynamic libs should have never been invented.

        I'm not buying it. This is not a list of advantages from something new, this is an old tradeoff that usually goes the other way, but with only the pros listed. I guess some people are falling for it because they look at the nouns instead of at the semantics. And it does indeed have a nifty new name.

        • Re: (Score:2)

          by tlhIngan ( 30335 )

          That's what we started with, with static linked libraries, so if that was the Hole Grail then dynamic libs should have never been invented.

          Dynamic linked libraries are still better, even as snaps, because you can still update the library in a snap. Static link libraries make it impossible.

          You also get the advantage of if libfoo is vulnerable, you can find all isntances of libfoo through the snaps as well. You can't if it's a static library because libfoo will be embedded inside the binary which is much more

          • Re: (Score:2)

            by tepples ( 727027 )

            Dynamic linked libraries are still better, even as snaps, because you can still update the library in a snap.
            [...]
            So just because you linked against version 1.0.0 of libfoo, doesn't mean it will work against version 1.0.1.

            If 1.0.0 and earlier have a security vulnerability, but the application does not work does not work with 1.0.1 and later, what should users of the application do to transition from the application to a replacement application?

          • Right, quality libraries like glibc don't have a problem, because they do the work to have a stable API and maintain backwards compatibility.

            Crapware that breaks from 1.0 to 1.0.1 is just crapware, finding the right crutch to make it easier to install crap is not guaranteed to solve the problems.

    • I thought TFS was talking about Snapchat, which changed its name to Snap.

      So my initial take on the story was, Ubuntu will come with Snapchat preinstalled. Presumably they got paid by Snap, Inc. to do this, similar to how Mozilla gets paid by Google to be its default search engine.

      Turns out this wasn't it at all.

  • Comment removed based on user account deletion

  • Snap packages are great but (Score:5, Informative)

    by Rosco P. Coltrane ( 209368 ) on Friday February 09, 2018 @03:52PM (#56096743)

    They're humongous and completely inefficient. Case in point, vlc:

    As a Debian package (assuming you have the other libs of course):

    $ apt-cache show vlc | grep Installed-Size
    Installed-Size: 4828 (4.7M)

    As a Snap package:

    $ du -ch /snap/vlc/current/ | grep total
    771M total

    Snap packages have no dependendy problems, can be installed on any platform, are dead easy to maintain and very easy and safe to install/uninstall.

    BUT! They start much slower, waste a LOT more disk space and a LOT of memory - since each Snap package is self-contained, and each package has different libraries that need to be loaded.

    I use Snap packages to try out software easily, or to install a testing version of some software on a stable machine without messing up all my libraries (in the case of vlc, to use the version that plays Youtube videos correctly, since the stable Debian version is hopelessly outdated). But really, having 3 of 4 of them in an otherwise normal, lean install is as much as I'm willing to put up with.

    An entire distro distributed as Snap package is plain suicidal.

    • Wow. That is an eye opening difference!

    • Snaps are not meant to be size-efficient. They're meant to easily bring software to a platform without all the traditional headaches of mucking with dependencies, builds, etc. I like the idea. Also, why are we still concerned about resources? Hardware is cheap.

      • Re: (Score:1)

        by Anonymous Coward

        Since when do we muck with dependencies? You must be using distros from 15 years ago

    • Dependencies in snap packages may also be behind in updates

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      Thank you. The majority of comments seem to side on the argument, "Well, we have space, so why should we care?" You should. Always. This is the major problem that I'm seeing with people who code now vs say, 20 years ago. Oh, lets import this entire library for one function that we probably could have optimized and created our own. So what if it takes another 4MB of ram, thats nothing. Compound that by people who never close applications, or have slightly older hardware, and it becomes an enormous mes

      • Re: (Score:2)

        by jrumney ( 197329 )

        Oh, lets import this entire library for one function that we probably could have optimized and created our own. So what if it takes another 4MB of ram, thats nothing.

        It sucks that you're stuck using Windows 98, but modern operating systems will load libraries using mmap, so they don't actually take up physical RAM for the unused portions.

    • Re: (Score:1)

      by Myrdos ( 5031049 )

      Perhaps they could factor out some of the libraries, and store them in some convenient place on the filesystem. Then each snap app would only need to list its required libraries, and the OS would provide the corresponding files. A dependency list, if you will.

    • I use Snap packages to try out software easily, or to install a testing version of some software on a stable machine without messing up all my libraries

      You can install multiple versions of libraries on one machine without messing anything ip, just don't set --prefix to /usr/bin when you run ./configure, though even then it probably won't break anything.

    • ...not for slow connections. I can't do these without some hassle on my 1.5M DSL line......

    • Re: (Score:1)

      by Threni ( 635302 )

      Who cares? The download differences (a few minutes instead of a few seconds) offsets the tedium of sorting out dependency problems. The size difference is a few pennies - who gives a shit about that?

      "An entire distro distributed as Snap package is plain suicidal."

      Huh?

    • Disclaimer, I work for Canonical and worked with the VLC devs on the snap.

      The snap of VLC is nearer 190MB, not 700MB for data-transfer and on-disk size comparisons. All snaps are loop-mounted squashfs files. What you are "du"ing is the mounted read-only files. The actual snap file is in `/var/lib/snapd/snaps/` and on my system is 189MB. The snap contains not only VLC but a bunch of libraries of course. However the bulk of the space (300MB uncompressed) is taken up by VLC plugins which make the snap a great

  • I hadn't heard about Snapcraft until now, but taking a look at the site it sounds like it will fix some major problems and make Linux a more viable platform.

    I'm just moving to Linux and have been doing a bit of development. A major drawback I've found is the trouble releasing your software, since it requires multiple builds and different packages for different distributions. The trouble distributing software has been a significant factor in putting me off Linux, but it sounds like Snapcraft will make thin

    • Most of all it will make windows 11 a more viable platform. This is _their_ escape from lib hell.

    • Another thing I've found annoying about Linux is that the software in the repositories is often extremely old and there's no way to upgrade to the latests version. It sounds like Snapcraft will solve this problem as well with auto-updates.

      Snaps will have the opposite problem instead - if the software publisher doesn't update the package, you'll be stuck with out-of-date versions of every library that the application uses. This could be a major issue if there's a serious security vulnerability found in a commonly-used library. Instead of getting a single patched version of the library from the package repository, which will probably only take a day or two, you have to hope that every one of the applications that use that library are updated q

  • "Bionic Beaver" Did they roll-over the alphabet and go back to A?

  • At some point, fellow linux user... (Score:1)

    by Anonymous Coward

    You should decide for yourself, has Ubuntu helped me learn Linux, or how to live in another walled ecosystem?

    You can survive, but when somebody emails you a tarball, or something that ends with .gz do you still have that post-it note that tells you how to install that application?

    Don't get me wrong, I'm all for widespread adoption, but not at the cost of diluting the benefits, or the gene pool.

    I wouldn't call myself an expert, but I still prefer the command line over the candy-colored icons myself.

    So now we

    • You can survive, but when somebody emails you a tarball, or something that ends with .gz do you still have that post-it note that tells you how to install that application?

      No. I reply and ask them why the hell they're using that archaic compression algorithm.

      • No. I reply and ask them why the hell they're using that archaic compression algorithm.

        Because of compatibility. Even a file compressed with "that archaic compression algorithm" is smaller than the combination of the same file compressed with a newer compression algorithm and a decompressor for the new compression algorithm that is itself compressed with "that archaic compression algorithm".

  • Would it be too much to ask... (Score:1)

    by Anonymous Coward

    to focus on broken things before add new crap no one wants, like hibernation and undocking my laptop without the screen screwing up.

    • to focus on broken things before add new crap no one wants

      Yes. If they did things like that, it would soon be the year of the LInux desktop, and that meme would be gone for ever!

      If you want software that actually works, you are supposed to use *BSD. If you want it to work and be secure, OpenBSD - but then it will be slower, and not work with the newer, untested, hardware that fanbois love so much, and you will have to learn how to play Colossal Cave, because there are not many other games that will run.

  • Hooray! Ubuntu will finally have all the security and quality control of a corporate app store!

    Sturgeon's Law is absurdly optimistic.

  • When they get to R it'd better be Robo Cock

  • Is anybody actually building Snap packages for their applications, or is it all just driven by Canonical? In my experience, Snaps are either built by Canonical employees or Canonical seems to be paying application builders to produce Snaps.

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close