I feel dirty.
Feb. 29th, 2008 05:55 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kickahaThis thread over at ars has to be the most inane, pedantic[1], idiotic argument between internet pinheads I've seen in a long while: http://episteme.arstechnica.com/eve/forums/a/tpc/f/48409524/m/393004570931/p/1
You've got PeterB repeatedly asserting that Apple is killing Firefox performance on purpose. (They're not - FF migrated to Cocoa with FF3, and didn't know how to optimize the frame buffer performance. The trick WebKit is using is undocumented because it wasn't ready for a public API, and the specific use case that makes the need arise is rare enough that only WebKit and FF3's core have run into it, apparently...) His argument boils down to repeating himself until the other people give up.
You've got pope master repeatedly stating that the code in question is an application. (It's not, it's a system framework.) Repeated clarifications are responded to with "anything above the OS is an application", but of course he can't define what the OS is.
And of course you've got bash666 doing his normal content-free hit-and-runs just to stir things up.
Wow. Bunch of pinheads, all, and I'm willing to bet not one of them has done any professional programming, from their posts. If they have, I'd be stunned. I'd also have much pity for their employers. It's pretty damned simple: (and documented for god's sake...)
FF3 (team) didn't know to optimize a tweak after moving to new framework.
FF3 looked at WebKit (since it's open source), saw that they were doing some undocumented stuff under the hood, and said "Why can't we do that?"
FF3 finds (documented on Apple's website) tweak.
FF3 decides it won't work for their needs.
FF3 posts to internet, claiming Apple shenanigans.
WebKit (team - well, lead actually) says "We have that strictly for support legacy apps on 10.4, we want to get rid of it as soon as we can. Recommend you use documented tweak." (ie, it's a hack.)
FF3 says "We want to do it. Make it public."
WebKit says "Not our code, file a bug report and feature request with the team that handles it."
FF3 says "Will do, we'd like that feature."
Internet flamewar ensues among people who haven't a stake in it, or a flying fig of a clue, apparently.
To recap:
FF3 didn't know about an optimization, found workaround in WebKit code, jumped gun on claiming shenanigans.
WebKit responds with why there is a proper workaround, and states that 'shenanigans' are a hack for backwards compatibility only.
FF3 decides they still want to do hack (which I'm still not sure why - they aren't going to have the backwards compatibility issue that WebKit had...), requests publishing of relevant API bits.
WebKit points them to proper team, since it's not their code.
Somehow, this became "Apple killing Firefox performance on purpose JUST LIKE MICROSOFT!!!!"
Yes, because this is *exactly* like detecting when DR-DOS is running and hobbling performance on purpose.
I'm done, ars. Your forums are just no longer worth visiting, the noise levels have far exceeded the signal, thanks to a few idjits. This has been a growing trend recently, but today was the Obvious Brick of Doom(tm). Sensationalist crap I expect from /. these days, but... jeez.
What's really frickin' funny is that using undocumented APIs on MacOS X has a long and solid history. class-dump is a tool that inspects Mach-O libraries and produces Obj-C header files for them. Very slick, *very* useful for poking around in /System/Library/PrivateFrameworks/ (Wow, now that's sneaky - they even label it and everything. Evil.) The vast majority of the public Frameworks in OS X were once private - ever notice how Apple apps seem to have Neat New Nifty UI Features here and there, that then get propagated out to everywhere else the next big OS update? 10.5 brought the translucent HUD look to the public frameworks, for instance - was previously used in the Pro apps. The apps are the breeding grounds for new ideas, that then get hammered on and tested internally until they are ready for public consumption. This is normal. This also means that at any point in time, there are undocumented API calls throughout the system. This is also normal. What matters is what a company does with them.
Do they...
1) Keep them for themselves, never to make them public?
2) Look for non-manufacturer apps calling them, and change performance or behavior (in)appropriately?
3) Have two complete APIs, one for public (throttled) consumption, and one for internal (optimized) use?
No, no, and no. Every MacOS X developer worth his or her salt knows that the PrivateFrameworks are a treasure trove of goodies - but that they can change at any time, and can't be counted on. They are peeks into the next big revision, and give developers a leg up on what's coming down the pipe... as long as they're willing to risk that the pipe may suddenly change in unpredictable ways that may break everything they've done. Most Mac devs I know, when they want to play in that realm, write a simple wrapper. If the code is hoisted up to public status later, great. If not, and it breaks, fixes can be handled in the wrapper (hopefully.) If not, and it all goes to hell, there's a convenient spot to write a replacement.
This is normal, folks. Oy.
[1] I include you, georgmi! No kidding! Any one of them exceeds you... but the collection of them? Oy. (What is a herd of pedants? A necklace?[2])
[2] Yes, that's pedant bait. ;)
You've got PeterB repeatedly asserting that Apple is killing Firefox performance on purpose. (They're not - FF migrated to Cocoa with FF3, and didn't know how to optimize the frame buffer performance. The trick WebKit is using is undocumented because it wasn't ready for a public API, and the specific use case that makes the need arise is rare enough that only WebKit and FF3's core have run into it, apparently...) His argument boils down to repeating himself until the other people give up.
You've got pope master repeatedly stating that the code in question is an application. (It's not, it's a system framework.) Repeated clarifications are responded to with "anything above the OS is an application", but of course he can't define what the OS is.
And of course you've got bash666 doing his normal content-free hit-and-runs just to stir things up.
Wow. Bunch of pinheads, all, and I'm willing to bet not one of them has done any professional programming, from their posts. If they have, I'd be stunned. I'd also have much pity for their employers. It's pretty damned simple: (and documented for god's sake...)
FF3 (team) didn't know to optimize a tweak after moving to new framework.
FF3 looked at WebKit (since it's open source), saw that they were doing some undocumented stuff under the hood, and said "Why can't we do that?"
FF3 finds (documented on Apple's website) tweak.
FF3 decides it won't work for their needs.
FF3 posts to internet, claiming Apple shenanigans.
WebKit (team - well, lead actually) says "We have that strictly for support legacy apps on 10.4, we want to get rid of it as soon as we can. Recommend you use documented tweak." (ie, it's a hack.)
FF3 says "We want to do it. Make it public."
WebKit says "Not our code, file a bug report and feature request with the team that handles it."
FF3 says "Will do, we'd like that feature."
Internet flamewar ensues among people who haven't a stake in it, or a flying fig of a clue, apparently.
To recap:
FF3 didn't know about an optimization, found workaround in WebKit code, jumped gun on claiming shenanigans.
WebKit responds with why there is a proper workaround, and states that 'shenanigans' are a hack for backwards compatibility only.
FF3 decides they still want to do hack (which I'm still not sure why - they aren't going to have the backwards compatibility issue that WebKit had...), requests publishing of relevant API bits.
WebKit points them to proper team, since it's not their code.
Somehow, this became "Apple killing Firefox performance on purpose JUST LIKE MICROSOFT!!!!"
Yes, because this is *exactly* like detecting when DR-DOS is running and hobbling performance on purpose.
I'm done, ars. Your forums are just no longer worth visiting, the noise levels have far exceeded the signal, thanks to a few idjits. This has been a growing trend recently, but today was the Obvious Brick of Doom(tm). Sensationalist crap I expect from /. these days, but... jeez.
What's really frickin' funny is that using undocumented APIs on MacOS X has a long and solid history. class-dump is a tool that inspects Mach-O libraries and produces Obj-C header files for them. Very slick, *very* useful for poking around in /System/Library/PrivateFrameworks/ (Wow, now that's sneaky - they even label it and everything. Evil.) The vast majority of the public Frameworks in OS X were once private - ever notice how Apple apps seem to have Neat New Nifty UI Features here and there, that then get propagated out to everywhere else the next big OS update? 10.5 brought the translucent HUD look to the public frameworks, for instance - was previously used in the Pro apps. The apps are the breeding grounds for new ideas, that then get hammered on and tested internally until they are ready for public consumption. This is normal. This also means that at any point in time, there are undocumented API calls throughout the system. This is also normal. What matters is what a company does with them.
Do they...
1) Keep them for themselves, never to make them public?
2) Look for non-manufacturer apps calling them, and change performance or behavior (in)appropriately?
3) Have two complete APIs, one for public (throttled) consumption, and one for internal (optimized) use?
No, no, and no. Every MacOS X developer worth his or her salt knows that the PrivateFrameworks are a treasure trove of goodies - but that they can change at any time, and can't be counted on. They are peeks into the next big revision, and give developers a leg up on what's coming down the pipe... as long as they're willing to risk that the pipe may suddenly change in unpredictable ways that may break everything they've done. Most Mac devs I know, when they want to play in that realm, write a simple wrapper. If the code is hoisted up to public status later, great. If not, and it breaks, fixes can be handled in the wrapper (hopefully.) If not, and it all goes to hell, there's a convenient spot to write a replacement.
This is normal, folks. Oy.
[1] I include you, georgmi! No kidding! Any one of them exceeds you... but the collection of them? Oy. (What is a herd of pedants? A necklace?[2])
[2] Yes, that's pedant bait. ;)