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

Hi,
We are several members of this community who wanted to share this concern. SNAP technology is not yet ready for us, simple users.

15 seconds to open a calculator is not acceptable for a so-called modern distribution. It is an obvious loss of productivity.
Ubuntu is our main distribution, but it can not be considered that the main applications like chromium, libreoffice, vlc… will become much heavier than on all other distributions. it will be a huge regression for all users

As we like Ubuntu, please, why not simply postpone this transition (calculator, chromium) while waiting for improvements to the snap system?

7 Likes

I agree with you.

Snaps should not replace deb, it should simply remain a possible alternative but not the main package system.

Imposing snaps is a bad idea

Chromium browser must be proposed in deb by default and not in snap package.

Linux Mint for example integrates flatpak but it does not impose any software installed by flatpak

You should replace the calculator also by the deb package

1 Like

I also agree with this !

If Ubuntu wants to propose some apps with snap as default, it’s fine and no problem if the deb package remains available and snap can be uninstalled.

But yesterday on 19.10 we got an update of Chromium saying that up to now, starting with v. 75, “all new releases of Chromium are only available to Ubuntu users through the snap package” ! :fearful:

This is unacceptable and a very bad idea, as deb packages are well used, performant, secure.

As a user, I always switch to earlier development branch of every new Ubuntu release, and also use many ppa for beta softwares, so I absolutely do NOT need snaps to get up-to-date with OS or programs (I never have more than 6 months old versions).

Snaps take lots of place as each of them brings the required libs, and every first launch of a snap application is painfully slow.

If Ubuntu’s aim is in a near future to drop deb packages and only support snap, this would be a huge mistake and for the first time since 2006 I would have to change of Linux distribution.

So please reconsider this and make Chromium (still packaged by Debian) available again as deb (with snap removable) - and same for all other softs.

1 Like

It seems to me, to be a done deal, and I agree with the reasoning behind it.

No doubt you’ve noticed that Ubuntu laid of desktop staff, last year (or might have been 2017)?

Snaps and Flatpak make it easier to update packages with a lower overhead labour metric. So, with a reduced staff, this makes the workload easier to manage. For us, the end user, it also gives us newer packages, without waiting for a major distro release to have them.
I don’t work for Canonical, so all the foregoing is just MY opinion, FWIW.

3 Likes

I’m not developer, so it’s a real noob question : is it a huge work to adapt Debian packages to Ubuntu ?

See this thread from last year for an insight into why Chromium is the first desktop application to be delivered to Ubuntu users as a snap only. Trusty is now EOL but presumably Xenial will be similarly affected in due course if not already.

Resources, voluntary or paid for are always limited so I have also come to accept, somewhat reluctantly, that the inclusion of snaps in Ubuntu releases will no doubt increase in due course.

5 Likes

A little benefit compared to the flaws snap bring into « average » desktop usage.
⋅ confinement somehow forces user to change their data organization,
⋅ slow ( first ) launch, still a bit slower launch after, much much slower on non ssd setups,
⋅ waste disk space,
⋅ often theming issues

Ok, we all know why snap are more a gain than pain for developers. Using Ubuntu at home and at work for ten years did not turn me into a dev’ - and my job so far does not require me to be a dev’ ( although linux is very present in my area ). Users want work be done. Not struggling about how allowing access to removable medias or such a file on another partition… Not breaking their habits or workflows each time a snap replaces a deb.

Snap in themselves are not bad - but for a smoother UX they require a « wider view » about how people use their computers. I’m afraid this kind of broader thinking also needs resources, voluntary or paid for. Like say ergonomic or UI design.

Going the all snap route now sounds dangerous : how test any and all use cases ? Why pushing snap so strongly when basic flaws for users are not solved ? And above all what is the meaning of LTS if it’s used as a testing bed for a non mature technology ?

Snap for the moment covers none of my needs as a desktop user while .deb do.
Safety ? How am I not safe using .deb ?
Newer versions of app’s ? Reliable app’s and workflows first matter in any « intensive » context.

Get back to Chromium : how its evolution will be handled by Debian ? How its cousin-sister-child projects will be handled ( vivaldi, brave, electron… ) ?

2 Likes

Hello
I do not find it normal that snaps be proposed by default in the logitheque,
These snaps are unable to see files from other disks and are very long at boot time
They should be a help when the .deb equivalent does not exist
if they were to generalize in the future without improvement, I will consider adopting another distribution.
I’m not against their presence in the logitheque but not by default
Thank you

3 Likes

The “no-snaps” ship already sailed years ago…you folks missed that boat. It’s too late to wish for a return to the past. Snaps in Ubuntu have been happening for years already, and will continue regardless of any opinions expressed here.

If folks want to get together and create a snap-free remix, you are welcome to do so. Ubuntu thrives on such contribution and leadership by community members.

Do be aware that you will be retreading territory that Ubuntu developers trod in 2010-14, and that you will encounter some of the same issues that led them to embrace snap-based solutions. Perhaps your solutions will be different.

