Distro News - Ubuntu 20.04 'Focal Fossa', Ubuntu MATE and other flavours released

I have read that prime-select doesn't work properly so if you have Nvidia hybrid graphics it would be a good idea to hold off upgrading

I do run standard Ubuntu 18.04 on my laptop (need one machine to have the most common Linux), so I guess I'll upgrade that to 20.04 eventually.

No need to hurry, though, I didn't have any problems with 18.04 to begin with.

I like snaps. They're convenient to install, use and create. There are still a lot of problems with the confinement, performance and ecosystem but these are improving. Canonical know, from their own survey, that about one third of users are positive about snaps, one third neutral and one third negative. If you follow the forums and IRC channels you'll find they are trying hard to improve things.

Thousands of people run the snaps I've packaged, including games like Wolfendoom: Blade of Agony, Quake Shareware and Tales of Maj'Eyal. Some people love them, some people hate them. Some of the hatred comes from my incompetence in packaging and some comes from flaws in snap technology. But we're all learning and trying to improve. This is a community, after all.

Upgrading to 20.04 will break some games (such as those linking to older versions of libssl) and Steam Controller users may be dismayed to find that sc-controller no longer runs. This is because of the deprecation of python2: something Canonical has no control over. I'm working on an sc-controller snap which will allow it to run on 20.04. It requires a bit of new plumbing to come to snapd before it will be ready to use, but the snapd guys are working on this. As I said, this is a community.

Being a community, it would be nice if we could be kind and respectful to each other. Ubuntu (and its flavours and its remixes) offers plenty of scope to run without snaps. It offers plenty of scope to use PPAs, Appimages and Flatpaks. Maybe the whole snap experiment will be abandoned further down the line but that will be dependent on what the community wants. Canonical are asking them and are being transparent about the results. Is that worth the anger? Let's enjoy what has been created, uninstall whatever annoys us and thank our respective $DEITYs that we have the freedom to do so.

Browsing by category in mintinstall seems to list apt packages only, and flatpaks are under their own special category. Searching for packages does list both. All in all, seems like a fairly passive way to "push" flatpaks, and not really comparable to what Canonical/Ubuntu is doing with snaps, IMHO. It's nice that they're there as an option though.

That's more or less how Ubuntu does it... The only real difference is that the Ubuntu Development Team have chosen to replace certain software with the "Snap" version rather than the "Debian" version (where as with Linux Mint, you actually need to choose to replace some of the default programs with the "Flatpak" version).

But even then, I'd hardly call that "Canonical forcing Snap down your throat"...


Last edited by Cyba.Cowboy on 24 April 2020 at 2:14 pm UTC

I'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well.

sudo apt purge snapd will get rid of snaps entirely. Easy enough.

Yes, but my understanding is that will also get rid of your ability to easily install certain software packages. In my case, I use spek to analyze audio files, but it can only be installed through snap now.

