March 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 306008] Ship projects more vanilla
by fate_noreply＠suse.de 05 Mar '09

05 Mar '09

Feature added by: Klaas Freitag (kfreitag) Feature #306008, revision 1, last change by Title: Ship projects more vanilla openSUSE-11.2: Unconfirmed Priority Requester: Important openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Klaas Freitag (kfreitag) Description: Upstream projects such as KDE 4 often are developed with very high care for usability, design and eye candy, staffed with high skilled specialists and/or artists. openSUSE modifications against the vanilla versions sometimes do not really improve the upstream version. Moreover, these kind of modifications often kind of rebrand the projects, for example by replacing the KDE startmenu button by an openSUSE branded one. The openSUSE distribution as a community project should maintain the brand of the upstream projects and not hide them from the distributions users. Also patching vanilla behaviors where not technically needed or fixing problems should be handled very carefully and only happen in good dialog with upstream. -- openSUSE Feature: https://features.opensuse.org/306008

1 0

[openFate 305170] openFATE test
by fate_noreply＠suse.de 05 Mar '09

05 Mar '09

Feature added by: Michael Loeffler <michl(a)novell.com> Feature #305170, revision 1, last change by Title: openFATE test openSUSE-11.1: Evaluation Priority Requester: Mandatory Requested by: Michael Loeffler <michl(a)novell.com> Partner organization: openSUSE.org Description: test Business case (Partner benefit): openSUSE.org: sdf -- openSUSE Feature: https://features.opensuse.org/?rm=feature_show&id=305170

1 5

[openFATE 303751] Support 802.1X Authentication on Wired Networks
by fate_noreply＠suse.de 04 Mar '09

04 Mar '09

Feature changed by: William Simon Lewis (WilliamSimonLewis) Feature #303751, revision 9 Title: Support 802.1X Authentication on Wired Networks openSUSE-11.1: Duplicate of #301902 Priority Requester: Desirable Requested by: Pavol Rusnak (prusnak) Description: SUSE Linux does not support 802.1X authentication on Wired Networks. That means that users which need this feature have to install and configure it manually. What's even worse, users in authenticated environment cannot install SUSE from network. This feature consists of 3 tasks: 1) add suport to sysconfig/netcontrol (e.g. by calling wpa_supplicant - D wired -i eth0 -c /etc/wpa_supplicant/wpa_wired.conf in network scripts) 2) add support to NetworkManager (and its frontends - NetworkManager-gnome and NetworkManager-kde) 3) add configuration dialogs to YaST (during the installation and outside the installation - on running system) PS: Fedora Rawhide (equivalent of openSUSE Factory) already has working implementation in NetworkManager-gnome. I do not know about other tasks. Discussion: #1: Steffen Winterfeldt (snwint) (2008-04-30 11:01:48) We already run wpa_suplicant during installation. Could you please explain the difference to your proposal and what exactly needs to be changed? #2: Pavol Rusnak (prusnak) (2008-04-30 11:23:26) (reply to #1) I'm talking about 802.1x authentication on wired networks (Ethernet). I'm not able to enter my credentials during install phase and even worse I cannot enter them in installed system either and I have to create wpa_supplicant with credentials by hand. #3: Steffen Winterfeldt (snwint) (2008-04-30 12:00:41) (reply to #2) And what needs to be changed to the present wpa_supplicant call? #5: Pavol Rusnak (prusnak) (2008-04-30 13:06:57) (reply to #3) Probably nothing, but installation lacks configuration of user credentials and there seem to be no way to input them in installed system too (eg. using YaST). #4: Tambet Ingo (tambet) (2008-04-30 13:22:45) NetworkManager does support wired 802.1x authentication (SLED10-SP2 and opensuse 11.0 beta1) and the feature request is already in FATE: 301902. + #6: William Simon Lewis (williamsimonlewis) (2009-03-04 21:19:41) + I would definitely vote for a much improved GUI for LAN/WLAN + configuration on openSUSE 11.1. knetworkmanager-KDE4 does not allow me + configure network connections, either LAN or WLAN. Knetworkmanager-KDE3 + automatically connects to my router over DHCP but cannot be used with a + fixed IP-address connection in order to configure my NETGEAR WG602 + access point. WLAN only works in unsecure mode - I cannot establish a + connection using WPA2-PSK. YAST 2 can be used to connect to router or + access point but I am only allowed one configuration per device. It + would be nice to be able to switch between router and access-point + configuration - which ever is plugged into my ethernet port. I cannot + get WLAN to work at all with yast but that is because openSUSE sees my + broadconm device as eth0 and not wlan0 and does not offer the right + encryption options. All-in-all network connections with cable or + wireless are very difficult to set-up with good command line knowledge + of the tools required - and I do not have this knowledge. + Please make easy WLAN configuration a very high priority - consider + also the special case where the access-point does not broadcast the + SSID for obvious reasons. -- openSUSE Feature: https://features.opensuse.org/303751

