Please, do not use snap into UBUNTU, it's too early

Regardless, most people despise the idea of an all-snap desktop by default anyway, so I think Canonical please more people than they anger by not doing one :stuck_out_tongue:

That is, if Ubuntu would stay the most popular distro of the Linux world. Not any more and will not catch up with the rest. Mimicking Unity won’t help either. The other forum on the “development” issue had gone silent too. I am not going with slower apps, even if it is from Ubuntu. Which other distro uses snaps anyway?

This thread seems to have wandered deep into the weeds of irrelevant speculation about other folks’ motives and goals.

Let’s please stick with the topic, which is snap packages.

5 Likes

There’s no heart for that. I think Cannonical lost interest in the desktop around 17.04, or just before that.

It’s funny you said that of one of the only few companies that are actually paying wages to work on Linux desktop.

1 Like

Looks like we are going off topic. Anyway, heart and paying wages are two different things. Paying wages depends on the bottom line, but heart doesn’t agree with the bottom line, its attitude is emotional, rather than rational.

Back to topic; I’d been with all the experiments of Ubuntu since 4.10, went through all the heartaches/tummy aches of getting into Unity. I liked the idea of snaps at the beginning, but not any more. Maybe, its heart :slight_smile:

Both Solus and KDE Neon are at least planning to have snap support by default (might use them by default already)

That’s nothing. Solus doesn’t say anything like that. KDE Neon has other important stuff to look after than experimenting.

According to the snapcraft website, Solus has snap installed by default, if you install Solus 3+ and find that it’s not then feel free to update it by editing this topic. Snappy reckons that KDE Neon has it installed by default, again, please edit the topic if you can prove that it’s wrong (edit the topic and provide your evidence in a post on the topic).

Just because the distribution websites don’t have snappy front and centre doesn’t mean it’s not on there by default.

1 Like

What’s according to snapcraft website has nothing to do with reality. There are no other distros that would use snaps by default. Once, Arch dabbled in installing Unity DE as the only other distro, but no any other. It is the same fate with snaps, sorry to say. (Arch would give a wiki on anything that’s new and somewhat interesting.)

Anyway, I’ve seen the ups and downs of Ubuntu for so long, I can safely say that snaps would stay on the experimenting level on the desktop. No idea how it is doing on IoTs, but that’s another world. The snaps are not ready yet is the OP, and I agree with him/her.

Well, then it is probably time to move on to snaps :slight_smile:

EDIT: that said I really want to say that from a security point of view some apps beg to be snapped. All the browsers should be snapped, as do Wine and Steam. Each webpage could be considered a random, untrusted app. Wine and Steam open potentially unsecured closed source apps from small and potentially dubious studios. Those apps would be a great start. But please don’t split up the default desktop into snapped parts. That doesn’t make much sense and will hurt the performance. Thus gnome-Calculator was probably the wrong app to start snapping.

2 Likes

There is no debate, I repeat:
Deb packages should be privileged, not snaps.

Snap packages have more disadvantages than advantages, they should not be recommended.

If you want to offer software in a more recent version, offer a PPA rather than a Snap.

  • Snap is not really secure
  • Snap is not efficient
  • Snap is slow
  • Snap takes up too much disk space
  • Snap is not adopted outside Ubuntu and derived (even Mint based on Ubuntu doesn’t want it)

To have a debate, I want to address some of your points:
Snap is not really secure
What is really secure? Debs certainly not. In comparison a containerized package system is more secure than without being containerized.
Snap is not efficient
Why? I didn’t find any deficiencies other than being slower.
Snap is slow
That might be an issue with small apps but bigger apps will not be instant, regardless of Deb vs Snap
Snap takes up too much disk space
Well, let’s admit that it takes more space than debs or even flatpak. If only few apps are chosen that will not matter in the grander theme of things.
Snap is not adopted outside Ubuntu and derived (even Mint based on Ubuntu doesn’t want it)
That is a non-issue because it is up to your distro to provide most of the software to you. And they have to choose in what format they want to deliver. It is not that deb-PPAs and Flatpaks will suddenly go away just because Ubuntu ships some Snaps (they even do now). That Red Hat (biggest Linux upstream around!!) and SuSE didn’t support debs, didn’t kill neither Debian nor Ubuntu.

  1. Wine should not be used at all, for it is to run Windows apps, not Linux apps.
  2. You have to trust the web browser you use, and if you are quite worried, if some organisation spies on you, use the incognito method. I trust the web browser, but not the "snapped’ one, if there is one. I’ll never use it.

