From owner-freebsd-current@FreeBSD.ORG Sat Mar 31 00:57:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34C14106566B for ; Sat, 31 Mar 2012 00:57:06 +0000 (UTC) (envelope-from deeptech71@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AFAA18FC17 for ; Sat, 31 Mar 2012 00:57:05 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1016423wgb.31 for ; Fri, 30 Mar 2012 17:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XDMphV/LNwJD36/i/9zuO/+K0hPkCnDZxvSsW8qOA1Q=; b=zQwkszRv2lF1bHpLEUfoKN31p9o4Nb9yruZWHgpzq3SgR4y8r1UOG/jDM02GixH+iK 0ibGW+jw6W2/d73dDGs+N6li1bPt0OK+z1IoCrgj4l/+vOgmkRVRmOs99gqqdTemAcTP oM+9MSU1Oex6SxY6tcQLRIxNCa0kBfsTaAUPamarPtwSsZ/XIK/uo4f2Ft/O7fOaTVZF hPWfZmrSree1nQdAQQBFrbzGMWuJkIGfj2ebcDM5UZVkn9ea6V2PBUzGPup3MoRZ30I2 a+ONlpwKLN5W+xDLKjbiLUF4HHZkz1ElWg2PoDyFqZEHgUaj9ygFgO3vlrQJWKnI7qCz 7CuQ== Received: by 10.180.85.70 with SMTP id f6mr2214036wiz.5.1333155424499; Fri, 30 Mar 2012 17:57:04 -0700 (PDT) Received: from [192.168.1.80] (dsl4E5C3B90.pool.t-online.hu. [78.92.59.144]) by mx.google.com with ESMTPS id fl2sm17602164wib.4.2012.03.30.17.57.02 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 17:57:03 -0700 (PDT) Message-ID: <4F765682.5040707@gmail.com> Date: Sat, 31 Mar 2012 02:57:38 +0200 From: deeptech71@gmail.com User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:11.0) Gecko/20120320 Firefox/11.0 SeaMonkey/2.8 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4F746F1E.6090702@mail.zedat.fu-berlin.de> <4F74BCE8.2030802@vangyzen.net> <20120330.151848.41706133.sthaug@nethelp.no> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Using TMPFS for /tmp and /var/run? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 00:57:06 -0000 C. P. Ghost wrote: > Not clearing /tmp on reboot has been > the norm for way too long and it is too late to change now. We either evolve or be in a stalemate forever. > It's not just POLA, it also involves deleting data of unaware > users, and that should be avoided. Mounting on a directory (/tmp) does *not* clear that directory, so automatic data loss will not occur. Adrian Chadd wrote: > One of those reasons people stick/stuck with BSD is that we don't go > and change this stuff so quickly. Yes, it would be a total of ~20 years before we finally decided to switch to using TMPFS for /tmp. Changes that potentially break the POLA can be categorized; a change has a combination of the following properties: (1) the change fixes a bug (ie., the change is about something that should have been different in the first place, eg., the change fixes the misspelling of a command name) (2) the change can be prepared for (ie., enough time is given for the user base to slowly switch the new method of doing things) (3) the change is evolutional (ie., the change is based on a decision to yield a net benefit (not necessarily a benefit in all cases)) (4) the change has priorly been given room (ie., is expectable as defined by standards and the documentation) The TMPFS-for-/tmp change obviously falls into (4), and surely into (3). With the support of UPDATING entries, release notifications, and perhaps announcements, the change also falls into (2). Furthermore, using TMPFS for /tmp is analogous to adding assert()s to code. Noone is really breaking the POLA that much. The TMPFS-for-/var/run should not even bother anyone.