|Fork Webkit||Daniel Hendrycks||11/25/10 10:23 AM|
Hi, could you please fork WebKit? When Chrome/ium did not go with
WebKit's JS engine things turned out great, and now V8 is the fastest/
second fastest (V8 and Carakan are too close) engine out there, this
shows great things can come from the Chrome team and developers when
they work together. Forking WebKit would make Chrome free from Apple,
since Apple could make it proprietary http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=85041789
. Additionally, Chrome would make the web better by doing this; this
would better prevent a monoculture (remember Flash and IE6?).
Competition is absurdly good for the web. Thank you for listening!
|Re: [chromium-discuss] Fork Webkit||Aaron Toponce||11/26/10 9:11 AM|
On 11/25/2010 11:23 AM, Daniel Hendrycks wrote:
You must not be familiar with how software licensing works, specifically
First, Webkit is licensed under the GNU LGPL and BSD licenses. This
Second, Apple isn't the only developer of the product. KDE, Nokia,
|Re: Fork Webkit||Daniel Hendrycks||11/27/10 9:59 AM|
On Nov 26, 11:11 am, Aaron Toponce <aaron.topo...@gmail.com> wrote:> > since Apple could make it proprietaryhttp://tarr.uspto.gov/servlet/tarr?regser=serial&entry=85041789
> > . Additionally, Chrome would make the web better by doing this; thisThank you for that clarification, that still does not diminish the
pluses for forking WebKit; but it eliminates that one. Still,
|Re: [chromium-discuss] Re: Fork Webkit||Peter Beverloo||11/27/10 12:28 PM|
What monoculture are you talking about? There are two engines which are larger than WebKit: Trident, used in Microsoft Internet Explorer, and Gecko, used in Mozilla Firefox. There are two other large engines around as well, being Presto, used in Opera and KHTML, still being used by the KDE project. Even though WebKit was based on the latter, internally both have changed significantly in the past eight years.
|Re: Fork Webkit||Daniel Hendrycks||11/27/10 1:11 PM|
On Nov 27, 2:28 pm, Peter Beverloo <pe...@chromium.org> wrote:> <danielhendry...@gmail.com>wrote:
> > Chromium Discussion mailing list: chromium-disc...@chromium.org
> > View archives, change email options, or unsubscribe:Presto is only used in Opera Products, its source has never been
public. I am talking about the potential monoculture, given Webkit
keeps rising, thanks to Chrome and Safari. WebKit's domination is
becoming more apparent, having a fork would mean Safari would use
WebKit and Chrome would use its fork, making a monoculure less likely.
While Gecko and Trident continue to lose share. Look at Flock, it is
now going to use WebKit, look at new browsers (e.g. Rockmelt), they
are using WebKit; look at the web space, all browsers (other than
Opera's Mobile and Mini and Mozilla's Fennec) are using WebKit, since
it is the only proper engine (that is free, not saying Presto is bad,
it is wonderful). The stage is set for WebKit to dominate, given its
rise. Much like how V8 was a success, I think a fork of WebKit would
|Re: [chromium-discuss] Re: Fork Webkit||Frank||11/27/10 1:41 PM|
Daniel, what benefits are you envisioning here? I don't even think Apple can close source WebKit at this point since it has a LOT of contributions from elsewhere. Basically every mobile device uses a form of WebKit these days, and a lot of large companies are quite committed to it going forward, including Sony, Nokia, Google, Apple, Intel, Samsung... it would not be cost effective at all for any of these companies to fork the code just to maintain by themselves.
Improving this rendering engine improves the internet for everyone, so it is in each of their interests to work together for the long term. Until one of the major companies involved does something radically bad with the code base, there is absolutely nothing to gain from what you suggest. Everyone wants HTML5 to succeed - even Microsoft is committed to it over Silverlight now.
|Re: [chromium-discuss] Re: Fork Webkit||Frank||11/27/10 1:42 PM|
WebKit is under the LGPL due to its history via KHTML - no one can take the current code base and simply not make it available anymore.
On Sat, Nov 27, 2010 at 2:11 PM, Daniel Hendrycks <danielh...@gmail.com> wrote:
|Re: Fork Webkit||Daniel Hendrycks||11/27/10 1:56 PM|
>WebKit is under the LGPL due to its history via KHTML - no one can take theAaron already corrected me on this.
I was not suggesting all of those companies fork it, I was/am
suggesting a fork.
If every browser moved to WebKit, hackers would focus their attention
to one place. Additionally, forking it would better prevent a
monoculture. If WebKit were on top, it would not be pushed to compete
with other engines, much or at all. This benefit can be easily seen
back on, pushing Opera's Carakan, Mozilla's Jaagermonkey, Idiot
Explorer's Charka, and Safari's Nitro to strive for first. If browser
developers were all to shift their development toward V8, we would
probably be at 700ms on sunspider rather than 200ms. The benefit of
competition can be empiracally proven;=: when Opera showcased Carakan
in Opera 10.5, it was ahead of V8, then V8 got some large speed
improvements, before Carakan there were not many large strides by V8,
the months before. Summation: Competition = Absurdly Good. Quality
Fork brings more competition.
|Re: Fork Webkit||Daniel Hendrycks||11/27/10 1:58 PM|
On Nov 27, 3:56 pm, Daniel Hendrycks <danielhendry...@gmail.com>
> *my response*
Sorry, I got a bit repetitive.
|Re: [chromium-discuss] Re: Fork Webkit||Frank||11/27/10 4:38 PM|
Again, most of the speed ups that happened in Opera were them playing catchup to the stable Chrome. The beta channel was already seeing speed improvements when Opera's stuff went public. Also, graphics card rendering stuff was in the beta channel far before Microsoft did any of that work too.
I simply think it is more beneficial having multiple large companies paying teams to make WebKit faster and more secure than forking WebKit and having two groups spending half their time integrating what the other has done back into their branch. If you actually have any ideas as to features not permitted in mainline WebKit that you think are interesting, sure, go ahead and fork. You seem to be suggesting a fork just to fork though, which is simply not how things work.
|Re: Fork Webkit||Daniel Hendrycks||11/27/10 6:21 PM|
On Nov 27, 6:38 pm, Frank <francis.e...@gmail.com> wrote:In a possible world where everyone used WebKit and an exploit
happened, they would all be effected by the exploit. Do take note of
PWN to Own 2010, where there was a vulnerability in WebKit, affecting
both Chrome and Safari, sure they use different methods of protection,
but the exploit was still there. Forking is measure against such a
possibility. Your assuming that the companies would take long to fix
an exploit if forked. I am suggesting Google fork, not everyone, since
they (everyone else) could not handle it.
Your whole response is contingent on the fact that speeds did not
dramatically increase when Carakan started winning. Of course Google
made gradual gains, but not as much when they were forced to fight for
their crown. And now look at us, Sunspider has reached the bottleneck.
Now we can optimise for things like Guassian Blur, etc on the Kraken
Benchmark (not topical).
The speed ups that were from Carakan were faster than that of the dev
builds of Chrome, people tested preview against preview. The speed
improvements from V8 greatly increased when Carakan was released. (You
can see many of the tests with a search) Your graphics comment is not
I am not suggesting forking for giggles, I am suggesting it for large
Engines got much faster when V8 and Carakan went at it; before, V8 was
making great strides, but not nearly as large as later. If you think
what I say is not true, just think about it (and search about it,
too): People are saying Chrome has competition, would you show Carakan
who is boss or would you say "my pase is fine" and lose your crown
(considering the pase of Carakan was phenomenal at the time of
introduction, here are my recordings of it:
Monoculure and Security Issues
Competition Is Absurdly Good, everyone working on one thing does not
bring much competition
|Re: [chromium-discuss] Re: Fork Webkit||Turtle||11/28/10 12:30 AM|
On Sun, Nov 28, 2010 at 10:21 AM, Daniel Hendrycks
> "You seem to be suggesting a fork just to fork though"
You are not suggesting forking for giggles, you are suggesting forking
However, anyone who is familiar with software development knows that
In any case there is already a fork of WebKit called KHTML (well
However, if you want to avoid a mono-culture feel free to use
|Re: [chromium-discuss] Re: Fork Webkit||Aaron Toponce||11/28/10 5:56 AM|
On 11/27/2010 02:11 PM, Daniel Hendrycks wrote:
You don't fork software, just for the sake of forking it. Failure will
Icecat was forked from Firefox, because the GNU project didn't like that
Forking can be healthy, if it's done right. Forking Webkit, just for the
|Re: [chromium-discuss] Re: Fork Webkit||Aaron Toponce||11/28/10 6:01 AM|
On 11/27/2010 10:59 AM, Daniel Hendrycks wrote:
There is no monoculture with Webkit. It's developed by a massive
Your fear is paranoia due to ignorance, and it's not based on any
|Re: Fork Webkit||Daniel Hendrycks||11/28/10 9:47 AM|
On Nov 28, 8:01 am, Aaron Toponce <aaron.topo...@gmail.com> wrote:Which use WebKit, all using the same engine. "A single, homogeneous
culture without diversity or dissension." There are many companies
developing it, but that does not in any way WebKit, if gains 99%
share, is not in a monoculture since there are many developers.
Personal attacks are always good for conversation, please be kind. It
is a suggestion, and additionally, one person cannot code a successful
fork that will work and be superior to WebKit. Please, quit putting
forth silly suggestions for it is waisting everyone's time.
No, did WebKit fork because it disagreed with KDE? (honest question)
Since many fork for those reasons, that does not mean it should never
be done for a different reason. I see no basis against that.
You seem to be diminishing the motive. I am not suggesting a fork for
no reason, I am suggesting one for reasons, not just for the reason
of, "Let's press the Fork button". Basically, if we were to use the
logic that is brought forth. LibreOffice is forking just to fork, one
with the mindset brought forth by you would be ignoring the reasons
why it is being forked, and it would then be called "just forking".
I supplied reasons, show me why they do not work/improve the web.
Actual counter arguments.
|Re: Fork Webkit||Daniel Hendrycks||11/28/10 10:01 AM|
> <danielhendry...@gmail.com> wrote:Agreed, however, in WebKit's case the actions requested are plausable
and would be helpful. If we were to fork a project, the fork would
probably not succeed if backed by a small person. The fork would
probably be successful if it has the proper backing, like from Google.
If Google would fork, there would actually be competition created, if
one person forked, then it would just create a mess and no larger
company would go with that petty fork.
Given its rapid pase and the fact that more and more browsers are
turning to it over Gecko, it is very likely to be the ruler, unless
Presto takes more share, but that is a different discussion.
Analogy is not proper, for they may both be working on a dinner, but
the dinner is not the same. No one is hiring two chefs to make the
same dinner. Since the owner would be hiring one to cook off with the
other chef that the owner is not employing.
That is backed by a small person. If you are attempting to show that
forking WebKit is wrong by saying "KHTML is failing, therefore, a fork
would fail" is not right, since Google would be backing the project.
I'll take this as a snide comment, rather than an actual suggestion.
|Re: [chromium-discuss] Re: Fork Webkit||Aaron Toponce||11/28/10 10:58 AM|
On 11/28/2010 10:47 AM, Daniel Hendrycks wrote:
I don't understand what you're saying here
There was no personal attack. I made no name calling nor did I use any
Wasting time? If you want to fork it, fork it. I've shown you were tho
> No, did WebKit fork because it disagreed with KDE? (honest question)
Yes. KHTML didn't meet the needs that Apple was looking for, and thus
> You seem to be diminishing the motive. I am not suggesting a fork for
> I supplied reasons, show me why they do not work/improve the web.
You haven't given a solid reason why a fork should be made, nor how it
|Re: Fork Webkit||Daniel Hendrycks||11/30/10 4:43 AM|
Sorry, I was unaware that there was a reply.
>Your fear is paranoia due to ignorance"Don't personally attack me."
You were calling me ignorant, and you were calling me paranoid. I do
agree you were calling my judgment that, but it is still rude. No
matter, let's drop this.
*Never responds to the second part of the first sentence, just tells
me to quit whining* Beside, this is a place of suggestion. Is every
request that comes here supposed to be coded before you post a request
for change or implementation? (rhetorical)
I'll try to change things up:
...which use WebKit, all using the same engine. Definition (since I
see fabrication) "A single, homogeneous culture without diversity or
dissension." It is monoculture in the engine space, there isn't
diversity. There are many companies developing it, but that does not
in any way mean WebKit, if gains 99% share, is not in a monoculture of
engines; since it is the hegemon.
I haven't heard an address to Security is improved and general
competition is great (look at V8)
>nor how it would be successful.You have doubt that if Google would fork, the fork would be
>then somehow it's monoculture even though I've shown you have massively large and diverse the community is.
The developers are diverse, not the engine. That is like saying V8 is
diverse, the developers may be, but the engine is the same across
millions of computers, or with a small modification. Please address
this point first.
|Re: [chromium-discuss] Re: Fork Webkit||PhistucK||11/30/10 11:42 AM|
I understand what you are trying to say (though I do not really agree), but in the meantime, WebKit is not a really major rendering engine in terms of market share.
Currently, there is no need to break the party.
Once it reaches a high percentage (at least as that of FireFox, but maybe even higher), that might be justifying a fork in some weird sense.
And even then, WebKit might be a monoculture, but the rendering engine world has a few dominant and diverse options, so it is still not enough of a reason to fork it.
Eventually, like Aaron wrote, once there is a conflict in the way things are run or headed at WebKit, there would really be a need for a fork. Until then, it is just a waste of time and resources. Security can be degraded as well as can be improved, it is not a one way street. They fix one thing that matters to them, but not the other, which they have not tested enough.
Forking WebKit now would mean to go back in time to 2008 and start merging the code from WebKit every few hours in a relatively manual way - that was not a good development life cycle, the development suffered from it, it hindered it, it slowed it down.
Until there is a real reason to invest time in actually doing other stuff than WebKit wants to do, there is no real need to fork.
Currently, they share the same targets. Until they do not - this is a fine situation.
|Re: Fork Webkit||Daniel Hendrycks||12/8/10 1:37 PM|
>WebKit is not a really major rendering engine in terms ofUntil then, I will wait to revive this suggestion.