October 2009 - openSUSE Features - openSUSE Mailing Lists

[openFATE 307984] Zeroconf LAN P2P assisted updating
by fate_noreply＠suse.de 08 Oct '09

08 Oct '09

Feature added by: Jason Newton (jenewton) Feature #307984, revision 1 Title: Zeroconf LAN P2P assisted updating openSUSE-11.3: Unconfirmed Priority Requester: Desirable Requested by: Jason Newton (jenewton) Description: Have several opensuse boxen that you need to update? Don't like the dent updating leaves in your quota or the sluggish behavior of your connection while your machines saturate it getting the same files over and over again? Just want the total job time to be reduced? Want to do this without a headache and enable those less technically inclined to reap the benefits as well? P2p automatic discovery over the local lan with cached packages (with a short ~ 1-3 day TTL) is the idea given that LAN bw is much cheaper/faster than WAN. Package hashes already take care of security problems and this should be an opt in feature the user is prompted with at install time (somewhere in the process) informing users that the option can reduce download times and bandwidth requirements in an openSUSE networked environment (as well as allowing users to help opensuse save on server side resources). The difference between here and local mirror repositories is that caching is done lazily (I actually don't know if suse's local repos are lazy - fetching package only when needed), the user merely sets a boolean preference at install time or anytime in yast, and that everything takes care of itself afterwards - ie things just work, but they work much faster. There should also be no repos added so if a laptoper goes to another network for whatever reason, he doens't get popups or other problems if his system refreshes the repo cache or if he decides he wants to continue an upgrad or start a new install. This obviously doesn't help the cases of only one oS computer of a particular version and has limited benefit (noarch only?) to mixed cpu arch envornments but on the bright side at least sha1 hashes as UUIDs make local-lookups easy. Cooperative caching should also be looked into to make sure the dogpile effect doesn't occur from multiple boxen trying for the same package at the same time. Also, I should mention the approach I see in my mind given a TTL/uuid based system cache system works nicely with users with different computers updating at slightly different times and through automated ways. Why again though? Show me numbers! Numbers eh... I'm in a house with 4 opensuse boxes (on factory so we get a big block of updates from time to time). Lets create a variable N so we see how things scale. Lets also define N=4 for my particular case of a 4 computer opensuse LAN. Lets also define the following: X as the number of packages an update brings. Et = expected time to download Ez = expected package size. Ei = expected time to install a package Now normally when I upgrade, I upgrade all my boxes at the same time, usually through word of mouth, my friends do so too - this includes the roommate who has another 2 oS computers. If all packages are downloaded at full WAN bandwidth rate, that's R/N rate at which each computer on the shared WAN link dls. *LAN is considered free So in the uncooperative case: How long will it take you to download your updates? N*Et*X units of time. How much time will be spent installing the applications to the system? X*Ei units of time. The total amount of WAN bandwidth used is N*X*Ez. Well anyway, the total time for each installation to complete is N*Et*X + X*Ei units of time. This sucks, we're redoing the downloads. Now lets see the local cooperative caching case: How long will it take you to download your updates? Et*X. How much time will be spent installing the applications to the system? X*Ei The total amount of WAN bandwidth used is X*Ez. The total time for each installation to complete is Et*X + X*Ei. Much better, no? No more of that N factor. Plugging in numbers (for my case)... Lets take an X for two cases, 300 packages, and the factory weekly norm of 1200. Note that I derive these all the way at the bottom of the page. These are simply to give a feel for the above models. Et = 11.66 seconds, expected time to download Ez = 7.6 MiB, expected package size. In my case I think Ei=Et = 11.66 seconds R then equals .65MiB/s (note that this is the bitrate at which you are able to dl packages from a suse repo, this is always <= the true amount of download you have). For the 1200 package case: Without cooperative caching: 4*11.66*1200 + 1200*11.66 ~ 19.5 hrs With cooperative caching: 11.66*1200 + 1200*11.66 ~ 7.8 hrs For the 300 package case: Without cooperative caching : 4*11.66*300 + 300*11.66 ~ 5 hrs With cooperative caching: 11.66*300 + 300*11.66 ~ 2hrs Efficiency over the naive alternative is defined as the ratio of time spent in the uncooperative case over the cooperative case: (N*Et*X+Ei*X)/(Et*X+Ei*X) for the number's I've given above, the efficiency is 250% and only 40% of the original time is required for the same tasks. So there you have it, great efficiency gains, users getting back to real work faster, suse working smoother, and novel saving some cash on bandwidth. **Here is a table of probabilities, expected download times for packages descritied into three different size ranges / classes. I've just noted this emphirically over time as I always run zypper by hand on a local terminal. small <3 MiB med = 5-20 MiB huge =20-200 MiB Et = Expected time of a package download, p = probability of a package size class Et(small)=1s, p(small )=most, lets say ~2/3 Et(med)=8s, p(med X)=quite a few, < p(small), so lets say ~ 1/3 Et(huge)=5 mins= 300s, p(huge)= 5 / 300, 20 / 1200 ~= 1.66/100 Et for any given package is then ~: 11.66 seconds Expected package size, Ez, is: p(small)*1.5+p(med)*12.5+p(huge)*110 = 7.6 MiB We can then say my expected R is Ez/Et = 7.6/11.6, or about .65 MiB/second. Pretty good estimations of R as despite having a 2MiB line, I drift between 400k and 2MiB for package upgrades alot, it really is either one or the other with the former occuring most of the time. ***Note I'm simply using class midpoint for the above. -- openSUSE Feature: https://features.opensuse.org/307984

