April 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 303520] Default NTP Setup
by fate_noreply＠suse.de 13 Apr '09

13 Apr '09

Feature changed by: Johan Kotze (gogga) Feature #303520, revision 23 Title: Default NTP Setup openSUSE-11.1: Done Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Federico Lucifredi (flucifredi) Description: A Yast pane should prompt for NTP set up, which should be configured by default, but of course can also be disabled there. Relations: - suse.pool.ntp.org (feature/id: 302915) - Depens on (feature/id: 303521) Documentation Impact: Installation guide needs to be updated. [0123].opensuse.pool.ntp.org mentioned for openSUSE. If you want me to document something for SLE11, please set the Doc Status accordingly. Discussion: #1: Stanislav Visnovsky (visnov) (2008-06-17 12:56:47) Federico, NTP setup is already possible. Do you want it in a more prominent place? Also I see a missing way for the product to pre-define the value, correct? #2: Federico Lucifredi (flucifredi) (2008-06-23 21:03:12) (reply to #1) right. I want to see it pre-enabled by default againt a dedicated suse.pool. ntp.org / time.novell.com server (separate feature for that). We are lagging a bit behind Win and Mac where the vendos provide their own time source, and we need to catch up there. #3: Jiri Srain (jsrain) (2008-07-07 12:18:32) We will need not only to enable NTP during installation, but display this information in the installation proposal (and possibly time zone dialog) as well. #6: Jiří Suchomel (jsuchome) (2008-08-12 13:27:44) (reply to #3) OK, this (http://w3.suse.de/~jsuchome/screenshots/yast2-timezone-ntp-status.png) is proposal how to show the info in current time zone dialog. It is probably bad that status is part of the frame label, but I didn't want to take more space from the whole dialog by adding new line... #4: Stephan Kulow (coolo) (2008-07-31 16:15:46) for openSUSE it's 0.opensuse.pool.ntp.org 1.opensuse.pool.ntp.org 2. opensuse.pool.ntp.org 3.opensuse.pool.ntp.org, for SLE there is no NTP server. time.novell.com can not be used, IS&T does not provide that level of service. #7: Jiří Suchomel (jsuchome) (2008-09-02 16:05:00) Alpha2 solution is working, to solve remaining issues there is a bug 422128. + #8: Johan Kotze (gogga) (2009-04-13 14:58:56) + Just to throw a spanner in the works - why don't we use geo-ip location + to pre-fill the timezone. I know this requires a working ip, but just a + suggestion. -- openSUSE Feature: https://features.opensuse.org/303520

1 0

[openFATE 305336] Ship man page for every executable
by fate_noreply＠suse.de 09 Apr '09

09 Apr '09

