February 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302119] Load package selector and libzypp only when needed
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature changed by: Michael Löffler (michl19) Feature #302119, revision 36 Title: Load package selector and libzypp only when needed openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 16:40:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-28 13:42:30 reject reason: Did not make it, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-12 14:13:58 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Rejected by Stanislav Visnovsky (visnov) reject date: 2009-02-02 13:15:32 reject reason: Out of scope. Priority Requester: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Desirable Requested by: Stefan Hundhammer (sh-sh-sh) Description: The YaST2 UI should load the code for the package selector and libzypp only when needed. Not all applications / YaST2 modules need package selection code, yet for all of them the respective code from the YaST2 UI and libzypp is loaded. Discussion: #1: Stefan Hundhammer (sh-sh-sh) (2007-04-13 18:13:44) In the YaST2 Qt the package management related code is now moved to a separate plugin that is loaded upon demand only if the calling YCP application actually requests a PackageSelector widget. This reduces the memory footprint from 20 MB VmRSS minimum (HelloWorld. ycp) to 18 MB minimum (PackageSelector-empty.ycp). #3: Katarina Machalkova (kmachalkova) (2007-04-16 14:41:35) Stano, do we want this for curses UI as well? If yes, than it's not 'done' ... #4: Stanislav Visnovsky (visnov) (2007-04-16 14:47:02) (reply to #3) Agreed. Reopening for ncurses and possibly gtk+. #5: Jiri Srain (jsrain) (2007-06-13 13:54:26) JP, both Qt and NCurses are done, but GTK is still missing. #6: Stefan Hundhammer (sh-sh-sh) (2007-06-13 15:08:58) Looks like yast2-pkg-bindings are also loaded unconditionally. It shouldn't be too hard to do that with "lazy initialization" like UI built-ins: Postpone loading the Y2Component until it's really needed. #7: Stanislav Visnovsky (visnov) (2007-06-19 15:01:54) (reply to #6) Jiri, if Pkg bindings problem is not addressed, it does not make sense to fix Gtk UI. #8: Jiri Srain (jsrain) (2007-07-18 13:59:50) (reply to #7) Sorry for missing this. Martin, please, solve this for the Pkg bindings. #10: Stanislav Visnovsky (visnov) (2007-11-08 11:38:22) (reply to #9) Please, follow up on this. #11: Martin Vidner (mvidner) (2008-04-10 15:23:51) yast2-perl-bindings-2.16.6 no longer links to libzypp, which means libzypp will not be loaded at the very start of yast (perl still will be loaded, but that is relatively cheap). That helps in some cases, but mostly it only delays loading of libzypp, which occurs as soon as Pkg (or Package) is imported. Now I need to make Pkg lazy. #12: Martin Vidner (mvidner) (2008-04-21 15:32:09) I have it almost working, but got stopped by bug 381917 (https://bugzilla.novell.com/show_bug.cgi?id=381917) : problems with destructors of static objects #13: JP Rosevear (jproseve) (2008-07-21 13:59:18) (reply to #12) Martin, what's the status here? Will we need to do anything explicit in packagekit to get this functionality? #14: Stanislav Visnovsky (visnov) (2008-09-08 16:44:06) (reply to #13) There is nothing regarding packagekit for this feature. -- openSUSE Feature: https://features.opensuse.org/302119

1 0