1 0

[openFATE 301175] Update Messages Handling
by fate_noreply＠suse.de 08 Oct '09

08 Oct '09

Feature changed by: Christoph Thiel (cthiel1) Feature #301175, revision 41 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: Rejected by Christoph Thiel (cthiel1) - reject date: 2009-04-21 15:36:05 - reject reason: No resources for 11.2 -- moving to 11.3. + openSUSE-11.2: Done Priority Requester: Mandatory - openSUSE-11.3: New - Priority - Requester: Mandatory + Projectmanager: Important 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: 450093) https://bugzilla.novell.com/show_bug.cgi?id=450093 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. #16: Michael Andres (mlandres) (2009-09-23 17:18:17) That's the zypp.conf option I'd like to introduce for this feature: ## ## Command to be invoked to send update messages. ## ## Packages may leave an update message file in {update.messagesdir}. ## At the end of each commit, zypp collects those messages and may send ## a notification to the user. ## ## zypp will prepare the update messages according to the selected ## content format and pipe the content to the command. ## ## Format: ## single - For each update message invoke the command and send ## the message. ## none - For each update message invoke the command but don't ## use a pipe to send any data. You probably want to pass ## the message file on the commandline using %P (see ## Substitutions). ## digest - Single invocation of the command, sending the path ## names of all update message. One per line. ## bulk - Single invocation of the command, sending the ## concatenated content of all update messages, separated ## by Ctrl-L. ## ## Substitutions: ## %p - package identification (name-version-release.arch) ## %P - full path to the update message file ## ## Valid values: The value is specified as "format | command". ## An empty value will turn off any notification. ## ## Examples: single | mail -s 'Update message from %p' root ## none | my-send-script -f %P ## ## Default value: single | /usr/lib/zypp/notify-message -p %p ## # update.messages.notify = single | /usr/lib/zypp/notify-message -p %p #17: Michael Andres (mlandres) (2009-10-07 17:13:03) The libzypp part seems to be done with libzypp-6.18.0 (for openSUSE 11.2). The /usr/lib/zypp/notify-message script, which gets invoked per default, sends mail with subject [zypp-notify-message] packagename- version.arch to root. The feature can be configured/disabled in /etc/zypp.conf. The list of update message files is also returned via ZYppCommitResult, so zypper/UI could write a note, or even offer to display them if we want that too. And we could also think about sending the config file diffs we create via this feature. -- openSUSE Feature: https://features.opensuse.org/301175

1 0

[openFATE 301175] Update Messages Handling
by fate_noreply＠suse.de 07 Oct '09

07 Oct '09

