From owner-freebsd-ports@FreeBSD.ORG Tue Nov 30 02:16:30 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE504106564A for ; Tue, 30 Nov 2010 02:16:30 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7B72D8FC08 for ; Tue, 30 Nov 2010 02:16:30 +0000 (UTC) Received: by vws9 with SMTP id 9so1657724vws.13 for ; Mon, 29 Nov 2010 18:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=JxgTac+BUpT/YcV+E7gj1dN29zcfwb563farDfEqi20=; b=eouyQCPuyjPGXnF2TVzjo+05ePGlG1GWjTA+GpkkJ5HkWLnom/sfmmqe2O1QGPaK5J L1jKDQNGY4iS838xtleaombhoaBVMswSqoe1F/hj+v6qE7jHIPBhXINrEsAn+apKo7Ai p1/biCL8GkLBHfQuPT6QNybLPJbwioS7TiQTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QBlQhus1qQpU+N/8rtFWQf5rxYmhbkLBvKWIZRIlcej5Ewk7c0BSZLSlv2xPaZgfA1 jKHhOEuVyWksOOLYQrri6Im/FlBAfQ8XZRrGZ+CmnOWmXVJ+dPyEYLZbtJcZIjvFVqdn iMqlVff1l3a7DJiRn4Q8r5MI9EmT+ADpz5Cgw= Received: by 10.220.199.134 with SMTP id es6mr1656523vcb.145.1291083389618; Mon, 29 Nov 2010 18:16:29 -0800 (PST) Received: from centel.dataix.local (adsl-99-19-40-65.dsl.klmzmi.sbcglobal.net [99.19.40.65]) by mx.google.com with ESMTPS id p30sm885598vcf.2.2010.11.29.18.16.27 (version=SSLv3 cipher=RC4-MD5); Mon, 29 Nov 2010 18:16:28 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CF45E7A.80102@DataIX.net> Date: Mon, 29 Nov 2010 21:16:26 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Matthias Andree References: <4CF38D7F.6070206@gmx.de> <4CF3F16E.3020501@DataIX.net> <4CF439F1.6050703@gmx.de> In-Reply-To: <4CF439F1.6050703@gmx.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: packages compressed with xz X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2010 02:16:31 -0000 On 11/29/2010 18:40, Matthias Andree wrote: > Am 29.11.2010 19:31, schrieb jhell: > >> Adding to this, as the manual says... The decompressing host will need >> to have at minimal 5% -> 20% of memory 'available' for decompression of >> what the compressing host had. Seeing as FreeBSD still runs on systems >> with memory as little as 200MB "~20% of 1024MB" and quite possible to >> run on systems with memory of 64MB "~5% of 1024MB" I would not see any >> benefit in modifying the default memory limit on a compressing host to >> accommodate for these system rather than using gzip(1) or bzip2(1) by >> default. > > You can specify limits during compression, so the question is should we do that > so that hosts with N MB of RAM can decompress packages? Do we retain the > compression ratio over bzip2 if we limit compression memory to 512 MB so that > decompression would be possible with, say, 128 MB? > Hosts that have [N]MB of "free or available" memory. Most systems in this case will not have a whole lot of RAM available in any case as they are likely to be utilizing it to its upper most potential. Doing such limiting on the compressors part I would think, be more of a waste of resources as such can be achieved by default just sticking with bzip2(1). Besides, limiting memory to 512MB to what ? shave an ~ small percentage off the top of a resulting package. >> It would be nice to support xz(1) compression for large selective >> packages like firefox or openoffice as those will never run on smaller >> systems. > > Yes, would be nice. I doubt it will happen soon. > Agreed. Soon can be quantified by actual need and of which there is not much need except for larger packages but adding this would just add unneeded complication to the system that is already in place. ~ JMO -- jhell,v