> 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.
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.
There is a big user issue on top of the philosophical and maintenance issues - snaps are SLOOOOOOW. I've only experienced them with two applications, and both took forever to startup compared to the apt-get installed versions I quickly replaced them with.
OK, "forever" is hyperbole - it was probably about 5 seconds. But it was enough of an annoyance for me to figure out how to install a deb packaged version. And every user having to wait an extra 5 seconds every time they open an app aggregates to a lot more time than Canonical saves maintaining packages.
That doesn't sit right with me, so my next OS upgrade will be Mint or pure Debian. I've been with Ubuntu since Dapper Drake, and I'd like to thank Canonical for making great distros all that time. But I'm not going to follow you down the snap-only path, time for me to move on.
Sending some encouragement your way: try Debian. I bet money you won't even notice it's not Ubuntu. Or you will, because your software will launch when you ask it to. I'm super happy with Debian lately. I know it used to be the old neck beard slow and steady distro, but honestly these days packages get updates rather timely and it doesn't feel like the Debian of 10 years ago. And you can always run Debian testing with almost no overhead if you want the shinnies. That's what I do and have only had to deal with gnome not starting after a reboot once XD
I've been using Debian unstable with apt-listbugs for many years with barely a problem. Testing has issues of its own which one should be aware of before choosing it over unstable (see https://www.debian.org/doc/manuals/debian-faq/choosing.en.ht..., "Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.")
Lately I tried fedora and surprised they have many up to date packages including exa (ls alternative) and other new shiny rust tools. I've switched to using it for one of my personal server and quite happy.
One problem I have with Debian (that is not Debian's fault) is that NVidia does not officially support it. It probably works just fine, but it's just another thing you might run into.
Debian is nice if you don't mind the glacial pace of updates -i.e. you're running a server. After using Arch I don't think I can give up rolling releases.
A little while ago I discovered snaps can be slow even when you're not using them. I had the fun of trying to log into an online job interview and couldn't because snapd was hogging the CPU doing god knows what. Restarted and the same happened, the machine became usable about 20 minutes later. Little "surprises" like that are infuriating.
> so my next OS upgrade will be Mint or pure Debian
I've moved one machine to debian stable and haven't looked back. There are a few teething issues like /usr/sbin not being in the default path, some sudo issues, the installer isn't as grandma friendly, but it's rock solid and doesn't nag me about updating 137 packages of things I've never heard of needing an update.
Just make sure you know what you are doing. It's not one of the major distros.
For the longest time you couldn't dist-upgrade it, at all. The functionality wasn't there. When their web servers got hacked, they cleaned them, and got hacked again.
From a Debian user's perspective it is unclear why these small distros can't just be a Debian derivative or a Fedora spin. It's not scalable that every small distro invents their own infrastructure.
Because pure Debian never worked with my wifi drivers, and Ubuntu didn't come with video codecs and other small lifestyle tweaks by default. If Debian came with those OOTB -- and they won't, since some of those codec ain't FOSS -- then I'd agree with you.
Like, I ain't crazy about what's happening with Mint and all of their hacks -- trust status: eradicated -- but I certainty get why they exist as a distro.
Except when it doesn't? I had all kinds of frustrations with Mint on a 2019 X1 Carbon which had some newfangled digital microphone. Ubuntu 20.04 worked out of the box. There were a bunch of other frustrations too. Bluetooth never worked right. The resolution kept resetting to the display native 4k mode instead of the 1080p I set it to which caused all other kinds of display bugs when switching back
I can see that Mint could be nice though. On a desktop, running hardware a few years old.
> the 'originals' work always better in the long run
Except that normal people can actually install Manjaro and it doesn't make you use AUR for pretty basic things. Except that Ubuntu actually doesn't shit itself almost every time you add a 3rd party package/repo and comes with reasonable defaults. Also, have you used Pop OS?
> Except that Ubuntu actually doesn't shit itself almost every time you add a 3rd party package/repo and comes with reasonable defaults.
I'm using debian testing for more than 15 years and it never shit itself for a 3rd party repo.
Debian comes with whathever the original software developers set as the default sans the wallpaper. For sensible default you can bug the software developer in question, not debian.
Maybe the situation is different on the server side or I've just been extremely unlucky, but I keep getting my packages broken. Just a few days ago I was installing Wireguard on a Stretch system (added unstable repo, lowest priority, pinned packages) and APT got tangled up to the point where I couldn't install almost anything because one package was too new, but trying to remove it went down the dependency tree all the way to `util-linux` and I had to do surgery with `dpkg -r --force-depends` to fix it.
On the server side, I only use stable (due to security updates and other critical stuff). Using testing in three desktop systems (two at office, one at home) currently, all workstations which see regular, heavy usage.
To add unstable packages to a stable system with repo pinning and using apt directly is not the best practice though.
If I'm going to add stuff from unstable, I use aptitude. Its dependency resolution and solution suggestions are better and more manageable than ordinary apt. It allows you what's going to happen before actually pulling the trigger.
The only package I get from unstable is firefox. I add the repo, update the package and remove the repo afterwards because unstable and experimental are highly chaotic realms and not suitable to use continuously due to high rate of uncontrolled change. Also unstable and experimental are not guaranteed to not to break. Testing and stable are implicitly (testing) and explicitly (stable) is guaranteed to work.
With this recipe, I only had to re-install a Debian system once; to migrate it from 32 to 64 bits since a very big disk cache with very small files was triggering a bug causing disks to trash and system slow down to a crawl. There were no procedures to migrate a 32 bit system to a 64 one in a reliable manner so, I just reinstalled it.
I've had a friend struggle with half a dozen Linux distributions. Then I told him about Arch Linux. One day later he told me he had a fully functioning Linux desktop.
I was impressed because usually when I install Arch Linux I forget to boot the flash drive with UEFI enabled so I get stuck because I get errors during bootloader installation. I also love to do pointless things like install Arch Linux (not the iso) on a 32GB flash drive.
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.
I have the same problem. Snaps are confined to only files within $HOME. I keep almost all data under /media/ and this caused snaps to be mostly unusable for me, at least unusable for productivity apps where I need to process data. Some apps though are self contained, e.g. Spotify, for example, works fine for me as a snap.
Yup. There needs to be considerable work to integrate snaps from completely sandboxed (no access to file system/network/hardware), to giving them controlled access to some resources, managed/monitored by root and/or user.
For the longest time Snap chromium couldn't access files it had downloaded. So I would click to open a pdf when it was completed and get an error. I had to go whitelist my home dir in some config somewhere ..
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.
That wouldn't solve the root of the problem, though. The real solution would be to use other distros.
Besides, there are quality concerns with browser forks maintained by an understaffed project. The fact that ungoogled-chromium asks for internet randos to provide its own binary releases doesn't inspire confidence either. If someone desperately needs to use Ubuntu, they'd be better off using Firefox.
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
> 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.
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.
AppImages are the only thing I run also, as a full time linux user and admin. I just hate the proliferation of questionable services, especially in systemd land. A lot of my focus is on minimization of stack, and snap and flatpak just don't stand up to scrutiny imho.
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)
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.
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?
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.
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.
Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build".
In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored).
The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare.
"Appimages are great but there's no sandboxing or updates"
Actually there is sandboxing and updates, if you want to take an extra steps.
I prefer AppImages over Flatpack and Snaps for essentially the same reasons commented above.
I typically launch them with Firejail for the sandboxing. i.e. "firejail --appimage /path/to/appimage" instead of just the appimage alone. Seems to work just fine. Firejail has additional options that can be done.
Some AppImage creators do provide an update method that can be installed using zsync2, but I've not tried it since the whole point is disposability.
There are two types of "static linking" being discussed:
* Linking with system libraries (what GP mentioned).
* Linking with Go packages (what you're talking about).
Yes, Go doesn't really support -buildmode=shared anymore (and it was pretty broken from the outset). But this is a separate question to whether a Go binary is actually a static object. In most cases (and by default), Go binaries are dynamically linked to system libraries (with Go packages being statically linked into the program).
The original comment[1] spoke about "statically linked binaries" which has a pretty specific meaning ("file" says its a static binary). There are similar issues for Debian packaging if you had a hypothetical language which required you to vendor your dependencies because maintenance for security issues would be annoying (Debian worked around this problem in Go through "de-vendoring" and Go modules -- in theory -- mostly solve this issue today). But static binaries are generally not distributed in distributions because they make make core library updates worse in terms of download size as well as inflating memory usage due to lack of page-cache sharing.
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.
For the first part, I found Debian’s Maintainers’ Guide [0] pretty helpful when I was updating xscreensaver last year (hasn’t been uploaded yet though...). It also has a section at the beginning concerning how to adopt orphaned packages. For upstream updates, some projects will have a way to create deb packages themselves, which can make installation/updates easier later on (concrete example, with OpenZFS can create RPMs and debs from the upstream tree).
Plenty of software companies provide their own Apt repositories. Adding a repository is usually as simple as copying a single file to /etc/apt/sources.list.d/. Sometimes you may also need to add a GPG key, which can also be as simple as copying a file to /etc/apt/trusted.gpg.d/ (though most instructions seem to favor a manual one-liner that imports the key to the global database[1]). Technically you could automate both with a one-time deb install, though I'm not aware of anybody that actually does this. In any event, after that `apt-get upgrade` will upgrade third-party packages just as well as Debian or Ubuntu packages.
I much prefer Debian packages over RPM, and Apt over Yum/DNF, but unfortunately setting up a Debian package repository is more difficult than for RPM. The tools exist, and are more sophisticated and capable--for example, Aptly--but there's a higher learning curve. Also, good luck using them outside Linux. Years ago I published Debian package repositories from OpenBSD, but I had to manually hack the relevant tools to build and work on OpenBSD. For RPM/Yum I could have more easily written (and at a different job later did) an indexing tool from scratch.
The problem with Debian packages and Apt repositories isn't that they're not capable, it's that they have high learning curves due to the slow accretion of features that obscure their potential. A better tooling story would help, particularly for repositories. Better tools for initializing Debian package builds exist; the problem is more a surfeit of choices.
[1] It's more complicated and creates unnecessary headaches than dropping a file into trusted.gpgp.d, but the practice seems to reflect the opacity of the Debian packaging ecosystem. There's a better, simpler way to do it, but everybody cargo cults the same old solutions and then complains that it's too complex or inelegant.
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?".
> 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.
It only works if they are self contained without access additional resources on the file system, as the executable file is kept alive until process termination.
Now if the process tries to access some datafiles that changed contents during the upgrade, it might just crash and burn, eventually corrupting data in the process.
Ideally security updates aren't deferred for 5 years because its working well enough and happen for the whole system when you aren't using the machine as opposed to just for that app when you launch it.
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 ?
> 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.
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.
I also prefer appimages as the "least worst" of the three.
However, a quick note: As someone who unofficially maintains a linux port of my companies software, I have considered packaging it as an appimage, but there's one problem with appimages that kills the concept.
Appimages are read-only[1]. I'd love to package my companies product that way, but we already have update-delivery infrastructure that works on windows and mac (and linux), and it assumes it can write to the "install folder". Changing the entire update infrastructure specifically for an OS we don't officially support is a non-starter.
From a developer perspective, I would love the ability to update an appimage's contents in place. However, as a user I'd also like the ability to set it read-only to block updates if I desire. Flatpak's mandatory updates are one of the key reasons I dislike it. Never the less, if the goal is to smooth the path for proprietary software to support linux without making half a dozen different packaging solutions, in place updates need to be supported.
[1] edit: according to comments below, they now have an update mechanism, but it's still a totally appimage-specific process, so my problem remains :/
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)?
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.
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...
...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.
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).
Taking power away from users to address that inconvenience may be the status quo in the proprietary software industry, but it's totally over the line for user-respecting FOSS software. Not least because, once a developer acquires that power over users they very frequently succumb to the temptation to abuse their userbase as involuntary beta testers for half-baked bullshit which users struggle to opt-out of.
Taking power away from the users and putting it in the hands of upstream maintainers is pretty bad, but putting it in the hands of distro maintainers is even worse in my experience. Upstream maintainers are at least the people who develop the software directly and deal with the bug reports.
Make the user report their current version in the reporting dialog. Automatically close all reports for prior versions and inform the user to update and revisit.
`curl | bash` gets a bad wrap. From a security perspective (assuming you trust web pki), it's 100% no different than a) downloading and running a script, b) downloading a package and and installing it, c) downloading a binary blob and executing it, etc. I actually find that piping an install script to an interpreter is the easiest to audit of all the options because I can see exactly the changes that will be made to my system. I don't know where the whole "zomg pipe to bash is so insecure" vibe came from, but it's effectively
developer urban myth. The only improvement is if you somehow directly exchange keys with the vendor out of band with no web pki intermediate step and then verify the signature on the software you're installing... yeah.
> The only improvement is if you somehow directly exchange keys with the vendor out of band with no web pki intermediate step and then verify the signature on the software you're installing... yeah.
Which is what Apt has done for 20+ years - packages are gpg-signed, developers sign with their individual keys (and have to have their identity verified by at least one other developer) and even someone who controls a root CA (which is most national governments and many large corporations, let's be fair) would have to mount a dedicated attack to subvert that process.
> 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.
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.
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.
Just wanted to easy one worry of you: the age, popularity and maturity of your application has no influence on whether or not these permission requests are granted. The approval process is formally defined and mostly depends on what your application does exactly.
In case this eases your worries: the approval process for permissions is formalised and does not depend on how mature or well-known the app is.
In addition: users always have the option to override permissions. The approval process is for automatic (default) permission grants. Even if these are not granted, users can grant them manually.
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).
Every attempt at "solving" this "problem", including Snap, Flatpak, and AppImage, are an absolutely awful regression in the state of Linux. I absolutely hate this trend. These tools solve problems for only two kinds of software: proprietary software, and software with suck reckless, runaway complexity that it can only run in one specific environment. I have no interest in either kind and I will give no quarter to "solutions" for their "problems".
flatkill.org is clickbait, not written in good faith, and doesn't propose any solution. Moreover things like "it's obvious Red Hat developers working on flatpak do not care about security" is just unnecessary and toxic.
Issues mentioned on flatkill are already fixed, will be fixed or doesn't depend on flatpak itself (like the UI / icon in the software app store).
I don't like Flatpak either but I think we should elevate the debate to deeper architectural issues of flatpak that won't be fixed easily. Personally, I do not like the following in Flatpak :
- no effort on full reproducibility like Nix&Guix
- a big fat flat runtime rather than traditional fine grained dependencies (although OStree avoids duplication, but still very elegant)
- you can't install extra pkg in the sandbox. So the quite overkill solution in RedHat's vision is to separate between Toolbox/Podman for devs vs Flatpak for users, rather than trying to make a single unified sandbox for everything. Of course everything breaks down when you try to code using a Flatpaked IDE, if you follow RedHat's vision you basically need to spawn a toolbox container from an unsandboxed flatpak instance of your IDE :
https://github.com/flathub/com.visualstudio.code/issues/44
So personally, I'm still waiting for a packaging system that is :
- compatible with the idea of a declarative/immutable os (like nix, guix, silverblue)
- tries to make everything reproducible (like guix)
- sandboxed with runtime permission API (like Flatpak portals, IOS, Android)
- sandbox can be augmented with packages so that you can code in your sandboxed IDE + add necessary dev packages inside a same sandbox without having to break it
I mostly agree with you and I'm not going to get even near Snaps and Flatpaks.
However, ignoring the aspect of software distribution, wouldn't you agree that the approach taken by the Linux desktop today is deficient security-wise? For example, I would like to be able to give mbsync (or Thunderbird or whatever) my IMAP password without giving it to any other program. So I don't want to store it in mbsync's config file in plain text. Neither will I use gnome-keyring (or any other keyring) because it doesn't have any kind of "program authorisation". Any program can just spawn a new "secret-tool" process and get my credentials from gnome-keyring.
I've been thinking for a while about implementing a keyring which runs as a daemon with SUID of a dedicated user and checks which program sends requests to it, using /proc/pid/exe, but I'm not sure if it's a secure source of truth: how e.g. namespaces affect what's visible in /proc/pid/exe. I know you've been developing himitsu[1]. Have you thought about this problem in that context?
> 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 :)
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.
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.
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...)
I personally would avoid docker, but 'containers', yes.
> Snaps are completely redundant there.
Yes, they certainly are but it seems to be harder and harder to get rid of snapd. It's probably not going to be an actual issue for Focal, but it's about this trend... Maybe Canonical will see sense -- who knows?
Meanwhile, I do have to at least have a broad plan for the next 2-5 years, so...
Not too seriously, but it kind of depends on the project which $OTHER_DISTRO we'll go with, I think.
Debian stable is an obvious choice for projects that don't rely on too much "new stuff" because we already have a lot of stuff that uses APT, deb repositories, etc. Otherwise, probably CentOS/RHEL for those situations that are just ultra-averse to incremental change and prefer a HUGE change once every 5-10 years.
I think we might become a bit more adventurous and move to e.g. NixOS for "newer" projects. That's probably going to have to be trialed for a few projects before we go all in on it, but it seems really nice for servers (and dev machines for that matter), but it'll be interesting to see if you have to truly go all in to reap the benefits. (The worry here would be the amount of upstream 'support' in terms of manpower to bring in security updates, etc.).
(I'm also vaguely aware of SuSE, but I only spent a very brief period of time with it about 10-15 years ago and don't really remember any distinctive features either way. Which is kinda weird, because it seems to be known as the 'popular in Europe' distro?)
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.
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.
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.
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.
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.
> 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.
That's not the difficult part. The hard part is compiling a program that doesn't depend on Glibc 2.X when your users only have 2.6 or use Musl or whatever.
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
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.
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.
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.
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.
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.
> glibc (no matter what they say about having stable endpoints)
glibc does have a stable ABI. What they don't have is a frozen ABI so they will all new entry points. But old programs linked against glibc do and will continue to work fine.
> You can't run a program written today on the system repo libraries from 5 years ago.
You can absolutely write programs today targeting 5 year old ABIs. I agree that the FOSS toolchains could be more helpful there so you can just pass some compiler flag for the oldest glibc version you want to support but it is not impossible to achieve that on your own.
Do you see the fast development itself as a problem? I tend to see as the real issue that most package managers only allow one version of a package to be installed, leading to conflicts very quickly.
The best known manager that does allow this is Nix, do you know of any more, maybe ways to get this working with "traditional" package managers (completely transitioning to Nix is would be quite hard, from my limited experience)?
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?
> an app quitting out from under me because it wants to update
This doesn't happen, at least on account of Snap. It's copy-on-write when it comes to updates, and whatever version you have running at the time of update will happily keep on running. I've been mildly confused by this a couple times, when I would end up with two different versions of VS Code running side by side, but the bright side was that my work wasn't interrupted.
It incidentally also sidesteps all the problems that stem from libraries or configuration being updated under a running application, which can happen with Apt.
This is sort of like saying you can turn off auto-updates by leaving your Internet connection disabled - true, but missing the point that what people are primarily complaining about is having to adopt an adversarial relationship to the software they use.
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.
AppImages are basically (kind of) statically linked binaries.
Not my favorite to install software since they're usually huge (500mb is not far out of the norm), but great for things that are hard to install, as they're pretty much guaranteed to work.
I just wish there was a command line switch to stop it from wanting to install itself on my system (move the AppImage to /opt).
I have never seen that behavior from an AppImage. I just mark them executable and run them and they do their thing. If there is a specific AppImage behaving this way then it is probably the fault of the author, and if all of them are doing it then I wonder if it is the behavior of something like appimaged?
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
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.
> 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.
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.
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.
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.
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.
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.
> People run linux because they want visibility and control into what is happening on their systems.
I mean, not really? Or rather, that's not the only reason, or the main reason for many users.
Many people just want to use a FOSS OS, for the reason that any buggy component can be forked, fixed, and PRed, which—if you're an IT organization yourself—often means far less turnaround time than waiting for the appropriate vendor to fix the problem for you.
Honestly, I'd be fine using Windows Server or some other "cathedral" OS, if I could fork/fix/PR its components. I want a stable operational substrate for my app that's quick to fix in an emergency; I don't care whether it's made out of tiny shell-scripts or huge C libraries, as long as it gives me that property.
In that perspective, snap seems fine (you can still fork/fix/PR a snap) just like Docker images are fine, or systemd is fine.
Maybe, in the end, I'm more of a BSD person than a Linux person. I mostly favor Linux installs for the hardware compatibility and performance, not because it really fits my philosophy.
> Canonical seems to want to take away that visibility and control from their users.
The Microsoft way: over-automated operating system DE's which attempt to make the OS appear user friendly yet create one headache after another. They suffer from massive interconnected webs of program state and logic which fails leaving you with the only sane option of rebooting. The more automation the vendor inserts the less transparency and control you have.
>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.
tbh I just run linux because I want a good dev machine and I personally don't care if canonical abstracts updating software away, as far as I'm concerned they can keep everything up to date and do their thing, for me that's a plus for snaps, I generally find them pleasant to use.
In my experience people on HN in particular tend to vastly overestimate how much people value control vs features/abstracting routine tasks away.
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.
>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.
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.
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)
* 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.
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.
> Again, if Canonical is evil and can't be trusted why I would run Mint?
Rational self-interest. I don't think the tech giants are good for society, but not working with them would mean slipping into irrelevance.
Say, I'm a game developer. Do I trust Microsoft? No. Do I sacrifice 90% of my profit to boycott Windows? No. There are different degrees of "evilness", and the scale does matter, too.
But you can keep compatibility with Ubuntu if you want by using the same code but keeping control,
Honestly tell me if this does not sound idiotic "Microsoft is evil and we don't trust them, please run our own Windows copy that is the exact same thing but with different colors, MS can push an update and delete all your files because this is not a supported configuration and we have no scripts to check for it but we are not competent enough to setup our own repos and scripts like other distress"
I understand why Mint does what it does, the only idiotic part is complaining about trust in Canonical.
> * 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).
Also true for the Chromium snap (see next item for details).
> * Serving Chromium binaries with Snap removes the option of downloading, inspecting, and running the build chain locally
This is outright false. The Snap Store page for Chromium is available here: https://snapcraft.io/chromium. It links to the source, which is the git repository here: https://code.launchpad.net/~chromium-team/chromium-browser/+.... You can use these source together with snapcraft (which is Free Software, licensed under GPL-3.0) to download, inspect and run the build chain locally, including with any modifications that you want to make. You'll get a snap package as output, which you are free to distribute and other users can install it using the snap CLI.
> * Serving a different version of Chromium, or replacing the stock version with a different variety, cannot be done without creating a new Snap repository.
Partly false. You can ship a different version of Chromium in the Snap Store under a different name. This is an automated process, rather like creating a PPA. As long as you aren't misleading anyone and you follow the terms of the relevant licenses[1], nobody will stop you.
> * 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.
Partly correct. One generally cited reason for this is that the same criticism was leveled at Launchpad which was opened in response - but nobody is running an alternative production of Launchpad anywhere so Canonical doesn't want to waste that sort of effort again. Another is that store fragmentation is bad. I'm just stating the other side's position here. Please don't shoot the messenger.
[1] Chromium's licenses are listed as: Apache-2.0 AND BSD-3-Clause AND LGPL-2.0 AND LGPL-2.1 AND MIT AND MS-PL AND (GPL-2.0+ OR LGPL-2.1+ OR MPL-1.1)
>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.
Mirrors are just mirrors, they are not build farms that build from source.
I would convert the next sentence in math logic and prove you that it makes no sense but not sure you can understand the symbols so let me try again in English.
1 Mint does not trust Canonical
2 Mint plugs their users systems directly to Canonical untrustworthy repos to run possible "evil" binaries and scripts as root.
if 1 and 2 are true then as a user you should not use Mint, as a Mint developer you should start working and finally create an independent distribution.
IMO 1 is false, probably they mentioning "trust" was a mistake.
> 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.
> 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.
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.
> 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.
> Instead, installing PPAs to get updated builds of standard packages seems considered “normal”.
Perhaps we should consider why this is: because people want up-to-date software on their computers (desktop or server), instead of being beholden to whatever version distribution maintainers have decided you can have.
If you don't want software that has been configured and tested to work together by a distro maintainer, you're volunteering to do that work yourself and become the sole maintainer of a bleeding-edge distro with a very small audience.
That's fine - and why I use macOS as a desktop: because Homebrew consistently gives me up-to-date versions of the software I want. If I were to use Linux on the desktop, it would be a distribution which also allows this with minimal fuss - almost certainly not a Debian derivative.
I understand the _reasoning_ behind the distribution model - I just don't think it works very well, and apparently nor do all the people who use PPAs in the course of everyday use to get up-to-date software.
It's also worth noting that FreeBSD does not have this problem - ports are updated _much_ more often than most Linux distributions seem to be.
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 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.
I didn't; the post you were originally responding to (the GP of my original post, which is the GP of this one) did. I am not the person who made that post.
You appear to be saying that you can audit, hold, modify, pin software in third-party repositories. That means you agree with what I was saying in the GP to this post, that you have just as much ability to do all these things with third-party repo software as you do with software distributed using snaps.
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.
This move made me 100% opposed to snap. Don't beta test on my daily-drivers as a default.
The calculator should -always- load in a couple ms. It's one of the simplest tools on the shelf! If a calculator snap can't load immediately then I have no interest in a single other snap app. Waiting more than a second is a nightmare, and I've definitely waited 5+ seconds at times. That's about how long it takes my system to boot. As far as I'm concerned it's a complete failure and I couldn't possibly trust it on any desktop or server that I manage.
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.
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.
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.
Sounds like Windows with their UWP apps. Calculator also used to take 5 secs to load. It’s down to about a second now but still baffles me to think that MS management are ok with that
I guess people at MS test and quality departments use I7 with an SSD driver. If so, it's bad. If not it's simply hard to understand, if we leave corporate politics aside.
To me, the calculator has always been more or less OK, but the Image Viewer is a clusterfuck.
With the old viewer, it's almost instantanious opening by clicking a file in windows explorer. The new one is slow as a crawl. The first time may take 5 or 6 seconds (in a 7 year old laptop). The next time is down to 2 or 3. Compare that to milliseconds using the native app. I've never felt the need to use an specific image viewer, but now I'm happy with Irfanview, as fast as the old app, and full of features.
The difference is not noticeable, at least on my computer, and since Python is the language I work with the most these days, I always have one REPL opened
I somewhat disagree with this interpretation, I see more as using the votes as part of the argument "considering the downvotes you are wrong" and similar. In this case he got the signal that many people disagree with his message but cannot understand why.
It is one thing when you make a controversial statement and then decide to attack downvoters, it is a different thing if you are trying to understand how and why people disagreed with you.
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.
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.
My personal theory by now is that that person/team is sick of being forced to work on a stillborn project, and is trying to create as many pain points as possible to get the project killed already. I see no other reason by now. In that case, hats off to him.
Well ~/snap is pretty terrible but I am almost as annoyed with something like ~/.tmux.conf and no support for the XDG Base Dirs Spec or setting the config path.
With tmux it seems like this is finally possible with version 3.1 or by compiling it yourself but I remember being annoyed about this years ago.
I dislike a home directory cluttered with dotfiles just as much as that snap folder choice because when do we actually ever not list the hidden files?
It should be the default that my home folder isn't cluttered. I have tens and tens of pieces of software, it's very impractical to keep track what does what and if I have to get them to behave somehow.
That export list required got me weary, plus look at how many in that list are hardcoded :/, the situation is rather bad.
If world does not match your view it may be you who is outlier. I quite like current convention - hidden files in $HOME belong to applications. There is value in $XDG_CACHE_HOME - it can be safely removed (like /var/cache).
You force your view on open source community, that is rather bad.
> If world does not match your view it may be you who is outlier.
Looking at the amount of software that does follow the base directory specification, actually you're the outlier insisting on obsolete conventions.
You and a bunch of other developers insist on those things, in reality that is the actually harmful behaviour for open-source.
Interestingly but yet non-surprisingly, that insistence very often goes in hand with the stubborness to stay on obsolete mailing lists, ugly user interfaces, insecurity by-default, git-email, buggy issue trackers, 80-column commit messages, obsolete security standards and practices and so much more.
> I quite like current convention - hidden files in $HOME belong to applications.
The future is now, home folders aren't to be filled with trash. Move on or stay behind, seriously.
Lets check. I tolerate both versions, use workarounds in my .bash_profile and share them, actually tried to patch and have written article [0].
You shame software, half of it has workaround, see patching as impractical.
XDG Base Directory Specification [1] is not about your home folder. It is about default storage, separation of cache, user data and config, a way to provide another config, so one can:
* remove entire config when stuck with a problem
* remove cache, think /var/cache
* `ssh -F foo` would be `XDG_CONFIG_HOME=foo ssh`
Everyone has a pain point, everyone has a workflow, there is no One True Way. Please stop shaming authors, they quit, sometimes post it here about mob. Patching folder structure is the simplest thing. If you can't do that who is going to fix actual bugs?
> Please stop shaming authors, they quit, sometimes post it here about mob.
If one feels that talking about a bug in their software is "shaming" them, then maybe they should quit or alternatively, just quit pretending they want feedback or to write FOSS. Same applies to teams writing software.
Not to mention how harmful it is to think that everyone who picks up FOSS is actually good at it. Thinking people as infallible is actively harmful for the end users.
> Patching folder structure is the simplest thing. If you can't do that who is going to fix actual bugs?
Incorrect folder structure is an actual bug. It might be simple to patch for the end user, but you're ignoring the maintenance burden, annoyance and cumbersomeness.
> Everyone has a pain point, everyone has a workflow, there is no One True Way.
There are paths more correct than others, some workflows are obsolete and stupid, and should't be catered to. It's wilful ignorance to ignore that.
That's why I've called it harmful - choice between your complains and people writing code is obvious. Fork it, patch it, there is no burden - if people care maintainers would switch, if switched enough patch would get in upstream. Or provide own repository with patches, that's FOSS way. If not by yourself than sponsor.
How much do you actually care? How much would you pay? Is it free as speech or free as beer?
Without the rest of the context and no, criticism is not harmful. If it is a "sin" like you say, should we look at things you've said about FOSS projects?
> Fork it, patch it, there is no burden
Either you're delusional or you haven't done either of the things.
> if people care maintainers would switch, if switched enough patch would get in upstream or provide own repository with patches, that's FOSS way.
Yeah, and it'll take the next decade, being optimistic. GPU acceleration in Chromium and Firefox on Linux is a perfect example how absolute shit that "way" is.
> How much do you actually care? How much would you pay? Is it free as speech or free as beer?
Feel free (as in freedom) to just type out your arguments instead of asking rhetorical questions.
Question was not rhetorical - it is realization of freedom 1. You answer implies there is a fork with GPU acceleration and no one cares (or does not answer my post). Ah, "criticism is not harmful":
No, I won't pay to devs that ignore conventions. That's like having someone take a s* on my porch and me paying them for not doing so. Plus, demanding payment is the thing not really in the spirit for FOSS.
> Ah, "criticism is not harmful":
That's just naming, without listing the reason. In addition to that, I listed projects, not people. Shows that you've totally missed the point of the original list.
This is not yours software, you are just allowed to use it, that's you who are taking other peoples software on your porch (and naming it s*). No one demands, ever heard of bounty, sponsorship? Do not want to support original developers - fine, 3rd party.
Out of principle I can implement XDG Base for ssh client. Just like my work - implementing features I am not that interested in, providing support. I hardly believe any reasonable man expects complains to work in that case. So how much would you pay?
Your account may be group of people (and may be not). Project may be group of people (and may be not). Shows that you've totally missed the point.
> This is not yours software, you are just allowed to use it,
Oh but keep in mind in some cases I'm not given a choice. If I could not use snap for example, I would not. But it was forced upon me. So I have every right to be annoyed at someone figuratively taking a shit on my porch.
Anyways this discussion has depleted itself, you have no good arguments protecting that nonstandard behaviour.
You say Google is less trustworthy than Canonical, but you're using Chromium from a PPA. That's a personal packaging archive with far less auditing/eyeballs than either Canonical or Google.
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.
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.
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.
> 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:
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.
I want to like Pop!_Shop more, but it seems to start in the background on boot and hog 800MB of memory on my laptop while doing nothing. Not great on a RAM-constricted machine.
I like that after significant upgrades via apt, Pop!_OS shows a short summary of the updated system. Little touches like that go a long way in improving the experience.
> 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.
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.
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.
Flatpak is not a walled garden. Flathub totally messed up the decentralised aspect of flatpak but in theory flatpak can be totally decentralised and you would add software source like you add .debs PPA
Flatpak doesn't impose closed-source, we have distros which only use open source flatpak repos.
Models like Flatpak have the advantage of "download from website & install" i.e you get the apps directly from the producer (which is better for security) while having no walled garden app store but having the advantage of auto updates & permission systems
I do not like Flatpak for technical reasons but Flatpak itself is in no way a walled garden solution, the problem is Flathub.
> I don't care one bit about Linux being a mainstream desktop distro
If you still want to be able to run Linux at all (not even on new hardware) on a consumer hardware, then you should care.
- Linux doesn't run (decently) on Microsoft latest surfaces
- Linux won't run on new Apple hardware
- Linux doesn't run on Android phones (with a few exceptions)
- once Google switch to Fushia no more Linux kernel on mobile hardware
- on the long term Huawei will ditch Android and other OS for their own thing.
Linux will die on consumer hardware (except on servers) if it does not become more popular. According to Apple's keynote the future of Linux is in its cage, in a VM running on walled garden MacOS. According to Microsoft the future of Linux is WSL, running on top Windows.
If you do not like walled garden then you should definitively care about Linux getting more mainstream before no comsumer hardwares support it anymore
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.
Laying countertops is standard handyman stuff but if your coffeepot doesn't do anything truly unique and requires you to rip it up to switch coffeepots it may be ill designed.
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.
You have described a trend where those technologies failed to gain sustainable traction and Canonical stopped investing in them. Whether they did this because they are evil or unlucky is not the point.
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.
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.
I've used an app store (or rather an 'apt store') since 1999, it's the reason I moved from redhat to debian in the first place.
I'm not sure that "desktop computers" as we know it were around in the 60s (I certainly wasn't), but in the early 90s software tended to come from floppy disks, before that it was a C90 cassette on a spectrum.
Microsoft Store and Valve Steam do not contain (shock!) browsers, office, tools, etc. That I believe is a distinction between distribution and store - "store" agenda is not aligned with users.
As a user, I could not hate Snap more, along with whoever thought it was a good idea to release their crapware "for Linux" through Snapcraft only. If "desktop Linux" is going to be anything like Ubuntu and whatever Canonical stands for, I most definitely do not want it. That said, I do not really know what "the year of the Linux desktop" is supposed to refer to as I have been a happy Linux desktop user for way over two decades.
This makes me wonder. If Linux will become mainstream then won't it lose its charm? I'm using Linux because of the package management. If something replaces that with a closed "app store" it might attract proprietary companies and those companies will attract regular users then I may stop caring about Linux.
I would like to think that there will be maintained Linux distributions out there that we currently have today that do not use or depend on such closed "app stores". I think we will not have to worry about this dystopian future just yet as there are like-minded people out there working on Linux distributions and do the packaging for them to keep the repositories up-to-date, and so forth. If something were to happen to Linux itself (quite possible given recent developments), then someone might just fork (I am not a lawyer, so I am not sure about the legalities). We will see. I certainly hope that it will retain its philosophy; "closed app stores" are definitely not it. :/
People really have learnt the wrong lessons from the iPhone.
The iPhone launched without the AppStore. The AppStore was not the cause of Apple's success, Usability and Power were - in the sense that it allowed users to do more things (access the web from anywhere) with less effort (no booting times or ceremony). It was the first mainstream device that made it really easy to browse the web; that is what made it successful.
The AppStore was just a play to entrench that initial success by coopting third-party developers and ensure they could only sharecrop on Apple's land: "If you do anything serious with our platform, we get 30%". That's it. Nothing to do with usability. The AppStore is actually a terrible model from a usability perspective, because it collapses discovery so much that it does not scale. "Tap and run" could have been implemented as a web protocol without a centralized UI and it would have worked just fine.
The same is true of Snap. Linux does not need a centralized store, from Canonical or anyone else; that's just a play for them to get a pound of flesh from third-party developers. It has been tried so many times before in the Linux world, and it has never succeeded. Even Nokia threw a lot of money at it, and failed.
What Linux really needs, as you say yourself, is to make it easy for developers to guarantee integrity of their solutions once they reach the user. That's why Snap is getting some traction: because it promises to move power from packagers to developers and to make it easier to guarantee that a program will Just Work, without having to deal with the packaging vagaries of this or that distribution or risking that an overzealous maintainer will "improve" your stuff with crippling patches.
If Canonical were sincere in their attempts to make Linux succeed, they would concentrate on that side of things and drop the AppStore shenanigans. But that's not what they are really after.
No, but that's probably because I've grown up in the wild west of the '90s, where apps lived or died on their reputation. Any betrayal of users' trust would result in immediate removal and condemnation.
Also, it's not like modern developers don't sell users down the river. In fact, that's one of the very few sustainable business models that the AppStore forces you to have.
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.
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.
> 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?
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.
There are a lot of things a metal lathe can do that other tools can't. But that doesn't mean a lathe is a good tool for everybody. In fact, it couldn't possibly be, because there are trade-offs between usefulness and safety. You just can't make a lathe that's safe for the casual user but useful to a professional user.
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.
Who says it needs to be? What if what appeals to Linux desktop users is precisely what differentiates it from the mainstream?
Snap is regressive. What we have now works better, faster, lighter, and more secure. No, you can't have a convenient means of shipping your proprietary electron 10G garbage monster to end users. We don't need it to be "mainstream".
Sandboxing is a laudible goal but curation is more likely to result in a system that isn't pwned in the context of current sandboxing being at present being vastly insufficient to contain real threats.
I'm not sure in what fashion flatpak is behind snap given that the former supports custom software sources served over simple existing servers, local and offline installs, runtimes, fine grained permissions via portals, and turning off automatic updates.
>A lot of people are mad at Canonical for not open sourcing the backend but no one seems to be offering to build one.
This is a very strange defense to a legitimate criticism. In what universe would anyone on earth offer to spend their own time to fork snap and write their own backend instead of using flatpak, appimage, apt or 17 other choices.
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.
This was done 19 years ago. It was called Lindows. It came with a fancy GUI and custom packaged applications using a private app repository. Wal-Mart sold PCs pre-installed with it. I bought one.
Needless to say, that was not enough for Linux to go mainstream.
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":
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.
> 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.
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.
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.
> 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.
> 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.
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?
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.
> 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.
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.
>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.
> 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.
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.
> 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.
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.
> 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:
> 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.
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.
>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?
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.
>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.
> 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.
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.
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.
> 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.
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.
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.
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".
> 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.
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.
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.
>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.
> 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?
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.
> 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 ...
> 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.
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.
> 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?
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.
My point was only that I expect an company like Canonical to not just open source everything, but to design it in such a way that it is useful for third parties.
To make the distinction with "open source waste", where companies Open Source the software they no longer want, maintain or monetize.
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.
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.
Ubuntu provides Java the same way as Debian does, enabling applications to run with any compatible Java implementation. There is one version which gets pulled by default, but you can totally switch to a different one.
Oracle Java cannot be packaged or used in any but personal setup, and there’s no need for it these days when OpenJDK is the official Java implementation.
> 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.
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.
>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.
> 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?
> 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.
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.
In previous versions of ubuntu, that package would install chromium, as one would expect.
In recent versions of ubuntu, this package is a stub that installs snapd, and then snapd installs chromium.
There is a substantial difference between those two things. Users that try to install chromium through an open package management system are being pushed to Canonical's proprietary store.
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.
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.
If you keep breaking the site guidelines, we're going to have to ban you. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to the rules when posting here?
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).
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.
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.
That "little haskell-ish 30 line script" gives you a stable and reproducible system that other distros can never provide. If I can spare myself from doing a clean re-install of my system every few releases just by writing a few lines of configuration, it's absolutely worth it. It also helps that I can reuse that configuration for any of my computers too, because I don't have to spend time installing and configuring software for each new computer I use.
BTW most people don't need to write a full-fledged "script" to get their system up and running. All they need to specify are some configuration variables that specifies the sort of things you'd need to specify anyways if you're going to setup a new system, like which packages should be installed. With NixOS, you write those things on a file instead of typing it on the command line.
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.
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.
> 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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
> 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).
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.
> 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.
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.
> I mean that Chromium wouldn't work at all because it wouldn't be installed following an upgrade
Because you don't ship it as a normal package any more, which is caused by you. Calling it something you did "for the users for the sake of not breaking it" is really rather nasty.
> 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.
Oh I disagree with both, there's no conflation there.
> Chromium wouldn't work at all because it wouldn't be installed following an upgrade
I am not an expert in apt/deb, could expand on this part?
Is this a problem due to Canonical not offering a chromium deb or is it something that was already happening before? (like chromium requires many libraries to be of specific versions and if you pin them in apt then sometimes it is impossible to install any version)
I think the LWN article misunderstands what Ken VanDine meant by “pressure” in the following quote:
> By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.
The article takes the quote to mean that “Canonical … is using [Snap] to apply pressure where it wants to see change” and implies that Canonical is trying to pressure distros like Linux Mint to support Snap. But I think VanDine meant only that using Snap in a high-profile package puts pressure on Canonical to make Snap easier to use in Ubuntu.
That’s a less controversial goal than the one implied by the article. Of course, whether Canonical’s actions are truly motivated by that goal is a separate discussion topic.
I've been wondering for a while whether the concept of "open source" and its connection to freedom are becoming meaningless.
Source code has been a dynamic thing for a while, and I think that's part of the reason the GPL (at least v2) is not very popular any more. I mean, nobody really even wants source code, it's just a maintenance headache.
Even after complexity started to take over, there was still the argument that you could audit your computer if it was doing something funny, or ask a different company to maintain it for you, instead. But that seems less and less practical as time goes on. The company that wrote the software is really the only game in town to keep it useful.
Snaps are a logical extension of this phenomenon. They cross a line in the sand, perhaps, but basically just continue a trend already going on.
Also, the unix security model seems fundamentally bad. The idea that any code you execute can delete everything in your home directory is insane. It imposes a huge burden of trust on your software distribution system for the most trivial things. That reduces the practicality of using third-party sources.
I'm not really defending snaps and I will probably avoid them as long as I can. But I sort of feel like the battle might already be lost.
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.
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.
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.
Just to add a small anecdote to this: what primarily caused me to switch distros in the past was encountering problems I wasn't able to solve. Over time these problems would build up to the point where using the distro became a series of constant annoyances. Not so with Arch. Sure, some of the reason why this is the case is due to Arch just being a great distro (hence the meme), but I think the biggest difference is just due to the simplicity of the architecture making it possible for you to be your own sysadmin, if that's what you want to do. In about 7 years of using Arch, I haven't encountered a single problem I wasn't able to solve.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
It just another bad move from Canonical in a long list of terrible failures, which weakend Linux fundamentally:
* Upstart vs Systemd
* Mir vs Wayland
* Snap vs. Flatpak
* Unity vs. GNOME and Gtk
* Ubuntu Phone vs. you should have teamed up with Nokia and Maemo before...
Looks like they don't learn. The fork and fight against the others and always lose.
Nowadays Ubuntu is upstreaming usefull patches to GNOME, again. Thank you! But imagine what GNOME and Gtk could be look like already, when Ubuntu had "helped" them earlier. I could be already a lot of better years ago? Mutter, Gtk, Terminal and Nautilus. GNOME is healthy! But they could so much better years ago.
Forking is good thing, when it aims initially for a merge.
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.
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.
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.
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.
Worse. Because when you then search the "software store", and install chromium, all your bookmarks, history, forms and other state is lost. At least the "apt package" migrates that for users.
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.
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.
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.
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.
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.
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.
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.
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."
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
It's open source. In a way the linux/GNU initiative has won, because they finally have hardware manufacturers and large companies developing source code in an open way.
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.
I've been using it for a few days now, and it's solid. My personal laptop is getting older, so it's hard to comment on perfomance, but i was able to install a steam video game "path of exile without touching the terminal or file manager.
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.
Between VLC, Snap and Ubuntu I'm seriously considering installing Windows - last time I did was Windows 98.
Given up trying to compile VLC thanks to usual the usual python mess (ImportError: No module named 'nasm')
VLC don't bother distributing debs any more, just these shit snaps.
In years gone by distributions used to do a good job of keeping systems healthy.
They no longer seem to care about the old way of doing that though, things like debs and make just aren't cool any more. Instead you have 160 different package managers all fighting each other, which you then install to update your build environment to install another package manager to build a new build system to eventually dig down to generate some shitty python crap which runs a gcc command.
For me, flatpaks are a better user experience in just about every way. The one feature they are missing is that there is no equivalent to the snap --classic confinement. That means that for applications like vscode the flatpak experience is very poor. You cannot easily access command line tools from the editor. For instance using the anaconda python distribution from the vscode flatpak is a pain.
> The problems with Linux Mint came to a head when Ubuntu moved Chromium to Snap distribution in Ubuntu 19.10. On the surface, that isn't a problem in and of itself — the Linux Mint project can always start providing its own Chromium APT packages. 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.
I don't have any issues with this behavior. I find it really annoying when I find a package I am looking for on apt and install it, only to realize that it's way out of date, and I'm supposed to install it via snap or some other means to get a reasonably up to date version. Pointing apt at the snap store is a nice convenience in my opinion.
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.
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.
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.
> 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.
The only reason to go on that forum is to ask for automatic permissions. If you do not do that, then it's your users who have to give you that permission.
yesterday I finally decided to investigate why gnome-calculator was so slow at starting up in my ubuntu-based xfce desktop.
It's a snap. instead of just launching a stupid binary (it's a f-ing calculator for christ's sake) somebody decided it was better to use a snap, mount a filesystem, add a cgroup and everything.
For me that was the last straw: I eradicated all the snaps in my system, uninstalled snapd and everything gnome-related that I could. Jesus christ.
Again, it's a f-cking calculator.
I don't need a snap for that.
That's what get people hating snaps.
For the record, I'm now using xcalc. It's less pretty but it starts IMMEDIATELY.
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.
> "snap vs flatpak vs appimages once again shows the fragmentation within the linux desktop ecosystem."
A common misconception about the FOSS ecosystem is that many similar projects is "wasted effort". In reality, diversity is what allows for progress and flexibility. Otherwise you end up with a single package manager which nobody can change AKA mono-culture.
> "Microsoft is going to eat Linux Desktop. WSL to run your server apps and coding environment. "
Only if Microsoft make their OS free, otherwise you're buying windows to run a translation layer of Linux (WSL) on top of it... doesn't make sense to a lot of people...
> A common misconception about the FOSS ecosystem is that many similar projects is "wasted effort".
From a developers and users perspecive, it is a wasted effort. Users still keep wasting time 'choosing' a distro. There's 1 form of Windows and macOS to choose and support. For a software vendor, you need to 'define support'. I can support all Windows and macOS users, but I can only target a certain amount of Linux users on some selected distros which isn't all Linux users.
Perhaps the reason the Linux desktop has failed is because of the lack of a standard desktop or common SDKs other than the Linux kernel itself.
> In reality, diversity is what allows for progress and flexibility. Otherwise you end up with a single package manager which nobody can change AKA mono-culture.
Just look at the tons of distro configurations that a software vendor needs to test for which is why many companies place some Linux distros as under having 'unsupported' status and have to target a select few, unlike Windows and macOS.
> "From a developers and users perspective, it is a wasted effort."
My point is that, the perceived "wasted effort" is actually learning and re-thinking the desktop. Many novel approaches to simpler OS's and package managers have risen, due to the diversity of the FOSS ecosystem.
Just like Darwinian evolution, many projects spawn into existence, only the fittest survive. The projects/distro's that don't survive were not a waste, they serve to prove which ideas work/don't work. Making all projects better off.
> "Just look at the tons of distro configurations that a software vendor needs to test for"
True there's many distros, but there's no reason to support them all, only the biggest. It's similar to translating books into other languages, you would translate a book to [1] Dumi, as it's the least used language on Earth.
Most Vendors only support the top OS's which are probably Windows, MacOS and Ubuntu.
> "Perhaps the reason the Linux desktop has failed is because of the lack of a standard desktop or common SDKs other than the Linux kernel itself."
This is a real point, and is something snap, flatpack etc. are trying to fix. Maybe one day a Linux desktop will unify on a standard...
Lately i've been using flatpak to install many applications and then `flatpak-override` to remove any unwanted permissions from those apps. Usually i try to completely sandbox them by only giving them access to a specific folder on disk.
However, here on HackerNews i've seen many articles about how "flatpak is dangerous" lately. Is there any real concern? If yes, what would be another option? Appimages? I definitely don't want to rely on snaps now...
I did find it particularly annoying when I upgraded to Ubuntu 20.04 and seemed to duplicate applications. Adding a snap version side by side with my old applications.
Actually Canoncial employees claim that many things claimed here are false. I.e., you can set up your own back-end and you can set-up proxies of to block/allow snaps that from entering an organization. You can also provide patched snaps that are presented from a store proxy that are not visible outside the organization for example.
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.
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.
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.
When I removed snapd from Ubuntu, all installed snaps and their mount points still remained. Then I reinstalled snapd to remove the snaps. I could not find a command to force remove a snap if other snaps depend on it. So I had to delete each snap one by one manually, taking care of dependency tree.
Anyone using Snap to get more up-to-date versions of packages might be interested in trying out Guix package manager on "foreign distro". Has a lot of free (as in freedom) software in latest or close to latest versions ready to install and I find myself using it more and more.
Hate snapd. Statically linking every dependency is a step backwards, I don't need to have duplicates of common shared libraries in every binary. It's the first thing I uninstall with Ubuntu.
> 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.
> ...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.
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.
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?
Snap isn't too bad, at least Ubuntu are trying to make it easier for new software to run on older machines... they might even swap it out if they get enough backlash
I've used Ubuntu since 2014 and have been impressed at most of the decisions they've made, mainly:
- [1] Sticking to 6 month release cycles. Any features not ready, go into the next release. (Windows copied this, but constantly miss release dates)
- [2] Trying Unification of all applications, across desktop and mobile OS. But abandoning the project when it became clear it wasn't working.
- [3] Trying their own desktop manager Unity, then abandoning it when everyone was complaining and focusing on better Gnome integration.
I especially like how they try developing a technology and if it's not working or being adopted/liked, then it's abandoned by the core team... which is better than focusing on hated/dead technology...
> 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.