Re: revisiting tunables under Safe Mode menu option

Found this old mail between avg_at_ 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
-- 
Cheers,
Devin


> On Mar 1, 2012, at 9:06 AM, Andriy Gapon <avg_at_FreeBSD.org> wrote:
> 
> on 01/03/2012 18:52 Devin Teske said the following:
>> 
>> 
>>> -----Original Message-----
>>> From: Andriy Gapon [mailto:avg_at_FreeBSD.org]
>>> Sent: Thursday, March 01, 2012 12:39 AM
>>> To: Devin Teske
>>> Cc: John Baldwin; freebsd-current_at_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