August 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Ján Kupec (jkupec) Feature #302159, revision 46 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 Test Case: - run zypper with: zypper --download-only install [package] + run zypper with: zypper install [package] --download-only + subsequent "zypper install [package]" (without --download-only) should + not download the package again, just install it. This should work with + install, update, dist-upgrade, patch, and verify commands Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. #17: Michael Andres (mlandres) (2009-07-21 12:30:27) libzypp-6.11.0 allows to set different download policies in ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, DownloadAsNeeded). #18: Ján Kupec (jkupec) (2009-07-27 15:22:59) Done also in zypper (--download-only/-d added to several commands). To be in zypper 1.2.3 -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 302628] Access to encrypted devices/partitons by dongle
by fate_noreply＠suse.de 11 Aug '09

11 Aug '09

Feature changed by: Mario Goppold (mgoppold) Feature #302628, revision 38 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Projectmanager: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) #15: Mario Goppold (mgoppold) (2009-03-29 22:26:03) Hi, because I just need to unlook my root partition via USB stick I have build an rpm for it: http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_… _SVNr46_luks_key-64.1.x86_64.rpm The main changes are in /lib/mkinitrd/scripts/{setup,boot}-luks.sh and the new /etc/sysconfig/initrd.luks_key. The LUKS-Keyfile should on an Labled or UUIDed USB-Stick. You can unlook all partitions with a master key or define a separate for every luks_device. The approach is certainly not the best but there is no keyscript in /etc/crypttab jet (why not?). #16: Ludwig Nussel (lnussel) (2009-03-30 09:13:46) (reply to #15) mind creating a patch against http://git.opensuse.org/?p=projects/boot.crypto.git;a=summary so I can have a look? I'm not really fond of supporting the keyscript option but since debian now uses that askpass program that I like to integrate we'd basically get keyscript support for free at least wrt boot.crypto. For YaST it would be between hard and impossible to support as one can never know what the keyscript does. #17: Mario Goppold (mgoppold) (2009-03-30 22:14:47) (reply to #16) Have a look at #18: Mario Goppold (mgoppold) (2009-04-01 20:59:06) (reply to #16) I have made some little updates: * There is no need to add /dev/mapper/swap and /dev/mapper/what_else to setup-storage.sh. or /boot/grub/menu.lst * If the key-File is not within the luks-Container there is now a prompt fallback. * I added ext3 and jbd modules to have the Key on ext3 formatted USB- Sticks The new version is Build 77 (http://download.opensuse.org/repositories/home:/mgoppold/openSUSE_11.1/x86_…) #19: Marcus Meissner (msmeissn) (2009-06-24 15:12:33) (reply to #18) Mario, It would really help us if you could provide a patch against the current git state. The patch does not aspply to current :( (Ludwig is not in the office this and next week, will get back in 2 weeks.) + #20: Mario Goppold (mgoppold) (2009-08-11 09:38:09) (reply to #19) + The new patch against the boot.crypto- + 2acb4efc564ca9af8e97162110987289f1206f11.tar.gz from 13.07.2009 is + done. You can find it in my OBS: + boot.crypto-0_200907131030.luks-key.dif (https://build.opensuse.org/package/view_file?file=boot.crypto-0_20090713103… + 3Amgoppold) + Unfortunately it don't build successfully on Factory. + There are some echos for debugging they should remove before commit. + Now setup-luks.sh uses the /etc/crypttab file and therefore my patch + don't need the /etc/sysconfig/initrd anymore.The root device was found + by setup-luks.sh automatically and all other devices e.q. home goes to + the /etc/cryptab file: + home /dev/sda2 none luks,initrd + Are there any helful suggestions? + -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 307373] Need the ability to regress fate requests
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature added by: Joe Harmon (jaharmon) Feature #307373, revision 1 Title: Need the ability to regress fate requests openFATE: Unconfirmed Priority Requester: Mandatory Requested by: Joe Harmon (jaharmon) Description: With Open Enterprise Server we have testing teams that are testing our features and do not currently have a way to regress a feature. The issue is that our developers mark the fate request done and then from that point we can't show that it has passed testing. -- openSUSE Feature: https://features.opensuse.org/307373

1 0