Feature changed by: Michael Andres (mlandres) Feature #301175, revision 39 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: Rejected by Christoph Thiel (cthiel1) reject date: 2009-04-21 15:36:05 reject reason: No resources for 11.2 -- moving to 11.3. Priority Requester: Mandatory openSUSE-11.3: New 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: 450093) https://bugzilla.novell.com/show_bug.cgi?id=450093 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. #16: Michael Andres (mlandres) (2009-09-23 17:18:17) That's the zypp.conf option I'd like to introduce for this feature: ## ## Command to be invoked to send update messages. ## ## Packages may leave an update message file in {update.messagesdir}. ## At the end of each commit, zypp collects those messages and may send ## a notification to the user. ## ## zypp will prepare the update messages according to the selected ## content format and pipe the content to the command. ## ## Format: ## single - For each update message invoke the command and send ## the message. ## none - For each update message invoke the command but don't ## use a pipe to send any data. You probably want to pass ## the message file on the commandline using %P (see ## Substitutions). ## digest - Single invocation of the command, sending the path ## names of all update message. One per line. ## bulk - Single invocation of the command, sending the ## concatenated content of all update messages, separated ## by Ctrl-L. ## ## Substitutions: ## %p - package identification (name-version-release.arch) ## %P - full path to the update message file ## ## Valid values: The value is specified as "format | command". ## An empty value will turn off any notification. ## ## Examples: single | mail -s 'Update message from %p' root ## none | my-send-script -f %P ## ## Default value: single | /usr/lib/zypp/notify-message -p %p ## # update.messages.notify = single | /usr/lib/zypp/notify-message -p %p + #17: Michael Andres (mlandres) (2009-10-07 17:13:03) + The libzypp part seems to be done with libzypp-6.18.0 (for openSUSE + 11.2). The /usr/lib/zypp/notify-message script, which gets invoked per + default, sends mail with subject [zypp-notify-message] packagename- + version.arch to root. The feature can be configured/disabled in + /etc/zypp.conf. + The list of update message files is also returned via ZYppCommitResult, + so zypper/UI could write a note, or even offer to display them if we + want that too. And we could also think about sending the config file + diffs we create via this feature. -- openSUSE Feature: https://features.opensuse.org/301175

1 0

[openFATE 307848] Include testdisk utility
by fate_noreply＠suse.de 07 Oct '09

07 Oct '09

Feature added by: Glenn Doig (doiggl) Feature #307848, revision 1 Title: Include testdisk utility openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Glenn Doig (doiggl) Description: >From the website. http://www.cgsecurity.org/wiki/TestDisk TestDisk is OpenSource software and is licensed under the terms of the GNU Public License (GPL). TestDisk is a powerful free data recovery software! It was primarily designed to help recover lost partitions and/or make non-booting disks bootable again when these symptoms are caused by faulty software, certain types of viruses or human error (such as accidentally deleting a Partition Table). Partition table recovery using TestDisk is really easy. TestDisk can * Fix partition table, recover deleted partition * Recover FAT32 boot sector from its backup * Rebuild FAT12/FAT16/FAT32 boot sector * Fix FAT tables * Rebuild NTFS boot sector * Recover NTFS boot sector from its backup * Fix MFT using MFT mirror * Locate ext2/ext3 Backup SuperBlock * Undelete files from FAT, NTFS and ext2 filesystem * Copy files from deleted FAT, NTFS and ext2/ext3 partitions. TestDisk has features for both novices and experts. For those who know little or nothing about data recovery techniques, TestDisk can be used to collect detailed information about a non-booting drive which can then be sent to a tech for further analysis. Those more familiar with such procedures should find TestDisk a handy tool in performing onsite recovery. other info: Download: http://www.cgsecurity.org/wiki/TestDisk_Download GPL: http://www.gnu.org/licenses/gpl.html Tutorial: http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step Thank you Glenn -- openSUSE Feature: https://features.opensuse.org/307848

1 1

[openFATE 305885] Handle the metadata "dirty" bit when an ISW array contains the root file system
by fate_noreply＠suse.de 07 Oct '09

07 Oct '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305885, revision 14 Title: Handle the metadata "dirty" bit when an ISW array contains the root file system - openSUSE-11.2: Evaluation + openSUSE-11.2: Candidate Priority Requester: Important Projectmanager: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Shutdown scripts need to wait until all the MDRAID arrays are marked clean: The dirty bit dictates whether an array needs to be resynced. The OS must block writes to the array until the dirty bit is set, and it should allow for the bit to be cleared as a part of the system shutdown process. For rootfs-raid the metadata handler will need to be started in the early userspace environment as even mounting the root- filesystem read-only may cause writes to be issued due to journal recovery. This involves including mdmon in the initrd and and using the "--switch-root" option to switch the monitor to the final rootfs environment. At shutdown the OS must allow for the metadata handler to stay running across the "mark root-filesystem readonly" event, i.e. it must be excluded from the general killall events. Once all filesystems are readonly a call to "mdadm --wait-clean --scan" will quiesce all writes and clear the metadata dirty bit. Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers Discussion: #4: Thorsten Kukuk (kukuk) (2009-10-07 10:04:05) Something for boot.md... -- openSUSE Feature: https://features.opensuse.org/305885

