Will *any* mobile OS emerge dominant by 2015?

So... the G engineers are just beholden to anyone wanting them to do work on their behalf? WTF?

The G code is *open source*. Claiming it's political that people make code available but then don't do the work you want is ridiculous.

This whole "Apple wanted Google to do all the integration work" thing appears to have been made up out of whole cloth. Again, after being rebuffed by Google, WebKit developers went and implemented their own multiprocess architecture. If they were willing to do the work on that, there's no reason to believe they weren't willing to do the work on integrating Google's code.

Except that indicates the *logical* conclusion that trying to adopt the chromium code would be... wait for it... *too much effort*.

I brought this up before. If WebKit's engineers wanted this, and had the resources for it, AND HAD THE CODE AVAILABLE FOR IT (FFS people), then how on earth is it political (on Google's end) that the WebKit guys decided to not use the chromium code?

Occam is standing right there.

Quote:

Metasyntactic wrote:

I don't think you understand. Why would google need to "give them the go ahead"?

That very statement doesn't make sense.

It only doesn't make sense if you focus entirely on what the license permitted and completely ignore the collaborative relationships surrounding WebKit.

The collaborative relationship is *precisely* that if WebKit wanted to do this, they could do it. That's precisely why chromium made this source open. That's precisely why the platform layer work *exists* FFS.

Quote:

Megalodon wrote:

-You say using it without permission would have scuttled the collaboration. The fork does that with far greater certainty. Meaning the barrier to using multiprocess code is reduced according to how you say things work, not increased.

This only makes sense if you take Google at its word that a fork was necessary because maintaining support for two multiprocess models was technically infeasible.

The onus is on you to show it's not. You have engineers saying it was more effort than they were willing to invest in. You have to show that that's not the case. Here's a hint *you can't*. Why? Because Google simply may have had all the engineers locked up in work they considered more important. They may literally have had no time in their schedules. Thus, if there was *any* cost to this (which you must accept that there is), then it would be reasonable on a *technical* level for G to find this work too costly.

It's not my position that Google is forking now to deny multiprocess support to WebKit. It's my position that Google is forking now to wield more power over the future of the web, and the entire multiprocess issue, which Google has used to claim the fork is purely technical, is a red herring.

"The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, 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—right off the bat."

Right. It's a red herring. I'm really curious what open source projects you work on. Because your ability to just disregard completely reasonable explanations *which i say as a person with a ton of experience in this realm* is absolutely baffling.

Quote:

It's my position that Google is forking now to wield more power over the future of the web

How on earth does that hold? They already have Chrome FFS. They already have V8. They already have tons of people involved in the W3C and whatnot. What power do they not already have? What do they gain in the power dept by doing this?

-You say using it without permission would have scuttled the collaboration. The fork does that with far greater certainty. Meaning the barrier to using multiprocess code is reduced according to how you say things work, not increased.

This only makes sense if you take Google at its word that a fork was necessary because maintaining support for two multiprocess models was technically infeasible. If you don't buy that, then the situation is that while using the code over the objections of its authors would have likely scuttled collaboration, creating an alternate multiprocess model allowed continued collaboration.

This is the kind of nonsense that people who aren't developers say when they try to talk about a complex software project without really knowing anything about software. A fork is never "necessary". The entire concept of necessity does not apply in this context. One can always work in the existing framework. One can always work outside of it. Both options, neither are ever necessary nor impossible.

Instead a fork is about trade offs. You trade off between the costs of working within an existing software framework versus the costs associated with going it alone. Once the costs of going it alone become much lower then working within, you should probably fork. This is just basic software engineering.

But I guess if you're someone on the outside who doesn't really know how software or computers work, this kind of logic doesn't really make sense. There is no reason for someone to assume a priori that computers work in any particular way, so I can see how someone like ZnU might think that the rest of us are trying to fool him. From his point of view, his logic is sound. The only problem is that his point of view is basically with his head burred in the sand

It's not my position that Google is forking now to deny multiprocess support to WebKit. It's my position that Google is forking now to wield more power over the future of the web, and the entire multiprocess issue, which Google has used to claim the fork is purely technical, is a red herring.

"The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, 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—right off the bat."

Right. It's a red herring. I'm really curious what open source projects you work on. Because your ability to just disregard completely reasonable explanations *which i say as a person with a ton of experience in this realm* is absolutely baffling.

Hes not a programmer. He does this all the time though, whatever people are talking about he makes up some silly idea and then posts the way he imagines it works. Search this forum his thoughts on RF design or parallel processing if you want some particularly hilarious examples of him pretending to be knowledgeable. Its good for a laugh.

In real life he probably has some boring, mid-tier graphics, design or IT job sitting in front of a PC all day.

Right. It's a red herring. I'm really curious what open source projects you work on.

Catching on, eh?

This is the guy who also thought that Google's cloud services were such a big threat (about a year or two back) that the open source crowd should abandon Android phones (lest it somehow help this weirdo, nonexistent threat -- something about a loss of autonomy that couldn't actually occur) and use jail broken Apple phones instead as the alternative. That's right, open source people should use jail broken phones. All for a threat that made no sense.

He hasn't had a clue about open source for a very long time, but he never admits to it.

And, once he gets a wrong idea in his head, it is remarkably difficult to remove. I think he'd argue with Einstein about relativity were it possible.

