When a market with competition becomes a monoculture, every security problem that used to affect only one product becomes a class break[1] that affects everything. Just like the potato famine, software monocultures can fall to a single attacker, who also benefits from the consistent interface.

> What is special about browsers

Nothing. We need multiple implementations of all software that is relied upon for anything remotely important. It still amazes me that so many businesses critically depend on something that is only available from one source. Without a second source[2], the business lives or dies at the whim of the company they depend on.

[1] https://www.schneier.com/blog/archives/2017/01/class_breaks....

[2] https://en.wikipedia.org/wiki/Second_source

Most of those aren't interchange formats. You can use Mecurial or Perforce instead of Git; PDF is the interchange format in TeX's space; Linux is an OS, so I don't even know what you're talking about here; for GHC, you can use ML or C or Python or PHP or whatever instead of Haskell.

HTML is supposed to be an actual standard for interchange of hypertext.

> or GHC, you can use ML or C or Python or PHP or whatever instead of Haskell.

Well there are also other Haskell interpreters and compilers (JHC, UHC, Hugs). Although of course GHC is de facto standard due to it's numerous extensions of the language.

Because defining the Web as a legacy pile of mostly sequential C++ code dating back to the '90s is not a forward-thinking idea.

Is your position that Blink's architecture is well suited for getting performance out of modern hardware? Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?

I don't think it matters what the particular engine everyone gets stuck with is. The argument is more that forcing everyone to use it, means that everyone now has an incentive to refactor it into something nice.

Consider where OpenGL would be right now, if DirectX never came into existence, and so all the people who would have been off contributing happily to DirectX, had instead been banging the OpenGL standard into better shape.

When we have "enclaves" like DirectX, we have developers who are perfectly content because their little corner of the ecosystem works for them, for their use-case—even if, somewhere else, a ton of people who can't (for whatever reason) work inside that enclave are suffering, for reasons that person could totally help with if they cared about what happens outside of the enclave.

Merging everyone's efforts into one big project, wouldn't mean that the project would be good (at least at the beginning.) It would just mean that everyone would be forced to take all their corner-case solutions for their use-cases from their enclaves, and bring them out into the open where everyone can benefit from them.

OpenGL is a standard, not an implementation! Imagine if were all stuck with SGI's implementation of GL instead of having it be a standard that the industry could create unique hardware implementations of. Would SGI have willingly collaborated with 3dfx on the Voodoo? Not likely--instead, 3dfx implemented a subset of the de facto GL standard, called it Glide, and created the entire PC GPU market in one fell swoop.

OpenGL is actually a great argument for the importance of multiple implementations--thanks for suggesting it :)

> everyone now has an incentive to refactor it into something nice.

My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust and JS in order to improve security. After working in this space for years, I've become increasingly convinced that this is what is needed in order for the Web to steal the performance crown from native, while simultaneously driving security forward.

Do you honestly think Google would be likely to collaborate on that?

I don't see it. My point doesn't change between talking about "a standard", and talking about "a FOSS project with open committee-based maintainership" (like e.g. ASF projects are.) It's stone soup: you'd start off with a worthless project—but if that pile of crap has to "feed the whole town", people are going to turn it into something worthwhile.

Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.

> My proposal to "refactor" Blink would be to completely redesign the layout system from the ground up to be parallel and to write as much as possible in Rust in order to improve security. Do you think Google would be likely to collaborate on that?

Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.

See: the Linux kernel.

> Eventually, in such an effort, there would probably be zero lines of code from the original project left. That's okay! It was there to bootstrap the project and inspire contributions, not to be good code.

The Web doesn't need "bootstrapping" and "inspiring contributions". It's 20 years old!

> Keep in mind that, if there really was just one impl that everyone used, there'd be more than one megacorp influencing it; Google would have no more say than anyone else, and would probably be "at arms' length" from the maintainership in the same way e.g. Apple is with Webkit. If Google didn't like an idea, but some other corp (e.g. Mozilla) did, sponsorship would still happen, code would still get written, and things would still change.

