I was reading the feature list for Fedora 8 and was disappointed when I came across the "Better Startup Experience". http://fedoraproject.org/wiki/Releases/FeatureBetterStartup
After reading the "Plan for improvement" section, I find it discomforting such a major change will be done to the existing very working/stable rhgb boot process.
1) Do away with the grub menu by default Why? That is the first question that came to mind. A large number of linux users dual-boot multiple OSes. It also is useful when you have multiple kernel versions installed; if you set the time-out to 3 seconds do you really notice it? 2) Switch to graphical Mode in initrd, draw an animation.... I have an animation now in rhgb, and as a bonus I can see all my services loading if I hit the "more" button. I trust this feature will not go away? 3) rhgb goes away ?reinvent the wheel?
This sounds a lot like the useless Mac OS X boot sequence in which a little circle is animated in the middle of the screen. That tells the user nothing what is going on in the boot process and is a pile of crap. Almost as brilliant as the Windows Vista loading screen.
I'd be curious to hear others thoughts on this; I can't be the only user out there who likes to know his system is indeed booting up and what it is doing. Is this really the direction we want for the fedora-desktop environment? Simply cloning other OSes poor user interface decisions?
Brian Tate escribió:
I was reading the feature list for Fedora 8 and was disappointed when I came across the "Better Startup Experience". http://fedoraproject.org/wiki/Releases/FeatureBetterStartup
After reading the "Plan for improvement" section, I find it discomforting such a major change will be done to the existing very working/stable rhgb boot process.
- Do away with the grub menu by default Why? That is the first question that came to mind. A large number
of linux users dual-boot multiple OSes. It also is useful when you have multiple kernel versions installed; if you set the time-out to 3 seconds do you really notice it?
I couldn't agree more with you on this... However...
- Switch to graphical Mode in initrd, draw an animation.... I have an animation now in rhgb, and as a bonus I can see all my
services loading if I hit the "more" button. I trust this feature will not go away?
Ever heard of Linux BootSplash? Is way better than RHGB in that BootSplash (upon which I'm assuming they're basing this) does not require to launch an early Xserver (in other words, it consumes quite a bit of resources to do that and can't be done as soon as the kernel is loaded, where as BootSplash can, as it is part of the kernel image).
- rhgb goes away ?reinvent the wheel?
Nope, improve upon it. RHGB was regarded by many back in the days of Fedora Core 2 as the worst idea for a graphical boot for Linux, as the Linux console already supported high resolution framebuffer images... Just out of curiosity, try passing the kernel the argument "vga=792" (without the quotes) on your next boot and see what happens ;-). Work on projects such BootSplash started even back in the days of Red Hat 9, but never got really stable. Some projects started to use it (Slackware, SuSE, Gentoo, etc). BootSplash had a function which could represent two modes, pretty much the same as what you see happens within RHGB right now. By means of pressing F12 you can see the boot process just like before, and it is even possible to switch to it if a problem occurs during boot up (a service taking too long to load, a service failing to start, a hard disk check, etc). This was the way to go from the beginning, I was actually surprised that RHGB lingered for so long!
This sounds a lot like the useless Mac OS X boot sequence in which a little circle is animated in the middle of the screen. That tells the user nothing what is going on in the boot process and is a pile of crap. Almost as brilliant as the Windows Vista loading screen.
I'd be curious to hear others thoughts on this; I can't be the only user out there who likes to know his system is indeed booting up and what it is doing. Is this really the direction we want for the fedora-desktop environment? Simply cloning other OSes poor user interface decisions?
On Sun, 2007-07-22 at 21:36 -0500, Gian Paolo Mureddu wrote:
Brian Tate escribió:
- Switch to graphical Mode in initrd, draw an animation.... I have an animation now in rhgb, and as a bonus I can see all my
services loading if I hit the "more" button. I trust this feature will not go away?
Ever heard of Linux BootSplash? Is way better than RHGB in that BootSplash (upon which I'm assuming they're basing this) does not require to launch an early Xserver (in other words, it consumes quite a bit of resources to do that and can't be done as soon as the kernel is loaded, where as BootSplash can, as it is part of the kernel image).
The idea isn't to use bootsplash because bootsplash is not at all upstream and basically has zero chance of getting there. Instead, work is underway so that the kernel can do native modesetting for various graphics chipsets. Then we'll just go the same mode and avoid the mode switch and corresponding monitor flash.
Jeremy
To Jeremy and Gian-
Well that's good.. after reading your posts I am comforted to know the boot process isn't going out the window. I guess I was just worried that I'd be stuck using text-only mode for the functionality I enjoy now. Because I know having fancy graphics chipset drivers load on the boot for good effects will work on older cards, I know it probably won't work for cards that are new and have limited x11 driver support. So it'd be nice for those cards to be able to fall back to the existing boot process rather then all the way to text-only mode.
I am still unclear on what you intend to do to the grub boot process. are you going to merge the new boot animation so that grub/kernel/service loading is all under one status screen? It definitely shouldn't be a hassle for a user to get to this menu.
All in all, It'd be nice to see that page have better explanations of the project's goals. Things like "there should be no text messages" should be elaborated; so users like me who joined the mailing list after the said discussion on this new boot process actually know what is going on.
Thanks for elaborating on the projects goals.
Brian
Jeremy Katz wrote:
On Sun, 2007-07-22 at 21:36 -0500, Gian Paolo Mureddu wrote:
Brian Tate escribió:
- Switch to graphical Mode in initrd, draw an animation.... I have an animation now in rhgb, and as a bonus I can see all my
services loading if I hit the "more" button. I trust this feature will not go away?
Ever heard of Linux BootSplash? Is way better than RHGB in that BootSplash (upon which I'm assuming they're basing this) does not require to launch an early Xserver (in other words, it consumes quite a bit of resources to do that and can't be done as soon as the kernel is loaded, where as BootSplash can, as it is part of the kernel image).
The idea isn't to use bootsplash because bootsplash is not at all upstream and basically has zero chance of getting there. Instead, work is underway so that the kernel can do native modesetting for various graphics chipsets. Then we'll just go the same mode and avoid the mode switch and corresponding monitor flash.
Jeremy
Brian Tate escribió:
To Jeremy and Gian-
Well that's good.. after reading your posts I am comforted to know the boot process isn't going out the window. I guess I was just worried that I'd be stuck using text-only mode for the functionality I enjoy now. Because I know having fancy graphics chipset drivers load on the boot for good effects will work on older cards, I know it probably won't work for cards that are new and have limited x11 driver support. So it'd be nice for those cards to be able to fall back to the existing boot process rather then all the way to text-only mode.
The idea behind the new boot process is to add graphics to the "text mode", which is possible.
I am still unclear on what you intend to do to the grub boot process. are you going to merge the new boot animation so that grub/kernel/service loading is all under one status screen? It definitely shouldn't be a hassle for a user to get to this menu.
The idea behind the Grub change is pretty much as you see it today, except, that instead of showing a graphic in the counter screen (the screen you see with a Fedora 7 themed backdrop, etc) the counter would be without a background extending the "look and feel" of the BIOS boot process. Once the kernel loads, as soon it does, there's gonna be graphics. Not EGA (16 color) graphics, like the Grub splash, but full blown 32-bit images and animations. This doesn't mean that the X11 drivers are loaded (again, this is all in-kernel, no X!) which means that even if your video card doesn't have proper X11 drivers for all the fancy stuff (aka 3D), you can still get 2D, which is exactly what will happen with the in-kernel graphics. There are a bunch of VESA drivers in the kernel already. There are known problems when using the Riva driver for the virtual terminal graphics and the nvidia X11 driver (nvidia recommends disabling the Riva driver or using the VESA [vga] driver)
All in all, It'd be nice to see that page have better explanations of the project's goals. Things like "there should be no text messages" should be elaborated; so users like me who joined the mailing list after the said discussion on this new boot process actually know what is going on.
While many of the terms and even concepts may be a bit disorientating at first, the page is quite clear actually (if you are familiar enough with the boot process of Linux and the capabilities of the kernel). Basic support for these graphics has been in the kernel for quite some time now, back in the 2.4 days was the very first time I saw them being used, and I don't know if the 2.2 series of kernels also had the capability. That was when projects like BootSplash appeared. I gather that BootSplash is no longer maintained, but still is the same basic idea which is going into the F8 boot process. Take advantage of the advanced graphics features of the kernel and use them during the boot process, pretty much like it is with RHGB without the added overhead of an early X11 session.
Thanks for elaborating on the projects goals.
Brian
Hey Gian,
Thanks for taking the time to explain all that; sounds much better now.
Good luck.
Gian Paolo Mureddu wrote:
Brian Tate escribió:
To Jeremy and Gian-
Well that's good.. after reading your posts I am comforted to know the boot process isn't going out the window. I guess I was just worried that I'd be stuck using text-only mode for the functionality I enjoy now. Because I know having fancy graphics chipset drivers load on the boot for good effects will work on older cards, I know it probably won't work for cards that are new and have limited x11 driver support. So it'd be nice for those cards to be able to fall back to the existing boot process rather then all the way to text-only mode.
The idea behind the new boot process is to add graphics to the "text mode", which is possible.
I am still unclear on what you intend to do to the grub boot process. are you going to merge the new boot animation so that grub/kernel/service loading is all under one status screen? It definitely shouldn't be a hassle for a user to get to this menu.
The idea behind the Grub change is pretty much as you see it today, except, that instead of showing a graphic in the counter screen (the screen you see with a Fedora 7 themed backdrop, etc) the counter would be without a background extending the "look and feel" of the BIOS boot process. Once the kernel loads, as soon it does, there's gonna be graphics. Not EGA (16 color) graphics, like the Grub splash, but full blown 32-bit images and animations. This doesn't mean that the X11 drivers are loaded (again, this is all in-kernel, no X!) which means that even if your video card doesn't have proper X11 drivers for all the fancy stuff (aka 3D), you can still get 2D, which is exactly what will happen with the in-kernel graphics. There are a bunch of VESA drivers in the kernel already. There are known problems when using the Riva driver for the virtual terminal graphics and the nvidia X11 driver (nvidia recommends disabling the Riva driver or using the VESA [vga] driver)
All in all, It'd be nice to see that page have better explanations of the project's goals. Things like "there should be no text messages" should be elaborated; so users like me who joined the mailing list after the said discussion on this new boot process actually know what is going on.
While many of the terms and even concepts may be a bit disorientating at first, the page is quite clear actually (if you are familiar enough with the boot process of Linux and the capabilities of the kernel). Basic support for these graphics has been in the kernel for quite some time now, back in the 2.4 days was the very first time I saw them being used, and I don't know if the 2.2 series of kernels also had the capability. That was when projects like BootSplash appeared. I gather that BootSplash is no longer maintained, but still is the same basic idea which is going into the F8 boot process. Take advantage of the advanced graphics features of the kernel and use them during the boot process, pretty much like it is with RHGB without the added overhead of an early X11 session.
Thanks for elaborating on the projects goals.
Brian
Brian Tate escribió:
- Do away with the grub menu by default Why? That is the first question that came to mind. A large number
of linux users dual-boot multiple OSes. It also is useful when you have multiple kernel versions installed; if you set the time-out to 3 seconds do you really notice it?
Didn't see the actual page until after I finished my other mail... No where do I understand they want to depart with GRUB, but rather make the kernel high resolution support as early as possible (i.e. as soon as the initrd image is loaded), switch to the best video mode (video modes in the VT are rather cryptic) and color bit depth for the attached display and continue booting all the way until X11 is loaded with a nice, shiny and professional looking through out all of the boot process, which could in turn be made faster by means of new stuff like 'initng' and the resource liberation of RHGB and the "extra" Xserver.
First -- this has been discussed (extensively) on this list in the past. Please see the archives.
On Sun, 2007-07-22 at 21:59 -0400, Brian Tate wrote:
- Do away with the grub menu by default Why? That is the first question that came to mind. A large number of
linux users dual-boot multiple OSes. It also is useful when you have multiple kernel versions installed; if you set the time-out to 3 seconds do you really notice it?
The idea isn't to fully get rid of the menu, it's to get rid of the vide mode change. So basically, the graphic won't show by default (you'll still have the graphic if you actually press a key to change something in the menu) but the menu is still perfectly accessible.
Jeremy
On Mon, 2007-07-23 at 11:39 -0400, Jeremy Katz wrote:
First -- this has been discussed (extensively) on this list in the past. Please see the archives.
Hm. There's no method to search the mailman archive via its interface. Googling "site:redhat.com fedora-desktop-list grub ..." gives a lot of hits but unfortunately nothing pertinent to this discussion. Care to give a pointer?
On Sun, 2007-07-22 at 21:59 -0400, Brian Tate wrote:
- Do away with the grub menu by default Why? That is the first question that came to mind. A large number of
linux users dual-boot multiple OSes. It also is useful when you have multiple kernel versions installed; if you set the time-out to 3 seconds do you really notice it?
The idea isn't to fully get rid of the menu, it's to get rid of the vide mode change. So basically, the graphic won't show by default (you'll still have the graphic if you actually press a key to change something in the menu) but the menu is still perfectly accessible.
Actually the only sensible thing to do would be to let anaconda configure grub to show the menu if another OS is configured during installation and skip the menu if another OS isn't configured. People who configure their systems for dual/multi-boot will want to see the menu while others won't.
Nils
desktop@lists.stg.fedoraproject.org
-
Brian Tate -
Gain Paolo Mureddu -
Jeremy Katz -
Nils Philippsen