Re: [hlds_linux] BZip2 compression methods
I think we need a slightly better description of the problem you're
trying to solve.
My interpretation of your original post is that you have a large number
of files to compress, but many cores. You tried pbzip2 (Parallel BZIP2)
and the resulting files couldn't be decompressed.
Have you confirmed that the pbzip2 compressed files are decompressible
by normal bzip2? The page for pbzip2 indicates that they should be
compatible with bzip2 1.0.2 or newer.
The problem could be that the game is using a bzip2 algorithm that isn't
compatible with bzip2 1.0.2.
Shane
On 3:59 PM, Philipp Reddigau wrote:
> Hi,
> Thank you for the reply.
> But this will compress up to 10 files at once.
> It will not compress one file on more than one core.
> It would be better and much faster if one file compressed by 8 or 16 cores.
>
> An Example: (we are do it like your skript)
> 5000 files:
> normal method(one file at time one core):
> 7h 34m
>
> like your skript(15 files on 15 cores): !extreme load, hdd is unusable!
> 1h 37m
>
> pbzip2(8 cores): !all is right, hdd usuable!
> 1h 43m
>
> Take care at the number of cores.
>
> Mit freundlichen Grüßen,
> Philipp Reddigau (GKServer)
>
> GKServer
> Daniel Zschau
> Niederfährer Straße 38
> 01662 Meißen
>
>
> -Ursprüngliche Nachricht-
> Von: hlds_linux-boun...@list.valvesoftware.com
> [mailto:hlds_linux-boun...@list.valvesoftware.com] Im Auftrag von kama
> Gesendet: Donnerstag, 21. Januar 2010 14:17
> An: Half-Life dedicated Linux server mailing list
> Betreff: Re: [hlds_linux] BZip2 compression methods
>
>
>
> On Thu, 21 Jan 2010, Philipp Reddigau wrote:
>
>
>> Hi,
>> we are using a automatic *.bz2 for our content servers (fastdownload) on
>> nix/lenny.
>> It works fine with bzip2 --compress --keep --force --best "$file"
>> But we have one Problem..we have many files to compress and one bzip2 is
>>
> not
>
>> enough.
>> So we have tried pbzip2 after compress join on server "Could not CRC
>> blabla".
>> So the game cannot decompress the file..
>> I there a way to get it clean with any other compress program?
>> (multithreaded)
>> Anyone knows witch exact format is required, that the games can decompress
>> it?
>> I cannot find any information about the decompression.
>>
> maybe do a script that does it for you instead...
>
> This script will keep you at max 10 instances of bzip:
>
> -- snip--
> #!/usr/local/bin/bash
>
> max
>
> for file in $*
> do
> bzip2 --compress --keep --force --best "$file"&
> while [ `ps aux | grep bzip | awk 'END { print NR }'` -ge $max ]
> do
>sleep 1
> done
> done
> -- snap --
>
> This is just an example. There are probably ways to tune it and make it
> better.
>
> /Bjorn
>
> ___
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
>
>
>
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Valve Source Engine Console Message Format String Vulnerability
Saul, You're mistaken. The C++ portion of the code base at my current employer is statically linked. We've been compiling the code that way for close to a decade. The code itself uses STL, streams, makes heavy use of templates, etc. We build on Debian and release on RedHat/CentOS and Solaris (albeit rarely now). Shane Turner Saul Rennison wrote: > If you knew anything about C++ you'd understand how unportable STL is > across various Linux distributions, and how impossible it is to > statically link it into the code. > > Thanks, > - Saul. > > On 18 Aug 2009, at 21:03, Stefan Popp wrote: > >> Thats not right ;) >> >> The programming language is the problem in this case. Why should i write >> my code with functions that shouldnt be used with C++? >> C++ works with the stdlib, which means streams. Not C stuff. So its >> finally up to Valve to write programs which follows C++ standards not C. >> You cant trust your users as programmer. Its up to us, to make the >> source safe, and if the projecttime needs 2 weeks more, you should spend >> the time. >> >> >> Ronny Schedel schrieb: >>> The problem is not the programming language, the problem is that >>> Valve trust >>> their game clients too much. >>> >>> >>> >>>> Well, >>>> >>>> Valve should start coding c++ with steams ;) >>>> Who works with printfs today? >>>> >>>> I hope Valve will fix the whole source to prevent overflows. >>>> C++ is you friend, not old C stuff... >>>> >>>> Best regards, >>>> Stefan Popp >>>> >>>> >>>> Claudio Beretta schrieb: >>>> >>>>> Thanks, anyone knows if a workaround is available? >>>>> >>>>> BTW: aren't "security researchers" supposed to contact the developers >>>>> before >>>>> releasing 0-day exploits?This is the 2nd 0-day exploy from aluigi >>>>> in a >>>>> few >>>>> weeks -.- >>>>> >>>>> >>>>> On Tue, Aug 18, 2009 at 6:44 PM, Morgan Humes >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> A friend forwarded me this info regarding a vulnerability. I am >>>>>> unable >>>>>> to >>>>>> test this at the moment, but it does look like it is possible. >>>>>> Thought >>>>>> I >>>>>> would get this out to the community before others start using >>>>>> this to >>>>>> cause >>>>>> havoc. >>>>>> >>>>>> http://www.vupen.com/english/advisories/2009/2296 >>>>>> http://aluigi.altervista.org/adv/sourcefs-adv.txt >>>>>> >>>>>> Morgan Humes ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