No, the organization that didn't like the change would fork the project. This already happened with WebKit!

> See: the Linux kernel.

Linux gets forked over and over and over again, every time some organization wants to ship a device running it.

> No, the organization that didn't like the change would fork the project. This already happened with WebKit!

Er, this whole thought exercise is about what would happen if it was literally impossible to fork the project. If everyone was forced to work on one implementation, full-stop, no takesie-backsies. (I'm imagining aliens from the Culture holding guns to our heads.)

It's a very implausible thought-exercise, yes, but if you're playing along, you can't challenge the axioms. (It's like one of those "how would a One World Government work" discussions: saying "there could never be one" is beside the point.)

No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice.

It gives the incentive to create a black market.

A black market is based on circumventing some prohibition. What prohibition is one circumventing to fight the Chrome monoculture? Google's success in creating a monoculture is based on making Chrome attractive and reducing friction with their services compared to alternatives. Independent of whether you think that's something they should do given their prominent position in some related markets, who or what is the black market going to be hiding from?

Not every person thinks the same or have the same moral believes. Only because you think that Chrome monoculture is a good thing with rational arguments, you can't assume that everyone agrees with that.

Just the fact that not everyone uses the Chrome engine today is a good indicator to that. Or that we are having this argument.

What will happen is that people not agreeing on Chrome monoculture will go else where. So even if you have the same engine, others have the possibility to create a total different web system. Now you have two different webs. To what gain?

Also an engine monoculture will eventually be treated as the de facto standard and the real standard will be ignored, i.e. implantation details will trump good design.

I'm not arguing in favor of a Chrome monoculture, since I don't want one. I just don't see how Chrome monoculture => black market happens. It wouldn't even had made sense as a response to the old IE monoculture.

Also the fact that this is even an issue is a product of HTML5, etc. leaving a lot of room for undefined behavior and being easy to misinterpret/misimplement. You don't even have to purposely bend the standard to try and create a monoculture; hard to predict implementation differences happen organically.

Black market is what happens who there is no choice.

For the old IE, Firefox happened (and other as well).

Okay, but what does Firefox's ascendance have to do with a black market? It wasn't even breaking some hard to enforce Microsoft EULA provision. IE got lazy, and Firefox offered a dramatically better experience. Whenever a new product overtakes a more established competitor because it's better, is there a black market involved?

My purpose isn't (just) pedantic. You claimed "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a black market.", but then your example shows an incentive to make a superior product. It starts making a lot less sense in Blink's case if you change it to the more accurate "No, forcing everyone to use the same engine does not give the incentive to refactor it into something nice. It gives the incentive to create a superior product." Why not a superior product that starts with a Blink fork?

Okay, I get your point, however my focus is the word force. For me it means a gun pointing at your head, no choice.

IE did not force anyone doing anything, even if it had a de facto monopoly, therefore Firefox was created, because people chose to.

In this scenario I'm discussing it would not be allowed to create a Firefox, because everyone was forced to use Chrome, hence a black market is created.

There's nothing wrong with modern C++, I think it can give any other language a run for its money in this space. If you are talking about a complete re-write, I don't think you can fairly overlook it. RAII + smart pointers eliminate the most pernicious memory management issues. The STL has grown to parity with other modern platforms. Even without a rewrite, given enough time and effort, that crappy old Konquerer codebase may even turn out to look reasonably good.

I would not, however, wish it to be the only thing available.

> There's nothing wrong with modern C++

The fact that it's a set of practices to avoid the deathtraps within a language which itself has plenty of problems left lying around is, arguably, the problem with modern C++.

Yes, that is the problem. It's also what allows you to drag that 20 year old mess forward into the 21st century. It compiles to virtually any platform with a number of compilers. Trade offs...

What platform needs/wants a web browser that isn't covered by an LLVM target?

> RAII + smart pointers eliminate the most pernicious memory management issues.