Feature changed by: Praveen Kunjapur (stilo_vingyou) Feature #305336, revision 28 Title: Ship man page for every executable openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Matthias Eckermann (mge1512) Description: 1. Even graphical applications need docs outside the application itself. The need to run the application, to know what does it does, is not good. 2. You need a standard documentation format; where standard = expected for people needing that documentation. Who are, often, not knowing the distro well (so the format can't be distro-specific). And the format must be the same for all binaries/packages. One can't rely on the fact it will always be easy and intuitive to find that some application is part KDE (for example) and one can get the documentation in konqueror when typing 'help:/application'. 3. To view the documentation must be as easy as possible and with as minimal resources as possible. This is why online documentation is not so good (you need a running Internet net connection), documentation in a web browser as well (you need X and graphical desktop). HTML is questionable as it (as a format) allows so many extensions that it is needed to expect that such documentation will not be readable in text browsers after some time. 4. Many parts are shared between openSUSE and the enterprise products. And, in the enterprise world, we need to be much more standard conforming. Including the documentation. A UNIX admin will use the 'man' command for getting info about the binary. 'info' system is here as well, for many years. But 'man' is still more usual. Imagine a server room with hundreds/thousands of servers of several UN*X clones - 'man' works everywhere, and Linux is expected to be "on par" also with respect to those capabilities. These four points stay behind the idea of man pages needed and provided for everything. Relations: - How to Create Manpages with DocBook (url: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook) - At http://en.opensuse.org/Manual_Pages/Missing a list of all packages with missing man pages can be found (url: http://en.opensuse.org/Manual_Pages/Missing) Use Case: User / Administrator should find a dedicated man page for every executable in openSUSE and SUSE Linux Enterprise systems. Discussion: #2: Stefan Behlert (sbehlert) (2008-10-22 15:00:11) I agree with the intention, but shouldn't it be rather 'documentation for each executable'? Newer stuff uses mostly info-pages, afaiks #3: Matthias Eckermann (mge1512) (2008-11-10 14:31:15) (reply to #2) It is valid to have a pointer to the info pages in the man-pages, sure. But man-pages are the UNIX proposed way of doing documentation. #9: Thomas Schraitle (thomas-schraitle) (2009-02-20 09:54:09) IMHO DocBook would be very suitable for this task as nobody has to learn the awkward syntax of groff/troff/... For example, I've submitted a DocBook file to the scout author and he generates the manpage with the DocBook stylesheets automatically. If you think, a manpage is not enough, each DocBook file can be easily transformed into (X)HTML, PDF, or almost any other output formats. IHMO it saves time if you want to support more formats than just manpage. The whole process is documented here: http://en.opensuse.org/Manual_Pages/How_to_Create_Manpages_with_DocBook #10: Jan Engelhardt (jengelh) (2009-02-21 20:31:14) (reply to #9) Manpages are very suitable for this task as nobody has to learn the awkward DocBook syntax. If done right, manpages are just another markup language and there are just a few elements one needs to know. (You can even count them in your hands: .TH, .SH, .SS, .PP, .TP, .nf/.fi, \fB, \fI, \fP, and sometimes . IP. They almost map to HTML's title, h1, h2, p, (no direct eqv), pre, b, i, /b|/i, and ol|ul, respectively.) + #11: Praveen Kunjapur (stilo_vingyou) (2009-04-09 21:38:39) + Knowledge is power. -- openSUSE Feature: https://features.opensuse.org/305336

1 0

[openFATE 303534] Extend BarGraph Widget
by fate_noreply＠suse.de 09 Apr '09

09 Apr '09

