Sorry to bring the bad news: at the current use rate you shared, you will die of old age before your SSDs.

I was thinking that the offline installers were good but you are right, that is very inefficient...
Thanks for bringing me this insight!

Since GOG are posting threads regarding the future of the business I think this should be addressed. Yes better and faster offline installers should be on the list of things needing improvement.

but they are just posting

You would have thought so, seeing as the product they are selling is the installers. It’s not the case though. This focus on core values has so far: removed the good support, and added some sorting options. Not to mention reaffirming that “because this is the way the gaming industry is, we will carry on selling drm games, online gating, whatever it takes”.
Also, CDPR ransacked the place, taking resource and galaxy - the only thing that they are interested in.
Even looking at the last round of “updates” to offline installers was to change the naming of the files and to add in galaxy dependancies/components

Hate to break it to you, but if you've got Windows (or any OS) installed on an SSD it will wear out before the average lifespan of a human with regular use. The reason is the OS itself writes a bunch of small things (log entries, temp files it uses internally, etc.) to the system drive.

Personally, I've had a copy of Windows 98 burn out a 1GB SD card, and an old copy of Windows 7 burn out 512 GB SSD.

It's just a matter of writes.

As for the installers, the game industry itself is horrible with packaging. Most of the reason why is due to the multiple different packaging layers.

Take an Unreal Engine game or a game that uses some middleware like Criware for example. The base engine supports patches. As does the middleware. So does most of the systems that will try to use it. (Switch / PS5 / XBox / Android / etc.) In addition so does the distribution network (eShop / Steam / GOG / etc.) As a developer, which mechanism do you use?

Most would assume use the base engine support. But that may be difficult if the different game assets can't be easily split between all supported systems. (You might wind up needing to test and ship multiple patches to fix one bug in a script file. Due to the different textures used for different systems.) The middleware, system and distribution support all fall under this same issue as well. With varying numbers of patches to cover everyone. Some of those systems (like the Switch) don't support layered / nested patches. (I.e. There can only be one patch archive, and if a second patch is needed, the entire patch archive must be updated and redownloaded even if you only change one byte in an unrelated file.) This is useless for modern games where multiple patches are needed as SOP for most developers. All it does is transfer the massive bandwidth usage from the base files to the patch files. The system support is the one that tends to get used however due to most console manufacturers requiring code signing for updates.

As the system support tends to be the patch support that is used, systems that don't implement it like Windows, have to deal with the raw updates differently. This can be a good or a bad thing depending on the level of nested containers used by the game engine. If the game is just stored as raw files, the updates can be pretty small. As Windows doesn't care about code signatures for data files so patching them is easy. If the game is stored as a bunch of middleware archives (.cpk, .vpk, .wad, etc.) however, it depends entirely on whether or not the developer wants to sink the time and money into creating a Windows specific patch that uses the middleware's patching support. Guess what? Capitalism called, and they said: No.

I have one of the first SSD's ever released by Intel. It's still going to this day.

This suggests that using a ramdrive for temporary files and disabling logging (since few would understand it in the first place) might be a good idea.

Too bad the system isn't more like Slax or a liveCD where you boot the OS compressed in ram, and run everything only making changes to the drive when necessary. A core OS doesn't have to take up a lot of space, a few hundred megs would suffice.

Though in regards to SSD which is on par with just thumb drives... i remember having a 64Mb drive in 2005 when i joined the army, however by 2010 i think i was noticing slowdowns, reliability issues, at that point that i retired said drive.

Oh right reminds me regarding multiple files at 4Gb for installers; If anyone really wanted to optimize space on their DVD's/blueray backups, you could do a combo of tar/split to make said files any size you want (long as the FS supports it) though to make use of them you naturally have to un-tar the data first. I don't really recommend this, but it would be a bit more space efficient, though likely only linux users would know what i'm talking about.

The fact they still haven't rectified themselves tells me they don't GAF.

As much as I like an optimized installer that doesn't bloat temporary space and runs faster, I think what they sorely lack is quality of support for their offline games (nevermind the installers themselves) for their purported use-case (ownership of your games).

Some games are getting scaled back in version and the only way to get the latest version is via Galaxy (looking at your Police Stories).

And not only they don't provide any official client to backup your offline installers across platforms, but if you are involved with implementing an unofficial one, let me tell you that interacting with their apis to retrieve offline installers is stupidly difficult to automate.

Not only is elegant login integration non-existent (without scrapping the login and dancing around recaptchas), but their api endpoints are also all over creation (you need to make THOUSANDS of api calls to get complete data on all your game files) and often downright flaky (often erroneous triple requests metadata endpoint, dangling files that point to nothing in your library, ambiguous duplicated files across languages... I could go on).

And right now I'm adding extra functionality to fetch all the metadata (screen shots, descriptions, etc) for your games... don't even get me started on that.

Nevermind whoever designed their installer packages. I've love to have a talk with the wunderkinds that initially implemented their apis in php. They've wasted days of my life at this point that I ain't getting back.

At the very very least, at least GOG provides us with offline installer (it would be a pain if it is an online installer). Having able to download the installer from your smartphone is quite a luxury.

Because they cost money.

Have a solution, but it takes a bit of thought.

Edit, moved the code to another thread, as it sat. Have fun.

Someone can create a boycott thread over this if it makes them angry enough (since the current boycott thread is exclusively for DRM and censorship).

As if GOG would allow multiple different Boycott threads on their forum. No doubt they wouldn't. They'd lock all subsequent ones on the basis that they are "duplicate threads" or something like that.