Although now that I've actually tested it, it seems that spek is extremely slow to start and doesn't even work (it says "The file contains no audio streams" when I know that's false). So hooray for snap? :p


Last edited by Mountain Man on 24 April 2020 at 4:07 pm UTC

Still don't see a usecase for snap (or fatpak) on the desktop that would not be better (less time, less space, more reliable functionality) solved by Appimage if you do not get a native package. Trying to push things onto me made me quit the Windows OS and keeps me away from the Gnome DE, just saying Canonical. On the other hand: I like the new icon theme. ;-)

Yeah, I use the Cura Appimage for 3D Printing, it works fine. I'd prefer one updated through apt myself, as that would put it in my Gnome Launcher, instead of me having to dig into Nautilus to click on an Icon, though I used to do that on the Atari ST back in the day, so not sure how that's any different :P

Still don't see a usecase for snap (or fatpak) on the desktop that would not be better (less time, less space, more reliable functionality) solved by Appimage if you do not get a native package.

Amen! I've been distributing Linux binaries in AppImage format for quite a while, and I really like how they're small and self-contained, with no daemon required in the background for them to run.

I had looked at both snap and flatpak as alternatives, but the whole idea of distributing binaries in the first place was for stuff to just work across distributions with minimal dependencies.

In general though, I'll want to use the regular binaries, managed via the package repository. With the image based applications, if some library they include has vulnerabilities, all the applications need to be patched and updated individually. With regular programs, the library in question can be updated and all the dependent applications are golden.

I have read that prime-select doesn't work properly so if you have Nvidia hybrid graphics it would be a good idea to hold off upgrading

Do you have any links to bug reports or forum posts regarding that?
prime-select via command line or via the mate-optimus seems to work without problems for me.

It could be some problems for only certain hardware, or the users had something broken before or its widespread problem, a link to a report would be nice.


Last edited by Redface on 24 April 2020 at 6:08 pm UTC

I'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well.

sudo apt purge snapd will get rid of snaps entirely. Easy enough.

Sure, but will any default programs be removed by that - like say, the calculator? (I legit don't know what would happen to installed snaps)

And will the Ubuntu repositories contain non-snap alternatives for stuff? If they stop maintaining stuff in the repos because they now use snaps, it becomes impractical to use the distro without it. (While, presumably, other distros could still have those normally... at least for now)

The calculator will be switched back to the .deb on upgrade, or installed on a new install, same as the other packages that where used to test snaps as the system monitor.

Only the software store will be installed as a snap as default now. And chromium is only as a snap in Ubuntu now, but available in PPAs as a deb, but that is not a default package.

The software store is also available as a deb, so all default programs can be installed without snap, but its possible one wants to use other programs only available as a snap.

I read it but their reasoning was that chromium usage isn't that high (so the test wouldn't inconvenience too many people) and that a browser is exactly the kind of thing that you'd want to be run in a sandbox. That decision doesn't affect me, personally, since I use chromium from a PPA anyway for the hardware video decoding.

I also use chromium pa, some little annoying thing is that every time I launch it , I get a message of chromium missing Google API dev keys. Do you know a way of getting rid of those messages?

It actually looks like a meaningful improvement in most aspects; there were many important updates to hardware support and big applications since 18.04, which I mostly had to backport or install in some way (newer mesa fixed several games, newer KDE had some nice features and look for those of us that use Kubuntu, newer libre office had a few important features, and I expect the version of wine in their repositories will be less awful). Plus generally looking nice and bugfixes, as always.

But the way they keep trying to push snaps almost makes me want to not update at all, or switch distros permanently. I used to assume that snaps weren't that bad, but after actually having more contact with them I was shocked by how horrible it is. First, snaps had ridiculously bad performance problems; so it was not even a "non-technical users wouldn't even notice" - people did notice, for example how ridiculously slow chromium was. Second, as a system it is way too closed and centralized, which is particularly bad for something that is intended to work across distros (other distros can't just host their own snap repositories, the backend isn't FOSS, and it is entirely developed by Canonical without any cooperation with other distros). And third, Canonical are actively pushing for it to replace other alternatives, which means we can't even ignore it if we don't like it.

I'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well. But frankly, I'm already looking to jump boat from Kubuntu, and particularly for something better to recommend for newbies.

Yea, I agree, snaps suck. I have a use case where I run Ubuntu vdis in Docker container (full UI in docker, it's sick! :D ), and as of 19.10, they no longer have a chromium deb package. If you apt-get install chromium, you get the snapd migration package (it's called something along those lines, i don't remember anymore) and there is no official deb.

The thing is, because snap is basically a container, you can't install it in a Docker container...the snapd service doesn't even work in docker. There are some hacky ways to get it working, but chromium still does not launch. So this was a big problem for me.

To work around this, I have a separate pipeline that builds chromium from source and spits out a deb that I host in a different location (should probably use aptly to host a local repo, haven't got there yet) and then my docker image pipeline fetches the deb from there and installs it. Basically a shitload of work needed to be done to get chromium working in Docker. I haven't tested 20.04 yet, but if they start doing the same for other applications I use in the VDI, I'll probably move to debian or something.

You could either use a PPA for chromium, or maintain your own.

As far as I know there is the PPA from the chromium developers which just has the latest development version, and then the latest released from popos, but that is not in a ppa of its own but together with a lot of other popos packages. (I have not checked popos 20.04, but that is the case for popos 19.10)

Still don't see a usecase for snap (or fatpak) on the desktop that would not be better (less time, less space, more reliable functionality) solved by Appimage if you do not get a native package.

Amen! I've been distributing Linux binaries in AppImage format for quite a while, and I really like how they're small and self-contained, with no daemon required in the background for them to run.

I had looked at both snap and flatpak as alternatives, but the whole idea of distributing binaries in the first place was for stuff to just work across distributions with minimal dependencies.

In general though, I'll want to use the regular binaries, managed via the package repository. With the image based applications, if some library they include has vulnerabilities, all the applications need to be patched and updated individually. With regular programs, the library in question can be updated and all the dependent applications are golden.

Sorry for my ignorance, but is there some kind of appimage store? I really find the appimage concept convenient, but is there something for the automatic updates aspect?

I'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well.

sudo apt purge snapd will get rid of snaps entirely. Easy enough.

Sure, but will any default programs be removed by that - like say, the calculator? (I legit don't know what would happen to installed snaps)

And will the Ubuntu repositories contain non-snap alternatives for stuff? If they stop maintaining stuff in the repos because they now use snaps, it becomes impractical to use the distro without it. (While, presumably, other distros could still have those normally... at least for now)

Hey, thank you both for this! I had a look on my system and sure enough, not only was snapd installed but among the few snaps installed on my system was gnome-calculator. I was wondering why the hell the calculator in Ubuntu took a freaking minute to load. Went ahead and installed the calculator from apt and now it loads in less than a second like a good calculator should... oh, and also I'm removing all of snapd and REPLACING ALL THE OTHER SNAPS WITH PACKAGES THAT ACTUALLY WORK RIGHT. ...And seriously contemplating switching to like, Debian or something.

I have been running Debian Sid for pretty much decades at this point. Sure I've played with other distributions along the way, but mostly stick with Debian Sid. You CAN install snapd and flatpak if you'd like in Debian, but it doesn't try to abuse it's users and force it upon anyone.

Thanks for the advice, but my musing about switching to Debian is largely fueled by wanting to avoid snapd. Maybe flatpack's better, but frankly I don't see the use much. ("Am I so out of touch...?")
But no matter what you think of the concept, I hope we can all agree that taking a minute to load a calculator, something that could load in about a second on Windows 95, is unacceptable.

I'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well.

sudo apt purge snapd will get rid of snaps entirely. Easy enough.

Sure, but will any default programs be removed by that - like say, the calculator? (I legit don't know what would happen to installed snaps)

And will the Ubuntu repositories contain non-snap alternatives for stuff? If they stop maintaining stuff in the repos because they now use snaps, it becomes impractical to use the distro without it. (While, presumably, other distros could still have those normally... at least for now)

Hey, thank you both for this! I had a look on my system and sure enough, not only was snapd installed but among the few snaps installed on my system was gnome-calculator. I was wondering why the hell the calculator in Ubuntu took a freaking minute to load. Went ahead and installed the calculator from apt and now it loads in less than a second like a good calculator should... oh, and also I'm removing all of snapd and REPLACING ALL THE OTHER SNAPS WITH PACKAGES THAT ACTUALLY WORK RIGHT. ...And seriously contemplating switching to like, Debian or something.

I have been running Debian Sid for pretty much decades at this point. Sure I've played with other distributions along the way, but mostly stick with Debian Sid. You CAN install snapd and flatpak if you'd like in Debian, but it doesn't try to abuse it's users and force it upon anyone.

Thanks for the advice, but my musing about switching to Debian is largely fueled by wanting to avoid snapd. Maybe flatpack's better, but frankly I don't see the use much. ("Am I so out of touch...?")
But no matter what you think of the concept, I hope we can all agree that taking a minute to load a calculator, something that could load in about a second on Windows 95, is unacceptable.

The calculator defaults to the deb package in 20.04 and you can avoid snaps on Ubuntu if you want.

Sorry for my ignorance, but is there some kind of appimage store? I really find the appimage concept convenient, but is there something for the automatic updates aspect?

The one I'm aware of is AppImageHub. Not sure about automatic updates, though. My own stuff is no longer in active development, so I never really have given that aspect much consideration.

And as a user, I try to get everything from either the official repository or a PPA.

With all the positive reactions here, I forced the upgrade from 18.04, as it was a relatively fresh install anyway. I think it's the first time that upgrading from one LTS to the next didn't break the graphics driver, so that's a positive :-).

It didn't, however, go totally smooth. For one it came up with python2 as the default interpreter instead of python3 (the only package actually still depending on python2 being mercurial, which I cannot get rid of, unfortunately). That caused unity-mail to crash, which is still my preferred notification app.

My gnome extensions also weren't updated automatically, and while a notification popped up that updates were available, it took me a while to figure out that what looked like a settings button was actually the button to load the update. But that's on Gnome, not Ubuntu. Also, for some reason, gnome-shell-extension-prefs was not or no longer installed, so extension preferences did not work initially.

But the worst was the new theme. I hate black in particular and dark themes in general. So I switched to the light variant, only to find that all console windows still sported a black window border. Well, turns out console has its own theme settings that for some reason is not following the system default. At least the upgrade preserved my desktop background, but I still have to change grub to show something other than black & white.

And finally, none of the few PPAs I use is yet available for 20.04. Though I guess this will be only a matter of time.

On the whole, I'm content with the updated system, but there's nothing to be ecstatic about.


Last edited by kaiman on 25 April 2020 at 10:13 am UTC

i hope 'Fractional Scaling' is refined sooner rather than later as i would love to scale my display to 125%

I'll wait a bit anyway and probably will update to 20.04 if it isn't too obnoxious to avoid snaps for most things, or if at least it works well.

sudo apt purge snapd will get rid of snaps entirely. Easy enough.

Sure, but will any default programs be removed by that - like say, the calculator? (I legit don't know what would happen to installed snaps)

And will the Ubuntu repositories contain non-snap alternatives for stuff? If they stop maintaining stuff in the repos because they now use snaps, it becomes impractical to use the distro without it. (While, presumably, other distros could still have those normally... at least for now)

Hey, thank you both for this! I had a look on my system and sure enough, not only was snapd installed but among the few snaps installed on my system was gnome-calculator. I was wondering why the hell the calculator in Ubuntu took a freaking minute to load. Went ahead and installed the calculator from apt and now it loads in less than a second like a good calculator should... oh, and also I'm removing all of snapd and REPLACING ALL THE OTHER SNAPS WITH PACKAGES THAT ACTUALLY WORK RIGHT. ...And seriously contemplating switching to like, Debian or something.

I have been running Debian Sid for pretty much decades at this point. Sure I've played with other distributions along the way, but mostly stick with Debian Sid. You CAN install snapd and flatpak if you'd like in Debian, but it doesn't try to abuse it's users and force it upon anyone.

Thanks for the advice, but my musing about switching to Debian is largely fueled by wanting to avoid snapd. Maybe flatpack's better, but frankly I don't see the use much. ("Am I so out of touch...?")
But no matter what you think of the concept, I hope we can all agree that taking a minute to load a calculator, something that could load in about a second on Windows 95, is unacceptable.

Ha, yeah my point is you can avoid both by going to debian, they just give you the option if you want to go down that path, which is fantastic.
Flatpack and snap both try to fill up /, so if you have a separate /home, it can cause some issues. I had been testing something in a VM and the flatpak package cache did that to me.

i hope 'Fractional Scaling' is refined sooner rather than later as i would love to scale my display to 125%

That's... one of the features that's included in 20.04 for Gnome. The other desktop environments have had it for a long time already.

Flatpack and snap both try to fill up /, so if you have a separate /home, it can cause some issues. I had been testing something in a VM and the flatpak package cache did that to me.

That's true. Flatpak cache directories can really pile up in your /var/tmp/. These are used to enable partial downloads if I've understood correctly. I manually delete them every once in a while, but a simple script or systemd service could take care of that just fine at shutdown/startup.

The packages themselves can be installed either in a system-wide prefix (/var/lib/flatpak on Mint) or per user (under ~/.local/share/flatpak).

KDE allows scaling in steps of 6.25%, that's definitely more granular than 25% steps.