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
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
>>
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
>
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.
>>>
>>>
> 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/d
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 replacin
On 11/19/10 2:38 AM, Richard W.M. Jones wrote:
> C, Java and Python are not the only programming languages in the world.
In case you missed it, I was poking fun at C as well.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lis
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" 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
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
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
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?
>
> P
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" wrote:
> >>> On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote:
> > Most code is not performance critical.
> >>>
> >>> Much more code than yo
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
On Fri, Nov 19, 2010 at 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.
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
> > htt
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?
>
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 F
On Fri, Nov 19, 2010 at 12:12 AM, Jesse Keating 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.la
On 11/18/10 10:58 AM, Doug Ledford wrote:
> - "Richard W.M. Jones" 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
On Thu, Nov 18, 2010 at 01:58:02PM -0500, Doug Ledford wrote:
> - "Richard W.M. Jones" 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
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
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
>
On 11/17/2010 11:39 PM, Chris Adams wrote:
> Once upon a time, Matthew Garrett 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 ther
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
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 opti
- "Richard W.M. Jones" 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 makin
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
p
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
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?
* 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
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 han
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?) m
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 p
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
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 ss
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
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: noth
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()
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
On Thursday, 18 November 2010 at 00:13, 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 par
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 any
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 f
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 possi
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
On Wed, Nov 17, 2010 at 21:03:02 -0600,
Chris Adams 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.
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
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 s
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.
> [s
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.
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
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
> portab
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 ar
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.fe
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 f
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.
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
> libflashplay
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 d
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 go
On Thu, Nov 18, 2010 at 12:13 AM, 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 c
On Wed, Nov 17, 2010 at 05:20:57PM -0500, Peter Jones wrote:
> 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
>
On Wed, 2010-11-17 at 15:21 -0500, Josh Boyer wrote:
> On Wed, Nov 17, 2010 at 3:16 PM, Jon Masters 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
On Thu, Nov 18, 2010 at 04:27:48AM +, Matthew Garrett wrote:
> On Wed, Nov 17, 2010 at 11:26:31PM -0500, Benjamin Kreuter wrote:
> > On Wednesday 17 November 2010 22:59:54 Matthew Garrett wrote:
> > > Pretty sure it doesn't point them out. It just breaks them.
> >
> > Using memcpy on overlappi
On Wed, Nov 17, 2010 at 10:39:15PM -0600, Chris Adams wrote:
> 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
On Wednesday 17 November 2010 23:30:00 Chris Adams wrote:
> Once upon a time, Matthew Garrett said:
> > On Wed, Nov 17, 2010 at 09:03:02PM -0600, Chris Adams wrote:
> > > However, I still think that changing memcpy away from years of "it just
> > > works" is an ABI change that should not be taken
Once upon a time, Matthew Garrett 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'".
On Wednesday 17 November 2010 23:27:48 Matthew Garrett wrote:
> On Wed, Nov 17, 2010 at 11:26:31PM -0500, Benjamin Kreuter wrote:
> > On Wednesday 17 November 2010 22:59:54 Matthew Garrett wrote:
> > > Pretty sure it doesn't point them out. It just breaks them.
> >
> > Using memcpy on overlapping
Once upon a time, Sam Varshavchik said:
> POSIX specifies memcpy's ABI. Both the previous implementation and the
> current glibc implementation of memcpy() is compliant with the defined ABI.
No, POSIX doesn't specify ABIs, only APIs.
--
Chris Adams
Systems and Network Administrator - HiWAAY In
On Wed, Nov 17, 2010 at 10:30:00PM -0600, Chris Adams wrote:
> Once upon a time, Matthew Garrett said:
> > On Wed, Nov 17, 2010 at 09:03:02PM -0600, Chris Adams wrote:
> > > However, I still think that changing memcpy away from years of "it just
> > > works" is an ABI change that should not be tak
Once upon a time, Matthew Garrett said:
> On Wed, Nov 17, 2010 at 09:03:02PM -0600, Chris Adams 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 gl
On Wed, Nov 17, 2010 at 11:26:31PM -0500, Benjamin Kreuter wrote:
> On Wednesday 17 November 2010 22:59:54 Matthew Garrett wrote:
> > Pretty sure it doesn't point them out. It just breaks them.
>
> Using memcpy on overlapping ranges is undefined behavior; a crash is a pretty
> good way of pointin
On Wednesday 17 November 2010 22:59:54 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 hur
On Wednesday 17 November 2010 16:43:48 Magnus Glantz wrote:
> 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 act
Chris Adams writes:
Once upon a time, Sam Varshavchik said:
Fulko Hew writes:
>I know the definition for memcpy (on Linux) says don't use overlapping
>regions
No, the definition for memcpy on Linux does not say that. What says that is
the POSIX specification. Which is called a "standard".
On Wed, Nov 17, 2010 at 09:03:02PM -0600, Chris Adams 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
> often enough (and on la
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
> c
On Wed, Nov 17, 2010 at 10:03 PM, Chris Adams wrote:
[snip]
> shouldn't be done in a "stable" release of glibc. Is memcpy called
> often enough (and on large enough blocks) that this change makes a real
> performance difference (not just on a synthetic memcpy benchmark)?
Most code is not perform
On 11/17/2010 03:13 PM, 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 po
Once upon a time, Sam Varshavchik said:
> Fulko Hew writes:
> >I know the definition for memcpy (on Linux) says don't use overlapping
> >regions
>
> No, the definition for memcpy on Linux does not say that. What says that is
> the POSIX specification. Which is called a "standard".
Just for kick
On Thu, Nov 18, 2010 at 12:58:52AM +0100, Kevin Kofler wrote:
> Magnus Glantz wrote:
> > 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.
>
> Uh, for me it's much e
Fulko Hew writes:
I know the definition for memcpy (on Linux) says don't use overlapping
regions
No, the definition for memcpy on Linux does not say that. What says that is
the POSIX specification. Which is called a "standard".
pgpoYWFweeBxG.pgp
Description: PGP signature
--
devel mailin
On Wed, Nov 17, 2010 at 08:08:00PM -0500, Fulko Hew wrote:
> On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta wrote:
>
> > On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters
> > wrote:
> > > Did anyone upstream look into a compatibility environment variable that
> > > could be exported to change the dire
On Thu, Nov 18, 2010 at 1:08 AM, Fulko Hew wrote:
> I know the definition for memcpy (on Linux) says don't use overlapping
> regions but thats really a poor excuse for knowingly misbehaving when
> it could certainly prevented. Sorry, but using 'optimization' as a defense
> is just plain poor engi
On Wed, Nov 17, 2010 at 4:26 PM, Jeff Spaleta wrote:
> On Wed, Nov 17, 2010 at 8:16 PM, Jon Masters
> 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
Magnus Glantz wrote:
> 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.
Uh, for me it's much easier. I've run for years without ANY Flash plugin. At
the moment, I'm ru
Josh Boyer wrote:
> 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.
+1
We should not support proprietary software, ever.
Kevi
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 wr
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 opportun
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.
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
tempora
On Wed, Nov 17, 2010 at 17:36:54 -0500,
Adam Jackson wrote:
>
> 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
* 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,
Once upon a time, Gregory Maxwell 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 qui
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 wrote:
> > On 11/17/2010 03:41 PM, Bruno Wolff III wrote:
> > > On Wed, Nov 17, 2010 at 21:46:09 +0100, François
> > > Cami wrote:
> > >> IIRC broken proprietary drivers never stopped
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/1
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
On Wed, Nov 17, 2010 at 5:11 PM, 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?
>
> The BZ ref'd in this thread has linus' (simple) tests which dont
>
* 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.
>
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 cal
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 (
On Wed, Nov 17, 2010 at 16:33:59 -0500,
Peter Jones wrote:
> On 11/17/2010 03:41 PM, Bruno Wolff III wrote:
> > On Wed, Nov 17, 2010 at 21:46:09 +0100,
> >François Cami wrote:
> >>
> >> IIRC broken proprietary drivers never stopped us from shipping, but I
> >> could be wrong.
> >
> > Offic
1 - 100 of 136 matches
Mail list logo