Wow, a lot of discussion of what seems to be a pretty straight-forward decision.

Google has limited resources; working with the WebKit project was adding additional work; breaking off into a new project speeds up development.

Simple, non-complicated, etc.

I'd expect a bigger discussion to be about the benefits of open source when a single company is the dominant contributor, i.e. in this case it seems limited. However, it's hardly a failure for open source, as the marginal cost of porting a Chromium feature into WebKit is doubtless smaller than the cost of writing the feature from scratch.

Except that indicates the *logical* conclusion that trying to adopt the chromium code would be... wait for it... *too much effort*.

I brought this up before. If WebKit's engineers wanted this, and had the resources for it, AND HAD THE CODE AVAILABLE FOR IT (FFS people), then how on earth is it political (on Google's end) that the WebKit guys decided to not use the chromium code?

Occam is standing right there.

You're speculating based on general principles despite the presence of more specific information.

Metasyntactic wrote:

The onus is on you to show it's not. You have engineers saying it was more effort than they were willing to invest in.

We have Google making self-serving statements, and you ignoring comments by a WebKit developer that call them into question.

Metasyntactic wrote:

You have to show that that's not the case. Here's a hint *you can't*. Why? Because Google simply may have had all the engineers locked up in work they considered more important. They may literally have had no time in their schedules. Thus, if there was *any* cost to this (which you must accept that there is), then it would be reasonable on a *technical* level for G to find this work too costly.

This is a move with extremely significant strategic implications, and you want everyone to blindly accept that a company with Google's massive resources made it purely to save some developer effort. It's simply not credible.

Metasyntactic wrote:

How on earth does that hold? They already have Chrome FFS. They already have V8. They already have tons of people involved in the W3C and whatnot. What power do they not already have? What do they gain in the power dept by doing this?

They can now make arbitrary changes to the world's most commonly used browser engine with effectively zero regard for other stakeholders.

redleader wrote:

But I guess if you're someone on the outside who doesn't really know how software or computers work, this kind of logic doesn't really make sense. There is no reason for someone to assume a priori that computers work in any particular way, so I can see how someone like ZnU might think that the rest of us are trying to fool him. From his point of view, his logic is sound. The only problem is that his point of view is basically with his head burred in the sand

Dude, I write code. Your patronizing bullshit is not a substitute for an argument. If Google didn't have a history of engaging in self-serving behavior while cloaking itself if openness, I might be more inclined to believe this justification.

ZeroZanzibar wrote:

This is the guy who also thought that Google's cloud services were such a big threat (about a year or two back) that the open source crowd should abandon Android phones (lest it somehow help this weirdo, nonexistent threat -- something about a loss of autonomy that couldn't actually occur) and use jail broken Apple phones instead as the alternative. That's right, open source people should use jail broken phones. All for a threat that made no sense.

What is this, patronizing nonsense day? You're effectively lying about the position I took in that argument, which you've now raised twice over the last several days in unrelated contexts. Here is a handy link to essentially every post I've made on the threat Google's vision for the future of computing poses to end user autonomy. I skimmed through it when you raised this issue a couple of days ago, and I stand by all of it.

One of the most important open source projects in the world, and a key enabling technology for the web, is now controlled by a company with a business model designed around centralizing personal computing on its servers so that user behavior and user data can be better mined to sell ads. And a bunch of open source advocates are cheering it on, and calling me clueless for asking if maybe this might not be such a great idea.

But I guess if you're someone on the outside who doesn't really know how software or computers work, this kind of logic doesn't really make sense. There is no reason for someone to assume a priori that computers work in any particular way, so I can see how someone like ZnU might think that the rest of us are trying to fool him. From his point of view, his logic is sound. The only problem is that his point of view is basically with his head burred in the sand

Dude, I write code.

Not even going to call yourself a programmer, let alone answer the question. Just "I write code".

"The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, 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—right off the bat."

Incidentally, there's no way that this is all related to supporting two multiprocess architectures, which is what you seem to be attempting to imply.

"The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, 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—right off the bat."

Incidentally, there's no way that this is all related to supporting two multiprocess architectures, which is what you seem to be attempting to imply.

Your expert opinion based on years of software engineering experience!

Not even going to call yourself a programmer, let alone answer the question. Just "I write code".

Is that what Excel jockeys call it these days? "Coding"?

Adorable.

I wear too many hats to sensibly call myself a "programmer". But don't think I've actually used a computer with Excel installed on it in about a decade.

Essentially, this comes down to one thing. Google has just made a move with major strategic implications, and is asking people to believe it was made with no regard for those implications. This is simply not credible on its face, and I am entirely certain that had Apple made this move, these forums would be rampant with wild speculation about their ulterior motives.

I'm not arguing that this split won't allow both codebases to be simplified. I'm simply arguing that it's horribly naive to believe that's all this was about.

redleader wrote:

Your expert opinion based on years of software engineering experience!

Oh, please. You don't actually believe supporting two multiprocess architectures involved seven additional build systems and 4.5 million lines of code. There are a lot of optional features in the codebase which aren't necessarily enabled in any given implementation; I suspect these numbers are for Google stripping out everything that's not used in Chrome, not just the code supporting WebKit2's multiprocess architecture.

Except that indicates the *logical* conclusion that trying to adopt the chromium code would be... wait for it... *too much effort*.

