Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.

Minecraft's rather large 'Update Aquatic' content update came out recently and it came with their fancy new launcher, getting it on Linux and keeping it up to date is now a snap.

To be clear, I'm talking about the Snap packaging format that comes built into Ubuntu, Solus and more. If you don't have Snap package support, installing it is easy and it gives you easy access to quite a lot of games and applications across different distributions and all kept up to date for you.

Minecraft has been available as a Snap for a while, but it was using the now outdated and ugly old launcher, which wasn't a great user experience. As of today, it was updated to give you the new and improved experience.

You can grab it from the Snapcraft store or if your distribution supports it, like Ubuntu, it can be found by just searching for "Minecraft" in the Software Centre.

If you already have it installed, you can wait for it to update automatically or quickly do it yourself like so in terminal:

snap refresh minecraft

Naturally, you can download Minecraft direct from the official site as well, but for me personally I do prefer the experience of just hitting install and having it all done there and then.

Also, it seems Mojang have already fixed the minor text distortion issue I reported to them recently—great!

Article taken from GamingOnLinux.com.
8 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. Find me on Mastodon.
See more from me
The comments on this article are closed.
26 comments
Page: 1/3»
  Go to:

PJ Jul 23, 2018
got to admit I have mixed feelings when I read news like this.
On the one hand it is awesome to hear about new ways of getting your software without hassle of hunting dependencies, configs etc and appreciate diversity in Linux.
But on the other hand - damn it, can't we agree on a single universal package format, not 3? It has this deb vs rpm stench all over it. Certainly I'd be happier if all the effort would went into making a single working, universally recognized format before adding new ones. Possibly Flatpak, even though personally I enjoy AppImages the most (due to its simplicity) - as it seems the most widely accepted across distros and does not bear the usual Canonical controversy mark...
14 Jul 23, 2018
View PC info
  • Supporter Plus
Maybe I should tinker and get snaps on my kids' Elementary machines. It was a bit annoying setting up Minecraft and shortcuts. It made me want to wipe the OS and replace it with an Arch-based OS so that I had access to the AUR. *sigh*
Liam Dawe Jul 23, 2018
Quoting: 14Maybe I should tinker and get snaps on my kids' Elementary machines. It was a bit annoying setting up Minecraft and shortcuts. It made me want to wipe the OS and replace it with an Arch-based OS so that I had access to the AUR. *sigh*
This is why I love the idea behind Snaps and other such stuff. Just being able to run what I want on whatever distro I happen to hop over to or stick on the laptop to mess with, without resorting to extra PPAs, adding extra repos and so on.
Exidan Jul 24, 2018
Quoting: PJgot to admit I have mixed feelings when I read news like this.
On the one hand it is awesome to hear about new ways of getting your software without hassle of hunting dependencies, configs etc and appreciate diversity in Linux.
But on the other hand - damn it, can't we agree on a single universal package format, not 3? It has this deb vs rpm stench all over it. Certainly I'd be happier if all the effort would went into making a single working, universally recognized format before adding new ones. Possibly Flatpak, even though personally I enjoy AppImages the most (due to its simplicity) - as it seems the most widely accepted across distros and does not bear the usual Canonical controversy mark...
I don't like how they handle libraries and dependencies. isn't the whole point of the linux ecosystem to avoid redundancy? if they ship every library with the snap (and they look first for the shipped library before looking into the system), they will end up with a whole lot of redundancy.


Last edited by Exidan on 24 July 2018 at 3:06 am UTC
TheSHEEEP Jul 24, 2018
View PC info
  • Supporter Plus
Quoting: Exidan
Quoting: PJgot to admit I have mixed feelings when I read news like this.
On the one hand it is awesome to hear about new ways of getting your software without hassle of hunting dependencies, configs etc and appreciate diversity in Linux.
But on the other hand - damn it, can't we agree on a single universal package format, not 3? It has this deb vs rpm stench all over it. Certainly I'd be happier if all the effort would went into making a single working, universally recognized format before adding new ones. Possibly Flatpak, even though personally I enjoy AppImages the most (due to its simplicity) - as it seems the most widely accepted across distros and does not bear the usual Canonical controversy mark...
I don't like how they handle libraries and dependencies. isn't the whole point of the linux ecosystem to avoid redundancy? if they ship every library with the snap (and they look first for the shipped library before looking into the system), they will end up with a whole lot of redundancy.
The worst point about linux (well, next to the fragmentation) is that terrible idea of avoiding redundancy by assuming you just have to the right versions of the right libraries.
It is completely impractical when you actually want to distribute software.

When you distribute software, your software was built against certain versions of certain libraries.
There is simply no way to guarantee that a user has those certain versions of those certain libraries on their computer. Nor is there a way to guarantee that there will always be your specific required version (architecture, version, etc.) available anywhere.
Nor is it realistic to expect devs to make sure that there is a PPA or whatever with exactly the versions they need.
Nor can you be sure that none of the symlinks on a user's system isn't somehow broken, pointing to a wrong version, etc.
Nor can you be sure that some update to a library won't break compatibility.
Nor can devs be expected to always make sure their software works with the most recent versions of all dependencies - devs must be able to move on to new projects, not maintain their old projects forever.
There are thousands of problems with this approach and it just barely works for open source projects IF and only if they are well maintained - for all others, it really doesn't. It is a "weakest link" approach - all goes well until the weakest link in the chain breaks - and "weakest link" approaches are generally terrible.

