Maybe I'm just misreading the charts/numbers but it looks like at the moment Google is contributing twice as much to WebKit as Apple is. That "nearly tied" claim seems to be for total number of commits (someone correct me if I'm wrong)- but Google's current rate of contribution is much higher. So the difference in the total number of commits between the two companies is likely to grow pretty quickly.
Overall, it's a pretty pointless statistic (number of commits). Someone could break one set of changes to 100 files into 100 different commits if they wanted to manipulate the numbers in their favour.
Really, what would be most interesting is who is contributing most to the overall architecture of WebKit these days (not just working in their own little area for their own needs). That's what everyone benefits from and what drives the project forward.
Now you're just trying to lessen Apple's involvement and achievement with WebKit. Apple spent years privately converting the KHTML fork over into the WebKit we finally saw released in Safari. To suggest this isn't Apple's creation and that they only get credit for the name and logo blows me away. Is Android's not Google's even though they bought Android from another company who used Linux for the kernel and whose codebase now consists of outside sources adding to it? I've never once heard you or MacRulez or DaHarder or anyone else say Android isn't Google's property so why is WebKit all of a sudden something Apple gets no credit for shaping? Seems disingenuous to me.
Wha?? How did you get that from my post? I never even commented on Webkit development, whose history is available to anyone who's interested in looking it up. You made the comment that Apple owned Webkit, and as evidence you offered the notice of their trademark. I replied with my understanding and followed up with a quote from Webkit.org, just as you did.
Now you're just trying to lessen Google's involvement and contributions to Webkit.
By the way, Android source code is not Google's property. It's open source. But I think they own the trademark to the name, just like Apple does with Webkit.
Really, the only thing which matters is the technologies/ideas which make up a project. A name is just a name and can change many times during the lifespan of a project (and it's forks). As can legal ownership as companies are bought, sold, go bankrupt, etc.
But yes, if it makes you happy, I'll also give Apple credit for providing the infrastructure to support the project. Though I believe that's the contentious point for the original KDE developers if you read the Wikipedia article: they really had to push Apple to provide this type of information (what bugs were being fixed by which patches). But I'm glad Apple finally set this up for the WebKit project in the end: many companies likely wouldn't bother unless they were legally forced to do so.
The only things which matters is whether corporate interests are aligned with open source. If they are then resources flow. When it does not you have a gimped dev team of two and a half men.
Webkit was an Apple fork refactored to meet Apple's needs and Apple goals and what could be released under BSD was done so rather than LGPL to make it corporate friendly for reuse (everything but webcore and javascriptcore). Back in the day I remember one of the original KDE devs that had moved to Webkit comment that calling Webkit a fork of KHTML was like calling a chicken a fork of an egg...ah open source pissing contests. If Theo had been involved it would have made it even more classic.
KHTML is about as significant as when it started...not very. I think Twitter rendering was nearly completely borked in KHTML/KJS last year sometime and no one noticed. Nobody tests against KHTML except maybe the KDE webmaster.
The only things which matters is whether corporate interests are aligned with open source. If they are then resources flow. When it does not you have a gimped dev team of two and a half men.
Webkit was an Apple fork refactored to meet Apple's needs and Apple goals and what could be released under BSD was done so rather than LGPL to make it corporate friendly for reuse (everything but webcore and javascriptcore). Back in the day I remember one of the original KDE devs that had moved to Webkit comment that calling Webkit a fork of KHTML was like calling a chicken a fork of an egg...ah open source pissing contests. If Theo had been involved it would have made it even more classic.
KHTML is about as significant as when it started...not very. I think Twitter rendering was nearly completely borked in KHTML/KJS last year sometime and no one noticed. Nobody tests against KHTML except maybe the KDE webmaster.
Indeed, this is the way of all things: something is only relevant if enough people pay attention to/care about it.
However, I still see a project and all of it's forks as a continuum of the same core technology. In this regard, you cannot say that Apple is solely responsible for WebKit. One day, Apple's influence on the industry could change (or it could morph into a different type of company which has no interest in WebKit). At which point, another Apple-like entity could devote resources to a new fork of the technology now known as WebKit, and the name "WebKit" would become as irrelevant as KHTML is today. A name is just a name.
Maybe I'm just misreading the charts/numbers but it looks like at the moment Google is contributing twice as much to WebKit as Apple is. That "nearly tied" claim seems to be for total number of commits (someone correct me if I'm wrong)- but Google's current rate of contribution is much higher. So the difference in the total number of commits between the two companies is likely to grow pretty quickly.
It's safe to say that a simple look at the number of commits isn't a very informative measure.
I would say Apple is in the driver's seat because it's their project. Other big contributors see the value of the central idea of the project (smart, sensible, fast, organized, predictable, standardized, open, un-borked, rendering engine and browser) and it fits the bill for them. The big dogs and a lot of small dogs agree — it makes sense for them, they like it, and they contribute, make fixes, and add things they want. As soon as it doesn't meet their needs, they can fork it and maybe others will follow. But no point in reinventing the wheel if it keeps getting better and better and keeps rolling so nicely.
Can everyone please stop quoting Wikipedia as a vetted source of information in these arguments?
There's nothing wrong with quoting Wikipedia (and it *is* "vetted.")
As with any writing, a quote is only as good as the person quoting it. People still have to evaluate sources, arguments, logic, truth, reliability, etc.
Funny too that webkit.org has safari's patented logo on there website as well:)
As an edit to this I have been looking back at some articles by arstechnica about the webkit fork of the khtml engine and found that the creator of khtml and others back in 2007 helped reincorporate khtml back into webkit and reverse some of the changes apple made to make developement easier and to get webkit's/khtml engine adopted back by kde. In an interview with Lars Knoll the creator of khtml he talks about apples involvement and how webkits fork is now coming back into a merger with khtml and eventually will be adopted as part of kde.
Also that the khtml community got apples webkit set up with full code disclosure by apple back to the community which was the reason for the big uproar with apples involvement to begin with.
There good reads if your interested circa 2007 on ars.
Apple.mail is a webkit product? Why does Apple.mail suck so much. It doesn't attach emails separately, it doesn't update very well (I'll get my iphone emails minutes before Apple.mail), and it does a poor job of handling wifi interruptions. It also creates stupid, meaningless attachments.
Apple.mail is a webkit product? Why does Apple.mail suck so much. It doesn't attach emails separately, it doesn't update very well (I'll get my iphone emails minutes before Apple.mail), and it does a poor job of handling wifi interruptions. It also creates stupid, meaningless attachments.
What blather. iPhone Mailis Apple Mail. The rest of this post can be read in the same context.
Can everyone please stop quoting Wikipedia as a vetted source of information in these arguments?
That particular Wikipedia article has links to mailing list archives which support what is written. I also happened to live through and follow the whole KHTML->WebKit fork (I was working on both Linux and Mac OS X at the time). And though I wasn't actually involved with the project, the Wikipedia article is accurate based on what I remember of it.
That particular Wikipedia article has links to mailing list archives which support what is written. I also happened to live through and follow the whole KHTML->WebKit fork (I was working on both Linux and Mac OS X at the time). And though I wasn't actually involved with the project, the Wikipedia article is accurate based on what I remember of it.
It's quite remarkable how many Wikipages are well cited. I find it an absolutely great jumping off point.
I don't think I've gone a day without Wikipedia as a resource in years. Sometimes the journey it takes as you click on links to other Wikipages will lead you to information that you had no idea existed.
That could mean no Flash or Silverlight needed for video streaming from larger providers. HTTP Live Streaming would work fine though. Apple's implementation doesn't support DRM but it says they can encrypt streams and restrict access to encryption keys. People will always be able to rip video from a stream anyway just like people can record TV shows.
That could mean no Flash or Silverlight needed for video streaming from larger providers. HTTP Live Streaming would work fine though. Apple's implementation doesn't support DRM but it says they can encrypt streams and restrict access to encryption keys. People will always be able to rip video from a stream anyway just like people can record TV shows.
1) I'm glad to see more uniformity on the internet but I would ideally like to see it happen with multiple browser engines.
2) I am more shocked Opera has 300 million users. I bet a good many of them are pissed by this. Hard to be elitist when you're using the same engine as everyone else.
3 The encryption seems to work well. I'v tried to find the source files for some sites and unable to find them. They usually pop up in under the Other folder in Web Inspector. For instance, if you change your UA to iPad, open up Web Inspector, then open up a clip on Comedy Central's The Daily Show the ad will be in MP4 but the video won't be there, at least not as a standard file. I haven't been able to figure out how they do it. I assume that don't think it's secure enough that they only allow clips and not full episodes to be watched unless you have Flash installed.
I'm glad to see more uniformity on the internet but I would ideally like to see it happen with multiple browser engines.
That was how it was supposed to work orginally but it's too slow trying to get everyone on the same path (yes Microsoft, everyone's looking at you). You can see from the article, they suggest the Opera developers were tired of having to modify things to keep up with sites being designed for Chrome and Safari - likely on the mobile side. For the same reasons that Android makes it easier for phone manufacturers to put out a solid OS, webkit makes it easier for browser developers to have a solid, compatible engine without the constant struggle to add compatibility.
While competition can help push new features and standards, given the scale and richness the web has reached, compatibility is more important.
I am more shocked Opera has 300 million users. I bet a good many of them are pissed by this. Hard to be elitist when you're using the same engine as everyone else.
There's still room to be unique while using the same engine just like video games can be different with the same core engine. Chrome is different from Safari for example. Here is a preview of Opera's Ice web browser:
IThe encryption seems to work well. I'v tried to find the source files for some sites and unable to find them. They usually pop up in under the Other folder in Web Inspector. For instance, if you change your UA to iPad, open up Web Inspector, then open up a clip on Comedy Central's The Daily Show the ad will be in MP4 but the video won't be there, at least not as a standard file. I haven't been able to figure out how they do it. I assume that don't think it's secure enough that they only allow clips and not full episodes to be watched unless you have Flash installed.
Streaming video tends to not be contained in a single file when it downloads. Adverts are so short, they can just put them in a small standalone document. To download streams, there are programs where you can direct the stream into a file and it will fill it up but it's not the same as a media file playing in a browser. It's like listening to internet radio where it doesn't download a file that just gets bigger and bigger, it just buffers a portion of the live packets being sent out and then flushes the buffer when you don't need it any more. That's why streaming has to buffer content again when you skip around far enough.
You never have to get a full copy of a streaming movie, just a buffer of a few MB and it can flush it regularly. That alone gives them some protection but when it has no DRM (more than encryption), someone would be able to develop a program that can point to the stream and never flush the buffer so eventually it gives you a full copy of the content, which you can then put somewhere else or stream yourself.
There's a lot of work goes into a full DRM service:
and as you say, it can be difficult enough with streaming that you won't bother anyway. For one thing, streams tend to be bandwidth capped too because you only need enough bandwidth to watch it in real-time so a 90 minute movie would take ~90 minutes to save the stream.
It does have implications for bigger scale operations though. Netflix for example. They have exlcusive licenses to some content so someone with a Netflix account could try downloading multiple streams to setup a rival service. I think they could get round it to some extent by embedding user credentials into the image content such as a license code. That way even if they downloaded it and re-encoded it, it would have their code in it and it could be made largely invisible right in the middle of the image. Poeple who rip streams could adjust the color of the image to obfuscate it but when it's multiplied with the image, they couldn't guarantee adjustments would eliminate the watermark.
If the stream is found to have been shared, they look at the embedded key and cancel the user's account and possibly prosecute for copyright infringement.
Mozilla is excited to announce that we’ve achieved a major milestone in WebRTC development: WebRTC RTCPeerConnection interoperability between Firefox and Chrome. This effort was made possible because of the close collaboration between the open Web community and engineers from both Mozilla and Google.
RTCPeerConnection (also known simply as PeerConnection or PC) interoperability means that developers can now create Firefox WebRTC applications that make direct audio/video calls to Chrome WebRTC applications without having to install a third-party plugin. Because the functionality is now baked into the browser, users can avoid problems with first-time installs and buggy plugins, and developers can deploy their apps much more easily and universally.
Comments
Quote:
Originally Posted by gwjvan
Maybe I'm just misreading the charts/numbers but it looks like at the moment Google is contributing twice as much to WebKit as Apple is. That "nearly tied" claim seems to be for total number of commits (someone correct me if I'm wrong)- but Google's current rate of contribution is much higher. So the difference in the total number of commits between the two companies is likely to grow pretty quickly.
Overall, it's a pretty pointless statistic (number of commits). Someone could break one set of changes to 100 files into 100 different commits if they wanted to manipulate the numbers in their favour.
Really, what would be most interesting is who is contributing most to the overall architecture of WebKit these days (not just working in their own little area for their own needs). That's what everyone benefits from and what drives the project forward.
Quote:
Originally Posted by SolipsismX
Now you're just trying to lessen Apple's involvement and achievement with WebKit. Apple spent years privately converting the KHTML fork over into the WebKit we finally saw released in Safari. To suggest this isn't Apple's creation and that they only get credit for the name and logo blows me away. Is Android's not Google's even though they bought Android from another company who used Linux for the kernel and whose codebase now consists of outside sources adding to it? I've never once heard you or MacRulez or DaHarder or anyone else say Android isn't Google's property so why is WebKit all of a sudden something Apple gets no credit for shaping? Seems disingenuous to me.
Wha?? How did you get that from my post? I never even commented on Webkit development, whose history is available to anyone who's interested in looking it up. You made the comment that Apple owned Webkit, and as evidence you offered the notice of their trademark. I replied with my understanding and followed up with a quote from Webkit.org, just as you did.
Now you're just trying to lessen Google's involvement and contributions to Webkit.
By the way, Android source code is not Google's property. It's open source. But I think they own the trademark to the name, just like Apple does with Webkit.
Quote:
Originally Posted by auxio
Really, the only thing which matters is the technologies/ideas which make up a project. A name is just a name and can change many times during the lifespan of a project (and it's forks). As can legal ownership as companies are bought, sold, go bankrupt, etc.
But yes, if it makes you happy, I'll also give Apple credit for providing the infrastructure to support the project. Though I believe that's the contentious point for the original KDE developers if you read the Wikipedia article: they really had to push Apple to provide this type of information (what bugs were being fixed by which patches). But I'm glad Apple finally set this up for the WebKit project in the end: many companies likely wouldn't bother unless they were legally forced to do so.
The only things which matters is whether corporate interests are aligned with open source. If they are then resources flow. When it does not you have a gimped dev team of two and a half men.
Webkit was an Apple fork refactored to meet Apple's needs and Apple goals and what could be released under BSD was done so rather than LGPL to make it corporate friendly for reuse (everything but webcore and javascriptcore). Back in the day I remember one of the original KDE devs that had moved to Webkit comment that calling Webkit a fork of KHTML was like calling a chicken a fork of an egg...ah open source pissing contests. If Theo had been involved it would have made it even more classic.
KHTML is about as significant as when it started...not very. I think Twitter rendering was nearly completely borked in KHTML/KJS last year sometime and no one noticed. Nobody tests against KHTML except maybe the KDE webmaster.
Quote:
Originally Posted by nht
The only things which matters is whether corporate interests are aligned with open source. If they are then resources flow. When it does not you have a gimped dev team of two and a half men.
Webkit was an Apple fork refactored to meet Apple's needs and Apple goals and what could be released under BSD was done so rather than LGPL to make it corporate friendly for reuse (everything but webcore and javascriptcore). Back in the day I remember one of the original KDE devs that had moved to Webkit comment that calling Webkit a fork of KHTML was like calling a chicken a fork of an egg...ah open source pissing contests. If Theo had been involved it would have made it even more classic.
KHTML is about as significant as when it started...not very. I think Twitter rendering was nearly completely borked in KHTML/KJS last year sometime and no one noticed. Nobody tests against KHTML except maybe the KDE webmaster.
Indeed, this is the way of all things: something is only relevant if enough people pay attention to/care about it.
However, I still see a project and all of it's forks as a continuum of the same core technology. In this regard, you cannot say that Apple is solely responsible for WebKit. One day, Apple's influence on the industry could change (or it could morph into a different type of company which has no interest in WebKit). At which point, another Apple-like entity could devote resources to a new fork of the technology now known as WebKit, and the name "WebKit" would become as irrelevant as KHTML is today. A name is just a name.
Quote:
Originally Posted by gwjvan
Maybe I'm just misreading the charts/numbers but it looks like at the moment Google is contributing twice as much to WebKit as Apple is. That "nearly tied" claim seems to be for total number of commits (someone correct me if I'm wrong)- but Google's current rate of contribution is much higher. So the difference in the total number of commits between the two companies is likely to grow pretty quickly.
Hard to say it's a complicated question.
What's a Typical Commit? A Characterization of Open Source ...
It's safe to say that a simple look at the number of commits isn't a very informative measure.
I would say Apple is in the driver's seat because it's their project. Other big contributors see the value of the central idea of the project (smart, sensible, fast, organized, predictable, standardized, open, un-borked, rendering engine and browser) and it fits the bill for them. The big dogs and a lot of small dogs agree — it makes sense for them, they like it, and they contribute, make fixes, and add things they want. As soon as it doesn't meet their needs, they can fork it and maybe others will follow. But no point in reinventing the wheel if it keeps getting better and better and keeps rolling so nicely.
deleted
Quote:
Originally Posted by iSteelers
Can everyone please stop quoting Wikipedia as a vetted source of information in these arguments?
There's nothing wrong with quoting Wikipedia (and it *is* "vetted.")
As with any writing, a quote is only as good as the person quoting it. People still have to evaluate sources, arguments, logic, truth, reliability, etc.
As an edit to this I have been looking back at some articles by arstechnica about the webkit fork of the khtml engine and found that the creator of khtml and others back in 2007 helped reincorporate khtml back into webkit and reverse some of the changes apple made to make developement easier and to get webkit's/khtml engine adopted back by kde. In an interview with Lars Knoll the creator of khtml he talks about apples involvement and how webkits fork is now coming back into a merger with khtml and eventually will be adopted as part of kde.
Also that the khtml community got apples webkit set up with full code disclosure by apple back to the community which was the reason for the big uproar with apples involvement to begin with.
There good reads if your interested circa 2007 on ars.
Here are the links:
http://arstechnica.com/apple/2007/06/ars-at-wwdc-interview-with-lars-knoll-creator-of-khtml/
http://arstechnica.com/information-technology/2007/07/the-unforking-of-kdes-khtml-and-webkit/
Quote:
Originally Posted by ash471
Apple.mail is a webkit product? Why does Apple.mail suck so much. It doesn't attach emails separately, it doesn't update very well (I'll get my iphone emails minutes before Apple.mail), and it does a poor job of handling wifi interruptions. It also creates stupid, meaningless attachments.
What blather. iPhone Mail is Apple Mail. The rest of this post can be read in the same context.
Quote:
Originally Posted by iSteelers
Can everyone please stop quoting Wikipedia as a vetted source of information in these arguments?
That particular Wikipedia article has links to mailing list archives which support what is written. I also happened to live through and follow the whole KHTML->WebKit fork (I was working on both Linux and Mac OS X at the time). And though I wasn't actually involved with the project, the Wikipedia article is accurate based on what I remember of it.
It's quite remarkable how many Wikipages are well cited. I find it an absolutely great jumping off point.
I don't think I've gone a day without Wikipedia as a resource in years. Sometimes the journey it takes as you click on links to other Wikipages will lead you to information that you had no idea existed.
One down:
http://www.engadget.com/2013/02/13/opera-300-million-webkit-switch/
C'mon Firefox/Mozilla, make the switch.
There are even considerations for DRM now:
http://www.engadget.com/2013/02/12/w3c-to-explore-a-proposal-bringing-drm-hooks-to-html/
That could mean no Flash or Silverlight needed for video streaming from larger providers. HTTP Live Streaming would work fine though. Apple's implementation doesn't support DRM but it says they can encrypt streams and restrict access to encryption keys. People will always be able to rip video from a stream anyway just like people can record TV shows.
1) I'm glad to see more uniformity on the internet but I would ideally like to see it happen with multiple browser engines.
2) I am more shocked Opera has 300 million users. I bet a good many of them are pissed by this. Hard to be elitist when you're using the same engine as everyone else.
3 The encryption seems to work well. I'v tried to find the source files for some sites and unable to find them. They usually pop up in under the Other folder in Web Inspector. For instance, if you change your UA to iPad, open up Web Inspector, then open up a clip on Comedy Central's The Daily Show the ad will be in MP4 but the video won't be there, at least not as a standard file. I haven't been able to figure out how they do it. I assume that don't think it's secure enough that they only allow clips and not full episodes to be watched unless you have Flash installed.
That was how it was supposed to work orginally but it's too slow trying to get everyone on the same path (yes Microsoft, everyone's looking at you). You can see from the article, they suggest the Opera developers were tired of having to modify things to keep up with sites being designed for Chrome and Safari - likely on the mobile side. For the same reasons that Android makes it easier for phone manufacturers to put out a solid OS, webkit makes it easier for browser developers to have a solid, compatible engine without the constant struggle to add compatibility.
While competition can help push new features and standards, given the scale and richness the web has reached, compatibility is more important.
There's still room to be unique while using the same engine just like video games can be different with the same core engine. Chrome is different from Safari for example. Here is a preview of Opera's Ice web browser:
[VIDEO]
Streaming video tends to not be contained in a single file when it downloads. Adverts are so short, they can just put them in a small standalone document. To download streams, there are programs where you can direct the stream into a file and it will fill it up but it's not the same as a media file playing in a browser. It's like listening to internet radio where it doesn't download a file that just gets bigger and bigger, it just buffers a portion of the live packets being sent out and then flushes the buffer when you don't need it any more. That's why streaming has to buffer content again when you skip around far enough.
You never have to get a full copy of a streaming movie, just a buffer of a few MB and it can flush it regularly. That alone gives them some protection but when it has no DRM (more than encryption), someone would be able to develop a program that can point to the stream and never flush the buffer so eventually it gives you a full copy of the content, which you can then put somewhere else or stream yourself.
There's a lot of work goes into a full DRM service:
http://msdn.microsoft.com/en-us/library/cc838192(v=vs.95).aspx
and as you say, it can be difficult enough with streaming that you won't bother anyway. For one thing, streams tend to be bandwidth capped too because you only need enough bandwidth to watch it in real-time so a 90 minute movie would take ~90 minutes to save the stream.
It does have implications for bigger scale operations though. Netflix for example. They have exlcusive licenses to some content so someone with a Netflix account could try downloading multiple streams to setup a rival service. I think they could get round it to some extent by embedding user credentials into the image content such as a license code. That way even if they downloaded it and re-encoded it, it would have their code in it and it could be made largely invisible right in the middle of the image. Poeple who rip streams could adjust the color of the image to obfuscate it but when it's multiplied with the image, they couldn't guarantee adjustments would eliminate the watermark.
If the stream is found to have been shared, they look at the embedded key and cancel the user's account and possibly prosecute for copyright infringement.
Quote:
Originally Posted by SolipsismX
1) I'm glad to see more uniformity on the internet but I would ideally like to see it happen with multiple browser engines.
https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/
Mozilla is excited to announce that we’ve achieved a major milestone in WebRTC development: WebRTC RTCPeerConnection interoperability between Firefox and Chrome. This effort was made possible because of the close collaboration between the open Web community and engineers from both Mozilla and Google.
RTCPeerConnection (also known simply as PeerConnection or PC) interoperability means that developers can now create Firefox WebRTC applications that make direct audio/video calls to Chrome WebRTC applications without having to install a third-party plugin. Because the functionality is now baked into the browser, users can avoid problems with first-time installs and buggy plugins, and developers can deploy their apps much more easily and universally.