I brought this up before. If WebKit's engineers wanted this, and had the resources for it, AND HAD THE CODE AVAILABLE FOR IT (FFS people), then how on earth is it political (on Google's end) that the WebKit guys decided to not use the chromium code?

Occam is standing right there.

You're speculating based on general principles despite the presence of more specific information.

The onus is on you to show it's not. You have engineers saying it was more effort than they were willing to invest in.

We have Google making self-serving statements, and you ignoring comments by a WebKit developer that call them into question.

*Where* did i ignore the comments? I *directly* responded *on point* to the comments *numerous* times.

Indeed, my first foray into the discussion was to *directly* respond to the comments by that developer. I have done this *numerous* times.

YOUAREFULLOF****.

I'm not sure how much clearer i can be. I have done literally the *opposite* of what you're saying, and the posts are absolutely clear on this. For you to claim otherwise is absolute bullshit.

Quote:

Metasyntactic wrote:

You have to show that that's not the case. Here's a hint *you can't*. Why? Because Google simply may have had all the engineers locked up in work they considered more important. They may literally have had no time in their schedules. Thus, if there was *any* cost to this (which you must accept that there is), then it would be reasonable on a *technical* level for G to find this work too costly.

This is a move with extremely significant strategic implications, and you want everyone to blindly accept that a company with Google's massive resources made it purely to save some developer effort. It's simply not credible.

WTF? This sort of conversation goes on on a *daily* basis on all the work i've ever done as an engineer. We make those sorts of engineering calls *all the fucking time*. It is credible because it's how development actually fucking works.

Quote:

Metasyntactic wrote:

How on earth does that hold? They already have Chrome FFS. They already have V8. They already have tons of people involved in the W3C and whatnot. What power do they not already have? What do they gain in the power dept by doing this?

They can now make arbitrary changes to the world's most commonly used browser engine with effectively zero regard for other stakeholders.

THEY HAD CHROME AND CHROMIUM ALREADY. Do you not understand that?

Quote:

redleader wrote:

But I guess if you're someone on the outside who doesn't really know how software or computers work, this kind of logic doesn't really make sense. There is no reason for someone to assume a priori that computers work in any particular way, so I can see how someone like ZnU might think that the rest of us are trying to fool him. From his point of view, his logic is sound. The only problem is that his point of view is basically with his head burred in the sand

Dude, I write code. Your patronizing bullshit is not a substitute for an argument. If Google didn't have a history of engaging in self-serving behavior while cloaking itself if openness, I might be more inclined to believe this justification.

So this is argument by handwaving then? Literally: "i don't trust them, so there must be something more here"?

Quote:

One of the most important open source projects in the world, and a key enabling technology for the web, is now controlled

"The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, 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—right off the bat."

Incidentally, there's no way that this is all related to supporting two multiprocess architectures, which is what you seem to be attempting to imply.

?

It shows the effort involved in trying to support the different codebases. Hence backing up the idea that *forking* is actually technically motivated.

Essentially, this comes down to one thing. Google has just made a move with major strategic implications, and is asking people to believe it was made with no regard for those implications.

Given that their reasoning actually fits the situation, and *what we know of Open Source development* what are we supposed to believe? Are we just firmly in tin foil hat land? We can't prove there's no conspiracy... So there's a conspiracy?

Quote:

This is simply not credible on its face,

Why not? It fits the actual facts at hand.

Quote:

and I am entirely certain that had Apple made this move, these forums would be rampant with wild speculation about their ulterior motives.

I do not give a shit about your random ass speculation about the unfairness of how people treat G or A. I am responding to this issue purely with the technical expertise i have from working on open source projects and knowing how they're run. This speculation is purely specious.

Quote:

I'm not arguing that this split won't allow both codebases to be simplified. I'm simply arguing that it's horribly naive to believe that's all this was about.

Then what was it all about? Again, what power does this give google that they didn't ALREADY f'ing have?

Yes. I believe that supporting two massive projects with teh complexity of (all of) WebKit and Chromium would absolutely involve that.

You know why? Because i have first hand experience here and i know just how fucking complicated it is.

Quote:

There are a lot of optional features in the codebase which aren't necessarily enabled in any given implementation; I suspect these numbers are for Google stripping out everything that's not used in Chrome, not just the code supporting WebKit2's multiprocess architecture.

Duh.

Multiprocess was probably just the largest and most complex portion of the architecture. By doing the split fully they can just throw out everything they need wholesale. From an engineering perspective that is enormously enticing.

Indeed, in my current work we're discussing *precisely* the same thing. And it comes down to entirely an engineering cost. How much do we save long term given the short term investment to break off and do things ourselves.

You're fucking unbelievable. I've actually defended my position with logical arguments as to why his position is nonsensical, and you outright come out and say that i'm just ignoring him. What the fuck is wrong with you?

[/quote]I don't have any idea what the PR machine actually said. I'm basing this on the facts of the matter (including how open source actually works). You seem completely ignorant of this topic, and it's mindboggling how that ignorance translates to you actually disregarding how engineering actually works to satisfy your conspiracy theory that there must be something deeper behind this decision.

As an engineer it's deeply frustrating seeing this sort of behavior. It's not uncommon when dealing with people who don't know how large scale project work, and it's highly aggravating when people make blatant assumptions and just handwave away logical and rational explanations for why decisions are made.