No, they don't. Browsers have been using RAII and smart pointers for years and years. The memory management-related vulnerabilities keep happening.

The biggest problem tends to be use-after-free, which smart pointers do absolutely nothing to mitigate.

This place hardly seems like an appropriate venue for debating the suitability of C++, given that a large chunk of the audience here seems to have a financial interest in competing technologies.

The FUD is strong...

I assume you're referring to Rust? Who has a financial interest in Rust? I have trouble imagining Mozilla making money off of Rust directly; I don't think there's any Rust developers who wouldn't immediately jump to a fork if Mozilla put ads in Rust's documentation or decided rustc needed a default search engine.

As far as making money off of their own software written in Rust, that advantage is actually stronger if they convince everyone else Rust is stupid and not worth their time.

How is an argument that C++ is a bad foundation not relevant to the proposal that we should define the Web to be a big pile of C++?

Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature. Further, since people here seem to be very invested in <sarcasm>futuristic</sarcasm> technologies and <sarcasm>disruption</sarcasm> they are naturally inclined to knock C++ just because, and then rationalize it with some technical bullshit.

> Because a lot of comments here seem to be very skittish due to security risks due to C++'s power, yet seem to reflect zero interest in pushing one's skills to a level where avoiding those pitfalls is second-nature.

If that is the case, then every browser engine, as well as every piece of large-scale network-facing software worked on by teams using reasonable development practices in C++ is written by unskilled programmers, since all of that software has vulnerabilities. In particular, you're saying that Google hires programmers unskilled in C++. Is that your argument?

> rationalize it with some technical bullshit.

If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.

> If arguments about C++ are "technical bullshit", you should easily be able to explain why virtually no large-scale C++ project has been free of memory safety problems.

Way to generalize there. No C++ project has been free of memory safety problems because they don't have to be. C++ is not optimized for that. Sure you can optimize for memory safety but then real hackers (not on "Hacker" News) will find something else, and then all the internet idiots will crow on about how {LANGUAGE} doesn't sufficiently protect them from {SCARY THING}.

Maybe if we stopped adding every feature under-the-sun to our browsers, memory safety problems wouldn't be so prevalent! (But we can't have that, not if there is less money to be made!)

> No C++ project has been free of memory safety problems because they don't have to be.

They don't have to be free of security vulnerabilities either, but it would be very nice. What's your point?

> Or that C++ is a good foundation on which to build some of the most security-critical software on the planet?

I don't care what it's written in. I care who is writing it and how well it is tested. Write it in Brainfuck for all I care, if it works, is efficient, and is safe.

And if the language has a direct impact on the efficiency and safety of the product, then what?

A memory-safe language dramatically reduces the frequency of memory safety bugs, which are the foremost cause of security vulnerabilities in software like browsers. This is an inconvenient conclusion that everyone wants to deny, because it's, well, inconvenient. But that doesn't make it less true.

And taking the train dramatically reduces the risk of being in an automobile accident.

Another inconvenient conclusion that's being denied is that memory safety errors are at their core due to bad assumptions and logic errors which sadly can't be caught by compilers yet. Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.

I love Rust -- it's quickly becoming a favorite language of mine, but at some level we have to be realistic that it doesn't solve all the world's problems and evangelizing that everything be rewritten in it or another memory safe language is the programming language equivalent of saying, "you should try using machine learning."

> Memory safe languages make it harder to create a specific types of vulnerabilities and can even keep them in check when they occur which is real a tangible benefit, but those same assumptions and errors will just produce different vulnerabilities.

No, because:

1. Not all such errors become vulnerabilities. An array index out of bounds exception triggered by a page causes an annoying crash in a memory safe language. In a non-memory-safe language, it is an out of bounds write that can be used to set up fun things like ROP chains.

2. Errors such as use after free simply don't exist in memory safe languages. There is no logic error that typically causes UAF: it's just straightforward failure to perform bookkeeping that a compiler and/or runtime does for you in most languages.