.debs are not perfect, snaps are not perfect. Each have advantages and disadvantages. Ubuntu tries to use the strengths of both.

7 Likes

Moreover, due to the confinement, snap does not allow Chromium to download by default in another folder than /home : “it won’t let the application see files on the host system (save for a few exceptions, like $HOME)”.

Is it a definitive point for snap ? If yes, it means that when all apps will be converted to snap without possible backport to debs (if installed without --classic and perhaps excepted Nautilus), it will be impossible to save files issued from them elsewhere than in /home ? Absolutely all my datas (documents, music, videos, photos) are on other partitions, this would be prohibitive…

@ian-weisser : I’m not a dev either, so no Ubuntu fork, but I will perhaps be forced to look at Debian testing, without some advantages of Ubuntu - but now that Unity is gone (and I deeply regret it), gap would not be so huge anymore…

Only folks who help package Chromium get to decide how Chromium gets packaged. This gives anyone two options: You can get involved and help package Chromium so you have a voice in the decision-making, or not.

Personally, I think you are perhaps blowing up a fairly medium-sized (and fixable) bug discovered during routine testing into extreme-case hyperbole. Again, engagement and participation will get the bug fixed faster. The entire point of testing is to discover and fix precisely these kinds of pain points before release.

6 Likes

We all know that ubuntu will use SNAP. It’s too late to go back.

The point here is to say that SNAP is not ready YET.
How can you work when an application take a long time to open? even a calculator.

On the first opening of writer, i do not have ssd, i have time to drink a coffee when with a deb i can work.
Use snap only when it will be as effective as a deb.

We must think of the users more than the technique itself

2 Likes

I disagree with you, I love snaps and usually use them if they’re available. And there’s no transition in course, snaps are not here to fully replace deb packages.

1 Like

I totally disagree that there’s little benefit, snaps have many benefits that are huge:

  • automatic updates
  • List item
  • shorter delivery times between develper and user
  • possibility to use tracks and choose how much on the bleeding edge you want to be
  • way more security and privacy,
  • less dependency issues
  • software available on the same versions independently of distributions and versions of distributions

Disk space is generally not an issue, not only disks are cheap, but snaps are compressed archives, and they can re-use some special snaps of common dependencies. And this strategy allows the advantages I mentioned above, developers won’t have to worry about which distro or version they’re targetting and this will bring us much more software as it already did.

Snaps provide more security, the confinement they have is way more secure than what we have by default with any deb package.

4 Likes

So far this is only for trusty, that is very clear on the post. And this is due to sound technical reasons, not a policy reason. People are freaking out about nothing.

2 Likes

No, the transition to a snap for Chromium will be for all supported releases as per the call for testing post: Call for testing: chromium-browser deb to snap transition.

Well, take a look at other snaps, and install them like odio. Then run them a few times and set them up. How long does it take once you get it used to your feel?

And for the calculator, the libraries have to load, and when they are part of your memory, the Snap is an independent application, so it has to load everything.

Snaps load slowly than .debs. I’m not going to use snaps not to get angry with Uhuntu.

I had one issue with snap and that involved VLC but I can see how it would lead to issues with other packages. I hav the libdvdcss2 package installed to allow me to watch DVDs on my laptop. The snap version of VLC was not aware of that and wouldn’t play the DVD. I had to uninstall the snap and install the .deb package. Just one example, but I know there will be others. Due to the quasi-legal nature of libdvdcss2, I doubt it’ll ever be bundled in a VLC snap package.

2 Likes

Most of what you mention may already be achieved with « legacy » apt/deb, from the user point of view.

What is the security issue for desktop users under apt/deb, that gets solved with those new packages ?
Aren’t main security concerns solved by wayland over xorg ?
I clearly understand why snap is a safety progress on server and IoT but in my « human » usage snap is just restricting how I use my data and computer.
Adding layer of settings and complexity for the end user might also bring bad practices to keep a comfortable use of app’s by installing snap without confinement…

Disk space is an issue. Resource usage is an issue. Those new packages nowadays need huge amount of storage to finally do the exact same thing as their older and lighter deb counterpart. Whatever the price of storage, it’s the opposite of a progress, it’s not optimal at all.

I - we all - totally agree about the benefits of snap for developers. But the loss of comfort and flexibility for end user is eventually a no-go option. What’s the use of ie. snap libreoffice if it can’t access documents on a samba server in my workplace ? Should I really re-organize years of storage and work in my office for being able to use snap ? A too high price to pay, for the moment.

@ian-weisser I totally understand the need for testing. I’m really wondering what will happen in already « working » context. And I must sadly admit I’m afraid it will imply much time and work for people on both sides ( end users and developers ) just to keep the same boat floating without immediate or « funny » rewards at the end. And Unity ditching for something that’s still not on par with it, had already broken a bit my trust in Ubuntu as a stable option at work. Now snap is coming closer and broader…

3 Likes