From owner-freebsd-current@freebsd.org Sun Dec 11 21:46:44 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A25E2C73834 for ; Sun, 11 Dec 2016 21:46:44 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from shxd.cx (mail.shxd.cx [64.201.244.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 923E71BE7; Sun, 11 Dec 2016 21:46:44 +0000 (UTC) (envelope-from devin@shxd.cx) Received: from [64.201.244.132] (port=50336 helo=[10.0.0.102]) by shxd.cx with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1cGBbT-000EV6-6q; Sun, 11 Dec 2016 21:24:15 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: revisiting tunables under Safe Mode menu option From: Devin Teske In-Reply-To: <4F4FACB0.8090605@FreeBSD.org> Date: Sun, 11 Dec 2016 13:46:40 -0800 Cc: John Baldwin , freebsd-current@FreeBSD.org, Scott Long , Devin Teske Content-Transfer-Encoding: quoted-printable Message-Id: <5ED1C7D5-8B70-4D36-9682-07B7583B6605@freebsd.org> 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> <4F4FACB0.8090605@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.2104) Sender: devin@shxd.cx X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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, 11 Dec 2016 21:46:44 -0000 Found this old mail between avg@ and myself and just had to laugh The boot loader is so much more levels of awesome now, but I had = forgotten how much thought I had put into it. Awesome sauce! ;D --=20 Cheers, Devin > On Mar 1, 2012, at 9:06 AM, Andriy Gapon wrote: >=20 > on 01/03/2012 18:52 Devin Teske said the following: >>=20 >>=20 >>> -----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 >>>=20 >>> on 01/03/2012 03:34 Devin Teske said the following: >>>>=20 >>>> +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). >>>=20 >>> Can you explain why? >>> +1 for having both menu items and each doing its own thing without = any >>> entanglement :-) >>>=20 >>=20 >> First, I realize that this may sound entirely *dumb*, but here-goes: >>=20 >> 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". >>=20 >> 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. >>=20 >> 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). >>=20 >> 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). >>=20 >> 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). >>=20 >> 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. >=20 > Devin, >=20 > 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! >=20 > 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. >=20 > But I still believe that it would be an improvement from the point of = view of > usability end-users. >=20 > 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. >=20 > --=20 > Andriy Gapon