If you want this sort of BS crap, then go to /.

--

Note: I originally entered the BF a long time ago because this sort of posting was depressingly common. I can't count how many times i ended up having to just explain how engineering worked to people just completely divorced from reality. And i also can't count how many times people would just disregard it in their quest to find *something* bad to get in a huff over. Things had been nice for the last year or so. Technical expertise here was actually quite high, and most of the discussion related to the relative merits of business decisions between the large players.

I got involved here because i was seeing the same crap from before. People pontificating about engineering and presuming a deeper ulterior motive, despite the evidence to the contrary. If you want to have your conspiracy theories, go right ahead. Just couch them in "well, i have no evidence, but i just don't trust them". Don't pull out shit like: "this is simply not credible on its face," when actual engineering experience tells you *precisely* that it is credible.

*Where* did i ignore the comments? I *directly* responded *on point* to the comments *numerous* times.

Your invocation of Occam implies that there is no data that cannot be explained by Google making purely technical decisions, but Google's apparent antipathy toward the idea of the WebKit project borrowing Chromium's multiprocess model does not look like a technical decision.

Metasyntactic wrote:

WTF? This sort of conversation goes on on a *daily* basis on all the work i've ever done as an engineer. We make those sorts of engineering calls *all the fucking time*. It is credible because it's how development actually fucking works.

You're claiming superior knowledge by claiming this decision is similar to decisions you regularly make. But I seriously doubt you regularly make decisions about whether major tech companies will fork large, strategically significant open source projects. This is precisely the point of contention here. You (and Google) are trying to portray this as a routine technical decision, but it's extremely naive to think things work that way at this level.

Metasyntactic wrote:

THEY HAD CHROME AND CHROMIUM ALREADY. Do you not understand that?

Look, obviously Google has always previously had the power to do whatever they wanted with the relevant code, because they've always had the power to fork. But when they were committed to remaining part of the WebKit project, they had to take other stakeholders into account in order to be able to continue to remain part of the WebKit project. Now they've declared they no longer have any interest in this.

More succinctly, Google has always had the option to say "we don't care what anyone else thinks", but now they've actually said it.

Metasyntactic wrote:

Note: I originally entered the BF a long time ago because this sort of posting was depressingly common. I can't count how many times i ended up having to just explain how engineering worked to people just completely divorced from reality. And i also can't count how many times people would just disregard it in their quest to find *something* bad to get in a huff over. Things had been nice for the last year or so. Technical expertise here was actually quite high, and most of the discussion related to the relative merits of business decisions between the large players.

Unless you are substantially more familiar with the Chromium and WebKit codebases than you have thus far indicated, all you can say on the basis of your general knowledge is that a fork might be technically advantageous. But nobody disputes that. My argument is that it's naive to think the strategic implications of this were simply incidental. That's essentially a point about politics and corporate strategy. Are you an expert there as well?

You're fucking unbelievable. I've actually defended my position with logical arguments as to why his position is nonsensical, and you outright come out and say that i'm just ignoring him.

You're not outright ignoring him, you're just dismissing his account as a data point requiring explanation by making nonsensical arguments based on unsupported claims — namely the claim that the WebKit project demanded Google engineers do all of the integration work. Something he explicitly says was not the case.

No amount of rolleyes changes the fact that Google didn't submit the code back to the WebKit project. Since they submitted a hell of a lot of code to WebKit it's clear they didn't submit it because they wanted it for themselves. If this was any other company than Google their refusal to commit would be seen for exactly what it is.

redleader wrote:

DR. M wrote:

I am unaware of a history in the open source movement of one project willy-nilly highjacking the work of another project.

Linux -> Android?BSD -> OSX/iOS?

Seriously, this is so stupid in the context of a mobile operating system thread its incredible.

Let's get one thing clear I am not criticizing Google for forking the project.

Those are forks. How much rummaging around do the Linux maintainers do in the Android code base. How much of the Darwin code base is wholesale lifted into the FreeBSD code. There are somethings Apple submits to FreeBSD and I'm sure the FreeBSD guys are happy for the code, but I don't think they are crying over the things Apple keeps to itself. The same is true of WebKit I'm sure Apple was happy for the commits Google made but they were not going to take code that wasn't submitted to them.

redleader wrote:

I actually asked some of the Chromium open source people about this a couple months ago, and their answer is that they disliked the way the Safari implementation worked when combined with how they'd designed Chrome. They said that it had been easier to just develop their own system then try and hack the existing one into what they were already doing..

By Safari did they mean WebKit or WebCore? I watch the Q/A I don't question that the Google guys have their own ideas and want to feel free to pursue them. I say more power to them I wish them luck as someone that uses Chrome everyday.

However that doesn't change the fact that they didn't submit the code back to WebKit. That doesn't change the fact that when Apple asked if they could use the code Google gave them a non-answer at best. Apple of all companies can't take the high road when it comes to keeping code to themselves. So it makes sense that they would respect the signals they got from Google.

You're fucking unbelievable. I've actually defended my position with logical arguments as to why his position is nonsensical, and you outright come out and say that i'm just ignoring him.

You're not outright ignoring him, you're just dismissing his account as a data point requiring explanation by making nonsensical arguments based on unsupported claims — namely the claim that the WebKit project demanded Google engineers do all of the integration work. Something he explicitly says was not the case.