Feature changed by: Duncan Mac-Vicar (dmacvicar) Feature #303534, revision 26 Title: Extend BarGraph Widget openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Arvin Schnell (aschnell) Requested by: Matthias Eckermann (mge1512) Description: The latest mockups for the partitioner contain an BarGraph with additional features: * legend * several areas with same color/legend * a bit small (maybe not so important) Here is a picture (http://w3.suse.de/~aschnell/bg2.png) from the mockup. Relations: - Enhance partitioner to be more user friendly (novell/bugzilla/id: 390213) https://bugzilla.novell.com/show_bug.cgi?id=390213 - Graphical Display of Hard Disk partitions (novell/bugzilla/id: 414322) https://bugzilla.novell.com/show_bug.cgi?id=414322 - Blog Comment praising GParted (url: http://lizards.opensuse.org/2009/03/06/context-menus-in-yast-partitioner/#c…) Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:15:21) Stano, if we need it it is of course M. Let me know, I just have no business reasons, this is entirely an engineering decision. #2: Stefan Hundhammer (sh-sh-sh) (2008-06-17 15:29:07) What's wrong with using the _existing_ widget with its existing features? #3: Stanislav Visnovsky (visnov) (2008-06-17 15:54:05) Agreement is that this is not needed. #4: Katarina Machalkova (kmachalkova) (2009-02-25 16:43:41) Can we please re-consider this for openSUSE 11.2 ? Some visualization of used/free space ratio on the disk/partition, or the whole disk layout in the partitioner overviews would be nice. The problem (not the only one) with current bar graph widget is that if some portion of the graph becomes too small, the text on it is no longer readable. A legend of the graph (as depicted above) would help a lot, but at the very minimum, some tooltips over the graph parts could be added #5: Michael Löffler (michl19) (2009-03-25 17:27:12) (reply to #4) It looks still like an engineering decsion. Stano please re-consider or reject ;-) #6: Arvin Schnell (aschnell) (2009-03-25 17:53:24) (reply to #5) I don't understand why this should be an engineering decision. This feature will directly influence what the users see. It's not a detail hidden deep in source code that makes geeks say "wow" if they should find it while being bored to death. This is a feature users are constantly asking for! #11: Jean-Daniel Dodin (jdd_sysop) (2009-04-08 20:53:33) gparted is much friendly than YaST. shame. jdd #12: FERNANDO RUBEN ESPINOSA RAMIREZ. (fersito) (2009-04-09 04:01:51) You must to do what ever you want Katarina so in order to learn like myself.-fernando (from Leòn GTO. Mexico)greetings. + #13: Duncan Mac-Vicar (dmacvicar) (2009-04-09 11:03:22) (reply to #12) + This is even a fake email. + Final-Recipient: rfc822; ferub(a)att.net.mx Action: failed Status: 5.0.0 + Diagnostic-Code: X-Postfix; host mailin-02.mx.aol.com[64.12.137.89] + said: 550 MAILBOX NOT FOUND (in reply to RCPT TO command) -- openSUSE Feature: https://features.opensuse.org/303534

1 0

[openFATE 303534] Extend BarGraph Widget
by fate_noreply＠suse.de 09 Apr '09

09 Apr '09

Feature changed by: FERNANDO RUBEN ESPINOSA RAMIREZ. (fersito) Feature #303534, revision 25 Title: Extend BarGraph Widget openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Arvin Schnell (aschnell) Requested by: Matthias Eckermann (mge1512) Description: The latest mockups for the partitioner contain an BarGraph with additional features: * legend * several areas with same color/legend * a bit small (maybe not so important) Here is a picture (http://w3.suse.de/~aschnell/bg2.png) from the mockup. Relations: - Enhance partitioner to be more user friendly (novell/bugzilla/id: 390213) https://bugzilla.novell.com/show_bug.cgi?id=390213 - Graphical Display of Hard Disk partitions (novell/bugzilla/id: 414322) https://bugzilla.novell.com/show_bug.cgi?id=414322 - Blog Comment praising GParted (url: http://lizards.opensuse.org/2009/03/06/context-menus-in-yast-partitioner/#c…) Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:15:21) Stano, if we need it it is of course M. Let me know, I just have no business reasons, this is entirely an engineering decision. #2: Stefan Hundhammer (sh-sh-sh) (2008-06-17 15:29:07) What's wrong with using the _existing_ widget with its existing features? #3: Stanislav Visnovsky (visnov) (2008-06-17 15:54:05) Agreement is that this is not needed. #4: Katarina Machalkova (kmachalkova) (2009-02-25 16:43:41) Can we please re-consider this for openSUSE 11.2 ? Some visualization of used/free space ratio on the disk/partition, or the whole disk layout in the partitioner overviews would be nice. The problem (not the only one) with current bar graph widget is that if some portion of the graph becomes too small, the text on it is no longer readable. A legend of the graph (as depicted above) would help a lot, but at the very minimum, some tooltips over the graph parts could be added #5: Michael Löffler (michl19) (2009-03-25 17:27:12) (reply to #4) It looks still like an engineering decsion. Stano please re-consider or reject ;-) #6: Arvin Schnell (aschnell) (2009-03-25 17:53:24) (reply to #5) I don't understand why this should be an engineering decision. This feature will directly influence what the users see. It's not a detail hidden deep in source code that makes geeks say "wow" if they should find it while being bored to death. This is a feature users are constantly asking for! #11: Jean-Daniel Dodin (jdd_sysop) (2009-04-08 20:53:33) gparted is much friendly than YaST. shame. jdd + #12: FERNANDO RUBEN ESPINOSA RAMIREZ. (fersito) (2009-04-09 04:01:51) + You must to do what ever you want Katarina so in order to learn like + myself.-fernando (from Leòn GTO. Mexico)greetings. -- openSUSE Feature: https://features.opensuse.org/303534

