WebKit Developers Discuss Removal of Google-Specific Code

hypnosec writes "WebKit developers have already started discussing the removal of Chrome- and Chromium-specific code from the rendering engine in a bid to make the code easier to maintain. Just a couple of days back, Google announced it will go ahead with a WebKit fork to develop a new browser engine — Blink. According to Google, having multiple rendering engines — just like multiple browsers — will allow for innovation as well as contribute toward a healthy open-web ecosystem. The discussion was started by Geoffery Garen, an Apple WebKit developer. He said Google's departure is an 'opportunity to streamline' the code of WebKit, which would eventually make development 'easier and more coherent for everyone.' Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel — two Google WebKit developers — have already offered their help." Google plans on making the switch to Blink in the stable Chrome release in around 10 weeks. They've posted a half-hour video explaining how the transition will work.

Comments

Clean It Up Boys

[Anonymous Coward]

The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.

The down side to all this is checking code in another browser model as well as a different js debugger in Blink.

World Wide Web of Moving Targets

Re:Clean It Up Boys

[mwvdlee]

I just hope they make it a fork in the sense that Linux distro's are forks; actively exchanging code with the upstream project for the benefit of both.

Re:Clean It Up Boys

[Anonymous Coward]

Directly contradicting the first post. The announcement suggests neither will be upstream of the other.

Re:Clean It Up Boys

[Digicrat]

That still doesn't preclude sharing on equal terms, at least until the two projects diverge enough to make that impractical.

Re:Clean It Up Boys

[Anonymous Coward]

Linux distros like ubuntu are technically not forks, but rather derivatives. A fork becomes independent after the fork takes place, even if they do merge code back and forth with the parent project. A derivative, on the other hand, is still dependent on the upstream project for core functionality.

Autonomy is what makes a fork a fork. Dependence is what makes a derivative a derivative.

Re:Clean It Up Boys

[KugelKurt]

The removal of Chrome specific code from WebKit, and non-Chrome code from Blink will benefit everyone in the long run. Both code bases and rendering engines will be smaller, faster, less buggy, etc.

Please explain to me: What negative impact do cleanly separated platform adaptions have? So WebKit devs will delete the chromium directory in https://trac.webkit.org/browser/trunk/Source/WebCore/platform and Google will delete all directories except chromium (and probably android) but I don't see why a buggy BlackBerry adaptation would have any negative impact on the Chromium adaptation and vice versa.

Re:Clean It Up Boys

[thetoadwarrior]

WebKit doesn't include a JS engine cheome has always had V8 and safari didn't. So your JS development should be any different.

Re:Clean It Up Boys

[afidel]

Yeah, the BSD projects borrow fairly liberally from each other despite the fact that the code can rarely be copied and pasted.

Re:Clean It Up Boys

[BasilBrush]

Webkit does have a JavaScript Engine. It's called JavaScriptCore. But Chrome didn't use it.

Re:Clean It Up Boys

[XSEnergy]

That would make sense, but the discussion has now veered off into also removing the ability to plug in components such as your own JavaScript engine, because it is expensive to maintain....if anything the cleanup should go the other way of making it more easy to plug-in different implementations for specific pieces into WebKit. The lesson here should be IMHO, to avoid future forks by making ports less expensive, not use this as an opportunity to cut down on extensibility.

Re:Clean It Up Boys

[Anonymous Coward]

I wish these targets (implementations) would move even faster, so developers would finally code to standards and standards alone.

Re:Clean It Up Boys

[Anonymous Coward]

Are you nuts? Extensibility for its own sake is not a good thing.

If you read through those messages carefully, you'll notice that they came to the conclusion that, with Google gone, literally every organization directly contributing to WebKit trunk uses JavaScriptCore. And that those who are using V8 in downstream projects don't seem to consider it a disaster if it goes away in trunk. So there isn't much reason for WK maintainers to continue V8 support.

It doesn't sound like there's a real plugin API involved either. What I take away from those emails is that JS is very tightly tied to the guts of WebKit, and that the present dual-engine support is a pile of #ifdef hurt which everyone only put up with because Google was providing enough value to the project (and getting enough value in return) to make the pain worthwhile.

Also consider that Google's reasoning for forking WebKit included doing much the same kind of cleanup in the new Blink fork, so that Blink will be easier to maintain and will also get faster. Why would WebKit want to leave those same benefits on the ground now that the only real force requiring them to support lots of alternate technologies is gone?