The ONLY way to make sure your distributed software works as intended is to distribute the exact versions of dependencies with it. Or use Docker or smth. similar (though that isn't applicable for all cases).
I rather have some megabytes "wasted", if what I get is software that is guaranteed to work on my user's machines without a hassle and without influencing anything else on the user's machines.

Oh, and because I know some tinfoil hat will come with the security argument:
If one of my dependencies has a security problem, I can update that dependency and forward that update to users. It is my responsibility as a dev to watch out for stuff like that.
But 95% of all software doesn't even do anything that could pose a security threat even if there was an exploit. And for the other 5% this happens so rarely that using a different approach doesn't come close to the benefits of distributing dependencies with your software.


Last edited by TheSHEEEP on 24 July 2018 at 8:09 am UTC
toor Jul 24, 2018
Quoting: PJgot to admit I have mixed feelings when I read news like this.
On the one hand it is awesome to hear about new ways of getting your software without hassle of hunting dependencies, configs etc and appreciate diversity in Linux.
But on the other hand - damn it, can't we agree on a single universal package format, not 3? It has this deb vs rpm stench all over it. Certainly I'd be happier if all the effort would went into making a single working, universally recognized format before adding new ones. Possibly Flatpak, even though personally I enjoy AppImages the most (due to its simplicity) - as it seems the most widely accepted across distros and does not bear the usual Canonical controversy mark...

Anyway, It's not passing the launcher for me with flatpak, I get a crash as soon as it tries to load some drivers via libGL
kemzen Jul 24, 2018
Snaps is one of the best things that has come to Linux. Sure the name sucks, but other than that, its great. I have had so much trouble like everyone else with dependency hell before Snaps. before snaps was introduced you could install maybe 10 famous apps without problems, but after that and installing infamous apps the deoendency hell started to come up. I want to install what I want and how much I want on my glinux machine without some shitty dependencies...
Ananace Jul 24, 2018
There is work ongoing on getting Minecraft running as a Flatpak as well, though apparently Java is misbehaving quite badly, so multiplayer doesn't seem to work.
Nezchan Jul 24, 2018
I get that flatpaks and snaps are easy to install, but what's never been clear to me is are they as easy to update as PPAs for instance? Or do I have to go to every single piece of software I use and keep them updated manually and individually?
Exidan Jul 24, 2018
Quoting: TheSHEEEP
Quoting: Exidan
Quoting: PJgot to admit I have mixed feelings when I read news like this.
On the one hand it is awesome to hear about new ways of getting your software without hassle of hunting dependencies, configs etc and appreciate diversity in Linux.
But on the other hand - damn it, can't we agree on a single universal package format, not 3? It has this deb vs rpm stench all over it. Certainly I'd be happier if all the effort would went into making a single working, universally recognized format before adding new ones. Possibly Flatpak, even though personally I enjoy AppImages the most (due to its simplicity) - as it seems the most widely accepted across distros and does not bear the usual Canonical controversy mark...
I don't like how they handle libraries and dependencies. isn't the whole point of the linux ecosystem to avoid redundancy? if they ship every library with the snap (and they look first for the shipped library before looking into the system), they will end up with a whole lot of redundancy.
The worst point about linux (well, next to the fragmentation) is that terrible idea of avoiding redundancy by assuming you just have to the right versions of the right libraries.
It is completely impractical when you actually want to distribute software.

When you distribute software, your software was built against certain versions of certain libraries.
There is simply no way to guarantee that a user has those certain versions of those certain libraries on their computer. Nor is there a way to guarantee that there will always be your specific required version (architecture, version, etc.) available anywhere.
Nor is it realistic to expect devs to make sure that there is a PPA or whatever with exactly the versions they need.
Nor can you be sure that none of the symlinks on a user's system isn't somehow broken, pointing to a wrong version, etc.
Nor can you be sure that some update to a library won't break compatibility.
Nor can devs be expected to always make sure their software works with the most recent versions of all dependencies - devs must be able to move on to new projects, not maintain their old projects forever.
There are thousands of problems with this approach and it just barely works for open source projects IF and only if they are well maintained - for all others, it really doesn't. It is a "weakest link" approach - all goes well until the weakest link in the chain breaks - and "weakest link" approaches are generally terrible.

The ONLY way to make sure your distributed software works as intended is to distribute the exact versions of dependencies with it. Or use Docker or smth. similar (though that isn't applicable for all cases).
I rather have some megabytes "wasted", if what I get is software that is guaranteed to work on my user's machines without a hassle and without influencing anything else on the user's machines.

Oh, and because I know some tinfoil hat will come with the security argument:
If one of my dependencies has a security problem, I can update that dependency and forward that update to users. It is my responsibility as a dev to watch out for stuff like that.
But 95% of all software doesn't even do anything that could pose a security threat even if there was an exploit. And for the other 5% this happens so rarely that using a different approach doesn't come close to the benefits of distributing dependencies with your software.
hmm... I always liked the point of no redundancy about linux, and one of the strongest argument against using windows. and fragmentation on linux? only if your hdd is nearly full, really. I don't see other way to do it (besides the "linux way").
Anyway, I guess we just have total disparity of opinions on this matter lol
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.