sourceforge ships drive-by downloaders

[abma]

http://www.gluster.org/2013/08/how-far- ... as-fallen/



where to move to?

didn't test if the spring installer is affected.

[jK]

strange, spring isn't affected atm

[FLOZi]

https://github.com/blog/1547-release-your-software ??

[abma]

if possible i would prefer to have two different sites...luckily we have springrts.com and we are not dependent on a single foreign site (thanks licho!) and this is how it should be in future, too.

[Kloot]

code.google.com?

[AF]

There is https://bitbucket.org/

[abma]

fyi:

the drive-by-downloader is an optional feature which can be enabled by the project developers to earn some money, seems to be not enabled by sourcefourge, so no worries. as long as its optional imo we can keep using sourceforge, if it for some reason enables such a downloader, imo we should try google-code... bitbucket is limited to 5 users.

[PepeAmpere]

I wouldn't take that message so bad. I would call it doomsaying a bit

If I understand correctly, its matter of project masters to agree with such product placement, which, as I expect, noone here wants.

[PepeAmpere]

ah, kind good abma (not that bad evil amba we are scary of) just said the same few mins ago

[SpliFF]

Not a high priority while the SF crapware remains optional but I do like the sound of the Github releases tool. If I'm reading it correctly it even seems to write your release notes for you (based on commit history).

It's a shame Windows is such a retarded platform when it comes to building software because what I would REALLY like to see is an installer that fetches the software from a Git repo and (optionally) builds it locally (like "emerge" for Windows) or else fetches binaries but does so using differential compression (ie, it only downloads the differences between what you already have and what is on the server instead of always downloading the entire package.

In other words if I download Spring 96.0 but already have 95.0 installed then I only need to download the changed parts (even changes within a file). Bittorrent actually does this but only for the exact same torrent, not upgrades or forks. Steam on the other hand DOES work like that so maybe we should even consider moving Spring and Spring games to Steam (The engine could be installed as a "tool" or SDK)?

[hoijui]

well.. the engine is like 20MB - 30MB. there is a new release every 6+ months.
in the worst case scenario, you are new, and you have to download the 3 latest releases, for 3 different games use them as default. so usually you would have to download 3 * 20MB, while with the delta compression stuff, you have to download 20MB + 2 * 15MB. in additional to that, you will probably download 10 * 30MB maps on the first day alone, plus the 3 games you will play, again 3 * 50MB. can't see how this is anyway meaningful. also... when a steam game is updated, and even if the change-log talks about some unit stat changes only, i have to download a minimum of 500+MB every time (no idea how they manage to do that).

it might make sense for testers, where releases follow each other in really short time intervals, and may have very little difference between each other.

[Anarchid]

Evo alone is 300mb, and zk is about that size.

That doesnt make the differential compression less nice of an idea, in fact, it only highlights how cool it is that all pr-downloader downloads except engine already are differential.

[SpliFF]

i have to download a minimum of 500+MB every time (no idea how they manage to do that).

Well, what you seem to be describing is either NOT differential compression or a very inefficient use of it. It might be because Steam's DRM and/or compression cause large changes to the gcf/ncf files when there are only small changes to the program but I could only speculate about that. To be fair I've seen Steam updates of as little as 300k so I think your updates may have been more than a few unit stats or the algorithm has improved over time.

I've had good results from both Git and Rsync differential updates to directories (zipped files are another matter but tarballs can be made 'rsync-friendly' when compressing.

[hoijui]

the difference is that the engine is mostly this one huge binary file, which i am pretty sure will have little similarity inbetween releases, and even if it had, it would make close to no difference, whether you download 20+0+0 or 20+20+20 MB the first time, or 0 instead of 20 MB once every 6 months, if you download like 300MB for ZK alone anyway (the first time), and 30MB whenever there is a new map being played.
not that it hurts, it is just practically close to no gain, except for testing releases.

[abma]

current win32 engine download file is about ~10MB: http://springrts.com/dl/buildbot/defaul ... e04/win32/

i see there few place for optimizations, it would be many work for little profit. also, with our current system, we want multiple versions installed, so patching existing files is not needed or wanted.

[SpliFF]

All fair points. If the engine is such an insignificant factor relative to the games/maps and a considerable amount of people are probably getting it through emerge/yum/apt anyway then I wouldn't burn any time on it either.