Hurr durr Google

[Anonymous Coward]

Here's to DART, NativeClient and Google's never ending quest to push their own battery-killing video and audio codecs as no hardware supports it natively.

Re:Hurr durr Google

[Anonymous Coward]

http://prng.net/blink-faq.html

Re:Hurr durr Google

[Anonymous Coward]

Clearly he's not a big fan of Google (unless Google was in the back seat of Thelma & Louise's car, then he'd be cheering them on for their gusto), but there is truth in his sarcasm.

I wonder how this will affect Chrome on iOS?

Re:Hurr durr Google

[Anonymous Coward]

What a bunch of FUD. Did whoever wrote that actually read the original?

For example:

1.4 How does this affect web standards?

We have sufficient market share on the desktop that a few months from now, we will be in a position to unilaterally dictate them.

We hope to leverage this control to achieve the same dominance in mobile eventually.

1.5 Will we see a -chrome vendor prefix now?

No. See 1.4.

vs

Will we see a -chrome- vendor prefix now?

We’ve seen how the proliferation of vendor prefixes has caused pain for developers and we don't want to exacerbate this. As of today, Chrome is adopting a policy on vendor prefixes, one that is similar to Mozilla's recently announced policy.

In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features” flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels.

For legacy vendor-prefixed features, we will continue to use the -webkit- prefix because renaming all these prefixes to something else would cause developers unnecessary pain. We've started looking into real world usage of HTML5 and CSS3 features and hope to use data like this to better inform how we can responsibly deprecate prefixed properties and APIs. As for any non-standard features that we inherited (like -webkit-box-reflect), over time we hope to either help standardize or deprecate them on a case-by-case basis.

How does giving devs a chance to use new features ahead of time, without vendor-specific prefixes, while keeping the -webkit- prefixes and saying "we won't use vendor prefixes for new features" translate into highjacking the standards process? If they are using the same approach as Mozilla, is Mozilla being accused of hijacking the standards process?

Re:Hurr durr Google

[Anonymous Coward]

Hurr durr, bullshit hardware lies from YEARS ago. VP8 has hardware support you twit, quite a bit of it, read the fucking specs.

Like this part

[Anonymous Coward]

#ifdef __CHROME__
doCheckpoint( 1332 ); // load additions to keystroke log and browser history
doCheckpoint( 1335 ); // compress
doCheckpoint( 1337 ); // send contents to gmail server
#endif

Re:Like this part

[allo]

> implying, there is the #ifdef line

Re:Good

[siride]

As of this article, that's exactly what's happened.

On the Origin of Species

[Anonymous Coward]

I don't see why people get so scared of forking code. Differentiation and species drift happens in nature all the time, and a code-base that tries to fit too many different requirements is awful to maintain (and also unstable).

Re:On the Origin of Species

[Anonymous Coward]

Because Adria Richards thinks forking is sexist and puts women down, that's why!

God forbid you using your 4g dongle to connect to the internet in order to fork webkit's repo, she'd probably have the cops arrest you!

Re:On the Origin of Species

[Anonymous Coward]

Well, in this case Webkit is planning to drop V8 support. I'm kinda freaked out by the fact that Webkit apparently isn't script engine agnostic as it should be, but now all the incentive to make it such may be lost.
Forks in general tend to cause much duplication of effort, especially if both branches remain popular. Given enough time, fixes for one fork aren't obvious to implement in the other. You shouldn't really fork a project unless you cannot reach a peaceful decision.
In this case however, Google just didn't want to contribute to the new Webkit2 with generalised multi-process support, because that would make it easy to develop a multi-process browser, which just happened to be Chrome's main selling point.
The Webkit folks made the right technical decision, Google made the right marketing decision. A fork was inevitable, sadly.

Re:On the Origin of Species

[SeaFox]

I don't see why people get so scared of forking code. Differentiation and species drift happens in nature all the time...>

I think the fear here is that the forking of code will lead to browsers that interpret "standards" differently and don't display web pages the same way. We'll be back to "I have to use Internet Explorer for site x and Netscape to get site y to work right."

One thing about homogenous browsers, we're more likely to all be on the same page on how to read the web (pun not intended).

Re:On the Origin of Species

[AmiMoJo]

We'll be back to "I have to use Internet Explorer for site x and Netscape to get site y to work right."