This Apple wanted Google to do all the work BS would be far more believable if Google did in fact submit the code and the Apple engineers did nothing with it. He goes on about Occam's razor and gives no reason why Apple would start being a poor steward of the WebKit project.

What's going to matter, for the purposes of this thread, is whether WebKit or Google's fork is going to be well- supported.

Will either iOS or Android browsers become second citizens on a lot of sites in a couple of years?

Both Apple and Google have the resources to maintain a modern browser, and both likely understand the strategic importance of not falling behind. But the question is, what constitutes 'falling behind', exactly? Now that this split has occurred, the potential exists for each party to try to take the web in whatever direction favors its strategic interests — and Google and Apple appear to have very different strategic interests. It doesn't seem impossible that we might end up in a world where Google and Apple refuse to implement some of each other's features not because they don't have the resources to do so, but because they believe those features disadvantage them in the marketplace.

I'm more concerned about Google here than Apple, because a) I view Google's business model, based as it is on data collection, as inherently more problematic for consumer interests, b) the web is simply of more strategic relevance to Google than to Apple, and c) Google is the party that initiated this split.

What's going to matter, for the purposes of this thread, is whether WebKit or Google's fork is going to be well- supported.

Will either iOS or Android browsers become second citizens on a lot of sites in a couple of years?

For now it looks like Google will own the desktop and Apple will own mobile. So I think both will be well supported for some time to come, we should all hope neither side tries something stupid to _control the web_. I'm curious as to whether Apple is going to make Safari again for windows.

*Where* did i ignore the comments? I *directly* responded *on point* to the comments *numerous* times.

Your invocation of Occam implies that there is no data that cannot be explained by Google making purely technical decisions, but Google's apparent antipathy toward the idea of the WebKit project borrowing Chromium's multiprocess model does not look like a technical decision.

I literally have no idea what that means. So you're telling me if i say "the work is too complex and i'm busy doing other things", then that's not a *technical decision*?

Quote:

Metasyntactic wrote:

WTF? This sort of conversation goes on on a *daily* basis on all the work i've ever done as an engineer. We make those sorts of engineering calls *all the fucking time*. It is credible because it's how development actually fucking works.

You're claiming superior knowledge by claiming this decision is similar to decisions you regularly make. But I seriously doubt you regularly make decisions about whether major tech companies will fork large, strategically significant open source projects.

You are incorrect. I have worked in positions where i made *precisely* these decisions. And i've made them *entirely* on technical grounds.

You're fucking unbelievable. I've actually defended my position with logical arguments as to why his position is nonsensical, and you outright come out and say that i'm just ignoring him.

You're not outright ignoring him, you're just dismissing his account as a data point requiring explanation by making nonsensical arguments

1) My position is *not* nonsensical.

When i point the actual technical situation it is the very opposite of *nonsensical*.

Quote:

based on unsupported claims

Wut? What claims have i not supported? Heck, i've either being using factually true unarguable data point (like the nature of the chromium or webkit projects), or completely reasonable inferences on top of them (like: WTF would *Google* do the work for the WebKit guys instead of the WebKit guys doing it?)

Quote:

— namely the claim that the WebKit project demanded Google engineers do all of the integration work. Something he explicitly says was not the case.

Already addressed, like 10 times.

He can say something. If it doesn't make any *sense* then what he says is *irrelevant*.

It's like me saying that Linus stopped me from adopting code from Linux in my own project because when i asked him if he'd do the coding, he said 'no'. It's an utterly specious perspective.

No amount of rolleyes changes the fact that Google didn't submit the code back to the WebKit project.

Right. WHY WOULD THEY NEED TO?

