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!
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...
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.
Quoting: PJgot to admit I have mixed feelings when I read news like this.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.
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...
Last edited by Exidan on 24 July 2018 at 3:06 am UTC
Quoting: ExidanThe 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.Quoting: PJgot to admit I have mixed feelings when I read news like this.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.
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...
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
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
Quoting: TheSHEEEPhmm... 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").Quoting: ExidanThe 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.Quoting: PJgot to admit I have mixed feelings when I read news like this.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.
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...
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.
Anyway, I guess we just have total disparity of opinions on this matter lol
See more from me