That's a problem with the design of the site. HTML was never designed for pixel perfect layout, quite the opposite in fact. CSS gives you a lot of control but also wasn't designed for the kind of perfection that web monkeys seem to want. Aside from anything else a site should at least be able to cope with different font sizes, for example.

If it uses so much tricky HTML/CSS/JS that it doesn't render reasonably in standards compliant browsers then I'm not browsing it.

Why not?

[RocketRabbit]

It only makes sense to trim unused legacy code from any library. If Google isn't using Webkit any more, why leave their own specific stuff in there?

It isn't a problem to fork code and remove legacy stuff. It was done when KHTML was forked into Webkit, and it will probably be done again. The only losers in the event of a fork like this are possibly the independent developers who contribute to Webkit, but it is doubtful that they were contributing code that is Google specific.

Re:Good luck with that

[MightyYar]

I thought about going for the first "woosh", but I'll leave it for another :)

Re:Good luck with that

[AikonMGB]

The video is for Chrome(ium), WebKit, and now Blink developers, not for the end users or the browser(s).

Know your audience.

[RivenAleem]

The "how the transition works" video will be for people interested in how the transition works, not a regular user. Your comment is like saying a 30 minute video on "how the internal combustions engine works" is a pointless exercise, because the regular driver just wants it to work

Re:Good luck with that

[Rich0]

This is an open source project, and the video is directed at people who work with the browser source code or who have an interested in webkit/blink. It isn't targeted at end users.

It is a rendering engine. How many end users have even heard of webkit?

Obviously the browser will work the same after as before. The only thing a user might notice is that it is faster (some day) or that it has some new feature that perhaps would not have been as easy to develop without the fork.

I for one appreciate that a company like Google takes the time to actually create videos like this. I can certainly say that my employer doesn't put half-hour videos on Youtube discussing the software engineering decisions it makes for its closed-source systems.

Re:Good luck with that

[loufoque]

Especially since none of the answers are useful at all.
It just says "it's a fork, so right now, it's the same thing". I don't know why they thought they needed to repeat this for 30 minutes.

Re:Good luck with that

[spacepimp]

The video isn't about how to use the browser. The article isn't about how to use the browser, or changes in UI of Chrome. Forking WebKit serves to accelerate and simplifying Chrome development.

Say "goodbye" to 64-bit builds of Opera... apk

[Anonymous Coward]

See my subject-line, & since Chrome-based browsers aren't 64-bit in Windows, then once the Blink/WebKit builds of Opera release (Presto = gone, what a shame imo), odds are they too will ONLY be 32-bit (that is, IF "Chrome/Chromium" & browsers derived for it for Windows are ANY kind of "indicator" here)...

