[HN Gopher] Ubuntu 23.10's New Software App Will Demote Debs (Ap...
___________________________________________________________________
Ubuntu 23.10's New Software App Will Demote Debs (Apparently)
Author : mariuz
Score : 50 points
Date : 2023-07-06 20:21 UTC (2 hours ago)
(HTM) web link (www.omgubuntu.co.uk)
(TXT) w3m dump (www.omgubuntu.co.uk)
| foobarbecue wrote:
| Wait, what? I thought I read recently that they were phasing out
| snap? Did I dream that?
|
| Edit: I'm talking about this https://news.itsfoss.com/ubuntu-
| ditch-snap/
|
| Oh JEEZ it was april fools. It seemed so reasonable. I thought
| they were coming to their senses.
| rohfle wrote:
| april fools? https://news.itsfoss.com/ubuntu-ditch-snap/
| SSLy wrote:
| it was one of those april fools jokes that a lot of people wish
| would be real.
| jjice wrote:
| So why does Ubuntu push Snaps so hard? They've been doing this
| for year and I still have no idea, since pretty much everyone I
| know would rather a deb file (myself included). What's their
| gain?
| WhyNotHugo wrote:
| It's a proprietary package management system (only the client
| part is open source, so it's kinda MSFT-style open source).
|
| The obvious answer is: vendor lock in. Once Ubuntu is snap-only
| you won't be able to host your own package repositories, since
| it's their secret code.
| rlpb wrote:
| The package hosting protocol is relatively trivial. I believe
| a couple of alternative implementations have been written,
| but I'm not sure they're maintained because there's no point.
| Anyone can publish to the Snap Store. Because snaps are
| sandboxed at the client end, there's no gate except automated
| checks.
| jcastro wrote:
| The linux desktop is in the middle of moving to a zero trust
| model: https://www.ypsidanger.com/the-distribution-model-is-
| changin...
| goodpoint wrote:
| zero trust meaning that you cannot trust your desktop anymore
| JohnFen wrote:
| Damn, that was a depressing read. If that's how things are
| going, then it really is past time for me to stop using Linux
| entirely. This is feeling like the final straw in a series of
| things that have been pushing me away.
| jcastro wrote:
| What are your concerns?
| michaelt wrote:
| Snap makes it easier to distribute closed-source software
| like skype - but people running linux on the desktop
| generally have no great love of closed source software.
|
| For open source software, snap is the same software, but
| slower, more broken and with worse upgrades.
|
| Snap's changed the firefox update process so I now have
| to run 'sudo snap refresh' and wait for a download, where
| before I just closed and reopened it. Maybe it'll make my
| running application's dock icon disappear, hope you
| always use alt+tab instead of the dock. Snap can install
| ffmpeg - but I can't feed a screen recording to vaapi for
| compression because whoever set up the sandboxing forgot
| to allow that. Good luck sharing anything from, say,
| ~/.config/ on, say, discord - you get a silent
| unexplained failure, because hidden folder access is
| blocked by the sandbox. Installing a browser? With snap
| you get three copies; you can adjust refresh.retain down
| to only keep 2 copies - but 1 copy is out of the
| question.
|
| There's a reason canonical has to force snap down
| people's throats, and it's because nobody uses it by
| choice.
| abeyer wrote:
| Personally mine are the fact that this isn't really "zero
| trust", but more "infinitely diffuse trust" where every
| user has to trust every application. None of the
| packaging alternatives I'm aware of seem to yet have
| their security story in line where they are either secure
| enough (without breaking most software) to not have to
| trust every application or provide some level of
| assurance themselves comparable to the debian
| maintainers.
| JohnFen wrote:
| Oh, I have quite a few of them, from increased resource
| usage, proprietary aspects, through forced updating and
| more. The forced updating is particularly unacceptable.
|
| But, the 10,000 ft view is that they reduce the amount of
| control I have over my system. They offer restrictions I
| chafe at while giving me no benefit that I care about.
|
| I'm not going to sit here and say they shouldn't exist.
| That they're not to my taste doesn't mean that others who
| like them shouldn't have them. But they're not to my
| taste at all.
|
| After seeing systemd getting widely adopted (also not to
| my taste), if snaps (or flatpacks, although I am less
| allergic to those) join the party then that's just a
| clear indication that the Linux world and I have diverged
| too much and I need to move on.
| fsflover wrote:
| > the Linux world and I have diverged too much and I need
| to move on
|
| I moved to Qubes OS and like it.
| WhyNotHugo wrote:
| Alpine feels a lot like a BSD to me, and I'm very happy
| with it.
|
| But this bloatification is happening all over the place.
| Firefox is starting to have more and more dependency on
| flatpak's daemons, even if you don't use flatpak. These
| daemons are becoming the de facto standard for some
| interfaces too sadly. This also means that a lot of
| software is a lot less portable.
| amelius wrote:
| It's a quite powerful idea to run every package in its
| own container (sandbox).
|
| However, it depends on the implementation and Snap just
| sucks.
|
| (Note that the default Unix assumption is that no users
| can be trusted but all applications can be trusted, which
| is wrong imho. Containers provide a way out of this, but
| things get messy very fast.).
| goodpoint wrote:
| The sandbox is not going to protect users from spyware
| telemetries, bad security for the application itself,
| ads, and so on.
| rlpb wrote:
| > The forced updating is particularly unacceptable.
|
| Snaps allow you to hold updates indefinitely now: no
| forced updates any more. Use "snap refresh --hold <some
| snap name>". See https://snapcraft.io/docs/keeping-snaps-
| up-to-date#heading--....
| srcthr wrote:
| This model destroys any reason for software to be open
| source. What's the point of having source code if you
| just run the binary provided by some party?
|
| Reminds me of the early days of the tensorflow where
| everyone used whatever binary package worked an no one
| could run anyone else's code because people kept getting
| stale binaries somewhere in the stack.
| jcastro wrote:
| The packaging format doesn't change source code
| availability or restrictions.
| goodpoint wrote:
| On a practical level it's completely different.
| BaseballPhysics wrote:
| You say that like the "Linux desktop" is a monolith. What
| leads you to believe this is a widespread movement outside of
| RHEL and Canonical?
| jcastro wrote:
| They're just catching up to Android, ChromeOS, and SteamOS.
| The market rejected traditional needs-a-sysadmin linuxes on
| client a long time ago.
| BaseballPhysics wrote:
| That's not an answer to my question. For example, I see
| no evidence Debian is moving toward app images as the
| standard way to distribute software. Same goes with Arch
| and I'm sure many others.
|
| And btw SteamOS is absolutely not a sandboxed
| environment. It just has a read-only OS filesystem so
| they can safely blow it away upon upgrade.
| jeroenhd wrote:
| Canonical sells access to the snap store. It's part of their
| Ubuntu IoT strategy.
|
| Uploading public applications is free. Uploading proprietary
| software is a business model.
|
| It also pretty much locks Ubuntu users in, because no other
| project uses snaps, so if an app chooses snap for their
| distribution method (certbot, for example) it suddenly becomes
| a lot easier to just download Ubuntu than it is to install Snap
| for a foreign platform.
| rlpb wrote:
| > it suddenly becomes a lot easier to just download Ubuntu
| than it is to install Snap for a foreign platform
|
| That's an exaggeration. It's about as easy to install snap
| support for a non-Ubuntu as it is to install any other third
| party app on that platform. And the latter case is exactly
| what you're trying to achieve by trying to install a third
| party app on that platform in the first place, so by
| definition it can't be significantly harder than any
| alternative method.
| JohnFen wrote:
| My hypothesis is that if everyone used snaps, it would reduce
| the complexity of packaging by reducing or eliminating
| dependencies that need to be installed separately.
| rlpb wrote:
| Debs work really well when they are shipped as part of the
| distribution deb archive itself. They work really badly when
| third parties try to use them to provide add-on software to an
| existing distribution release.
|
| The main problem that Snaps solve is this latter case: when
| third parties are trying to ship directly into a distribution
| release[1].
|
| Often third party debs appear to work OK, but then break future
| distribution upgrades. By then users have forgotten about the
| third party software that has hacked itself into their system,
| and blame the distribution for their upgrade failure. The
| problem is that distribution debs are designed to provide
| metadata about what has changed so that the package manager can
| accommodate. But it's not possible for distribution debs to be
| aware of the third party debs to handle those changes. So
| things break.
|
| The breakages caused by debs aren't just limited to future
| distribution upgrades. A bad third party deb package can break
| your entire system. We routinely get reports where it turns out
| that this is what happened to our users!
|
| There's also the problem of dependencies. If a third party app
| needs a bunch of dependencies, then they can't realistically
| bump those dependencies on the system as a whole without
| regressing all the other apps that need older versions of that
| dependency. So they have to bundle their dependencies, and this
| is something else that regular deb tooling doesn't handle well.
| You can theoretically construct a deb that bundles all its
| dependencies, but then that's exactly what snaps and snap
| tooling handles better - that's half the point. Nix only
| partially solves the problem by better supporting concurrent
| installation of multiple versions of those dependencies. But
| those concurrent versions would still each have to be
| maintained; that's something that distributions try to avoid by
| picking one version of each dependency and making the entire
| distribution release work with just that one. Moving that
| maintenance responsibility to each third party app developer,
| and having the packages bundle their dependencies, is the other
| solution. This was already happening with deb packages like for
| Firefox. Firefox upstream bundles nearly everything, and the
| debs (eg. in Debian) do the same for most of their
| dependencies. Snaps just call a spade a spade and are designed
| around it.
|
| You also wouldn't really expect a third party app to have
| access to everything on your system. Say for example you
| download and install some game app to try out. Do you really
| want it to have access to your online banking browser session?
| The game developer might not secure their development
| infrastructure as if someone's trying to steal their users'
| money, because that's expensive and they're only shipping a
| game. But if you install their game, then that's what you risk.
| That game developer's infrastructure is suddenly an attack
| vector for an adversary that wants to get to your online
| banking session. On iOS and Android, each app only has system-
| mediated access to everything outside its sandbox. Debs
| fundamentally cannot provide this separation, so if you install
| third party debs then you're giving all those third parties
| access to everything, which really is unacceptable in modern
| security practice. Snaps give you that sandboxing.
|
| So that's what snaps are for: 1) bundling dependencies, because
| that's necessary in world of third party software that ships
| independently of the distribution; and 2) sandboxing, because
| that's necessary in a world of third party software if you
| don't want to give all those third parties and their
| adversaries root on your system.
|
| If you _don 't want_ third party apps, and only want what your
| distribution ships in a curated manner, then you don't really
| need snaps. But consider that Firefox is essentially a third
| party, non-curated app, regardless of your distribution! See
| [1] below.
|
| Snaps are also immutable, which really helps with stability and
| upgrade and revert cases. This is more relevant for snap-only
| systems like in IoT, not the Ubuntu desktop. In an IoT
| deployment you can't tell the user to run "apt-get -f install"
| to fix up the system because power got interrupted during an
| upgrade - because that's how debs work.
|
| In years gone by, Ubuntu tried really hard to make third party
| debs work. But it didn't work for various reasons. In the
| meantime, it became the norm for third parties to ship debs
| together with all of their problems, since there was nothing
| better possible at the time. This is what snaps solve.
|
| Disclosure: I work for Canonical. But here I am speaking for
| myself, not my employer. I'm not involved in the design of
| snaps, but as a distribution developer, it's clear to me what
| problems they solve.
|
| [1] Packages like Firefox also use snaps because even as a deb
| it's really not the case that Firefox is curated by the
| distribution and mostly unchanged after release any more. So it
| suffers from mostly all the same problems that third party debs
| do.
| simion314 wrote:
| > since pretty much everyone I know would rather a deb file
| (myself included).
|
| Not me, for programs that are not from the repos I do not like
| debs.
|
| I needed to install dubious apps like Skype,Slack, Some Pdf
| Editor etc. With deb I would give them root , so I either find
| an app image or snap, or try to unpack the deb file and attempt
| to run the binaries without root.
|
| I also installed one a server some CLI snaps, they did their
| job and I did not had to build them from source.
|
| I agree from things that are in the repo I prefer the debs 99%
| of the time.
| awinter-py wrote:
| I have zero horse in this race other than every time I've tried
| snap firefox it has been unpleasant (slower, weird memory, weird
| hangs that sometimes OOM), so I install it in some silly manual
| way
|
| in theory I like that snaps have a permission model w/ default
| confinement, in practice I keep getting asked to install in
| 'classic' mode
| anonymousab wrote:
| I have never understood why the pushed snaps so early and so
| hard as they have. Feature parity isn't always a necessity, but
| you'd think they would have made sure that Snap apps perform at
| least "ok".
| e63f67dd-065b wrote:
| In my mind, Ubuntu Desktop, and desktop linux in general, has
| always been a hobbyist project masquerading as a real production-
| ready environment. There's no money in building a desktop distro,
| so nobody really cares what happens there.
|
| The real power of Ubuntu has really always been as a server
| distro. I used to run desktop Ubuntu when I was younger and had
| more spare time to tinker with this nonsense, but nowadays I
| administer enough ubuntu servers at work, I don't need to do it
| at home too. Ubuntu server is great -- everything is very well-
| documented, LTS is stable, snaps are sometimes pretty useful (I
| recently had to quickly spin up redis temporarily for a project
| and it was a one-liner), and everything just works in general.
|
| I used to run CentOS (rip) servers, and Ubuntu, whilst noticeably
| worse, is still great to administer. It's not all sunshine and
| rainbows for sure, but things generally work the way you expect
| them to and things are generally sane.
| layer8 wrote:
| For server, Debian is the simpler and more stable solution.
| e63f67dd-065b wrote:
| Debian is not really an alternative. There's no maintenance
| guarantee, no support contract, and is usually not validated
| to work with packages the way Ubuntu and RHEL is. These are
| the kinds of things that matter for production.
| lockhouse wrote:
| FreeBSD is a great option on the server as well. Simple,
| stable, mature, and great documentation.
| e63f67dd-065b wrote:
| If I tried to run FreeBSD in prod I might have actually
| been fired. None of the BSDs are production ready:
| basically nothing is validated to work with them, there's
| no commercial support, less available sysadmins, no
| software officially supports it, etc. It's a hobby system,
| nothing more.
| retrocryptid wrote:
| Just another reminder I need to move back to stock Debian or BSD.
| whalesalad wrote:
| Come back to where the air is crisp - Debian 12 is glorious.
| JohnFen wrote:
| Debian remains OK (I use it on all of my machines), but
| worrying signs have been growing there as well.
| bithaze wrote:
| > worrying signs have been growing there as well
|
| Care to elaborate?
| JohnFen wrote:
| My comment was too harsh to Debian. Debian has been good
| to me, and is the best distro I've used.
|
| But their adoption of systemd is something that makes me
| worried for the future. It's still avoidable for now, but
| the writing is on the wall.
| whalesalad wrote:
| systemd is great
| xdennis wrote:
| Or come to Ubuntu without the nonsense: Linux Mint.
| wing-_-nuts wrote:
| or popOS
| stavros wrote:
| Is Pop!OS a viable alternative to Ubuntu? I don't like
| Snaps but I like the fact that all my hardware (even my
| nVidia GPU) is supported. I think rolling release would
| be better, though, even if stuff breaks once in a while.
| jrockway wrote:
| I've used Debian since the early 2000s and keep wondering why
| there are any other distributions of Linux.
| zokula wrote:
| [dead]
| wing-_-nuts wrote:
| Debian fell out of favor because stable is too damned stale
| and ubuntu had a lot of small polish and quality of life
| improvements that debian didn't have at the time.
|
| I used ubuntu for years, but finally gave up on it when
| they started pushing snaps hard. I'm on PopOS now now but
| I'll go to mint debian edition or something else if I have
| to.
| jamesbfb wrote:
| I'm a long time Debian user but I have recently fallen down the
| rabbit hole that is NixOS. I'm still ways away from moving my
| entire dev environment to NixOS, but I definitely see it's
| appeal.
| greenspam wrote:
| Why not nix on Debian? So you have the benefit of both.
| srvmshr wrote:
| Often, great engineering products start out crisp and clean until
| the product manager, sales and marketing guys, growth managers
| and evangelists step in and start adding antipatterns. I am not
| surprised Ubuntu did it. I am surprised they did it so late. They
| were slow-cooking this for the last 5 years. And for anyone
| unwilling to see it: Ubuntu wasn't about building a solid
| engineering product like RHEL, Debian or Slackware. It was always
| cashing on making a fork (i.e Debian unstable) more usable. Their
| core interest is increasing number of installs everywhere, not
| bringing the next engineering marvel. Flatpak serves that cause
| beautifully. They only have to worry about sandbox & containers
| part for software others build.
|
| Ubuntu has tried bold moves - like trying to replace Xorg with
| Mir. That failed because Mir was raw. But this one might just.
| Making deb packages second class citizens in a Debian derived OS
| is so unfortunate.
| synergy20 wrote:
| we have Debian, which i'm going to use and replace all ubuntu
| stuff on the server side.
|
| on the desktop side, I really just need a browser and a vim
| editor for 99% of what I do, Debian should be perfectly fine
| too.
| BaseballPhysics wrote:
| And honestly, for desktops, Debian testing is plenty stable
| IME and stays quite up to date. It's what I've run on my
| laptop for years with absolutely no issues.
| stavros wrote:
| How up to date is it? That might be attractive after years
| of Ubuntu. How is the proprietary driver support?
| BaseballPhysics wrote:
| Pretty darn up to date. Tbh I think it's not unusual for
| it to be more to date than the current Ubuntu stable
| (which I thought started out as a snapshot of Sid).
|
| As for proprietary drivers, the non-free repos have
| traditionally carried everything I need.
| jdub wrote:
| All of Canonical's most hilarious (and sad) mistakes came
| directly from the top. But in fairness, so did the initial
| insight (the gap in the distro market).
| renewiltord wrote:
| I use Ubuntu Server. Should I be moving to Debian? I really like
| Ubuntu (user since Breezy Badger back when Mark Shuttleworth
| shipped CDs to everyone) but the whole snap thing has been a
| pain. They change around on you, don't work well (docker or
| something installed as a snap for me and failed in a strange
| way), and are quite slow (visually apparent load time).
|
| I really don't want to worry about this stuff on Ubuntu Server.
| Has anyone else moved to Debian?
___________________________________________________________________
(page generated 2023-07-06 23:03 UTC)