Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Debian Ubuntu Linux

Adios Apt and Yum? Ubuntu's Snap Apps Are Coming To Distros Everywhere (arstechnica.com) 274

An anonymous reader shares an Ars Technica report: Ubuntu's "snappy" new way of packaging applications is no longer exclusive to Ubuntu. Canonical today is announcing that snapd, the tool that allows snap packages to be installed on Ubuntu, has been ported to other Linux distributions including Debian, Arch, Fedora, and Gentoo among others. To install snap packages on non-Ubuntu distributions, Linux desktop and server users will have to first install the newly cross-platform snapd. This daemon verifies the integrity of snap packages, confines them into their own restricted space, and acts as a launcher. Instructions for creating snaps and installing snapd on a variety of distributions are available at this website. Snaps can exist on the same system as either deb or RPM packages. Snaps aren't the only new package manager for Linux distributions that aims to simplify installation of applications. There's also AppImage and OrbitalApps.
This discussion has been archived. No new comments can be posted.

Adios Apt and Yum? Ubuntu's Snap Apps Are Coming To Distros Everywhere

Comments Filter:
  • lol (Score:2, Funny)

    by Anonymous Coward

    Hay, finally a universal app for Linux!

  • And hello problems (Score:5, Insightful)

    by phorm ( 591458 ) on Tuesday June 14, 2016 @02:46PM (#52317265) Journal

    Adios to tried and true package managers, hello dependency and network/firewall hell as you try to resolve conflicts between the different sources?

    • Re: (Score:3, Funny)

      by Anonymous Coward

      Curses you package installer!!! No really, how do I install Curses with this?

    • by armanox ( 826486 )

      I thought the idea was for snaps was that it would be statically linked packages so that they wouldn't depend on the system libraries (so basically we're moving back to /opt) and could theoretically have multiple versions of the same thing installed?

      • by phorm ( 591458 )

        TFS does a crappy job of describing that, as certainly no such system is going to replace the primary package manage (apt/yum).

    • by tlhIngan ( 30335 ) <slashdot@@@worf...net> on Tuesday June 14, 2016 @04:33PM (#52318147)

      Adios to tried and true package managers, hello dependency and network/firewall hell as you try to resolve conflicts between the different sources?

      Well, snaps actually are trying to solve this.

      Let's say you have a critical program you need for your work. And let's also say that it needs specific versions of software installed - you can't upgrade those dependencies or your risk breaking the program.

      Now, all package managers have the ability to freeze a package - that is, prevent updating it. So you dutifully do it, and it works great - in the beginning. Slowly as time goes on the number of updates you get will slow to a trickle as you get more and more new packages dependent on newer versions of the dependencies. Eventually you'll get to a point where you can't install anything as what you want needs a newer version than what you have, or is dependent on things that need a newer version.

      Snaps help solve that - your program can be made into a snap with the versions of libraries it needs, while the rest of your system marches forward

      It doesn't matter what the application is - if it needs specific revisions of dependencies, holding back can lead to various DLL hells.

      Snaps won't replace apt or yum - those tools are always going to be required. Snaps are useful for programs with a tricky set of dependencies to have them easily met

      • by Dadoo ( 899435 ) on Tuesday June 14, 2016 @04:55PM (#52318365) Journal

        Snaps help solve that - your program can be made into a snap with the versions of libraries it needs, while the rest of your system marches forward

        That sounds a lot like the "winsxs" folder, which is currently eating up 25% of the total space on my Windows machine, for no good reason. Having the same "feature" on Linux really doesn't thrill me.

      • Snaps are useful for programs with a tricky set of dependencies to have them easily met

        I suspect snaps will be used for far more than 'tricky dependencies'. They'll be used as an excuse to not keep code up-to date, because developers will be able to continue using obsolete 'legacy' libraries instead of coding against newer ones which will presumably be more secure and/or more stable.

        Having said that, I still look forward to the day when I can install a snap of almost any application, in almost any version, (and even several versions of one program, say, Kicad), and be fairly likely to have th

      • by cheesybagel ( 670288 ) on Tuesday June 14, 2016 @06:11PM (#52318983)

        So in other words the "solution" is the Microsoft way of shipping a copy of the .dlls with every single program. So if someone finds a security issue with .dll (say OpenSSL) even if the bug gets fixed in the library you need to issue updates to all the apps as well. Fun.

        • What would be really nice is if libraries would report backwards compatibility, so that you could default to using the latest version compatible with your program, but still have the "canonical" version bundled in case of program-breaking changes.

          It sounds like Snaps are primarily targetting desktop software, and frankly if it's a choice between being as up-to-date and secure as possible, or being able to actually run the program that does what I need to do, I'll choose the second one every time. Besides,

      • by Anonymous Coward on Tuesday June 14, 2016 @06:41PM (#52319145)

        FUCKING AWESOME!

        You mean certain programs can opt to keep using vulnerable libraries?! YES! Soon Linux will finally catch up to Windows in terms of malware thanks to Snap!

      • Let's say you have a critical program you need for your work. And let's also say that it needs specific versions of software installed - you can't upgrade those dependencies or your risk breaking the program....

        It seems that you have not heard of library symbol versioning.

    • Well, no, thankfully. "ported" of course doesn't mean "switched to." This is significantly misleading, but it will at least help with packages that don't have support on multiple distros. Not surprising when the headline writer thinks "yum" is still one of the package managers...

  • by Anonymous Coward on Tuesday June 14, 2016 @02:48PM (#52317275)

    In the year 2016, where can I, a long time Linux user, get a decent UNIX-like Linux distro?!

    What I mean by that is a Linux distro that follows the UNIX philosophy of simplicity, doing one thing well, openness, and modularity.

    All of the major distros today, including conservative ones like Debian, are rife with systemd, GNOME 3, now this "snap" crap, and all sorts of other shenanigans that violate the UNIX philosophy.

    I don't want to use a goddamn relic like Slackware, either. I guess what I want is Debian, but just before systemd was forced on Debian users. So a distro that's sensibly conservative, that's reliable, that works, and that follows the UNIX philosophy.

    And don't even bother suggesting Devuan. It's a terrible, terrible joke of a distro in my experience. Conceptually it's what I'd want, but in practice I've found it to be a total shitfest.

    At this point I don't think I'll have any choice but to use FreeBSD. Yeah, it's not Linux, but I don't think that I even care about using Linux at this point. I need a UNIX-like system, and if FreeBSD can deliver (and all of the evidence suggests that it can!) maybe I should just say to hell with Linux and use FreeBSD instead.

    • by LichtSpektren ( 4201985 ) on Tuesday June 14, 2016 @02:53PM (#52317325)
      Your post is rife with self-contradiction. Pick one:

      1) I want to avoid modern technologies as much as possible because I hate them (therefore use Slackware, Devuan, CRUX, Gentoo, etc.).
      2) I want a modern distro that uses mainstream technologies (therefore use Ubuntu, Fedora, openSUSE, Debian, etc.).
      3) I want my own custom mix of 1 & 2 exactly how I like it (therefore make your own distro).
      • by jedidiah ( 1196 ) on Tuesday June 14, 2016 @03:00PM (#52317393) Homepage

        It's not a contradiction. A better way of putting it might be "more Unix and less Windows please".

        It remains to be seen whether today's iteration of "yet another standard" is going to reduce the number of standards or just increase them (as is usually the case).

        Also, dpkg and rpm are already widely supported. Moving to something new wipes out all of that progress. Churn for it's own sake in general does that.

        We're not Microsoft. We can't burn something down and completely redo it every release like they do. We don't have the clout for people to put up with that kind of nonsense.

        • It's not a contradiction. A better way of putting it might be "more Unix and less Windows please".

          It remains to be seen whether today's iteration of "yet another standard" is going to reduce the number of standards or just increase them (as is usually the case).

          Also, dpkg and rpm are already widely supported. Moving to something new wipes out all of that progress. Churn for it's own sake in general does that.

          We're not Microsoft. We can't burn something down and completely redo it every release like they do. We don't have the clout for people to put up with that kind of nonsense.

          Ignore the clickbait headline. Nobody is saying "deprecate apt and yum". Snappy was invented to be used in parallel to them.

      • by skids ( 119237 ) on Tuesday June 14, 2016 @03:43PM (#52317777) Homepage

        I don't know if I'd throw the term "modern" around so much as "trendy". After all, isolating apps in containers where they cannot integrate with the rest of the OS is pretty much warmed over mainframe thinking.

      • by Junta ( 36770 )

        I think the issue is that there is a lot of welcome new work, and a lot of unwelcome new work. This is of course nothing new and has been the case from the beggining of time.

        However, this time, systemd is not something that can be opted out of so simply. You could for the most part pick and choose which things you thought were good and gleefully ignore what you don't like. systemd is not something that can be ignored in the event you disagree with it as a distro embraces it.

        Thus far, Devuan has come the

    • Here's the way I'm going. [linuxfromscratch.org] I'm happy with slackware nowdays tho. Pretty easy tp update it. It actually *is* pretty close to a classical UNIX, but of course BSD actually *is* UNIX.... bear in mind that originally UNIX didn't *have any* package management. It required you to use your brain and put in some effort. In many cases it still does, compared to the other systems on the market.
    • by andrewa ( 18630 )
      You seem to have talked yourself into FreeBSD by the end of your post. Go for it...
    • by Lennie ( 16154 )

      Someone collects links here: http://without-systemd.org/wik... [without-systemd.org]

    • Slackware current has updates a recent as today, how exactly is a still actively maintained distro a relic? Or are you referring to their website which hasn't been updated in ages?
    • by armanox ( 826486 )

      What's wrong with Slackware? They usually have a yearly release cycle (little behind right now, but it's in RC stages), regular security patches, easy to install software, releases ship with updated kernel, KDE and XFCE for desktop users, plus the collection in slackbuilds as an extra software repo - all the power is in your hands. The only thing that I'm not sure about running on Slackware is Google Chrome - I didn't try when I was running Slackware, but I did have Chromium installed.

      Also, snaps don't se

    • Ever try Gentoo? or Funtoo?

      • This. Gentoo's Portage is modelled after BSD Ports, and it follows a minimalist unix style in many other ways. At the same time, it uses the GNU userland on the Linux kernel for a much better hardware and software availability. And no, it doesn't use systemd by default. As a side effect of the compilation thing, Gentoo is a nice environment for developers [iki.fi].

    • by lannocc ( 568669 )
      I have to recommend Gentoo for you. Gentoo is really a meta-distribution... and super flexible. You can use OpenRC if you like SysV style init, or you can use systemd if you like the new way. You can use it with Linux kernel or you can use it with BSD kernel. Gentoo is a great system to really discover and learn about what brings a working distribution together and do things the UNIX way.
    • by dbreeze ( 228599 )

      Here ya go Snowflake... http://www.linuxfromscratch.or... [linuxfromscratch.org]

  • I Like Apt (Score:5, Informative)

    by Thelasko ( 1196535 ) on Tuesday June 14, 2016 @02:49PM (#52317281) Journal
    When I first tried Linux, I didn't understand the repository system. I had been so used to the Windows .exe files I didn't understand downloading my programs from a single secure repository. One day, it clicked. The repository system is so much better. No more worrying about compatibility, or someone adding malicious software to my programs. It all comes from one secure repository and is known to be compatible with my system.

    In fact, that model works so well, Apple and others now use the same model. They call it an "App Store". I've even heard rumors that Microsoft wants to switch to this model

    So, why is Linux going back to the old, and inferior way of doing things?
    • I still prefer the idea of static build executable. Shared libries while a good idea doesn't work well for lesser known libraries.

    • I've even heard rumors that Microsoft wants to switch to this model

      Do you mean the PackageManagement module that comes standard with Windows 10/Server 2016?

      It's kind of a package manager manager. It's a set of simple commands that let you add and use different package managers ("Providers") and their repositories ("Sources"). They all manage dependencies and whatnot in their own way, but it seems like a nice start.

      Chocolatey is the provider with a lot of bread and butter FOSS and even MS binaries you might be looking for. For instance, you can install 7-zip, FreeMind, or

    • by Raenex ( 947668 )

      The repository system is so much better. No more worrying about compatibility, or someone adding malicious software to my programs.

      Any software you install is potentially malware or contains an exploitable bug -- all it takes is one to slip through. As it stands now, on a typical Linux distribution when you run a program it has full access to all of your account.

      Linux really needs to move towards "app" models where the programs are self-contained and explicit permissions are required for sharing. This is a step in that direction -- though I haven't looked at the details as to how good it is.

  • by LichtSpektren ( 4201985 ) on Tuesday June 14, 2016 @02:50PM (#52317295)
    1) DEBs and RPMs aren't going anywhere; they serve different functions from Snappy Core. Snaps are better for servers that require zero downtime because they prevent ABI breakage as packages are updated asynchronously. DEB and RPM are better for desktop, mobile, and less-important servers because they take up monumentally less room (because you don't have to have a million versions of the same dependency installed at the same time).

    2) As TFS indicates, Snaps can coexist with all the other packaging tools (apt, dnf, yum, zypper, slapt, portage, pacman, etc.).

    3) A large percentage of the Linux community are [a] too suspicious of Canonical to ever adopt any of their technologies and [b] conservative to the tried-and-true methods of doing things. apt will probably live forever on account of that.
    • by gmack ( 197796 ) <[gmack] [at] [innerfire.net]> on Tuesday June 14, 2016 @03:25PM (#52317635) Homepage Journal

      I don't know if I agree with point 1. SNAPS (as a concept) should be better for third party apps because the APP as it is packaged, now imports all of the libraries it needs. The downside of course, l is that if some library has a security issue, you must wait for the package maintainer of each SNAP app that contains it to do the update.

      • by guruevi ( 827432 )

        And there is the issue, we can barely get package maintainers to support their regular apps with many "apps" being hopelessly out of date on various standard platforms (try anything: Sympa, Drupal, MySQL, nginx, Apache, PHP... - you'll be several point versions if not major version numbers behind the 'stable' version available from the original websites).

        • you'll be several point versions if not major version numbers behind the 'stable' version available from the original websites

          Unless the original website is providing the 'snaps'. I run several vendors' yum repos, preferentially to the distros' versions of their app. It gets updates when needed, not when an additional volunteer has time to look at it.

        • by Junta ( 36770 )

          Particularly since the whole advertised benefit is you don't have to keep up with the distro, mr. app developer. Which means you are explicitly trying to attract folks who are almost certainly *also* too lazy to keep up with CVEs and such. At least with dynamic linking, you have some *hope* of fixing lots of app problems externally without the app maintainers specific attention... here....

          • Particularly since the whole advertised benefit is you don't have to keep up with the distro, mr. app developer. Which means you are explicitly trying to attract folks who are almost certainly *also* too lazy to keep up with CVEs and such. At least with dynamic linking, you have some *hope* of fixing lots of app problems externally without the app maintainers specific attention... here....

            I also imagine that I would need to check my system *and* all the snaps for CVE updates, rather than just the system. I look forward to telling my manager and/or customer that the system is mostly up-to-date, except for snaps and having to track down those separate developers to get things fixed. Perhaps fine when it's against an app, but not so much when against libc. (sigh)

        • by ADRA ( 37398 )

          Maintainers would be a lot more motivated to fix their dependency issues if its trivial to fix (across all architectures/OS's). It also means that my Xyz app doesn't need an Ubuntu maintainer, Fedora, Mint, etc... or even if they did, the surface area becomes significantly smaller. For what its intended for, it seems pretty great. This all assumes near universal Linux distro adoption, but I like it in concept.

    • by Junta ( 36770 )

      Snaps are really better for things like Chrome, third party applications that don't want to screw with actually following the distribution roadmaps. They are specifically architected to provide for mobile 'apps' to attract developers that are too lazy to keep up with distributions (btw, that would also mean too lazy to keep up with security vulnerabilities, by and large). On the server side, if you are still worried about 'downtime' in a way that any single system can impact, you are almost certainly doin

  • by Pseudonymous Powers ( 4097097 ) on Tuesday June 14, 2016 @02:50PM (#52317299)

    ...that the answer to any question posed in a headline is "No".

    I'd be all for a single consistent package management system for Linux that everyone could get behind. This isn't that. This is just a third option everyone's going to have to deal with.

  • by RavenLrD20k ( 311488 ) on Tuesday June 14, 2016 @02:54PM (#52317337) Journal

    Et tu, Gentoo? Then fall Linux

    Snapd seems to be spreading with the same wildfire potential that systemd did. I hope I'm cringing over nothing in this case and snapd will only be an optional package management system (so far it sounds like it). But I'm leery. Systemd fractured a lot of distros with the "my way or the highway" attitude they had over it. I managed to avoid it on my servers where just about everything run on it right down to the compiler time sharing are background user processes. If even more distros move on pushing snapd in the same way it may finally be time for me to look into one of the Beasties to migrate to... either way, there's going to be a lot of workflows that will need analysis for migration one way or the other.

    • systemd didn't "do" anything. Most Linux distro communities voted or otherwise decided that they only wanted to support systemd.

      Snappy Core used by itself has a lot of disadvantages to apt, yum, etc. so it likely won't replace any of them (ignore the clickbait title). However it can be used well in parallel to them.
      • Most Linux distro communities voted or otherwise decided that they only wanted to support systemd.

        "Wanting to support" something and "accepting it because upstream is shoving it down your throat and forking is too much work" are two different things.

        • Most Linux distro communities voted or otherwise decided that they only wanted to support systemd.

          "Wanting to support" something and "accepting it because upstream is shoving it down your throat and forking is too much work" are two different things.

          What's the "upstream" here? The only case where that seems to apply is Ubuntu switching from upstart in order to stay in sync with Debian. Fedora, openSUSE, Debian, and Arch all decided entirely of their own volition.

          • They made Gnome dependent on systemd which pushed it on the distrobutions.

          • by fnj ( 64210 )

            What's the "upstream" here? The only case where that seems to apply is Ubuntu switching from upstart in order to stay in sync with Debian.

            There is a myriad of other Debian offshoots besides Ubuntu. Ubuntu has its own ecosystem, but just about all the others are stuck with whatever crap the asshats at Debian may decide on a whim to pollute Debian with.

    • Snapd seems to be spreading with the same wildfire potential that systemd did.

      Not really ... it was pushed to AUR which anyone can do and is in COPR like anyone can do.

      No one from the Fedora side has worked on this, the Canonical employee who has that COPR is not a Fedora packager and the various desktop communities have been coordinating on Flatpak

      I'd strongly suggest never taking a Canonical Press Release at face value given the recent history with them...

  • "snapd"? (Score:3, Funny)

    by idontgno ( 624372 ) on Tuesday June 14, 2016 @02:55PM (#52317351) Journal

    We all know this technology won't really be mature until "snap management" is fully subsumed and integrated into systemd, where it belongs.

  • >> "Snaps aren't the only new package manager for Linux distributions that aims to simplify installation of applications. There's also AppImage and OrbitalApps."

    Said without irony.
  • by nimbius ( 983462 ) on Tuesday June 14, 2016 @03:07PM (#52317443) Homepage

    And i think i speak for us all when I say I'll be in the cold cold ground before i ever trust some bull-shit packager repository more than portage. Shuttleworth can eat my ass like groceries.

    • Re: (Score:3, Insightful)

      And i think i speak for us all when I say I'll be in the cold cold ground before i ever trust some bull-shit packager repository more than portage. Shuttleworth can eat my ass like groceries.

      I don't understand the hostility. Canonical developed a new tool for you to use if you want to, for free (as in both beer and speech). Nobody is taking portage away from you.

      • by Junta ( 36770 )

        I think it's a lot of paranoia related to the systemd controversy. Before that, things that people might have bitched about could be used or ignored at will. systemd, being a pretty core init system is something people couldn't easily step away from as an individual choice (unlike, say, desktop environments). Now *every* thing that could *conceivably* be construed as 'core' is going to be regarded with more worry than before.

  • by adosch ( 1397357 ) on Tuesday June 14, 2016 @03:16PM (#52317547)

    Seems like all my /. posts have been crabby, complacent, old-hat UNIX/Linux sys-admin ranting as of late. F me I need to lighten up...

    With that out of the way, I do have to say: Who said that installing packages was hard on a *NIX platform that we needed snapd to solve this? I'm sorry, I really think package repositories like apt/yum are gosh-darn God-sends when set up, populated, built and maintained correctly. I use them in-house and it really makes deployment, configuration management, deployment and all that stuff most people care about, well, easy. Why would I need 'another' package manager to sit 'alongside' my existing one to do updates? In regards to RPM based distros, isn't that what drpms and alike were suppose to solve? And not to mention you can checksum, roll-back, push/pull version specific, ect.

    This just sounds like yet another shitty reinvention of wheel idea with YOLO douchey distro dev backers that I'm going to see take over yet another great part of Linux distro's as we know it --- I thought enough was enough with systemd.

    • by Ash-Fox ( 726320 )

      Who said that installing packages was hard on a *NIX platform that we needed snapd to solve this?

      Linus Torvalds actually mentions the issues relating to this being one of the primary reasons he believes desktop adoption is problematic for Linux.

      I'm sorry, I really think package repositories like apt/yum are gosh-darn God-sends when set up, populated, built and maintained correctly.

      I think they are too, however for desktop applications and their developers, I think they are problematic because it involves g

    • Re: (Score:2, Insightful)

      Again, nobody is taking apt or yum away from you. Snappy Core is meant to complement them. If you don't like it, don't use it. As it stands now, you're being a huge douchebag because Canonical developed a technology with their own time and money and are offering it to the Linux community for free, and you're thrashing and crying about it.
      • by fnj ( 64210 )

        Again, nobody is taking apt or yum away from you.

        Yeah. I don't know which is stupider, the stupid headline, or the stupid blockheads who are running terrified in circles moaning "oh noze they are taking away apt".

    • This just sounds like yet another shitty reinvention of wheel idea with YOLO douchey distro dev backers that I'm going to see take over yet another great part of Linux distro's as we know it --- I thought enough was enough with systemd.

      It's things like this that make me think Linux on the desktop peaked in 2010. Everything has been downhill since.

  • We don't even have anything as capable as apt and yum. Meanwhile Linux is moving ahead even further.

  • "confines them into their own restricted space"

    I'd like to know more on this. What restricts them? Are they, like, restricted by SE Linux to only act in their own little space, or is something outside the kernel doing this restriction? Whenever I hear about these types of access control, I always get concerned. All these sandboxes and jails have ways out of them normally, and the more obscure, the longer they wait, and their mere existence and claims makes people trust the supposedly protected applicati

    • In theory AppArmor ... except confinement only works under Mir ...

      And as for the cross distro stuff in the PR statement? The Arch build disables the confinement tech (since it's a Canonical special and not upstreamed) and the Fedora COPR in addition to that only "works" with selinux not enforcing.

  • I seem to recall a big panic over some fundamental security flaws in Snaps, something about them leveraging the worst ways X11 is written. Unless it's some convoluted way to try and progress what seems to be the IPv6 of the display server world (Mir / Wayland), isn't spreading this thing to other distros a bit of a bad idea?

    • You recall a kerfuffle over the fact that if you use X11 on a system you are no more secure than X11 is (which is to say, not very). Snaps do not allow one single system-wide X11 server, so that particular flaw is avoided.

  • by PPH ( 736903 ) on Tuesday June 14, 2016 @03:52PM (#52317853)

    That run in some sort of 'restricted' space? Fine. But what about all the other components of a Linux distro that aren't apps, can't run in a restricted space and will never be ported to the Snap model?

    I think apt, yum and their kin will be around for a long time. Snap sounds like an environment written for people like the ones that thought Microsoft Windows Metro apps would be all that users would need.

  • I could get behind this for some programs - especially games.

    It might be a little space-wasting for "core" stuff.

Can anyone remember when the times were not hard, and money not scarce?

Working...