[openFATE 120115] Common Virtual File System Support
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature changed by: Michael Löffler (michl19) Feature #120115, revision 41 Title: Common Virtual File System Support openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-07-21 13:06:16 reject reason: Lack of time before feature freeze. Priority Requester: Important Projectmanager: Important openSUSE-11.2: Rejected by JP Rosevear (jproseve) reject date: 2009-08-21 08:47:14 reject reason: Past feature freeze deadline Priority Requester: Important - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Important Requested by: Joachim Werner (joachimwerner) Description: KDE and Gnome both use their own virtual file system layer to access protocols like SSH, WebDAV, FTP, or SMB (KIO slaves vs. gnome-vfs). This functionality should be available from all major desktop applications on both desktops. Different approaches could be taken: * Implement a lower-level VFS layer that can be used from all applications. This approach has obvious limits because all remote file systems would have to be "mounted" locally, which is not as flexible as accessing them via URLs. * Separate file loading and file storage from the application cores and use the desktop environments' native file dialogs. This approach has worked quite well for some applications (e.g. OpenOffice.org, Sodipodi), but may be a painsome process for others. * Use the useful parts from the non-KDE/non-Gnome applications and write new, native applications using those parts. This has been done with the Gecko rendering engine. Another example is gphoto2, which used to be a GTK application, but now is a library that is used in Gnome and KDE digital camera management frontends. How could we reach that goal? * KDE and Gnome developers at Novell should cooperate to develop a guideline for 3rd party developers. * Where possible, tools should be provided to help developers with using the native dialogs. Discussion: #1: Joachim Werner (joachimwerner) (2006-02-14 15:30:07) FUSE and user space filesystems like fusesmb or fuse_kio can deliver this. We need to put some effort into this post Code 10. #2: Stefan Behlert (sbehlert) (2008-05-21 21:15:25) Michael, you did some evaluation wrt. KDE/GNOME using common stuff. Anything helpful to add? #3: Gary Ekker (gekker) (2008-05-29 14:35:45) Given Novell and the communities recent investement in gvfs and the fact that KDE4 isn't using gvfs, I'm going to reject this one. #4: Michael Meeks (michael_meeks) (2008-06-03 11:14:21) Sure - this is a great direction to go in. Wrt. the different approaches - I want to use this as an opportunity to share code & reduce bug fixing / sustain costs: and of course to unify the ISV platform. I'm not that enthusiastic about FUSE from this angle: I would prefer a single implementation that can be compatibly wrapped by both existing KIO and GIO APIs. In addition, I believe we need to unify the wallet / keyring pieces since network IO slaves are fairly useless without that. #5: Joachim Werner (joachimwerner) (2008-06-06 11:37:22) I'm not quite sure I understand why this request is closed for 11. The problem persists, and AFAICS my initial description is still valid, regardless of the technology switch to gvfs on the GNOME side. In addition to that gvfs does not address the problem of making files available transparently to non-GNOME or even non-GUI apps (think vi), or does it? Please either reject it for time reasons and move it to a later version or even better address it for 11, but we should not close and forget about it, as the pain is still there for any user of a desktop that runs at least one major application from the "other side" or from the pre-GUI times. #6: Michael Meeks (michael_meeks) (2008-06-06 12:43:31) (reply to #5) Sure - I want to see this in sled11 too, and we have a plan to investigate this: lets not close it now. #7: Gary Ekker (gekker) (2008-06-09 08:37:43) (reply to #5) GVFS does make files available. At least you can tab-complete a path on a remote host when entering the path for scp for example. #8: Michael Meeks (michael_meeks) (2008-06-09 16:40:05) (reply to #7) Gary: the advantage of switching to a common IO subsystem is that it would make both KDE & Gnome equal peers in terms of their device access: it would also reduce our costs wrt. long term maintainance, and make things far easier for ISVs to integrate with both desktops in one shot. The fact that GVFS works, or KIO works in a given place is not that relevant here :-) #9: Norbert Frese (nf2) (2009-06-01 02:10:36) Just to mention it: Here is some experimental work, which tries to address this problem: http://live.gnome.org/KioGioBridge It's not that hard to run KIO on top of GIO/GVFS - but to make it neat, the dependencies of GVFS need to be approached as well. Particularly gconf and gnome-keyring. The latter could perhaps be tackled by making the KDE password manager GUI "dualistic" (allow to peek into both password managers - KWallet and Keyring daemon). #10: Will Stephenson (wstephenson) (2009-08-24 13:45:21) I agree that this will be nice to have but it's out of scope for an SP. By replacing a core part of the platform with an experimental compatibility layer we would be replacing reliable and painstakingly maintained upstream code with something new that will run into every API corner case and badly specified behaviour, something we have to maintain ourselves, and which has not had any testing in openSUSE. IMO if we do this, we should do it right, upstream by proposing a common standard and taking it when it has matured there. KWallet is being ported to a standardised gnome-keyring backend so this will be easier in future. -- openSUSE Feature: https://features.opensuse.org/120115

1 0

