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

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

I would suspect that it’s 3rd party, non transparent snaps that present possible security issues, hence the need for confinement.

@coeur-noir +1 : for servers, IoT, developers, snaps are useful, but for Desktop (users) not (at least for now).

And even from Ubuntu, it has always been said that snap would not replace completely deb, the last one 4 months ago :

https://news.slashdot.org/story/15/09/06/196249/shuttleworth-says-snappy-wont-replace-deb-linux-package-files-in-ubuntu-1510 : Shuttleworth said that Ubuntu users will still get access to an archive of .deb packages.

https://itsfoss.com/ubuntu-snap-replaces-apt-blueprint/ : Alan Pope (Canonical) “All of this said, we do actually have an awesome “all snaps, no debs” version of Ubuntu called “Ubuntu Core” - and it’s been around for a while now. It targets IoT and devices, rather than desktops though. Not the same thing.”

But now Chromium is no more available as deb, so what to expect ?

1 Like

Mmm… then it’s a « problem » brought by snap ( easily packaging proprietary software ) and in the same time half solved by snap. Why not. « Half solved » because, hey, still it’s proprietary so who knows ? You have to trust the software editor then, it’s just moving the trust cursor.

But in my apt/deb world, where I use official repositories from my distro, where is the threat from 3rd party ? They are eventually « curated » in partner repository, or in universe ( I think, ie. nvidia drivers ).

Thinking about ppa maybe ? Some are very trustable. Some provide so many packages they can break dependencies. All are meant to be used cautiously and not aimed at primo beginners - I mean you first have to apprehend how apt and deb work to use them cautiously.

Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.

Here I totally speculate ! And myself could be interested in purchasing some industrial grade proprietary jpeg2000 encoder… at the end, wouldn’t that « lesser » the FOSS effort towards desktop app’s ?

( sorry for 2 answers, can’t we edit posts here ? )

Do you imply that FOSS snap do not need to be confined - then why it’s not the default behavior ?

None of what I’ve said is provided out of the box with apt/deb, and they can only be done in ways that are way to much complex for most non-technical users and in some points they require more work, and some things are simply not available with apt/deb, like the possibility to isolate dependencies, app confinement at the level snaps provide, the possibility to use the same package on other distros (including those that don’t have apt/deb) and different versions of the distro (same package will work on old and new versions independently on how it was built…

This example of the chromium really shows that unless snaps or other similar format was used, applications would have to be sometime very heavily patched to work on older versions of systems to the point that it generates so much work that it would not be worth do to it otherwise, or at least not worth when the snap option exists and doesn’t require that much more work.

Storage is not an issue, I’ve explained why it’s not. There could and should be improvements on that area, but this is not a relevant issue. Progress is made of compromises, this implies that we have to consider not only disadvantages, but also the advantages. Advantages do very clearly outweigh disadvantages. This doesn’t mean it perfect, or that work shouldn’t continue to minimize and reduce the disadvantages, but just considering disadvantages is not the correct way.

The benefits for developers do reflect on benefits for users, with more software delivered faster and more securely.

1 Like

I don’t think he implies that, he didn’t mentioned FOSS or non-FOSS. Third party doesn’t refer to licensing, only to who provides it. However there’s more benefit of confining proprietary closed source applications, because they are to audit to the same level, but that doesn’t mean that confining applications is not a benefit also to FOSS applications, security is an issue that needs to be addressed with many layers of measures no mater what licensing approach you use to license the software.

1 Like

The software installed with Snap is slow, so it is not acceptable.

we must continue to use deb packages for all software

The first launch is noticeable slower, after that you will be pressed to do a formal benchmark because, even if snaps were slower as you say, that is not immediately perceptible. Once snaps become pervasive this first launch issue will be irrelevant anyway, probably part of the session startup.

2 Likes

I disagree with this post! :smile:

Ofc snaps have their rough edges that need to be rounded but overall they are already the best package. Auto update and channel switching are my favourite features.

When I need to say something negative the ugly-cursor-bug in webappsnaps comes to my mind!

But imho snaps are ready enough to replace app debs

4 Likes

@frederik-f
Would you be willing to do a test for me please.
In your company you buy a new computer. You do a demonstration in front of the staff of the installation of Ubuntu. Awesome. In front of all these people, you launch for the very first time the calculator or vlc or other snap. More than 20 seconds. What are people going to think about? They will choose this distribution. Will they be ready to follow you for their daily work? Would you be ready to make this presentation? I do not believe. It’s not very serious :slight_smile:

1 Like