Re: Fixing the glibc adobe flash incompatibility
On 11/19/2010 09:41 PM, Matej Cepl wrote: Dne 19.11.2010 15:40, Przemek Klosowski napsal(a): - freeze glibc to avoid this bug ever (OK, maybe this one isn't serious) - fix glibc or the flash wrapper to accommodate the buggy clients - bug Adobe to fix the bug ASAP, do nothing in Fedora - refuse to use flash and work towards replacing it with Free software Install nspluginwrapper.x86_64, nspluginwrapper.i686, flash-plugin.i686, alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64, and alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 with all required dependencies (yes, there is a lot of them, how much are you willing to sacrifice for your YouTube?). Restart Firefox and enjoy! Aside from actually working, flash-plugin.i686 (http://www.adobe.com/go/getflash and select Yum repository) is actually updated so you don't fall so fast victim to all nastiness on the web. 64bit one is IIRC not-upgraded so you can get your browser hosed. That's a good answer. I wonder how we can make sure that people do this. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/22/2010 11:52 AM, Andrew Haley wrote: On 11/19/2010 09:41 PM, Matej Cepl wrote: Dne 19.11.2010 15:40, Przemek Klosowski napsal(a): - freeze glibc to avoid this bug ever (OK, maybe this one isn't serious) - fix glibc or the flash wrapper to accommodate the buggy clients - bug Adobe to fix the bug ASAP, do nothing in Fedora - refuse to use flash and work towards replacing it with Free software Install nspluginwrapper.x86_64, nspluginwrapper.i686, flash-plugin.i686, alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64, and alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 with all required dependencies (yes, there is a lot of them, how much are you willing to sacrifice for your YouTube?). Restart Firefox and enjoy! Aside from actually working, flash-plugin.i686 (http://www.adobe.com/go/getflash and select Yum repository) is actually updated so you don't fall so fast victim to all nastiness on the web. 64bit one is IIRC not-upgraded so you can get your browser hosed. That's a good answer. I wonder how we can make sure that people do this. Andrew. With guides on for example: * fedoraproject.org * fedorasolved.org * fedoraforum.org * fedora project members blogs As there are a lot of good reasons not to run the 64-bit version at the moment, that makes complete sense. //M -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Kevin Kofler wrote: Richard Zidlicky wrote: However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 The solution is not obvious at all: to include firmware, we need a license Ok, what about this one? Is this not obvious? https://bugzilla.redhat.com/show_bug.cgi?id=646157 After you spend half a day trying to understand why the fine installer is not making you the favor to do its work, you find the cause, you workaround the issue (by modifying py anaconda code _live_ and running a second instance on another tty), you open a bug and explain everything with all details, you just get a reply with a mildly disguised attempt to say that it is your fault. Then the bug is ignored (one months passed, 12 months left until self destruction). -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Hi, On 11/19/2010 10:39 AM, Richard Zidlicky wrote: On Thu, Nov 18, 2010 at 06:28:58PM +0100, Kevin Kofler wrote: thanks for looking at it. However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 The solution is not obvious at all: to include firmware, we need a license which allows that in the first place. The Ubuntu mailing list link you posted to one of your reports does not include any actual license, only talks about some license existing somewhere (which don't even tell us whether that license is acceptable for Fedora in the first place – we're quite tolerant when it comes to firmware licenses, but there are some restrictions which are unacceptable even for firmware, e.g. forbidding any commercial use). Plus, this is not actually an issue with Free Software, but with the lack of some proprietary firmware. it is against free in kernel drivers and the bugs have been rotting in bugzilla for the lifecycle of F11 and F12 without anyone even asking for info or anything. And finally, those bugs should be filed against linux-firmware, not kernel. I will file it with the correct package the next time when I confirm this is still an issue. Note, I've mailed Steven Toth (the owner of the website where the firmware is hosted) asking him if he can provide us with a clear license document for these firmwares. I've also indicated that it would be even better if the could get them into linux-firmware upstream. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Dne 18.11.2010 16:39, Magnus Glantz napsal(a): It's very important that Fedora doesn't rub upstream the wrong way, but (if it should come to that, or is already happening) is it worth having people change from Fedora to other distributions? People who switch from Fedora because of broken Flash are probably not people we should be most eager to retain. I mean, I don't want to be a dick, and I don't want to be nasty to people for their preferences, but some other distribution would probably serve them better. Besides, given frequent activity of their updates, wouldn't it be more profitable to bother Adobe to fix their program in one of its many many updates? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/19/2010 08:11 AM, Matej Cepl wrote: Dne 18.11.2010 16:39, Magnus Glantz napsal(a): It's very important that Fedora doesn't rub upstream the wrong way, but (if it should come to that, or is already happening) is it worth having people change from Fedora to other distributions? People who switch from Fedora because of broken Flash are probably not people we should be most eager to retain. Good grief man, that's almost everybody who watches the BBC on their computer! Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 06:28:58PM +0100, Kevin Kofler wrote: thanks for looking at it. However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 The solution is not obvious at all: to include firmware, we need a license which allows that in the first place. The Ubuntu mailing list link you posted to one of your reports does not include any actual license, only talks about some license existing somewhere (which don't even tell us whether that license is acceptable for Fedora in the first place – we're quite tolerant when it comes to firmware licenses, but there are some restrictions which are unacceptable even for firmware, e.g. forbidding any commercial use). Plus, this is not actually an issue with Free Software, but with the lack of some proprietary firmware. it is against free in kernel drivers and the bugs have been rotting in bugzilla for the lifecycle of F11 and F12 without anyone even asking for info or anything. And finally, those bugs should be filed against linux-firmware, not kernel. I will file it with the correct package the next time when I confirm this is still an issue. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Fri, Nov 19, 2010 at 10:39 AM, Richard Zidlicky r...@linux-m68k.org wrote: On Thu, Nov 18, 2010 at 06:28:58PM +0100, Kevin Kofler wrote: thanks for looking at it. However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 The solution is not obvious at all: to include firmware, we need a license which allows that in the first place. The Ubuntu mailing list link you posted to one of your reports does not include any actual license, only talks about some license existing somewhere (which don't even tell us whether that license is acceptable for Fedora in the first place – we're quite tolerant when it comes to firmware licenses, but there are some restrictions which are unacceptable even for firmware, e.g. forbidding any commercial use). Plus, this is not actually an issue with Free Software, but with the lack of some proprietary firmware. it is against free in kernel drivers and the bugs have been rotting in bugzilla for the lifecycle of F11 and F12 without anyone even asking for info or anything. Limited manpower ... there is no free vs. non free conspiracy here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Fri, Nov 19, 2010 at 09:34:08AM +, Andrew Haley wrote: On 11/19/2010 08:11 AM, Matej Cepl wrote: Dne 18.11.2010 16:39, Magnus Glantz napsal(a): It's very important that Fedora doesn't rub upstream the wrong way, but (if it should come to that, or is already happening) is it worth having people change from Fedora to other distributions? People who switch from Fedora because of broken Flash are probably not people we should be most eager to retain. Good grief man, that's almost everybody who watches the BBC on their computer! That's a good reason to badger the BBC to use open formats. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 09:12:51PM -0800, Jesse Keating wrote: On 11/18/10 10:58 AM, Doug Ledford wrote: - Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote: Most code is not performance critical. Much more code than you think is performance critical, particularly when I can throw up 1000 instances of it in the cloud. /me considers making snide comment about Python and how many extra power stations we've built because of it ... Allow me: if we all turned off python apps for one hour, we would save enough electricity to power the entire world for a year. That electricity would be eaten up on developer workstations for the increased code development, compile, and debug time it would take to write the same tools in other languages C, Java and Python are not the only programming languages in the world. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/19/2010 03:11 AM, Matej Cepl wrote: Dne 18.11.2010 16:39, Magnus Glantz napsal(a): It's very important that Fedora doesn't rub upstream the wrong way, but (if it should come to that, or is already happening) is it worth having people change from Fedora to other distributions? People who switch from Fedora because of broken Flash are probably not people we should be most eager to retain. I mean, I don't want to be a dick, and I don't want to be nasty to people for their preferences, but some other distribution would probably serve them better. People discussed several possible ways to proceed, proposing solutions ranging from complete accomodation to a principled stand against flash. - freeze glibc to avoid this bug ever (OK, maybe this one isn't serious) - fix glibc or the flash wrapper to accommodate the buggy clients - bug Adobe to fix the bug ASAP, do nothing in Fedora - refuse to use flash and work towards replacing it with Free software Sometimes those choices were discussed as if they were exclusive of each other--but in my opinion that should not be the case. It makes sense to me to pursue the last two on an appropriately longer time scale, while deploying a short-term fix. Someone pointed out that a negative consequence of the short term fix is that other instances of the same problem might stay unnoticed---but that should not be the case if the fix is in the flash wrapper. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Louis Lagendijk wrote: There is one more reason to revert the change imho: abusing memcpy this way is seen more often. Then those programs must be fixed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Fri, Nov 19, 2010 at 09:34:08AM +, Andrew Haley wrote: On 11/19/2010 08:11 AM, Matej Cepl wrote: People who switch from Fedora because of broken Flash are probably not people we should be most eager to retain. Good grief man, that's almost everybody who watches the BBC on their computer! get_iplayer is in rpmfusion; save yourself the grief of Flash (or that god-awful Air monstrosity). Ewan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, 2010-11-18 at 21:12 -0800, Jesse Keating wrote: On 11/18/10 10:58 AM, Doug Ledford wrote: - Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote: Most code is not performance critical. Much more code than you think is performance critical, particularly when I can throw up 1000 instances of it in the cloud. /me considers making snide comment about Python and how many extra power stations we've built because of it ... Allow me: if we all turned off python apps for one hour, we would save enough electricity to power the entire world for a year. That electricity would be eaten up on developer workstations for the increased code development, compile, and debug time it would take to write the same tools in other languages FWIW, I'm working right now on improving Python's performance: http://bugs.python.org/issue10399 ...well, I will be, once I stop checking mail :) Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Dne 19.11.2010 15:40, Przemek Klosowski napsal(a): - freeze glibc to avoid this bug ever (OK, maybe this one isn't serious) - fix glibc or the flash wrapper to accommodate the buggy clients - bug Adobe to fix the bug ASAP, do nothing in Fedora - refuse to use flash and work towards replacing it with Free software Install nspluginwrapper.x86_64, nspluginwrapper.i686, flash-plugin.i686, alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64, and alsa-plugins-pulseaudio-1.0.22-1.fc13.i686 with all required dependencies (yes, there is a lot of them, how much are you willing to sacrifice for your YouTube?). Restart Firefox and enjoy! Aside from actually working, flash-plugin.i686 (http://www.adobe.com/go/getflash and select Yum repository) is actually updated so you don't fall so fast victim to all nastiness on the web. 64bit one is IIRC not-upgraded so you can get your browser hosed. Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Good grief man, that's almost everybody who watches the BBC on their computer! Yeah - flash is a necessary evil which I'd rather do without but cannot (Australian ABC iView in my case!). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 10:06 AM, Benjamin Kreuter wrote: Oh I must have misunderstood, I thought it was crashing. Well, at least it is going to be obvious that something is wrong, unless you are watching a video of people trying to talk in a flooded submarine. Yes, *something* is wrong but going from there to a glibc change is not obvious to most people. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 12:48:01AM +0100, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: Dont we have an upstream mantra to uphold... Forward all Fedora users and otherwize that experience this to Adobe.. If we are going hack around this on our side where are we going to draw the line.. Are we planning to start hacking around every ill written code out there? +1 It is not our job to support Adobe's proprietary software, it is Adobe's job! This is a bug in Adobe's code and any complaints should be redirected to Adobe. Including workaround for bugs in proprietary software in our code is entirely the wrong thing to do. If you want software we or you can actually fix, use Free Software! (Maybe Flash being broken can actually get more interest into Gnash and Lightspark, which can only be a good thing! So it's actually GOOD if the proprietary Flash does not work. The fact that there's a free-as-in-beer proprietary implementation of something tends to be a big motivation remover for implementing a truly Free version, so having it break is actually good for our community. But we don't need to go out of our way to deliberately break it, we should just not work around its bugs!) +1 to this. Reading this thread, I was starting to forget that we're supposed to be about Free software ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 01:16:42PM -0800, John Reiser wrote: On 11/17/2010 12:41 PM, Emmanuel Seyman wrote: 2) Issues found in proprietary software cannot be fixed by anybody except the vendor False. In this particular case, it is possible to binary edit the plugin libflashplayer.so so that all its calls to memcpy become calls to memmove. The change is to copy the .st_name field from the symbol for memmove to the .st_name field of the symbol for memcpy, which creates another instance of memmove. With that one 32-bit change, then the player will work. Memmove can be a few percent slower than memcpy, but nobody will notice. Doesn't flash use some (in-)security scheme which involves checksumming its own binary? I vaguely thought that was how the BBC iPlayer DRM works ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 08:53:21AM +, Richard W.M. Jones wrote: On Wed, Nov 17, 2010 at 01:16:42PM -0800, John Reiser wrote: On 11/17/2010 12:41 PM, Emmanuel Seyman wrote: 2) Issues found in proprietary software cannot be fixed by anybody except the vendor False. In this particular case, it is possible to binary edit the plugin libflashplayer.so so that all its calls to memcpy become calls to memmove. The change is to copy the .st_name field from the symbol for memmove to the .st_name field of the symbol for memcpy, which creates another instance of memmove. With that one 32-bit change, then the player will work. Memmove can be a few percent slower than memcpy, but nobody will notice. Doesn't flash use some (in-)security scheme which involves checksumming its own binary? I vaguely thought that was how the BBC iPlayer DRM works ... I'm wrong here. The half-assed scheme that they use is to take a checksum of the SWF file: https://secure.wikimedia.org/wikipedia/en/wiki/Protected_Streaming#SWF_verification Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://et.redhat.com/~rjones/libguestfs/ See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 05:23 AM, Benjamin Kreuter wrote: Well, I am glad that Adobe is committing to fixing the problem, but it is not something I would rely on happening in all cases. I agree completely. On 11/18/2010 05:23 AM, Benjamin Kreuter wrote: The majority of Fedora users also need support for certain proprietary video and audio codecs, but we stick to our guns when it comes to that. But are you referring to something as wide spread as flash? If you are thinking about mp3, then I would guess that if for example mp3 stopped working on Fedora, we would be in the same seat as today - where a lot of people are putting resources into fixing something that they care about, but what is not open source. On 11/18/2010 05:23 AM, Benjamin Kreuter wrote: As long as there is no open source option for the majority of these users, why not QA Adobe Flash before a release? It's done easily and has great worth to the users. That would require us to ask people to agree to the proprietary Flash license, which is not, in my opinion, philosophically sound. It is one thing to accept bug reports regarding Flash and forward them to Adobe; it is another thing entirely to start asking Fedora contributors to test it out. As I said before, Adobe released proprietary software, so Adobe should take on the responsibility of performing QA on the platforms they want to support. If Adobe wants to target Fedora, then let them install rawhide and beta releases, and make sure that the Flash plugin is still working. -- Ben That is a good point. I feel that this discussion is now finding it's way home. Indeed I would never ask such a thing from anyone. But I would myself, in this specific case, not think twice before clicking on a yes I agree button, doing some basic testing to provide what I perceive is a necessary evil of today. The same, I guess, goes for any proprietary tech that a very large part of our user base could not imagine to live without. I'm not advocating the user of Adobe Flash or any other proprietary tech. I think it should be avoided if practically possible, but not to all and any costs. Linus Torvalds asks some questions in the BZ #638477-thread, to try and get people to reconsider that it is Adobe's problem: 1) QUOTE There is no advantage to being just difficult and saying that app does something that it shouldn't do, so who cares?. That's not going to help the _user_, is it? And what was the point of making a distro again? Was it to teach everybody a lesson, or was it to give the user a nice experience? END QUOTE 2) QUOTE And in the end, the big question is simple: Are you seriously going to do a Fedora-14 release with a known non-working flash player? END QUOTE For me, the answers to these questions is simple. 1) There is no point of just being difficult. The point of making a distro is giving the users a nice experience. The very majority of that experience is open source, there are a few exceptions, but people are working on that, in the mean time, let's try and make stuff work. 2) No.. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Dne 18.11.2010 05:27, Matthew Garrett napsal(a): Flash isn't crashing. It just sounds like it's trapped in a flooded submarine. Does it make any difference if you listen via speakers or via headphones? It does to me. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 10:16:25AM +0100, Magnus Glantz wrote: But are you referring to something as wide spread as flash? If you are thinking about mp3, then I would guess that if for example mp3 stopped working on Fedora, we would be in the same seat as today - where a lot of people are putting resources into fixing something that they care about, but what is not open source. MP3 is open source, and over here in the free world we can use it without problems. It's only because Red Hat is based in the same country as East Texas and has deep pockets and a connection with Fedora that there's a problem. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 11:42 PM, Kevin Kofler wrote: Andrew Haley wrote: So we should be able simply to patch glibc, right? Can't see any reason not to. Because it's NOT a bug in glibc, because what glibc does is CORRECT, because it actually POINTS OUT bugs in applications which are portability issues and can hurt future optimization opportunities (regardless of whether the current implementation really is faster than before or not) Which it isn't. and, most importantly, because it is NOT our job to work around bugs in proprietary software! How is any of that a reason not to patch glibc? Upside of patching: happy users. Downside: nothing. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Andrew Haley wrote: On 11/17/2010 11:42 PM, Kevin Kofler wrote: Because it's NOT a bug in glibc, because what glibc does is CORRECT, because it actually POINTS OUT bugs in applications which are portability issues and can hurt future optimization opportunities (regardless of whether the current implementation really is faster than before or not) Which it isn't. On some hardware, it is. It wouldn't have been committed if it hadn't been benchmarked to be a win. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Magnus Glantz wrote: 2) QUOTE And in the end, the big question is simple: Are you seriously going to do a Fedora-14 release with a known non-working flash player? END QUOTE For me, the answers to these questions is simple. [snip 1)] 2) No.. Newsflash: We already did. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 12:04 PM, Kevin Kofler wrote: Magnus Glantz wrote: 2) QUOTE And in the end, the big question is simple: Are you seriously going to do a Fedora-14 release with a known non-working flash player? END QUOTE For me, the answers to these questions is simple. [snip 1)] 2) No.. Newsflash: We already did. Kevin Kofler Hahaha, very clever of you Kevin. I did not read the question as Are you seriously going to release Fedora-14, but Are you seriously going to offer Fedora-14. Eg. It's Adobe's problem, we don't care if flash ever work again on Fedora. //M -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 09:44:31PM +0100, Magnus Glantz wrote: Because a large part of the Fedora users, uses the flash plugin from Adobe, and if it does not work, they will go off and find a distribution where it does work. With less people using Fedora, the project becomes less successful, as less people will be contributing. For me it's natural that we should care about the end-user experience of Fedora, even if that does include us caring about application outside of the Fedora owned repositories. after the experience that 90% of bugs filled against free software get closed after the lifetime of a distribution (my subjective estimate) without anyone ever looking at them I am wondering if we should abandon free software at all. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 01:39:50PM +0100, Richard Zidlicky wrote: after the experience that 90% of bugs filled against free software get closed after the lifetime of a distribution (my subjective estimate) without anyone ever looking at them I am wondering if we should abandon free software at all. Bug fixes don't happen by magic. If you feel that bugs are not being fixed fast enough, how about fixing some yourself? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 21:03:02 -0600, Chris Adams cmad...@hiwaay.net wrote: However, I still think that changing memcpy away from years of it just works is an ABI change that should not be taken lightly and IMHO shouldn't be done in a stable release of glibc. Is memcpy called It didn't just work. It happened to work in some cases and now it works in other cases instead, on some hardware. It probably would have been nice to have enabled some debugging mode during the F14 development period to actively find code misuing the function. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 08:28 AM, Bruno Wolff III wrote: On Wed, Nov 17, 2010 at 21:03:02 -0600, It probably would have been nice to have enabled some debugging mode during the F14 development period to actively find code misuing the function. Yes definitely - but for now, since, No-one has yet shown that the absolute time benefits of the change are large enough not to revert this for the time being. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Andrew Haley (a...@redhat.com) said: and, most importantly, because it is NOT our job to work around bugs in proprietary software! How is any of that a reason not to patch glibc? Upside of patching: happy users. Downside: nothing. Downside: cranky libc maintainers While possibly sometimes hard to distinguish from the default state, I'm guessing that the chance of getting glibc upstream to change their behavior for a closed-source app that broke semantics defined in KR is nil, and they're going to be pretty annoyed if we slam that in on top of them. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 10:14:58AM +, Andrew Haley wrote: On 11/17/2010 11:42 PM, Kevin Kofler wrote: How is any of that a reason not to patch glibc? Upside of patching: happy users. Downside: nothing. Downside: slower memcpy on sse4.2 machines Downside: if we workaround the Adobe flash bug by reverting that change for say half a year to let Adobe fix it in the months timeframe, another possible misuses of memcpy in other proprietary closed software won't be detected over that period of time, so then we'll revert it for another buggy program and so on forever Downside: this isn't ever going to be acceptable to upstream If you want to workaround the bug somewhere, do it temporarily in nspluginwrapper, or the browser upon detecting loading of libflashplugin.so. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 01:08:01PM +, Richard W.M. Jones wrote: On Thu, Nov 18, 2010 at 01:39:50PM +0100, Richard Zidlicky wrote: after the experience that 90% of bugs filled against free software get closed after the lifetime of a distribution (my subjective estimate) without anyone ever looking at them I am wondering if we should abandon free software at all. Bug fixes don't happen by magic. If you feel that bugs are not being fixed fast enough, how about fixing some yourself? done that when I had time to spare and always willing to waste some minutes playing with gdb. However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 08:58:03AM +0100, drago01 wrote: Sure can. 4.5 No Modification or Reverse Engineering. You shall not modify, adapt, translate or create derivative works based upon the Software. You shall not reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of the Software. [...] As long as you don't redistribute it you can do whatever you want with it. Depends on how binding that license is. It clearly says no modification, even for personal use. The risk of actual legal action is infinitesimally small, unless Adobe gets infected with space zombie madness plague. And it may not be legally binding. But their intent is clear. I say: we want people to follow the intent of the licenses we put on our software, let's follow the licenses they put on theirs, or else not use the software. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 09:28 AM, Jakub Jelinek wrote: Downside: nothing. Downside: slower memcpy on sse4.2 machines Do you know how much slower in absolute time is it? And is it (or would it be) visible (1/10's of seconds) or invisible (ms) in some typical (or atypical) apps that call memcpy() ... ? Thanks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 02:16 PM, Bill Nottingham wrote: Andrew Haley (a...@redhat.com) said: and, most importantly, because it is NOT our job to work around bugs in proprietary software! How is any of that a reason not to patch glibc? Upside of patching: happy users. Downside: nothing. Downside: cranky libc maintainers While possibly sometimes hard to distinguish from the default state, I'm guessing that the chance of getting glibc upstream to change their behavior for a closed-source app that broke semantics defined in KR is nil, and they're going to be pretty annoyed if we slam that in on top of them. I sympathize. This comes down to the core question that we keep banging against: who is Fedora for, its users or it maintainers? Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 10:09:56AM -0500, Genes MailLists wrote: On 11/18/2010 09:28 AM, Jakub Jelinek wrote: Downside: nothing. Downside: slower memcpy on sse4.2 machines Do you know how much slower in absolute time is it? And is it (or would it be) visible (1/10's of seconds) or invisible (ms) in some typical (or atypical) apps that call memcpy() ... ? Depends on the application, but certainly memcpy is one of the most performance critical functions, it is used basically everywhere and heavily so, I've very often see it very high in oprofile dumps etc. For memcpy both performance with very small length is criticial (most programs call memcpy with small lengths) but many apps also copy large memory blocks around (which is where SSE*, nontemporal stores etc. play role). E.g. the latter measurably shows up on SPEC2k/SPEC2k6. It is very sad that Intel/AMD just didn't make sure rep movsb isn't the fastest copying sequence on all of their CPUs, which underneath could do whatever magic based on size and src/dst alignment (e.g. for small length handle it in hw so it is as quick as possible, for larger sizes perhaps handle it in microcode) - rep movsb can be easily inlined and is quite short as well. But on many, especially recent, CPUs it performs very badly compared to these much larger SSE* optimized routines. If you want exact numbers, best ask Intel folks who wrote and tuned the SSE4.2 memcpy routine. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 03:28 PM, Jakub Jelinek wrote: On Thu, Nov 18, 2010 at 10:14:58AM +, Andrew Haley wrote: On 11/17/2010 11:42 PM, Kevin Kofler wrote: How is any of that a reason not to patch glibc? Upside of patching: happy users. Downside: nothing. Downside: slower memcpy on sse4.2 machines Downside: if we workaround the Adobe flash bug by reverting that change for say half a year to let Adobe fix it in the months timeframe, another possible misuses of memcpy in other proprietary closed software won't be detected over that period of time, so then we'll revert it for another buggy program and so on forever Downside: this isn't ever going to be acceptable to upstream If you want to workaround the bug somewhere, do it temporarily in nspluginwrapper, or the browser upon detecting loading of libflashplugin.so. Jakub So.. Upside of patching: happy users :-) Downside of patching: unhappy developers :-( It's very important that Fedora doesn't rub upstream the wrong way, but (if it should come to that, or is already happening) is it worth having people change from Fedora to other distributions? There are at least two known workarounds out there, but you need to be somewhat technical to 1) find them 2) implement them. I'm sure not just technically skilled people use Fedora, which is good, but if you do not understand a specific issue you are likely not as understanding when it comes to something not working. You don't understand and just want things to work. Ubuntu was mentioned in the first post of this thread. From my perspective Fedora and Ubuntu are opposites, where Fedora always does things the right way and Ubuntu will do whatever it takes to make people happy, even if that means the worlds ugliest upstream-hostile patch. I'm sure no-one wants to turn to the dark side of making-people-happy, but perhaps additional flexibility can be added to allow more people to use Fedora? Then when there's a real open source option to flash for all to enjoy that's the end of the story. The number of proprietary vendors of the world not using open standards AND with a technology that almost everyone use (like Adobe Flash) - are getting fewer and fewer, thanks to open standards and open source, so hopefully this is all a temporary issue. Larger user base or a solid open source platform? Are issues like this one really so fundamental so that we cannot have both? I bought into what Linus Torvalds wrote about development in the kernel. Quote ( https://bugzilla.redhat.com/show_bug.cgi?id=638477#c38 ) So in the kernel we have a pretty strict no regressions rule, and that if people depend on interfaces we exported having side effects that weren't intentional, we try to fix things so that they still work unless there is a major reason not to. End Quote Is there really a major reason for Fedora not to try and fix this temporary? Happy users? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 04:39:40PM +0100, Magnus Glantz wrote: So.. Upside of patching: happy users :-) Downside of patching: unhappy developers :-( and unhappy users because their software runs slower, apparently you've (intentionally?) missed that. There is absolutely no reason to punish all sanely written apps for one badly written proprietary one. As I said earlier, if you can't live without the proprietary blob and for whatever reason can't just use the 32-bit one using nspluginwrapper (as 64-bit one is not in a yum repository using the 64-bit one is a security risk, because very few people will keep tracking new versions of it, downloading them as tarball and installing them), let's do the workarounds in nspluginwrapper or browser for libflashplayer.so only, not in glibc where it will affect all apps. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 06:13:51PM -0500, Matthew Miller wrote: On Wed, Nov 17, 2010 at 01:16:42PM -0800, John Reiser wrote: On 11/17/2010 12:41 PM, Emmanuel Seyman wrote: 2) Issues found in proprietary software cannot be fixed by anybody except the vendor False. In this particular case, it is possible to binary edit the plugin libflashplayer.so so that all its calls to memcpy become calls to memmove. Cannot legally. 4.5 No Modification or Reverse Engineering. You shall not modify, adapt, translate or create derivative works based upon the Software. You shall not reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of the Software. [...] so whoever debugged the problem did it illegaly? Hard to imagine how to debug such an issue without any kind of decompile, disassemble or reverse enginieer. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 04:47 PM, Jakub Jelinek wrote: On Thu, Nov 18, 2010 at 04:39:40PM +0100, Magnus Glantz wrote: So.. Upside of patching: happy users :-) Downside of patching: unhappy developers :-( and unhappy users because their software runs slower, apparently you've (intentionally?) missed that. There is absolutely no reason to punish all sanely written apps for one badly written proprietary one. As I said earlier, if you can't live without the proprietary blob and for whatever reason can't just use the 32-bit one using nspluginwrapper (as 64-bit one is not in a yum repository using the 64-bit one is a security risk, because very few people will keep tracking new versions of it, downloading them as tarball and installing them), let's do the workarounds in nspluginwrapper or browser for libflashplayer.so only, not in glibc where it will affect all apps. Jakub Absolutely, I expressed myself a bit unclear. I'm sorry for that. I meant patching in general, doesn't have to be glibc. Just temporarily solving the issue, in general by patching something :-) //M -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 04:23:56PM +0100, Jakub Jelinek wrote: It is very sad that Intel/AMD just didn't make sure rep movsb isn't the fastest copying sequence on all of their CPUs, which underneath could do whatever magic based on size and src/dst alignment (e.g. for small length handle it in hw so it is as quick as possible, for larger sizes perhaps handle it in microcode) - rep movsb can be easily inlined and is quite short as well. But on many, especially recent, CPUs it performs very badly compared to these much larger SSE* optimized routines. If you want exact numbers, best ask Intel folks who wrote and tuned the SSE4.2 memcpy routine. I wonder if the Intel people who benchmarked memcpy throughput also benchmarked the increased context switch time that will happen now that the kernels lazy-fpu state saving is effectively disabled every time something calls memcpy. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
* Magnus Glantz [18/11/2010 17:07] : I meant patching in general, doesn't have to be glibc. Just temporarily solving the issue, in general by patching something :-) I'm unclear as why you feel the 'something' in question should be anything other than libflashplayer.so . Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 03:47 PM, Jakub Jelinek wrote: On Thu, Nov 18, 2010 at 04:39:40PM +0100, Magnus Glantz wrote: So.. Upside of patching: happy users :-) Downside of patching: unhappy developers :-( and unhappy users because their software runs slower, apparently you've (intentionally?) missed that. I think it's not so much missed as don't believe. Is there really some inherent reason why a backward copy runs faster than a forward one? There is absolutely no reason to punish all sanely written apps for one badly written proprietary one. Well, hold on, we don't know that it's only one. I expect that this broke [*] more apps, some in Fedora, and we've not found them yet. Andrew. [*] Yes, they were already broken. I know. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Richard Zidlicky wrote: However for some of the reports it is only the matter of someone looking at them as they contain the obvious solution to the problem. https://bugzilla.redhat.com/show_bug.cgi?id=595165 https://bugzilla.redhat.com/show_bug.cgi?id=582013 The solution is not obvious at all: to include firmware, we need a license which allows that in the first place. The Ubuntu mailing list link you posted to one of your reports does not include any actual license, only talks about some license existing somewhere (which don't even tell us whether that license is acceptable for Fedora in the first place – we're quite tolerant when it comes to firmware licenses, but there are some restrictions which are unacceptable even for firmware, e.g. forbidding any commercial use). Plus, this is not actually an issue with Free Software, but with the lack of some proprietary firmware. And finally, those bugs should be filed against linux-firmware, not kernel. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote: Most code is not performance critical. Much more code than you think is performance critical, particularly when I can throw up 1000 instances of it in the cloud. /me considers making snide comment about Python and how many extra power stations we've built because of it ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 10:59 PM, Matthew Garrett wrote: On Thu, Nov 18, 2010 at 12:42:56AM +0100, Kevin Kofler wrote: Because it's NOT a bug in glibc, because what glibc does is CORRECT, because it actually POINTS OUT bugs in applications which are portability issues and can hurt future optimization opportunities (regardless of whether the current implementation really is faster than before or not) and, most importantly, because it is NOT our job to work around bugs in proprietary software! Pretty sure it doesn't point them out. It just breaks them. Could you shout a little less? I'm already hungover and I haven't even been to bed yet. Obviously we should make glibc check the ranges and abort() with a snarky note. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thursday, November 18, 2010, 2:06:38 PM, Peter Jones wrote: On 11/17/2010 10:59 PM, Matthew Garrett wrote: On Thu, Nov 18, 2010 at 12:42:56AM +0100, Kevin Kofler wrote: Because it's NOT a bug in glibc, because what glibc does is CORRECT, because it actually POINTS OUT bugs in applications which are portability issues and can hurt future optimization opportunities (regardless of whether the current implementation really is faster than before or not) and, most importantly, because it is NOT our job to work around bugs in proprietary software! I'm in 100% agreement with Kevin's position on this matter. I also avoid Flash on Linux (and run with NoScript to keep a lot of other crap at bay). I have a couple of XP machines that I can use if I really need Flash. The glibc certainly conforms to the memcpy standard definition, and did not break the ABI. Apps that are not coded to use memmove when required are broken-by-design. QED. Pretty sure it doesn't point them out. It just breaks them. Could you shout a little less? I'm already hungover and I haven't even been to bed yet. This is a very low level and standard function, with absolutely no way to issue messages. On some CISC platforms (like zSeries mainframe), memcpy results in the compiler emitting a single instruction in the right conditions (move length is a constant). Obviously we should make glibc check the ranges and abort() with a snarky note. Peter Not interested in that either. Those checks would significantly slow down all code. Not by a little, but by an enormous amount. Anything change at this point would be wasted effort - all to handle a few programs written by folks who _obviously_ never bothered to learn C programming correctly in the first place. C has come a long way since KR, but this restriction has been in place since day-1. Fedora's limited resources are much better directed towards finding ways to make bad programs fail louder and earlier in the development cycle. Oh yeah... Adobe isn't part of Fedora, and doesn't concern themselves with our schedules. Based on their response, they don't really seem all that concerned with their own schedule regarding this issue. C'est la vie. Al -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 11:39 PM, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: On Wed, Nov 17, 2010 at 10:30:00PM -0600, Chris Adams wrote: How is that relevant? If the behavior changes on only some architectures, then it is okay? If it's broken on non-x86 already then there haven't been years of 'it just works'. It doesn't change the fact that glibc changed behavior on some CPUs (which is also going to make tracking down memcpy bugs highly irritating, since the behavior will be different depending on the CPU). Any normal person writing code is going to write a memcpy that copies up, whether a simple C loop or optimized assembly, so I really doubt you'll find lots of architectures that are widely used in the Unix world where people use the memcpy routine in the standard C library that does something different. If you code it to copy up instead of down, then it just means you've opted to misbehave in the /other/ overlap case instead of this one. There's no winning to be had here. -- Peter When in doubt, debug-on-entry the function you least suspect has anything to do with something. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/2010 05:17 PM, Emmanuel Seyman wrote: * Magnus Glantz [18/11/2010 17:07] : I meant patching in general, doesn't have to be glibc. Just temporarily solving the issue, in general by patching something :-) I'm unclear as why you feel the 'something' in question should be anything other than libflashplayer.so . Emmanuel Check previous posts in this thread -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, 2010-11-17 at 17:11 -0500, Genes MailLists wrote: Lets also not forget that the motivation for changing memcpy was to get some speedup - has anyone seen evidence of any significant benefit of that glibc change? There is one more reason to revert the change imho: abusing memcpy this way is seen more often. I like the old adagium: be strict in what you send but be liberal in what you expect -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Thu, Nov 18, 2010 at 01:58:02PM -0500, Doug Ledford wrote: - Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote: Most code is not performance critical. Much more code than you think is performance critical, particularly when I can throw up 1000 instances of it in the cloud. /me considers making snide comment about Python and how many extra power stations we've built because of it ... Allow me: if we all turned off python apps for one hour, we would save enough electricity to power the entire world for a year. It's amusing we're slagging off python for performance on a thread about that svelte, blazing-fast technology called Flash. Martin pgpnOKrSPtoFO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/18/10 10:58 AM, Doug Ledford wrote: - Richard W.M. Jones rjo...@redhat.com wrote: On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote: Most code is not performance critical. Much more code than you think is performance critical, particularly when I can throw up 1000 instances of it in the cloud. /me considers making snide comment about Python and how many extra power stations we've built because of it ... Allow me: if we all turned off python apps for one hour, we would save enough electricity to power the entire world for a year. That electricity would be eaten up on developer workstations for the increased code development, compile, and debug time it would take to write the same tools in other languages /me ducks -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Fri, Nov 19, 2010 at 12:12 AM, Jesse Keating jkeat...@redhat.com wrote: That electricity would be eaten up on developer workstations... ...flaming endlessly on a topic where - the glibc patch is clear - the external workaround (which avoids changing glibc) is trivial and has been posted m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 17/11/10 08:57, Hans de Goede wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction. The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin. This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans Is someone talking to Adobe about this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 10:17 AM, nodata l...@nodata.co.uk wrote: On 17/11/10 08:57, Hans de Goede wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction. The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin. This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans Is someone talking to Adobe about this? Yes, see https://bugs.adobe.com/jira/browse/FP-5739 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, 17 Nov 2010 10:20:35 +0100, drago01 wrote: On Wed, Nov 17, 2010 at 10:17 AM, nodata l...@nodata.co.uk wrote: On 17/11/10 08:57, Hans de Goede wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 ... I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans Is someone talking to Adobe about this? Yes, see https://bugs.adobe.com/jira/browse/FP-5739 So this problem would not have been there in the first place had the Flash plugin just reuse some other MP3 decoding library (e.g. through Gstreamer) rather than rolling out their own, right? -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 17/11/10 10:20, drago01 wrote: On Wed, Nov 17, 2010 at 10:17 AM, nodatal...@nodata.co.uk wrote: On 17/11/10 08:57, Hans de Goede wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction. The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin. This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans Is someone talking to Adobe about this? Yes, see https://bugs.adobe.com/jira/browse/FP-5739 Adobe benefits from Flash in Linux. So it seems sensible to: 1. Get Adobe to commit to a fix soon WITH A $DATE 2. Agree to patch the change until $DATE 3. Adobe updates Flash, we revert the patch, everyone is happy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 11:36 AM, nodata wrote: On 17/11/10 10:20, drago01 wrote: On Wed, Nov 17, 2010 at 10:17 AM, nodatal...@nodata.co.uk wrote: On 17/11/10 08:57, Hans de Goede wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction. The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin. This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans Is someone talking to Adobe about this? Yes, see https://bugs.adobe.com/jira/browse/FP-5739 Adobe benefits from Flash in Linux. So it seems sensible to: 1. Get Adobe to commit to a fix soon WITH A $DATE 2. Agree to patch the change until $DATE 3. Adobe updates Flash, we revert the patch, everyone is happy I've e-mailed a with Shu Wang at Adobe (who is the assigned contact for this issue) about a date when they can have this fixed. You've got the e-mail thread regarding this below: On 11/17/2010 10:19 AM, Shu Wang wrote: Hi Magnus, Maybe months. Thanks. Best regards. Shu -Original Message- From: Magnus Glantz [mailto:the-mail-address-is-not-this-...@redhat.com] Sent: Wednesday, November 17, 2010 5:15 PM To: Shu Wang Subject: Re: FP-5739 Strange sound on mp3 flash website with Fedora 14 x86_64 Hi Shu, That's is great to hear. Would you guess it's a matter of days, weeks or months before this can get fixed? If it will take a long time for you to fix this, Fedora may need to look at some way to work around this bug. Best regards, Magnus On 11/17/2010 10:06 AM, Shu Wang wrote: Hi Magnus, Thanks very much for your information. Flash Player team is investigating on it. It is in progress. Thanks. Best regards, Shu -Original Message- From: Magnus Glantz [mailto:the-mail-address-is-not-this-...@redhat.com] Sent: Wednesday, November 17, 2010 4:47 PM To: Shu Wang Subject: FP-5739 Strange sound on mp3 flash website with Fedora 14 x86_64 Hello Shu, I humbly wonder if you may have a time estimate on fixing FP-5739. It is seriously is affecting the ability to listen to sounds played in Flash for the users of Fedora. The issue has been traced to Adobe Flash by maintainers of glibc at Red Hat, Linus Torvalds and others. You may read more about this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=638477 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 2:57 AM, Hans de Goede hdego...@redhat.com wrote: I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. Hardly; we could for example equally as well patch firefox to load flash with a compatibility wrapper. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 03:17 PM, Magnus Glantz wrote: On 11/17/2010 11:36 AM, nodata wrote: On 17/11/10 10:20, drago01 wrote: On Wed, Nov 17, 2010 at 10:17 AM, nodatal...@nodata.co.uk wrote: On 17/11/10 08:57, Hans de Goede wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. The problem has been analyzed and is known, as well as a fix for it, see: https://bugzilla.redhat.com/show_bug.cgi?id=638477 The problem still exists however. The glibc developers say that this is not a glibc bug, but a flash plugin bug. And technically they are 100% correct, and the adobe flash plugin is a buggy (no surprise there). To be specific the flash plugin is doing overlapping memcpy-s which is clearly not how memcpy is supposed to be used. But the way the flash plugin does overlapping memcpy's happens to work fine as long as one as the c library does the memcpy-s in forward direction. And the new memcpy implementation does the memcpy in backward direction. The glibc developers being technically 100% correct is not helping our end users in this case though. So we (The Fedora project) need to come up with a solution to help our end users, many of whom want to use the adobe flash plugin. This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Regards, Hans Is someone talking to Adobe about this? Yes, see https://bugs.adobe.com/jira/browse/FP-5739 Adobe benefits from Flash in Linux. So it seems sensible to: 1. Get Adobe to commit to a fix soon WITH A $DATE 2. Agree to patch the change until $DATE 3. Adobe updates Flash, we revert the patch, everyone is happy I've e-mailed a with Shu Wang at Adobe (who is the assigned contact for this issue) about a date when they can have this fixed. You've got the e-mail thread regarding this below: So we should be able simply to patch glibc, right? Can't see any reason not to. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Dont we have an upstream mantra to uphold... Forward all Fedora users and otherwize that experience this to Adobe.. If we are going hack around this on our side where are we going to draw the line.. Are we planning to start hacking around every ill written code out there? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, 2010-11-17 at 16:32 +, Jóhann B. Guðmundsson wrote: Dont we have an upstream mantra to uphold... Forward all Fedora users and otherwize that experience this to Adobe.. If we are going hack around this on our side where are we going to draw the line.. Are we planning to start hacking around every ill written code out there? Hopefully not; this is a particularly high-visibility issue. Looking at https://fedoraproject.org/wiki/Objectives and related pages, Fedora has to weigh the desire for things to just work for the envisioned user base against the desire not to do something technically inferior to accommodate non-free software. I'm happy to let FESCo decide this. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 04:46 PM, Matt McCutchen wrote: On Wed, 2010-11-17 at 16:32 +, Jóhann B. Guðmundsson wrote: Dont we have an upstream mantra to uphold... Forward all Fedora users and otherwize that experience this to Adobe.. If we are going hack around this on our side where are we going to draw the line.. Are we planning to start hacking around every ill written code out there? Hopefully not; this is a particularly high-visibility issue. Looking at https://fedoraproject.org/wiki/Objectives and related pages, Fedora has to weigh the desire for things to just work for the envisioned user base against the desire not to do something technically inferior to accommodate non-free software. I'm happy to let FESCo decide this. Yes. This is not a one size fits all problem, and doesn't need a one size fits all solution. Flash is important to our users. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Adobe fix on QA/QE: Fixing the glibc adobe flash incompatibility
Hi guys, I just got an e-mail from Adobe that: 1) They have a fix 2) The fix has been send to QA/QE They say that they cannot commit to any dates, but that they are taking the issue seriously. I told them that if they want volunteers trying out their fix, we can help. Cheers, Magnus Glantz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 08:57:20 +0100, Hans de Goede hdego...@redhat.com wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. I saw memcpy / memmove issues affecting squashfs-tools shortly before the F14 alpha. So we had some what of a heads up about the issue over three months ago. It is unfortunate that we didn't catch the flash issue during prerelease testing of F14. If this really is an important critera for releases, maybe we should be having QA testing that flash works. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff III br...@wolff.to wrote: On Wed, Nov 17, 2010 at 08:57:20 +0100, Hans de Goede hdego...@redhat.com wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. I saw memcpy / memmove issues affecting squashfs-tools shortly before the F14 alpha. So we had some what of a heads up about the issue over three months ago. It is unfortunate that we didn't catch the flash issue during prerelease testing of F14. If this really is an important critera for releases, maybe we should be having QA testing that flash works. I will be very, very, disappointed if that gets added as a criteria for a Fedora release. It would be no different than making sure the nvidia driver works, and we certainly shouldn't be doing that either. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote: This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Did anyone upstream look into a compatibility environment variable that could be exported to change the direction of the memcpy? Yes, it's a hack, but it would allow affected users to have an option. Alternatively, I agree that this is one case where a wrapper hack would also work for the flash plugin. I suspect, however, that other projects will be affected and so a generic solution would help. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 09:09 PM, Josh Boyer wrote: On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff IIIbr...@wolff.to wrote: On Wed, Nov 17, 2010 at 08:57:20 +0100, Hans de Goedehdego...@redhat.com wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. I saw memcpy / memmove issues affecting squashfs-tools shortly before the F14 alpha. So we had some what of a heads up about the issue over three months ago. It is unfortunate that we didn't catch the flash issue during prerelease testing of F14. If this really is an important critera for releases, maybe we should be having QA testing that flash works. I will be very, very, disappointed if that gets added as a criteria for a Fedora release. It would be no different than making sure the nvidia driver works, and we certainly shouldn't be doing that either. josh I can relate to that. I'm all for pure open source, but.. I really can't see why it would be a bad thing Fedora would do QA on a proprietary software that is very important for a majority of the Fedora users. If we'd have an open source flash player that almost everyone could run as a substitute, then it would be a different situation. I would say that is the case regarding Nvidia. Cheers, Magnus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 3:16 PM, Jon Masters jonat...@jonmasters.org wrote: On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote: This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Did anyone upstream look into a compatibility environment variable that could be exported to change the direction of the memcpy? Yes, it's a hack, but it would allow affected users to have an option. Alternatively, I agree that this is one case where a wrapper hack would also work for the flash plugin. I suspect, however, that other projects will be affected and so a generic solution would help. Other FOSS projects? That people can send patches to fix the broken use of memcpy to? Seems the generic solution is exactly that. If you're talking about closed source applications, then I'm confused because I thought Fedora, as a project, did not care. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: Fixing the glibc adobe flash incompatibility
From: jonat...@jonmasters.org To: devel@lists.fedoraproject.org Date: Wed, 17 Nov 2010 15:16:20 -0500 Subject: Re: Fixing the glibc adobe flash incompatibility CC: fedora-devel-l...@redhat.com On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote: This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Isn't only 64-bit preview release affected? from adobe's website...http://labs.adobe.com/technologies/flashplayer10/ We have made this preview available so that users can test existing content and new platforms for compatibility and stability. Because this is a preview version of Flash Player, we don’t expect it to be as stable as a final release version of Flash Player. Use caution when installing Flash Player Square on production machines. If they don't expect it to work properly why should we? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
* Magnus Glantz [17/11/2010 21:33] : I really can't see why it would be a bad thing Fedora would do QA on a proprietary software that is very important for a majority of the Fedora users. 1) Time spent doing QA on proprietary software is time that will not be spent doing QA on free software 2) Issues found in proprietary software cannot be fixed by anybody except the vendor Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 09:30 PM, Ugis Fedora wrote: From: jonat...@jonmasters.org To: devel@lists.fedoraproject.org Date: Wed, 17 Nov 2010 15:16:20 -0500 Subject: Re: Fixing the glibc adobe flash incompatibility CC: fedora-devel-l...@redhat.com On Wed, 2010-11-17 at 08:57 +0100, Hans de Goede wrote: This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring any further user intervention. I would also like to point out that if this were to happen in Ubuntu which we sometimes look at jealously for getting more attention / users then us, the glibc change would likely be reverted immediately, as that is the right thing to do from an end user pov. I've filed a ticket for FESCo to look into this, as I believe this makes us look really bad, and the glibc maintainers do not seem to be willing to fix it without some sort of intervention: https://fedorahosted.org/fesco/ticket/501 Isn't only 64-bit preview release affected? from adobe's website... http://labs.adobe.com/technologies/flashplayer10/ We have made this preview available so that users can test existing content and new platforms for compatibility and stability. Because this is a preview version of Flash Player, we don’t expect it to be as stable as a final release version of Flash Player. Use caution when installing Flash Player Square on production machines. If they don't expect it to work properly why should we? Because a large part of the Fedora users, uses the flash plugin from Adobe, and if it does not work, they will go off and find a distribution where it does work. With less people using Fedora, the project becomes less successful, as less people will be contributing. For me it's natural that we should care about the end-user experience of Fedora, even if that does include us caring about application outside of the Fedora owned repositories. Cheers, Magnus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 8:44 PM, Magnus Glantz m...@hacka.net wrote: For me it's natural that we should care about the end-user experience of Fedora, even if that does include us caring about application outside of the Fedora owned repositories. Just a thought - but for those users who use chrome/chromium as prime browser where flash is part of the deal - would they install Adobe flash as well? i.e. would they even notice if Adobe flash-plugin was not working? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 9:21 PM, Magnus Glantz m...@hacka.net wrote: On 11/17/2010 09:09 PM, Josh Boyer wrote: On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff IIIbr...@wolff.to wrote: On Wed, Nov 17, 2010 at 08:57:20 +0100, Hans de Goedehdego...@redhat.com wrote: For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. I saw memcpy / memmove issues affecting squashfs-tools shortly before the F14 alpha. So we had some what of a heads up about the issue over three months ago. It is unfortunate that we didn't catch the flash issue during prerelease testing of F14. If this really is an important critera for releases, maybe we should be having QA testing that flash works. I will be very, very, disappointed if that gets added as a criteria for a Fedora release. It would be no different than making sure the nvidia driver works, and we certainly shouldn't be doing that either. I can relate to that. I'm all for pure open source, but.. I really can't see why it would be a bad thing Fedora would do QA on a proprietary software that is very important for a majority of the Fedora users. If we'd have an open source flash player that almost everyone could run as a substitute, then it would be a different situation. I would say that is the case regarding Nvidia. IIRC broken proprietary drivers never stopped us from shipping, but I could be wrong. Furthermore, no proprietary software vendor supports Fedora timely and fixes for issues like this one take months (from their own estimate). So by making sure proprietary software works, we could break the First Foundation. I would also argue we would break the Freedom Foundation, because proprietary software may limit what Fedora can do. On the other hand, proprietary software-related bugs found before the release would probably receive some attention (and could be forwarded to the vendor accordingly), so anyone is free to test whatever they use and file bugs. I am not saying that we should refrain users from testing proprietary software - but we should not make it part of the release criteria. François -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 21:46:09 +0100, François Cami fdc-li...@fcami.net wrote: IIRC broken proprietary drivers never stopped us from shipping, but I could be wrong. Officially. Unofficially, it was probably a contributing factor. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 09:46 PM, François Cami wrote: On Wed, Nov 17, 2010 at 9:21 PM, Magnus Glantzm...@hacka.net wrote: On 11/17/2010 09:09 PM, Josh Boyer wrote: On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff IIIbr...@wolff.towrote: On Wed, Nov 17, 2010 at 08:57:20 +0100, Hans de Goedehdego...@redhat.comwrote: For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. I saw memcpy / memmove issues affecting squashfs-tools shortly before the F14 alpha. So we had some what of a heads up about the issue over three months ago. It is unfortunate that we didn't catch the flash issue during prerelease testing of F14. If this really is an important critera for releases, maybe we should be having QA testing that flash works. I will be very, very, disappointed if that gets added as a criteria for a Fedora release. It would be no different than making sure the nvidia driver works, and we certainly shouldn't be doing that either. I can relate to that. I'm all for pure open source, but.. I really can't see why it would be a bad thing Fedora would do QA on a proprietary software that is very important for a majority of the Fedora users. If we'd have an open source flash player that almost everyone could run as a substitute, then it would be a different situation. I would say that is the case regarding Nvidia. IIRC broken proprietary drivers never stopped us from shipping, but I could be wrong. Furthermore, no proprietary software vendor supports Fedora timely and fixes for issues like this one take months (from their own estimate). So by making sure proprietary software works, we could break the First Foundation. I would also argue we would break the Freedom Foundation, because proprietary software may limit what Fedora can do. On the other hand, proprietary software-related bugs found before the release would probably receive some attention (and could be forwarded to the vendor accordingly), so anyone is free to test whatever they use and file bugs. I am not saying that we should refrain users from testing proprietary software - but we should not make it part of the release criteria. François I'm not saying that a broken Adobe Flash would stop Fedora from shipping. But.. if we notice that it's broken, we can: 1) Notify Adobe about it, so they -can- provide a fix. If they do not know, they can't fix it.. The Adobe developers I e-mailed with did say that they took the issue seriously, they want it to work on Fedora, as I'm sure a lot people/companies would. 2) Create a work-around for the end-users (as has been done by several people in the BZ #638477-thread) There's nothing bad about that is it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 08:58 PM, Magnus Glantz wrote: But.. if we notice that it's broken, we can: 1) Notify Adobe about it, so they -can- provide a fix. If they do not know, they can't fix it.. The Adobe developers I e-mailed with did say that they took the issue seriously, they want it to work on Fedora, as I'm sure a lot people/companies would. 2) Create a work-around for the end-users (as has been done by several people in the BZ #638477-thread) There's nothing bad about that is it? 3. Spend that time working on open alternative and get rid of flash for good JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Jóhann B. Guðmundsson wrote: 3. Spend that time working on open alternative and get rid of flash for good Write a cross-platform IDE for HTML5-based technologies. Of course it would also require a fast Javascript JIT engine, which has been frowned upon[1], so I don't know if there is a make-everyone-happy solution. Someone will have to have their feelings hurt. [1] http://www.spinics.net/lists/fedora-devel/msg141194.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wednesday 17 November 2010 15:21:55 Magnus Glantz wrote: On 11/17/2010 09:09 PM, Josh Boyer wrote: On Wed, Nov 17, 2010 at 2:28 PM, Bruno Wolff IIIbr...@wolff.to wrote: On Wed, Nov 17, 2010 at 08:57:20 +0100, Hans de Goedehdego...@redhat.com wrote: Hi all, For those who do not know it yet, recent Fedora glibc updates include an optimized memcpy (which gets used on some processors) which breaks the 64 bit adobe flash plugin. I saw memcpy / memmove issues affecting squashfs-tools shortly before the F14 alpha. So we had some what of a heads up about the issue over three months ago. It is unfortunate that we didn't catch the flash issue during prerelease testing of F14. If this really is an important critera for releases, maybe we should be having QA testing that flash works. I will be very, very, disappointed if that gets added as a criteria for a Fedora release. It would be no different than making sure the nvidia driver works, and we certainly shouldn't be doing that either. josh I can relate to that. I'm all for pure open source, but.. I really can't see why it would be a bad thing Fedora would do QA on a proprietary software that is very important for a majority of the Fedora users. We do not want to wind up on Adobe's schedule -- the problem is on Adobe's end, not ours, and we cannot even send them a fix. The behavior of memcpy for overlapping ranges is not even defined, so there should be nothing stopping us from using a new implementation of memcpy. The fact that a lot of people use the Flash plugin makes it even more important for *Adobe* to fix what can only be described as a bug in Flash, which is the current reliance on undefined behavior. -- Ben -- Message sent on: Wed Nov 17 15:57:16 EST 2010 signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 10:02 PM, Jóhann B. Guðmundsson wrote: On 11/17/2010 08:58 PM, Magnus Glantz wrote: But.. if we notice that it's broken, we can: 1) Notify Adobe about it, so they -can- provide a fix. If they do not know, they can't fix it.. The Adobe developers I e-mailed with did say that they took the issue seriously, they want it to work on Fedora, as I'm sure a lot people/companies would. 2) Create a work-around for the end-users (as has been done by several people in the BZ #638477-thread) There's nothing bad about that is it? 3. Spend that time working on open alternative and get rid of flash for good JBG Absolutely. This does in a good way show the dangers of being dependent on a closed source piece of software, owned by a company that most probably won't fix something if it does not affect their business. But first things first. //M -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
2) Issues found in proprietary software cannot be fixed by anybody except
the vendor
False. In this particular case, it is possible to binary edit the plugin
libflashplayer.so so that all its calls to memcpy become calls to memmove.
The change is to copy the .st_name field from the symbol for memmove to the
.st_name field of the symbol for memcpy, which creates another instance
of memmove. With that one 32-bit change, then the player will work.
Memmove can be a few percent slower than memcpy, but nobody will notice.
If the plugin did not have a reference to memmove already, then on x86_64
an impostor can be created by introducing the name memmove\0 at
{DT_NULL}.d_un. This is a generic work-around for this particular
issue with memcpy on x86_64.
--
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wednesday 17 November 2010 15:58:28 Magnus Glantz wrote: I'm not saying that a broken Adobe Flash would stop Fedora from shipping. But.. if we notice that it's broken, we can: 1) Notify Adobe about it, so they -can- provide a fix. If they do not know, they can't fix it.. The Adobe developers I e-mailed with did say that they took the issue seriously, they want it to work on Fedora, as I'm sure a lot people/companies would. Sure, but they need some incentive. Like, Flash not working without a fix, and lots of people complaining about it. 2) Create a work-around for the end-users (as has been done by several people in the BZ #638477-thread) This pretty much erases whatever incentive Adobe might have to actually fix the bug. Instead of fixing their code, now what they can do is use some hack and not bother to update anything. It also reduces the pressure on Adobe to release the Flash plugin under a libre license, since it would basically amount to the community doing the work to fix the problem while the software is still under a proprietary license. In the grand scheme of things, this is a bug that Adobe could fix pretty quickly, if they feel like they have a good reason to do that. Why not put the burden on them? They release proprietary software, so they take on the responsibility of making sure it works on the platforms they target. -- Ben -- Message sent on: Wed Nov 17 16:10:53 EST 2010 signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters jonat...@jonmasters.org wrote: Did anyone upstream look into a compatibility environment variable that could be exported to change the direction of the memcpy? Yes, it's a hack, but it would allow affected users to have an option. Could we make use of that sort of environment variable feature more generally as a way to build environments that test for bad memcpy usage similar to this by flipflopping back and forth, even while we are writing code? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 02:41:15PM -0600, Bruno Wolff III wrote: On Wed, Nov 17, 2010 at 21:46:09 +0100, François Cami fdc-li...@fcami.net wrote: IIRC broken proprietary drivers never stopped us from shipping, but I could be wrong. Officially. Unofficially, it was probably a contributing factor. I believe that we've frequently shipped with a sufficiently new X that binary nvidia and radeon drivers fail to work. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 03:41 PM, Bruno Wolff III wrote: On Wed, Nov 17, 2010 at 21:46:09 +0100, François Camifdc-li...@fcami.net wrote: IIRC broken proprietary drivers never stopped us from shipping, but I could be wrong. Officially. Unofficially, it was probably a contributing factor. No, I don't think so. We've certainly shipped with code that broke any given one of these before. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 10:18 PM, Benjamin Kreuter wrote: 2) Create a work-around for the end-users (as has been done by several people in the BZ #638477-thread) This pretty much erases whatever incentive Adobe might have to actually fix the bug. Instead of fixing their code, now what they can do is use some hack and not bother to update anything. It also reduces the pressure on Adobe to release the Flash plugin under a libre license, since it would basically amount to the community doing the work to fix the problem while the software is still under a proprietary license. But what you describe did not happen just now. There was two separate work-arounds (one from Linus Torvalds, replacing memcpy with a custom version, using LD_PRELOAD, and one from Ray Strode, replacing the memcpy calls in the binary with memmove, using a script) but Adobe still notified me today that they are QA/QE:ing a fix. In the grand scheme of things, this is a bug that Adobe could fix pretty quickly, if they feel like they have a good reason to do that. Why not put the burden on them? They release proprietary software, so they take on the responsibility of making sure it works on the platforms they target. -- Ben Because Adobe is not the one that pretty quickly risks loosing users. Ignoring flash content on the web is not done as easy as you can change between two Linux distributions. As it is (I don't like it, probably no one here likes it) a majority of the Fedora users are dependent on Adobe Flash working in Fedora. If it does not work, then a lot of things they do daily, stops working. As long as there is no open source option for the majority of these users, why not QA Adobe Flash before a release? It's done easily and has great worth to the users. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 03:45 PM, mike cloaked wrote: Just a thought - but for those users who use chrome/chromium as prime browser where flash is part of the deal Flash is only bundled in Google's Chrome builds, not in the FOSS Chromium code. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Lets also not forget that the motivation for changing memcpy was to get some speedup - has anyone seen evidence of any significant benefit of that glibc change? The BZ ref'd in this thread has linus' (simple) tests which dont confirm any benefit of the change compared to his simpler version (which does not go backwards). So why make a change which only has downside and little to no upside? The pragmatic side of is pushing to revert the change in glibc rather than create workarounds for it ... at least for now and until there is clear evidence of significant benefit to offset the obvious downside. Which apps gain - and by how much in real world situations ? Sounds like Adobe will fix it eventually anyway and in the mean time all will be peaceful ... and we can read/contribute to other threads!! gene/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 17/11/10 22:16, John Reiser wrote:
On 11/17/2010 12:41 PM, Emmanuel Seyman wrote:
2) Issues found in proprietary software cannot be fixed by anybody except
the vendor
False. In this particular case, it is possible to binary edit the plugin
libflashplayer.so so that all its calls to memcpy become calls to memmove.
The change is to copy the .st_name field from the symbol for memmove to the
.st_name field of the symbol for memcpy, which creates another instance
of memmove. With that one 32-bit change, then the player will work.
Memmove can be a few percent slower than memcpy, but nobody will notice.
Editing binaries is a bad idea and also breaks the packaging guidelines.
rpm verification will also break. It sets a bad precedent.
If the plugin did not have a reference to memmove already, then on x86_64
an impostor can be created by introducing the name memmove\0 at
{DT_NULL}.d_un. This is a generic work-around for this particular
issue with memcpy on x86_64.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
* John Reiser [17/11/2010 22:30] : On 11/17/2010 12:41 PM, Emmanuel Seyman wrote: 2) Issues found in proprietary software cannot be fixed by anybody except the vendor False. In this particular case, FWIW, I was refering to the general case. it is possible to binary edit the plugin libflashplayer.so so that all its calls to memcpy become calls to memmove. With all due respects, this looks more like a hack than a fix. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 5:11 PM, Genes MailLists li...@sapience.com wrote: Lets also not forget that the motivation for changing memcpy was to get some speedup - has anyone seen evidence of any significant benefit of that glibc change? The BZ ref'd in this thread has linus' (simple) tests which dont confirm any benefit of the change compared to his simpler version (which does not go backwards). So why make a change which only has downside and little to no upside? [snip] The original testing that went with the GLIBC patches also showed no speedup on the hardware Linus uses, but it did show an impressive (perhaps too impressive) speedup on other hardware: http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278 But is it only me who worries that lots of people are running code exposed to the internet that has obviously never even been run under valgrind? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 05:11 PM, nodata wrote: On 17/11/10 22:16, John Reiser wrote: On 11/17/2010 12:41 PM, Emmanuel Seyman wrote: 2) Issues found in proprietary software cannot be fixed by anybody except the vendor False. In this particular case, it is possible to binary edit the plugin libflashplayer.so so that all its calls to memcpy become calls to memmove. The change is to copy the .st_name field from the symbol for memmove to the .st_name field of the symbol for memcpy, which creates another instance of memmove. With that one 32-bit change, then the player will work. Memmove can be a few percent slower than memcpy, but nobody will notice. Editing binaries is a bad idea and also breaks the packaging guidelines. rpm verification will also break. It sets a bad precedent. To be fair, we're not packaging flash in Fedora anyway. -- Peter Computers don't make errors. What they do, they do on purpose. -- Dale -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On 11/17/2010 05:20 PM, Gregory Maxwell wrote: The original testing that went with the GLIBC patches also showed no speedup on the hardware Linus uses, but it did show an impressive (perhaps too impressive) speedup on other hardware: http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278 Ok - but % speedups are just one metric - the absolute time is also important. If something went from 20 ms to 60 ms its a huge % percentage speedup but could well be irrelevant in real world app setting - so my question is not the % speedup on the function, but the observed speedup in application setting (flash for example). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, 2010-11-17 at 15:42 -0600, Bruno Wolff III wrote: On Wed, Nov 17, 2010 at 16:33:59 -0500, Peter Jones pjo...@redhat.com wrote: On 11/17/2010 03:41 PM, Bruno Wolff III wrote: On Wed, Nov 17, 2010 at 21:46:09 +0100, François Camifdc-li...@fcami.net wrote: IIRC broken proprietary drivers never stopped us from shipping, but I could be wrong. Officially. Unofficially, it was probably a contributing factor. No, I don't think so. We've certainly shipped with code that broke any given one of these before. I am refering to the case referred to here: http://lists.fedoraproject.org/pipermail/devel/2006-August/088541.html There was a lot of discussion and speculation about this at the time. That was about updating FC5 after it shipped. An OS that went gold on 20 May 2006, three months before the post you're referencing. We've never broken X server ABI in any Fedora release as far as I'm aware, for basically the same reason you don't bump sonames after release. That thread sure is a flashback though. Turns out the things I was saying four years ago, I still believe: http://lists.fedoraproject.org/pipermail/devel/2006-August/088641.html Breaking proprietary drivers has _never_ been a ship criteria while I've been in charge. Remember F9, when we shipped an xserver 1.5 snapshot before all the binary drivers were ported? I got a lot of shit for that, that was pretty sweet. Turns out you get criticized no matter what you do, even if you're unflinchingly consistent for five years. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Once upon a time, Gregory Maxwell gmaxw...@gmail.com said: But is it only me who worries that lots of people are running code exposed to the internet that has obviously never even been run under valgrind? Yeah, people are acting like Adobe Flash is the only program in the world to make this (unfortunately quite easy) mistake. ISTR some old configure scripts (the rn/trn/perl one maybe?) that actually checked memcpy's overlap behavior at compile time. Somebody else has already reported finding another program (in the Fedora distribution even) that suffered from the same problem. Yes, by standards, memcpy is free to explode the universe if you call it with overlapping source and destination. It doesn't mean it is the right thing to do, especially for a limited performance gain (and only on certain CPUs). Changing its behavior is an ABI change, even if an undocumented one. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
* Peter Jones [17/11/2010 23:31] : To be fair, we're not packaging flash in Fedora anyway. From the post that started this thread: This solution could be reverting the problem causing glibc change, or maybe changing it to do forward memcpy's while still using the new SSE instructions, or something more specific to the flash plugin, as long as it will automatically fix things with a yum upgrade without requiring ^^ any further user intervention. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
Benjamin Kreuter writes: In the grand scheme of things, this is a bug that Adobe could fix pretty quickly, if they feel like they have a good reason to do that. Why not put the burden on them? They are fixing it. There's no need to waste any more electrons on this. Linus's fix is a temporary workaround. They're on the record as stating that this will be fixed. pgpqehAPvNViR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fixing the glibc adobe flash incompatibility
On Wed, Nov 17, 2010 at 01:16:42PM -0800, John Reiser wrote: On 11/17/2010 12:41 PM, Emmanuel Seyman wrote: 2) Issues found in proprietary software cannot be fixed by anybody except the vendor False. In this particular case, it is possible to binary edit the plugin libflashplayer.so so that all its calls to memcpy become calls to memmove. Cannot legally. 4.5 No Modification or Reverse Engineering. You shall not modify, adapt, translate or create derivative works based upon the Software. You shall not reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of the Software. [...] -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
