Snaps are experimental stuff, created not thinking of desktop users, maybe good enough for IoT, where one specialised app would only be needed. Btw, who cares for desktop users these days, after all?!
How long does the Calculater snap takes to start, and how long it takes to start the old fashioned, Debian like deb calculator app? A simple app, after all.
The Calculator-snap is not snappy!
The container is making it late – something else has to start for it to start or something like that. @popey
You feel that lateness. Snaps are not ready…yet.
Be assured I understand the problem more than you realise. My team has regular meetings with the desktop team and the snapd teams. We discuss these issues very frequently. However, without specificdata it’s very difficult to fix anything. It’s incredibly frustrating to be told “This is broken” with no usefulactionabledata to back it up. If you said to Mozilla “Firefox is slow” you’d be requested for more data. This is no different.
I will personally advocate for you and others to the Ubuntu Desktop team and snapd team, but I can’t do that without something more than “snaps are slow” or “snaps are rubbish” or “snaps don’t work” because that’s useless to everyone.
Not quite true. There are a number of AUR -bin packages which use the prebuilt binaries provided by debs or RPMs. However, there are from-source versions of the same software also available.
That’s true but, having used Arch for about ten years, my experience is:
Building from source complex packages in the AUR drags lots of from-source build-time dependencies from the AUR itself and the chance of a happy ending significantly decreases.
When the “complex packages” are binaries in the community repo, they tend to be outdated (at least comparing them to third-party PPAs or snap/flatpaks). Also, I’ve had experiences with broken dependencies in complex community packages (for example, mismatched electron versions).
That said, nobody is to blame here, it’s amazing what Arch has achieved with little resources but VERY SMART design decisions: close to upstream, rolling-release, few target architectures, simplistic packaging with centralized user repository, excellent documentation. But the problem Ubuntu faces is very different, it’s not a system oriented to tinkerers and power users. And, as I’ve already said, that Arch sometimes excels at providing a common packaging interface around stuff prepackaged as deb/rpm/snap/flatpak depends, well, on these things existing in the first place. But, by all means, with this I’m not saying Arch is free-riding Debian nor something remotely equivalent!
That’s entirely beside the point. There is this rhetorical device named quoting (exemplified above) and you have misused it, that is to say you have misquoted me. You could have just fixed it instead of trying to justify the unjustifiable.
What’s the point of insisting on the first-launch benchmark? It was acknowledged many times, even in this thread, that this is a shortcoming of snaps. Once you agree there are more advantages than disadvantages, repeatedly mentioning the disadvantages won’t outweigh the advantages. And if you find the balance negative, provide a new argument in order to make the discussion advance.
This is problematic for all Ubuntu based derivatives. For example pop_os doesn’t use snap at all. How can I keep using chromium-deb on pop_os or are we now forced to use snap ?
I have bunch of snap application installed (Chromium, Firefox, Brave, Skype, VS Code, Spotify to name a few) as of this morning all of them opened up super fast. Which is great and surprised me.
Hey there, sorry but that post happened during the weekend and I’ve only been catching up with it now, Í’m going to reply as a Ubuntu Desktop Team member on what we are doing and why, hopefully removing some your worries.
I don’t think such statements are helping the conversation, at the contrary they are creating fud against opensource projects, hurting the reputation of new technologies that have potential and damaging free software on the long run.
I know it can feel that the developers are dismissing the problems when they ask you to report specifics but that’s not the case, we just need to understand the problems properly to be able to work on them.
SNAP technology is ready for simple users. Try enabling livepatch on Bionic LTS and I bet it will “just work” for you. It’s a simple system component which bring better security, gets auto-updated, doesn’t get in your way, isn’t big or slow.
You could word your messages differently and say
some of desktop snaps are slow, for example gnome-calculator
desktop snaps still have some integration issues (e.g theming)
the isolation which comes with snaps (and other technologies like flatpak) can create problems for components that need to interact with files or other system components
Those statement are all true, desktop components are more challenging to get working correctly and we still have work to do.
You can probably also add
the packaging of some the snaps is buggy
But to be fair that’s also true of some of the debs and not a problem with “snaps”, just that those packages are newer so went through less testing/fixing/stabilization.
Be re-assured, we know about those problems and we are working hard on resolving them.
We don’t plan to onboard on migrating stacks of debs to snaps and removing the debs (at least not until we feel confident snaps are ready for that, which we agree is not the case yet)
Now as mentioned in the previous comments, chromium is a complex project and difficult to maintain. It’s also a webbrowser so security sensitive, which means it’s a component we need to keep updating on all supported Ubuntu series.
It’s not even our default browser in Ubuntu, but yet to keep up with security updates on all series (which often ends up requiring things like backporting of new toolchains) it costs us almost half time of a paid engineer, which is a pretty expensive in resources for a small team like ours.
Now it’s easy to state that $company should be paying to keep investing lot of money to maintain a product you get for free but that’s neither fair nor work out (the company is going to get bankrupt and you will get even less in return).
So yes, we need to reduce the maintenance cost for chromium. We could simply delete it from the archive and tell users to get it from a ppa or Debian and make clear we are not the ones supporting the maintenance cost. That would be letting our users down though and we believe that’s not right. We do believe though that the snap solution will allow us to keep providing it our users with high quality for a lower cost and is the right thing to do.
We don’t plan to delete gnome-calculator or other debs at this point since those don’t have that maintenance cost problem.
Yes, agreed that the gnome-calculator start time is a bit embarassing and that we need to get it resolved, it’s on our list
What do you mean “heavier”?
Taking the chromium example, as state on the other topic, the snap is smaller than the deb!
Yes, gnome-calculator has a start time issue but GNOME snaps have specific constraints that don’t translate to e.g chromium, vlc, libreoffice. Please back up such statement with fact so we can work on the issues (when they exist), otherwise it’s fud and just damaging for Ubuntu/our communities/free software.
The calculator one has been done in 17.10 so it’s nothing new. It’s about time we deal with the startup issue though you are right.
Chromium we need to migrate for the reasons explained before, and we do believe we can get it working well enough that most users should be just fine with it.
We don’t plan to migrate other desktop components at this point.
One point which is also dismissed when you state that snaps don’t provide anything over debs is that for a decade a class of users have been asking for newer versions of software on their stable LTS distro, snaps provide an easy solution to that.
The use of ppa has been an acceptable solution for some users but
they are not obvious to find/enable
deb packaging is not easy which means the number of people working on providing software updates in ppa is rather low, you will just find a subset of packages that interest users there
some updates can’t be done in a ppa, for example when needing new system libraries (or the ppa needs to provide them, but changes in the library then could create issues/conflicts with other components from the archive)
Hi, thanks a lot for your reply and time taken to explain us in detail !
Maybe some of our posts were over-reacted, but some previous answers also tend to underestimate our feelings and were received as “look, snaps have many more advantages than the constraints you describe, they’re here so get used to it”.
So we have told our advice, devs heard it, now we have all to move on to improve snaps and the 2 main concerns - launch time and confinement restrictions for user (access to other partitions than home).
I very well understand the particular point of Chromium and that it took too many resources (useful elsewhere), and you reassure (as Alan Pope did) that no other deb would disappear until at least snaps are ready for daily use, so we’ll try to help with reporting bugs
Thanks, to you and everyone who provide useful feedback and actionable data in the form of bug reports.
The concern about the ability to save downloads to an external hard drive out-of-the-box without the need to manually connect an interface has been heard, I have filed a store request for auto-connection.