* :(

(Afaik @ least? Chrome/Chromium are only 32-bit for Windows, & hence, my statements above...)

APK

P.S.=> Got to thinking about this today, & just had to note/mention it (unless anyone else KNOWS otherwise that is, & I'd appreciate that IF anyone does)...

... apk

Re:Say "goodbye" to 64-bit builds of Opera... apk

[Anonymous Coward]

Google recently banned ad-blockers and host files from their Google Play store. Will they now block them from Chrome? By default, Safari blocks 3rd party cookies (Firefox recently changed to the same). What will Chrome do? (Google was already busted for working around the 3rd party cookie restriction). There are a lot of good employees and a lot of talent at google... but they make their money by tracking you and selling you.

Re:Say "goodbye" to 64-bit builds of Opera... apk

[Guspaz]

They didn't block them before, I don't see why this fork would cause them to block them after. They may decide to do so at some point, but that decision doesn't have anything to do with the forking...

Re:Say "goodbye" to 64-bit builds of Opera... apk

[etresoft]

I think defeating ad-blocking and enhanced ad management are one of the primary reasons for the fork.

The first thing Google lists for architectural changes is support for out-of-process iframes

Re:Say "goodbye" to 64-bit builds of Opera... apk

[afidel]

Did you even bother to see why they are moving iframes to their own process? Yeah, it's all about ads, not about making a more secure product... I think this has infinitely more to do with Chromebook than it does to ad sales, in fact moving iframes to their own process would give any ad-in-iframe LESS visibility into your surfing which you would think would be the exact opposite of what an "evil" Google would want.

Re:Say "goodbye" to 64-bit builds of Opera... apk

[Guspaz]

That change has nothing to do with ads, and in no way does it help or hinder ad blocking.

Google could have handled that quite simply by banning ad blockers from the chrome store, or by not extending the API with things specifically designed to support ad blockers...

The fork doesn't have anything to do with ad blockers because nothing was stopping them from banning those before.

Re:Say "goodbye" to 64-bit builds of Opera... apk

[afidel]

Sweet, posting information about why a technical change is being made is now trolling on Slashdot, it really has gone downhill.

Re:Say "goodbye" to 64-bit builds of Opera... apk

[etresoft]

I said nothing about Google being "evil". Google is just providing more value to its customers. Google most definitely does not want ads to be able to access the rest of your browser information. That information should only come from Google, properly anonymized and billed. While this change would make it harder for malicious iframes to sniff data that doesn't belong to them, it would also give malicious iframes more opportunities to inject code. Currently, if such an iframe tried that and failed, it will kill the parent process, effectively ending the injection attempts. With the new system, multiple iframes could keep trying different tactics.

Re:Say "goodbye" to 64-bit builds of Opera... apk

[DirtyLiar]

Google is just providing more value to it's customers.

Why is it that I find when a company says that it's providing me with "more value", that I find that they are in reality removing things that I actually value, and / or adding things I do not value, and are probably charging me more for the priviledge?

For example:
I called a company complaining about a new juice bottle that, because the bottom was concave, held 1/2 an ounce less than the previous bottle, but they had not lowered their already high price. The person had the nerve to tell me that the change had been made because market research showed that their consumers wanted it. She didn't have much to say when I replied, "So you can show me surveys where people say that they either want to pay more for their juice, or get less of it, right?"

Oh, and keep in mind that the users of Google and Chrome are NOT Googles customers. Google sells targeted ads to advertisers. To be a customer really requires some kind of payment to be exchanged for a good or service.

The consumers of Google's free products are not customers, they are the product that Google sells to it's paying customers, it's advertisers.

One size fits all?

[bitflusher]

I have always wondered why everyone was using the same engine while every browser has a unique selling point. Now it becomes clear a one size fits all equals a one size fits noone perfectly. Perhaps this creates a bit more diversificaton and true unique selling points for the browsers.

Re:One size fits all?

[UnknowingFool]

Well code reuse has greatly helped anyone who has worked on open source. They don't have to reinvent the wheel every time. Apple forked KHTML because it was small (140,000 lines) and clean. Apple could have written it all from scratch but they benefited from the work that was already done in terms of time and direction. When they got more expertise they started to take it in a different direction. Google is doing the same with Blink. It's the same pattern as Apple's ARM hardware. They used slightly customized Samsung chips in the beginning for the iPhone. Then they bought PA Semi and Intrinsity. With each generation of CPU, they have customized the ARM chip more and more. At first they modified the SOC but left the ARM core intact. With the A6, they have begun to make modifications to the core itself.

And to think .. (paranoia)

[Anonymous Coward]

People were saying with the whole "Opera goes Webkit" thing was going to wreck the web, this happens.

Hope you enjoy that paranoia, you guys who were crying over it.
All that paranoid reaction for no reason. No wonder the world is in ruin.

Gonna wash that man right out of my hair!

[Anonymous Coward]

lol. They're like a bitter woman burning pictures of the ex who dumped her.

Re:Gonna wash that man right out of my hair!

[moronoxyd]

... with the ex helping to burn the pictures?
Note that at least two Google employees offered to help.

Re:Good luck with that

[flimflammer]

Yikes, the FUD is strong with this one.

Terrible name considering...

[cjjjer]

The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/

I can only imagine how much easier it will be for Google to track us via a custom HTML and extensions it implements...

Re:Terrible name considering...

[Anonymous Coward]

Said by someone with a hotmail address....

Re:Terrible name considering...

[VortexCortex]

The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/ I can only imagine how much easier it will be for Google to track us via a custom HTML and extensions it implements...

Which is doubly odd, because I just recently used the forbidden <blink> element once, in all my years of development, to create a blinking terminal-like cursor for a few quick one-off temporary landing pages (excerpts from my old text based BBS game).

Firefox actually renders the "cursor" blinking... Guess which browser doesn't? Chrome.

Re:Terrible name considering...

[Plumpaquatsch]

The first thing I though of was the http://en.wikipedia.org/wiki/Blink_element/

And I was thinking about Bling. As in "Chrome, now with extra Bling!"

Re:Terrible name considering...

[keytoe]

You may be the only other person I've heard of to use <blink> in a legitimate fashion.

About 8 years ago, I was writing a web based application for a public facing help desk department. Appointments were limited to 15 minutes per customer, and to serve as a reminder we provided a timer right in the ticket system. At a certain threshold, the timer would turn red to indicate hurry up mode - and for the last minute, it would blink. One of my coworkers set out to write a JS timer to handle it until I reminded him of <blink>*.

* Technically, it was done with CSS, but <blink> is nothing but a <span> with a default style, so same thing.

Re:quid pro quo

[flimflammer]

Erm... You're confusing external functionality that isn't cross platform (ActiveX, the old DirectX-labeled text effects, etc) versus internal functionality designed to integrate better with the browser. This is obviously the latter.

Re:quid pro quo

[moronoxyd]

For the same reason there is Apple specific code in WebKit. And (probably) PowerPC code, and x86 code, and Android code, and iOS code, and ...

Why is HyperV code in the Linux kernel?
Or code that is for Intel graphics?

If a piece of software tries to support many platforms and usage cases, you have code that is only used in specific scenarios.

And if the reason to support this platform or usage case is gone (i.e. iOS support for Blink, and Google support for post-split WebKit), then you remove it.

So...

[Sollord]

Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit? Safari and Chrome don't share much of anything really in common save for the webkit api and even then it's a clusterfuck of vendor specific tags

Re:So...

[Bill_the_Engineer]

There was a large number of "whiny bitches" on here when WebKit forked from KHTML. People react to change. Life goes on.

Re:So...

[Billly Gates]

Thats because most sites sniff useragents and serve browser specific code. This move will break apps that sniff android or Chrome and only serve -webkit specific CSs

Re:So...

[KugelKurt]

Google is evil according to all the whiny bitches on here for Forking Webkit into Blink. So just how horrifically evil is Apple for forking KHTML into Webkit?

Actually Apple at that time was a pretty bad FOSS citizen. People campaigned to Apple to rethink the way it does development and that resulted in a vendor-neutral development home for WebKit. These days KDE is a happy user of WebKit.

Google now repeating Apple's past mistakes is not so great. 2 wrongs don't make 1 right, as they say.

Re:So...

[Nerdfest]

Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.

Re:So...

[jayrulez]

Blink will support -webkit prefix.

Re:So...

[Anonymous Coward]

It basically is 3 'kits' already. Just depends on how you compile it.

Googles flavor
Apples flavor
and neither

Google said they are 'done' with supporting Apple and the neither flavor for any changes they make.

What this is is a bad merge gone horribly wrong with a bad set of internal API's to abstract these issues away.

Re:So...

[Anonymous Coward]

forking KHTML was a bad move, khtml was much better, but now webkit is edging out khtml.

Re:So...

[KugelKurt]

Part of the reason for this is that Apple is not being completely vendow neutral. They seem to be fighting some Google enhancements on somewhat 'political' grounds rather than technical. I think this is going to end up being good for everybody.

You got it the wrong way around. It was Google who refused to develop a multi-process architecture within WebKit, just as they refused to improve JavaScriptCore and instead created V8 as stand-alone project under Google-exclusive control.

Re:So...

[UnknowingFool]

Actually Apple at that time was a pretty bad FOSS citizen.

Can you recite specific cases? The situation with KHTML was when two different development models clash. Apple with its paid development team churned out a lot of code because they needed to develop a working browser (Safari) quickly. Apple first submitted changes in Jun 2002 and by Jan 2003 had Safari in beta. They didn't have a lot of time to document the code as necessary when they submitted their patches to upstream. It happens. The KHTML core developers are mostly volunteer so they work whenever they have free time; they didn't have time to review and implement all the code Apple was releasing and got further behind.

Apple has contributed to and still contributes to many open source project today. LLVM, OpenCL, Darwin, cups, Bonjour/ZeroConf, etc.

Re:So...

[Anonymous Coward]

It will support what's currently there, no telling about future extensions. Anything that kicks lazy devs in the butt is a good idea IMHO, stop writing to engines, morons.

Re:So...

[Anonymous Coward]

For a while it will support existing -webkit-* properties, but the plan is to phase them out. Which is the right thing to do.

Re:So...

[Anonymous Coward]

Wait a minute, the whining when KHTML was forked into WebKit was because Apple initially was very bad about contributing code back to the community in any useful way. Once they got their act together and started running WebKit as a much more open development process, there was a ton of development on WebKit from non-Apple devs and WebKit eventually was developed to the point it is today where it is the defacto standard rendering engine.

In short, people were mad at Apple for being assholes and once Apple wised up, it was much better for everyone.

I don't know how Google will run the Blink project. Hopefully they will continue to have an open development process (as opposed to the Android model) and code will continue to be shared between WebKit and Blink where applicable.

Re:So...

[KugelKurt]

Can you recite specific cases? The situation with KHTML was when two different development models clash.

Apple's development model at that time was behind closed doors and doing that is not good FOSS citizenship.
Another example is Apple Public Source License 1.0.

Apple has contributed to and still contributes to many open source project today. LLVM, OpenCL, Darwin, cups, Bonjour/ZeroConf, etc.

Yes, today. I was referring to Apple's initial steps into FOSS development.
Apple dropped source code under APSL unless it had no choice. Today even Apple's own developments such as Bonjour or Dispatch are released under Apache License or BSD-like licenses and other parties can easily pick them up. Apple successfully set up WebKit as vendor-neutral project, joined LLVM and contributed Clang, even became the release manager of X.org at some point, etc.

Google should have learned from Apple's past mistakes. Yet, Google somehow successfully presents itself as great FOSS citizen, despite:
The Android kernel was as much of a "uncivil" fork of Linux as WebKit was from KHTML and it took much campaigning by Greg KH and others to get Google to even start to submit and maintain the patches upstream.
Google refused to implement a multi-process architecture directly in WebKit and insisted to make it Chrome-exclusive. Same with V8: No attempt to even try to optimize WebKit's JavaScriptCore, instead insisting on adding hard to maintain bindings for V8.

Re:Good luck with that

[gstoddart]

It is a rendering engine. How many end users have even heard of webkit?

Anybody who has ever looked at their task manager and wondered WTF WebKit2WebProcess process was and why it was using so much memory.

I find it tends to try to use as much memory as it possibly can, and even if it's sitting just on a single web page over time it bloats enough that I have to exit the browser and restart it to reclaim it

I just wish Safari could actually delete cookies without that webkit process crashing. I suspect both Apple and Google would far rather I kept cookies so they could make money from me.

I'm starting to lose my patience with webkit based browsers.

Re:quid pro quo

[hkmwbz]

Chromium specific, as in, is only used when building Chromium/Chrome (that other Webkit browsers don't want or need). Not actual web standards stuff, probably. Except maybe WebGL?

I don't see how they can block hosts.. apk

[Anonymous Coward]

It operates @ the IP stack level as a filter in ring 0/rpl 0/kernelmode (not usermode/ring 3/rpl 3, like browser addons).

* It operates NO MATTER WHAT & long before browsers (let alone their addons that layer ontop of them slowing them down even more) do...

(Only way they could really do that is to alter the IP stack itself imo or the OS, unless others know otherwise, & that's NOT going to happen...)

APK

P.S.=> Again though - I am MORE concerned about Opera NOT HAVING 64-bit builds though (since Chrome doesn't) in Windows, once the "Blink/WebKit" transition 'takes hold' @ Opera...

... apk

Re:I don't see how they can block hosts.. apk

[Anonymous Coward]

When chrome wants to connect to a web site, it asks the OS to convert the name to an ip address. The OS then checks the hosts file, checks it's DNS cache, then queries the DNS server.

But Chrome could skip the OS and implement it's own DNS lookups (google run their own DNS servers)... bypassing your precious ring 0 hosts file. They could even justify it for technical reasons -- Google's DNS server blocks malware and doesn't hijack invalid domains like some ISPs do. Also, if they do the DNS lookup themselves, they'll have accurate TTL information for cache invalidation which the OS doesn't provide.

And while we're on the subject, BSD and Linux perform their name lookups in a libc (run in usermode), not in the kernel.

Re:I don't see how they can block hosts.. apk

[DirtyLiar]

It doesn't even have to do that, it could just ignore everything that returns 127.0.0.1 that isn't localhost, and only THEN query the DNS server. Or, it could keep it's own small file of Google's own ad serving addresses, and translate those into IP Addresses before the request even hits the hosts file. This would have the advantage of never allowing THEIR ads to be blocked, while allowing their competitors to be blocked.

And since most Google ads (AFAIK) are graphics and flash light, this might even be acceptable to most Chrome (and now Blink) users.

Since I actually like the free website model mostly in use today, I only ever block ads when they begin effecting my web browsing speed, browser stability, or my privacy. So, yeah, I block all flash advertising, always.

Anyone said it yet?

[Anonymous Coward]

DON'T BLINK!

Re:Anyone said it yet?

[Anonymous Coward]

Yeah, only a million times. Congratulations on your supreme dipshittery.

Re:Good

[KugelKurt]

Nobody is removing anyone's code from WebCore itself. They are only talking about now unmaintained platform adaptions. Unmaintained adaptions have always been removed. Nobody within the public even noticed when the Symbian S60 adaptations were deleted.

Amicable parting

[jayrulez]

That was an amicable parting if I've ever seen one. However, leave it to the internet peanut gallery and various religious nut jobs (i.e Google fan girls, Apple fan girls and certain other fan girls) to make a mountain out of this ant hill.

Re:Amicable parting

[UnknowingFool]

Indeed. This is what forking is supposed to do. If someone decides to take a code in another direction, they can do so as long as they meet the licensing terms.

Editors: grammar, dammit!

[Anonymous Coward]

Garen expects that developers who will be working on WebKit in the future should help to clean up the code. However, Adam Barth and Eric Seidel â" two Google WebKit developers â" have already offered their help

Garen expects everyone's help, which includes Barth and Seidel. "However" makes no sense if Barth and Seidel are going to help Garen. If they are going to help the forked version, then "have already offered their help" makes no sense.

Please, please, please, please, please take an english class!

Re:quid pro quo

[Reapman]

Wow. A comment like that from a UID much lower then mine.

Fascinating.

A major user of WebKit had submitted code for WebKit. News at 11.

True: MS does it for their sites.. apk

[Anonymous Coward]

They'd have to "bulk up" their webbrowser more to do that though, as well as circumnavigate native TCP/IP functionality - & for what?

Tracking + Advertising purposes??

(They do that, I wager this strongly - they'll LOSE users on Chrome/Chromium in doing so...).

Lastly - Per my subject-line: Microsoft bypasses hosts:

http://slashdot.org/story/06/04/16/1351217/microsoft-bypasses-hosts-file

Albeit (& iirc), for purposes that aren't along THOSE lines (tracking/advertising), but rather for Windows Update functionality to be accurate, to THEIR servers only @ certain IP addresses (iirc)... e.g.:

DomainScreenList:

  windowsupdate.microsoft.com
  windowsupdate.com
  microsoftupdate.com
  download.microsoft.com
  update.microsoft.com

  HostsScreenList:

  microsoft.com
  www.microsoft.com
  support.microsoft.com
  wustats.microsoft.com
  microsoftupdate.microsoft.com
  office.microsoft.com
  msdn.microsoft.com
  go.microsoft.com
  msn.com
  www.msn.com
  msdn.com
  www.msdn.com

APK

P.S.=> GOOGLE wouldn't have to even get as "technical" as you're stating though: They could simply use a list of servers that doesn't change on THEIR end, as the DO have the ca$h for static addresses on their servers for sure (sort of the reverse of what Opera does in its urlfilter.ini, which IS a way to block sites in it), OR even "hardcode" said IP addresses to said servers of theirs in the executable of the browser itself (not a huge trick)...

... apk

Re:Good luck with that

[Anonymous Coward]

Idiot... the video for developers, regular users will notice absolutely nothing, like they don't notice anything right now with seamless autoupdates.

Will Blink support the blink tag?

[descubes]

One has to wonder.

If it aint broken

[martijn hoekstra]

Don't fix it. Once it starts causing problems and you see no upside in maintaining, remove it. Easy as that.

Opera COULD go for another "Opera 1st"... apk

[Anonymous Coward]

A 64-bit for Windows build of a WebKit/Blink browser though, in Opera - you never know!

* :)

(That, would be cool...)

APK

P.S.=> It's not like they haven't done their share of firsts & bests in webbrowsing tech before... I'd like that one @ least + I am sure I'm not alone in that regard either (especially if they're dropping Presto which I feel is excellent personally)...

... apk