1 0

[openFATE 303749] provide common source for a overall battery time information
by fate_noreply＠suse.de 04 Mar '09

04 Mar '09

Feature changed by: Stefan Behlert (sbehlert) Feature #303749, revision 21 Title: provide common source for a overall battery time information openSUSE-11.1: Rejected by Christian Zoz (zoz) reject date: 2008-09-12 12:04:06 reject reason: We could not provide that in time. And it does not effect UI funtionality. Priority Requester: Important Projectmanager: Desirable openSUSE-11.2: Evaluation Priority Requester: Important + Projectmanager: Desirable Requested by: Danny Kukawka (dkukawka) Description: In the past we used powersaved to get battery information. Powersaved provided information about each battery but also about all batteries. There was a overall battery object which e.g. provided remaining time information for all batteries in the system (of one type). Now we use HAL to collect these information. Unfortunately there is no such overall battery object to calculate the full remaining time in multibattery machines. HAL has no such object like powersaved. AFAIK g-p-m calculates it own remaining time, but KPowersave only use the info from HAL. Because of this KPowersave show no overall remaining time. IMO it's no option to do all the magic like g-p-m in KPowersave. There should be a common place to do this and provide the same information for all applications (KDE/GNOME/....). It could be HAL or a new powermanagement daemon (like powersaved) if DeviceKit is comming. Relations: - Power consumption gauge (feature/id: 302446) - Support multiple battery indication (feature/id: 304716) Discussion: #1: Christian Zoz (zoz) (2008-06-19 14:46:22) This feature is usefull if all applications that show battery information would use it. Jared, who can tell us if g-p-m would accept that solution? - We should also enhance this feature a bit. Hal should also serve individual and overall power consumption. This is needed for feature: #302446: Power consumption gauge #3: Jared Allen (jpallen) (2008-06-19 09:29:23) (reply to #1) We need to make sure that any changes are made in time for g-p-m to take advantage of the changes in time for SLE11. Richard Hughes is the upstream maintainer. #2: Christian Zoz (zoz) (2008-06-19 15:01:35) I forgot to mention another feature that should make use of this: #304716: Support multiple battery indication #4: Christian Zoz (zoz) (2008-06-25 19:07:40) Danny, please contact Richard. Since you need that feature for kpowersave anyway, let's do it. #5: JP Rosevear (jproseve) (2008-09-11 19:36:06) I assume we are going to reject this? -- openSUSE Feature: https://features.opensuse.org/303749

1 0

[openFATE 305303] Easier language selection in grub installation screen
by fate_noreply＠suse.de 04 Mar '09

04 Mar '09

