From owner-svn-src-head@FreeBSD.ORG Fri Dec 2 15:32:59 2011 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E21B106566B; Fri, 2 Dec 2011 15:32:59 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id CFDED8FC13; Fri, 2 Dec 2011 15:32:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LVL00I061UYBV00@smtpauth1.wiscmail.wisc.edu>; Fri, 02 Dec 2011 09:32:58 -0600 (CST) Received: from comporellon.tachypleus.net ([unknown] [76.210.61.201]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LVL00FSV1UQNV00@smtpauth1.wiscmail.wisc.edu>; Fri, 02 Dec 2011 09:32:51 -0600 (CST) Date: Fri, 02 Dec 2011 09:32:49 -0600 From: Nathan Whitehorn In-reply-to: <4ED8EC14.6000000@FreeBSD.org> To: John Baldwin Message-id: <4ED8EFA1.80104@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.61.201 X-Spam-PmxInfo: Server=avs-11, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.2.152118, SenderIP=76.210.61.201 References: <201112020038.pB20cmt6068628@svn.freebsd.org> <20111202094411.GJ23987@goofy01.vnodelab.local> <4ED8EC14.6000000@FreeBSD.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111113 Thunderbird/8.0 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ken Smith , Joel Dahl Subject: Re: svn commit: r228192 - head/usr.sbin/bsdinstall/scripts X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 15:32:59 -0000 On 12/02/11 09:17, John Baldwin wrote: > On 12/2/11 4:44 AM, Joel Dahl wrote: >> On 02-12-2011 0:38, Ken Smith wrote: >>> Author: kensmith >>> Date: Fri Dec 2 00:38:47 2011 >>> New Revision: 228192 >>> URL: http://svn.freebsd.org/changeset/base/228192 >>> >>> Log: >>> Add a screen that asks if the user would like to enable crash dumps, >>> giving them a very brief description of the trade-offs. Whether the >>> user opts in or out add an entry to what will become /etc/rc.conf >>> explaining what dumpdev is and how to turn on/off crash dumps. >>> The folks >>> who handle interacting with users submitting PRs have asked for >>> this. >> >> Hmm. Two things I'd like to bring up: >> >> * Not specifically aimed at this commit, but my recommendation >> would be that we keep bsdinstall as simple as possible: installing >> FreeBSD >> should require a minimum amount of keystrokes. I realise this is >> just one >> more screen, but I hope we don't turn bsdinstall into a configuration >> utility where you can disable/enable just about anything in rc.conf. >> >> * Mentioning future system crashes during installation feels awkward. >> Is that >> really what we want? I understand the problem and how this helps >> us with >> debugging, but this is like saying to users that what they are >> installing >> is unstable and that it'll eventuelly crash and die. I know we >> discussed >> ways of making crash dumps smarter in order to not fill up /var, >> which in >> turn would allow us to always have it on. Maybe that is the right >> path? > > All non-trivial software has bugs and eventually crashes. I don't > expect this to be a surprise to someone installing a UNIX-like > operating system. Note that this isn't the PC-BSD installer, but the > FreeBSD installer. Also, there have been long discussions about this > and ample time for other patches to be developed but they haven't. If > you want this changed, implement the alternate solution. Until then > this is better than not having it at all. > This was also my conclusion when Ken asked me to review this patch. I also don't want the installer to become bloated and made the same original objection, but (a) this patch existed and (b) the long discussion meant that Ken felt it was a particular important decision that deserved its own screen. In particular, the explanation of why you might or might not want it was larger than could fit in a line in the regular services screen and the matter may require some thought. -Nathan