From owner-freebsd-current@FreeBSD.ORG Thu Mar 1 17:07:51 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 EAA45106566B; Thu, 1 Mar 2012 17:07:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2A18FC14; Thu, 1 Mar 2012 17:07:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA11451; Thu, 01 Mar 2012 19:06:57 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F4FACB0.8090605@FreeBSD.org> Date: Thu, 01 Mar 2012 19:06:56 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120221 Thunderbird/10.0.2 MIME-Version: 1.0 To: Devin Teske References: <4F26CC5A.2070501@FreeBSD.org> <4F4C0600.2000903@FreeBSD.org> <3BA1B476-ED05-4E8E-8DFA-0B06EFB48867@samsco.org> <201202280846.08966.jhb@freebsd.org> <4F4F35B9.5090308@FreeBSD.org> <06bb01ccf7cb$b255a200$1700e600$@fisglobal.com> In-Reply-To: <06bb01ccf7cb$b255a200$1700e600$@fisglobal.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, 'Devin Teske' , 'John Baldwin' Subject: Re: revisiting tunables under Safe Mode menu option 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: Thu, 01 Mar 2012 17:07:51 -0000 on 01/03/2012 18:52 Devin Teske said the following: > > >> -----Original Message----- >> From: Andriy Gapon [mailto:avg@FreeBSD.org] >> Sent: Thursday, March 01, 2012 12:39 AM >> To: Devin Teske >> Cc: John Baldwin; freebsd-current@FreeBSD.org; Scott Long; Devin Teske >> Subject: Re: revisiting tunables under Safe Mode menu option >> >> on 01/03/2012 03:34 Devin Teske said the following: >>> >>> +1 on keeping the menu items loosely entwined (ACPI stands alone, but Safe >>> Mode knows about ACPI but only acts on it when being enabled). >> >> Can you explain why? >> +1 for having both menu items and each doing its own thing without any >> entanglement :-) >> > > First, I realize that this may sound entirely *dumb*, but here-goes: > > In transitioning from an old release (sans-menu; 4.11 for example) to a newer > release (with menu; 6.x for example), one of the first thing that is noticed is > "Safe Mode". > > I know that when I first saw this, I scratched my head and wondered what it did > and what it might be useful for. To this day, I still have never used it. > > When I created the new menu for 9.x/higher, I had to rewrite that portion of the > code and eventually learned what Safe Mode does when used. Still can't say that > I've ever used it, however, at the point that I saw that it disabled ACPI among > other things, that it is more of a blanket option for anything and everything > that might be useful if/when you're having problems (*cough* still can't say > that I've ever used it, as when I have problems I'm usually slogging through the > kernel code, not relying on safe mode to fix some problem). > > That being said, I felt that it was a huge improvement to the UI to have the > Safe Mode option divulge a little bit of its secret by visibly diddling the ACPI > menu item (giving a clue to people that *haven't* read the code that this option > is indeed not independent but instead conglomerate in-nature). > > Indeed, I've watched field engineers when exploring the menu options and their > eyes light-up when they see that "Safe Mode" toggles ACPI off when enabled. > Extrapolating on their surprise, they appear to have an "Aha!"-moment as > previously... this field engineer had no idea what on God's green Earth what > "Safe Mode" did (or didn't) as he didn't know about "kenv" and certainly > couldn't read "Forth". At that point, he may not have had a full understanding > of all the options that Safe Mode diddled, but at that point he at least knew > that Safe Mode is a multi-option that does many things -- which is more than > 6.x, 7.x, or 8.x ever offered which simply boots immediately the Safe Mode > option is selected and does nothing to explain what it is that Safe Mode is > doing (which would in-turn properly calibrate the user's expectations). > > Making the menu items completely independent would be take away the (however > slight) above value-add that was brought in by entwining these two menu-items. > I'm not saying that this would be a grave travesty, but would in-fact be a > value-loss. Devin, you did a great job with boot menu enhancement in general and in this area in particular. You greatly improved usability while preserving the historic behavior and put a lot of work and creativity into that. Thank you! But the argument is that the historic behavior is no longer useful. I see that removing the historic behavior also kills a little bit of your code (and a little bit of magic). That's true, that's a loss in the code. But I still believe that it would be an improvement from the point of view of usability end-users. Having a whole sub-menu where multiple parameters could be tweaked individually would be even greater improvement. But that's not as easy to do. -- Andriy Gapon