Feature changed by: Stephan Kulow (coolo) Feature #305303, revision 8 Title: Easier language selection in grub installation screen openSUSE-11.1: Rejected by Michael Löffler (michl19) reject date: 2008-09-16 18:20:46 reject reason: to late for 11.1 Priority Requester: Important - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Stephan Kulow (coolo) + reject date: 2009-03-04 12:25:36 + reject reason: see comments Priority Requester: Important Requested by: Kai Dupke (kdupke) + Partner organization: openSUSE.org Description: Change language selection in grub installation screen to allow non English speaking people to easy find the right function key. This could be done by highlighting the function key in a graphical way (ie. flag('s)) or changing the text. Test Case: Show information on boot screen for non-English speaking users how to change default language. Use Case: Show information on boot screen for non-English speaking users how to change default language. Business case (Partner benefit): - openSUSE is intend for both non-expirienced and expirienced users. Non- - expirienced users might also not be able to interpred the 'language - selection - F2' in the right way as English is not their native - language. For such user a graphical hint will be much easier. + openSUSE.org: openSUSE is intend for both non-expirienced and + expirienced users. Non-expirienced users might also not be able to + interpred the 'language selection - F2' in the right way as English is + not their native language. For such user a graphical hint will be much + easier. As non-graphical systems are only used by expirienced users this is not a need for the text screen of grub. Discussion: #2: Michael Löffler (michl19) (2008-09-16 18:24:45) Hmm, I don't see a real need for this. Maybe I'm blind but I haven't heard about language selection. #3: Kai Dupke (kdupke) (2008-09-17 10:36:45) (reply to #2) That might be as you (and many others around you) installed openSUSE already many time even don't think about the F2 key. And most other users might have a tight relation to computers so they might even be able to switch to the next screen without thinking to much. The need is usability and without this users won't raise their hands but won't install openSUSE. I got this feedback by really non-expirienced users with even no computer skills at all. Enable openSUSE for the grandfather generation :-) + #4: Stephan Kulow (coolo) (2009-03-04 12:25:23) (reply to #3) + As a matter of fact grub only runs after installation. I'm not sure if + isolinux can do icons and changing the text is pretty nonsense. If + people don't look at the bottom of the screen, they might not get the + idea at all that they can change the language. + I don't think optimzing the DVD installation for grandmas is something + we should invest in. Optimizing the live cd installation sounds like + the better investment. -- openSUSE Feature: https://features.opensuse.org/305303

1 0

[openFATE 305400] kerneloops.org for openSuSE
by fate_noreply＠suse.de 04 Mar '09

04 Mar '09

Feature changed by: Stephan Kulow (coolo) Feature #305400, revision 9 Title: kerneloops.org for openSuSE openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Brandon Philips (philipsb) Partner organization: openSUSE.org Description: Desktop integration: Stephan Kulow reported that the kerneloops-applet doesn't work under KDE. I will look into this and fix it. Installer integration: Stanislav Visnovsky suggested that Kerneloops opt-in be done in the same way as the smolt opt-in. I think this is the way to go. References: http://kerneloops.org https://bugzilla.novell.com/show_bug.cgi?id=388570 Business case (Partner benefit): openSUSE.org: Allows us to see trends in kerneloopses in our community releases on kerneloops.org and thereby improve our SLE releases. Eventually we could have the daemon report to an encrypted private internal server so we can get Kernel oops reports from enterprise customers. + Discussion: + #1: Stephan Kulow (coolo) (2009-03-04 12:03:46) + I don't want to see yet another applet for such a specific task. If + this is something that does check the log from a cron job and then + signals the desktop, I don't mind. But having another applet is a no go + - the same for something to start on boot. -- openSUSE Feature: https://features.opensuse.org/305400

1 0

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

04 Mar '09

Feature changed by: Stephan Kulow (coolo) Feature #305296, revision 48 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) #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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0

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

04 Mar '09

