A new ‘app store’ is expected to ship as part of Ubuntu 23.10 when it’s released in October — and it’ll debut with a notable change to DEB support.

    • Canonical is just weird like that, it seems. They tend to pick something and fixate on it really hard (Eg. Unity desktop, Mir, that convergent phone thing, now Snaps) and work on it until it’s almost really good, then they get fixated on the next shiny thing and dump whatever they were doing to go chase that instead.

    • There’s a benefit to Canonical, the corp that maintains Ubuntu, which is that while snaps are open source tech, the server for the snap store is closed source and snap can’t be configured to point at another store.

      In other words, it’s about centralized control.

      There are some advantages to the tech itself, like live auto-updating, which is good for security-critical server apps, but over all I’m not a fan.

      •  Recant   ( @Recant@beehaw.org ) 
        link
        fedilink
        English
        5
        edit-2
        1 year ago

        I don’t think that the board members are sitting there and pondering how they can exercise more control on the user via snaps.

        The auto updating is a nice benefit but it doesn’t seem like a big enough benefit to allocate so many developer man hours into. I would think that Canonical would realize that the developers time is better spent making features the users want.

        But what do I know? I’m just someone posting on Lemmy not a Canonical board member haha

      • I believe you’re completely right here, except that snapd can be configured to point to another store, though it’s not very well documented… I did find the piece of information once :).

        But the thing is that the client still only supports one app backing site at a time. So if you pick another one, you lose visibility to the other store. I doubt even updates work as they should.

        So it’s really about building technology that is geared towards centralized control, whereas basically anyone can host flatpak packages and give ref links to them.

    • Snaps are used for Ubuntu’s IOT distro, and also for their upcoming immutable desktop. They even ship kernel and mesa as snap, which makes updating less likely to break a system (in case of a crash while updating, user error, …).

      That’s why they push snap. Canonical doesn’t mainly aim to make a apps available to all distros like flatpak does. Just like now where all distros need their own packages, snap will coexist with other package formats.

      For the user it’s unimportant how apps are installed, as long as they’re available.

    • Aren’t you sorta trusting whoever wrote any package you install with root? I mean, you should have that attitude anyhow as packages have a huge attack surface so privilege escalation bugs are way more common than remote execution but still, flatpak and snap at least offer a bit of a sandbox which might improve…

      • Depends on your distro and what’s available in the repo. With default repos you’re more trusting the distro developer to vet packages.

        I trust debian for that. It’s been a while since I used Ubuntu so I don’t remember how their repos are set up but the debian team is notoriously conservative with their repos.

      • The track record has been very good as far as i know with thousands of packages over the years so I doubt if there is a real problem to be solved here.

    • APT is not good at managing dependency hell. This is a common problem for all package managers that don’t typically bundle dependencies. You can get 30000 open source packages from trusted sources having a maintainer working on each to all share the same dependencies for an OS release. That’s what Debian does. However it’s a lot of work and that works increases significantly when you try to do it for a piece of software across OS releases.

      Read - it’s difficult for LibreOffice or Mozilla to ship a new version of their software that works on several Debian or Ubuntu releases. It’s also difficult for maintainers to do that.

      You could of course include dependencies in debs, but then you’re increasing the security attack surface of the OS, because there’s no sandbox around those bundled dependencies. Bundling dependencies requires sandboxing to be safe. Otherwise whenever there’s a security hole in one library in package X, package X might patch it, but the same library might exist in another 50 packages on the system unpatched.

      This is a solved problem. It was done in Android, iOS, BlackBerry 10 and probably others. All OSes that had to deal with more than 30000 packages, open source or proprietary, from trusted or untrusted sources. Bundle non-system dependencies and confine in a sandbox. Snap’s been doing this ever since it was called Click. Flatpak didn’t have the sandbox part for a while if I’m not mistaken. I’m not sure what its current sandbox state is.

      There are other issues with APT/deb but managing dependencies without sandboxing is probably the most fundamental one since dependency management is one their fundamental purposes.

    • Honestly for new/average users, those who tend to use Ubuntu, I always would recommend Manjaro. Since I use arch btw myself I have a bias but using pacman, being rolling release, and having access to the AUR (+ Flatpaks) set Manjaro apart from other distros for average users.

      But frankly I never understood why Debian itself is considered an “intermediate” distro since it’s no harder than Ubuntu to use IMO.

      • Debian is more bare bones then Ubuntu, that’s why. Ubuntu comes with a lot of packages already installed by default. In Debian you have to install a lot of that stuff manually. You might also have to edit some configs for example. It’s not that hard, but maybe a little too much for a beginner.

        I upgraded Debian to 12 last night, which required manually updating the source.list for the apt repos for example. It’s been a while but I’m pretty sure Ubuntu gives you a UI for upgrades? Upgrading Debian was simple for a techie who’s played around in Linux already, but it could be more intimidating for a newbie.

    • I’m kinda baffled people would jump ship because of this matter
      Snaps have been a thing for 7 years and before that Canonical did similar really weird things (Amazon shopping lense a decade ago anyone?)

      anyone who really cares already uses something else

  • The Fedora software app has been promoting flatpaks over native packages, even not displaying that native packages are available even if they are, requiring the command line tool to access some native packages. So I don’t see how this is fundamentally different.

    • The fundamental difference is that flatpak is a good system, adopted by many distributions.

      Snap sucks and only Ubuntu uses it.

      They’ll do like their Unity UI, wait many years until they realize their mistake then drop it.

          • I beg to differ. I think it’s very harmful.

            • There as absolutely no reason for anyone in Arch to use snap to install something mainstream like Firefox. Same goes for other OS’s like Fedora etc. (which are all mined in similar way, just change it to /fedora for instance).
            • The page presents itself as if it’s the only choice, and can easily scam someone who’s just getting into Linux into installing snap. I think it’s designed for that purpose. Arch links to the package, but not step by step guide (which is on Arch), but this can easily lure people into installing snap and being none the wiser the it’s not the default package manager for their distro.
            • It’s 4th for Firefox, but I’ve seen it as the top result for some other packages. Probably Google caught up, or probably for packages not mainstream as Firefox it still shows snap as number one result.
    • The big difference is that Snap is partially proprietary. For those who like Linux for its free and open-source nature and all the benefits that confers, this is an unfortunate evolution that has a negative impact on the Linux ecosystem.

    • All the servers I’ve spun up in the past few years have been Debian instead of my usual Ubuntu.

      The last straw was kinda when I learned that installing docker via the install menu gives you the snap version instead of the normal one, with no indication that this is the case.

    • Snaps I get, but Ubuntu? Aside from an asinine application process to get hired a Canonical, they did a lot to push for a more straightforward Linux desktop experience. Their time has passed, but cancer is a bit too much for me, considering all the fantastic offshoots.

      Context: I came to Ubuntu from Gentoo. Debian before that and a brief flirt with the hot fantastic mess that was Mandrake when I first discovered Linux.

      • Snaps is just the latest controversial tech they haved pushed for. They have a long history of pushing for things they have created that people don’t want or don’t want their implementation of (like upstart or the original unity desktop env). Or pushing for stuff before it is ready (like pulseaudio).

        Nothing wrong with pushing for your own tech, but they do seem to miss the mark a lot on what they want to introduce. And keep upsetting the community over it.

        • There is a problem with pushing tech if that tech is proprietary — such as with Snaps.

          Unity I don’t think was ever that controversial, except that Ubuntu was sending all desktop search queries to Amazon at one point, which was, of course, terrible privacy-wise. The reason why Unity died is because Ubuntu decided it’s not worth the money to maintain it.

          • There was a lot of community backlash when they first released unity as its own thing. Lots of people hated it because it was very different from what came before. That is what made it controversial.

  • Yeah, nah, that’s a dealbreaker for me. I’m back to LMDE when this happens.

    I don’t mind having snaps available but I’d avoid using them whenever possible. They’re larger than necessary, slower than necessary, and I trust software checked by its original devs plus distro maintainers more than software checked by the devs alone.

  • I’ve been using more and more flatpaks lately on arch and fedora based distros, i have no idea how snaps compare but seems similar? Seems an odd push from Ubuntu, but could make more sense than deb packages for non techy users perhaps?

          • Because it’s extra work to make it open source and few outside of Canonical are interested in contributing. Open sourcing an existing component and maintaining it as such has non-trivial overhead. In that case that work is better spent on other, higher priority items. My guess is that they’ve gauged that the cloud end being open source won’t move the needle on who uses Snap and Ubuntu so they’ve deemed it low priority. Personally I’m using Debian and Ubuntu and therefore Canonical has root on some of my systems. Given I can implement a cloud end for Snap, it bares very little importance to me that today the cloud end isn’t open source since it’s run by the folks that have root on my system anyways as well as supply all other packages on my Ubuntu systems. In fact we don’t even know what the cloud end for the apt repos is. It could easily be Sonatype Nexus. For me the important bit is the client and installer side of Snap since I can’t implement that in a relatively small amount of time. :)

    • Ubuntu / Canonical were working on Snap for some years when Flatpak came on the scene. They’ve been shipping Ubuntu bits using it since 2016. In addition to the legacy, Snap is more versatile than Flatpak in that it can be used to package pretty much anything, including system bits. It’s also had a secure sandbox from the start. Changing to Flatpak would be a functionality downgrade for Canonical and Ununtu maintainers using Snap. In addition Flatpak can be used along with Snap on Ubuntu so there’s no need to not use both for whoever finds that useful. Snap lets Ubuntu ship software using less work, which means more up-to-date bits in Ubuntu. Users can install other software via Snap or Flatpak, whichever they find more useful.