svn commit: r228192 - head/usr.sbin/bsdinstall/scripts

[Nathan Whitehorn]

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