Feature changed by: Marcus Meissner (msmeissn) Feature #302628, revision 26 Title: Access to encrypted devices/partitons by dongle openSUSE-11.0: Rejected by Stephan Kulow (coolo) reject date: 2008-03-31 10:53:14 reject reason: too late - and still lacking a real concept behind the full story. Priority Requester: Desirable openSUSE-11.1: Rejected by Stephan Kulow (coolo) reject date: 2008-08-07 16:27:08 reject reason: out of resources. Priority Requester: Desirable openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Stefan Fent (sfent) Description: Think of the following scenario: You store your files on an encrypted partition and if you want to access them you just insert your USB stick, flash card or whatever and gain access to your files. Another thought would be to encrypt the whole system and the only possibilty to access it is via dongle. Relations: - FATE#301352: Filesystem encryption using Smartcard certificate (feature/id: 301352) Discussion: #1: Gerald Pfeifer (geraldpfeifer) (2007-10-05 23:04:19) Michele (desktop) / Matthias (storage) what do you think about this? #2: Michael Löffler (michl19) (2008-01-02 18:27:26) Nice to have but I miss a business case. #3: Stephan Kulow (coolo) (2008-01-07 14:42:28) (reply to #2) the business case of such a feature only works if you have a company to sell those dongle sticks I'd say. And those dongle vendors prefer custom boot loaders from those I know. So I don't think a solution with a stick that can be easily copied by dd is preferrable and I would rather reject this. #4: Guy Lunardi (glunardi) (2008-01-18 19:46:42) It's my understanding that Chris' work would allow for this to happen. This would be very neat indeed, we have discussed this with several customers who expressed interest. Using a simple USB key would be one inexpensive way to make this work. One alternative that a customer asked was to have the ability to unlock the data using certificates strored within a smart card. #7: Stephan Kulow (coolo) (2008-06-27 11:23:16) (reply to #4) Chris work? I fail to see the context. #9: Guy Lunardi (glunardi) (2008-07-02 15:27:37) (reply to #7) I do believe that Chris' work would be good for us to leverage however I do not know the details and could be wrong since it has been a few months now since we last talked about this. Chris, would you be able to assist me with provide insights on ways we could address this? #11: Chris Rivera (chrismrivera) (2008-07-06 23:52:49) (reply to #9) If you setup an encrypted home directory with cryptconfig it defaults to creating an encrypted container and a key file. The key file can reside anywhere, including removable media. If you use removable media you need to setup an fstab entry using the device label or device UUID to ensure that the dongle gets mounted automatically and the key file is in the right location. #12: Stephan Kulow (coolo) (2008-08-07 16:26:44) (reply to #11) ok, just talked about with Chris about this feature. We have no resources for yast work any more and the work required seem to be this: "so it would just mean moving the .key file to the media, changing the . key file location in pam_mount.conf, and adding an fstab entry" (quoting Chris). So this would be either put in a README or we wait for SPx. #13: Stephan Kulow (coolo) (2009-03-04 11:39:07) (reply to #12) any objection against opening this to openSUSE.org? + #14: Marcus Meissner (msmeissn) (2009-03-04 11:40:59) (reply to #13) + no, done #5: Stephan Kulow (coolo) (2008-03-31 10:52:41) I still have no clear picture of what cryptfs setups we're going to support - there are various fate entries about it: e,g, 302981 and 301352. So I would like PM to sort this out - and I personally think it's too late for 11.0. #6: Matthias Eckermann (mge1512) (2008-04-01 01:35:14) In an ideal world we would support: * TPM (incl. fingerprint readers etc.) * Smart Cards * simple devices with key on (USB sticks, memory cards) * passphrase (as today) * (optional) integration with a directory (LDAP, eDirectory, ...) -- openSUSE Feature: https://features.opensuse.org/302628

1 0

[openFATE 301175] Update Messages Handling
by fate_noreply＠suse.de 04 Mar '09

04 Mar '09