1 0

[openFATE 303534] Extend BarGraph Widget
by fate_noreply＠suse.de 08 Apr '09

08 Apr '09

Feature changed by: Jean-Daniel Dodin (jdd_sysop) Feature #303534, revision 23 Title: Extend BarGraph Widget openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Arvin Schnell (aschnell) Requested by: Matthias Eckermann (mge1512) Description: The latest mockups for the partitioner contain an BarGraph with additional features: * legend * several areas with same color/legend * a bit small (maybe not so important) Here is a picture (http://w3.suse.de/~aschnell/bg2.png) from the mockup. Relations: - Enhance partitioner to be more user friendly (novell/bugzilla/id: 390213) https://bugzilla.novell.com/show_bug.cgi?id=390213 - Graphical Display of Hard Disk partitions (novell/bugzilla/id: 414322) https://bugzilla.novell.com/show_bug.cgi?id=414322 - Blog Comment praising GParted (url: http://lizards.opensuse.org/2009/03/06/context-menus-in-yast-partitioner/#c…) Discussion: #1: Federico Lucifredi (flucifredi) (2008-06-13 15:15:21) Stano, if we need it it is of course M. Let me know, I just have no business reasons, this is entirely an engineering decision. #2: Stefan Hundhammer (sh-sh-sh) (2008-06-17 15:29:07) What's wrong with using the _existing_ widget with its existing features? #3: Stanislav Visnovsky (visnov) (2008-06-17 15:54:05) Agreement is that this is not needed. #4: Katarina Machalkova (kmachalkova) (2009-02-25 16:43:41) Can we please re-consider this for openSUSE 11.2 ? Some visualization of used/free space ratio on the disk/partition, or the whole disk layout in the partitioner overviews would be nice. The problem (not the only one) with current bar graph widget is that if some portion of the graph becomes too small, the text on it is no longer readable. A legend of the graph (as depicted above) would help a lot, but at the very minimum, some tooltips over the graph parts could be added #5: Michael Löffler (michl19) (2009-03-25 17:27:12) (reply to #4) It looks still like an engineering decsion. Stano please re-consider or reject ;-) #6: Arvin Schnell (aschnell) (2009-03-25 17:53:24) (reply to #5) I don't understand why this should be an engineering decision. This feature will directly influence what the users see. It's not a detail hidden deep in source code that makes geeks say "wow" if they should find it while being bored to death. This is a feature users are constantly asking for! + #11: Jean-Daniel Dodin (jdd_sysop) (2009-04-08 20:53:33) + gparted is much friendly than YaST. shame. jdd -- openSUSE Feature: https://features.opensuse.org/303534

1 0

[openFATE 305473] virt-manager: add option to set the keymap via UI for every VM
by fate_noreply＠suse.de 07 Apr '09

07 Apr '09

Feature changed by: Michael Rybin (mrybin) Feature #305473, revision 7 Title: virt-manager: add option to set the keymap via UI for every VM - openSUSE-11.2: New + openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Michael Calmer (mcalmer) Description: If the default keyboard mapping does not work, it is difficult to set the keymap manual. A option in virt-manager to change the keymap setting via the UI for a single VM would be good to have. See also Bug #444632 Relations: - Wrong default keymap configured. Cannot enter important chars with vncviewer (novell/bugzilla/id: 444632) https://bugzilla.novell.com/show_bug.cgi?id=444632 -- openSUSE Feature: https://features.opensuse.org/305473