[openFATE 307371] configurable communication protocol in fs/dlm
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature added by: coly li (colyli) Feature #307371, revision 1 Title: configurable communication protocol in fs/dlm Requested by: coly li (colyli) Description: in HEA SLE11, fs/dlm uses TCP as the default communication protocol, and no interface to configure a different communication protocol e.g. SCTP. Right now the SCTP related code is in fs/dlm already, we need a configurable interface to specify SCTP as communication protocol when necessary. With SCTP, fs/dlm can support multi-homed addresses, then redundant multiple rings in openais can work correctly. -- openSUSE Feature: https://features.opensuse.org/307371

1 0

[openFATE 305150] Indicate automounted filesystems in YaST partitioner
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature changed by: Maximilian Maher (maxmaher) Feature #305150, revision 13 Title: Indicate automounted filesystems in YaST partitioner openSUSE-11.2: Done Priority Requester: Mandatory Projectmanager: Important Requested by: Arvin Schnell (aschnell) Description: Currently the partitioner does not indicate if a filesystem (e.g. NFS) is mounted via some automounting daemon. For these filesystems the "Edit" and "Delete" buttons do not make sense. Using them could even cause trouble. So these filesystems need special handling. Libstorage must be extended to detect and provide the information. The ignore_fstab flag can be used as a starting point for this. Relations: - Yast2 Partitioner shows NFS mounts from automounter (novell/bugzilla/id: 446502) https://bugzilla.novell.com/show_bug.cgi?id=446502 + Test Case: + check if yast partitoner indicates automounted filesystems Discussion: #2: Arvin Schnell (aschnell) (2009-07-23 09:45:00) Implemented during hackweek: The ignore_fstab flags is now also set for non-NFS volumes and displayed in the UI. -- openSUSE Feature: https://features.opensuse.org/305150

1 0

[openFATE 303400] Allow to enable the backend error handler (beh) from the YaST printer module
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature changed by: Maximilian Maher (maxmaher) Feature #303400, revision 15 Title: Allow to enable the backend error handler (beh) from the YaST printer module openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-08 09:39:42 reject reason: Postponing. Priority Requester: Desirable openSUSE-11.2: Done Priority Requester: Desirable Requested by: Lars Müller (lmuelle) Description: It should be possible to enable the backend error handler (beh) from the YaST printer module. This is usefull if a network printer isn't always reachable. Think of a printer switched on later than the startup of cups happens. + Test Case: + Test if you can enable the beh with Yast printer Discussion: #1: Johannes Meixner (jsmeix) (2009-03-27 09:46:06) I wonder why I am not included in such requests? It is already implemented in the new yast printer module for openSUSE 11.1 and accordingly also for SLE11 via the "Connection Wizard". How to use it: 0. Usually one would first set up the queue as usual (i.e. without beh). 1. In case of backend errors and when additionally the default error handling is not what is wanted, one would first try if another CUPS error policy helps. One can change the CUPS error policy in YaST via "Policies". 2. If even another CUPS error policy does not do what is wanted, one could daisy-chain beh: Select the queue and "Edit" it. In the "Modify" dialog select "Connection Wizard" and therein "Daisy-Chain Backend Error Handler (beh)" usually leave the defaults for beh (or adapt them, read the help text in YaST), klick "OK" to go back to the "Modify" dialog. Now there is a new connection using "beh" available. Select this new connection in the "Modify" dialog and klick "OK" to apply the change to the queue. -- openSUSE Feature: https://features.opensuse.org/303400

1 0