[openFATE 120091] Samba LDAP configuration
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature changed by: Michael Löffler (michl19) Feature #120091, revision 40 Title: Samba LDAP configuration openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-10-17 10:01:44 reject reason: postponed. Priority Requester: Desirable Projectmanager: Desirable openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-08-01 16:19:54 reject reason: Out of time. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-20 17:41:19 reject reason: -ENORESOURCES Priority Requester: Desirable Projectmanager: Desirable - openSUSE-11.3: New + openSUSE-11.3: Evaluation Priority Requester: Desirable Requested by: Lars Müller (lmuelle) Description: Make LDAP easily configurable, for example by introducing a special LDAP tab. Also see bug 41306 (http://bugzilla.suse.de/show_bug.cgi?id=41306) Discussion: #3: Lars Müller (lmuelle) (2006-08-01 13:44:45) A system should recognize if we have a local LDAP server configured and running. In this case the Samba configuration should use LDAP as passdb backend and for the other config cases mentioned in bug 56306 by default. Do we announce a LDAP server by SLP? Then we might even use this information for a reasonable suggestion. We, Ralf Haferkamp, Guenther Deschner, and me, discussed this for SLES 10 SP 1. #4: Ralf Flaxa (ralfflaxa) (2006-08-13 15:09:29) Is it easily possible to detect a local LDAP server? If so I am not against this. But as it changes the default behaviour compared to SLES 10 GA I would suggest to show a popup window "local LDAP server found, do you want to use it" and default to "yes". This way we could warn former users about the new behaviour but also make it easier for new installations. Would this be ok for you? #5: Ralf Haferkamp (rhafer) (2006-09-05 16:48:16) Detecting a local LDAP Server is easy. E.g. just starting a simple LDAP query against localhost should do it. Another possiblity would be to use chkconfig to check if the ldap init script is enabled. There are multiple ways to detect if there an LDAP Server running in the local network: * SLP (OpenLDAP can register at an SLP daemon, AFAIK eDirectory can do so as well) * DNS SRV Records. This is how it is done in Windows. Unfortunately our DNS-Server module doesn't support managing SRV Records yet (see also Feature #120091) * Check the /etc/ldap.conf (or /etc/openldap/ldap.conf) and test if the server configured there is reachable. After a server has be detected the YaST module would also need to check if it has the required Schema installed. This should be doable via some additional LDAP queries. If the server is running locally it could also offer to update the server's configuration, when needed. #6: Ralf Flaxa (ralfflaxa) (2007-01-17 14:52:44) Changing the state to eval by TL to find out what the status is. I assume this has not been done given the lack of priority. So either mark it as Done or let me know and I will reject it. #7: Jiri Srain (jsrain) (2007-01-17 16:00:07) (reply to #6) No, it has not been implemented. #8: Jiri Srain (jsrain) (2007-08-01 16:14:59) Please, postpone. running out of time. -- openSUSE Feature: https://features.opensuse.org/120091

1 0

[openFATE 306956] Set up feature for wireless card on desktop
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature added by: Roman Bysh (Romanator) Feature #306956, revision 1 Title: Set up feature for wireless card on desktop openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Roman Bysh (romanator) Description: It would be nice to add a set up feature for the wirless card on the desktop after the installation has finished. -- openSUSE Feature: https://features.opensuse.org/306956

1 4

[openFATE 306940] NX/NeatX remotable desktop sessions
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature added by: Tin Blaskovic (canobix) Feature #306940, revision 1 Title: NX/NeatX remotable desktop sessions openSUSE-11.2: Unconfirmed Priority Requester: Desirable openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Tin Blaskovic (canobix) Description: Since the NX server (http://www.nomachine.com) libraries are GPL-ed, there is now a Google project Neatx (http://code.google.com/p/neatx/) that provides a free clean and stable NX server implementation. Together with FreeNX client libraries and a standalone client (http://svn.berlios.de/svnroot/repos/freenx/trunk/freenx-client/nxcl/) , all the components are now available for adding out-of-the-box support for a remotely usable personal Linux desktop. Right now it can be achieved by manually loging into a failsafe X session and starting an NX session to a local server. That session can then be detached and resumed remotely, exhibiting the characteristics (including the speed) comparable to, if not better, than an MS windows terminal (remote desktop) session. It would be handy if creating a "remotable" session that works as described above would be automated and could be chosen from the login screen, so in addition to "KDE", "GNOME", "Failsafe" and other session types, there would be a "KDE remotable","GNOME remotable" or similar types of sessions. Since many of business users still primarily work at their desktops, this would enable them to more easily work remotely, as well as bring Linux desktop features on par with that from the Windows world. -- openSUSE Feature: https://features.opensuse.org/306940

1 3

