High priority bug (IMHO) that needs to be fixed before Raring Release?
I upgraded to Raring the other day (from 12.04.2 LTS). Used Skype and noticed that all notification sounds sounds very distorted. Like a blown-out speaker. Googled it and found a solution in a askubuntu.com-question. http://askubuntu.com/questions/157891/skype-and-vlc-sounds-sizzle-distorted-bad And then on launchpad also, don't know about VLC because I haven't used it https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/751265 But, the main thing is, should users really have to do this, edit config files manually to get a common app as Skype to work? I have no clue what this tsched=0 does but it works for me.. Rgds//Thomas -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: High priority bug (IMHO) that needs to be fixed before Raring Release?
hi, On Fr, 2013-04-19 at 11:27 +0200, Thomas Novin wrote: I upgraded to Raring the other day (from 12.04.2 LTS). Used Skype and noticed that all notification sounds sounds very distorted. Like a blown-out speaker. Googled it and found a solution in a askubuntu.com-question. http://askubuntu.com/questions/157891/skype-and-vlc-sounds-sizzle-distorted-bad And then on launchpad also, don't know about VLC because I haven't used it https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/751265 But, the main thing is, should users really have to do this, edit config files manually to get a common app as Skype to work? I have no clue what this tsched=0 does but it works for me.. as daivid said in the bug, if tsched=0 fixes it for you it is a problem with the driver/hardware ... so you should file a specific bug for this. ciao oli signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Regarding manual partitioning on EFI systems
I recently installed 13.04 final beta(Gnome version) on my Efi enabled desktop. I selected manual partitioning option during installation. This being my first installation of an OS supporting Efi, I was not aware of the requirement of a separate EFI partition. The installer proceeded with the installation without indicating that there was any problem and the installation was otherwise correctly done except the Efi part. I discovered this problem only after when the system refused to boot. I then re-installed the whole system again after creating the EFI partition(I was not sure chroot would work). I am proposing that a warning system be included in the installer, which will warn users if the EFI partition is absent during installation. Thanks for listening, Biswarup Ray India -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: PIE on 64bit
Am 18.04.2013 20:25, schrieb John Moser: Meant to go to list On Apr 18, 2013 2:15 PM, John Moser john.r.mo...@gmail.com wrote: On Apr 18, 2013 2:07 PM, Insanity Bit colintre...@gmail.com wrote: On 64bit multiple services (pulseaudio, rsyslogd, many others) are shipping without Position Independent Code. On 32bit there is a potential performance hit for startup time... but there shouldn't be any performance hit (or negligible) on 64bit. There is a continuous performance hit of under 1% without -fomit-frame-pointer and under 6% with -fomit-frame-pointer on IA-32. The impact is statistically insignificant (i got 0.002% +/- 0.5%) on x86-64. The performance hit on IA-32 only applies to main executable code because library code is PIC already. This accounts for under 2% runtime, except in X where it used to be 5%. That makes the overall impact 2% of 6% or 0.12%--which is non-existent if your CPU is ever at less than 99.88% load because you would swiftly catch up. In other words: there is NO PERFORMANCE HIT for PIE in any non-laboratory, non-theoretical situation. (Theo de Raadt argued this with me once, using the term very expensive a lot. I built two identical Gentoo boxes and profiled them both extensively with oprofile. It is exactly a theoretical cost, and the performance concerns come from people who have no clue what the execution flow of modern software looks like) I'm tired to repeat that there *is* a performance penalty. Building the python interpreters with -fPIE results in about 15% slower benchmarks. Building GCC with -fPIE slows down the build times by 10-20%. So maybe you want to have a python interpreter with -fPIE, accepting this performance penalty, and gaining some security? But what else do you gain by building GCC with -fPIE besides forcing longer build times on developers? I don't think that -fPIE is ready to be enabled by default, but maybe we need to think about a better or easier way to enable it. However the current method using the hardening-wrapper seems to work fine. Matthias -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Regarding manual partitioning on EFI systems
On 19 April 2013 11:59, Biswarup Ray biswar...@gmail.com wrote: I recently installed 13.04 final beta(Gnome version) on my Efi enabled desktop. I selected manual partitioning option during installation. This being my first installation of an OS supporting Efi, I was not aware of the requirement of a separate EFI partition. The installer proceeded with the installation without indicating that there was any problem and the installation was otherwise correctly done except the Efi part. I discovered this problem only after when the system refused to boot. I then re-installed the whole system again after creating the EFI partition(I was not sure chroot would work). I am proposing that a warning system be included in the installer, which will warn users if the EFI partition is absent during installation. Which image have you used? i386 or amd64? Regards, Dmitrijs. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
MySQL 5.6
Just wondering when mysql server 5.6 will show up in the repos, not necessarily tied to the 'mysql-server' package itself but aside mysql-server-5.5 at least. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: PIE on 64bit
On 04/19/2013 08:25 AM, Matthias Klose wrote: Am 18.04.2013 20:25, schrieb John Moser: Meant to go to list On Apr 18, 2013 2:15 PM, John Moser john.r.mo...@gmail.com wrote: On Apr 18, 2013 2:07 PM, Insanity Bit colintre...@gmail.com wrote: On 64bit multiple services (pulseaudio, rsyslogd, many others) are shipping without Position Independent Code. On 32bit there is a potential performance hit for startup time... but there shouldn't be any performance hit (or negligible) on 64bit. There is a continuous performance hit of under 1% without -fomit-frame-pointer and under 6% with -fomit-frame-pointer on IA-32. The impact is statistically insignificant (i got 0.002% +/- 0.5%) on x86-64. The performance hit on IA-32 only applies to main executable code because library code is PIC already. This accounts for under 2% runtime, except in X where it used to be 5%. That makes the overall impact 2% of 6% or 0.12%--which is non-existent if your CPU is ever at less than 99.88% load because you would swiftly catch up. In other words: there is NO PERFORMANCE HIT for PIE in any non-laboratory, non-theoretical situation. (Theo de Raadt argued this with me once, using the term very expensive a lot. I built two identical Gentoo boxes and profiled them both extensively with oprofile. It is exactly a theoretical cost, and the performance concerns come from people who have no clue what the execution flow of modern software looks like) I'm tired to repeat that there *is* a performance penalty. Building the python interpreters with -fPIE results in about 15% slower benchmarks. Building GCC with -fPIE slows down the build times by 10-20%. So maybe you want to have a python interpreter with -fPIE, accepting this performance penalty, and gaining some security? But what else do you gain by building GCC with -fPIE besides forcing longer build times on developers? On x86-64 PIC is handled fast natively with additional registers, and non-PIC has a higher penalty to load and execute (because of more RAM usage and so occasional page faults to read from swap, since the main executable .text is not shared). What are your Python benchmarks? Loading/unloading a program? Most of Python's modules are *in* Python. Do you mean to indicate that building gcc with a gcc built with -fPIE is slower, or that building gcc with -fPIE is slower? The first is an actual legitimate test; the second is making gcc itself do more work during build. Who ran these benchmarks? What do they actually measure? I don't think that -fPIE is ready to be enabled by default, but maybe we need to think about a better or easier way to enable it. However the current method using the hardening-wrapper seems to work fine. Matthias -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
How to run quickly applications outside of quickly
Hi there, Created a test application using quickly. It works fine if I execute quickly run appname. However if I execute it directly from shell, app crashes. It's obvious that quickly is setting paths and/or environment variables. What do I need to do to run quickly generated application directly from shell prompt? Thanks, Niranjan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: How to run quickly applications outside of quickly
On Sat, Apr 20, 2013 at 3:54 AM, Niranjan Rao nhr...@gmail.com wrote: Hi there, Created a test application using quickly. It works fine if I execute quickly run appname. However if I execute it directly from shell, app crashes. It's obvious that quickly is setting paths and/or environment variables. What do I need to do to run quickly generated application directly from shell prompt? What error are you getting once you run python app in /bin? Regards, -- Bhavani Shankar Ubuntu Developer | www.ubuntu.com https://launchpad.net/~bhavi -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