1 0

[openFATE 305885] Handle the metadata "dirty" bit when an ISW array contains the root file system
by fate_noreply＠suse.de 07 Oct '09

07 Oct '09

Feature changed by: Thorsten Kukuk (kukuk) Feature #305885, revision 13 Title: Handle the metadata "dirty" bit when an ISW array contains the root file system openSUSE-11.2: Evaluation Priority Requester: Important Projectmanager: Important Requested by: Marc Ruehrschneck (macrue) Partner organization: openSUSE.org Description: Shutdown scripts need to wait until all the MDRAID arrays are marked clean: The dirty bit dictates whether an array needs to be resynced. The OS must block writes to the array until the dirty bit is set, and it should allow for the bit to be cleared as a part of the system shutdown process. For rootfs-raid the metadata handler will need to be started in the early userspace environment as even mounting the root- filesystem read-only may cause writes to be issued due to journal recovery. This involves including mdmon in the initrd and and using the "--switch-root" option to switch the monitor to the final rootfs environment. At shutdown the OS must allow for the metadata handler to stay running across the "mark root-filesystem readonly" event, i.e. it must be excluded from the general killall events. Once all filesystems are readonly a call to "mdadm --wait-clean --scan" will quiesce all writes and clear the metadata dirty bit. Business case (Partner benefit): openSUSE.org: Enable feature parity with the Windows IMSM stack for Linux customers + Discussion: + #4: Thorsten Kukuk (kukuk) (2009-10-07 10:04:05) + Something for boot.md... -- openSUSE Feature: https://features.opensuse.org/305885

1 0

[openFATE 307913] Improved installation server setup
by fate_noreply＠suse.de 06 Oct '09

06 Oct '09

Feature added by: Birger Kollstrand (MrKane) Feature #307913, revision 1 Title: Improved installation server setup openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Birger Kollstrand (mrkane) Description: There is currently an Yast "Installation Server" module that makes an ftp/Http install service availabel. It lacks the possibility to set up a network boot environment which probably is a key element for most users of a network install server. As Yast already have an atftp server setup, my suggestion is that this can be called from the Installation server to facilitate a smooth installation server setup. This would really hel also in testin openSUSE as it is easy to have multiple instances ready to install. I use this heavily now when testing multiple machines on openSUSE. I can test a release and easily return to latest stable setup for my family to use. -- openSUSE Feature: https://features.opensuse.org/307913

1 0

[openFATE 307912] Solve bug Bug 544191 - Yast Installtion server can be started in multiple inst.
by fate_noreply＠suse.de 06 Oct '09

06 Oct '09

Feature added by: Birger Kollstrand (MrKane) Feature #307912, revision 1 Title: Solve bug Bug 544191 - Yast Installtion server can be started in multiple inst. openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: Birger Kollstrand (mrkane) Description: When setting up MS8 for testing I use the Installation server. To be smart I opened two instances to ready both 32 and 64 bit at the same time. That worked, both are copied to the correct directory at /srv/install/. The problem is that when I now start the "Installation Server" again it only shows one of the builds. I guess the problem is that it saves the configuration at program exit and the one that is closed last "wins". As I see it, either the Installation Server should not accept being started in multiple instances or it should lock the config file for writing so there is no race condition risk. -- openSUSE Feature: https://features.opensuse.org/307912

1 0

[openFATE 305888] Disable PulseAudio by default
by fate_noreply＠suse.de 06 Oct '09

06 Oct '09