This is not always true, see, for example:

$ snap info 0ad
  stable:    0.0.23b-alpha 2019-06-11 (91) 949MB -
$ apt show 0ad-data
Version: 0.0.23.1-2
Installed-Size: 2,093 MB
$ snap info chromium
  stable:    75.0.3770.100 2019-07-04 (784) 159MB -

Deb size (I don’t have it installed):
amd64 75.0.3770.90-0ubuntu0.18.10.1 [Package size:] 60,145.7 kB [Installed size:] 216,708.0 kB

These snaps will likely take up more space in practice because the three most recent versions on your system are kept by default so that you can revert easily to the previous version if the new version doesn’t work on your computer (it’s not as simple as this with Apt/Debs), this is customizable, so I think you can just have one verson stored (the version you have installed) if you prioritize disk space over being able to rollback app updates.

The reason why these snaps are smaller than the Debs, however, is because the apps are stored as squashfs filesystems, rather than uncompressed. This is actually an improvement on how Debs work, if you prioritize disk space usage! On the other hand, more space is taken up if an app’s dependencies aren’t included in the core snap or a base snap (e.g. core18 or kde-frameworks-5-core18), since the app has to bundle these dependencies, but this is good, the snap knows that dependency version it is running on on any computer, and this can thus be tested and dependency version differences (as is the case with Debs, which need to run on the possibly different dependency versions between Debian, its versions, and its derivatives, and their versions) are no longer a problem because they’re the same on every computer which supports snaps.

1 Like

We talk about .debs here (sort of negatively), and so on. Do you find a package named .deb anywhere in your installed system? You don’t.

Download a .deb package and unpack it, well, twice, and you see files that are to be placed in different places, /usr/share, /usr/lib and so on. And, if you unpack a “packed” deb package and place most of the unpacked files in relevant places, but won’t place those that allow apt to change/upgrade, you have no worry. Apt won’t update/change, or place an additional file in.

Now, the apt “installer” would “unpack” deb package and the “install” those “unpacked files” in relevant places, if you use apt to install them. And, it doesn’t leave a residue, after “installing.”

A deb is a packed amount of files, packed a different way, the way how Debian became such a well known, well respected OS, the Universal Operating System. And, everything is here.

All I want to say is: Use the Snaps but do not mess up with Apt / Deb.

As I posted in the links below, transforming the Apt into a Snap wrapper is a HUGE mistake that will charge a big price very soon.

Snap is really a nice tech and it’s impossible to stop it’s usage. It’s really nice to think about a very compact and secure system with a small set of libs and Snaps to be a source of new apps. But if an app is not supported by apt/deb anymore just deprecate it and moves on, as it was done with Ubuntu 12.04.

Ps.: Sorry if someone already said that but i got here late and i don’t have time to go through all the messages.


1 Like

The toggles work fine but after enabling/desabling you can’t visually see the change on the software store. You have to go to CLI to see the change

I have opened a new thread to discuss more specific problems of snap desktop integration here: Some snap desktop integration shortcomings

2 Likes

Actually, don’t think snappy is an bad idea.
But it’s still a bit early for an LTS system.
Snap apps have some problems I can’t stand.
1, Ugly font rendering
2, Lack of 3rd party theme support
3, bad support of CJK input method.
Hope newer version snap apps can solve these issues.

1 Like

Currently, the biggest problem of snaps is their slowness at first launch. It’s really painful. This defect alone justifies not using snaps!

On the French forum of Ubuntu (I’m French), many beginners have software problems only because of snaps. Many do not understand for example why it’s slow.

For example: https://forum.ubuntu-fr.org/viewtopic.php?id=2041803

If you do not understand French, basically a user asks why the software installed with snap takes 3 minutes to start …

that’s why I recommend that Ubuntu developers do not activate a default snap.

I’m not saying that we have to give up this technology but it will be necessary that the snaps is just an alternative to install a software but not the main method by default.

So it is a big mistake to impose snap for Chromium for example, we must continue to propose the package deb.

Ubuntu is the only linux distribution that makes this mistake

1 Like