July 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306748] video4linux stream sharing with a server daemon
by fate_noreply＠suse.de 08 Jul '09

08 Jul '09

Feature added by: Brandon Philips (philipsb) Feature #306748, revision 1 Title: video4linux stream sharing with a server daemon Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Brandon Philips (philipsb) Description: Video devices currently can only be open by one process at a time. This makes it impossible to do necessary things like software auto-focus or recording video while using ekiga. A server, similar to PulseAudio, is necessary to make this possible. This HackWeek project aims to work to create a v4l server. -- openSUSE Feature: https://features.opensuse.org/306748

1 0

[openFATE 306731] robot to populate BS project home:cpan
by fate_noreply＠suse.de 07 Jul '09

07 Jul '09

Feature added by: Juergen Weigert (jnweiger) Feature #306731, revision 1 Title: robot to populate BS project home:cpan Hackweek IV: Unconfirmed Priority Requester: Important Requested by: Juergen Weigert (jnweiger) Description: Create a robot that autocreates spec files for all perl packages found on cpan.org -- openSUSE Feature: https://features.opensuse.org/306731

1 1

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

07 Jul '09

Feature changed by: Segundo Luis Martín Díaz Sotomayor (zchronos) Feature #305296, revision 96 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation 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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

07 Jul '09

Feature changed by: Dean Hilkewich (deanjo13) Feature #305296, revision 95 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation 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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 07 Jul '09

07 Jul '09

Feature changed by: Michael Schröder (mlschroe) Feature #305553, revision 16 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) So multiple repositories are not a problem in general, but multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute? If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right? + #13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12) + ma, is there a libzypp interface? -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305553] zypper: dist upgrade could error out if more than one repository exists
by fate_noreply＠suse.de 07 Jul '09

07 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305553, revision 15 Title: zypper: dist upgrade could error out if more than one repository exists openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Dirk Mueller (dirkmueller) Description: I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. apparently one has to call it with -r name, where name points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given. Relations: - make zypper dup error out if more than one repository exists (novell/bugzilla/id: 385972) https://bugzilla.novell.com/show_bug.cgi?id=385972 Discussion: #1: Stephan Kulow (coolo) (2008-05-11 02:20:39) * ** Bug 388956 has been marked as a duplicate of this bug. *** #2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24) Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)? Currently they can't, we need to add means of such identification (as well as identification of update repos). yup, sounds good #3: Lukas Ocilka (locilka) (2008-05-12 06:17:43) Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver. OK, some packages are dropped by installation by default :) See bug #300540. #4: Stephan Kulow (coolo) (2008-05-12 06:25:06) the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup. BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update #5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35) Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid. #7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5) I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-( #8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7) The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out). What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there. #9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8) Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever. #6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19) Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed. #10: Ján Kupec (jkupec) (2009-06-24 09:33:26) Michael, is this still relevant? Is this related to the planned --from option? #11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10) This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled. + #12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11) + So multiple repositories are not a problem in general, but multiple + repos for different products are! OK, so now back to the solution: can + you tell me or point me to some info abou these CPEs Duncan mentions in + c#6? I guess they are part of the product solvable and are available as + solv attribute? + If so, all that's needed is to check whether there are multiple repos + with a different product and write a warning if that's the case, + right? -- openSUSE Feature: https://features.opensuse.org/305553

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 07 Jul '09

07 Jul '09

Feature changed by: Ján Kupec (jkupec) Feature #305503, revision 24 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) Well, my objection is the new term 'fix' besides 'update' and 'patch' and will confuse people. It should be an option to "list" or "list-patches" imho + #16: Ján Kupec (jkupec) (2009-07-07 16:16:12) (reply to #15) + OK, so far the following looks like a candidate (taken yum into account + as well): + # to install a fix + $ zypper patch [--bz #] [--cve #] [--any-other #] + # to list available needed fixes (issue-number, patchname-version, + category, description) + # all + $ zypper list-patches --issues + # matching a substring ("CVE", number, or any) + $ zypper list-patches --issues foo + # only CVEs/bugzillas + $ zypper list-patches [--cve] [--bz] -- openSUSE Feature: https://features.opensuse.org/305503

1 0

[openFATE 305503] zypper: allow update by issues/bugs/advisories
by fate_noreply＠suse.de 07 Jul '09

07 Jul '09

