Re: [sdcc-devel] [Fwd: [ alexandria-Support Requests-1588418 ] increase sdcc web quota]

[Borut R. <bor...@si...>]

Maarten Brock wrote:
> Borut,
>
> Do you have an idea why the i386 linux snapshot has grown so much today?
>
>   
Yes, I have the idea ;-)  : I added readline5.dll, required by sdcdb, to 
the setup package.

> And if we need to cut down I propose to replace the .zip snapshots with
> .7z files. I just ran a test and it (7zip) compresses the zip contents
> faster to 7z than to zip format and uses only 2MB instead of 7MB. But
> maybe another zip implementation is faster. 7zip is free, open source
> software contrary to zip/rar/whatever.
>
>   
The LZMA algorithm - the one used by 7-Zip - is used by the Windows 
setup packager too. That's why the setup.exe packages are so small in 
comparison with .zip packages. I'm afraid that 7-Zip is not so widely 
used as zip, that's why I didn't change the packaging. But on the other 
hand, the setup.exe is now the recommended installation method on 
Windows, so I agree that we can really switch from zip to 7z and save 7 
x 5MB = 35MB of disk space.

By the way, zip is also open source, at least the info-zip 
implementation using the BSD based license, and the zip algorithm is not 
patented.

> Then again, why not use 7z for all snapshots. The command line version is
> not limited to windows but available to all OS's. The source tar.bz2
> (3.1MB) becomes tar.7z (2.3MB)
>   

I wouldn't dare to do that before asking developers and users using sdcc 
on *nix platforms. I think that p7zip utility is not a part of standard 
(default) installations (I haven't found it on my FC5 Linux 
installation), so we risk a (contra)revolution if we change the packaging.

But, in the end, I don't think that the problem is the amount of disk 
space we are requesting from SF, but the fact, that we are (supposedly) 
doing something which is against the SF rules: "The storage of nightly 
tarballs ... is not allowed in the project web space.", as written in 
Acceptable Use, chapter 6. I hope that they'll take my arguments and let 
us work in the old-fashioned and successful way...
> On the whole I agree that we cannot go release the snapshots on a daily
> basis through the file release system, but I do regret that snapshot
> downloads do not count in the file download statistics.
>   

I hope that this will be fixed when (and if) SF will introduce the 
Snapshot service...
> Let's see where this leads.
>   

I'm curious too ;-)

Borut