[New: openFATE 308981] Build comedi kernel drivers in staging
by fate_noreply＠suse.de 11 Feb '10

11 Feb '10

Feature added by: Roger Light (oojah) Feature #308981, revision 1 Title: Build comedi kernel drivers in staging openSUSE-11.3: Unconfirmed Priority Requester: Desirable Package Wishlist: Unconfirmed Priority Requester: Desirable Requested by: Roger Light (oojah) Partner organization: openSUSE.org Description: comedi is the linux control and measurement device interface. It provides kernel drivers and a user space library for use with data acquisition devices such as PCI/USB analogue to digital converters. These types of devices are widely used in scientific/engineering areas of work. Although the drivers are located in the "staging" area of the mainline kernel, they have been in use outside the kernel for many years. Business case (Partner benefit): openSUSE.org: At the moment, the easiest way to install the comedi drivers is to download the appropriate tarball from the comedi website, then compile and install. This is a burden, especially when dealing with lots of machines. It also suffers from the need to recompile/reinstall each time a new kernel update is released because the module directory location has changed. By making the comedi drivers available as a package, the difficulty of installing comedi is significantly reduced and it also provides the opportunity for valuable testing of the drivers as integrated into the kernel. -- openSUSE Feature: https://features.opensuse.org/308981

1 0

[New: openFATE 308961] 11
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature added by: alex Mironov (iracundia) Feature #308961, revision 1 Title: 11 openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: alex Mironov (iracundia) Description: 12 -- openSUSE Feature: https://features.opensuse.org/308961

1 1

[New: openFATE 308954] test
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature added by: john vreeland (johnav13) Feature #308954, revision 1 Title: test openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: john vreeland (johnav13) Description: nothing -- openSUSE Feature: https://features.opensuse.org/308954

1 1

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature changed by: Jakub Rusinek (liviopl) Feature #305317, revision 28 Title: Default to hidden bootloader menu openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-08-05 12:17:52 reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: Evaluation Priority Requester: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! #9: Jan Engelhardt (jengelh) (2009-08-09 14:38:47) (reply to #6) (Well I had hoped you know ;-) What Fedora does (or what it used to in the last years, or what other distros did/do) is that the first GRUB screen does not show the menu (it's "hidden"), but only shows it if you interrupt with a keypress: http://www.dedoimedo.com/images/computers/fedora-first-boot.jpg --1st screen with "HIDDEN MENU" http://fedoraproject.org/w/uploads/d/d4/Tours_Fedora9_001_Install_Boot.png -- 2nd screen And FWIW, I find that rather pointless, just show the menu, does not hurt anybody to know a bit more about one's own system. #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) The only problem I see with this is when the installer does not pick up another installed OS (happens to Windows once in a while) and defaults to a hidden Bootloader? #10: Robert Davies (robopensuse) (2009-12-10 17:53:20) GRUB2 defaults to this method. How does this speed boot time though? If you wait for the user to give them a chance to activate the Hidden menu, you actually slow things up, as they are not encouraged to hit <enter>. I think having option hidden, makes it less obvious and increases documentation and support workload, because greater need for user education. Also the kernel does not give good user feedback early in boot process, seeing menu flash up reassures end user that things are working as expected. #11: Jan Engelhardt (jengelh) (2009-12-12 14:29:27) (reply to #10) Indeed, the switch time from the hidden state to showing the menu entries is considerable (and part of that is because it uses VESA). GRUB's text mode hidden feature (for serial consoles) is faster ;) #12: Vincent Untz (vuntz) (2010-02-10 19:12:15) (reply to #10) Hidden makes sense if the timeout is reduced. The main reason I see to do this change (from my perspective) is that having the grub menu doesn't really look professional. Why should I care about it if I only have openSUSE? + #13: Jakub Rusinek (liviopl) (2010-02-10 19:19:54) + My proposal is to have menu hidden when only openSUSE is installed and + a black screen with line saying "Press Esc to enter boot menu..." for a + few seconds. + Such a Windows-like behaviour, but with info, how to. -- openSUSE Feature: https://features.opensuse.org/305317

1 0

[openFATE 305317] Default to hidden bootloader menu
by fate_noreply＠suse.de 10 Feb '10

10 Feb '10

