[Design-team] Fedora GRUB2 boot menu, from design perspective

Wed Jun 20 20:27:56 UTC 2012

Then maybe we should have a vote on it just like we did with release names?
Maybe we should do more voting on more major changes? Maybe we should make
it a full democracy instead of the engineering team decides is "better for
the novice user" when they don't even communicate with the novice user.

Dan
On Jun 20, 2012 1:12 PM, "Elad Alfassa" <elad at fedoraproject.org> wrote:

> I do not like this approach, way too much clutter.
>
> On Wed, Jun 20, 2012 at 11:11 PM, Dan Mashal <dan.mashal at gmail.com> wrote:
>
>> However, keep one thing in mind. It already automagically selects the
>> lates Fedora kernel without user intervention, Martin. ;)
>>  On Jun 20, 2012 12:39 PM, "Martin Sourada" <martin.sourada at gmail.com>
>> wrote:
>>
>>> On Wed, 20 Jun 2012 08:03:35 -0700
>>> Kirk Bridger wrote:
>>>
>>> >
>>> > Perhaps we can put some additional solution ideas forward.
>>> >
>>> > As a quasi-novice kernel user I always found it helpful to have the
>>> > kernel versions visible.  When I update Fedora and the nvidia blob
>>> > causes X to fail, I like being able to choose older versions because
>>> > I can't do anything else.  When a pre-upgrade ends up with a
>>> > non-working version, I like to be able to run an older version to
>>> > stay productive while I research the problem.
>>> >
>>> > I'm not an expert user but I don't think I'm novice either.  I don't
>>> > see why we need to *hide* the older versions behind another menu,
>>> > just perhaps make it more clear that the old versions are still
>>> > functional but are not the latest on the machine.
>>> >
>>> > Novice users have the "out" of saying "I don't know what this all
>>> > means but I know I want to launch the most current version".  And if
>>> > they're dropped back here after a failure or two trying the current
>>> > version they can try the older versions.
>>> >
>>> > This all assumes that we're limited to the current console-style
>>> > menu. If we can use HTML/CSS or some other layout and styling we can
>>> > make this info much more parse-able with styling and different font
>>> > sizes/layout. If we can do more than just console can someone send a
>>> > screenshot of what we can do, and maybe we can mock something up?
>>> >
>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> > Welcome to Fedora 17 (BeefyMiracle)
>>> >
>>> > *Current Versions*
>>> > Fedora 17 (kernel-3.6.0-1.fc17)
>>> > *
>>> > Superceded Versions*
>>> > Fedora 17 (kernel-3.5.20-3.fc17)
>>> > Fedora 17 (kernel-3.5.20-2.fc17)
>>> > Fedora 16 (kernel-3.2.10-4.fc16)
>>> >
>>> > *Other Operating Systems*
>>> > Microsoft Windows 7
>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> >
>>> IMHO not a bad idea. I have a few notes though:
>>>  * Fedora 16 and Fedora 17 should be considered separate operating
>>>   systems (*if* they use different root).
>>>  * Boot loader should behave look like boot-loader not like an already
>>>   running operating system (the "Welcome to Fedora 17" text is
>>>   misleading)
>>>  * Why have Fedora stylistically higher priority than other operating
>>>   systems?
>>>
>>> IMHO, there are multiple different types of users, who use fedora,
>>> let's divide them into few different groups.
>>>
>>> 1. Dual booters -- Fedora and Windows (or Mac)
>>> ==============================================
>>> These people probably just want to boot the latest version unless
>>> something is broken. They might or might not know what the kernel
>>> versions mean. It might be better to "hide" older kernels in submenu
>>> (or if grub2 allows some better css-like way, why not?)
>>>
>>> 2. *nix enthusiasts/developers -- multi-booters
>>> ==============================================
>>> These people will probably have multiple operating systems installed,
>>> maybe even various versions of fedora. Let's say they have (for example)
>>> Fedora Rawhide, Fedora 17, Debian 6.0, FreeBSD 9 and Arch Linux. They
>>> know very well what kernel is, but if all installed kernels are listed
>>> there, the list gets rather large and it gets hard to quickly find the
>>> latest kernel. Especially for the two Fedoras that you can tell apart
>>> only by the fc18 vs. fc17 in kernel release number... While it would
>>> make selecting *older* kernel versions slower, I think it would be
>>> better to *hide* the older kernels in submenu, thus making the main
>>> menu easier to navigate. IMHO the gain of quicker selection of most
>>> recent kernel for each release would outweigh the less frequent slow
>>> down introduced by submenus.
>>>
>>> 3. Massive virtualization
>>> =========================
>>> These people have only one host operating system, the rest is in
>>> virtual machines. IMHO they are the only group that would *not* benefit
>>> from switch to sub-menus.
>>>
>>> IMHO, the gains to the first two groups outweigh the loss of the third
>>> group, but well, others might disagree. That's why we discuss things,
>>> right?
>>>
>>> So how would the bootloader screen would look like?
>>>
>>> ----------------------------------------------------
>>>                Welcome to GRUB 2
>>>              Select an OS to boot:
>>>
>>> * Fedora Rawhide (with linux-3.6.0-23.fc18)
>>> * Fedora 17 (with linux-3.6.0-23.fc17)
>>> * Debian 6.0 (with linux-2.6.28.3-23)
>>> * Microsoft Windows 7
>>>       --------
>>> * Fedora Rawhide (Rescue)
>>>  - older kernels listed in this submenu, and possibly some special
>>>   rescue mode(s)
>>> * Fedora 17 (Rescue)
>>>  - older kernels listed in this submenu, and possibly some special
>>>   rescue mode(s)
>>> * Debian 6.0 (Rescue)
>>>  - older kernels listed in this submenu, and possibly some special
>>>   rescue mode(s)
>>> * Microsoft Windows 7
>>>  - if we can only chainload win 7, this would not make sense, however
>>>   if we could run rescue modes for win from grub, this where it would
>>>   be.
>>>
>>> ----------------------------------------------------
>>>
>>>
>>> THanks,
>>> Martin
>>> _______________________________________________
>>> design-team mailing list
>>> design-team at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/design-team
>>
>>
>> _______________________________________________
>> design-team mailing list
>> design-team at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/design-team
>>
>
>
>
> --
> -Elad Alfassa.
>
>
> _______________________________________________
> design-team mailing list
> design-team at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/design-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/design-team/attachments/20120620/4f6234ae/attachment-0001.html>