I did. Except it doesn’t work. Doesn’t use default theme. And it crashes for 32 bit.
If you’re seeing crashes, perhaps file a bug so it can be fixed.
1 Like
The System76 developers could maintain a deb of Chromium in the Pop! OS repo as they do for other applications which they ship and support.
4 Likes
Try to install the 32 bit debs that goes into the snap separately from here. Maybe, you would be able to get Chromium going. 
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.
5 Likes
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.
12 Likes
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)
4 Likes
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 
3 Likes
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.
4 Likes
One major problem with migrating deb packaged software to snap packaged is the lack of ability to supply custom AppArmor profiles, which is especially an issue with security-critical software like a web browser.
Until this is fixed, full migration (removing deb in favor of snap) is irresponsible and will break security minded environments. In my case, I will no longer be able to use chromium on Ubuntu.
Can you give some specific on what you are looking to do? The bug report mention blocking access to user files, which you basically get by default with the snap which has its own private user dir (just disconnect the interface that let you access your normal user files)
(google translate)
Be assured that I do not want to fud. It’s even hurtful that you can think that. I spend the majority of my free time for opensource projects with great respect.
I support Ubuntu since version 8.04 with great luck.
I know exactly when the calculator was added as SNAP. There are many messages that we have received from users on the forums complaining about snap.
I have also completed a bug report on this slowness but only with the items that I can have and remains waiting for any requests.
On the help forums, snap issues are quite common and the help requests that come with it. That’s just why we had to report a current concern about the arrival of chromium that might cause this to happen with other major software. obviously it’s a lack of information about it.
It seems to me that this is an appropriate space to communicate incomprehension between the developers and the daily users. Where else to do it?
I hear that you are concerned about some remaining dysfunction and really thank you for it.
This post will obviously allow you to bring explications on the proposed changes and for us not to passively undergo them.
Sorry if you found the comment offensing, I was not speaking about your intend but about things you are writing.
It would be a more reasonable position to state “please don’t replace debs by snaps without making sure those have no regression in performance or usability” than to write that “snaps are not ready for normal users” (written like that it implies the technology is not ready which damages the reputation of a good project and hurts the feeling of a good team which is working hard on it, when the reality/problems are not with “snaps” but with “some snaps” which are mode demanding/need work)
Remember also in those conversations with users that debs are not perfect, it’s not uncommon for upgrades to hit a packaging error which can let the system is a buggy state/not booting for example.
2 Likes
(google translate)
I have nothing against snaps but they shouldn’t be imposed.
Inexperienced users use Ubuntu Software to install new applications and often choose to install the snap instead of the .deb out of ignorance, then the snap is updated and the user finds himself with many Megabytes occupied by the various versions without understanding why.
Ubuntu Software should better highlight the snap packages to avoid these problems.
1 Like
There you assume they would be better served by the deb, but maybe they do want the snap because it’s more uptodate, or maybe the snap for that software is directly maintained by upstream and better maintained.
You have a valid point that snaps by default keep previous versions installed and that those take disk space which can be problematic for some users. The answer there is probably to talk to the snap team about allowing to set the number of revision to 1 (instead of 2 which is the default and lower limit now)
4 Likes
I can agree to some point. On the other hand you miss the great advantage of switching back to previous version if something went wrong.
2 Likes
Personally I’ve got mounts and symlinks and can probably turn any child-safety locks off without too much risk, but I’d say “widest possible usage case” includes being able to save to a flash drive without needing to find a setting and change it. That’s likely to confuse and inconvenience non-experts, and shouldn’t be pushed as a new normal.
Putting aside that snap auto updates are not user controllable I don’t understand why such updates don’t present a user notification . Can’t fathom the reason there, users should always be notified of any update…
2 Likes
No thanks! I only want to care if the update goes badly or I have to make a decision, software is updating faster and faster these days, last thing I want to care about is worrying that each time I install software the amount of my notifications will keep increasing over time.
6 Likes
Interesting. I guess Ubuntu is taking a different approach that what Debian did. For example, here’s Debian chromium’s versions https://qa.debian.org/madison.php?package=chromium&table=debian&a=&c=&s=#
They seems to have decided that if upstream breaks using new unsupported features, they will simply not update it. That obviously has tickled down to Ubuntu https://askubuntu.com/a/890625/169736 and their “solution” was snap.