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 -- Cheers, Devin > On Mar 1, 2012, at 9:06 AM, Andriy Gapon <a...@freebsd.org> wrote: > > on 01/03/2012 18:52 Devin Teske said the following: >> >> >>> -----Original Message----- >>> From: Andriy Gapon [mailto:a...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
