@sibe39 You don’t need to keep repeating the same message here. It’s not useful to the conversation.
Looking at the thread you posted, according to Google translate the thread suggests that all software that’s snapped takes 3 minutes to load. This is just factually not right. It’s certainly right that on first launch some snaps can be slow to launch, and faster on subsequent launches. We are actively working on improving that. But to say all snaps take 3 minutes is frankly, a lie.
You’ve repeatedly said “It’s not ready” and we shouldn’t ship snaps. You know what helps make things ready? Testing, and reporting actual bugs with actual data.
Rather than blindly telling people to remove the snap and install the deb, it would be considerably more useful to gather specific information. What snap are they having problems with? Does it only happen on first launch? What version of Ubuntu (or other distro), and snapd? etc.
Just saying “it’s slow, use the deb” won’t fix anythingatall. If you want it to be better, help us.
What’s wrong with the .deb package, anyway? It is only needed to “install” the relevant files to the relevant places. There’s no .deb package anywhere in your installed Ubuntu, is there?
It is a different matter, if a snap is a self-contained file, and clicking on it it would run it by itself. It doesn’t do that, does it? It needs another app to run it. Snapd and lot of other files/folders are living in the root, aren’t they? I am all for self-contained packages that can be kept where a user considers safe to keep them, for example in my home folder, which I can keep even in a separate partition.
@chanath I think you’re missing one of the key reasons why we’re keen on snaps.
Chromium is an open source application, which has been packaged as a deb and is in the “universe” section of the Ubuntu repository. That means it’s “community supported”. Compare that to the Mozilla Firefox deb which is a default application on the Ubuntu desktop and is thus in the “main” section of the Ubuntu repository.
That means Canonical have a commitment to maintain the Firefox deb in the archive with security updates - because it’s in “main”. There is no such obligation for any package in the “universe” section. So you’ll notice that Mozilla Firefox gets regular and timely security updates. Universe packages are maintained by the wider community, which includes people who work on the various Ubuntu Flavours. Chromium is one of those debs. It’s not in main, so there’s no obligation to maintain the package, but we have done for some years now.
Every time there’s an update to Chromium, whether security or just a new upstream release, someone needs to ensure the new version builds. This is not a trivial operation. It’s not as simple as just changing one line from “66” to “67” and you’re done. There’s build failures to contend with, new dependencies, new compiler requirements and so on. It’s work and someone needs to do it. Right now, a Canonical employee is the main person doing that. They need to update the package not just for the 19.10 release currently in development, but all supported releases. That includes 19.04, 18.10, 18.04 (LTS) & 16.04 (LTS). That is a LOT of work.
Making a snap means one package which works on 19.10, 19.04, 18.10, 18.04 and 16.04. That’s a tremendous amount of effort saved.
The fact that a snap is a single file on the filesystem is a technical detail, and is a good thing. When you install a snap it’s a single file that gets mounted on boot. When you remove that snap, the file is unmounted and gets deleted. No files left lying around on the filesystem, it removes cleanly.
I am not talking about Chromium as a snap or as a deb.
Snap maybe a good idea, if I can take it and put it anywhere as a self-contained app. It is not that. It needs other apps to work and those live in the root.
Take for example web browsers; Firefox, Chrome, Opera or Vivaldi. I don’t have to install them in Ubuntu or any other Linux distro. Even in Windows. All I have to do is to download the web browser and unpack it and put it in a folder. (It actually unpacks to a folder.) Put it in my home folder and have a link to the exe file on the desktop, on the panel etc. They start up immediately. All those web browsers are self-contained. Once started, they create a user cache, which doesn’t get deleted, if you don’t delete them. The next time a new release is out, and if you want, change the contents of that web browser folder. Today, all web browsers are self contained, with maybe few additional files needed.
I have many web browsers, and none of them are installed. And, they can be run in any Linux distro. All I need is a link to the exe file. Many apps would run that way. Any Linux app that would be installed to /opt would run that way. That app can be placed in your home directory. Any app that “installs” itself to /usr/lib can be put into a folder in your home (LibreOffice). They are self-contained. Any app can be made to be self-contained, and without the “squashing” and still be safe to use. You, as the user decides when to upgrade or whether to upgrade. You are in charge, not another app.
(Btw, I use Opera most of the time, in Linux and in Windows 10).
Nothing snap is doing is stopping you continuing to do that. If you prefer to manually install applications in your home directory, carry on doing that.
How about making snap work like that? For example, a downloaded snap stays in a different partition and and a link to it could clicked on from any Linux distro for it to start up? And without an additional app snapd?
You’re essentially describing appimage. We’re not about to re-architect our entire software delivery and solution to re-implement something else that already exists. If you want to carry on using appimage, or some other system, use it.
Not exactly that, but also the way Ubuntu live iso is run (and installed). There too the whole root is squashed, and opened live with an app that won’t stay back. The app that installs came later, of course. In AppImage the idea is the same open the squashed set of files with a runtime. Those set of files are usually /usr/share, usr/bin, usr/lib, /etc and so on with the necessary dependent files.
What a web browser, Firefox for example, does is to have the whole set of files placed in folder somewhere (usr/lib) and put a link to the executive file. It is not squashed and opened every time, sort of wasting time at starting. When you squash a set of files, and need another app to unsquash it and then run, it takes bit of time. With the fastest processor, this might not be noticed, but not everyone has the fastest processors, so the time lap is noticed.
So, click on a link > run an additional app > unsquash the needed app > then run the needed app >> takes some time. And, this appears to be the problem of this kind of starting apps.
There are no debs installed in your Ubuntu, and when you click on the icon the needed app starts up bang (snappier). Click on the link > runs the exe app > app is on your screen.
There are plenty of alternatives for that.
For me snaps are not a bad thing, they just need a bit of polishing. I always remove my .deb apps in favor of snaps apps (Libreoffice, Firefox, chromium, gitkraken, text editor, VLC… just to mention a few).
For those who are always complaining about snaps how many ups have you tested or are just following the news and complaining?
My only concern is on metered connection, it shouldn’t allow updates when using it
My analysis is correct. When we have a snap app that would start faster than its equivalent app, I’d believe otherwise.
As for the 2nd line, we should end the discussion.
First, I am NOT complaining, and I never do.
Second, you don’t have a single (working) .deb app in your Ubuntu system.
You have files and folders, but nothing called a .deb app. The same way, you don’t have a snap app, only some files and folders inside a snap folder, which needs another app run them. These files/folders are not squashed (sorry, @popey not like in AppImage. Just reinstalled “snap” gnome-calculator to check) and they contain the same files and some other files in that folder.
Normally, when you click on the icon for the given app, it simply runs the relevant exe file in the /usr/bin. So, the app starts immediately. With the snap, the /usr/share, /usr/bin, etc are in the app folder in the snap folder and it takes some time for click to get registered, so the lateness. Maybe, the guys behind snap would find a way around this, and maybe one day the “snap” apps would boot just as the normal ones. There is some sort of a runtime app that’s slowing it up. At the moment this happens in the first time you boot your “snap” app, and every time after you reboot your computer.
A “snap” app would boot equal (in terms of time) to the normal app in your Ubuntu system, but never faster. If you are interested, have look at the folders inside /snap directory. Normally, a click would send a message to the file in /usr/bin, and now with a “snap,” it’d have to go to /snap > then to the named folder > and then to /usr/bin inside it. Maybe, even go through some other places.
(google translate)
I would just like to point out, that originally this post is not to judge the quality of the technology used for SNAP. Of course, I have no jurisdiction to say if SNAP is the best solution for the future of distribution, it would be pretentious. If investments are made on this point it is that it must be justified.
But it’s just the user voice that can only find that SNAP applications already installed on UBUNTU are longer now at first boot. It is therefore a regression to use. I know that the problem is already taken into account but not resolved at present, and I do insist on the word now.
Could we simply take into consideration the deployment of this technology to be postponed until the resolution of these identified difficulties of use?
If not, and if you think that this precise point will not be debated because the decision is irreversible, be free to block these exchanges
Thank you for all these exchanges that are still rewarding and that prove the interest we all bring to UBUNTU.
I’ve been looking inside the /snap folder and did a bit of experimenting. I found this exe file in it for gnome-calculator; /snap/gnome-calculator/406/usr/bin/gnome-calculator
I also have a little run program installed : gmrun. If I open gmrun and paste the above line (/snap/gnome-calculator/406/usr/bin/gnome-calculator) and click Enter, the gnome calculator opens immediately. The same happens by pasting that line in the terminal and click Enter. Bang, it opens.
The same happens, if I only write gnome-calculator in gmrun or in the terminal and click Enter. Bang, it opens. It points to /usr/bin/gnome-calculator. The result is the same. The theme is the same.
But, if I click on the icon that points to snap gnome-calculator from the app-grid, it takes certain time, and the app that opens has another theme. Something is slowing it to start,
Anyway, you can try this yourself and see for yourself. I will not comment on this matter any more.
Just do it. Nothing good comes out of these kind of threads except drama. Memplex made a much better thread (let’s hope the discussion does not get distracted again by some people like in this thread)