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

Elad Alfassa elad at fedoraproject.org
Wed Jun 20 20:12:45 UTC 2012


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/design-team/attachments/20120620/5b455719/attachment.html>


More information about the design-team mailing list