Feature added by: Stephan Kulow (coolo) Feature #305888, revision 1, last change by Title: Disable PulseAudio by default openSUSE-11.2: Unconfirmed Priority Requester: Mandatory Requested by: Alberto Passalacqua (albertop) Description: PulseAudio has been one of the major sources of complaints and of problems for both the 11.0 and 11.1 release, with significant annoyances for openSUSE users, as reported on IRC and on local forums. As a consequence it is worth to consider the possibility to disable it by default on freshly installed systems for openSUSE 11.2. This enhancement request aims to collect the votes of those who agree with this. According to a discussion in IRC with coolo, if there are enough requests, this might be done. So, please, if you want to see PA disabled by default, in favour of a working audio system out of the box for many more users, just comment here. Relations: - Disable PulseAudio by default (novell/bugzilla/id: 478511) https://bugzilla.novell.com/show_bug.cgi?id=478511 Discussion: #1: Criss Peress (pieris) (2009-02-22 12:52:19) +1 #2: Jakub Rusinek (liviopl) (2009-02-22 13:31:25) You should have a look at what Lennart says on pulseaudio-discuss list [1], 'cause this might be important for openSUSE. 1| https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150… #3: Luigi Bettin (gigi888) (2009-02-22 13:55:58) +1 #4: Alberto Passalacqua (albertop) (2009-02-22 14:23:28) On comment #2: that has nothing to do with this discussion. Please keep it on topic! Fedora, cited in the link as the distribution doing something in the suggested direction, has similar complaints to those we had for openSUSE 11.0 and 11.1. Bye, A. #5: andrea florio (anubisg1) (2009-02-22 16:57:39) +1 for me #6: andrea martin (il_cjargnel) (2009-02-22 23:54:03) +1 for me (no pulse audio of default in 11.2) #7: Takashi Iwai (tiwai) (2009-02-23 01:07:08) Guys, the bugzilla is no place for voting or discussions, and it's no user forum. It's the place to report a bug and fix the bug. Please vote/discuss on ML at first. Then report back the result to bugzilla as the consensus of the whole community. Thanks. #8: Sven Burmeister (rabauke) (2009-02-23 04:28:01) I do not see any discussion here. Enabling pa by default can be regarded as a bug and not doing so as an enhancement people vote on. Bugzilla is about bugs/enhancements (not features) and voting. #9: Alberto Passalacqua (albertop) (2009-02-23 07:22:54) In answer to comment #7: This is an enhancement request, and bugzilla is exactly the place where this kind of discussion, to collect votes for it. Further discussion happened in the IRC anyway, and this bug report was opened as a consequence of it to collect user's feedback in a clean and organized manner, so that the decisionmaker can decide without reading an endless discussion in a mailing-list. As a consequence I reopen it. Regards, A. #10: Alberto Passalacqua (albertop) (2009-02-23 07:26:33) @Takashi Iwai: You might want to take part to the IRC life of openSUSE and discuss with us. Any suggestion/help is welcome! :-) #11: Takashi Iwai (tiwai) (2009-02-23 07:43:54) Could you give the exact voting result here? (And, no I'm not going to join IRC just for this purpose.) The vote must be done in an open way, and needs to take from a wide range of voters (users) without bias. Voting in bugzilla doesn't make sense for this kind of issue because the bugzilla (a specific bug entry) isn't the place where every user takes a look. It's the place where the people with the same problems take a look. Thus, of course, it will result in votes just by haters. Also, the endless discussion in ML is the result you have to respect. If there is no clear sign in the discussions in ML, it means there is no clear way to go, too. The rest is the political decision, and not about technical ones (remember KDE vs GNOME). So, please give more concrete technical issues rather than emotional +1/-1 votes. #12: Michael Skiba (mirrakor) (2009-02-23 10:03:31) > So, please give more concrete technical issues rather than emotional +1/-1 votes. There's nothing emotional about it. > It's the place where the people with the same problems take a look. Thus, of course, it will result in votes just by haters. Which is exactly the point - this isn't an open "opinion poll" it's about messuring how big the disturbances/problems (->bug) with PA really is, and if it affects enough people it's worth thinking about disabling it by default. #13: Alberto Passalacqua (albertop) (2009-02-23 10:07:28) Hi Takashi, the result of the voting, done with the usual procedure to vote bugs and requests, can be read at the top of the page. Currently this request has 27 votes. Each user can give a maximum of five votes. I probably wasn't clear in the initial post. We discussed to disable PA on IRC, and coolo suggested that is can be done if there is a sufficient number of requests. I don't know what "sufficient" means, but I thought it would have been easier to collect the votes in a quantitative manner here, using bugzilla features. I think it is important to notice that I'm not asking to remove PulseAudio, but to simply disable it by default, so that users don't meet the problems it is causing to them. PulseAudio can be already be disabled with one click in YaST, and the same can done to enable it again. My idea is that we should not activate it by default, because for 11.0 and 11.1 releases we had quite a lot of complaints due to it. Users who want it will be able to enable it with a simple click, but the new unexperienced user won't have to fight to make it work to listen to his music, which will result in a better image of the distribution that "works out of the box" and at the same time provides "the latest stack" for those who want/need it. The concrete technical issues are the following (I sum up what reported): - PA audio glitches often. - It gives troubles with Flash and other players, which capture the server, making other applications unable to work correctly. - It crashes, leaving you without controls on the audio system (Connection refused). - It doesn't work properly with some player and sound tool (someone reported issues with audacity, skype (I know it's skype problem but people wants to use it) gives problems too). Anyway, if you prefer, we can post the link on the ML to make it available to a wider public. I simply fear it will become noisy. I already spread it on IRC when I opened the request. P.S. My invitation on IRC was friendly. If you don't like it, there is no problem. But I'm serious when I say that suggestions are welcome. After all we are here to improve things, and not to fight between us :-) Regards, Alberto #14: Daniele Tombolini (kailed) (2009-02-23 11:47:18) +1 at least, under kde is unuseful. #15: Takashi Iwai (tiwai) (2009-02-23 12:11:37) OK, then I reassign this bug to coolo. Please reassign back after the decision is made. My position is neutral about this. I myself don't use PA, and I won't. But I do understand that some (other) people want PA as default, too. #16: alberto rossi (al9000) (2009-02-23 12:13:09) no to pulseaudio by default in opensuse 11.2 #17: Rajko Matovic (rajko_m) (2009-02-23 13:17:47) This is discussion about this enhancement request: http://lists.opensuse.org/opensuse-factory/2009-02/msg00208.html #18: Alberto Passalacqua (albertop) (2009-02-23 13:21:34) FYI, opened a discussion here so the interested people can say their opinion and we can collect more feedback: http://lists.opensuse.org/opensuse-factory/2009-02/msg00208.html A. #19: Vincent Untz (vuntz) (2009-02-23 14:47:36) Stupid question, if people think that the votes on this bug can be taken into account for the decision: how can people vote to keep pulseaudio? IMHO, bugzilla is not the right place for this -- this is not an enhancement request, this is a technical decision. Starting a thread on opensuse-factory was a good thing, though :-) #20: Andras Barna (sartek) (2009-02-23 19:59:13) for me alsa worked perfectly, so why change it.. so +1 #21: Jigish Gohil (cyberorg) (2009-02-23 22:45:22) Can we get kernel people look into the points raised in link posted on comment #2? https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-February/003150… Quoting relevant parts from that post for everyone's benefit here. "Apparently OpenSUSE ships a kernel (2.6.27.7-9-pae) that causes scheduling latencies of > 210ms. That is a lot. That is really really really a lot." "Fedora-kernels that easily give latencies of 5ms or so." "1) For fucks sakes: get your bloody kernels fixed. Enable preempt, set HZ to 1000. Get rid of low-quality drivers that block the CPU. Latencies of 210ms is *REALLY NOT NECESSARY*. 2) If you want to stick with your crap kernel, then either disable g-f entirely or adjust the #defines at the top of src/modules/alsa-sink.c and src/modules/alsa-source.c." So why do our kernel suck so bad? -- openSUSE Feature: https://features.opensuse.org/305888

