Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by msmash on 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.

68 of 139 comments (clear)

  1. Found the LUDDITE! by Anonymous Coward · · Score: 1

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

    Apps!

    1. Re:Found the LUDDITE! by ToTheStars · · Score: 2

      SnApps!

      FTFY

  2. I'll just be happy if CUPS works correctly by damn_registrars · · Score: 1

    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.

    --
    Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
    1. Re:I'll just be happy if CUPS works correctly by damn_registrars · · Score: 1

      Complain to Apple who owns CUPS

      Indeed they do but the Ubuntu folks decide which version of CUPS to ship with a given version of Ubuntu. Some versions work better than others (obviously); they happened to choose poorly this time. Hopefully 18.04 ships with a CUPS version that is better tested for Ubuntu.

      --
      Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
    2. Re:I'll just be happy if CUPS works correctly by dbreeze · · Score: 2

      I love living in Linux Land. Thanks again to Linus and all those who contributed to get us here. I was just remarking to someone recently about how what I loved about running Linux, is that I never feel held back by someone else. I can dig and root around on my computer as far as I can imagine and/or comprehend. There are no walls.
      This place doesn't suit everyone, but I love living here.....

      --
      When the king heard the words of the Book of the Law he tore his robes.2Kings22:11
    3. Re:I'll just be happy if CUPS works correctly by HatofPig · · Score: 1

      Yup! I'm with you. :D And the community surrounding it all, which makes it accessible and friendly is just wonderful. Everything is human in Linux land. And once you learn to RTFM first, you are afforded all the support you could ask for.

      --
      Silicon & Charybdis McLuhan Kildall Papert Kay
  3. Source appears to be slashdotted... by CaptSlaq · · Score: 1

    I'm sure there's a snap for that...

  4. Security concerns? by Anonymous Coward · · Score: 1

    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.

    1. Re:Security concerns? by Anonymous Coward · · Score: 2, Funny

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

      Is that better or worse than security halves?

    2. Re:Security concerns? by greenwow · · Score: 1

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

    3. Re:Security concerns? by Aighearach · · Score: 1

      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.

    4. Re: Security concerns? by Reverend+Green · · Score: 1

      The LTS release/support cycle is a big part of what makes it business friendly. And it's very popularity means an awful lot of software is developed on, or at least tested against, the LTS releases.

  5. A Question on the Difference by ytene · · Score: 3

    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.

    1. Re:A Question on the Difference by omnichad · · Score: 1

      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.

    2. Re:A Question on the Difference by sanf780 · · Score: 1
      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.

    3. Re:A Question on the Difference by F.Ultra · · Score: 1

      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 use build servers where you call a simple script and it then builds a version for all different systems, one benefit here is that you then get to see how your code compiles with different versions of various libraries (my code is better today due to this).

    4. Re:A Question on the Difference by Aighearach · · Score: 1

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

    5. Re:A Question on the Difference by Parker+Lewis · · Score: 1

      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.

    6. Re:A Question on the Difference by F.Ultra · · Score: 1

      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.

    7. Re:A Question on the Difference by jrumney · · Score: 1

      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.

  6. WTF is a snap app by HeckRuler · · Score: 3

    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.

    1. Re:WTF is a snap app by Hasaf · · Score: 1

      From the webpage https://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."

    2. Re:WTF is a snap app by sinij · · Score: 2

      So they reinvented MSI installer, only on Linux?

    3. Re:WTF is a snap app by Aighearach · · Score: 1

      "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 rather forego software that wants to use new features of unstable APIs, and instead have stable APIs and be able to update libraries for security on a systemwide basis.

    4. Re:WTF is a snap app by Spy+Handler · · Score: 1

      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.

  7. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  8. It's a Linux software package by rsilvergun · · Score: 1

    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 sounds too good to be true.

    --
    Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
    1. Re:It's a Linux software package by dhaen · · Score: 1

      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.

    2. Re:It's a Linux software package by Aighearach · · Score: 2

      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.

    3. Re:It's a Linux software package by tlhIngan · · Score: 1

      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 difficult ot analyze.

      So no, even in snaps a dynamic library is better for many reasons.

      The main reason for snaps is because it turns out a lot of libraries are not as compatible as you'd like. Between versions of libraries, things change and binary compatibility between libraries isn't maintained. So just because you linked against version 1.0.0 of libfoo, doesn't mean it will work against version 1.0.1. And non-trivial programs start using more and more libraries, you start running into a lot of issues because of library mismatches. Yes, lots of bugs get exposed.

      If you want to see what happens, take a look at glibc and all the contortions it goes through in order to remain binary compatible - it's why other C libraries often get away with less because they're embedded and thus every program is re-linked against a specific version, while glibc is designed to be internally compatible.

      It ends up a huge mess, and if you want to release your program for various Linux distributions, well, no Linux distribution uses the same version of libraries as other distributions, so you end up having to re-build and re-link your program against every distribution. And if you don't, you'll get strange errors that no one can find - the author (who didn't build it) sees it works fine, while the user (using another distribution's version) has an issue caused by library binary incompatibility.

      Effectively, dynamic libraries are good, but we also end up with a program where we need dozens of installed versions of a library because dozens of programs need a specific version. Linux has reached the point where DLL Hell exists.

    4. Re:It's a Linux software package by tepples · · Score: 1

      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.

    5. Re:It's a Linux software package by tepples · · Score: 1

      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?

    6. Re:It's a Linux software package by Aighearach · · Score: 1

      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.

  9. Snap packages are great but by Rosco+P.+Coltrane · · Score: 5, Informative

    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.

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
    1. Re:Snap packages are great but by The+Faywood+Assassin · · Score: 1

      Wow. That is an eye opening difference!

      --

      "I'm a humble person really,

      I'm actually much greater than I think I am"

    2. Re:Snap packages are great but by Anonymous Coward · · Score: 1

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

    3. Re:Snap packages are great but by Anonymous Coward · · Score: 3, Interesting

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

      Just because your test platform can support something, doesn't mean people who may adopt your solution can.

      How about this? Write your code in the most efficient way possible. Eliminate cruft, and just take pride in what you do. I understand that big business cares more about time to release than efficiency, but do your part. I first installed linux on a machine with 4MB ram (upgraded to 8 soon after). Now I'm pretty sure GRUB uses more than that.

    4. Re:Snap packages are great but by Myrdos · · Score: 1

      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.

    5. Re:Snap packages are great but by serviscope_minor · · Score: 1

      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.

      --
      SJW n. One who posts facts.
    6. Re:Snap packages are great but by jrumney · · Score: 1

      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.

    7. Re:Snap packages are great but by Threni · · Score: 1

      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?

    8. Re:Snap packages are great but by popeydotcom · · Score: 2

      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 out of the box experience of many users, whatever their use case.

      Sure we need to optimise startup time, and that work is ongoing. We could certainly trim the snap down a bit, and I will be looking at that when I'm back from vacation.

       

  10. Hadn't heard about Snapcraft, but it sounds great by Inviska · · Score: 1

    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 things much easier by allowing you to do just one build and bundle all the dependencies.

    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. I just hope there's a way to keep a specific version if you don't want to upgrade.

    These were actually my two biggest issues with Linux, and I'm very enthused to hear there's a solution. It sounds like Snapcraft will make things easier for both developers and users.

  11. Re:have I lived under a rock? by Rosco+P.+Coltrane · · Score: 2

    You've lived under a rock.

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  12. Been a while since I've been in the UBU game... by wardrich86 · · Score: 1

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

  13. At some point, fellow linux user... by Anonymous Coward · · Score: 1

    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 have snap whatever. Just hold your hand out towards the incoming tide and say, No, I'll be fine, thanks

    1. Re:At some point, fellow linux user... by DamnOregonian · · Score: 1

      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.

  14. Re:Hadn't heard about Snapcraft, but it sounds gre by barryvoeten · · Score: 1

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

  15. Would it be too much to ask... by Anonymous Coward · · Score: 1

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

    1. Re:Would it be too much to ask... by Anne+Thwacks · · Score: 1
      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.

      But it will be reliable and secure.

      Like Granny said: You can't have it all In fact, you probably can't have any of it. Sit down and shut up. - well my Granny, anyway - but she had to put up with an IBM709, so you have to make allowances. No one is waiting for the year of the IBM709 desktop.

      --
      Sent from my ASR33 using ASCII
  16. Dependencies may not be patched by HalAtWork · · Score: 1

    Dependencies in snap packages may also be behind in updates

    --
    Twinstiq, game news
  17. Re:Hadn't heard about Snapcraft, but it sounds gre by Dragonslicer · · Score: 1

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

  18. for some reason... by Lead+Butthead · · Score: 1

    "Bionic Beaver" ... for some reason, "Sharon Stone" comes to mine.

    --
    ELOI, ELOI, LAMA SABACHTHANI!?
  19. DRAM price has trended upward by tepples · · Score: 2

    Even if disk space and memory aren't in short supply on full-size tower PCs nowadays, they're still in short supply on compact laptop PCs. And I thought the price of DRAM had been trending upward over the past several years.

  20. A snap that busts your cap by tepples · · Score: 1

    Programs aren't the source for storage issues.

    Downloading new versions of programs is the source for overage issues when security updates for all the snaps that bundle a particular library cause you to redownload said snaps, in turn causing you to exceed the monthly Internet data transfer quota that your ISP imposes on your household.

  21. RAM is twice as expensive as it used to be by tepples · · Score: 2

    Since when in this day and age is hard drive and memory space been an issue?

    Since at least 18 months ago, the general price trend for memory space has been upward. (Source: Memory - Price Trends - PCPartPicker)

  22. Plus and minus for security by raymorris · · Score: 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 one snap that uses an older version of a library doesn't mean you have that older version installed system-wide, where everything has to use it.

    You mentioned a negative (which is also a positive) - Snaps can update themselves without disturbing the rest of the system, so by default they do. That means it *could* update to something malicious, but in most cases updates *improve* security. In the real world, bad guys most often take advantage of known vulnerabilities which have been fixed by updates. So keeping your system up-to-date is one of the best ways you can make it more secure.

    1. Re:Plus and minus for security by fahrbot-bot · · Score: 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.

      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.

      --
      It must have been something you assimilated. . . .
    2. Re: Plus and minus for security by jgfenix · · Score: 1

      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.

  23. Yes, and updating backward compatible libs by raymorris · · Score: 1

    > 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 think it is because backward compatibility can't be guaranteed in general, only known for specific versions of specific libraries.

  24. Re:have I lived under a rock? by ChunderDownunder · · Score: 1

    Weren't snaps the packaging format for downloadable paid apps on Canonical's phone project, Ubuntu Touch? This seems like an attempt to salvage any 'monetizable' aspects of the abandoned wreck.

    By design, I don't think the dpkg format supports proprietary DRM, so if businesses want to ship paid/subscriber-only software, e.g. MS Office 365 for Ubuntu, then snaps would enable that.

  25. Re:Snap packages are great but....... by dbreeze · · Score: 1

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

    --
    When the king heard the words of the Book of the Law he tore his robes.2Kings22:11
  26. That or bundle xz-utils with every package by tepples · · Score: 1

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

    1. Re:That or bundle xz-utils with every package by DamnOregonian · · Score: 1

      Compatibility? With what? bzip2 and xz are ubiquitous, these days.

  27. Re:Until Snaps become so bloated and overconfigura by Hognoxious · · Score: 1

    someone will have a revolutionary idea: we need a new packaging standard.

    I hope and pray that someone isn't Lennart Poettering.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  28. yay! by cas2000 · · Score: 1

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

    Sturgeon's Law is absurdly optimistic.

  29. Bionic Beaver? by Kryptonut · · Score: 1

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

  30. Does anybody actually care about snaps? by noahm · · Score: 1

    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.