From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C07F5139083 for ; Wed, 6 Dec 2017 16:12:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 92E65E0F7C; Wed, 6 Dec 2017 16:12:30 +0000 (UTC) Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 2F143E0EC9 for ; Wed, 6 Dec 2017 16:12:30 +0000 (UTC) Received: from [192.168.1.64] (host86-176-79-41.range86-176.btcentralplus.com [86.176.79.41]) by auth-4.ukservers.net (Postfix smtp) with ESMTPA id 59BF61520CC4 for ; Wed, 6 Dec 2017 16:12:26 +0000 (GMT) Subject: Re: [gentoo-user] is multi-core really worth it? To: gentoo-user@lists.gentoo.org References: <6b5fbeca-453c-f103-5e4e-a8db83a6dabf@st.com> <6661527.9k004Oio64@eve> <1768467.U8M6HPhz0d@peak> <20171205215627.6fec87e3@digimed.co.uk> <5A27F0BC.6000802@youngman.org.uk> From: Wols Lists Message-ID: <5A2816E9.1010102@youngman.org.uk> Date: Wed, 6 Dec 2017 16:12:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 78ffd7a2-009b-4d82-b524-cd3083a92cfe X-Archives-Hash: 1f50bd8b2ddb36edd84740e14daab629 On 06/12/17 15:34, Alan McKinnon wrote: > Those guidelines you mention about what /tmp and /var/tmp are "for" are > probably from the FHS. On the whole, I tend to agree they are good ideas > but the proper wording is more like this (from memory, being far too > lazy after a day's work to actually look something up): > > - contents of /tmp are not expected to survive the invocation of the > program that created them http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES > - contents of /var/tmp are not expected to survive a reboot > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARTMPTEMPORARYFILESPRESERVEDBETWEE > Which is different from what you said. Except that /var/tmp is exactly the opposite of what you said :-) Not surprisingly, if you follow > that through, you can run rm -rf /tmp/* in a cron every minute and > nothing should ever break. Or, every file in /tmp can be anonymous (just > an inode without a dentry giving it a name) Cheers, Wol