1 28

[openFATE 305168] Default to relatime
by fate_noreply＠suse.de 06 Oct '09

06 Oct '09

Feature changed by: Karl Eichwalder (keichwa) Feature #305168, revision 30 Title: Default to relatime openSUSE-11.1: Rejected by Stanislav Visnovsky (visnov) reject date: 2008-09-10 10:20:17 reject reason: This is too late for openSUSE 11.1. Postponing. Priority Requester: Mandatory openSUSE-11.2: Done Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: At least for desktops, we should reduce the memory and I/O thrash caused by atime updates, by using relatime. Relations: - bugreport from community (novell/bugzilla/id: 398616) https://bugzilla.novell.com/show_bug.cgi?id=398616 - Offers 'noatime' when 'relatime' is clearly better (novell/bugzilla/id: 461829) https://bugzilla.novell.com/show_bug.cgi?id=461829 Documentation Impact: Needs to be documented in release notes Test Case: * cat /proc/mounts * all locally mounted filesystems should have "relatime" Discussion: #1: Robert Davies (robopensuse) (2009-01-16 15:52:09) Bug #461829 is not requesting breaking POSIX semantics by default! relatime should replace noatime option in the mount options part of partioner tool, especially now it has been improved to update atime on file access if it's older than 24 hours. Standards are important, and LRU file caches cannot be relied on if noatime usage is common, or if poor backup software touches atimes, when reading files. #2: Sven Burmeister (rabauke) (2009-01-23 01:09:47) 11.1 is out and 11.2 getting started. Did anyone hear of ubuntu suffering from using relatime by default? If not, it seems likely that there are little to none issues. #3: Stephan Kulow (coolo) (2009-05-08 16:51:21) Matthias, I would think the easiest solution is replacing the current checkbox "use noatime" with "use relatime" and make it default (possibly per product). atime is a major pain for many systems where powersave and co are affected. #4: Matthias Eckermann (mge1512) (2009-05-11 15:52:11) (reply to #3) I am not perfectly happy, as a system crash could invalide the "atime"s with "relatime" switched on; looking for supporting information though, it seems, the broader Linux community is in favour of "relatime" (with remarkable exceptions); thus I propose: * introduce "relatime" as an independend parameter * keep the "noatime" checkbox in YaST * make "relatime" default on SSDs automatically * introduce a generic switch in YaST "defaultrelatime", which can be switched on/off per product * make "relatime" default "on" for the openSUSE product Does that help? #5: Jan Kara (jankara) (2009-05-11 16:33:11) This is a bit separate to how it will all look in Yast but I wanted to point out that in current Linus's tree (going to be 2.6.30) is a patch which changes kernel's default to 'relatime'. So unless we change something, all filesystems on this or newer kernel are going to be mounted as relatime (you have to specify 'strictatime' mount option if you really wish to keep atime). #6: Stephan Kulow (coolo) (2009-05-12 10:36:27) (reply to #5) then we can leave everything as it is actually and the feature is Done once we switch to 2.6.30 #7: Jan Kara (jankara) (2009-05-12 13:08:05) (reply to #6) Yes, the original request will be fulfilled. But I believe it would be good to have a selection in partitioner tool like: "Access time behavior: <relatime|noatime|strictatime>" anyway and make 'relatime' default. Also it is a question how to behave on update - the safest would be to add 'strictatime' to filesystems that don't have any atime setting but realistically it is probably better to ask user whether he agrees to switching to relatime and default to "yes". #9: Stephan Kulow (coolo) (2009-05-12 13:45:51) (reply to #7) completely different feature IMO and way more complex (and definitely over the top of openSUSE 11.2) #10: Duncan Mac-Vicar (dmacvicar) (2009-05-12 14:00:25) (reply to #7) Do we really need this extra options really? Is there a good usecase for it? I don't want to bring something to implementation because it is "good", "cool" or "nice to have". #11: Jan Kara (jankara) (2009-05-12 15:50:33) (reply to #10) User can always edit /etc/fstab by hand so strictly speaking it's not necessary. About the usecase - there really are people who want 'strictatime' for various reasons (well, most often they are just afraid that something can break). From my POV that is enough for substituting that 'noatime' checkbox we have currently with the selection I suggested but I admit I'm not the one who'll have to implement it ;-). Regarding the update - silently changing the behavior of atime seems kind of rough to users to me. At least we should warn them (release notes?) that this is happening and that they can add 'strictatime' to /etc/fstab if they have problems with the change. #12: Andreas Jaeger (a_jaeger) (2009-06-09 15:36:15) (reply to #11) Let's add something to the release notes for those updating - and not do any other changes. #13: Arvin Schnell (aschnell) (2009-07-29 15:14:15) (reply to #12) With 2.6.30 in factory this isn't a feature for yast2-storage anymore. Andreas, if something should be added to the release notes please assigned to approptiate people. #14: Andreas Jaeger (a_jaeger) (2009-07-30 10:06:20) Karl, could you add something, please? Arvin, I agree. + #15: Karl Eichwalder (keichwa) (2009-10-06 13:10:18) (reply to #14) + I'll track it as bnc#544609 -- openSUSE Feature: https://features.opensuse.org/305168

1 0