Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

Post reply on HN
Print view View original

191–200 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#191

Post by Me1000 »

othermaciej wrote: post #183
mikewest wrote: post #126

Earlier quoted context omitted.

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run…

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…

I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.

Re: Blink: A rendering engine for the Chromium project

#193

Post by nnethercote »

yanw wrote: post #20
ebbv wrote: post #2

I can't help but think that forking WebKit is a business based decision since Apple controls WebKit. This blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks. * - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason. EDIT: At the bottom of the project page are some engineering reasons:…

Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines How is that not engineering based?

Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.

Re: Blink: A rendering engine for the Chromium project

#194

Post by justinschuh »

othermaciej wrote: post #183
mikewest wrote: post #126

Earlier quoted context omitted.

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run…

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…

I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR

Re: Blink: A rendering engine for the Chromium project

#195

Post by nnethercote »

mikewest wrote: post #175
checker659 wrote: post #170

Can anyone from the chromium team answer few questions? 1. How does this affect the build system? 2. Will Blink always remain a fork of Webcore, or do you plan on replacing all the bits and pieces from Webcore with your own code? 3. Are we still stuck with the LGPL license? 4. Does this change anything in the spectacularly lacking source documentation / porting guidelines front. 5. You mentioned stripping out a lot.…

1. Chromium will continue to build via gyp. 2. I'm not sure what you mean. 3. We can't, and don't want to, change the license of code that's already been released. That said, most (all?) of WebCore isn't LGPL. See my favourite file, http://trac.webkit.org/browser/trunk/Source/WebCore/page/Con... for example. 4. WebKit and Chromium have historically had differing opinions regarding what makes a "good" comment. I think…

I mentioned above that the last time I measured (late 2012) the entire mozilla-central repository it was 4.488 million lines of code. How many lines is Chromium? How on earth can you be removing 5 million LOC?

Re: Blink: A rendering engine for the Chromium project

#196

Post by itafroma »

Me1000 wrote: post #191
othermaciej wrote: post #183

Earlier quoted context omitted.

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…

I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.

A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split.

Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.

Re: Blink: A rendering engine for the Chromium project

#197

Post by jammmuel »

dave1010uk wrote: post #102

This paragraph makes me happy: From a short-term perspective, monocultures seem good for developer productivity. From the long term perspective, however, monocultures inevitably lead to stagnation. It is our firm belief that more options in rendering engines will lead to more innovation and a healthier web ecosystem. From http://www.chromium.org/blink/developer-faq

I find this a doubled-edged sword. Monocultures are said to foster a culture of laziness, apathy. This hasn't been the case with WebKit. Don't get me wrong - competition is healthy. I'm simply thinking of how Jovinder experiences the web.

Re: Blink: A rendering engine for the Chromium project

#198

Post by [deleted] »

Me1000 wrote: post #191
othermaciej wrote: post #183

Earlier quoted context omitted.

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…

I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.

[deleted]

Re: Blink: A rendering engine for the Chromium project

#199

Post by dubcanada »

frewsxcv wrote: post #189
dubcanada wrote: post #173

Earlier quoted context omitted.

You do know that most of the WebKit code as it is is Apple's right? If anything it was Google who got a free ride.

I thought most of it is KDE's?

KDE originally built KHTML. WebKit however is mostly a product of Apple. They made it into the product it is today. Along with help from Google/RIM/etc. But it was mostly them since they needed it to work in Safari and iOS.

Re: Blink: A rendering engine for the Chromium project

#200

Post by Osiris »

macrael wrote: post #112

So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…

Why is this a failure of open-source? Isn't it exactly what open-source is supposed to do, fork when a project doesn't meet your needs?

I've always found it curious that open-source advocates rail on people that fork or split from projects instead of maintaining code that they believe isn't worth maintaining.

Post reply on HN