linux-kernel - losing a menuconfig session to a typo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CCCA86B6E10.000005AEeuphoria@inbox.com>
Date:	Mon, 15 Dec 2008 13:03:28 -0800
From:	euphoria@...ox.com
To:	linux-kernel@...r.kernel.org
Subject: losing a menuconfig session to a typo

It's easy to accidentally lose a menuconfig session.  Scenarios start with a
user being accustomed to hitting [right-arrow][return] to exit from a typical
menu.  Perhaps the user prefers his underutilized numeric keypad over adding to
the beating [escape] takes.  Scenarios finish with the user accidentally
issuing [right-arrow][return] to "Do you wish to save? <Yes> <No>".  I only
lost a quick change, but it's easy to imagine how a few hours of menuconfig
time might go away.  "It'll just take a few minutes to whip my distro's kernel
into shape."  Yeah right.  Four hours of guesswork and research later, you're
tired, thinking about the make command to follow, [right-arrow][return] as
usual, wait! no! damndamndamn!, yer snookered.

There are a variety of simple ways to address this.  First, change the menu.
Swapping the order of the <Yes> and <No> would be begging for even more
trouble.  However, the <Yes>/<No> decision could be made a <Yes>/<Maybe>/<No>
decision.  This leaves <Yes>, the predominant choice, in place.  <Maybe>, in
the disputed position, could simply present the same menu.  Someone might even
have a little well-deserved fun with <Maybe> menus.  This doesn't seem all that
intrusive to me.  Second, print the diff.  When changes aren't saved, a diff of
the original config and one that would've been saved could simply be written to
stdout followed by a little blurb, "Those were the changes you didn't save.".
Third, add a save command.  I save at comfortable intervals when editing
everything else, why not kernel configurations?  This reduces the scope of
lossage in general.

Regards, [Ag]   Andy Gaynor   euphoria@...ox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/