3. Not all vulnerabilities have the same severity. Memory safety problems tend to cause the worst of the worst: remote code execution.

> Errors such as use after free simply don't exist in memory safe languages.

Right, but we can play this game all day with different types of errors. Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.

I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.

> Static typing makes improper method calling errors impossible and data hiding prevents someone from accidentally modifying internal state but we still use Python. Explicit returns makes accidental data leaking impossible but we still use Ruby. Explicit casting and comparing by value instead of identity would make all of JS's conditional errors disappear.

No, we can't "play this game all day". Those errors don't result in arbitrary code execution with anything remotely approaching the frequency that UAF does.

> I completely agree with 1/3 but there are other solutions to this problem like W^X which gives similar benefits and doesn't require rewriting everything in a different language.

W^X comes nowhere near offering similar benefits. I even specifically mentioned ROP chains to defuse that notion…

> I care who is writing it and how well it is tested.

Static guarantees are particularly strong tests of whatever they guarantee, so what static guarantees the language used can provide is not an entirely separate issue from how well tested a piece of software is. (It's not the whole story, obviously, but it's a potentially important part of it.)

I strongly disagree. HTML is used for long-term text archival in science, education, administration, politics, literature, for personal notes and memories, and so on. Do you want to leave all this to a single browser implementation dominated by an ad company?

git really? there are tons of big projects that don't use git. Java for instance.

Also, there are multiple implementations of the Git API. Original "git" is the only command-line implementation but there are JGit and libgit2 libraries that are used in various projects. In particular, Github, Gitlab, and Bitbucket all use libgit2 for hosting Git.

They use it when multiple people code on the same codebase. It's either in Github, Gitlab or Bitbucket and uses git.

I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.

This just in: an in-development webapp with WebSockets, Shared Workers, and WebRTC integration turns out to actually be "ancient" because it's being managed with subversion!

> I haven't seen someone use anything other than git in a long time, and those that do are ancient projects.

Then you live in a very small bubble.

