I was downloading the latest version of GIMP the other day and thought it was rather large so I checked the various version I’ve downloaded over the years and… wow. Here’s a summary:
Over 15 years GIMP’s installer (the Windows one anyway but other platforms seem similar) has ballooned to nearly 20 times its size. What explains this enormous increase? Even with a larger graphics library and a ton of new features I might have expected it to double of triple in size at the most. Is something very inefficient being done here?
GIMP 2.10.38 have three archs (x86 32-bit, x86 64-bit and ARM 64-bit). That’s not true from GIMP 2.62.8 up to some versions of GIMP 2.10, which have only two archs.
Rectifying my comment above, 2.6 series don’t have universal installers (see: Index of /gimp/v2.6/windows/) so you are making a even more reckless comparison, with all due respect.
Yeah as @brunvonlope notes, first of all, we moved from 1 architecture to 2 architectures and since very recently to 3 architectures.
Also all data got bigger too. If you look at the splash image logs, it’s funny how what was considered a splash screen back then would nearly be considered a thumbnail nowadays: images/splash-log.md · main · GNOME / gimp-data · GitLab
Of course, this is a single image, but it’s a good example of how what was standard image size many years ago is far from standard nowadays. And we have a lot more image data in GIMP! For instance we have hundreds of icons (I count more than 700!), to be multiplied by 3 (we have 3 icon sets these days, though 2 of them became fortunately vector now). We also have dozens of cursors, each in 2 sizes to handle high density displays. Themes also have images. Then we have all the image data (brushes — and we added MyPaint brushes a few years ago —, patterns, and so on).
I also count 83 translated languages these days. The compiled data for every language can be heavy: if I look randomly at the French .mo files on my system, they take 828KiB; Spanish ones take 912KiB! And I am only counting core GIMP translations but our installer will also embed the ones for dependencies we rely on (translations in GEGL, GLib, GTK, and many more!)! From these numbers, it is easy to realize that every language (at least the ones with most complete localization) may take a MiB or more of disk space just with localization data! Multiply this now by 83.
Add to this that when we add more features, it often comes with new dependencies. Also existing dependencies also grow up in size themselves.
And so on, and so on.
Having installers make a diet is something we have done all the time across the years, and we will continue to do so. But there is just so much we can do with limited time.
Of course, I’m sure we miss stuff, which is why we welcome contributors willing to help with packaging work.
The main bit I don’t understand is the different architectures. The vast majority of PC users will be using x86-64 so it’s a real waste for them to be downloading data for any other archs.
Even for x86-64 we still need 32-bit, because of the TWAIN plug-in, which is traditionally only 32-bit. We will work on deprecating this soon after 3.0 in favor of a WIA plug-in.
I think one important point we are learning from the macOS distribution, where the 2 architectures are separate, is that a considerable amount of people are not aware of what architecture their computer is running based on the regular questions we get about GIMP not being able to run.
Indeed. We have regular reports of people when GIMP doesn’t work on macOS. Then we ask them which of the 2 packages they downloaded (often they didn’t even realize there were 2 packages, maybe they just clicked on whatever big “Download” button came under their mouse pointer?) and we see that they have no idea what architecture they are running.
While people following technology news closely will have heard of Apple Silicon, or M1, M2, etc. For most people, all they know is that they bought the last model of a given brand.
Now we have only a few thousands of daily macOS package downloads… while we have a few dozens of thousands of daily Windows installer downloads. Imagine all the reports we’d get if we didn’t have a universal installer auto-detecting the proper architecture!
The whole industry is pushing towards either ARM (we have contacts with various big hardware or software makers and we can see this is a big deal for them) or even at some extents more and more are experimenting with RISC-V. Thinking that x86_64 is the architecture we should prioritize… well I can understand believing this when you are not in the core of the industry. But it’s not the direction things are going to.
Last point: we will very likely soon drop the x86 (32-bit) architecture anyway. Not really because we want it, but because the MSYS2 project we depend on is slowly getting rid of this architecture. What we want is to at least release a few versions of GIMP 3.0 with x86 support so that people with machines in this architecture have at least some access to a modern version of GIMP (even though they soon won’t have any update, which is not very cool).
In fact I would have preferred not dropping this architecture that soon, because it will basically deprecate a whole range of hardware which will eventually only be good for trash (if they have nothing to install, what’s the point). Ecologically it’s bad. Despite what some say, there are even some hardware still being constructed with this arch. It’s clearly not much, but it still exists nowadays. So it’s even sadder to me. But again, it’s not like I have the ability to go against the direction which the whole industry is taking. So we’ll follow too.
And then the universal installer will very likely do a big diet (one less architecture!) so you should be happy when that happens!
Is it time to consider a two-phase installer, in which the first is a small multi-architecture package that works out which GIMP package should actually be installed, and does so?
Well that’s what the universal installer already does.
Or you meant for the macOS packages? If so, yes it’d be nice (we know it’s also possible there), but then the problem is the lack of time of our macOS packager.
@Jehan I think Liam is talking about the universal installer download the arch-specific installer and install it in the background.
I am partial to say that, since I touched a bit installer code, by I prefer our offline installer and wouldn’t change anything of Jernej work in that matter. It is just perfect.
Even with the 32-bit drop, I prefer to mantain the universal installer with both x64 and arm64 together. We will remain avoiding a lot of pains.
Oh I see. So the installer contains basically nothing then downloads the actual data. I foresee 3 issues with such installer:
If the machine is behind some proxy or other complex network configuration, will it work well? (I think modern network APIs get the correct network configuration from the system, but we all know that “problems” still happen)
What about offline installations? (e.g. you download the installer, put it on some USB key and plug it on another computer with no network)
What about people doing massive installations, like in universities, companies, etc. Right now, they can automatize it all on local network. But if the installer also requires to download from internet, it may become messy.
Anyway I can definitely see that it can be seen as a good idea under some perspective (namely much smaller download, multiplied by the dozens of thousands of daily downloads), but it has its own problems too.
An alternative could be to have 2 installers (a minimum + a complete one), but then we get back to the messy situation where “too much choice removes the choice”, i.e. people are lost with what to download. Also it’s additional work.
Anyway in the end, I’m mostly giving some opinion. The people who do are the people who choose.
I would only intervene if something feels really wrong, but apart from this, I’m just keeping up-to-date with the chosen solution and supports it (even if it may or may not always be my preferred solution). So yeah: go team!
First, i 100% agree it’s the people who do the work who choose, and the work has been fantastic and helped large numbers of people.
Second, yes, i did mean that the first stage installer downloads the 2nd. I agree this is a pain for people who download the installer and then go offline and want to install.
In a corporation or university, sometimes it can be possible to reconfigure a two-stage installer to fetch a locally-hosted copy, which can save the organization a lot of bandwidth and help them make sure everyone installs a version their IT department has tested.
At any rate, thinking about it and deciding No is fine.
A second approach might be to have separate installers but make sure if you have the wrong one it pops up a window saying you have the wrong one. But i don’t know how easy that is to achieve on the Mac especially. The Mac install is already a little tricky for some people, who download the installer and double-click on it each time they want to run GIMP! (as far as i can tell from the questions i get asked)
You definitely want to give people a way to download any installer, regardless of what the “proper way” is going to be. Just think about downloading an installer on a completely different platform.
yes - having an “installer chooser” that’s downloaded first doesn’t preclude people downloading the real installer. At any rate, doesn’t look like there’s interest in this approach right now.