Do you not get how open source works? If WebKit wants to use G's multiprocess implementation, then it behooves *them* to do that. G already made all the code. They already made the code open. They even doc'ed the code. They even put the code out there on the web for *anyone to take* (as long as they follow'ed the license). Why the fuck would G need to do anything else?

Do you honestly have no idea how open source projects work?

The onus is on the people who *want* the work done to figure out how to get it done. So, if G really wanted it in WebKit, then G would have to make it happen. But if the WebKit guys wanted it to happen, then *they* need ot make it happen.

Otherwise, we'd have an entirely non-functioning world where any random project would say "yo, i like feature X of your project, you should submit it to us".

What's going to matter, for the purposes of this thread, is whether WebKit or Google's fork is going to be well- supported.

Will either iOS or Android browsers become second citizens on a lot of sites in a couple of years?

Both Apple and Google have the resources to maintain a modern browser, and both likely understand the strategic importance of not falling behind. But the question is, what constitutes 'falling behind', exactly? Now that this split has occurred, the potential exists for each party to try to take the web in whatever direction favors its strategic interests — and Google and Apple appear to have very different strategic interests. It doesn't seem impossible that we might end up in a world where Google and Apple refuse to implement some of each other's features not because they don't have the resources to do so, but because they believe those features disadvantage them in the marketplace.

Wut?

"Now that this split has occurred"

What on earth are you thinking? This ability has *always* existed. It existed before the split. It exists after the split.

That's why you have *two* projects in the first place and not *one* project.

"It doesn't seem impossible that we might end up in a world where Google and Apple refuse to implement some of each other's features"

???

Wut?

That world exists *today*. Both companies decide which features are important to implement, and both/either may choose not to implement something that the other did. Nothing about this decision changes that.

BTW, i get the sense that you guys have absolutely no idea how hte chromium or webkit projects are actually structured or maintained.

You are literally making statements that do not jive with the blatant reality that is right there and easily verifiable.

Like, you know you can actually look at all this source now right? You can see how chromium is built. You can see how it currently includes WebKit right? You can see how it already ends up not using huge swaths of webkit because they already have their own implementation for things (like V8) right?

It's like you guys think Chrome/Chromium is just this thin wrapper around the entirety of the WebKit project (and not just WebCore).

This is basic stuff, and it's amazing how much we can reason about it *given that hte technical aspects of both projects are transparent and available for our own perusal*. It's honestly painful having to point this out.

BTW, i talked to one of my buddies who is a dart dev. He mentioned a bunch of areas where this enables things that he's wanted to do, but hasn't because of WebKit issues. Specifically, they've wanted to make changes that would affect the WebKit abi as well as significant architectural areas. However, those sorts of changes wouldn't be allowed because of the breakage it would cause to all sorts of projects that integrate WebKit.

For example, a huge area for him is the networking code. He's wanted WebKit's networking code to be made much much simpler. However, they've been unable to do this because of API compat. **

At the end of the day both projects have different technical requirements. WebKit seems to value back compat (of their own API) more. This makes sense given how many products out there embed it. However, these same compat concerns limit improvements in technical areas that G seems to care about (especially around performance). Forking enables G to make these positive technical changes without having to deal with constraints of the WebKit project.

--

** Other areas they wanted to work on included reducing a large number of bugs and complexity around having a browser with support for multiple scripting engines (something which will also make the lives of the WebKit guys easier as well). Also mentioned were large architectural changes to things like layout (including making is much more parallelizable). These sorts of large architectural changes would be tremendously difficult in webkit *especially* because they'd also need to be concerned with all the downstream consumers.

As someone who has done a lot of work with OSS, i can attest to how much of a technical impact this can have on a project. Your costs increase and increase and increase with all these downstream consumers, and that can very much be a limiting factor on being able to make the changes you're interested in.

The onus is on the people who *want* the work done to figure out how to get it done. So, if G really wanted it in WebKit, then G would have to make it happen. But if the WebKit guys wanted it to happen, then *they* need ot make it happen.

Err, no. When you take an existing open source project, the Linux kernel, Apache, or Webkit, and make changes that _you want to be part of the future direction of that project_, you don't dump your changes in the public domain and say "Here, this is what we changed, you figure it out." You make the effort to feed your changes back upstream with small, well documented patches. If your changes make sense and are desired by the community, they get included in the upstream.

Linus has in the past told people to GTFO for submitting big blobs of changes and expecting it to be merged. It's completely the wrong way to go about getting your work into the main source tree.

Quote:

Otherwise, we'd have an entirely non-functioning world where any random project would say "yo, i like feature X of your project, you should submit it to us".

But this is not what happened is it? Google took something that already existed, modified it, then refused to submit it back to the main in a form anyone could use. You'd be right if Google had taken the Mozilla engine, added per-process support, and the Webkit guys said "Hey! We'd like that too! Please make it work for us.", but that's not what happened here. Google took Webkit, and then didn't work with the community to feed their changes back upstream.

I literally have no idea what that means. So you're telling me if i say "the work is too complex and i'm busy doing other things", then that's not a *technical decision*?

No evidence has been offered that this is what occurred. And again, given that WebKit developers were evidently willing to implement their own multiprocess model from scratch, it seems unlikely that they'd have demanded Google to do all of the work migrating the Chromium model to WebKit.

Metasyntactic wrote:

You are incorrect. I have worked in positions where i made *precisely* these decisions. And i've made them *entirely* on technical grounds.

There are only a handful of projects in the world with WebKit's strategic significance. There are likely, at best, a few dozen people who have been in a position to make significant decisions with respect to them on behalf of major technology companies that fund development of them. You're probably not one of them.

Metasyntactic wrote:

Already addressed, like 10 times.

Where? Seriously. I see lots of argument relying on the premise that WebKit developers demanded Google do all the work, but no demonstration that this premise is true.

Metasyntactic wrote:

That world exists *today*. Both companies decide which features are important to implement, and both/either may choose not to implement something that the other did. Nothing about this decision changes that.

You're attacking a straw man here. It's not that I think this fork changes everything overnight; it's that I think this fork clarifies Google's past behavior and future intent.

Metasyntactic wrote:

BTW, i talked to one of my buddies who is a dart dev. He mentioned a bunch of areas where this enables things that he's wanted to do, but hasn't because of WebKit issues. Specifically, they've wanted to make changes that would affect the WebKit abi as well as significant architectural areas. However, those sorts of changes wouldn't be allowed because of the breakage it would cause to all sorts of projects that integrate WebKit.

This is actually an interesting case, because it's rather debatable whether the fact that WebKit was retarding Google's attempts to unilaterally deploy its own new language on the browser was a bug or a feature. Enough of this stuff, and Chrome will evolve into something more like a Google-controlled middleware platform than a traditional browser. Having already created a fork over which it has essentially sole de facto control, there are no longer significant barriers to Google moving in this direction.

The onus is on the people who *want* the work done to figure out how to get it done. So, if G really wanted it in WebKit, then G would have to make it happen. But if the WebKit guys wanted it to happen, then *they* need ot make it happen.

Err, no. When you take an existing open source project, the Linux kernel, Apache, or Webkit, and make changes that _you want to be part of the future direction of that project_, you don't dump your changes in the public domain and say "Here, this is what we changed, you figure it out."

Wuh?

Again, it was the *WebKit* guys who wanted the capabilities provided by *Chromium*. You have things backward.

Quote:

You make the effort to feed your changes back upstream with small, well documented patches.

Says who?

That's what you do if you think it's *worth the technical effort*. Because if you go that route, you are now signed up to ensure all the effort to meet that project's requirements.

If that effort is too high, or you aren't interested in the same goals as that project (for example, supporting all the downstream consumers of webkit) then that's *not* what you do.

That's why forks fucking exist FFS.

Quote:

Linus has in the past told people to GTFO for submitting big blobs of changes and expecting it to be merged. It's completely the wrong way to go about getting your work into the main source tree.

You have it *backward*. That would be the case if someone was asking linus to include something in *linux*. I'm bringing up the case where Linux has something *i* want and i ask him to do the work to integrate it into *my* project.

You have the actors and the responsibilities completely ass backward.

Quote:

Quote:

Otherwise, we'd have an entirely non-functioning world where any random project would say "yo, i like feature X of your project, you should submit it to us".

But this is not what happened is it? Google took something that already existed, modified it, then refused to submit it back to the main in a form anyone could use.

No. That's not what happened at all. Google did *precisely* what you do with FOSS. They took it, modified it, and made it available. *Precisely* what open source asks for. Open Source never asks that you "submit it back to the main in a form anyone could use."

FFS, where did you get that idea?

What you have here are the WebKit guys going "oh wow... that would be useful. Can you merge it back into WebKit" and the G guys going "nope." at which point the WebKit guys can do what all FOSS projects can do... wait for it... MERGE IT BACK THEMSELVES.

Quote:

Google took Webkit, and then didn't work with the community to feed their changes back upstream.

Right. Precisely. No one is arguing otherwise. And the reason they didn't do it was... wait for it... it was too technically involved. Just like they said.

I literally have no idea what that means. So you're telling me if i say "the work is too complex and i'm busy doing other things", then that's not a *technical decision*?

No evidence has been offered that this is what occurred.

It is the only sensible explanation given what we know about these projects. Literally the only one. All the other explanations make no sense given how FOSS projects work.

Which is more likely... let's think about this with a modicum of logical thought:

1) This code was not merged back into webkit because:a) google somehow exercised some non political power to prevent it from happening.b) google exercised the technical power to not do the work involved.