[openFATE 302159] zypper: Add option to only download packages (-d)
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature changed by: Maximilian Maher (maxmaher) Feature #302159, revision 45 Title: zypper: Add option to only download packages (-d) openSUSE-10.3: Rejected by Stanislav Visnovsky (visnov) reject date: 2007-06-19 14:19:54 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.0: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-04-04 14:32:54 reject reason: Running out of time, postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-07-11 22:23:41 reject reason: Postponing. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Done Priority Requester: Desirable Projectmanager: Important Requested by: Jiri Srain (jsrain) Description: rug has a '-d' option which causes it only download packages, not to install them. zypper does not have one. to make use of such options (download packages and install them later) zypp must be able to keep the packages downloaded and use them later instead of downloading them again (eg. some kind of persistent cache). References: https://bugzilla.novell.com/show_bug.cgi?id=230704 See also feature #300747 and #305624 + Test Case: + run zypper with: zypper --download-only install [package] Discussion: #2: Ján Kupec (jkupec) (2007-06-05 13:43:33) (reply to #1) First, we must have a clue how to do it :O) #5: Michael Andres (mlandres) (2007-06-18 13:21:51) (reply to #2) We need a persistent package cache, where packages are indexed by MD5, SHA. Commit has to be rewritten to separate download and install code (still offering alternating download/install or download all then install). And we need some cache cleanup policies. But we probabely don't want to do this before we know the refactored zypp runs smoothly, so I would not promise this for 10.3 #8: Federico Lucifredi (flucifredi) (2007-06-18 15:48:59) (reply to #5) As an aside, indexing will cause you probelsm with blind-revisioned packages, depending on how you implement it. #4: Duncan Mac-Vicar (dmacvicar) (2007-06-18 09:19:27) (reply to #3) This means changing the commit, and we can only do that if we are ahead of time with the other changes. #6: Jiri Srain (jsrain) (2007-06-18 14:40:08) Duncan, Michael, thanks! Stano, please, postpone for 11.0. #7: Federico Lucifredi (flucifredi) (2007-06-18 15:46:55) Lets not forget that 70%+ of OpenSUSE users have broadband according to the survey, which means this is a marginal advantage, albeit a nice one (I imagine, users who are charged by the bit, and advanced users doing who-knows-what will take advantage of the ability to retrieve packages from the cache). #13: Jan Engelhardt (jengelh) (2009-03-01 17:02:04) (reply to #7) Broadband is actually a pretty broad term, and so the survey item probably did not have much value. #10: Stanislav Visnovsky (visnov) (2007-11-23 11:26:31) zypper improvements, commit re-factoring. #14: Elmar Stellnberger ATK (estellnb) (2009-03-26 13:04:40) One advantage will be that packages can be inspected by a prog. such as mc in advance to installation or to manually take them apart by rpm2cpio. Sometimes it is necessary to add special rpm-installation options as --excludepath or --excludedocs to install several versions of a single package for downward compatibility. Furthermore in combination with an upcoming --arch switch it may enable to download packages on a server to be installed on another system/machine. f.i. the ati repo can not be browsed via http so that it is necessary to download packages from it via zypper rather than a web browser. #17: Michael Andres (mlandres) (2009-07-21 12:30:27) libzypp-6.11.0 allows to set different download policies in ZYppCommitPolicy (DownloadOnly, DownloadInAdvance, DownloadInHeaps, DownloadAsNeeded). #18: Ján Kupec (jkupec) (2009-07-27 15:22:59) Done also in zypper (--download-only/-d added to several commands). To be in zypper 1.2.3 -- openSUSE Feature: https://features.opensuse.org/302159

1 0

[openFATE 305866] osc/obs: load Packages from every Project without Link
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature added by: Sascha Manns (saigkill) Feature #305866, revision 1, last change by Title: osc/obs: load Packages from every Project without Link Buildservice: Unconfirmed Priority Requester: Neutral Requested by: Sascha Manns (saigkill) Description: If i build Packages with OBS/OSC, i must link Packages from other Project to my own. I wish me, that future Releases from OBS/OSC solve the depencies automaticly, and load the Packages from every Repository. Other Way, is if we give Repositories an Priority Number. So the OSC/OBS works first with the high Priority Repos. -- openSUSE Feature: https://features.opensuse.org/305866

1 8

[openFATE 305296] Easy Way to Disable Beagle Completely During Installation
by fate_noreply＠suse.de 10 Aug '09

10 Aug '09

