Re: make the cvs build zips smaller?
On Wed, 3 May 2006, Jonathan Gordon wrote: ive setup my computer with linux and moved it downstairs so it can stay on 24/7 so youve got another build server if u want it (celly 2.4ghz, 512mb ram), the only downside is that my uploads are capped to about 20KB/s so uploading the 2mb zip actually takes longer than compiling... We're on 45 builds in the CVS table right now, and only 12 or so of them transfer anything back. But yes, adding a 100 second transfer time to the single build is of course no fun. so, my suggestion (also happens to decrease your bandwidth usage also) is to strip the non-comiled stuff into a seperate zip for all targets.. (fonts, docs, wps, cfg, etc). removing this from the build dropped 1mb off the zip size... which would work out a fairly big bandwidth saving for everyone seen as these dont really need to be updated frequently... (actally english.lang prob would need to be in the zip...) This is repeatedly discussed and we've been planning on doing something like this for the 3.0 release. I can't say I have all details sorted out in my head yet as in how this will affect users and how users will know when they want to get a full package and a subset package. But I don't think having the cvs builds do light packages is a solution to anything as there will still be people who want to download a full version and then we need to offer such ones. Doing full/light packages will help the users who download packages, not build servers that create them. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: make the cvs build zips smaller?
On 5/3/06, Daniel Stenberg [EMAIL PROTECTED] wrote: But I don't think having the cvs builds do light packages is a solution to anything as there will still be people who want to download a full version and then we need to offer such ones. Doing full/light packages will help the users who download packages, not build servers that create them. Could the central build server not repackage submissions from such slow-connected-servers ? Or let the central server do the packaging only. ~lImbus
Re: make the cvs build zips smaller?
I can highly recommend 7-zip to make things smaller still. It worked wonders for The DevKit ...try it, I think you'll be pleasantly surprised :) And to boot it's all gpl open-source etc. :)) ive setup my computer with linux and moved it downstairs so it can stay on 24/7 so youve got another build server if u want it (celly 2.4ghz, 512mb ram), the only downside is that my uploads are capped to about 20KB/s so uploading the 2mb zip actually takes longer than compiling... We're on 45 builds in the CVS table right now, and only 12 or so of them transfer anything back. But yes, adding a 100 second transfer time to the single build is of course no fun. so, my suggestion (also happens to decrease your bandwidth usage also) is to strip the non-comiled stuff into a seperate zip for all targets.. (fonts, docs, wps, cfg, etc). removing this from the build dropped 1mb off the zip size... which would work out a fairly big bandwidth saving for everyone seen as these dont really need to be updated frequently... (actally english.lang prob would need to be in the zip...) This is repeatedly discussed and we've been planning on doing something like this for the 3.0 release. I can't say I have all details sorted out in my head yet as in how this will affect users and how users will know when they want to get a full package and a subset package. But I don't think having the cvs builds do light packages is a solution to anything as there will still be people who want to download a full version and then we need to offer such ones. Doing full/light packages will help the users who download packages, not build servers that create them. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: make the cvs build zips smaller?
On 5/3/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Wed, 3 May 2006, Bluechip wrote: I can highly recommend 7-zip to make things smaller still. It worked wonders for The DevKit ...try it, I think you'll be pleasantly surprised :) And to boot it's all gpl open-source etc. :)) ... and we've supported 'make 7zip' in Rockbox for a while already. I just don't think the world is ready for us to switch all our official builds over to 7zip completely instead of zip. Wasn't there that normal zips compressed with 7zip are smaller than normal zips compressed with normal zip ? ~lImbus
Re: make the cvs build zips smaller?
At 14:39 03/05/2006, you wrote: On 5/3/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Wed, 3 May 2006, Bluechip wrote: I can highly recommend 7-zip to make things smaller still. It worked wonders for The DevKit ...try it, I think you'll be pleasantly surprised :) And to boot it's all gpl open-source etc. :)) ... and we've supported 'make 7zip' in Rockbox for a while already. I just don't think the world is ready for us to switch all our official builds over to 7zip completely instead of zip. Wasn't there that normal zips compressed with 7zip are smaller than normal zips compressed with normal zip ? Yes, it will ALSO make an optimised gzip file by using an adaptive multi-pass huffman table generator :) BC
Re: make the cvs build zips smaller?
On Wed, 2006-05-03 at 17:14 +0200, Manuel Dejonghe wrote: On 5/3/06, Bluechip [EMAIL PROTECTED] wrote: But I found that even with a self-extractor stuck on, the .7z.exe file was still smaller than a gzip file [whether created by 7zip or gzip] ...I would suggest this be checked for a Rockbox distro as it is (by nature) considerably smaller than anything I have worked on (relevant to this post). er. This self-extractor, isn't that a operating-system dependant executable ? Indeed. Eeeek. smime.p7s Description: S/MIME cryptographic signature
Re: make the cvs build zips smaller?
When talking about a platform specific solution, how about a web-aware windows *updater*? I'm thinking of a small wizard that - can be placed on the filesystem of the dap itself - can look up its settings from a config file on the player (say, /.rockbox/wizard.cfg) which stores player type, installed version and misc stuff like proxy settings - asks the user about the settings if no configuration found, - gives the possibility to install the latest release, daily or cvs build - downloads the file and installs it on the player. This way it could be made 7zip-aware and be dap independent. I guess the world outside of windows should be ready for 7zip (hmm, I don't know about 7zip for MacOS). Being it an updater also doesn't need to handle the bootloader itself (for devices that need one) so I guess this could be a pretty small program. - Dominik
Re: make the cvs build zips smaller?
At 16:14 03/05/2006, you wrote: On 5/3/06, Bluechip [EMAIL PROTECTED] wrote: But I found that even with a self-extractor stuck on, the .7z.exe file was still smaller than a gzip file [whether created by 7zip or gzip] ...I would suggest this be checked for a Rockbox distro as it is (by nature) considerably smaller than anything I have worked on (relevant to this post). er. This self-extractor, isn't that a operating-system dependant executable ? Poo! Yes! Hm! ~lImbus
RE: X5 dual boot
Hi list, I have a *working* X5 dual-boot patch (#5289). I rebased the RB bootloader and merged it into the OF. I prefixed crt0.S with a small routine that dispatches either RB or the OF based on whether REC button is pressed or not. Comments are welcome. R. P.S. The problem was a bge vs. ble thing.
Re: X5 dual boot
On 5/4/06, RaeNye [EMAIL PROTECTED] wrote: I have a *working* X5 dual-boot patch (#5289). I rebased the RB bootloader and merged it into the OF. I prefixed crt0.S with a small routine that dispatches either RB or the OF based on whether REC button is pressed or not. Congratulations. From what I heard before, a dual boot was due, and not planned by cowon. ~lImbus
Re: make the cvs build zips smaller?
Compression algorithms like 7zip, RAR, bzip2, etc tend not to be wins (except for very large files) since they use *much* more CPU time for relatively minor size savings. If you're concerned about server load, 7zip is a bad idea and best case scenario is that you'll only see 15-30% filesize savings.
Re: make the cvs build zips smaller?
On 5/4/06, bk [EMAIL PROTECTED] wrote: Compression algorithms like 7zip, RAR, bzip2, etc tend not to be wins (except for very large files) since they use *much* more CPU time for relatively minor size savings. If you're concerned about server load, 7zip is a bad idea and best case scenario is that you'll only see 15-30% filesize savings. I don't see the point, as the original concern was cpu power bandwidth ~lImbus
Re: make the cvs build zips smaller?
On Thu, 4 May 2006, Manuel Dejonghe wrote: 7zip is a bad idea and best case scenario is that you'll only see 15-30% filesize savings. I don't see the point, as the original concern was cpu power bandwidth Yeps. In my quick and naive zip/7zip compression tests I did a number of months ago, the typical gain for a rockbox.zip was in fact more than 30%. Since we're talking about packages that are downloaded thousands of times *every day* we would also cut down on bandwidth for the server(s) hosting the downloads. (If we also count the daily builds.) -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
