I think it was a fair question which was raised about the size
of the audience being sought to be catered to, vs the mass of
users of Fedoraproject code, and their 'least astonishment'
and loss of acquired knowledge as to use
If there are, oh, say, twelve people in the world that
actually care about instantaneous GUI boots in Fedora, it is a
waste of time to mess with this thread
but to the most recent point raised about 'modifier keys'. I
recall doing this back in DOS days with a third-party tool
that permitted 'BAT files' to query for Shift, Alt, and Ctrl
key states, and to build boolean decision trees:
On Thu, 31 May 2018, Andrew Lutomirski wrote:
If the protocol were that the boot menu would be shown if
any key at all were held down, then we wouldn't need a 1
second delay.
or, perhaps, better still and less complex as in needing to
suppress a boot menu, a message at the bottom of the GUI
screen from its first appearance and for ten seconds or so:
Hold either Shift key for more boot options
so that a person could be habituated to holding a 'harmless'
key. Harmless, in the sense that it does not fill and over-run
a key-press buffer and start beeping at the holder
I speak having personal setup options of:
15 sec timeout at the grub options menu
with plymouth graphical stuff, rhgb, and quiet
disabled
always booting to a non-GUI console
why: multi-user.target for something formerly
though of as 'single user', although with
multiple PTYs ??
with a 640x480 console
which is NOT cleared away
to support the fact that I am almost always remote and on KVM
devices of varying resolutions, and so favoring a 'least
common denominator' as to capabilities
That last (preserving the TUI boot screen was tricky to find
docoed
Use:
# systemctl edit getty@tty1
and add:
#
[Service]
TTYVTDisallocate=no
#
as the description for the service
-- Russ herrold