I suppose Firefox is ancient too. They use Mercurial canonically. :-(

So does Facebook... My company also uses mercurial - I know plenty of people that prefer it over git - but there is no github equivalent for it.

There's bitbucket. It also has free private repositories.

It never reached the mass that github has unfortunately.

Why does that prevent you from using it?

For personal and company sources we use RhodeCode - so we have both Git and mercurial. I was mentioning github because it is the closest thing to social network for open source.

Well obviously you should just be using Chrome.

Lots of people use and prefer mercurial.

I learnt git when I started college and then discovered Mercurial when I started contributing to Firefox. It was painful at first but after some really good reading of the Mozilla Version Control Tools docs and the Hg Tutorial by Joel Spolsky and some blogs regarding the Mozilla contribution and coding workflow I started liking Hg better than git.

Mercurial has a more sane way of referring to commits and traversing the history. They now also have different kinds of branching models. You can even maintain multiple checkouts of a repo using a single clone which is great and saves me from having to checkout branches when I want to work on another feature. (Imagine checking out 3.5 mn files each time you wanted to change branches).

In, my opinion, Mercurial scales better but suffers from the unintuitive names and lack of enough people talking about it.

mmmmh, delicious delicious high quality open source implementation completely controlled by Google. Because Chrome is definitely not known for implementing stuff on their own and ignoring standards. Same way Google is not known for purposefully worsening performance and experience on their websites to non-Chrome users, and same way Google is not transitioning all important Android capabilities into Google Play Services, which itself is closed source.

What could happen with Chrome if they were the only ones on the market, I wonder.

Have any citations for those bold Anti-competitive claims?

- Implementing the newest Google Earth through pNaCl, basically ActiveX by Google

- Play Store website threw you out if you were using Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=1131601

- Gmail delivered an inferior mobile version to Firefox on Android | https://bugzilla.mozilla.org/show_bug.cgi?id=668275

- Actually, Google fucks with Firefox on Android all the time https://bugzilla.mozilla.org/show_bug.cgi?id=668288

- Inbox is still Chrome only

- Youtube refused to serve webm to Firefox for a while | https://bugzilla.mozilla.org/show_bug.cgi?id=1233970

Is that enough for now?

Google is no better than old Microsoft/IE team often. But hey, since you get a shiny browser that implements non standard things, it's okay, right?

That is a list of bugs and one has an apology and a fix from Google. Most are even fixed. Even what you consider anti-competive "Youtube refused to serve webm to Firefox for a while", shows bias because the first comment of the ticket explains that it served videos. It probably worked for a ton of people.

Even with the NaCL thing I was able to find and implementation [1] of it that was under a open source license when I was trying to find a NaCl spec. NaCl existed because webassembly didn't, Google wanted other browsers to implement it.

Bugs happens, Technologies don't get adopted; Google is made of people and mistakes happen. Your disingenuous crying of anti-competitive wolf dilutes real claims of anti-competition.

[1] - https://chromium.googlesource.com/native_client/src/native_c...

As I explained elsewhere in this thread, (P)NaCl is only open source in the sense that Chromium is. Because of the dependency on Pepper, Google's implementation is Chrome only.

The problem with this is that Google solicited feedback on Pepper on the plugin-futures mailing list early on. The other browser vendors correctly pointed out that Pepper was unnecessary. Google completely ignored the feedback and did it anyway. Years later, it is obvious that the unanimous consensus of the other browser vendors was right. PNaCl is dead, and Web Assembly uses the Web APIs instead of Pepper, which is precisely what everyone else had advocated early on.

The lack of adoption of PNaCl is Google's problem. As is obvious with Web Assembly, nobody has any problem with adding a portable low-level IR to the browser. The biggest problem was the insistence on Pepper. If they had listened to feedback, maybe we would have had Web Assembly much sooner.

I am taking what you say about historical events as you say it, but It still doesn't seem like the move is "anti-competitive". At worst its bad engineering.

Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.

I hate microsoft but I still don't give them flak for not releasing Linux versions of office and excel. They are allowed to not do that. Where it steps into anti-competitive is when they start breaking other's people things or maliciously manipulating standards. Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.

Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.

> I am taking what you say about historical events as you say it, but It still doesn't seem like the move is "anti-competitive".

It sure is when combined with Google releasing NaCl-based software, such as Google Earth.

> Google has demonstrated a willingness to go out of their way and fix things for most things not NaCl related.

Not with Dart, which followed a very similar trajectory (see my other comments). Not with -webkit prefixes. Etc. etc.

> Even per your recounting of history they weren't trying to coerce the standards body, they just asked for comments and then unilaterally did something else. They didn't force it on anyone else.

When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.

I had a misunderstanding with Google earth vs maps. I used Google maps in Firefox just fine, and that is what I meant earlier.

I was unaware even of the existence of a web based version of Earth. The last time I used Google earth was as a desktop client. That was back when I worked in the Air Force Weather Wing almost a year ago. Have they done away with the desktop client?

Starting over with whether or not this is anticompetitive; who are they repressing by giving away free software that runs on other free software? Does this software need to be used?

This all seems to hinge around this part of what you are saying:

> When you release software that only works on your platform that you aren't open to outside comments on, then you are forcing others to implement it, warts and all, or lose users.

The option to lose users here is huge. How is this different than microsoft making excel and only supporting it on windows? I choose not to use excel at least in part because it doesn't run on any platform I care to use. I feel I should clarify here, I don't condone this obnoxious behavior from microsoft or Google. I think it is wrong from the stance that all software should inter-operate smoothly and be open source, but it doesn't seem illegal or even unethical.

The answer for a users to both Earth and excel seems to be to use some other competing software. For mapping software something like openstreetmap or even some other Google software like Google maps (or even a pay for solution). For spreadsheets I use libreoffice.

Even if this is anti-competitive it seems so minor that it dilutes the meaning of the term. Lumping this in with things like the Dr DOS fiasco just doesn't seem right. For reference in the Dr DOS times there was a DOS competitor to microsoft's DOS. Dr DOS was a relatively bug free DOS and it worked fine with windows until the 3.0 release (I think). Until this specific version/patch started intermittently causing windows to not run if Dr DOS was detected even though it was advertised as working. The end result was Dr DOS being run out of business because it looked like a bug in Dr DOS and sometime ms even claimed such. The Dr DOS team was very overtly fucked by ms.

Nothing about most of the things brought up in this thread seems overt. No money is being paid for web browsers or this mapping software. Having users takes significant effort to monetize. It seems detached from web standards in any direct way (I agree it indirectly relates to webassembly, but not in a way that seems legally relevant). Most of it seems like engineers being engineers and fixing their own little slice of the world and hoping everyone works with their stuff because they don't want to change. Shortsighted and imperfect just like most humans.

Thank you for taking the time to explain (and listen) to me in a rational and level headed way. I won't be checking my messages here again until I start another build or boring process tomorrow. Have an upvote.

>Its not like there is some new killer feature in the new google maps that makes it not work on Firefox, I have used it from Firefox in the past week and it worked fine. Even if there were some killer feature, they are free to release it in such a way that it only works with their software.

http://i.imgur.com/FDM5DQ9.png

k

You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards

>when they start breaking other's people things

They are! They actually are! These bugs I listed aren't "bad engineering". They're "When UserAgent is detected send shitty version". In what world is that not deliberately breaking people's things? Users access Inbox on Firefox, see that their friends on chrome that sent him the link can actually access it, they're not going to blame Google, they're going to say that Firefox is a piece of crap and dump it.

> maliciously manipulating standards.

chrome.* javascript APIs

Bluetooth API

FileSystem API

-webkit CSS prefixes

not manipulating standards, just implementing half assed things on their side of things and leaving the blame on other browser manufacturers when they don't implement them.

>They didn't force it on anyone else.

"Company with 50% of desktop browser share and 80% of mobile browser share only unilaterally did something non standard and screwed everyone over. But that's not forcing everyone's hand I swear, they're only the biggest players on the market."

k

You know, when pcwalton keeps proving you wrong over and over again, you might want to rethink your opinions. It's not as if he knew what he's talking about or anything, right? :>

> They're "When UserAgent is detected send shitty version".

If you must pick an example of them breaking stuff, please pick one that they didn't already apologize and fix.

> http://i.imgur.com/FDM5DQ9.png

My mistake on confusing google earth with google maps, that is an important point that issue. It does suck that doesn't work on firefox, but no one is forcing any one to do anything. Its not like you paid for any of this, or there is some law that says companies have to give stuff away for free.

> You're doing 180s with such grace, it it impressive. On one hand, Google isn't forced to release their software for firefox. On the other hand, they're paragons of the open web and are all about standards

I am not reversing my stance or saying anything self contradictory. I am attempting to define nuanced boundaries around some who would rather bludgeon things into a simple categories whether or not it fits. So far all I hear are complaints about company giving away huge amounts of value for free, but isn't doing it the way you (or I) want.

I never said Google was paragon of anything and I admitted they could do better (I really do wish they would do better), the only line I am taking is that their behavior is not "anti-competitive", which is not a high bar. Which has not been disproved or this case even rationally approached. I am open to having my mind changed, but I would need well thought out discourse and evidence to change it.

If you respond again so thoughtlessly or with such poor grammar I will not be responding again.

>If you respond again so thoughtlessly or with such poor grammar I will not be responding again.

...Okay then ? ¯\_(ツ)_/¯

It's not as if we were having a meaningful discussion anyways, each of us camping on his positions.

Pcwalton provide me new information and did change my opinion on some things and I suspect I gave him at least some new perspective.

You... Clearly just want me to agree with you without applying any critical thought of my own. You implicitly my experience, personal and professional, while presuming your stance to be the only valid one on a subjective topic. That is not how you have a constructive conversation, goodbye.

Google Earth.

That is a noun, please expand.