Feature changed by: Hecke Degering (Hecke_Goe) Feature #305296, revision 107 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Done Priority Requester: Important Projectmanager: Important Requested by: JP Rosevear (jproseve) Description: We need to either have beagle off by default and allow a user to enable it the first time they search or provide an install option to turn it off. Relations: - Better Beagle Acceptance (feature/id: 303367) - Easy way to disable beagle completely during install (novell/bugzilla/id: 282678) https://bugzilla.novell.com/show_bug.cgi?id=282678 Discussion: #1: Federico Lucifredi (flucifredi) (2009-01-26 20:52:46) I prefer to start with disabled, offer option to run at first search. We are proliferating checkboxes in the installer too much. #8: Stephan Kulow (coolo) (2009-02-10 15:32:39) (reply to #1) I wholehearty agree. Having specific applications in the installer is definitely something that we shouldn't do. Have it disabled by default and make it easy to enable. #9: Manuel Bejarano (mbejaranoc) (2009-02-11 09:29:51) (reply to #1) 100% agree #11: Jean-Daniel Dodin (jdd) (2009-02-15 10:12:29) (reply to #1) +1 #2: Kevin Dupuy (kdupuy9) (2009-01-29 23:40:17) I prefer a more sane option than disabling it by default... instead, allow the user to go in and uninstall it from the installation software screen, just as they would any other app (perhaps make 'Desktop Search' pattern, installed by default?) We just need to insure that uninstalling Beagle doesn't throw up any dependency errors. #3: Eric Springer (erikina) (2009-01-30 00:16:23) Every single openSUSE install I've done has resulted in beagle being removed. It slows down the computer, and the firefox extension throws lots of errors. I'm quite happy with how easy it is to remove, and I can see why it's useful -- but unless its seriously improved, I think it should be removed (by default) #26: Peter Nixon (peternixon) (2009-03-11 20:39:01) (reply to #3) +1 #29: Pedro Veloso (pedrodh) (2009-04-01 22:18:05) (reply to #26) Totally agree #4: Jan Engelhardt (jengelh) (2009-01-30 15:22:34) Maybe pulseaudio should be too, for slightly similar reasons. :) #5: Rastislav Krupansky (ra100) (2009-01-31 13:10:36) (reply to #4) exactly right ;-) #6: Thomas Beimel (rheydtergekko) (2009-02-01 16:22:09) Yes this would be an perfect option during installation. Especially because I prefer to have a new installation that consumes as less resources as possible. I do not need indexing service and I think many others as well. #7: Andri Andreas Priyanto (turtlix) (2009-02-05 11:20:44) I haven't use beagle since I install openSUSE, and maybe wouldn't or never But I don't know other user. I always remove beagle from my gnome-session-properties. #10: Johnny Stovall (oouc) (2009-02-11 22:50:14) Beagle should be disabled by default. Everyone in the DFW Linux Users Group complained when Suse added it. It causes nothing but trouble for me. #12: Bart Otten (bartotten) (2009-02-16 01:13:58) I agree with the people voting to disable it by default. I think we have to keep focus on the 'consumer' and most of them won't use Kerry/Beagle. ps. KDE4 -and- Beagle is useless. KDE4 uses Strigi and Nepomuk. #13: Sebastian Rösgen (palimpseste) (2009-02-17 12:55:11) Despite all who now have voted for this proposal, I just have to vote against it. At least in the forms discussed here. I use Beagle heavily as do some other people I got convinced to use openSUSE instead of Windows. A good Desktop search was among the arguments to move these people to change their OS (others arguments were Deskbar etc... which btw. does not necessarily need Beagle but gets some interesting advantages IF Beagle is activated). Why not simply ask at startup how to configure some basic system defaults. Among them there could be beagle. So concerning the proposals of Federico Lucifredi, Stephan Kulow and so on, I am definitively of the same mind. Beagle should be installed by default, but it should be easy to switch it "on" or "off" whenever one wants. #14: Eric Springer (erikina) (2009-02-18 01:05:18) (reply to #13) Yes, a search is very useful. Yes, some people find beagle beneficial (as apparently you do). But the vast majority (Currently the vote is at 47:1) of people it doesn't work well with. And that's truly an amazing statistic, as it's super easy to see and use the feature it provides but much harder to see that it's beagle causing so many (resource related) problems. And if that statistic alone isn't enough to convince you it's not a sensible default, then I have absolutely no idea how to. There really should be a resemblance of QA in place, especially for default (and completely optional) packages. #15: Sebastian Rösgen (palimpseste) (2009-02-19 12:04:23) (reply to #14) Ok, I hope that my comment did not sound as gruff or ... brusque, for I, basically, hoped to present a different opinion. What I did not intend was to, evidently, irritate somebody by not completely assenting to his opinion. See: I am working for a university in Germany. We have 45.000 students and a staff of employees of a size appropriate for this amount of students. We rely heavily on the capabilities of a search system (to be honest: in this case not beagle, but somethings similar to beagle). I am one person who posts here but, to stay in your line of argumentation, statistically I represent so many single individuals, that my vote could be multiplied by a "pretty fight factor". Now the problem is that most of these people just use a search feature but do not understand of configure it. But they will notice when it is gone . These users do not vote, they are not involved in community work, they are not programmers, not system architects, not members of an online community. But they use systems like beagle. I know, as I stated in my first post, some people, which I got to switch their OS, from Windows to openSUSE. These people will miss features, too. Especially if you are so eager so simple remove this feature despite the fact that it was part of the distribution for many years. The more I write here, the angrier I get. I mentioned that Lucifredi and Kulow are of another opinion (disable but no remove the software; make it possible to switch it on or off when needed), an opinion I agree with. Is it possible that YOU ignored that part? This is quite normale for the usual open source community. To me it is a relatively illusive concept, the more I deal with it (and I deal with it for now 9 years) the more I learn about the ignorance it contains. Too many people choose rather to ignore those who have to vote (usually called users) and instead see their opinion as the ultimate measure to decide pro and contra. Did it come to your mind that about 80-90% of those who start to create an account for a portal like openFATE, who pay the time to write some comments and skip through all these proposals in this portal, that 80-90% of these people might perhaps be programmers? Geeks and nerds as they are called nowadays. This is no real statistic representing the opinion of those who use a software, it is a statistic of those how develop a software. Make this clear to you. So to get back on a rather rational level: I recognize that you are of another opinion. That most of the people here are. But, and that was important to me, these votes in here are not a real representation of opinions. I prefer openSUSE after all these years espcially because it was bought by Novell. Because they do research in usability, which is the only real way to ask the customers/the users, how to design the software. That is why I said, that an easy startup QA for the normal user is the best to do. Do not be too ignorant. The users know what they want, even if they miss some technical versatily, they will still take note of features that are missing, of bugs in the browser, of missing parts in the system "that they know worked on a different OS" or whatever else. Perhaps they annot name the source of the problem and do not know if it is a real design issue or a real bug. But they will say that the feature is not how they expected it to be. I recently said to a colleague of mine that the times of Mac OS are nearly over. The only real advantage they have is that they can design an OS without paying too much attention to different hardware. They know exactly which hardware their OS will possible have to run on. If Linux with a nice GNOME, KDE, or-whatever-desktop would run out of the box on ANY posible hardware, with all features running without a problem (Audio, Bluetooth, 3D Graphics are still a problem as we know) it would be undeniable that Linux will be the winner. I see progress made well into that direction. I see that Linux is close to this goal, to solve these issues in nears time (most Graphic Cards now easily work, with only a few exceptions). So please do not disappoint me. I have to lead discussions about Linux/Windows and Linux/MacOSX nearly every week. I do not want to have them led in vain. Look at what Mac and Windows do, they have a search system with an index. Make ours betters, faster and less memory hungry instead of removing it. These who switch from Windows/Mac to Linux (for instance to openSUSE) want to find new and more useful features instead of fewer features. I know this post was too long. I am sorry, but it thought it necessary. #16: Eric Springer (erikina) (2009-02-19 14:33:07) (reply to #15) I agree with everything you said, but you must realize I/we aren't arguing against search. We're arguing against beagle. I personally use google desktop search on a daily basis. And it works well. I assume that it does all its work when I'm not physically using the computer (a policy that is ideal for desktop usage). I'm not advocating its inclusion (primarily license reasons and kde integration reasons) but you should see that I'm not against a search or anything like that. Beagle on the other hand, I've tried to give it a fair shot a few times. To see if it has improved (something I will admit Banshee has done). But its *always* problematic. Something that is echoed daily on IRC and the mailing lists. The firefox extension causes huge amounts errors and slow downs. The actual search program maxs out the CPU. IO brings the computer to a crawl when I need to get work done etc. It's just not pretty. So if Beagle works well, I'd love to use it. But it doesn't and shouldn't be included. Put it this way. I would really like to see kernel initialization of graphics devices. However, until it's finished and works properly -- I think we'd both agree that it shouldn't be on our systems. I know it's not a good test for everything, but have you noticed how many other desktop distros have chosen to include beagle? #17: Sebastian Rösgen (palimpseste) (2009-02-19 18:16:48) (reply to #16) Ok, I see your point. Perhaps beagle is indeed not a good solution and I was too narrow minded to realize it. (Though I haven't experienced the CPU problems anymore for about one year, I suppose you are right). Especially since the development of beagle has come to a crawl (the last release: 0.3.9 was released about four weeks ago but it needed nearly half a year to be released and contains only some mere bug fixes). I think, I am going to open a new feature request in openFate. If you (and the other guys) are not against desktop search, but instead against beagle, it could be interesting to discuss why Tracker (http://projects.gnome.org/tracker/index.html) should not become a replacement for beagle. Especially since KDE has now Strigi as a core component. So one can get rid of beagle and use some "quasi native" tools for desktop search (namely "strigi" and "tracker") on Gnome and, respectively, KDE. Anyway, thanks for your reply and the discussion. #18: Sebastian Rösgen (palimpseste) (2009-02-19 18:23:53) (reply to #17) Hm, as it seems I cannot open such a request. Wonderful! So perhaps somebody has read this discussion and might be so kind to at least evaluate the request and "perhaps" might open a new feature request concerning the replacement of beagle by Tracker (which is a Gnome Desktop search, but since KDE has already its own Desktop search this should not be that problematic... I hope) And before somebody asks: no I will not file a feature request via bug tracking system. Those usually take weeks or even months before they are answered/evaluated/discussed etc... #19: Federico Lucifredi (flucifredi) (2009-02-19 16:52:12) (reply to #18) Hello Sebastian - I do not take the thread as being "against desktop search", which is a great feature, or against Beagle, which I personally run. The decision is only to have Beagle not be running by default out of the box, but to have it installed and ready. The first time a search is performed, we ask. Users who want desktop search select to run it, and those who are more "frugal" in terms of CPU do not. I am running a 3 year old laptop, and Beagle is running just fine for me. I suspect that's the case for a lot of people. But it is still a good idea to ask for a choice. #20: Eric Springer (erikina) (2009-02-22 03:03:55) (reply to #17) 100% agree. I think tracker/strigi make wonderful replacements. :) #22: andrea florio (anubisg1) (2009-02-25 00:40:51) (reply to #20) indeed... beagle is to heavy, traker instead, is simply wonderful! #23: Barbara Hudson (barbie_h) (2009-03-04 02:22:21) (reply to #15) I was going to vote in favour of the request, because I've been bitten by beagle bringing machines to a crawl many times, but one thing I've noticed is that, as people move to dual / quad -core machines, it's no longer a big issue. I'm not saying ignore the memory and resource problems - just that even laptops nowadays can run plasma and beagle and still feel responsive. The current system, where it notifies you when it does the initial indexing, is a lot better than the computer slowing to a crawl on a fresh install and people wondering why openSUSE is soooo slow. #21: Stanislav Visnovsky (visnov) (2009-02-24 09:10:56) Coolo, I believe this should be done via patterns. #24: Stephan Kulow (coolo) (2009-03-04 11:52:23) (reply to #21) having a desktop search easy to enable sounds like a good to have feature, so I wouldn't simply remove the package from install. But it doesn't make sense on a KDE4 desktop (and it's not there in 11.1 afaik) and it doesn't have to be running by default for GNOME either. But this is something for the beagle maintainers to decide. #25: Stephan Kulow (coolo) (2009-03-04 11:53:33) (reply to #24) that is: it should be off by default (seeing all the votes). But if it's worth to make it easier to turn it on than it is, I leave to those that know. But the solution to enable it, should be within the desktop. #27: Jan Engelhardt (jengelh) (2009-03-16 18:03:00) Less than "easy way to disable beagle completey during installation" it should even be "disable beagle by default", thank you. #28: Marcel Müller (open_assistant) (2009-03-16 20:32:45) great idea, especially to my slowly pc #30: Gabriel Stein (gabrielstein) (2009-04-03 21:15:44) Totally Agree. I just post on my blog, and I will pay 5 pints of Guinness to the great developer which will do that amazing thing. #31: john andersen (jsamyth) (2009-04-16 20:22:51) I agree Beagle should be an optional item, not installed by default.   There, I've said it.   But an alternative might be to install it and restrict it't indexing BY DEFAULT to the user's home directory, (and perhaps the user's mail spool), and hava a configuration window that allows adding additional directories. That is a feature that might make it more palletable.  But realistically, when this many people arrive at a Future Feature site begging and pleading for a package to dropped from a normal installation you should assume there are some serious flaws with that package.  This site should be about new and improved features we would all like to see, but instead this thread is focused on something that has been rammed down our throats for way too many releases, and which has historically been difficult to remove.   Side issue: Unless you are a Linux Developer there is no point in having it index the entire hard drive.  Your average user has no need of these areas, and experienced users already know where things are, so a generalized indexer that searches the entire disk is a solution looking for a problem. #32: jean-christophe baptiste (phocean) (2009-04-27 11:28:48) Ok for those who want to get an easy way to disable Beagle. But it should be activated by default. I am using Beagle intensively (on Gnome) and I have never got a problem with it. It just rocks and a huge time saver to me. Maybe my hardware is just not obsolete (Core 2 duo laptop)... I think it is the kind of killer app good to show off and that can bring more new users. #33: andrea florio (anubisg1) (2009-05-12 20:04:51) (reply to #32) you are luky then.. beagle on my pc make them very very slower, it should be disabled by default, if you need it, then you insta/activate it #34: Marc collin (collinm) (2009-07-04 15:03:05) Disable it by default, i use kde... and there is alreay a solution for it.... we could also disable mono... #35: Michael Löffler (michl19) (2009-07-07 11:29:54) Vincent, can you do this? As it is our highest rated feature it would be very good to have implemented rather soon then later. Thanks. #36: Vincent Untz (vuntz) (2009-07-07 12:09:24) Well, it depends on what is the decision here: * if it's something that should be done during installation, I have no idea how to implement that. * If it's just disabling beagle by default, I'll need to investigate, but it hopefully only is changing something in a .desktop file. So what's the process on taking a decision here? That being said, just disabling beagle by default might expose a usability issue: if it's disabled, it will not index files. So when the user searches for something for the first time, it will not work and users won't understand it, and will just give up on it. (It might be solvable with a nice message the first time the user does a search, though) #37: Michael Löffler (michl19) (2009-07-07 14:43:12) (reply to #36) Vincent, please see #1. What you describe is exactly what Federico suggested as well. So I'd say disable beagle by default and offer option to run at first search. #38: Karl Eichwalder (keichwa) (2009-07-07 15:08:23) (reply to #37) IIRC, the kde help center works this way and it is rather annoying. Most of the time, the desktop computer idles... I think on the Mac the desktop search (spotlight) is enabled by default. #39: Stephan Kulow (coolo) (2009-07-07 15:16:24) (reply to #38) you're wrong. Most of the time, the desktop computer saves power. #40: Karl Eichwalder (keichwa) (2009-07-07 15:36:52) (reply to #39) Yes, you are right. Once the work is done. On my desktop at work, beagled and beagled-helper do not cause any notable load. It's different on my test machine, though. #41: Dean Hilkewich (deanjo13) (2009-07-07 16:36:55) (reply to #38) When it comes to indexing services spotlight is far ahead of beagle in usability and performance. It is also easily disabled with a system setting if desired. Even on old G4's spotlight doesn't kill performance like beagle does. #42: Segundo Luis Martín Díaz Sotomayor (zchronos) (2009-07-07 17:47: 18) Beagle should be disabled by default. #49: Vincent Untz (vuntz) (2009-07-18 18:42:21) Fixed in GNOME:Factory, and submitted to openSUSE:Factory (#14802). + #51: Hecke Degering (hecke_goe) (2009-08-10 09:02:11) + just heard about this request... + i would like to strongly support it. + Beagle eats way too much ressources away for something to be + convenient. + btw: in our institutes desktop configuration (OpenSuse, ~60machines) we + got rid of beagle totally. Unfortunately some packages depend on beagle- + lib, so there is some leftover in the package selection, but this + should not harm, hopefully;-) -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

09 Aug '09

Feature changed by: Jan Engelhardt (jengelh) Feature #305317, revision 21 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: New 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? -- openSUSE Feature: https://features.opensuse.org/305317

1 0