From owner-freebsd-current@FreeBSD.ORG Sun Apr 1 13:40:52 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 1D11B106566C for ; Sun, 1 Apr 2012 13:40:52 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id D87748FC08 for ; Sun, 1 Apr 2012 13:40:51 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SEL17-000K6v-4s; Sun, 01 Apr 2012 09:40:25 -0400 Date: Sun, 1 Apr 2012 09:40:25 -0400 From: Gary Palmer To: deeptech71@gmail.com Message-ID: <20120401134025.GC76647@in-addr.com> References: <4F746F1E.6090702@mail.zedat.fu-berlin.de> <4F74BCE8.2030802@vangyzen.net> <20120330.151848.41706133.sthaug@nethelp.no> <4F765682.5040707@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F765682.5040707@gmail.com> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-current@freebsd.org 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: Sun, 01 Apr 2012 13:40:52 -0000 On Sat, Mar 31, 2012 at 02:57:38AM +0200, deeptech71@gmail.com wrote: > 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. Other than catching software that mistakenly assumes /tmp and/or /var/run is persistent, what are the CLEAR advantages for changing the default? Has consideration been paid to low-memory systems? I think this discussion is fast becoming a bikeshed and distracting people from real work on improving FreeBSD. Without clear advantages from a switch to tmpfs(5) or md(4) non-persistent storage the default should stay the same, especially on release branches. If people want that behaviour, the switches are already there and while I may have missed it, I don't believe there hasn't yet been suitable justification for making the change. Gary