[HN Gopher] Linux Mint drops Ubuntu Snap packages
___________________________________________________________________
Linux Mint drops Ubuntu Snap packages
Author : jonquark
Score : 668 points
Date : 2020-07-08 17:07 UTC (5 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| red_admiral wrote:
| Snap sounds to me like the latest of many decisions by Canonical
| that are more like what you'd expect from a commercial vendor
| than a FOSS one. This is Microsoft-level coercing people into
| your own ecosystem.
|
| I don't doubt for a moment that it makes business sense for
| Canonical, but I really wonder whether there's a market for this
| - the huge majority of people who don't care about this kind of
| thing are on Windows or Mac, or even just working happily away on
| their phones and tablets.
|
| Linux' selling point for me was always that I was in control and
| could make the system work the way I wanted to; people more
| ideologically pure than me have slogans like "free as in freedom"
| or "binary blobs are bad".
|
| I really don't see the market for "linux, but with commercial
| vendor practices". I switched from ubuntu to mint a while ago and
| I'm really happy about that right now.
| Miraste wrote:
| I'm not sure I see how it even makes business sense. Trying to
| compete with with Apple and Microsoft by eliminating your
| strengths to focus on your weaknesses isn't a good play. Gnome
| and Ubuntu are not and will never be as smooth and integrated
| as MacOS, and that's okay because that's not why people use
| them. Take away the openness and you have a slower, uglier Mac
| with a worse app store.
| renewiltord wrote:
| I like the App Store functionality etc. It's good to have a
| trusted store and all that. It's just that Snap packaged stuff is
| slower to open than stuff otherwise. A user on lobste.rs[0]
| showed what it was like and mine is just as bad
|
| Also by `df` and `mount` are unusable with this stuff.
|
| 0:
| https://lobste.rs/s/aktv9k/problem_ubuntu_20_04_snaps_where_...
| jefft255 wrote:
| I wonder if it is finally time for me to give Arch a try. It's a
| shame that all my lab's machines run Ubuntu; although I find it
| solid, this sort of controlling behavior by Canonical seems
| against the spirit of FOSS.
| DarkCrusader2 wrote:
| If the goal is to acquire and update to latest versions of your
| favorite software, I would definitely recommend you to check
| out nix package manager.
| knowhy wrote:
| You should do that. I did so in 2012 and I have never looked
| back. Besides that ArchLinux just works better the ArchLinux
| community understood that a good documentation is way more
| important than a flashy gui.
| bityard wrote:
| You might like Linux Mint or Pop OS, both of which are re-spins
| of Ubuntu without snaps.
|
| Or for that matter, regular old Debian probably has 99% of what
| you need.
| justaguyhere wrote:
| I'm running ubuntu, maybe it is time to try Pop OS. Hopefully
| system76 doesn't pull shenanigans like Canonical.
| kelnos wrote:
| Adding a vote for regular old Debian. My strategy is to run
| Debian testing, and then 6 months or so after it's promoted
| to stable, switch back to the new testing branch. This way I
| get a reasonably stable experience (Debian's view of
| "testing" is at least as stable as many other distros' view
| of "stable"), avoid the large churn in testing right after a
| new stable series is released, and still get to use all the
| newest stuff.
|
| The only thing to watch for is testing isn't covered by the
| Debian security team, so you need to pay attention to
| security advisories and make a call to keep or uninstall if a
| package you use has a security issue, as testing often
| doesn't get security fixes until a week or so after stable
| does.
| slenk wrote:
| Been using debian for a few years and loved it. Ubuntu
| calling their own website on every shell login is a serious
| problem
| dTal wrote:
| I would recommend anyone considering Arch to skip straight to
| Void. It's "like Arch", but it addresses a number of pain
| points - specifically, its binary repositories are much larger,
| and its package manager won't let you break the system with
| incomplete upgrades like pacman will (on Arch, anything short
| of a complete system upgrade every time you install any package
| is not guaranteed not to lead to breakage, whereas xbps tracks
| shared libraries).
| 1_player wrote:
| I want to try Void Linux one day, but a distro that throws
| away systemd because REASONS is completely anachronistic for
| me.
|
| Say what you want, systemd is here to stay. Everybody's free
| to make a distro without it, but I wouldn't consider it for a
| full time workstation, at all.
| bhhaskin wrote:
| I am honestly thinking the same thing. Still a bit hesitant as
| I mainly use Linux for work.
| 6AA4FD wrote:
| I would try fedora or centos. They have good stability and
| documentation. In my admittedly limited experience centos has
| worked better for me than debian or ubuntu.
| 1_player wrote:
| I have returned to Linux after a few years on macOS, and
| tried Fedora 32: it's interesting, but I did not like:
|
| - The hassle you have to do to install "non-free" software.
|
| - It's basically RHEL unstable: plenty of opinionated,
| bleeding-edge software choices that are either unsupported
| [1] or very much undocumented, unless you can find some
| help on the actual RHEL guides.
|
| - COPR (user packages) is worse than Ubuntu's PPA, both of
| which are much worse than Arch Linux's AUR.
|
| 1: Running Docker on Fedora 32 is non trivial because of
| how firewalld is configured and because Fedora decided to
| go all in on nftables. Sure, it's the future, but Docker
| hasn't got the memo yet. Nor the memo about cgroups2.
| jefft255 wrote:
| Same for me. ROS in particular only supports Ubuntu
| officially; although I know people can run it on Arch, it's
| much more hacky and you have to build every package from
| source.
| knowhy wrote:
| There are packages for ROS in the aur. And there are
| wrappers for the commands needed to install packages from
| AUR. To install ros on my system I just need to execute
| pacaur -S ros-noetic-desktop-full In this case it will
| indeed compile the package with cmake. But there are also
| many binary packages on the aur. The user experience is not
| like Gentoo. I have never had problems finding a package
| with Arch.
| jefft255 wrote:
| I wasn't aware of that, thanks!
| the_af wrote:
| Aren't you changing more than just snaps by changing the
| distro? It seems the philosophy of Arch is different to a
| Debian based linux.
|
| Can't you simply opt out of using snaps and keep using .deb
| with Ubuntu, no matter what Canonical is pushing as their
| preferred distribution?
| lbruder wrote:
| Try Manjaro. It's based on Arch, but with a little more stable
| software, think Debian Testing instead of Sid. Simpler to
| install and works like a charm.
| 1_player wrote:
| Everybody telling you to try something else than Arch.
|
| There's a reason Arch is so famous and a meme: installation is
| a challenging weekend project if you've never done it, but it's
| the most stable distribution with the sanest ecosystem (AUR,
| sane defaults like systemd, fastest package manager, rolling
| releases, packages are kept as close to upstream as possible).
|
| Once you go Arch you probably won't go back and you will just
| grow the meme further.
| Darmody wrote:
| Just today I switched from Ubuntu to Pop_OS (I hate that name).
| Unity was giving me some trouble as it's starting to conflict
| with all the newer stuff so I had to make a decision.
|
| I dislike Gnome Shell. It's clean and fast but the GUI is
| "locked" to the main monitor and I can't even switch windows
| without looking at it.
|
| But I love how the distro is made focusing on a good user
| experience. To give you an example, the shop (software center)
| allows me to choose between deb packages and flatpak if
| available. Sounds like something obvious, but after having snaps
| shovelled down my throat when I was thinking I was installing deb
| packages, this means I can finally trust my distro again.
|
| Now the only thing I need is a good DE. Maybe the next decade.
| dTal wrote:
| https://support.system76.com/articles/desktop-environment/
|
| I don't use Pop!_OS, but I recommend Plasma.
| Darmody wrote:
| I know Plasma, I can't stand the inconsistency and the
| ugliness.
| rootbear wrote:
| I dislike how snap clutters up my df listings. I have to pipe
| them through grep to get rid of the noise: df -h
| | grep -v /snap
|
| An option to ls to suppress all loopback mounts might be a nice
| option.
| Symbiote wrote:
| alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs
| --exclude-type=squashfs'
| mixmastamyk wrote:
| sudo apt autoremove --purge snapd # ;-)
| nullc wrote:
| To call Ubuntu snap a security disaster would be a tremendous
| understatement.
| [deleted]
| ed25519FUUU wrote:
| > _The Linux Mint project has made good on previous threats to
| actively prevent Ubuntu Snap packages from being installed
| through the APT package-management system without the user 's
| consent. This move is the result of "major worries" from Linux
| Mint on Snap's impact with regard to user choice and software
| freedom. Ubuntu's parent company, Canonical, seems open to
| finding a solution to satisfy the popular distribution's concerns
| -- but it too has interests to consider._
|
| An excellent and succinct summary of the issue in the first
| paragraph. I have to hand it to LWN for excellent
| synopsis/summary paragraphs in the articles. This is a lost art
| in today's clickbait headline where the lede is buried in the
| center of the Earth.
| Spivak wrote:
| Canonical's decision to abuse the power of apt packages to make
| it some "universal installer" is kinda gross. I get the thought
| but I would consider is surprising that, say, installing python-*
| actually installed pip and ran pip install.
|
| This is totally going to break Gnome Software's UI since it has
| plugins for snap, flatpack, apt, dnf, pacman, etc.. and making it
| so that Chromium from apt is doing a run-round with snap makes it
| really confusing to the user.
| rlpb wrote:
| > Canonical's decision to abuse the power of apt packages to
| make it some "universal installer" is kinda gross.
|
| This is a mischaracterization. "chromium-browser" is a
| transitional package that installs the chromium snap for one
| reason: it is to provide an upgrade path for users of Chromium
| in previous Ubuntu releases to the latest Ubuntu release
| without breaking Chromium.
|
| I use an example of where Debian does the same thing: on the
| latest Debian release, install "mysql-server" and you'll get
| MariaDB, not MySQL. Granted this doesn't bridge across from a
| deb to a snap, but the mechanism is the same and the technical
| reasoning is the same. It is to stop users from ending up with
| a regression in available software following an upgrade.
|
| There is no "to make it some "universal installer"" going on
| here.
|
| You may not like the decision, but please do not make it out to
| be for reasons that do not exist - at least without providing
| the facts to allow readers to decide for themselves.
|
| (I work for Canonical but don't work in an area related to the
| Chromium snap, Snap Store, this decision, etc. I speak for
| myself, and not Canonical).
| Avamander wrote:
| > it is to provide an upgrade path for users of Chromium in
| previous Ubuntu releases to the latest Ubuntu release without
| breaking Chromium.
|
| Are you seriously, unironically claiming this?
|
| You broke a massive amount of native plugins. The snap auto-
| update mechanism fucks up Chromium's data each time because
| Chromium gets no warning that it suddenly can't write to the
| disk. Its launch time is also way worse. On top of all that,
| Chromium just vomits all over syslog due to incomplete/bad
| confinement. You even made the damn switch when a massive CVE
| was found in Chromium, delaying a __critical __security
| update for a week due to the switch.
|
| What a massive load of bullshit.
| rlpb wrote:
| > Are you seriously, unironically claiming this?
|
| Yes - because when I say "without breaking Chromium", I
| mean that Chromium wouldn't work at all because it wouldn't
| be installed following an upgrade, as opposed to some
| things you don't like about how the Chromium snap works but
| don't apply to the majority of Chromium users.
|
| Edit: you seem to be conflating your disagreement on
| Ubuntu's choice to move to shipping Chromium as a snap with
| a technical detail on how the upgrade path for users was
| achieved. I understand you disagree with the former. The
| claim that this is about "make it some "universal
| installer"" is entirely false, and I'm simply pointing out
| why. Downmodding me for disagreeing with the former is
| doubly inappropriate here.
| Spivak wrote:
| Sorry, I should have been more explicit. I understand that it
| follows the pattern of transitional packages and that this
| was a practical decision to not break people's existing
| setups.
|
| But I don't necessarily agree with the decision because
| "install Chromium via apt" now doesn't make any sense. It
| really should be something like "Ubuntu doesn't package
| Chromium anymore, but a Canonical supported package is
| available in the Snap store." Because Chromium via snap isn't
| a drop-in replacement: it automatically updates, it's not
| versioned with the distro, the usual file paths you would
| expect to exist aren't there anymore.
|
| I use "universal installer" because Canonical has made apt do
| something really unexpected. Canonically has effectively made
| apt a frontend for snaps. I wouldn't expect that if I tried
| to install a package what wasn't in Ubuntu's repos that it
| would try to find some PPA that has that package,
| automatically enable and trust it, and install it from there.
| tssva wrote:
| Canonical solution is to remove the Gnome Software store and
| instead install the Snap Store which although based upon the
| Gnome Software doesn't support plugins for apt, flatpak, etc.
| pkaye wrote:
| Why do they base it on Ubuntu instead of Debian anyway?
| michaelmrose wrote:
| To derive substantial value from software which is packaged
| specifically for Ubuntu but not Debian?
|
| To have relatively up to date software without running
| unstable?
| unixhero wrote:
| They have a Debian base as well. Just incase Ubuntu
| relationship goes sour. It's called LMDE.
| ColanR wrote:
| I've been putting off my next OS reinstallation, but I think I'll
| be moving away from Ubuntu and over to Mint this time.
| graton wrote:
| I've been happily using Fedora for years. Just another option
| to consider.
| rocky1138 wrote:
| Pop!_OS is another choice to consider. Apparently they are
| sticking with Ubuntu but are stripping the Snap stuff before
| pushing any updates.
| bityard wrote:
| Most notably, Pop OS (I'm doing the damn silly punctuation)
| takes all of the stuff that Ubuntu has made snap-only and
| builds them as debs. So it's basically Ubuntu de-snapified.
| gavinray wrote:
| Seconding Pop!_OS, utterly fantastic distro.
|
| Based on Ubuntu but with a bunch of manual patches + tweaks
| and driver support additions (particularly Nvidia). Really
| solid stock UI, and it even comes with a tiling WM built in.
|
| https://github.com/pop-os/shell
| fullstop wrote:
| I've been using Pop!_OS on a System76 laptop since February,
| and like it quite a bit.
|
| I use plasma desktop on all of my other systems, but left
| this one with the defaults.. so far I really like it, but I
| have a problem with gnome-shell leaking memory over time,
| since I tend to not shut down or log out over long periods of
| time. If I don't restart / log out, /usr/bin/gnome-shell eats
| up more and more memory (as the gdm user). I let it get up to
| about 7GB before I updated some firmware and rebooted the
| laptop.
|
| I mean, I put 32GB of RAM in the thing in an attempt to
| future-proof it, but this is kind of bonkers.
| DoofusOfDeath wrote:
| Any reason to use Pop!_OS over Mint, or vice versa?
| DrAwdeOccarim wrote:
| I just switched from MacOS to Mint Xfce on a Razer Blade
| Stealth 13. Really wonderful OS. Donated $50!
| tom_devref wrote:
| You can avoid snaps by using Synaptic Package Manager. I learned
| this the hard way after installing Xubuntu 20.04 and finding
| every piece of software I installed from Ubuntu Software Center
| was either a slow, buggy or completely broken snap image.
| jrockway wrote:
| I've been kind of disappointed by Snap. It seemed like it was a
| way to always have the latest version of software you care about
| available, but in practice, nobody updates their Snaps. I used it
| to get a newer version of Go, and while it is more recent than
| what comes with Ubuntu, it's still not the latest version.
| Apparently Some Guy updates it on a volunteer basis when he
| remembers, so it's nearly useless.
|
| Even if people do update the Snap, it's clear that it provides
| too many features. It has some sort of isolation model... that
| every Snap I've ever installed requires you to disable.
|
| It's also surprisingly expensive to run something in a snap. For
| example, getting the name of my current k8s context with "kubectl
| config current-context": $ sudo execsnoop.bt
| Attaching 2 probes... TIME(ms) PID ARGS 7603
| 29266 kubectl config current-context 7612 29272
| /usr/sbin/apparmor_parser --preprocess 7614 29266
| kubectl config current-context 7626 29280
| /snap/core/9436/usr/lib/snapd/snap-seccomp version-info
| 7630 29266 /snap/core/9436/usr/lib/snapd/snap-confine
| --classic snap.kubectl.kubectl
| /snap/core/9436/usr/lib/snapd/snap-exec kubectl config current-
| context 7632 29266
| /snap/core/9436/usr/lib/snapd/snap-exec kubectl config current-
| context 7634 29266 /snap/kubectl/1561/command-
| kubectl.wrapper config current-context 7635 29266
| /snap/kubectl/1561/kubectl config current-context
|
| This adds 32ms of latency before the app runs for absolutely no
| good reason.
| AnIdiotOnTheNet wrote:
| > Some Guy updates it on a volunteer basis when he remembers
|
| Blame repo culture. In saner worlds there is no requirement for
| a middle man between developer and user, so users get the
| software when the developer releases it to them. For various
| reasons (only a few of which are technical), Linux has settled
| on this middelmen-everywhere way of doing things, and because
| it is FOSS all those middlemen are also _volunteers_ , and then
| to top it all off there are dozens of repos and packaging
| formats.
|
| AppImage (and its predecessors) have been valiantly struggling
| to undo this cultural brain damage.
| anthk wrote:
| >Linux has settled on this middelmen-everywhere way of doing
| things,
|
| BSD ports had it before. And before that, Irix machines had
| the packages split in several CDs.
| michaelmrose wrote:
| It's not brain damage its a reaction to people being capable
| developers but crap at system engineering.
|
| I really don't want 187 system vulnerabilities from 12 apps
| which use different versions of different outdated libraries.
| AnIdiotOnTheNet wrote:
| This is a solvable problem. The vast majority of "shared"
| libraries are used by exactly one application. Commonly
| used libraries like the system interface, cryptography,
| networking, and the widget set, should be provided by the
| base system and their ABIs kept stable.
| fractal618 wrote:
| Some will argue that 32ms is negligible, but I don't believe it
| is.
| PNWChris wrote:
| Agreed, that's 4 round trips to Google from my main box at
| home! You can round-trip ping nearly halfway across the U.S.
| in that kind of time.
| skykooler wrote:
| And that's just for command line programs. GUI programs
| packages as snaps have much greater startup costs. It takes
| the Ubuntu calculator 4-5 seconds to launch. It takes Mumble
| 12 seconds to launch. The latter launches in 2 seconds as a
| native package, and the former, well, is a calculator app - I
| don't have access to a non-snap version of the Ubuntu
| calculator anymore but is should launch virtually instantly.
| eberkund wrote:
| The Go snap looks up to date to me?
|
| https://snapcraft.io/go
| jrockway wrote:
| Sure, but there hasn't been a release recently. It's
| generally inconsistent, so I stopped looking a year ago.
| mixmastamyk wrote:
| It's interesting in that I quite like the idea of snap packages,
| just not their implementation. I recently purged snaps from my
| Ubuntu Mate machines after a few years of use because of the
| realization of only using two:
|
| 1. The micro terminal editor.
|
| 2. Chromium, because it was forced.
|
| Well, #1 was packaged for 20.04 so I didn't need it any longer.
| That left Chromium. For that single package, I had to tolerate my
| system being spammed all over:
|
| - Multiple irrelevant loopbacks cluttering my mounts list
|
| - Dedicated folders in filesystem: /snap ~/snap
|
| - Very slow startup, for chromium.
|
| - Lots of disk space taken
|
| - An always running daemon! (Wasn't it root too? Can't remember).
| apt doesn't need a daemon.
|
| Sheesh! That's not even mentioning the store issues which others
| have described already.
|
| Sorry, but a few newer packages here and there are not worth all
| that. I'll handle it myself, thanks. What snap does isn't
| actually that hard. I'd keep it around if it wasn't so obnoxious
| at putting itself in front and center of everything.
| boring_twenties wrote:
| ~/snap is really just wholly unacceptable, how did that even
| become a thing? Do the people who develop this software never
| use their own systems?
| Avamander wrote:
| I have no nice words about the person who thought that folder
| is acceptable to use. Seriously, what the fuck even?
| mixmastamyk wrote:
| It's definitely irritating but I consider the root daemon
| the primary offender. Kill it with fire!
|
| Oh, forgot to mention: /var/cache/snapd/
| ccmcarey wrote:
| That and their utter refusal to permit controlling the
| updates of snaps. They had an announcement where they noted
| that the community wanted to control their own damn
| machines, and their solution was something like permitting
| delayed updates for up to a week.
|
| What the heck is this, windows?
| catalogia wrote:
| > _Do the people who develop this software never use their
| own systems?_
|
| I've harbored this suspicion of GNOME developers for years.
| It honestly wouldn't surprise me if a lot of Canonical devs
| don't use Ubuntu at home.
| nemetroid wrote:
| I believe it's not even ~/snap, but specifically
| /home/$LOGNAME/snap:
|
| https://bugs.launchpad.net/snappy/+bug/1620771
|
| https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-...
| marvinblum wrote:
| Thanks god.
| psanford wrote:
| From the linked announcement: https://blog.linuxmint.com/?p=3906
|
| > Applications in this store cannot be patched, or pinned. You
| can't audit them, hold them, modify them or even point snap to a
| different store. You've as much empowerment with this as if you
| were using proprietary software, i.e. none. This is in effect
| similar to a commercial proprietary solution, but with two major
| differences: It runs as root, and it installs itself without
| asking you.
|
| This is a great summary of why people rightfully feel nervous
| about Snap. People run linux because they want visibility and
| control into what is happening on their systems. Canonical seems
| to want to take away that visibility and control from their
| users.
| jonquark wrote:
| I can see why Snap is like it is from Canonial's perspective -
| but from the User perspective it seems like FlatPaks[1] are
| much better and address the issues that this article raises
|
| [1] https://flathub.org/home
|
| (Disclaimer: I'm talking in a personal capacity but the company
| I work for in my day job now owns Red Hat - I don't work on
| Linux Operating Systems).
| yellowapple wrote:
| I feel like both Snappy and FlatPak are inferior to AppImage,
| which IMO is much easier to use (it's a self-contained
| executable) and doesn't rely on any fancy management daemons
| or what have you.
|
| Like, in terms of user experience it's about as close to the
| Windows-style "download this .exe and run it" approach as one
| could get, though it'd be interesting to see a macOS-style
| "put this .app in your ~/Applications" approach as well
| (which should be doable with a daemon watching such a folder
| and generating e.g. menu entries and such, as an optional
| component or perhaps a feature of the desktop environment
| itself).
| toyg wrote:
| _> the company I work for in my day job now owns Red Hat_
|
| That's the longest spelling I've ever seen for a three-letter
| company.
| DoofusOfDeath wrote:
| I assume then that you don't speak German?
| lawl wrote:
| > but from the User perspective it seems like FlatPaks[1] are
| much better and address the issues that this article raises
|
| This is interesting, because the last few days I was actually
| working on packaging an application of mine as a
| snap/flatpak.
|
| From my PoV, they both have their fair share of issues.
|
| Snaps enforce a sandbox, which I think is actually a good
| idea, because the desktop security model is somewhat broken.
| If your application cannot run as a sandboxed app, you need
| to be granted special permissions by canonical after manual
| review (my app needs this), where they also discuss if they
| can make a new permission in a safe way for your usecase that
| everyone can use afterwards.
|
| On one hand this sucks because I need to ask canonical for
| permission to publish something, and there's no certainty
| that I will get these permissions as a nobody for a new app
| nobody ever heard of before. On the other hand, I think I
| like that they're doing something about the desktop security
| model.
|
| The next problem is, if this is denied, how do I ship
| updates? Provide a self updater? Easy to write, but if
| everyone does that, we can just go full windows and abandon
| package managers. Tell people to just curl | bash? That's not
| more secure than a potentially shady snap.
|
| But I do have to praise canonical for being very helpful in
| IRC and the forums for helping me debug issues and file bugs
| against snap stuff.
|
| Now flatpak on the other hand, just feels kinda weird to me.
|
| It sandboxes things, but every application can pretty much
| grant itself access to everything. This is a completely
| different philosophy, but if you rely on everyone tightly
| sandboxing their applications without granting themselves
| permissions for sandbox escape, I think something like
| landlock[0] (when it lands) or pledge is _much_ more suited
| for this, and baked into the application.
|
| Then there is this weird thing where flatpaks force a runtime
| on you. My application is a statically linked go binary. But
| flatpaks pretty much want to force me to add an entire
| freedesktop suite as a dependency, as you simply cannot
| choose no runtime.
|
| (Community-)Support for building flatpaks? Pretty much non-
| existant.
|
| So yeah, the entire linux upstream-packaging situation is
| still quite depressing honestly. And with the time and energy
| I have invested into this by now, I could have written a
| simple but sufficient self-updater about 10 times over.
|
| [0]: https://landlock.io/
| 1_player wrote:
| > Then there is this weird thing where flatpaks force a
| runtime on you. My application is a statically linked go
| binary. But flatpaks pretty much want to force me to add an
| entire freedesktop suite as a dependency, as you simply
| cannot choose no runtime.
|
| That's a weird criticism to have of Flatpak. The
| FreeDesktop dependency is the base set of libraries all
| flatpaks have access to. You don't have to use it. In fact
| Freedesktop is a great idea, to provide a base framework
| applications can use that goes further than just libc. If
| we want Linux on the desktop, we need a common desktop
| framework interface.
|
| It would be like being unhappy a static go binary on
| Windows COULD access all of the win32 libraries.
|
| Also, Flatpak currently is best suited to GUI apps. If your
| go binary is a GUI app using either GTK or KDE, these will
| need the freedesktop facilities (such as D-Bus) to actually
| run properly.
| kevincox wrote:
| For sandboxing the user is supposed to decide if they will
| give you access to the permissions that you requested. Now
| in practice most FlatPak apps don't use sandboxing but
| hopefully that will change and permissions are treated with
| scrutiny.
| [deleted]
| inetknght wrote:
| > _The next problem is ... how do I ship updates?_
|
| ...why not make a new release and ship that? That 's the
| way package managers _work_. Developer makes a package.
| User installs the package. Then when developer fixes some
| bug and releases a new version the user can install the new
| version when the user decides it 's necessary.
|
| The whole point about this is that it's user-centric.
| That's good.
| danielheath wrote:
| It's largely a good thing but it's unreasonable not to
| mention the "flood of bug reports about issues that have
| since been fixed" effect that comes with manual updates.
|
| This has burnt a few projects pretty badly (especially
| where distros have packaged an old version and never
| updated it).
| d1plo1d wrote:
| I'm in a similar boat with regards to launching a new,
| unknown product in the snap store. As an interim solution
| I'm planning to ask users to do use the beta flag: `snap
| install my-app --beta` which gets me around the secure
| sandbox requirements.
| m4rtink wrote:
| Flatpaks deduplicate _everything_ - all flatpak apps and
| all flatpak runtimes installed on a machine agains each
| other. So if you specify the basic freedesktop.org runtime,
| it is effectively a no-op as pretty much everyone will have
| it already installed, due to most of the other runtimes
| being based on it and most flatpak apps needing a runtime.
|
| As for sandboxing with Flatpal - AFAIK this is all
| intentional for the time being. The authors have ckearly
| statet their initial effort targets app dependency
| isolation and app portability, not security just now. That
| is much harder to do without severely limitting useful
| applications in what they can do.
|
| I have encountered incomplete sandboxing systems that
| strived for security in past and it has not been a good
| experience.
|
| For example I had the onr and only official Ubuntu Touch
| tablet, which used a predecessor of the Snap technology.
| One day I wanted to show my friends a couple photos from a
| micro SD card. I put it in to the tablet, bit no photo
| viewing app could show photos from the card.
|
| Why ? Because back then you could only open files from
| outside of the apps sandbox one by one using a special
| system controlled dialog. Not really usable for hundreds of
| photos and forget about a text editor or an IDE.
|
| This is where I like Flatpak - it gives you all the goodies
| of app separation and portability without all the hassle of
| a strict but unfinished secure sandbox. You only need to
| make sure you are getting the software from thrusted
| sources.
|
| A I think that's something one should be doiny anyway, even
| with a strct sandbox - if it can't support basic app use
| cases, who knows what security holes have the authors left
| in it...
| still_grokking wrote:
| As a user I don't like neither Snaps (that for sure as this
| is Cannonical only) nor FlatPaks (as they seem conceptually
| a "80% solution" which combines the problems of package
| systems with the problems of self-contianed apps, but don't
| improve on anything).
|
| For me the only acceptable solution besides proper .debs
| are AppImages. AppImage doesn't try to "replace" the
| package management for desktop apps like the former two
| candidates. It tries to complement package systems for some
| special cases (like for example commercial software, or for
| the cases where the user "just wants to try something out"
| without "polluting" the whole system with a lot of
| dependencies).
|
| For my desktop needs AppImage is like "Docker, the good
| parts". A simple self contained format that runs everywhere
| without any further dependencies. Compared to that Snap and
| FlatPak are bloated annoyances.
| baldfat wrote:
| FlatPack was made to address two things focused on
| security:
|
| 1) Application won't need root privileges
|
| 2) Without compromising on the systems security
| cies wrote:
| Some kernels, e.g. Linux, were also made to do just (that
| amoung other things).
|
| I think fixing what we have in standard kernel/userland,
| and leaving the containers for specialized
| developer/devops deployed workloads may well be where
| this (what will be known as the snap/flatpack saga)
| started from, and will end as well.
| saurik wrote:
| Is "I just give you a tgz with small folder of files, one
| of which is a binary; I managed to make it run just about
| everywhere" worse than AppImage (notably, for a GUI app)?
| yellowapple wrote:
| That's basically what an AppImage is, except that an
| AppImage goes one step further and slaps that tarball
| onto an executable that opens its embedded tarball and
| runs whatever's inside.
| lawl wrote:
| I tend to agree with you, but I really like updating all
| my software with one click/command.
|
| So out of curiosity:
|
| My application is already self contained and statically
| linked, so no AppImage needed, but it behaves like one,
| you can just run download and run it everywhere. And so
| what you're describing will be for sure an option for
| those who like it (in fact currently it's the only option
| in alpha).
|
| How would you like to get updates for something like
| this? Visit the website yourself occasionally to check
| for updates? Have the application notify you a new
| version is available? Have an integrated updater so the
| binary can update itself?
| yellowapple wrote:
| > How would you like to get updates for something like
| this? Visit the website yourself occasionally to check
| for updates? Have the application notify you a new
| version is available? Have an integrated updater so the
| binary can update itself?
|
| I've seen all three approaches with AppImage'd software.
|
| There are also package managers specifically for
| AppImage'd software, though it doesn't look like any of
| 'em are particularly mature.
| AnIdiotOnTheNet wrote:
| Personally, I rarely think about updating my software
| unless there's a new feature I need or a fix for a bug
| that's been ruining my life, so just visiting the website
| when to check for new versions is fine by me.
|
| However, you could also include a facility to _manually_
| check for updates and either self-update or just show the
| changelog. Why manually? "I know you're about to do this
| thing real quick that needs to get done, but a new
| version is available! Would you like to twiddle your
| thumbs for 5 minutes while watching a progress bar?".
| ric2b wrote:
| > Why manually? "I know you're about to do this thing
| real quick that needs to get done, but a new version is
| available! Would you like to twiddle your thumbs for 5
| minutes while watching a progress bar?".
|
| That's a very Windows-centric point of view. Programs on
| Linux can be updated without closing them. You get the
| new version when you restart them.
| dflock wrote:
| most AppImages seem to auto-update themselves when you
| run them, which is convenient, until it isn't.
|
| I'd want it in an apt repo, really.
| m4rtink wrote:
| That actually sounds pretty dangerous - what is more
| likely to get compromised and stay that for a long time -
| a random developpers app image update service or distro
| infrastructure ?
| still_grokking wrote:
| That's easy. It should be officially in Debian. ;-)
|
| Stuff like AppImage, static binaries, Docker & Co are for
| me at least a kind of "last resort". Even I'm using
| Docker a lot[1] to try things out I first look for an
| AppImage in those cases. But when I decide that some app
| should become part of my system I will look for a proper
| package. One source to rule them all...
|
| [1] Docker is a _big_ problem on it 's own. But as I
| can't avoid to have it installed because of work I
| decided I could use it at least to "keep experiments
| under control". Before I was forced to have Docker I've
| used systemd-nspawn for that use-case.
| petre wrote:
| Debian has a lot of rules, some of which prevent
| statically linked binaries, like Go programs, from being
| packaged and shipped with it. A notable example is lxd.
|
| Appimages are great but there's no sandboxing or updates.
| But hey, we used to downlad debs and install them by hand
| on Debian 1.3, before apt was a thing. Maybe appimages
| could be signed and distributed in a similar fashion.
| viraptor wrote:
| > prevent statically linked binaries, like Go programs
|
| What do you mean? There's debian go packaging team:
| https://go-team.pages.debian.net/ as well as go packages
| in stable (for example
| https://packages.debian.org/buster/influxdb)
| pantalaimon wrote:
| Where can I find an up to date guide on how to package
| software for Debian and what to do to get it included in
| the repository?
|
| I've often came across orphaned packages where Debian was
| stuck with an old version, but didn't know what to do
| about it other than installing from source. Or using a
| PPA if I was lucky.
| m4rtink wrote:
| Appimage has its own issues though: - no update mechanism
| - no sandboxing and only basic app isolation - no
| deduplication (Flatpak automatically deduplicates
| _everything_ it installs on a machine)
| yellowapple wrote:
| On the sandboxing front, it works great with Firejail:
| https://firejail.wordpress.com/documentation-2/appimage-
| supp...
| AnIdiotOnTheNet wrote:
| AppImages do have an update mechanism:
|
| https://docs.appimage.org/packaging-
| guide/optional/updates.h...
| m4rtink wrote:
| Interesting! That must be something relatively new, as it
| at least looked like there was nothing back then when I
| looked up Appimage.
| robotbikes wrote:
| AppImage seems like the best replacement then. I've
| loathed Snap since it first appeared on my horizon and I
| installed LibreOffice with it and that snap image showed
| up in my mounted drives forever. I was a big fan of
| Canonical/Ubuntu for years and switching to Debian has
| not been without pain points but at least I have more
| control of my computer. Pop! OS and Linux Mint seem like
| good Linux desktop alternatives to Ubuntu at this point
| if you don't want to use Debian.
| riku_iki wrote:
| > Linux Mint seem like good Linux desktop alternatives to
| Ubuntu at this point if you don't want to use Debian.
|
| Mint also has Debian based distro.
| rezonant wrote:
| AppImage is the format I'm using for distributing Linux
| apps as well, for many of the reasons you mention
| red_admiral wrote:
| I wonder how hard it would be, in theory, to write an open-
| source "cracked" version of snap that lets you do these things.
| commoner wrote:
| The Snap server is closed source, so this would require
| building an open source Snap server as well. At this point,
| it would be much simpler to use Flatpak or some other
| solution.
| esclerofilo wrote:
| I hate snap as much as anyone, but it may not be as hard as
| you think: <https://ubuntu.com/blog/howto-host-your-own-
| snap-store>
| commoner wrote:
| The difficult part is maintaining compatibility with
| snapd.
|
| > snapstore was a minimalist example of a "store" for
| snaps, but is not compatible with the current snapd
| implementation. As a result I have removed the contents
| here to avoid further confusion.
|
| https://github.com/noise/snapstore/
| jhasse wrote:
| Why not simply use Flatpak instead?
| heavyset_go wrote:
| My favorite anecdote about Snap is the development team's
| opinion when it comes to users wishing to relocate their ~/snap
| directory elsewhere.
|
| It's a commonly requested feature and being able to move it
| would follow the Freedesktop.org spec, but the developers don't
| care.
| etskinner wrote:
| What's stopping someone from doing:
|
| $ ln -s /somewhere-else ~/snap
| jhasse wrote:
| ~/snap would still exist then
| hannasanarion wrote:
| The problem isn't that the folder exists, the problem is
| that software is being installed in a non-hidden folder in
| the home directory. That's supposed to be a space for user
| files, not system software.
|
| If anything has to be installed in the home folder for some
| reason, it is supposed to go into .local, so the user
| doesn't see it among their documents and photos.
| msclrhd wrote:
| I've allocated a 5GiB partition to /home on my SSD, as it
| does not need to be bigger. I don't want it filling up
| with software or other things like ivy/maven caches.
| sascha_sl wrote:
| bind mounts
| Quekid5 wrote:
| You absolutely nailed it and this is why -- if I have any say
| in this (and I do) -- we will be moving away from Ubuntu.
|
| It's a completely insane stance for server systems. (I believe
| it's still possible to run server systems without snaps with
| various "workarounds" etc, but we can feel which way the wind
| is blowing...)
| curt15 wrote:
| >You can't audit them, hold them, modify them or even point
| snap to a different store.
|
| In particular, it's easy to inspect the sources for apt
| packages using "apt-get source". Snap seems to have no
| equivalent command.
| xav0989 wrote:
| That is, as long as the package publisher distributes the
| source. While it's the case for the some standard
| repositories, packages in "restricted" (some of "multiverse"
| too) and third-party apt repository can be published in
| binary-only mode. You have no ability to at the source in
| those circumstances, even if you apt-installed them.
| IshKebab wrote:
| Sure because Snap is designed to be able to distribute closed
| source applications. Part of the reason Snap and Flatpak
| exist is that distributing binaries on Linux is an enormous
| pain.
| wtetzner wrote:
| So allow viewing sources for the open source packages. If
| sources aren't available, then the user can easily opt not
| to install the binary.
| blablabla123 wrote:
| Still it's an improvement over the current situation.
| Using snap IMHO only makes sense with closed-source or
| Open-source software that you don't want to self-compile
| but at the same time there is only a package available
| for a different distribution. So a typical installation
| procedure might be to forcibly install it with dpkg while
| ignoring the dependencies which cannot be resolved
| automatically. (Or worse, convert rpm to deb and then
| install it...) Of course the source is still
| downloadable, on the other hand, reproducible builds are
| anyway far from standard. I would prefer snap any time
| over other more crude installation methods if compiling
| is not viable.
| NicolaiS wrote:
| > distributing binaries on Linux is an enormous pain.
|
| It doesn't have to. Packaging using FPM [0] allows many
| targets (deb, rpm, etc) and using ELF2deb [1] (shameless
| plug) allows packaging any files to a .deb with no effort.
|
| [0] https://github.com/jordansissel/fpm
|
| [1] https://github.com/NicolaiSoeborg/ELF2deb
| glennpratt wrote:
| You are not required to publish source packages, most of the
| third party repos I use either don't have them or they are
| surprisingly useless because I don't have the build
| environment they were executed in.
| CogitoCogito wrote:
| I'm not sure how this is relevant. You're not required to
| publish source debian package either, yet there is still a
| nice command to use in case the source package exists.
| paulcarroty wrote:
| > Applications in this store cannot be patched, or pinned. You
| can't audit them, hold them, modify them or even point snap to
| a different store. You've as much empowerment with this as if
| you were using proprietary software, i.e. none. This is in
| effect similar to a commercial proprietary solution, but with
| two major differences: It runs as root, and it installs itself
| without asking you.
|
| Short version: Canonical does classic _vendor lock-in_ with his
| Snap Store. I 'm pretty sure 99.9% HN users knows what it means
| :)
| danudey wrote:
| From an IT perspective:
|
| I can set up an internal APT mirror for my users, servers, test
| systems, etc., but I can't set up an internal snap mirror as
| far as I can tell. This means that despite having an internal
| repo that I can whitelist, some package installations will now
| arbitrarily require internet access. I can no longer install
| chromium on a system without access to the internet, and
| package installation will fail as a result.
|
| I'd rather have an older version than a snap version,
| personally, but better would be two packages which Provides:
| the same chromium-browser, chromium and chromium-snap.
|
| The most irritating thing here is that they're using a package
| distribution system which handles dependencies and updates
| flawlessly, and has for decades, and using it to install things
| using a package system which does not solve those problems, and
| instead ships multiple copies of multiple libraries and
| applications, which run slower, ignoring any settings I have in
| APT.
|
| So far, it's a maintenance nightmare, and I loathe it.
| tankenmate wrote:
| You might want to look at ungoogled-chromium,[0] there are
| downloads for most non Windows platforms. Also packages are
| available in repos for apt/deb, yum/rpm, etc.
|
| [0] https://github.com/Eloston/ungoogled-chromium
| loopz wrote:
| Snap can't seem to access my mounts. They're not very special
| mounts, but it happens in linux that you mount something, but
| snap just won't access. That made "no-go" a no-brainer.
| rlpb wrote:
| > Applications in this store cannot be patched, or pinned. You
| can't audit them, hold them, modify them...
|
| I think it should be noted that this generally applies to the
| addition of "third party apt repositories" in general, use of
| which is the problem that snaps fix[1]
|
| _Some_ snaps are built from Free Software and reproducible
| sources, as are _some_ third party apt repositories.
|
| In other words, if this criticism bothers you, then you should
| never install from any third party apt repositories ever. If
| some are acceptable to you, then so should some snaps.
|
| If you don't want to use third party software ever, then you
| can still use Ubuntu without snaps.
|
| [1] Third party apt repositories often break users' systems.
| pdonis wrote:
| _> if this criticism bothers you, then you should never
| install from any third party apt repositories ever._
|
| This does not follow at all. Third-party apt repositories
| work just like Ubuntu's apt repositories; you have just as
| much ability to audit, hold, pin, etc. in both cases.
|
| If there is a difference in reliability (software from third-
| party repos is more likely to break your system--and, btw,
| software from Canonical's repos has also broken systems in
| the past, so "avoid third party repos" is not a guaranteed
| way to avoid software breaking your system), using snaps to
| install third-party software instead of third-party repos
| does not fix that problem: the third-party provider is still
| just as unreliable as before and their software is just as
| likely to do something stupid.
| rlpb wrote:
| > audit, hold, pin
|
| Originally you said audit, hold, modify.
|
| You can audit snaps just as you can audit third party apt
| repositories. Either the publisher ships the source such
| that you can rebuild, or they don't.
|
| You can hold snaps using this method:
| https://forum.snapcraft.io/t/disabling-automatic-refresh-
| for...
|
| You can modify snaps just as you can modify what you get
| from a third party apt repository. Either the publisher
| ships the source such that you can modify and rebuild, or
| they don't.
| giovannibajo1 wrote:
| Third-party apt repositories are a security nightmare: you
| are giving a third party unrestricted semi-silent root
| access to your computer. I can trust my distro provider
| with this, but it should be strongly discouraged for third-
| parties. Instead, installing PPAs to get updated builds of
| standard packages seems considered "normal". At least, this
| doesn't hold true for snaps.
| pdonis wrote:
| _> I can trust my distro provider with this, but it
| should be strongly discouraged for third-parties._
|
| Again, it all depends on how much you trust the third
| party compared to how much you trust your distro
| provider. I don't have many third party PPAs installed on
| my computer because there aren't many third parties I
| trust that much. But there aren't zero either.
|
| Also, a big part of my trust of my distro provider is
| based on having source code forced to be open, and
| another big part is based on them not doing things behind
| my back. Snaps significantly erode both of these aspects
| of trust.
| ncr100 wrote:
| Is there no way to sandbox these packages - "have you cake and
| eat it too?" I'm a noob to modern Linux.
|
| Edit: Are snaps images? ...like containers?
|
| Edit 2: answer:
|
| > mounted dynamically by the host operating system, together
| with declarative metadata that is interpreted by the snap
| system to set up an appropriately shaped secure sandbox or
| container for that application
| solarkraft wrote:
| The main (and better supported) competitor is Flatpak, which
| at least doesn't have the terrible marketing.
| ncr100 wrote:
| Thank you - :)
|
| Reading about the cons of Snap now - "auto-updates cannot
| be turned off" -
| https://en.wikipedia.org/wiki/Snap_(package_manager)
| _jal wrote:
| Yep. One of many reasons they're banned in our shop.
|
| Even for client software it is bad - an app quitting out
| from under me because it wants to update is functionally
| equivalent to a crashing bug - but they're offering
| daemons this way, which is just insane.
|
| Who doesn't want all their containers randomly restarting
| because someone up the distro chain decided when your
| machine needed to upgrade?
|
| https://snapcraft.io/lxd
| tomponline wrote:
| The containers do not restart when the snap package is
| updated.
| tssva wrote:
| If snap decides to update lxd on the nodes of your lxd
| cluster at the same time that a node has failed it is a
| CF.
|
| The cluster will not come up because your down node is
| now not the same version as the other cluster nodes.
| xet7 wrote:
| Auto-updates of all Snap packages can be turned off at
| /etc/hosts by adding a line:
|
| 127.0.0.1 api.snapcraft.io
| nawgszy wrote:
| Just what we all want on our production hosts.
| entropicdrifter wrote:
| Especially when they're being installed covertly through
| APT
| superkuh wrote:
| All containerization is just the fever to the sickness that
| is the futureshock from extremely fast rate of development
| of major libs like c++$year, glibc (no matter what they say
| about having stable endpoints), and the like. You can't run
| a program written today on the system repo libraries from 5
| years ago.
|
| Containers try to mitigate this problem but like a fever
| they often end up making things worse.
| zentiggr wrote:
| I don't run any APT based distribution right now but I
| understand the issues... I think the biggest problem I
| see is Canonical developing what looks like a very useful
| tool but holding it proprietary.
|
| If Canonical provided the snap creation and hosting tools
| to the community I imagine it would be judged on its
| technical merits.
|
| As it is, I see more and more reports that Canonical is
| trying to gain more and more control and that's exactly
| what I don't like to see.
|
| Would have tried Ubuntu but they've poisoned that well.
| I'll have to recalculate.
| xav0989 wrote:
| As far as I can tell, snapcraft[0], the tool that allows
| the creation of snaps is open-source and on github.
| However the hosting server-side code is closed source.
|
| [0]: https://github.com/snapcore/snapcraft
| drewg123 wrote:
| Wouldn't it just be simpler to statically link apps then?
| AnIdiotOnTheNet wrote:
| Depending on the qualities your after, AppImage is also
| really great. Advantages over Flatpak are that they are
| completely portable (you can store them anywhere and run
| them from anywhere), and they don't require a special
| runtime or package management infrastructure of any kind.
| entropicdrifter wrote:
| If you need this kind of packaging but want to retain
| freedom, just use an alternative solution like flatpak, which
| sandboxes from the get-go and lets you control what parts of
| your system the application can access
| DoofusOfDeath wrote:
| > just use an alternative solution like flatpak
|
| Saying " _just_ use an alternative " seems overly
| dismissive of the complications that entails.
|
| IIUC, the only options for that are (a) abandon Ubuntu, or
| (b) actively circumvent Ubuntu's software distribution
| infrastructure, reminiscent of dealing with Windows 10
| forced updates.
|
| IMHO this somewhat erodes Ubuntu's value proposition.
| zentiggr wrote:
| I have a laptop that I'm planning on rebuilding from a
| failed NTFS/Win10 system to Linux something.
|
| Now I know it's not going to be Ubuntu or anything else
| derived from Canonical.
| Endeavourist wrote:
| Why not EndeavourOS? It's based on Arch Linux, with
| minimal numbers of external packages; quite unlike
| Manjaro actually. You can just treat it as a standard
| Arch install, and even use the ISO to boot with wi-fi
| drivers and all and install Arch plainly, without the
| non-wifi and other regrets. EndeavourOS is pretty great;
| I personally use it as a live-ISO (XFCE environment) and
| just install Arch from within the live EndeavourOS booted
| iso. Just throwing it out there.
| zentiggr wrote:
| Hadn't heard the name but glad I did. I was going to look
| for a live CD distro with good NTFS read support for the
| old drive recovery. This sounds good.
| DoofusOfDeath wrote:
| > Now I know it's not going to be Ubuntu or anything else
| derived from Canonical.
|
| Why avoid Ubuntu derivates like Mint or Pop!_OS, though?
|
| They're doing the heavy lifting of fighting Canonical on
| this issue. Maybe using one of those distros instead of
| vanilla Ubuntu actually _strengthens_ the pressure that
| Canonical feels on this topic.
| zentiggr wrote:
| Fair point, but honestly I'm in the "don't have enough
| time to Gentoo this build" category.
|
| If I know I can avoid Snap crap by changing distros for
| now, that's what I have a timeslice for.
| xet7 wrote:
| AFAIK Ubuntu does not force reboot like Windows 10.
| entropicdrifter wrote:
| I agree that this erodes Ubuntu's value proposition. I
| run Manjaro with KDE, personally.
| ncr100 wrote:
| Neat - "permissions that are defined by the maintainer of
| the Flatpak and can be controlled (added or removed) by
| users on their system" -
| https://en.wikipedia.org/wiki/Flatpak
|
| I'm wondering now if Wikipedia would be appropriate to host
| a linux sandboxed app packaging comparison chart in the
| form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/
| - and it would be extensible ...since Wikipedia.
| michaelmrose wrote:
| Sandboxing addresses AN issue but does not address any of the
| issues discussed in this article.
|
| Also sandboxing and running apps under reduced permissions
| makes a lot of sense but should be seen as a tool to increase
| security not an answer outright as poorly used any tool can
| be less effective or even harmful.
|
| Historically locking down increasingly effectively often
| leads to impeding things the user actually wants to do which
| leads to apps asking for and granting permissions with the
| net effect of training users click yes to enable whatever the
| app wants to do.
|
| It ends up being not just a technical challenge but a
| psychological one as well and its less easily resolved once
| you start having to deal with real users.
| ex_amazon_sde wrote:
| You can easily create very strong sandboxes for daemons using
| unit files and packaging them as native OS packages.
| blablabla123 wrote:
| It seems to incorporate some novel ideas despite its obvious
| shortcomings.
|
| I also think that so far Linux distributions have done very
| poorly when it came to cross-distribution/forward/backward
| compatibility of packages. This is a non-issue for popular
| Opensource packages since they can be easily packaged by the
| distributors. But not so popular packages sometimes need to
| be installed in a hacky way when they are not available for
| the target distribution. Even worse when dealing with
| commercial software, it can happen that it degrades with each
| distribution update.
|
| Also I think that probably the package format will improve
| over time and add additional features, that would allow
| auditing for instance. Also with proper de-duplication
| (perhaps even on filesystem level) it should be possible to
| also deal with waste of space.
| arexxbifs wrote:
| "Linux on the desktop" is apparently a lot like having sex in a
| greenhouse: fucking close to Windows.
| craftinator wrote:
| All that, and it takes Ubuntu's default calculator program 4
| full wall clock seconds to open on my laptop. Nothing grows in
| this desert.
| simion314 wrote:
| But Mint are too lazy to build their own packages so they use
| Ubuntu binaries that are installed as root, this is IMO a PR
| move and a hypocrisy, if you don't trust Canonical don't use
| Mint use Debian or some distribution that has the capacity to
| host and build their binaries.
| Daishiman wrote:
| As long as you can audit the source and build chain what's
| the problem?
| simion314 wrote:
| >As long as you can audit the source and build chain what's
| the problem?
|
| As long as Linux Mint developers are not doing that how it
| helps you? you don't trust Canonical binaries but you trust
| the deb binaries, you could be honest and claim that you
| don't like snap but you still trust the deb binaries.
| Daishiman wrote:
| The point isn't that the devs are the ones doing the
| auditing, even though pretty much everything that lives
| in DEB and RPM repos has maintainers which do.
|
| The point is that _you_ can audit without having to
| depend on a third party. Nobody 's claiming audits are
| free or that they're assumed. The point is that you have
| the option to choose to trust as much or as little of the
| build chain, from the compiler to the target code to the
| artifacts.
| simion314 wrote:
| let me clear some things up and tell me if I am wrong,
| link me to the correction and I will apologize.
|
| - Mint uses Ubuntu repositories
|
| - Canonical pushes the changes they want into this repos,
| this changes are probably done by scripts that build
| source code on Canonical servers.
|
| - the Ubuntu repos also contain binary blobs
|
| - when a Mint user does an update he gets the binary
| directly from Canonical servers, there is no Mint dev or
| Mint script that does any check to see if for example the
| evil Canonical modified the NVIDIA driver and added even
| more evil in it then already is
|
| Now explain to me if all the above is true why would
| someone that does not trust Canonical would use Mint?
| There is no safety checks to prevent evil Canonical
| people do evil things.
|
| My conclusion is if you don't trust Canonical don't use
| Mint. Maybe Mint is working on addressing this and soon
| we will see an PR campaign that announces they are
| finally able to self host but until then I would stop the
| hypocrisy about not trusting Canonical. (Btw there are
| many smaller distros that can host their own repos, not
| sure why Mint is not doing it)
| Daishiman wrote:
| The differences are the following:
|
| * Nonfree software is generally demarcated as such. There
| is nonfree software that has available source (in the
| case of some codecs), other that comes as blobs.
|
| * The Chromium package is open source, and in most
| distros comes as binary built from the toolchain set up
| by the package maintainers. In all free software distros
| if you don't want to download the binary, you can
| download the source and build locally with the provided
| build scripts (in the case of most APT packages in
| Debian/ubuntu).
|
| * Serving Chromium binaries with Snap removes the option
| of downloading, inspecting, and running the build chain
| locally
|
| * Serving a different version of Chromium, or replacing
| the stock version with a different variety, cannot be
| done without creating a new Snap repository. Downstream
| distros like Mint need to replace some of the stock
| Ubuntu stuff, just like Ubuntu changes stock Debian
| packages
|
| * Because there is no open source Snap repository
| software, Mint is unable to set up an alternative repo
| that could work around some of the objections they have
| with Ubuntu.
| simion314 wrote:
| You are making my point, the "trust" is not the issue ,
| the issue is "control". Canonical has the control on the
| snap store and Mint can insert their customization on
| top.
|
| Again, if Canonical is evil and can't be trusted why I
| would run Mint? Do the developers run any scripts to
| alert me if Canonical slips some bad thing in a binary?
|
| I think is fine if they remove snaps but IMO is stupid to
| accuse Canonical to be evil and not trustworthy while you
| blindly trust their repos.
| 8bitsrule wrote:
| >when a Mint user does an update he gets the binary
| directly from Canonical servers
|
| When I update Mint binaries, I get them from one of about
| 30 mirrors which Mint enables me to choose. (Or it will
| decide for me based on speed.) Do the mirrors at
| Clarkson, Harvard, Purdue, UW, etc belong to Canonical? I
| think not. Nor does most of the code the binaries are
| built from.
|
| Canonical has made its choice, Clem's made his.
| whalesalad wrote:
| One of the first things I do on any Ubuntu-based box is remove
| snap completely.
| aphexairlines wrote:
| This seems like a problem:
|
| > Snap packages are effectively black-boxes; they cannot be
| reproduced independently as the packaging data is controlled by
| the package maker alone.
|
| One of the nice properties of debian packages is the ability to
| `apt-get source` and build it locally. Would be a shame to lose
| that.
|
| Maybe Nix and Guix can provide the best of both worlds here:
| self-contained software but reproducible builds too.
| einpoklum wrote:
| > Would be a shame to lose that.
|
| So don't lose that. Use Debian (or Devuan), or one of its
| properly-FOSS derivative distributions.
| Dormeno wrote:
| > One of the nice properties of debian packages is the ability
| to `apt-get source` and build it locally.
|
| You don't get that for a lot of third party apt repos actually,
| no deb-src repo.
| superkuh wrote:
| Any distro where you have to write a little haskell-ish 30 line
| script to set up an environment just to be able to start
| compiling (or even running!) things is not going to be widely
| popular for desktop use.
| andrewla wrote:
| It's definitely going to take some work. I have set up my
| first NixOS install, and the functionality is very
| impressive, but usability-wise it is a mess.
|
| I think Nix/Guix is going to be the bridge to the post-POSIX
| world where we can move away from the trend of a globally
| visible filesystem and into much stronger container-based
| approach. But it can't be in its current form; the Nix
| language and Guix's Guile/Scheme are too difficult and not
| declarative enough.
| nicoty wrote:
| Theres https://github.com/andrewchambers/hermes which uses
| Janet instead. Not sure if that's closure to what you're
| looking for.
| 6AA4FD wrote:
| `nix-shell -p ghc` does it for me.
| ghostwriter wrote:
| For desktop use, any shortcut icon on a desktop would just be
| a wrapper script for `nix-shell -p <package> --run <package-
| binary>`
| superkuh wrote:
| I was thinking more things you find on the internet and
| then do a bit of ./autogen or mkdir build;cd build;cmake
| ../;make; and the like. Without a file system you really do
| have to write that script and manually pull in the relevant
| libraries, and you have to figure out what those are. No
| autotools will be capable of doing it automatically because
| no global filesystem exists.
| abathur wrote:
| Nix throws sparks, but I'm still cautious about who I
| recommend it to and how.
|
| I understand why there's consternation about usability (and a
| steady stream of requests focused on helping novices get it
| up and running), but I'm not sure the project(s)/ecosystem
| are ready for the stress of getting strapped to a growth
| rocket that brings in many new non-developer general-
| computing users who can't reasonably contribute back.
|
| I don't mean this in an elitist RTFM way. More users of any
| stripe just inevitably exert support pressure in all sorts of
| directions. The community is perpetually iterating on
| tools/automation/process issues to try and stay on the right
| side of the wave. I sympathize with everyone who has a tough
| time finding their legs, but for the near term I think it is
| probably a net good if ergonomics issues filter out people
| for whom most distros are effectively fungible.
| Shared404 wrote:
| Indeed. I am however curious to see if there will be a Nix
| made easy type distro, similar to Ubuntu's relation to
| Debian.
| rlpb wrote:
| This doesn't have to be true. It's perfectly possible to
| produce a reproducible-build snap, and many Free Software snaps
| _are_ reproducible from source. It 's established convention to
| do it this way.
|
| The capability is necessary because snaps can also ship
| proprietary software (eg. Spotify, Skype, etc). So one wouldn't
| expect this to be a property of (binary) snaps, just as it
| isn't for binary debs. apt/deb comes with "source package
| building tooling" (dpkg-source, dpkg-buildpackage, policy
| around debian/rules, etc) and so do snaps (snapcraft).
| osd5 wrote:
| Installed ubuntu 18.04, purged snapd. It was back after `do-
| release-upgrade` to 20.04
| the_af wrote:
| I installed 18.04 a couple of weeks ago, after software I
| needed didn't work for 16.04. I don't need snaps and want to
| continue using .debs (which so far I'm doing, but some snap
| apps come preinstaled).
|
| What is the cleanest way of ditch the snap system and its
| preinstalled apps? I'm assuming this won't break anything
| important.
|
| PS: I'm not planning on installing 20.04 any time soon. At
| least not until the dust really settles. I don't see the point
| of running the absolutely latest version until there is a
| strong, evidence-backed consensus on its strong and weak
| points.
| lioeters wrote:
| sudo rm -rf /var/cache/snapd/
|
| sudo apt autoremove --purge snapd gnome-software-plugin-snap
|
| rm -fr ~/snap
|
| From: https://askubuntu.com/questions/1035915/how-to-remove-
| snap-s...
|
| ---
|
| ..Or..
|
| sudo apt purge snapd
|
| rm -vrf ~/snap
|
| # following may not be required as apt purge already removes
| them
|
| sudo rm -vrf /snap /var/snap /var/lib/snapd /var/cache/snapd
| /usr/lib/snapd
|
| # trying to install some package like chromium-browser will
| bring back snapd
|
| # make sure snapd is not installed as a dependency anymore
|
| # downside is that some package installation might fail
| because of dependecy on snapd
|
| sudo apt-mark hold snapd
|
| From: https://www.kevin-custer.com/blog/disabling-snaps-in-
| ubuntu-...
| DoofusOfDeath wrote:
| I think it's reasonable that the installer for a new LTS
| release would go with the default package-management scheme.
|
| Especially if the people authoring the do-release-upgrade
| scripts weren't aware of this being a hot-button issue.
| andrewshadura wrote:
| You need to write a bit of config to prevent it from being
| installed. See the apt_preferences manpage.
| emerongi wrote:
| Snaps are super laggy. GNOME calculator on Ubuntu runs in a snap
| and it is baffling that whoever made the decision to package it
| in a snap by default was OK with the fact that it takes 2 seconds
| to launch a basic calculator on a 2017 laptop (edit: re-tested,
| it took 5 seconds).
|
| To top it off, a couple months ago my calculator disappeared. For
| some reason I have been having problems with snap applications
| disappearing for a while now, even though I have made no
| configuration changes. How fun it is to discover that such a
| basic tool just no longer exists on your machine, way to fuck up
| a morning.
|
| I get that snaps make application distribution easier, but please
| don't do it at the expense of the user. I've had more success
| with Flatpak and AppImages, but not enough experience with any of
| them to judge which is best.
| CSDude wrote:
| I think it's because they extract compressed rootfs tar each
| time to be mounted in LXC container. Even with a beefy
| computer, it takes considerable time.
| emerongi wrote:
| What is weird to me is that apparently there has not been
| someone in a position of power in this project that would go
| "Wait guys, this is not good. Any other ideas? How can we
| improve?"
|
| No, just roll on with it.
|
| There was a period of time, around 2010-2015 when I really
| felt that computers were fast. SSDs were getting more
| affordable and that was a huge improvement, every action was
| immediately responsive. In 2020, that has somehow been
| undone. It takes 5 seconds to launch a calculator. Software
| guys really like to undo all the advances that the hardware
| guys are doing.
| Andrew_nenakhov wrote:
| In that period, computers made a significant leap forward,
| and it took developers some time to catch up and fully
| utilize surplus performance.
| clktmr wrote:
| This is exactly my experience. On top of that snap creates
| visible directories in $HOME, f-up my loop devices and snap
| applications can't even access /tmp. Never had any problems
| with flatpak and appimage. I will however use it solely for
| proprietary software.
| aritmo wrote:
| I think gnome-calculator was just an experiment for Ubuntu
| 18.04 to test snap packages. In 20.04 it has been switched
| back.
| trashburger wrote:
| It's very funny that this article is two places above the article
| about how Canonical is bringing Flutter to Linux via the Snap
| Store. Some choice quotes from that article:
|
| > Flutter's native cross-platform story is growing rapidly and
| Canonical wanted to be at the vanguard.
|
| > By making Linux a first class Flutter platform, Canonical is
| inviting application developers to publish their apps to millions
| of Linux users and broaden the availability of high quality
| applications available to them.
|
| > Canonical will continue to collaborate with Google to further
| improve Linux support and maintain feature parity with the other
| supported platforms.
| [deleted]
| mastrsushi wrote:
| Can someone explain the need for Linux Mint? It's derived from
| Ubuntu which is derived from Debian which just sounds ridiculous.
|
| Is Ubuntu considered difficult to install? Does it not support
| older hardware as well as Mint? Wouldn't Ubuntu be more supported
| if they just ended Mint and jumped aboard?
| indymike wrote:
| Originally, it was user interface.
| kd913 wrote:
| The reason for why the backend for the snap store hasn't been
| opensourced has been explained multiple times. Namely that it
| would be expensive to open source it with little benefit in
| return.
|
| Canonical already spent a large amount of investment opensourcing
| launchpad and nobody other than them operate it. Mainly because
| the majority of the costs are for operating an instance which
| most other distros aren't willing to spend. Not even Mint operate
| run or operate their own launchpad infrastructure. They
| experienced large backlash back then, open sourced it and nobody
| contributed.
|
| The same problem applies here. Snap store specifically from what
| I gather is a bunch of operational machinery that doesn't make
| sense without also operating launchpad. Such a cost operating
| would benefit nobody but Canonical because nobody else is
| bothering footing the bill to run an instance.
|
| Second aspect that they wanted to avoid was the same pitfalls
| that they experienced previously with ppas and now being
| experienced with flatpak. Namely they want one location to find
| software, and one location to serve software. If users have to
| use the command line to add a external repo that has unfetted
| access, then that defeats any usability gains. That and the whole
| aspects of malware/trust goes out the window.
|
| I will remind people that the most popular PPA to this day is a
| Java PPA being run by some 3rd party that doesn't offer Java.
| That PPA has root access to thousands of machines.
| blendergeek wrote:
| > Namely that it would be expensive to open source it with
| little benefit in return.
|
| Would you describe exactly what will be expensive in releasing
| the source code to software that was developed in house? Does
| it have lots of dependencies on proprietary software? If so,
| why?
|
| > Namely they want one location to find software, and one
| location to serve software.
|
| And this, is the killer. This is exactly what the people at
| Linux Mint do _not_ want. This is why F-Droid exists on
| Android. Yes, free software can be distributed on the snap
| store or on Google Play, but ultimately these are proprietary
| platforms controlled by one corporate entity whose interests
| may not be aligned with those of the community. Users of
| community Linux distros demand choice in where they obtain
| software.
|
| > That and the whole aspects of malware/trust goes out the
| window.
|
| Malware has already been successfully pushed to the Snap Store.
| The idea of "trust" here is also antithetical to open-source
| and software freedom. Rather than trusting software because it
| has verifiable source code, we now trust software because it
| came from a store that removes well known malware.
| tyree731 wrote:
| > Would you describe exactly what will be expensive in
| releasing the source code to software that was developed in
| house? Does it have lots of dependencies on proprietary
| software? If so, why?
|
| If all you're doing is taking an internal repository and
| hosting it externally, then it takes no time. But if you make
| sure licenses are being used correctly throughout the code,
| audit to make sure no internal secrets accidentally made
| their way into the internal repository (this happens as much
| in closed source as it does in open source), and you try to
| remove any problematic code, commit messages or references
| from the code, it takes time.
| kemayo wrote:
| Isn't it a bad look for Canonical, a major open source
| company, to not have developed core software for their
| major open source product in an open source friendly
| manner?
| Andrew_nenakhov wrote:
| Why should they do everything open source? To keep happy
| a few bored FOSS maximalists, who have neither real
| interest, nor use for the code?
|
| We develop open source applications ourselves, and the
| amount of jerks who drop in from time to time and teach
| us how to do what (without contributing any code or
| donations, of course) is overwhelming. They don't care
| how you pay your bills and how much effort it takes to
| make things happen.
| bananamerica wrote:
| IDK where you work but isn't it possible that many FOSS
| has significantly less resources than Canonical?
| kd913 wrote:
| >Would you describe exactly what will be expensive in
| releasing the source code to software that was developed in
| house? Does it have lots of dependencies on proprietary
| software? If so, why?
|
| Im not too sure as I don't work for Canonical. However, from
| an external perspective having worked with bzr and launchpad,
| I wouldn't be surprised if there is a bunch of aspects there
| that would make opensourcing a nightmare.
|
| Things like potentially giving some mechanism that could
| enable a user to sign/publish on behalf of Canonical
| snaps/packages for example. That kind of thing would probably
| need to be removed. Deep integration between CI/operational
| infrastructure for things like building images. I can imagine
| after Canonical's experience of launchpad that they probably
| did hardcode aspects and it isn't some modular thing you can
| just spin up on docker.
|
| >And this, is the killer. This is exactly what the people at
| Linux Mint do not want. This is why F-Droid exists on
| Android. Yes, free software can be distributed on the snap
| store or on Google Play, but ultimately these are proprietary
| platforms controlled by one corporate entity whose interests
| may not be aligned with those of the community. Users of
| community Linux distros demand choice in where they obtain
| software.
|
| Snaps I checked aren't there to replace apt. They don't
| prevent the install of flatpak, appimages or any alternative.
| Canonical has no agreement that prevents parties like
| Mozilla/KDE from only publishing on the snap store.
|
| >Malware has already been successfully pushed to the Snap
| Store. We now trust software because it came from a store
| that removes well known malware.
|
| There was one case of a snap bundled with a cryptominer. That
| was settled within 3 days and addressed to the community in a
| blog. Since then, it has been deliberately looked for. As
| someone who has published on the snap store, yes there are
| some checks present to ensure malicious software isn't being
| pushed.
|
| >The idea of "trust" here is also antithetical to open-source
| and software freedom. Rather than trusting software because
| it has verifiable source code,
|
| It is really easy for me to see exactly what is being
| run/executed on the snaps that I install. In fact I have
| built/used snaps successfully without even the snap store all
| together.
| commoner wrote:
| > However, from an external perspective having worked with
| bzr and launchpad, I wouldn't be surprised if there is a
| bunch of aspects there that would make opensourcing a
| nightmare.
|
| If Canonical, as a Linux company, is not willing to spend
| the effort to open source their software, then Snap can
| continue to be rejected by Linux distributions. Canonical's
| most obvious reason for keeping the Snap server closed
| source is to lock its users into a proprietary and
| centralized system that it has full control over. This
| strategy is no different from Apple disallowing
| installations outside of the App Store on iOS, and Google
| disallowing alternative app stores in Google Play.
| kd913 wrote:
| You haven't really at all explained any justifiable
| reason for Canonical to open source it. You still haven't
| argued at all the resource aspects which are I think the
| primary motivator here.
|
| Canonical has done this experiment precisely in the past,
| and we see the results of nobody operating their own
| launchpad instance. Nobody contributing back. That
| experience probably trumps all of this goodwill and
| opinions from the community.
|
| Canonical is more importantly getting users, publishers
| and numbers behind them. A discussion I remember reading
| was that every snap has 10x more installs than the
| corresponding flatpak. That and they have 1st party
| support from major publishers like Google, Microsoft,
| Amazon, Spotify, Mozilla, Jetbrains, KDE etc....
|
| Those aspects are more important for usability for the
| average user.
| commoner wrote:
| > You haven't really at all explained any justifiable
| reason for Canonical to open source it.
|
| I've explained why it would be in the users' interest for
| Canonical to open source the Snap store: it reduces
| vendor lock-in and allows the users to enjoy the benefits
| of open source software (the ability to use, study,
| share, and improve the software with no restrictions).
|
| Whether open sourcing the Snap server benefits Canonical
| is irrelevant to the users.
| kd913 wrote:
| No you think it would be in the users' interest but it
| absolutely isn't. I'm willing to bet money you haven't
| looked at launchpad's source code at all. Nor have you or
| anyone else considered operating their own. That is how
| most of the Ubuntu based distros right now are already
| getting their software.
|
| If Canonical goes down, a huge part of the usable linux
| market goes down with it. Possibly Linux Mint too, unless
| im mistaken.
|
| >vendor lock-in
|
| You are not vendor locked in. You can install flatpak,
| install via apt, appimages etc... Canonical doesn't ban
| the removal of snapd from ubuntu distros.
|
| In fact, from a Linux dev I would argue that half the
| fragmentation for pointless nonsense like packaging and
| distributions has harmed the community far more. Namely
| because it's increased the cost of development for these
| things to a degree that companies won't even bother
| developing/publishing software on Linux. That has been
| the primary problem for Linux so far.
|
| Canonical is actually getting first party support from
| major publishers and people still lampoon them. This
| includes publishers in the past who never would have
| considered publishing for Linux before.
| commoner wrote:
| > No you think it would be in the users' interest but it
| absolutely isn't.
|
| If you don't understand the value of free and open source
| software, you're not obligated to use it. The maintainers
| of Linux Mint and other Linux distributions do
| understand, and that is one of the reasons they have
| rejected Snap.
|
| > I'm willing to bet money you haven't looked at
| launchpad's source code at all. Nor have you or anyone
| else considered operating their own.
|
| Your assumption is wrong and you've lost the bet.
| Additionally, Flatpak is available and Flatpak servers
| are already being hosted independently:
|
| https://www.google.com/search?q=%22our%20flatpak%20repo%2
| 2
|
| > You are not vendor locked in. You can install flatpak,
| install via apt, appimages etc... Canonical doesn't ban
| the removal of snapd from ubuntu distros.
|
| Canonical has already transformed apt installs of
| Chromium into Snap installs, which motivated Linux Mint
| to reject Snap. Vendor lock-in is not black and white.
| For example, Android users can also install F-Droid or a
| variety of third-party app stores, but considering Google
| Play's default status on Android, most users are
| effectively locked in. The same applies to Canonical's
| handling of Chromium, and the Linux community is opposing
| this to discourage Canonical from continuing this dark
| pattern.
|
| > half the fragmentation for pointless nonsense like
| packaging and distributions has harmed the community far
| more
|
| Snap increases the fragmentation, and is more hostile to
| the FOSS community than all of the other options because
| its server is closed source.
| kd913 wrote:
| >If you don't understand the value of open source
| software, you're not obligated to use it. The maintainers
| of Linux Mint and other Linux distributions do
| understand, and that is one of the reasons they have
| rejected Snap.
|
| I understand the value of open source software. I work
| for the industry building open source drivers and
| contributed back. But providing/producing and maintaining
| software isn't free and that is precisely the main
| motivator that you don't seem to pay attention to.
|
| It's all good using a 100% FOSS stack, but that is
| irrelevant for the average user who wants to use things
| like Office, Steam and Spotify. The lack of usable
| software holds back Linux Desktop. So does your almost
| Stallman esque attitude to this.
|
| >Your assumption is wrong and you've lost the bet.
| Additionally, Flatpak is available and Flatpak servers
| are already being hosted independently:
|
| So you are hosting your own launchpad instance? Please do
| show me, that and all the wonderful contributions you
| have made to Canonical to have justified the massive
| resources they undertook by open sourcing it.
|
| >Additionally, Flatpak is available and Flatpak servers
| are already being hosted independently:
|
| That is a negative which I have argued multiple times.
| Multiple locations to have to find software which makes
| finding useful software harder. The user has to trust
| random third parties which breaks security.
|
| Yea, Canonical had all those experiences with PPAs and
| how much of a nightmare that has been.
|
| >Canonical has already transformed apt installs of
| Chromium into Snap installs, which motivated Linux Mint
| to reject Snap. Vendor lock-in is not black and white.
| For example, Android users can also install F-Droid or a
| variety of third-party app stores, but considering Google
| Play's default status on Android, most users are
| effectively locked in. The same applies to Canonical's
| handling of Chromium, and the Linux community is opposing
| this to discourage Canonical from continuing this dark
| pattern.
|
| Funny you are saying this and advocating OpenSource and
| all this nonsense. Do you know why Canonical moved the
| chromium binary to snap? It's because maintenance costs
| were ridiculous. They had to backport their compiler and
| support versions from 14.04 to 19.10 at the time. They
| couldn't backport the compiler, and because chromium is a
| browser, users must be on the latest version for security
| reasons. It also deeply integrates with the OS via the
| Linux specific sandboxes which do not work the same from
| 14.04 to 19.10.
|
| This they were maintaining for FREE. They didn't even
| have to do this because the officially supported browser
| is Firefox.
|
| They didn't want to burden the cost for this nonsense and
| rightfully moved it to snap.
|
| Where is Mint here providing the maintenance costs/burden
| for providing chromium as a deb here.
|
| Canonical explained it clearly here.
|
| https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-
| trans...
|
| >For example, Android users can also install F-Droid or a
| variety of third-party app stores, but considering Google
| Play's default status on Android, most users are
| effectively locked in.
|
| You are delusional if you think the situation is anywhere
| near the closed wall aspects of Android. Canonical
| doesn't operate it's own safety net or attestation that
| bans F-Droid or any other distribution. They don't have
| any controls or inhibitions in place for how users
| install/distrubte software unlike Android.
|
| >Snap increases the fragmentation, and is more hostile to
| the FOSS community than all of the other options because
| its server is closed source.
|
| You seem more hostile to the goals of the FOSS community
| than they are in my eyes. The person who is preventing
| Steam Games, WINE, Adobe software etc.. from coming to
| Linux is people like you.
|
| They can reject snap all they want.
| suby wrote:
| Linux Mint maintains a Debian derivative
| (https://linuxmint.com/download_lmde.php) so that they
| can continue operating should something happen to make
| the Ubuntu derivative unfeasible.
|
| Also, for what it's worth, I remain entirely unconvinced
| by your argument that this is fine from a users point of
| view. If they want to stop the push back, they need to
| ensure that they are not the only one with the ability to
| host a Snap store similar to how Flatpak does it. You can
| claim that this is irrelevant as it won't be used, and I
| suspect that you're right about that, but they will not
| be trusted until this happens.
| rlpb wrote:
| > Does it have lots of dependencies on proprietary software?
|
| Not so much proprietary software (those dependencies would be
| owned by Canonical and therefore released in the same lot)
| but I understand there is considerable dependency on
| deployment machinery. Documentation for that machinery will
| need to be split out into private (contains secrets,
| references to customers, etc) and public (consumable by
| someone looking to replicate a Snap store deployment) and so
| on.
|
| > Rather than trusting software because it has verifiable
| source code, we now trust software because it came from a
| store that removes well known malware.
|
| The world has moved to that. I don't like it. I would prefer
| to install only distribution-curated software. However that
| doesn't help me get a bunch of software that isn't available
| that way. Where it is (and at the version I need), I use it.
| Note that this particular statement of yours applies equally
| to AppImage, Flatpak and everything else that isn't
| distribution-curated. It's not just an argument against
| Snaps.
| jancsika wrote:
| > The world has moved to that.
|
| The world has also moved to casually clicking links to
| "install" arbitrary apps (which in turn call stacks of
| arbitrary libraries and frameworks the dev probably found
| by casually clicking links).
|
| You could give Debian and Ubuntu another decade to work on
| their packaging infrastructure and they still wouldn't
| reach parity with what we get through the web with the
| current browser security model.
| einpoklum wrote:
| > Namely that it would be expensive to open source it with
| little benefit in return.
|
| Ok, so the whole technology is irrelevant and should not be
| used then.
|
| > Canonical already spent a large amount of investment
| opensourcing launchpad
|
| Why develop it as non-open-source to begin with?
| madeofpalk wrote:
| > The reason for why the backend for the snap store hasn't been
| opensourced has been explained multiple times.
|
| I just think it's weird that a supposedly open source company
| like Canonical would build close source infrastructure. Like,
| just develop it in the open to begin with?
| berkes wrote:
| Better even: design it to be self-hostable from scratch.
| Edit: by making it a self-contained executable, a .deb or
| even a set of ansible scripts.
|
| I understand that some complex interconnected ball-of-
| spaghetti of microservices makes little sense to open-source,
| b/c no-one can run it.
|
| But that is essentially saying: we never wanted people to run
| it themselves, and now we are at a point that no-one can run
| it, so why bother?
| madeofpalk wrote:
| Sure, there's "even better" ways to go above what they did,
| but it seems to be than an open source company would at
| least by default develop open source software.
|
| They had to have actively chosen to build this closed-
| source software, no.
| johannes1234321 wrote:
| > Canonical already spent a large amount of investment
| opensourcing launchpad and nobody other than them operate it.
|
| Launchpad has a weird user experience and was for a long time
| too much focussed on bazaar when git won.
|
| At work we used bazaar and lp for a while, but still I always
| have to search for the right path for getting to a project's
| code. The bug tracker was more useful than GitHub's but that
| didn't help ...
|
| Aside from that there are the legal implications of AfferoGPL
| which prevent many people from touching it.
|
| But yes, doing infrastructures is hard. I however don't know
| how complicated hosting is and how well it's packaged. For
| software starting for in-house use this often is a mess ...
| ocdtrekkie wrote:
| > Canonical already spent a large amount of investment
| opensourcing launchpad and nobody other than them operate it.
|
| I posit that this doesn't matter.
|
| Presumably Ubuntu's infrastructure should be open source so
| that it can be inspected if necessary, for security reasons. It
| shouldn't matter if nobody else is actually hosting an
| alternative copy... it is still important that their copy be
| open source.
| dilandau wrote:
| >snapd not open-source.
|
| Red herring. The Linux Mint teams' _main_ complaints have to do
| with issues around the way snap wrests control from the user.
|
| >I will remind people that the most popular PPA to this day is
| a Java PPA being run by some 3rd party that doesn't offer Java.
| That PPA has root access to thousands of machines.
|
| Imagine strawman-ing this hard.
| kd913 wrote:
| >Red herring. The Linux Mint teams' main complaints have to
| do with issues around the way snap wrests control from the
| user.
|
| Like Linux Mint is doing the same? There is no control being
| lost by using Ubuntu versus Mint. I could remove snapd there
| without people making that decision for me.
|
| Worse would be Mint's decision of removing the only FOSS
| built version of chromium without offering an alternative in
| place. Canonical only installed the chromium snap because
| they did not have the resources to support a deb version
| instead.
|
| >Imagine strawman-ing this hard.
|
| It isn't a strawman. It is precisely what their reasoning was
| and it makes perfect sense. The snap store has already seen
| people attempt to install cryptominers. There is no way in
| Flatpak of banning known malicious flathub repos.
| the_af wrote:
| > _Like Linux Mint is doing the same? There is no control
| being lost by using Ubuntu versus Mint._
|
| If I understood the issue correctly (and I may very well be
| mistaken!) the problem Mint has with Canonical is that
| Ubuntu has "hijacked" (for lack of a better term) some apt
| packages so that they now actually install snapd and the
| snap. So you think you're opting out of snap, but when you
| use apt to install Chromium you end up using snap anyway.
|
| _If I understand correctly_ , this is Mint's main
| complaint: that Ubuntu seems to be hijacking apt packages
| with snap.
| kd913 wrote:
| There is no apt package with Chromium.
|
| https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-
| trans...
|
| Canonical couldn't afford the maintenance costs for it.
| On Ubuntu distributions it's either the snap or you have
| to create some weird frankendeb aspect by pulling from
| Debian.
|
| They explained it better than I would.
|
| In other cases, I don't think of a case where apt
| installs snaps over apt. I think the only priority for
| the decision choice was based on most recent version.
| Although this aspect I am slightly unclear.
| dilandau wrote:
| And yet they have all the time in the world to spend on
| an invasive daemon that pulls updates OTA without user
| consent. Plus all the other bullshit they've tried (Mir,
| unity, juju or whatever it's called). Thankfully Debian
| is still true to the game.
| the_af wrote:
| Oh. If there is no Chromium apt package, isn't the
| following from TFA (lwn) misleading?
|
| > _The problem was the decision to change the Ubuntu
| chromium-browser APT package itself upstream in Ubuntu.
| Previously, that package would simply install Chromium
| directly. With the change, it would instead install the
| Snap package-management tools first and then install the
| Snap equivalent of the Chromium package -- without making
| it clear to the user what was happening._
| hannasanarion wrote:
| > Canonical only installed the chromium snap because they
| did not have the resources to support a deb version instead
|
| So Canonical has the resources to make an entire DE, an
| init system, a mobile OS, a new display server (all of
| which were dumped on the roadside), and then going all in
| on a brand new sandboxing/package management system
| developed from scratch, but merely _compiling_ a web
| browser officially supported by google and used by nearly
| every single one of their users is too much work?
| dilandau wrote:
| Another red herring, and also moving the goalposts.
|
| Quit shilling.
| stonogo wrote:
| None of these arguments are convincing.
|
| > Namely that it would be expensive to open source it with
| little benefit in return.
|
| I don't think that's the real reason; I think it's that
| Canonical wants to maintain control. Their dream of being the
| App Store of linux isn't working out.
|
| > Canonical already spent a large amount of investment
| opensourcing launchpad
|
| If their development practices make open-source development
| expensive, that's Canonical's problem, not anyone else's.
| Nobody else uses Launchpad because Launchpad is not a
| compelling platform. It's still tied to bazaar, which frankly
| lost the version-control wars. Treating git as a second-class
| citizen is not how to engender contributors.
|
| > Snap store specifically from what I gather is a bunch of
| operational machinery that doesn't make sense without also
| operating launchpad.
|
| Another example of having to choose: did Canonical engineer
| themselves into a corner, causing all of Launchpad to become
| technical debt from under which Snap cannot escape? Or was it a
| deliberate business decision to try to maintain control of the
| store? An affirmative conclusion _in either case_ doesn 't look
| good for Snap.
|
| > Namely they want one location to find software, and one
| location to serve software. If users have to use the command
| line to add a external repo that has unfetted access, then that
| defeats any usability gains.
|
| Users pretty clearly do not want this. Many people use Ubuntu
| expressly because of the PPA system; I'd argue that it directly
| caused Fedora's COPR system to exist because of the user
| demand. There's no mandate that PPA installation require
| command-line configuration; it would be trivial to create a
| bespoke per-PPA using e.g. Vala. Synaptic already allows
| configuration of PPAs via GUI. It's total non-issue.
|
| > That and the whole aspects of malware/trust goes out the
| window.
|
| They're already out the window. Snap packages are not reviewed
| for content and anyone can just cram software into it from
| random GitHub repositories. Wouldn't it be nice if it were
| possible to set up a 'curated' Snap store with strong promises
| of software quality and review? We can't, because it's
| apparently too hard to run. Another drag on Snap.
|
| I'll not bother to respond to the whataboutism regarding PPAs.
| Literally the only difference between "a giant PPA that
| Canonical hosts" and the Snap store is that anyone can upload
| to the Snap store.
|
| None of the problems Snap store purports to solve are
| compelling, so these explanations don't really further the
| cause.
| Grimm665 wrote:
| > Users pretty clearly do not want this. Many people use
| Ubuntu expressly because of the PPA system
|
| Agreed. This is one feature of Ubuntu I miss sorely after
| leaving it behind for other distros.
| michaelmrose wrote:
| Nearly every packaging system is able to successfully divorce
| building of software from offering artifacts for download let
| alone ops. This is arguing that having failed to design their
| system appropriately we ought to accept the fruits of that bad
| design instead of dumping Ubuntu. Compare this with apt.
|
| Second what you describe as a defect. There being multiple
| sources of software is a plus it means the power is in the
| hands of the user to decide whom to trust. What you don't want
| is a situation where people must configure additional sources
| just to have commonly needed software. The example you provide
| about the Java PPA is apt, pun intended, ideally commonly
| required software would be provided by the vendor instead of
| siloed in a third party source. Of course the vendor and the
| license must make this possible.
| agentx3r wrote:
| Disclaimer, I like the snap packaging format, and I'm not
| familiar with the history of launchpad.
|
| Operationally:
|
| - I can trivially host and control my own apt repository,
| either as a mirror of some upstream repository, or with bespoke
| packages.
|
| - I can't do the same with snaps.
|
| So launchpad and snap store isn't quite apples-to-apples. It
| would help of course if a snap store could be statically hosted
| or re-implemented, but the full API is quite complex.
| rdschouw wrote:
| I do not think anyone disputes Ubuntu's goals or intentions.
|
| The problem is that the snap store is managed by Ubuntu without
| any community oversight.
|
| By not releasing source code to the store, other distributions
| cannot create their own.
|
| These are the reasons what is holding snap back for broader
| adoption.
| kd913 wrote:
| >The problem is that the snap store is managed by Ubuntu
| without any community oversight.
|
| That is already the case for most repos/launchpad on Ubuntu
| but people don't really have too much problems with that.
|
| >By not releasing source code to the store, other
| distributions cannot create their own.
|
| Other distributions wouldn't because the operational cost of
| operating it is too high.
|
| >These are the reasons what is holding snap back for broader
| adoption.
|
| Snap isn't being held back by adoption. It has more first
| party publisher support and more installs.
| commoner wrote:
| There is no downside to Flatpak's support for multiple
| repositories and ability to self-host repositories. GNOME
| Software and KDE Discover both set Flathub as the default
| repository, which serves as the primary software source, and
| users can optionally add more repositories if they choose to do
| so. Users who don't want additional repositories can simply
| stay with Flathub without having to do anything.
|
| The Snap server's closed-source nature is not a benefit to
| users, and there is no excuse that can justify this from the
| users' perspective.
| kd913 wrote:
| >There is no downside to Flatpak's support for multiple
| repositories and ability to self-host repositories.
|
| There are always tradeoffs. I would argue there are
| advantages for having a trusted party vetting my software
| repos. It's why I even use Ubuntu because I trust Canonical
| to make some sane decisions when vetting their repositories.
|
| You give multiple repository support and suddenly users have
| to one find a way to add another repo, and second there is no
| way of removing software from those repositories if they do
| end up malicious.
|
| Which is why I brought up the webupd8 java instance having
| root access to thousands of machines.
|
| >users can optionally add more repositories if they choose to
| do so.
|
| Ubuntu is the version of Linux designed to be used by your
| grandmother. They want to make it as easy as possible for
| users to install trusted/safe software from both
| proprietary/free vendors.
|
| It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains
| released software as a snap long before it is even possible
| on flatpak but nevermind that. I don't think you can even get
| VSCode, Spotify or Intellij on Flatpak.
| kelnos wrote:
| > _They want to make it as easy as possible for users to
| install trusted /safe software from both proprietary/free
| vendors._
|
| Canonical deciding that Ubuntu won't allow third-party Snap
| repositories is completely orthogonal to open sourcing
| their Snap server and/or making it easy for people to
| develop alternatives. They can perfectly well do both.
| commoner wrote:
| > You give multiple repository support and suddenly users
| have to one find a way to add another repo, and second
| there is no way of removing software from those
| repositories if they do end up malicious.
|
| > Ubuntu is the version of Linux designed to be used by
| your grandmother. They want to make it as easy as possible
| for users to install trusted/safe software from both
| proprietary/free vendors.
|
| By default, GNOME Software and KDE Discover only use the
| Flathub repository. Your grandmother won't be adding other
| repositories to the Flatpak client. Users who don't add any
| extra repositories will use Flathub, which is a trusted
| source of software that runs on an open source server.
|
| > It's kind of telling that
| Mozilla/Microsoft/Spotify/Jetbrains released software as a
| snap long before it is even possible on flatpak but
| nevermind that. I don't think you can even get VSCode,
| Spotify or Intellij on Flatpak.
|
| https://www.flathub.org/apps/details/com.visualstudio.code
|
| https://www.flathub.org/apps/details/com.spotify.Client
|
| https://www.flathub.org/apps/details/com.jetbrains.IntelliJ
| -...
| kd913 wrote:
| None of those 3 links are provided by Microsoft, Spotify
| or Jetbrains. Yes they are there, but they are published
| from 3rd parties. Why exactly do you think that is?
|
| The microsoft, spotify and Jetbrains software comes
| directly from their respective publishers. Problems are
| supported and debugged directly. That is a major
| difference.
| cosmojg wrote:
| > Why exactly do you think that is?
|
| Canonical very publicly collaborated with these companies
| to get their software on the Snap store while Flathub has
| been handled in a more free-for-all manner. If you build
| it, they will come, and all that. Moreover, I'm not so
| sure Red Hat is _as_ explicitly interested in
| monopolizing the Linux application ecosystem as
| Canonical, especially since their acquisition by IBM.
| Maybe IBM has other ideas, but we likely won 't see
| similar marketing efforts on that front in the near
| future.
| michaelmrose wrote:
| Can we not pretend that the single source nature is
| anything other than a money grab? It's pretty clear that
| all you have to do to ensure grandma doesn't add sources is
| make adding it require the cli.
| kd913 wrote:
| You can watch the discussions from Popey, Martin Wimpress
| etc... It's pretty clear from their perspective that they
| built the tech from users/devs first approach.
|
| Do you really think Canonical is looking for money over
| here? If so do please precisely explain in the short-term
| how exactly you think they are gonna achieve that.
|
| Do you think they are suddenly going to be able to
| dominate the entire 100% Linux desktop software market
| and charge 30%? Do you think a company like
| Microsoft/Spotify/Jetbrains would just roll over with
| that? I don't imagine they can do that considering Red
| Hat/Suse market position. Nor do I see the total Linux
| Desktop applications being a blip at all on their revenue
| streams.
|
| Last I checked, they are still providing infrastructure
| to the Linux community for free. They still have more
| market share then the rest of the Linux distros combined.
| That and without them, Linux Mint wouldn't be operating
| as they do now.
|
| Frankly they don't deserve the hatred the FOSS community
| throws at them and you are being somewhat disingenuous by
| presenting them as such.
| commoner wrote:
| The FOSS community opposes Snap because its server is
| closed source and forces vendor lock-in to Canonical,
| among other reasons. This is fairly simple to understand
| and not "disingenuous".
| kd913 wrote:
| You haven't even explained how it's vendor lock-in.
| Canonical has no way designed their approach to ban the
| use of apt, rpm, deb, flatpak or appimages. They are in
| no way of a position to dominate the market in the way
| Google does with Android and it's stupid to even think
| that is their aim.
|
| It should be pretty obvious to you why they aren't
| exactly going to claim 30% commission on nothing from
| users who are as cost averse as possible. It should be
| plainly obvious to you also how they don't have the clout
| to bully software vendors to publish for them.
|
| They have already plenty of evidence that profitability
| of distribution of linux software isn't exactly a
| lucrative market like Google or Apple. The fact that you
| think that is their aim or that it is feasible in the
| FOSS Linux community with large scale players like
| Google/Microsoft/IBM is ludicrous. Canonical tries to
| attempt to get such vendor lock-in and they would lose so
| much marketshare apps on their store instantaneously.
| They aren't even in a position like
| Apple/Google/Microsoft here who charge money to publish
| apps.
|
| I have already explained how that argument is complete
| nonsense.
| commoner wrote:
| There are degrees to vendor lock-in, and it's not black
| and white as you portray it to be. Flatpak and apt
| exhibit minimal lock-in, because they are decentralized
| and fully open source. Snap, on the other hand, has a
| closed source server that is controlled solely by
| Canonical. Since the Snap Store is the only preinstalled
| app store on Ubuntu, this results in a greater degree of
| lock-in than Flatpak and apt.
|
| The backlash from Linux Mint and other distributions was
| partly caused by Canonical using Snap for Chromium when
| the user intended to install it through apt. This sleight
| of hand is not as extreme as a 30% commission, but it's a
| step in the wrong direction. The FOSS community is able
| to reject moves toward vendor lock-in even if the closed
| source Snap server does not mandate a 30% commission.
| kd913 wrote:
| >There are degrees to vendor lock-in, and it's not black
| and white as you portray it to be. Flatpak and apt
| exhibit minimal lock-in, because they are decentralized
| and fully open source. Snap, on the other hand, has a
| closed source server that is controlled solely by
| Canonical. Since the Snap Store is the only preinstalled
| app store on Ubuntu, this results in a greater degree of
| lock-in than Flatpak and apt.
|
| You keep repeating yourself. Having a default mechanism
| for installing software installed on Ubuntu distros that
| is using Ubuntu based infrastructure does not constitute
| vendor lock in. Guess what, Ubuntu uses apt rather than
| yum. That isn't vendor lock in either.
|
| Having a proprietary back end does not constitute vendor
| lock in.
|
| What you are saying is the equivalent of using spotify is
| vendor lock in. That or using Firefox. Heck Canonical's
| model here is practically no different from Firefox with
| their addon store.
|
| A developer can choose to ignore snap all together and
| still distribute on Ubuntu. A user can choose to ignore
| snap all together and still install software on Ubuntu.
| They will have to face the consequence of not having to
| use chromium because nobody is willing to maintain it
| other than Canonical. What is this nonsense that you are
| spouting.
|
| >The backlash from Linux Mint and other distributions was
| partly caused by Canonical using Snap for Chromium when
| the user intended to install it through apt. This sleight
| of hand is not as extreme as a 30% commission, but it's a
| step in the wrong direction. The FOSS community is able
| to reject moves toward vendor lock-in even if the closed
| source Snap server does not mandate a 30% commission.
|
| Because any move that you or Mint disagrees with is a
| 'step' in the wrong direction? So be it, I and probably
| Canonical would rather be wrong.
|
| Snap has 10x the install base for each snap compared to
| flatpak. It also has more first party software support.
| ryukafalz wrote:
| > Guess what, Ubuntu uses apt rather than yum. That isn't
| vendor lock in either.
|
| Apt and yum both support configuring multiple repos,
| their protocols are well-documented, there are an
| abundance of repo implementations, etc. If apt only
| supported a single upstream repo and Debian kept the
| source proprietary, do you think Ubuntu would exist?
| jcastro wrote:
| > The FOSS community opposes Snap because its server is
| closed source
|
| If this was true FOSS projects wouldn't be publishing
| things on the snap store (they are, and they publish on
| google play, winget, and other closed app stores).
|
| No one can claim they speak for whatever you think "the
| FOSS community" is, let alone what it opposes or
| supports.
| addicted wrote:
| Your first argument is an argument against using Linux at
| all.
| ufo wrote:
| I'm curious... what is that Java PPA that you are talking
| about? I tried searching for it but I couldn't find anywhere
| that had a list of the most downloaded PPAs.
| kd913 wrote:
| This is the PPA.
| https://launchpad.net/%7Ewebupd8team/+archive/ubuntu/java
|
| For years it has been recommended as the mechanism for
| installing Java on Ubuntu installs.
| andrewshadura wrote:
| Why would anyone use this instead of distro packages?
| boring_twenties wrote:
| Distros (at least Debian and Ubuntu) don't package Oracle
| Java AFAIK.
| kd913 wrote:
| Because SO/Google told them in 2012 to do it that way.
|
| Suddenly the sysadmins in charge have forgotten they used
| this mechanism to install it on their ancient linux
| boxes.
| alyandon wrote:
| The short story is - developers typically need to target
| more than one version of Java and the long lifetime of
| LTS releases don't line of up very well with that.
|
| Canonical historically provided a single "system" version
| of Java (meaning any system packages that depends on Java
| depended on this package) which meant that that was the
| version of Java that you got with Ubuntu XX.XX - even for
| LTS releases which had a 5 year lifespan.
|
| Ubuntu 16.04 - which is still in support came with
| openjdk-7 and Canonical refused to provide an openjdk-8
| package for it despite Java 8 being the prevalent
| development platform from late 2016 onwards and despite
| numerous requests to do so. No one was expecting
| Canonical to replace openjdk-7 with openjdk-8 - they only
| wanted to be able to install openjdk-8 along side the
| existing openjdk-7 system Java.
|
| Ubuntu 18.04 - slightly different scenario but still the
| same problem - openjdk-8 and openjdk-11 are available but
| that still doesn't cover all development use cases.
|
| Thus, people add the PPA and install the openjdk from
| there because someone currently is doing the work of
| keeping the PPA up to date.
| vips7L wrote:
| Most people I know seem to use sdkman, jenv, or jabba for
| managing multiple jdk installs rather than rely on the
| system one.
| curt15 wrote:
| >The reason for why the backend for the snap store hasn't been
| opensourced has been explained multiple times. Namely that it
| would be expensive to open source it with little benefit in
| return.
|
| Perhaps a business reason left unsaid is that an open source
| snap store would undermine Canonical's paid "enterprise
| edition" snap store. Why would an organization pay $30000
| (https://ubuntu.com/internet-of-things) for a private app store
| if they could easily set up their own snap store?
| BruiseLee wrote:
| And that is exactly why it would be very expensive to open
| source it. All this revenue ($30000 * number of paying
| organizations) would then be gone.
| darksoulzz wrote:
| Great
| falcrist wrote:
| From the July 2 Mint blog post:
| https://blog.linuxmint.com/?p=3766
|
| > When Flatpak came out it immediately allowed anyone to create
| stores. The Flatpak client can talk to multiple stores. Spotify
| is on Flathub and they can push towards it. If tomorrow they have
| an argument with Flathub they can create their own store and the
| very same Flatpak client will still work with it. When Snap came
| out, it was only a client. The server was behind closed doors and
| the client couldn't talk to multiple servers.
|
| and
|
| > Ubuntu is planning to replace the Chromium repository package
| with an empty package which installs the Chromium snap. In other
| words, as you install APT updates, Snap becomes a requirement for
| you to continue to use Chromium and installs itself behind your
| back.
|
| Yea that seems to me to be a problem.
|
| From the June 1st Mint blog post:
| https://blog.linuxmint.com/?p=3906
|
| > ...in the Ubuntu 20.04 package base, the Chromium package is
| indeed empty and acting, without your consent, as a backdoor by
| connecting your computer to the Ubuntu Store. Applications in
| this store cannot be patched, or pinned. You can't audit them,
| hold them, modify them or even point snap to a different store.
| You've as much empowerment with this as if you were using
| proprietary software, i.e. none. This is in effect similar to a
| commercial proprietary solution, but with two major differences:
| It runs as root, and it installs itself without asking you.
|
| If I'm reading this right, Snap is basically trying to fix the
| problem of software dependencies on older packages by bundling
| things together (a la flatpack)... but it ALSO replaces the
| various repositories in different distributions of linux with a
| closed-source, centralized repository that points towards
| cannonical, and advertises ubuntu to people using other distros
| and potentially gives cannonical control over the distribution of
| sotfware in the linux ecosystem. AND it can do this behind the
| scenes without the knowledge of the users, who may think they're
| still using their normal repo system.
|
| The whole scheme seems completely antithetical to the principles
| of FOSS. You don't have to go full Stallman to see this as a bad
| thing IMO. From that perspective, Mint's decision to drop support
| for Snap makes a LOT of sense.
|
| Also, one of the reasons I enjoy running linux (I dual-boot with
| windows) is that it does what I tell it to do, and ONLY what I
| tell it to do. There's no BS like Cortana auto-installing or
| onedrive automatically uploading a bunch of my pictures to the
| cloud (yes that actually happened). I already have a linux distro
| that takes that benefit away, but I accept that (for now),
| because it's a phone. I'm not ok with losing that on my desktop.
| CrankyBear wrote:
| Ancient news. https://news.ycombinator.com/item?id=23433794
| dzonga wrote:
| snap vs flatpak vs appimages once again shows the fragmentation
| within the linux desktop ecosystem. as a user, it makes me sad,
| cz I can't have one good solid experience. snap, updates might
| break, flatpak is not fully supported.
|
| And my strong belief, is Microsoft is going to eat Linux Desktop.
| WSL to run your server apps and coding environment. windows for
| user apps. as someone who hasn't used windows in over 10 years,
| day by day seems windows is gonna be the future. sad to say, but
| true.
| unethical_ban wrote:
| I haven't used Snap much, but I would like to add this: The
| Ubuntu Software Center (and debian packaging in general) is not
| gen-pop friendly. There are library packages, support packages,
| metapackages, and when you search, the results are shaky, non-
| existent, or overwhelmed by results no end-user would be
| interested in installing standalone.
|
| There is also the issue of dependencies, and there is some
| elegance in the design philosophy of "package everything for a
| program and install it standalone" vs. having shared libraries.
|
| So I see the benefit in an app-store. Someone below said "snap is
| horrible" because it's lock in. It isn't! Ubuntu hasn't taken
| away apt.
|
| But simple, easy package distribution to nontechnical users, for
| the benefit of stability and ease of use, is a noble one.
| fractal618 wrote:
| I am hoping that they switch over to Clear Linux. I just switched
| over on my personal laptop, and it's been terrific.
| pjfin123 wrote:
| If desktop Linux is ever going to be mainstream there needs to be
| an easy to use "app store" where users can use a GUI to install
| apps which need to be sandboxed like on a mobile phone with
| defined permissions. Snapcraft is way ahead of Flatpak on this
| and the current Ubuntu setup works well. On Ubuntu you can go to
| the Ubuntu software app (gui) search for software and it blends
| apt results with snap results. This really seems like the best
| way to do things, common packages can be installed through a
| traditional package manager while more niche ones can be
| installed with snap. A lot of people are mad at Canonical for not
| open sourcing the backend but no one seems to be offering to
| build one. Anyways the really important part of snap is having a
| unified executable for Linux (which Canonical has made open
| source).Snap makes it really easy for developers to target Linux
| with a unified executable which they won't do otherwise due to
| Desktop Linux's small market share.
| fullstop wrote:
| Pop!_OS integrates flathub into their "app store" [0]
|
| [0] https://blog.system76.com/post/616861064165031936/whats-
| new-...
| commoner wrote:
| > On Ubuntu you can go to the Ubuntu software app (gui) search
| for software and it blends apt results with snap results.
|
| GNOME Software and KDE Discover support both Flatpak and the
| distribution's native package manager together. For example
| implementations on Ubuntu-based distributions that work out of
| the box, see the elementaryOS AppCenter and the Pop!_OS
| Pop!_Shop:
|
| https://github.com/elementary/appcenter
|
| https://github.com/pop-os/shop
| qchris wrote:
| Just wanted to +1 Pop's Pop!_Shop. I have machines running
| both Ubuntu and Pop!_OS, and for some reason (not sure if
| it's because of the underlying tech/architecture differences,
| System76 curation, or what), the Pop package management has
| always been a better experience than Ubuntu's.
| gjs278 wrote:
| people used windows without an app store just fine. I don't
| even use an app store on macs, I download straight from the
| publishers
| sleavey wrote:
| Is the best solution then (in terms of what current Linux users
| probably want) to introduce permissions to existing repository
| applications? Best of both worlds: reuse of system libraries,
| security updates to upstream packages without having to update
| the application itself, and pseudo-sandboxing for extra
| security.
| maweki wrote:
| You missed the point where Canonical brought their own apt-get
| that just installs the snap anyways. So no, you can't install
| stuff through your traditional package manager.
| driverdan wrote:
| > If desktop Linux is ever going to be mainstream there needs
| to be an easy to use "app store"
|
| Why? Desktop computers worked just fine for 35 or so years
| before app stores showed up. It's completely unnecessary.
| sgillen wrote:
| Yes but I believe that most causal non techy users just wont
| put up with it or at least would much prefer a GUI.
| old-gregg wrote:
| With gadgets similar to iPhones and iPads I think we'd be
| better off designating general purpose computers for
| professional use, and not having to worry about
| hypothetical "grandpas" installing malware while checking
| the weather, especially on Linux.
| sgillen wrote:
| Yeah I actually agree with you. If the goal was to get
| more people to use desktop linux / PCs making them more
| like and iPhone would be good. But I don't think that's a
| good goal to have.
| kelnos wrote:
| > _If desktop Linux is ever going to be mainstream there needs
| to be an easy to use "app store" where users can use a GUI to
| install apps which need to be sandboxed like on a mobile phone
| with defined permissions._
|
| Curious... do you think that the world has moved on from the
| "download from website and run installer" model? Obviously that
| has serious drawbacks from a security perspective, but up until
| less than a decade ago, that was the only way to get software
| on Windows and macOS, and they were perfectly mainstream.
|
| I think the majority of users out there don't understand
| sandboxing or permissions models or why they are useful. While
| I think those are the users that probably benefit from them the
| most, it doesn't follow that we need these things before
| average users will embrace a particular platform.
|
| > _A lot of people are mad at Canonical for not open sourcing
| the backend but no one seems to be offering to build one._
|
| You mention Flatpak and then two sentences later claim this?
|
| I think maybe you're just missing the point. I have been using
| Linux as my daily driver for a good two decades now. I don't
| care one bit about Linux being a mainstream desktop distro.
| Sure, if it was, new (and even not-so-new) hardware would get
| better support, and that would be a win. But getting that is
| not a fair trade off if what we have to accept in return is a
| closed-source, walled-garden software delivery model. Hard
| pass, no thanks.
|
| For the most part, the only people who _really_ care about
| "the year of the Linux desktop" are people trying to build a
| business around desktop Linux. Those aren't the sorts of people
| I want making decisions like this, but, unfortunately, they're
| often the kinds of people who have the ability to force these
| things on the community.
| throwaway8941 wrote:
| >For the most part, the only people who really care about
| "the year of the Linux desktop" are people trying to build a
| business around desktop Linux
|
| As another long time Linux guy, I have a feeling most of
| those obsessed with Linux becoming a mainstream desktop
| platform are Mac or Windows users.
| mad182 wrote:
| Same. I'm running Linux as my primary desktop and server
| operating system for ~16 years, and I don't really care if
| it's becoming more mainstream on desktops anymore. It's
| already working perfectly fine for my needs, so I don't
| even want it to change much.
| MarcellusDrum wrote:
| But it should at least continue to grow on the same rate
| as Windows and Mac. Losing market share is gonna be
| disastrous, as it would mean less software supported, and
| companies give less time to ensure quality of software
| supported.
| wmil wrote:
| There are a lot of web developers who aren't thrilled with
| Apple's current lineup.
|
| They just want to get Chrome and VSCode running without any
| headaches.
| pjfin123 wrote:
| No one is offering to build an alternate store for snaps,
| Flatpak is building an entirely different executable.
| blendergeek wrote:
| Why would anyone offer an alternate store for snaps?
|
| Ubuntu seems to have made clear that the snap client will
| not be able to connect to alternative stores. What is the
| point of building an alternative store.
|
| Further snap is controlled by one company. Canonical has a
| history of developing groundbreaking new things for the
| Linux community before unceremoniously killing them off.
|
| * Ubuntu One * Unity Desktop * Ubuntu Touch * Upstart Init
| system
|
| Do you see a trend here? There is a reason the community is
| skeptical of something completely controlled by Canonical.
| thekyle wrote:
| I believe that the Canonical Snap server is hardcoded into
| snapd, so even if someone did implement their own you would
| need to recompile snapd to even use it.
| mschuetz wrote:
| I wish every OS had comprehensive sandboxing so that you could
| just run any untrusted and potentially mallicious executable
| from the web and enable and disable features at will.
| AnIdiotOnTheNet wrote:
| > If desktop Linux is ever going to be mainstream there needs
| to be an easy to use "app store" where users can use a GUI to
| install apps which need to be sandboxed like on a mobile phone
| with defined permissions
|
| If this is what you're looking for out of a computer, then why
| not just use a phone, tablet, or something like ChromeOS?
| esclerofilo wrote:
| Because there are lots of things a computer can do
| comfortably that a phone, tablet or chromebook can't.
|
| Sometimes there can be tradeoffs between convenience and
| security, but in the case of an app store the convenience
| actually enhances the security, because it diminishes the
| chance of people running random harmful commands from the
| Web.
| trabant00 wrote:
| > If desktop Linux is ever going to be mainstream
|
| I do not want that to be the target. Going mainstream never
| helped with the quality of anything. Quite the contrary:
| mainstream means lowest common denominator.
|
| If you want to compromise on how much you control of your
| desktop os for more vendor support you already have windows and
| macos.
| lifeisstillgood wrote:
| should I just give up and go back to FreeBSD ?
| seemslegit wrote:
| Canonical was overdue for cancellation ever since they pulled the
| "Amazon shopping lens" crap.
| fractal618 wrote:
| I'm hoping they will switch their base to Clear Linux. I have
| been using Clear Linux on my personal laptop, and it's been a
| fantastic experience so far.
| pyrophane wrote:
| What's been fantastic about it? I'm genuinely interested. My
| only real familiarity with Clear is that I see it dominating
| those Phoronix benchmarks, but I didn't know it was a complete
| end-user distro.
| entropicdrifter wrote:
| Isn't Clear Linux an Intel project? Kinda defeats the purpose
| if you're trying to reduce the influence of one corporation by
| replacing it with an even bigger, more monopolistic one
| Shared404 wrote:
| Why would they switch to Clear Linux? They already have a
| Debian edition for those who don't want an Ubuntu base.
|
| I personally don't see the issue with using Ubuntu as a base,
| _if_ you remove all of the offensive bits. iirc one of the
| Pop!_OS dev's was asked if they were going to rebase on Debian.
| The response was something akin to "We already change
| everything on the end user facing side, so there's not really a
| need."
| chimen wrote:
| The fact that you have to post on a forum and argue with people
| why you need permission X for your snap package was enough for me
| to abort publishing on this platform. I should ask permissions
| from the users not from the platform publishers on a forum post.
| simosx wrote:
| By default you ask your users for these permissions, if you do
| not want to get them from the Snap Store.
|
| That is, create your snap package and publish it on the Snap
| Store. Do not request to pre-approve any permissions. Arrange
| with your users to enable those permissions on demand.
| donmcronald wrote:
| This is exactly the issue I have with it. It feels like an
| attempt to control app distribution on Linux. No thanks.
|
| I'm so sick of the app store model. The app stores usurp
| control of distribution from developers which adds risk which
| reduces willingness to invest and the result is that app stores
| attract low effort, low value apps unless they're coming from a
| huge company. Everyone loses except the app store owners, big
| platforms like Facebook and Spotify, and spammers / scammers.
|
| The app store model is one of the worst things to happen to
| tech in my lifetime.
| Animats wrote:
| Is it time to switch from Ubuntu to Mint? Does Mint have enough
| repositories that work? I'm at Ubuntu 18.04 LTS, and Ubuntu 20
| seems to have a host of unwanted Canonical-oriented features. I'd
| appreciate comments.
| opdahl wrote:
| Well since Mint is also a Debian distro you can basically run
| anything that you can run on Ubuntu. I've used it for 3 years
| and still haven't come across any situation where this isn't
| the case.
| addicted wrote:
| I usually go with Ubuntu on cloud platforms because it's one of
| the defaults.
|
| Any suggestions on what's a good alternative distributor go with
| that is widely supported and easily available on the variety of
| cloud platforms?
| john-shaffer wrote:
| I'm very happy with Debian. I mostly like Ubuntu, but I can't
| have snapd restarting things whenever it feels like it.
| TekMol wrote:
| Debian
| suff wrote:
| 'efficiency' over community? Fine. Looks like Ubuntu gets kicked
| out of the community. There's the door, Ken VanDine. Bye bye.
| flavor8 wrote:
| I haven't been impressed with snap as a user.
|
| The jetbrains stuff keeps several versions around by default,
| which eats disk space. I'm sure there's a way to change that, but
| I haven't cared enough to dig.
|
| The other day I ran `apt install chromium-browser` on a brand new
| install; it chose to install via snap (grr) and then snapd
| promptly crashed ("Waiting for restart" --
| https://forum.snapcraft.io/t/installing-the-chromium-snap-in...),
| but apt's wrapper wasn't notified. I ended up ctrl-Cing, which
| left dkpg (somehow involved) in an inconsistent state. Took
| several iterations of dkpg reconfigure and apt update to recover.
| I've been on linux for 20 years, so not a big deal for me, but my
| experience has been that snap is less newbie friendly than apt.
| rlpb wrote:
| > The jetbrains stuff keeps several versions around by default,
| which eats disk space. I'm sure there's a way to change that,
| but I haven't cared enough to dig.
|
| See "refresh.retain" from https://snapcraft.io/docs/keeping-
| snaps-up-to-date - the point is that you can revert an update
| instantly.
| flavor8 wrote:
| I mean I get it. I don't think the defaults are right though.
| It could be smarter - automatic purge 7 days after user has
| used new version, or something along those lines. Keeping 3
| versions just in case doesn't sound like anybody's ideal.
| simosx wrote:
| By default, snapd keeps three copies of older versions of a
| snap package. It does so, so that you can revert easily to a
| previous version if the latest version does not work. You can
| disable this feature by setting the appropriate key to `1`.
|
| There is a negative sentiment around snap packages. Even if you
| are an experienced Linux user, you fall into that negative
| sentiment and even if an issue is small, it is a deal-breaker
| for you.
|
| The "chromium" issue has been explained in 2019. Ubuntu 20.04
| does not plan to package "chromium" as a deb package (too
| difficult to maintain properly), therefore there was a need for
| a backup plan if users were trying to install it.
| flavor8 wrote:
| > Even if you are an experienced Linux user, you fall into
| that negative sentiment and even if an issue is small, it is
| a deal-breaker for you.
|
| I don't think that's fair. Apt/deb is solid, battle tested,
| and works. Introducing snap with this kind of instability is
| the source of the negativity.
|
| > The "chromium" issue has been explained in 2019.
|
| And the fact that it still crashes in 2020, on a flagship
| package on a modern laptop, is really really bad. In fact I
| had the same crash happen during a dist-upgrade on another
| laptop(!) which locked up the entire dist-upgrade.
|
| If apt is going to call snap, it needs to be rock solid.
| [deleted]
| Swastikadb wrote:
| Great
| pyrophane wrote:
| I immediately thought of Linux Mint Debian Edition when I saw
| this. They describe it as something they are developing just in
| case, you know, "Ubuntu was ever to disappear." Well, excepting
| for some kind of Microsoft acquisition of Canonical ("we will be
| shifting our focus to developing Ubuntu for WSL"), I don't think
| Ubuntu will disappear, but it certainly might become so
| unfriendly to downstream distros that they have to move off of
| it.
| jwlake wrote:
| I'm unclear why ubuntu needs the chromium package in apt. Seems
| like they should just stop publishing apt packages for chromium,
| only publish in snap, and steer users into using snap for
| installs and not apt. Seems less confusing and wins or loses on
| its merit.
| berkes wrote:
| On latest LTS (Ubuntu 20.04 LTS) the apt version is simply a
| transitional package. It installs the snap for you.
|
| It says so on the description directly next to the name:
| "Transitional package - chromium-browser -> chromium snap"
|
| There only for people upgrading, so they are not suddenly
| surprised seeing their browser gone.
| jwlake wrote:
| Just seems like an unintended consequences confusing
| situation. I think a pretty rational policy would to _never_
| have an apt package install a snap package. Moving to snap is
| a breaking change, effectively, so you have to bite the
| bullet at some point.
|
| Mixing your distribution systems with references to each
| other seems like a recipe for confusion and anger. And it
| looks like they got the expected outcome.
| berkes wrote:
| > seems like a recipe for confusion and anger.
|
| People where "suddenly Chrome is gone" will be angry too.
|
| Just imagine the outrage of a title like "The update to
| Catalina wiped all mac users' browsers with all their
| bookmarks and history. Forever".
|
| And those are the people that cannot easily solve it. The
| person being able to know what a "Transitional package" or
| the difference between snap and apt is, is also the person
| who knows how (to google for) to move the old
| ~/.config/chrome/ directory into the snap.
|
| This is also the person being enraged that Ubuntu offers a
| mechanism for all the people who cannot do that themselves.
| That sounds quite selfish to me.
| rlpb wrote:
| I believe the reasoning is that Ubuntu users do not care
| about the technical mechanism used to ship the software
| that comes with Ubuntu.
|
| I mean: clearly some people do care, given that that this
| thread exists. I think you'll find that they aren't your
| typical Ubuntu user though.
|
| Users who do care are quite capable of adjusting their
| configuration, and Ubuntu doesn't get in the way of that
| (configure apt not to install snapd ever, and it won't).
|
| This is only an issue for users who want to push their
| political opinions on to other Ubuntu users.
| yxhuvud wrote:
| Then people get stuck on old insecure versions of chromium.
| Or it simply disappears. Do you really think that doesn't
| create confusion and anger?
| simosx wrote:
| Chromium is very complicated in terms of packaging, and
| packaging it as a deb package is too tough. Because when a new
| version appears, you need to do lots of work to get it updated
| quickly.
|
| For Ubuntu 20.04, it has been explained (in 2019!) that
| Chromium will be only available as a snap package. To help
| users transition, the command `sudo apt install chromium-
| browser` would install the snap package. It is better than
| "package not found".
|
| It is so simple, but if you are stuck in a negative sentiment
| on snaps (read this thread), you get crazy.
| hamandcheese wrote:
| My only brief experience with Snap packages was installing golang
| (on Ubuntu). I was just dabbling, and the snap package seemed to
| be a lot more recent than the apt version, so I went for it.
|
| A week or so later, I guess the snap package auto-updated itself,
| because my go installation broke with an error about how the go
| tool version no longer matches the currently running version of
| go.
|
| That pretty much ruined Snap in my mind, particularly for system
| software.
| einpoklum wrote:
| This snap business is what we get when commercial interests try
| to warp the concept of FOSS distributions. That's what we get for
| letting companies such as Canonical and Red Hat control so much
| of the distribution space (and I mention Red Hat because of
| systemd, which has made its inroads much more successfully).
|
| And snap is bad not just because you can't patch, or pin, or set
| up a snap mirror etc. The whole concept is bad.
|
| That
| williesleg wrote:
| Bravo! I switched from Ubuntu to Debian to escape the Snap Crap.
| speakspokespok wrote:
| Suse has been around just as long as RedHat, put out a great
| suite of products, went for-profit, and seems to do well in the
| EU market. They've never generated as much buzz - good or bad -
| though. Is that just my perspective from being in the American
| linux bubble? Centos, RHEL, Debian, Ubuntu, Arch even; I hear
| about those players all the time.
___________________________________________________________________
(page generated 2020-07-08 23:00 UTC)