Feature changed by: Klaus Kämpf (kwk) Feature #305503, revision 23 Title: zypper: allow update by issues/bugs/advisories openSUSE-11.2: Candidate Priority Requester: Desirable Projectmanager: Mandatory Requested by: Duncan Mac-Vicar (dmacvicar) Partner organization: openSUSE.org Description: Description: YUM security plugin allows to filter updates showing only ones that mention certain issues. Example: yum update --security yum update --bz 410101 yum update --cve CVE-2007-5707 --advisory RHSA-2007:1082-5 As our patches contains this metadata, we could add similar functionality to zypper. Scope The scope is only for zypper. Other front ends would require some GUI concept first. Open Issues: libzypp's PoolQuery would need support for subattributes (updateinfo. xml references are stored as subarrays) User experience * Adds command line options like the ones described above. Dependencies * libzypp Contingency Plan * Feature is new, so in a bad scenario it can simple be deactivated. Relations: - updateinfo XML scheme (url: http://git.opensuse.org/?p=projects/zypp/libzypp.git;a=blob_plain;f=zypp/pa…) - Tips and tricks: yum-security (url: http://www.redhatmagazine.com/2008/01/16/tips-and-tricks-yum-security/) Documentation Impact: New command line options would need to be documented. Test Case: The testing of this feature can be done creating a repository (for example using enhancerepo) containing patches that reference issues, like described in http://en.opensuse.org/Maintenance/Code11/Howto , and then performing updates passing to zypper command line the issues, confirming that only those issues are shown. Use Case: Sysadmin is only interested in particular updates to solve security issues or specific bug numbers or advisories. Business case (Partner benefit): openSUSE.org: Sysadmins do not update ther systems without a strict process and maximum care. Therefore it is very important to allow them to update the system to fix a single issue. It would save them the time to look that themselves package per package. Discussion: #1: Marcus Meissner (msmeissn) (2008-12-03 14:51:14) Random notes: - CVE-XXXX-YYYY RPM provides after fixing issues? - OVAL relation? #2: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:02:46) (reply to #1) About CVE provides. Right now the CVE information is in the patch (since 11.0). I don't have anything against having it as Fix(CVE-XXX-XXX) provides, but I am not sure if having them in both makes sense. Specially in the case that one issue needs more than one package, you will need to install all packages fixing the issue, and if you have 2 repos with 2 same packages providing the issue, they will conflict. #3: Duncan Mac-Vicar (dmacvicar) (2008-12-03 16:08:13) (reply to #1) I don't have knowledge how OVAL works, may be you can provide some very concrete example scenarios for the feature described above. What I can say is that the reason why the repository/product compatibility and update information in SLE11/openSUSE 11.1 is supported using CPE ( that is, product can contain a CPE id, and repos can tell to which CPE they are compatible and which CPE they update with fixes ) was to enhance our ability to do semantic queries like relate upstream security issues and installed products. OVAL uses CPE as the platform descriptor AFAIK. #4: Dirk Mueller (dirkmueller) (2008-12-04 14:58:01) adding rpm provides was also my first idea, but that has a side effect: often enough, CVE numbers are not yet known when the package is built and ends up in QA, and editing rpm provides essentially needs a rebuild, which invalidates QA. so preferably we need a way to update the rpm provides without doing a rebuild (bad) or we need a way to add it to the meta information (which is currently generated via patchinfo and where it is also too late). an idealistic approach would be to make sure that we can update this meta information after patchinfo checkin (entering the data into swamp and autobuild fetches that information when the update is released and adds it to the meta info). #5: Federico Lucifredi (flucifredi) (2009-01-07 15:52:34) This has quite a bit of customer value. BTW, there may be a duplicate out there #6: Michael Andres (mlandres) (2009-07-01 18:33:01) libzypp-6.9.2 supports PoolQuery of subattributes. So one can e.g search for patches with updateReferenceId "CVE-2007-5707', or of updateReferenceType 'bugzilla",... (I'll provide some sample code) @Jano: I'll provide some code example, that tells how to access and iterate the matching updateReferences. So you could start working on zypper. #7: Ján Kupec (jkupec) (2009-07-03 15:10:56) Thanx! I have a question about the reference types. What types do we support? in updateinfo.rnc (see references) i only see bugzilla and cve Do we want separate options for all supported types, like yum has? #9: Ján Kupec (jkupec) (2009-07-03 15:57:19) (reply to #7) Also, i noticed in 11.1 updates repository, that many bugs have a CVE, but it's only in the description, not in the 'reference' metadata. Only bugzilla is in 'reference'. Do we want to address this? #10: Marcus Meissner (msmeissn) (2009-07-03 15:59:21) (reply to #9) we are not emitting it yet. this also needs to be done :/ #8: Ján Kupec (jkupec) (2009-07-03 15:20:18) Suggestion how the commands could look like: $ zypper fix --search [string] $ zypper fix --bugzilla <#> $ zypper fix --cve <#> #11: Klaus Kämpf (kwk) (2009-07-04 12:11:44) (reply to #8) Please re-think about introducing another term ( fix ), we already have * update * upgrade * patch #12: Ján Kupec (jkupec) (2009-07-07 10:11:04) (reply to #11) What i try to achieve is to have a way to install the patches fixing the issues and a way to list them (issue number & patch name & (patch) description), search in them. The other alternatives i considered were: $ zypper patch [--bugzilla #] [--cve #] $ zypper list-patches --issues [string] The first command looks nice, but i don't know what to use to list/search the issues - the list-patches command does not seem right to me - looks more like it deserved a new command. $ zypper install [--bugzilla #] [--cve #] $ zypper search --issues [string] In this case, like in the 'list-patches --issues' case, the search command would either need to radically change its output, or user would need to call 'zypper patch-info the_found_patch' to get the patch description. Any other ideas? Why is having a new command a bad thing (esp. compared to having new options in the existing commands)? BTW: (We don't have 'upgrade' :O) #13: Martin Vidner (mvidner) (2009-07-07 14:33:03) (reply to #12) Why reinvent the wheel? Can we just copy yum's interface as described in the referenced yum-security article? * http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/ (http://magazine.redhat.com/2008/01/16/tips-and-tricks-yum-security/) * http://linux.die.net/man/8/yum-security (http://linux.die.net/man/8/yum-security) #14: Ján Kupec (jkupec) (2009-07-07 14:57:27) (reply to #13) 'zypper update' does not work with patches. 'zypper patch' looks to me like better candidate for new --bz or --cve options. yum does not make difference between these two. The yum plugin also adds a new command (list-sec), which was Klaus' objection. + #15: Klaus Kämpf (kwk) (2009-07-07 15:51:26) (reply to #14) + Well, my objection is the new term 'fix' besides 'update' and 'patch' + and will confuse people. + It should be an option to "list" or "list-patches" imho -- openSUSE Feature: https://features.opensuse.org/305503

1 0

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

07 Jul '09

Feature changed by: Karl Eichwalder (keichwa) Feature #305296, revision 94 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation 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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

07 Jul '09

Feature changed by: Stephan Kulow (coolo) Feature #305296, revision 93 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation 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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0