GIMP Now Offers an Official Snap Package For Linux Users (nerds.xyz) 53
Slashdot reader BrianFagioli writes: GIMP has officially launched its own Snap package for Linux, finally taking over from the community-maintained Snapcrafters project. The move means all future GIMP releases will now be built directly from the team's CI pipeline, ensuring faster, more consistent updates across distributions. The developers also introduced a new "gimp-plugins" interface to support external plugins while maintaining Snap's security confinement, with GMIC and OpenVINO already supported.
This marks another major step in GIMP's cross-platform packaging efforts, joining Flatpak and MSIX distribution options. The first officially maintained version, Version 3.0.6GIMP 3.0.6, is available now on the "latest/stable" Snap channel, with preview builds rolling out for testers.
This marks another major step in GIMP's cross-platform packaging efforts, joining Flatpak and MSIX distribution options. The first officially maintained version, Version 3.0.6GIMP 3.0.6, is available now on the "latest/stable" Snap channel, with preview builds rolling out for testers.
Re: (Score:1)
If you take a shower more than twice a week, I promise you, you won't have to project any longer.
In other words (Score:1, Interesting)
Gimp makes a package for Ubuntu
Just say no to snap (Score:5, Interesting)
Snap is the wrong solution to the problem, and every time some big project switches to it (or any of the other awful systems like Flatpak and AppImage), I shake my head.
The problem of the balkanization of Linux distributions isn't solved by an app system that takes away all the best parts of Linux. The great thing about Linux is that you didn't need fifty copies of every DLL, that you could fit an entire working system with complete office software, in a tenth the space of a similarly "capable" Windows system. Making a system that essentially wraps everything an app needs in its own little mini-distro is awful. It costs storage space. And it costs RAM. Each application needs to instantiate its own set of every shared library it uses, so you can end up with ten instances of the same shared object in ram. Even to multiple libc's.
The FHS then LSB were the correct answers. The answer was and still is standardization on the back end. Standardize the basic system and libraries, standardize where packages are installed to, then keep going and standardize the way packages are installed. The distros can keep their rpm and apt/dpkg, I don't care about the command name or its command line switches. But each of them can and should call a more basic level library whose API is the same for every distributions to do the final work.
The problem is there is too much money on the Red-Hat esque side of the fence interested in making it NON-compliant with any standard. And, in fact, in pulling it back from even being open source as much as possible. The rest of the Linux ecosystem, though, needs to hang its head in shame for allowing distro balkanization to happen to this extent.
Any big-name software projects needs to just say no to the bandaid "solutions" like snap flatpak, and appimage that apply just enough bandage to the situation to keep the incentive away from fixing the problem properly.
Re: (Score:2)
The modders are on a (bad) roll today! And I literally just ran out of mod points yesterday :(
Re:Just say no to snap (Score:4, Informative)
The great thing about Linux is that you didn't need fifty copies of every DLL
The sad reality is that you actually do need fifty copies of every lib.so. Distros make their own unique changes to the binaries, and then give the modified versions the same names as the originals. Even worse, most of the dynamic loaders the major distros don't support looking up a hash of the needed lib.so instead of a hardcoded file name. (Despite the ELF format supporting it.)
The result is a bunch of different lib.sos are needed just because one app depends on distro X's lib, and it's completely incompatible with distro Y's lib. Which due to the above, means you can't install them side-by-side at the same time without causing conflicts elsewhere in the system.
The FHS then LSB were the correct answers. The answer was and still is standardization on the back end. Standardize the basic system and libraries, standardize where packages are installed to, then keep going and standardize the way packages are installed.
That's actually the reason why all of this is broken. They DID try to standardize it and the talks kindof got some crap done, but then egos got in the way, and we wound up in the situation described above. The names were "standardized", i.e. kept the same in some cases across distros, but the unique and incompatible changes kept coming. Mostly due to the lack of proper standardization. I.e. Use a unique hash to id the needed lib.so based on it's content instead of a filename, then it doesn't matter where on the filesystem it's kept or what it is called. That change alone would have fixed the need for AppImages, Flatpaks, Snaps, etc. But they refuse to make the needed changes.
The LSB was even worse, to the point that most people today only use it as a generic command to find out what distro is running. (I.e. `lsb_release -sd`.) It did result in the alien command, which converts packages from one format to another (ie. deb->rpm, rpm->deb, etc.) and is great when it works, but many packages won't work properly even if they convert successfully. Due to broken lib.so dependencies, (See above.) or distro specific paths. (I.e. deviations from the FHS.)
As for backend standardization, I do agree with you. Developers need a consistent platform to target. Which is why until Valve promoted ubuntu with Steam for Linux and Arch with SteamOS, most game developers steered clear of Linux entirely. Ironically, Linux may get standardization around ubuntu's or Arch's way of doing things because of Steam. (Ubuntu is probably more likely due to the Steam on Linux client releasing before SteamOS and The Steam Deck.) Developers will want to target the largest install base, with the most potential users. In the server world that won't mean much initially, but as the years go on and more game devs target Linux through Steam, it will start impacting the servers too. (They won't want to develop for multiple distros on the client side. Let alone the multiplayer server side.) Not to mention those who grew up with SteamOS or ubuntu will expect things on the server side to work the same way when they get hired by someone to develop for or manage servers.
The problem is there is too much money on the Red-Hat esque side of the fence interested in making it NON-compliant with any standard. And, in fact, in pulling it back from even being open source as much as possible.
Red Hat is a dead duck as far as I'm concerned. They've burnt too much good will within their own user base, abandoned multiple projects after promising support, and changed their entire ecosystem so much that it's impossible to develop a stable set of expectations. In my personal experience, the last 4 major issues that required a complete overhaul of the network I manage was caused by their deprecation of various projects. (Yes, their sudden degradation of CentOS was one of them.) I've sworn off using them for anythin
Re: (Score:2)
Even worse, most of the dynamic loaders the major distros don't support looking up a hash of the needed lib.so instead of a hardcoded file name. (Despite the ELF format supporting it.)
What loader is needed to take advantage of this? Is there a ready solution that can reasonably be built and installed on a typical system?
Re: (Score:1)
Every time I think about trying my hand at Linux again, I read posts like this and think, "Nope. Got no time to worry about all that bullshit. I'll just stick with MacOS."
Thanks for the reminder.
P.s. not a criticism of your post, it's a thank you for the reminder to use my time wisely.
Re: Just say no to snap (Score:2)
What he is complaining about is that things like Flatpak make Linux applications work more like macOS. He is mad because many Linux distros are making things more Mac-like to make things easier for users like you. The OP actually wants the prospect of dependency hell because he would rather save a minor amount of disk space than have redundant libraries.
Re: (Score:1)
Wow. You really make a lot of unwarranted assumptions.
Re: (Score:3)
The great thing about Linux is that you didn't need fifty copies of every DLL
The importance of this is underestimated even by it's proponents. There might be two copies of one set of DLLs, because you are a developer and need to work work on a special version in order to build some specific application but once you have three or more then you are guaranteeing that there will be security problems in future.
The sad reality is that you actually do need fifty copies of every lib.so. Distros make their own unique changes to the binaries, and then give the modified versions the same names as the originals. Even worse, most of the dynamic loaders the major distros don't support looking up a hash of the needed lib.so instead of a hardcoded file name. (Despite the ELF format supporting it.)
If you did that, then you would allow software to block security upgrades of particular libraries. It's a disaster waiting to happen since every piece of software will start demand
Re: (Score:2)
DLL Hell is the reason for snaps and flatpaks and other container formats.
Linux has DLL hell - it's caused by libraries being binary incompatible with themselves. Some libraries, like glibc, pride themselves on binary compatibility which is why programs linked against older glibc still run on newer glibc. But such capability means a lot of code goes into just keeping compatibility. It's why alternative C libraries exist that provide much of the same functionality but with half the size or less - they dump t
Re: (Score:2)
This is not my experience. I am on Debian and I did not experience anything like DLL hell in since I switched to Linux 30 years ago. I can see that if one passes locally compiles binaries around in a company that it does not work automatically, but the solution to this does not require anything like Snap. Where there is friction, then the main issue is lack of standardization, but this done intentionally by commercial Linux distribution to differentiate, and Snap and co. a part of the problem and not the
Re: (Score:3)
This is not my experience. I am on Debian and I did not experience anything like DLL hell in since I switched to Linux 30 years ago.
There is no direct equivalent to DLL hell on Linux because nothing precludes you installing multiple different versions of a library and loading them at the same time like DLLs. But if you go trying to get a new version of some software on Debian that nobody has bothered to package yet, you will often have a bad time. You will need to build dependencies for your dependencies and then you will need to build dependencies for those dependencies and so on. You can help keep your system clean by setting the pref
Re: (Score:2)
Yes, but in practice this was never a problem for me. But if it were, the solution would be to package the software for Debian instead of creating snap packages. And if the complaint is that this too much work for different distributions, then the answer would still not be snap but to revive the LSB.
Re: (Score:1)
RAM and storage space are dirt cheap. Hardly a concern for normal people.
Re: (Score:3)
The great thing about Linux is that you didn't need fifty copies of every DLL
You left out a word. The great thing about Linux *Distributions* is that you didn't need fifty copies of every DLL. Distribution maintainers put a shitload of work into avoiding the kind of DLL hell that Windows suffered from. However that only works when you play within their environment. As soon as you start stepping outside of it, outside of their configuration, outside of their organised dependency tree, then things start to get ugly.
Linux isn't immune from DLL hell, quite the opposite. Many-a Linux dis
Re: (Score:2)
It's the same line of thinking that says Systemd exists only because of RedHat. The reality is Snap is just one of several attempts in parallel by multiple people to solve a very real problem.
No, it isn't. I mean, it's not the same line of thinking. Systemd does only exist because of redhat. It doesn't solve any problems because there are things you can't do in unit files, so what you wind up having is unit files that cause systemd to call shell scripts, at which point you have gained nothing.
Snap, as shit as it is, addresses a real problem in a way that at least offers a solution to the problem. Systemd addresses a made-up problem in a way that doesn't even solve it. The only thing the two have
Re: (Score:2)
Systemd does only exist because of redhat. It doesn't solve any problems because there are things you can't do in unit files
Thanks for demonstrating your ignorance. Systemd is just one of about 15 separate attempts by different people to replace sysvinit. Claiming it doesn't solve a problem is just nothing more than gaslighting the many developers who actually know how the Linux boot process works.
Stop it, it's lame. Hate software as much as you want, but don't be an ignorant gaslighting arse in the process.
Re: (Score:2)
Claiming it doesn't solve a problem is just nothing more than gaslighting
The initial problem it claimed to solve was needing to write scripts to manage daemons.
It doesn't solve that problem.
Claiming that systemd solves that problem is the actual gaslighting.
Meanwhile it creates new problems. I switched away because I had an early boot problem which systemd's bullshit logging scheme wasn't capturing. It was actively preventing me from addressing the problem.
People who think systemd solves problems are provably the ones without understanding.
The total number of init systems which
Re: (Score:1)
Re: (Score:2)
I thought that systemd was created to boot faster by starting daemons in parallel.
That's a feature of systemd, but it's also a feature of other systems which predate its adoption, so it's not actually a change for most users.
Re: (Score:2)
You should be able to see, however, that Red Hat, Ubuntu, and similar distributions are actively trying to add scaffolding and extensions, like the original sin of Systemd, Snap, proprietary app "stores", and so on. It's Embrace, Extend, Extinguish, invented by IBM and arguably perfected by Microsoft. All companies want to be a monopoly. Red Hat and Ubuntu have taken Linux hostage, and and locked you into their ecosystem, while superficially being able to claim they are "Linux".
I think thoug
Re: (Score:1)
I'll be very interested to find out whether the gimp snap has the same problem as the Firefox snap: it does not work in a VNC session. Like at all. There's a known workaround involving futzing some environment variables, but it is not a complete solution: although it gets the main Firefox window to come up, additional popups (like the Save As dialog) are still broken.
This was always a problem right from the beginning, since Ubuntu replaced its native Firefox package with a snap, 2-3 years ago. Initially I g
Re: (Score:2)
I suspect you do not need to be told what to do to address this, and I am not running Ubuntu anymore so I do not know in any case, but last I checked the solution was to remove the snap for firefox and pin it away — and to install firefox as a deb package from the official PPA.
Re: (Score:2)
>"I suspect you do not need to be told what to do to address this, and I am not running Ubuntu anymore so I do not know in any case, but last I checked the solution was to remove the snap for firefox and pin it away â" and to install firefox as a deb package from the official PPA."
A better solution is to abandon Ubuntu and use Mint, instead. Which not only has a NATIVE Firefox package (and LibreOffice, and GIMP and Thunderbird, etc), but also doesn't use or force SNAP.
Re: (Score:2)
I abandoned Ubuntu and went to Devuan, so I got rid of snap and systemd at the same time. Good riddance to both pieces of garbage.
Re: (Score:1)
Yes, that's exactly what I did,
Re: (Score:2)
PPAs have different problems though. Instead of having a simple "Ubuntu" distro, every PPA you add is a new distro maintainer which you have to watch. Even if they are unlikely (but not impossible) to go totally bad and install malware, they definitely have policy changes, lose interest, decide that there's a better alternative PPA so they can give up on theirs but fail to inform their user base etc. etc.
It should have been something that was agreed with Debian and worked with both base distros - with a kin
yay snaps! (Score:4, Funny)
I've always wanted a version on the gimp that takes ages to start, runs slower and can access all the critical files in my home directory but not a plug in usb stick it a secondary drive for "security reasons".
Re: yay snaps! (Score:2)
Re: (Score:2)
It's 2025, no one cares about disk space. My Linux server is installed on the smallest SSD I could buy, and the drive is 90% empty.
Re: (Score:2)
Running GIMP and lots of snaps on your server?
Re: (Score:2)
>"I've always wanted a version on the gimp that takes ages to start, runs slower and can access all the critical files in my home directory but not a plug in usb stick it a secondary drive for "security reasons".
And takes up more RAM and disk space. And is less efficient, overall. And is more complicated and harder to troubleshoot. And take much, much, much longer to update. And if you do use containers, why would it be freaking SNAPS, of all forms available? It is the worst and most "proprietary."
N
The solution being to compile from source (Score:3)
This page describes how to build GIMP. [gimp.org]:
* build/linux - Building GIMP on Linux
* build/macos - Building GIMP on macOS
* build/windows - Building GIMP on Windows
Re: (Score:2)
What solution? The solution to the question "What if I want my system to be like Linux, except with the dependency hell of Windows 95?"
If you're compiling from source in 2025, you're actively working against your distro maintainer and you will be the one back here complaining "I tried to do a dist-upgrade and it broke my system!"
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
You could try and contact the writers of the source code and ask their advice.
So now, ironically ... (Score:2)
Installing GIMP is now a snap, but learning/using it still isn't. :-)
(Joking as one who stopped using Ubuntu when they completely Snap happy and switched to Mint.)
Unsafe (Score:1)
Thinking of Zed.. (Score:2)
Zed: "Bring out the Gimp!"
Maynard: "Gimp's sleeping."
Zed: "Well, I guess you're gonna have to go wake him up now, won't you?"
Snap is horrible (Score:2)