1 0

[openFATE 306340] Creation of a list of all tags
by fate_noreply＠suse.de 06 Apr '09

06 Apr '09

Feature added by: Michael Löffler (michl19) Feature #306340, revision 1, last change by Title: Creation of a list of all tags openFATE: Unconfirmed Priority Requester: Desirable Requested by: Michael Löffler (michl19) Description: Creation of a list of all tags makes life easier and avoid creation of very similar tags which in fact could be united under one tag. -- openSUSE Feature: https://features.opensuse.org/306340

1 3

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

03 Apr '09

Feature changed by: Gabriel Stein (gabrielstein) Feature #305296, revision 64 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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

[openFATE 302446] Power consumption gauge
by fate_noreply＠suse.de 02 Apr '09

02 Apr '09

Feature changed by: Stefan Behlert (sbehlert) Feature #302446, revision 25 Title: Power consumption gauge openSUSE-11.0: Rejected by Gary Ekker (gekker) reject date: 2008-05-09 10:28:15 reject reason: Nothing done for 11.0. Priority Requester: Desirable openSUSE-11.1: Rejected by JP Rosevear (jproseve) reject date: 2008-09-10 16:50:33 reject reason: Dependent feature not complete. Priority Requester: Desirable Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Desirable + Projectmanager: Desirable Requested by: Frank Seidel (fseidel) Description: Some kind of "power meter" would be good to have. It could be integrated into the system monitor applet or in kpowersave/gnome-power- manager (to be discussed). Its intent is to make the user aware when the system starts to hog power (e.g. after starting some bad behaving application that polls "expensive" hardware all the time). Some kind of "power meter" would be good to have. It could be integrated into the system monitor applet or in kpowersave/gnome-power-manager (to be discussed). Relations: - provide common source for a overall battery time information (feature/id: 303749) Documentation Impact: Needs to be documented Discussion: #1: Michael Löffler (michl19) (2008-02-01 11:56:22) In regards of Green IT theme for SLE 11 this sounds like useful thing. #2: Stefan Behlert (sbehlert) (2008-05-29 23:23:48) (reply to #1) Right.. #4: JP Rosevear (jproseve) (2008-06-02 13:52:01) Christian, can we actually aggregate power consumption information from somewhere? If so, getting a gui on top of it should be straight forward. #5: Christian Zoz (zoz) (2008-06-19 15:03:57) Power consumption information is only available when the system runs on battery. But i guess on ac-power this info is less interesting anyway. We can get this information via ACPI. Not really power consumption, but power drain of each battery. I suggest that hal can provide individual drain and aggregate overall power consumption. For that have a look at feature: #303749: provide common source for a overall battery time information #6: Rodrigo Moya (rodrigomoya) (2008-09-08 14:43:35) For gnome-power-manager, we already have something like this (right- click -> power history), it shows lots of information about powe consumption. Isn't this enough? #7: JP Rosevear (jproseve) (2008-09-10 16:49:55) Fate 303749 is not complete, so I think I have to reject this. -- openSUSE Feature: https://features.opensuse.org/302446

1 0

[openFATE 306327] Add DB2 Express-C
by fate_noreply＠suse.de 02 Apr '09

02 Apr '09

Feature changed by: Robert Schweikert (rjschwei) Feature #306327, revision 2 Title: Add DB2 Express-C openSUSE-11.2: New Priority Requester: Desirable Requested by: Robert Schweikert (rjschwei) - Partner organization: IBM Description: IBM is interested to providing an easy mechanism for users to install DB2 Express C, the free version of DB2. It would be nice if we could add DB2 Express C to the openSUSE non-oss repository. - Business case (Partner benefit): - IBM: This is in support of our partnership with the IBM software group - information management team. Easy access to DB2 Express C will increase - their visibility as an available database on Linux. -- openSUSE Feature: https://features.opensuse.org/306327

1 0