Feature changed by: Vincent Untz (vuntz) Feature #305317, revision 26 Title: Default to hidden bootloader menu openSUSE-11.2: Rejected by Christoph Thiel (cthiel1) reject date: 2009-08-05 12:17:52 reject reason: out of resources for 11.2. Priority Requester: Desirable Projectmanager: Desirable openSUSE-11.3: Evaluation Priority Requester: Desirable Info Provider: Jan Engelhardt (jengelh) Requested by: Jiri Srain (jsrain) Description: As long as there is no other operating system present (SUSE is the only system), it makes sense to default to hidden bootloader menu (and booting directly). References: http://www.gnu.org/software/grub/manual/grub.html#Hidden-menu-interface https://bugzilla.novell.com/show_bug.cgi?id=425717 Discussion: #1: Stephan Kulow (coolo) (2009-04-16 10:34:48) I like that idea. I guess it's a tiny change for bootloader, but has possibly some docu impact. #2: Stanislav Visnovsky (visnov) (2009-05-28 16:45:13) How should it behave with option to keep kernels from updates (libzypp option)? What about failsafe? #3: Jiri Srain (jsrain) (2009-06-01 11:21:11) From the GRUB documentation: When your terminal is dumb or you request GRUB to hide the menu interface explicitly with the command `hiddenmenu' (*note hiddenmenu::), GRUB doesn't show the menu interface (*note Menu interface::) and automatically boots the default entry, unless interrupted by pressing ESC. When you interrupt the timeout and your terminal is dumb, GRUB falls back to the command-line interface (*note Command-line interface::). This sounds to me like this GRUB feature is intended for different purpose, and the use case described here does not make much sense (unlike lowering the time-out to e.g. 1 second). Torsten, what is your view? According to the documentation, GRUB allows to display the boot menu via pushing the Escape button. #7: Christoph Thiel (cthiel1) (2009-07-16 11:27:26) (reply to #3) Torsten, could you please provide your view on this? Fedora and others seem to be doing this for years. #4: T. J. Brumfield (enderandrew) (2009-06-13 03:31:06) This option would only be utilized when no other OS is present, and you can still get back to the menu with Esc. This isn't that much different than needing F8 for the boot menu for Windows. It would speed up boot times. How is that a bad thing? #5: Jan Engelhardt (jengelh) (2009-06-18 23:53:45) Does not Fedora do something similar? #6: Christoph Thiel (cthiel1) (2009-06-28 10:00:44) (reply to #5) I haven't looked at how Fedora handles this. Jan, would you be able to dig into what Fedora does technically? This would be very much appreciated! #9: Jan Engelhardt (jengelh) (2009-08-09 14:38:47) (reply to #6) (Well I had hoped you know ;-) What Fedora does (or what it used to in the last years, or what other distros did/do) is that the first GRUB screen does not show the menu (it's "hidden"), but only shows it if you interrupt with a keypress: http://www.dedoimedo.com/images/computers/fedora-first-boot.jpg --1st screen with "HIDDEN MENU" http://fedoraproject.org/w/uploads/d/d4/Tours_Fedora9_001_Install_Boot.png -- 2nd screen And FWIW, I find that rather pointless, just show the menu, does not hurt anybody to know a bit more about one's own system. #8: Stefan Kunze (kunzes) (2009-07-28 16:03:50) The only problem I see with this is when the installer does not pick up another installed OS (happens to Windows once in a while) and defaults to a hidden Bootloader? #10: Robert Davies (robopensuse) (2009-12-10 17:53:20) GRUB2 defaults to this method. How does this speed boot time though? If you wait for the user to give them a chance to activate the Hidden menu, you actually slow things up, as they are not encouraged to hit <enter>. I think having option hidden, makes it less obvious and increases documentation and support workload, because greater need for user education. Also the kernel does not give good user feedback early in boot process, seeing menu flash up reassures end user that things are working as expected. #11: Jan Engelhardt (jengelh) (2009-12-12 14:29:27) (reply to #10) Indeed, the switch time from the hidden state to showing the menu entries is considerable (and part of that is because it uses VESA). GRUB's text mode hidden feature (for serial consoles) is faster ;) + #12: Vincent Untz (vuntz) (2010-02-10 19:12:15) (reply to #10) + Hidden makes sense if the timeout is reduced. + The main reason I see to do this change (from my perspective) is that + having the grub menu doesn't really look professional. Why should I + care about it if I only have openSUSE? -- openSUSE Feature: https://features.opensuse.org/305317

1 0