Feature changed by: Stephan Kulow (coolo) Feature #301175, revision 29 Title: Update Messages Handling openSUSE-10.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2006-11-23 08:29:21 reject reason: not done in time... Priority Requester: Mandatory Projectmanager: Important openSUSE-10.3: Rejected by Stephan Kulow (coolo) reject date: 2007-08-07 11:17:55 reject reason: Solution needs to be integrated earlier in the release Priority Requester: Mandatory Projectmanager: Important openSUSE-11.2: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Requested by: Marcus Meissner (msmeissn) Description: During update of packages they could notify users about changes via email and/or the SuSEplugger (until 10.0, this is not anymore in 10.1). Most of these are outdated and not really usefull anymore and should be removed. The question is how to handle situations like bind where config files get rewritten and the user should be informed if this fails. In general, it is not possible to send emails from rpm install scripts. Most cases could be handled by the release notes but there are cases that cannot and we need a better solution to present this, especially since many people to not read the local emails. Relations: - update-messages functionality not implemented (novell/bugzilla/id: 4500930) https://bugzilla.novell.com/show_bug.cgi?id=4500930 Discussion: #2: Hendrik Vogelsang (hennevogel) (2006-09-05 14:52:12) Cleanup the messages and readd the features we lost with the removal of SUSEPlugger to zen-updater or whatever? #3: Duncan Mac-Vicar (dmacvicar) (2006-11-02 11:48:15) Current patches offer the message feature, so you could basically offer that package as a patch. If that is not sufficient, I propose something: We add a /var/spool/zypp-messages or something, and a binary which rpm spec call to inject messages. The zypp backend of the applet, check the spool in every check and use knotify to notifiy the user. I am only missing, where does the current rpm inject the messages to? #5: Edith Parzefall (emapedl) (2007-02-01 17:30:54) Andreas: any comments on the proposed solutions? #6: Duncan Mac-Vicar (dmacvicar) (2007-07-27 15:58:07) A proposal for normal packages: Create a dbus/dcop interface both applets implement. * create a /usr/sbin/update-messsage wrapper that allows rpms to send a message. * the wrapper sends a dcop/dbus message to the applets, which in turn show a passive popup? Other ideas? #7: Edith Parzefall (emapedl) (2007-08-06 13:50:22) Coolo, should we go ahead with the proposed solution and make a late feature admission request? #8: Stephan Kulow (coolo) (2007-08-06 19:18:17) (reply to #7) No, this requires documentation changes I'm not willing to accept. So I rather stay with the status quo ;( #9: Edith Parzefall (emapedl) (2007-08-07 11:05:55) Then please reject for 10.3. #10: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:19:05) Please reject for 11.0. All resources allocated with mandatory features already. #11: Duncan Mac-Vicar (dmacvicar) (2008-07-25 17:32:22) Please reject for SLE11/11.1. All resources allocated with mandatory features already. #12: Marcus Meissner (msmeissn) (2008-12-03 15:50:15) This was promised as "will be done" to the Maintenance Department. Mark it Mandatory for SP1. #13: Federico Lucifredi (flucifredi) (2009-01-23 15:39:07) (reply to #12) please note, any solution must not break "RPM only" compatibility - meaning these should be notification messages, not scripts used in any event to finish configuration or to cause "side effects" of any kind. #14: Federico Lucifredi (flucifredi) (2009-01-23 15:38:53) I disagree with the rationale that users don't read local mail. An admin should have that local mail forwarded, and I think we ought to facilitate configuring the forwarding even to other machines. I think that may have more success than popups... at least for Enterprise customers. For community use, sure, popups are helpful (as init 5 is more likely :-) + #15: Stephan Kulow (coolo) (2009-03-04 11:35:25) (reply to #14) + but who would send these mails if rpm is the only vehicle we can be + sure of. We don't want packages to send mails. -- openSUSE Feature: https://features.opensuse.org/301175

1 0

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

04 Mar '09

Feature changed by: Barbara Hudson (barbie_h) Feature #305296, revision 47 Title: Easy Way to Disable Beagle Completely During Installation openSUSE-11.2: Evaluation Priority Requester: 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) #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. -- openSUSE Feature: https://features.opensuse.org/305296

1 0