Which is more likely? Hrmm?

How could it be 'a'? G has no such power. That's the virtue of FOSS. But could it be 'b'? Absolutely. G just said "yeah, we're not doing that work. we've got enough of our own work on our own project to concern us. Do it yourself. There's all the code".

One actually fits the nature of the situatoin, one is completely F'ing ludicrous.

Quote:

And again, given that WebKit developers were evidently willing to implement their own multiprocess model from scratch,

Gee... makes one think... perhaps trying to merge the chromium approach was... wait for it... technically unfeasible![quote it seems unlikely that they'd have demanded Google to do all of the work migrating the Chromium model to WebKit.[/quote]Why? They asked for it. Chromium guys said "no", so webkit guys had no choice. It fits perfectly.

Quote:

Metasyntactic wrote:

You are incorrect. I have worked in positions where i made *precisely* these decisions. And i've made them *entirely* on technical grounds.

There are only a handful of projects in the world with WebKit's strategic significance.

And?

Quote:

There are likely, at best, a few dozen people who have been in a position to make significant decisions with respect to them on behalf of major technology companies that fund development of them.

That's not true. I would estimate the number at several thousand based on my direct experience.

Quote:

Metasyntactic wrote:

Already addressed, like 10 times.

Where? Seriously. I see lots of argument relying on the premise that WebKit developers demanded Google do all the work, but no demonstration that this premise is true.

Are you kidding me? You're taking the piss aren't you?

"Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no."

It's right there in black and fucking white. They asked Google to do the work. They wanted Google to do the contribution back to webkit (his FUCKING words). And Google declined to do that work.

You literally must be taking the piss. This is in the hackernews post *you* posted.

Quote:

Metasyntactic wrote:

That world exists *today*. Both companies decide which features are important to implement, and both/either may choose not to implement something that the other did. Nothing about this decision changes that.

You're attacking a straw man here. It's not that I think this fork changes everything overnight; it's that I think this fork clarifies Google's past behavior and future intent.

And, again, what about hte existing world prevented any of that inferred intent?

Quote:

Metasyntactic wrote:

BTW, i talked to one of my buddies who is a dart dev. He mentioned a bunch of areas where this enables things that he's wanted to do, but hasn't because of WebKit issues. Specifically, they've wanted to make changes that would affect the WebKit abi as well as significant architectural areas. However, those sorts of changes wouldn't be allowed because of the breakage it would cause to all sorts of projects that integrate WebKit.

This is actually an interesting case, because it's rather debatable whether the fact that WebKit was retarding Google's attempts to unilaterally deploy its own new language on the browser was a bug or a feature.

It's an engineering decision. I have no idea what you mean by "new language", but it's up to G to make the engineering call. Note: this was quite common. It came down to things like:

"Well, if we do it ourselves, it'll make things X% faster, but then we'll have to invest those engineering resources."

This was precisely behind several of the discussions around things like V8.

And it's definitely a bug if a company can't take an open source project, provide value on it if they're abiding by its license.

It's not a feature for G not to be able to provide a better javascript engine if they want. or a faster networking layer. Etc. etc.

Quote:

Enough of this stuff, and Chrome will evolve into something more like a Google-controlled middleware platform than a traditional browser. Having already created a fork over which it has essentially sole de facto control, there are no longer significant barriers to Google moving in this direction.

Thank you for finally agreeing with. You get that this i a technical issue. You have *admitted* there were "significant barriers" involved in Google being able to make the technical changes they wanted to do.

You just admitted that the prior state of affairs there were "significant barriers" to Google taking the browser and doing what it wanted with them, then... tada... guess what? You're agreeing with exactly what they and I have been saying.

There were significant barriers and getting around them wasn't worth the engineering effort.

As others have said this is *EXACTLY* the moment at which you fork. The moment when the drawbacks of trying to work with the existing project becomes more costly than doing it yourself is the moment that you *FORK*.

Tada. You've just made an engineering decision based on technical merit for an open source project. Hoorah. We'll make a dev out of you one of these days!

I love that we now exist in a world whereby if someone asks you to do work for them and you tell them "no, it's too much effort" that is now an example of internalized politics.

Methinks that some people here view everything from a political lens. OMG, something in the tech sphere happened between Company A and Company B, it must be political! It simply is not feasible that a decision be possibly made on technical merit. Nope... no siree...

Whether an action was substantially political is of course an empirical question. As you're aware, absence of evidence isn't evidence of absence. I don't mean any personal offense by this, but to me you simply don't spend enough time weighing the non-technical aspects to lend your impressively ferocious counter-argument sufficient breadth.

Whether an action was substantially political is of course an empirical question. As you're aware, absence of evidence isn't evidence of absence.

And, as you're aware. The onus is on those making the claim to provide actual evidence to show that it's true. You're right i can't provide a negative. But i can show ample enough evidence and other examples to demonstrate why the technical explanation is the most likely.

At the end of the day it could be neither after all. It could be little green martians manipulating all of us into being distracted by these matters while they work their way toward invasion. We can't prove it's *not* happening. After all, absence of evidence of little green martians is not evidence that it's not really little green martians after all.

Quote:

You simply don't spend enough time weighing the non-technical aspects

Ah. The fox news approach. I'm not fair and balanced because to be fair and balanced means giving equal weighting to both sides, even if one side carries almost no weight at all (and, as you said, has no evidence for it), while the other side has ample evidence.

Clearly, i should spending more time weighing the impressive arguments put forth by Znu. But perhaps you could better help direct my time by pointing out a single argument put forth that i haven't weighed enough and haven't provided enough counter evidence against. I will happy weigh that part again and see if i come to a different conclusion.

See, here's where you lost me. Someone is coming and making a claim that a certain event *must* be political. I've listened and pointed out that for every aspect they've called out that there is not only a normal technical explanation for the situation, but a *likely* explanation. The explanations i've put forth fit the facts of the situation, and are in line with commensurate situations *elsewhere*.

On top of this, the person putting forth the position that this *must* be political has even admitted *flat out* that there are indeed technical issues with the previous situation that could have been affecting google. As such, admitting that google had *technical* cause to go ahead with this split. Given that, there is no argument anymore.

He's the one making the claim. he's the one that needs the evidence. And so far the *only* evidence he's even provided *doesn't support his claim*.

I'm not disregarding the claim of the webkit engineer. I'm pointing out that the claim of the webkit engineer does *not* support his claim that it's political. Indeed, it very strongly supports the case that it is *technical*.

"Note that Google was asked to contribute its multiprocess support back to WebKit, but declined.

I think it's fairly clear that the decision to fork here is political, not technical."

He's not beating about the bush here. It's not "well, it was mostly technical, but maybe a little bit political as well". Nope. He's blunt. It was "not technical". "it's fairly clear [it] is political."

To support that claim he has been able to do nothing except:a) point to the claims of a webkit developer *which i do not deny*. But which i show actually defend the claim that it is *technical*.b) state that he is not trusting of G's motives, and as such, this is likely political.c) Completely confuse the actors and actions involves in open source projects, and upstream/downstream contributions.

That's his *entire* argument. A conversation by someone not actually providing evidence for politics. His own gut. And deep misunderstandings of how an Open Source project actually works, including the responsibilities of the developers involved, and how code moves back and forth.

On top of all of this, after providing more technical information for why G would want a split, Znu even admits that the previous situation could have actually been limiting G in a technical way. However, he then waxes philosophical on whether or not those limitations are a good thing, as opposed to then accepting that this recognition does mean he understands that G could very well have done this for technical reasons.

So, again, what have i not weighed deeply enough? What part of his argument am i not giving enough consideration to? What part of my argument have i not provided enough data or information for?

I may have attacked his position "ferocious[ly]", but that's only because he himself put himself out there by so posting such a blatantly weak position, and providing the shakiest defense for it.