First of all, he specifically mentioned downloading them with Bittorrent.
I didn't read the sentence that way to begin with - I read the comma as separating bittorrents from the other items. But, in retrospect, downloading the shows with bittorrent is most certainly what he meant. But, my point of being able to legally download TV shows and movies still stands.
Second, the shows on iTunes are (generally) of a lower resolution than the TV rips you find floating around on Bittorrent and/or are heavily compressed. In other words, they're generally not bit-perfect DVD rips, so they're a good bit smaller.
Yes, that is a good point. However, I download shows from iTunes and they're usually well over 500 MB. If my ISP limited my data transfer that would measurably limit the number of shows I could download each month. I don't download too many shows right now, mostly because of cost, but I still don't want my ISP limiting that number (obviously I'm limited to the transfer rate of the service I get from my ISP).
Third, why would you be downloading all sorts of TV shows using your Verizon wireless EVDO connection?
I wouldn't. While the article is about EVDO, the post that started this thread was about a "traditional" ISP. He said his ISP limited him to 90 GB/month.
All it takes is a little self-control and good judgement and I guarantee you won't run into any problems with your ISP.
You and I both understand that no ISP can truly offer "unlimited" service and that we shouldn't abuse that service, even if it is advertised as "unlimited". I have a 5 Mbps connection but I wouldn't constantly use that pipe 24/7 because I know that would be an abuse of the service that I receive - my ISP doesn't have a tier-1 connection of (5 Mbps) * (number of customers). I guess the main question is, why are ISPs marketing their services (specifically EVDO in this case) as "unlimited" when they're not truly unlimited? That's simply false advertising. ISPs should be responsible for communicating clearly to their customers what the limits of their services are. When a company markets a service as "unlimited" when there is a limit to that service, that's irresponsible.
You do realize that TV shows and movies can be purchased, legally, on iTunes, right? Now, I don't know if the specific shows he mentioned are available on iTunes and he could be pirating these TV shows and movies. But, that doesn't make his point any less valid - simply replace the TV shows and movies he mentioned with ones that are on iTunes.
OK, so their security systems are an unknown at this time. That doesn't mean they have no security. I agree that security through obscurity is generally not a good practice, but as an additional step above-and-beyond other security mechanisms it can be a good thing. What I'm saying is, maybe Google doesn't publish there security architecture since publishing it would make it less secure. Again, I highly doubt security stops at the login box - that simply makes no sense to me, only someone just learning to build web applications would do that. Certainly Google has some experience building web applications?
Only the login page has encryption. Mail.google.com and docs.google.com have no encryption.
So, what's:
https://mail.google.com/mail/
https://docs.google.com/
https://docs.google.com/?action=newdoc&title=
Unfortunately spreadsheets don't have encryption yet for some reason. SSL should be the default, but at least it's there if it's something that's important to you.
So far, all of the most serious exploits in GMail have involved hacking the login to gain access to email stores.
Really? Can you provide some references to these exploits? I have never heard of any exploits in Google's login system. The Gmail contacts exploit required a user to already be logged in to there Google account, but it didn't exploit a weakness in the login system itself.
As long as Google uses a central login for all services a weakness that allows you login access for ONE application allows access to ALL applications.
There are some advantages to this from a security point-of-view. There is only one login system to secure, so all of your efforts can be focused on making sure it is as secure as possible. Also, what do you think the average user does when they have to remember 20 different passwords? They write them down on a piece of paper next to their computer (for example) or use the same password for all accounts anyways. I'd take a single sign-on system over multiple logins (but that's just my preference). It annoys me when a company I do business with has more than one login account for me to maintain.
I didn't see your post as an attack on Java. I just wasn't sure what the point of saying it's not a "purely object oriented language" was. The only part of Java that isn't object oriented is something so trivial that I wouldn't refer to Java as "not object oriented" because of it. Besides, object oriented programming is more about a developer's use of the language then the language itself, so I suppose this whole thread is pointless. What I mean by that is, I could write my entire application in one class using a purely object oriented language and my application certainly wouldn't be considered "object oriented" even though, technically, it uses nothing but objects. On the other hand, I could take a language that doesn't support objects at all and still find ways to apply object oriented programming techniques with it and make an application that is more "object oriented" than the application in my first example. But, I digress from the topic at hand. However, since this whole thread is pointless anyways, what's it matter?
Certain data types are not objects and have to be wrapped in an object (Integer leaps to mind, for example).
A point of clarification - int is a primitive, Integer is a class. Maybe I don't always want an object in memory when I simply need a primitive (the primitive will take up at least half of the memory as its object version)? If I do need an object (which certainly has its place), I can simply wrap the primitive in its object version. Every primitive in Java has a class counterpart, so I really don't see this as a problem. If you want everything to be objects in your Java application, then you have that option. So, you're point that "Java is *not* a purely object-oriented language" is technically true, but pointless at the same time.
You get my point. I was not being lazy, I was simply replying to someone who failed to provide something solid to measure. Why was I going to bother giving a solid measurement if he couldn't bother being clear about what he was talking about? If you must know, it took me 25 seconds to see the first 1000 emails (this is from work where I have a slower and more latent connection than at home - T1 at work and 5 Mbps fiber also used for VoIP at home). At 50 emails per "page" that's 0.8 seconds per "page" load. That's approximately twice as fast as the 1.5 seconds the original poster mentioned (if that's even what he meant). I don't have a stopwatch to measure more precisely, but clicking and loading an email in my inbox is under 1 second - faster than 1.8 seconds to "pop up an email message".
Are you really that lazy? How long/complicated is it to just time your page refreshes? A guy replies to you with real numbers and your answer is "I can't be bothered with facts"?
Really, you consider those "real numbers"? If you read the original post that I was replying to and you know how Gmail works, you would have an understanding of why I didn't provide "real numbers". How, exactly, does one define "transmit each page" when Gmail is one page built using AJAX? I simply wasn't going to measure every possible interpretation of "transmit each page" and provide figures for each possible interpretation. All I know is that, by every possible definition of "transmit each page", Gmail is much faster than 1.5 seconds (for me). Now, when he says 1.8 seconds to "pop up an email message" what does he mean, exactly? Does he mean viewing an email or composing an email, for example? If I had clearly defined scenarios to measure, perhaps I would have provided counter examples. All I know is, for me, no action in Gmail is as slow as the numbers provided, as vague as they are.
Than you have much higher tolerance for poor performance than I do. I just checked my Gmail account and I have 1600 messages in my Inbox. It takes about 1.5 seconds to transmit each page and slightly longer (about 1.8 seconds) to pop up an email message. This means that it would take about 4 minutes just to scroll through the email headers. I find this intermitibly slow compared to Eudora, the desktop email client I use. BTW, I'm on a 10 megabit cable connection less than 5 miles from the Googleplex.
Nope, Gmail is lightning fast for me. I haven't timed timed it, but it's certainly faster than the numbers you provided. Your connection may have fast throughput, but what's the latency on it? Also, from my understanding of how Google serves up content, how far you are from the Googleplex makes no difference since they have data centers all over the world and use Akamai (not sure if that applies to Google Apps). I am on a 5 Mbps fiber connection which is also used for delivering VoIP (so the latency is low), so I'm sure that helps.
As far as I'm aware, the only security on Google apps is the password-protected login which is transmitted in the clear (Docs and Spreadsheets does not apparently use SSL or TLS), making it pretty easy to sniff. There have also been a number of exploits in GMail, which would affect D&S as they use the same login. I would also feel more comfortable if they supported some soft of VPN for corporate users.
The "only" security "as far as you're aware"? WTF does that mean? Have you researched the security systems in place (apparently not since you failed to provide sources for your information)? Obviously, if you haven't bothered researching it, you wouldn't be aware of it, would you? I highly doubt security stops at the login box. Also, if you look at the address bar when logging into Google Docs or Gmail, you'll notice those pages are https. Why would exploits in Gmail automatically affect Docs because "they use the same login"? They're two totally different applications. You obviously have not idea WTF you're talking about or I'm feeding a troll.
Like I said, when using Subversion your working copy is only a temporary workspace. You merge the repository version into your local copy before you do a commit. As far as merges go, you don't have to use Subversion's merge tool if you don't trust it - you can do a diff and manually pick which changes to keep. Yes, technically the state of your workspace before the merge is "lost forever". But, even with decentralized version control you still need to do a merge at some point. If it's so important to have this intermediate state saved, you can always work on a branch that only you are committing to (however, if all developers are going to do this all the time, you might as well use decentralized version control). I think Subversion gives me many, very useful, features. Again, it comes down to centralized vs. decentralized version control. You certainly wouldn't argue that there is anything better than Subversion for centralized version control?
If I'm hearing you correctly, it sounds like we simply have a difference of opinion on which is better, centralized or decentralized version control. I can see the benefits of both, but my general preference is centralized version control. With Subversion (a centralized version control system), the code in your repository is what's most important, and your working copy is simply a temporary work space. Before you start working, you run an update to make sure you've got the latest stuff from the repository. You then do a unit of work, run another update to merge any changes from the repository into your working copy, and then do a commit to put your changes into the repository. You then move on to the next unit of work.
Where you can get into trouble is in the following situations:
Not running an update before you start working. If you don't, you're more likely to run into merging issues later.
Doing too much work before committing your changes back to the repository (or at least running another update to bring in the latest changes from the repository). The longer you go without merging the repository into your working copy, the more changes other developers could have committed and the more merging work you may have to do. Also, since your working copy is meant to be only a temporary work space, by not committing often you risk losing work.
I find this edit-merge-commit model works very well for me. I like having one authoritative copy of the software in my repository and I like the discipline of doing a unit of work and committing it. If you follow the basic work-flow I outlined above, I don't see how subversion doesn't "help you coordinate changes between multiple team members and allow those folks to work as independently of each other as possible without duplicating effort or bumping heads." Simply update and commit often and you're good-to-go. I haven't worked with decentralized version control, but I understand the basic concepts and why it would work for some people. If developers prefer to go for extended periods of time without updating or committing, then decentralized version control would certainly work better.
Actually, it was more a crack that Subversion sucks.
Yes, I knew what you meant. My point was that Subversion doesn't suck. It would be interesting to hear your specific complaints with it other than "it sucks". My guess is that your complaints are based on a lack of knowledge about basic version control practices and not actually any issues with the software itself. That's why I suggested you read the book I linked to.
Passing around tarballs sounds silly until the only other option is Subversion.
Either you're joking, or you're lazy. Subversion is relatively easy to learn and certainly easier than trying to keep a bunch of tarballs in sync. Heck, everything you need to know about Subversion is in the very well written book, Version Control with Subversion. Once you've read it and understood how to work with Subversion, then tell me which is easier.
Umm, I was pointing out the original posters use of caps, otherwise I wouldn't have used caps. Please forgive me for the horrible misspelling, my point must be entirely lost because of it.
If you read your own link you will see the point the parent to your post was making.
Actually, I think the parent (now grandparent) was pretty clear in his/her point:
Except that you CANT short pink sheet stocks or OTC stocks.
This is a common misconception, so I thought I'd correct the point. You are absolutely right that it is INPRACTICAL to short pinks or OTC stocks, but, INPRACTICAL is different than CANT, IMHO. I'm not sure if you're reading the same post as me.
You know what they say, it takes money to make money. Those with lots of money can manipulate the market in lots of "interesting" ways to make even more money. Typically it's money managers with lots of other-people's-money to play with that can manipulate the market. Us little investors are just along for the ride:-)
I have not been watching SCOX and have no idea why it's up. However, there are a lot of factors that go into a stock price on any particular day. My guess is that SCOX is heavily shorted by people betting SCOX will go down in price. If a stock is heavily shorted, it can be subject to a short squeeze. Basically, a money manager with a lot of cash can throw money at the stock, causing the price to go up slightly, which causes shorts to cover, which causes a short squeeze and drives the price up even higher. The money manager then cashes out at the higher price and the stock goes back down again. I have no idea if this happened with SCOX, just giving one scenario that could cause a bad stock to go up in price.
I am kind of interested in
how a 100% accurate polygraph or lie-detector would affect civilization.
One of the fundamental problems with polygraphs is that there is no such thing as an absolute truth. If one could invent a "100% accurate" polygraph all it would really measure is if the subject believes he or she is telling the truth or not (which is all that current polygraphers claim that it can measure anyways). So, someone that could truly convince themselves that something is true could still fake a polygraph exam. Therefore, there will never be a "100% accurate" polygraph because the fundamental concept of polygraphs is flawed.
I had this happen to me last winter coming back from Canada. The officer had me turn on and log into my computer and then looked through my files for about 30 minutes. He only had me login as one account on the system, which isn't very smart if they're actually looking for anything. Also, if I had been doing something illegal and he found it, it would have been inadmissible since he was working on my laptop directly, not an imaged copy of my hard drive. Oh, and he didn't bother checking my iPod either.
That always gets me: we fuck up and get fired, we get nothing; a CEO gets fired; they get a wind-fall!
CEOs are hired to be fired. If things go well, they get credit, if things go poorly they get blamed and possibly fired. CEOs (and others) know this when they take a job and it's why they almost always have a severance package in place as part of their contract. You see, most executives aren't hired to do actual work like us peons.
An interesting post overall. I take issue with only one statement, however:
Do you really think somebody who, to give an example, kills their wife after catching her in bed with another person is automatically psycho? Granted a psychopath put in that position is more likely to commit violence than an average person...
I am not a psychologist, but my hunch is that a psychopath may actually be less likely to kill in that situation (but would not feel guilt if they did). My reasoning is that a psychopath doesn't feel emotions the same way a "healthy" person does. The jealousy and anger that may drive a person to kill in that situation may very well not be the emotional response of a psychopath in that situation, even though a "healthy" person would be jealous and angry in that situation
IMHO that was an example of why Google *should* integrate.
I wasn't necessarily saying that they should or shouldn't have used the Google Maps API, just giving an example of where, from a strictly technological point of view, it would have made sense to integrate but they chose not to integrate for whatever reason. I'm guessing that all of the Urchin users that were switched over to Google Analytics have an expectation as to how that feature works and Google wanted to be cautious about changing a feature out from under an existing user base.
Even though they say "YouTube will retain its distinct brand identity" I wonder how much integration they will eventually do with Google Video. Will YouTube videos be search-able on Google Video, for example? Google is usually good at not integrating just for the sake of integrating. For example, Google Analytics still uses a Flash based map instead of the Google Maps API.
Slashdot Mirror
I didn't read the sentence that way to begin with - I read the comma as separating bittorrents from the other items. But, in retrospect, downloading the shows with bittorrent is most certainly what he meant. But, my point of being able to legally download TV shows and movies still stands.
Yes, that is a good point. However, I download shows from iTunes and they're usually well over 500 MB. If my ISP limited my data transfer that would measurably limit the number of shows I could download each month. I don't download too many shows right now, mostly because of cost, but I still don't want my ISP limiting that number (obviously I'm limited to the transfer rate of the service I get from my ISP).
I wouldn't. While the article is about EVDO, the post that started this thread was about a "traditional" ISP. He said his ISP limited him to 90 GB/month.
You and I both understand that no ISP can truly offer "unlimited" service and that we shouldn't abuse that service, even if it is advertised as "unlimited". I have a 5 Mbps connection but I wouldn't constantly use that pipe 24/7 because I know that would be an abuse of the service that I receive - my ISP doesn't have a tier-1 connection of (5 Mbps) * (number of customers). I guess the main question is, why are ISPs marketing their services (specifically EVDO in this case) as "unlimited" when they're not truly unlimited? That's simply false advertising. ISPs should be responsible for communicating clearly to their customers what the limits of their services are. When a company markets a service as "unlimited" when there is a limit to that service, that's irresponsible.
You do realize that TV shows and movies can be purchased, legally, on iTunes, right? Now, I don't know if the specific shows he mentioned are available on iTunes and he could be pirating these TV shows and movies. But, that doesn't make his point any less valid - simply replace the TV shows and movies he mentioned with ones that are on iTunes.
OK, so their security systems are an unknown at this time. That doesn't mean they have no security. I agree that security through obscurity is generally not a good practice, but as an additional step above-and-beyond other security mechanisms it can be a good thing. What I'm saying is, maybe Google doesn't publish there security architecture since publishing it would make it less secure. Again, I highly doubt security stops at the login box - that simply makes no sense to me, only someone just learning to build web applications would do that. Certainly Google has some experience building web applications?
So, what's:
- https://mail.google.com/mail/
- https://docs.google.com/
- https://docs.google.com/?action=newdoc&title=
Unfortunately spreadsheets don't have encryption yet for some reason. SSL should be the default, but at least it's there if it's something that's important to you.Really? Can you provide some references to these exploits? I have never heard of any exploits in Google's login system. The Gmail contacts exploit required a user to already be logged in to there Google account, but it didn't exploit a weakness in the login system itself.
There are some advantages to this from a security point-of-view. There is only one login system to secure, so all of your efforts can be focused on making sure it is as secure as possible. Also, what do you think the average user does when they have to remember 20 different passwords? They write them down on a piece of paper next to their computer (for example) or use the same password for all accounts anyways. I'd take a single sign-on system over multiple logins (but that's just my preference). It annoys me when a company I do business with has more than one login account for me to maintain.
I didn't see your post as an attack on Java. I just wasn't sure what the point of saying it's not a "purely object oriented language" was. The only part of Java that isn't object oriented is something so trivial that I wouldn't refer to Java as "not object oriented" because of it. Besides, object oriented programming is more about a developer's use of the language then the language itself, so I suppose this whole thread is pointless. What I mean by that is, I could write my entire application in one class using a purely object oriented language and my application certainly wouldn't be considered "object oriented" even though, technically, it uses nothing but objects. On the other hand, I could take a language that doesn't support objects at all and still find ways to apply object oriented programming techniques with it and make an application that is more "object oriented" than the application in my first example. But, I digress from the topic at hand. However, since this whole thread is pointless anyways, what's it matter?
A point of clarification - int is a primitive, Integer is a class. Maybe I don't always want an object in memory when I simply need a primitive (the primitive will take up at least half of the memory as its object version)? If I do need an object (which certainly has its place), I can simply wrap the primitive in its object version. Every primitive in Java has a class counterpart, so I really don't see this as a problem. If you want everything to be objects in your Java application, then you have that option. So, you're point that "Java is *not* a purely object-oriented language" is technically true, but pointless at the same time.
You get my point. I was not being lazy, I was simply replying to someone who failed to provide something solid to measure. Why was I going to bother giving a solid measurement if he couldn't bother being clear about what he was talking about? If you must know, it took me 25 seconds to see the first 1000 emails (this is from work where I have a slower and more latent connection than at home - T1 at work and 5 Mbps fiber also used for VoIP at home). At 50 emails per "page" that's 0.8 seconds per "page" load. That's approximately twice as fast as the 1.5 seconds the original poster mentioned (if that's even what he meant). I don't have a stopwatch to measure more precisely, but clicking and loading an email in my inbox is under 1 second - faster than 1.8 seconds to "pop up an email message".
Really, you consider those "real numbers"? If you read the original post that I was replying to and you know how Gmail works, you would have an understanding of why I didn't provide "real numbers". How, exactly, does one define "transmit each page" when Gmail is one page built using AJAX? I simply wasn't going to measure every possible interpretation of "transmit each page" and provide figures for each possible interpretation. All I know is that, by every possible definition of "transmit each page", Gmail is much faster than 1.5 seconds (for me). Now, when he says 1.8 seconds to "pop up an email message" what does he mean, exactly? Does he mean viewing an email or composing an email, for example? If I had clearly defined scenarios to measure, perhaps I would have provided counter examples. All I know is, for me, no action in Gmail is as slow as the numbers provided, as vague as they are.
Nope, Gmail is lightning fast for me. I haven't timed timed it, but it's certainly faster than the numbers you provided. Your connection may have fast throughput, but what's the latency on it? Also, from my understanding of how Google serves up content, how far you are from the Googleplex makes no difference since they have data centers all over the world and use Akamai (not sure if that applies to Google Apps). I am on a 5 Mbps fiber connection which is also used for delivering VoIP (so the latency is low), so I'm sure that helps.
The "only" security "as far as you're aware"? WTF does that mean? Have you researched the security systems in place (apparently not since you failed to provide sources for your information)? Obviously, if you haven't bothered researching it, you wouldn't be aware of it, would you? I highly doubt security stops at the login box. Also, if you look at the address bar when logging into Google Docs or Gmail, you'll notice those pages are https. Why would exploits in Gmail automatically affect Docs because "they use the same login"? They're two totally different applications. You obviously have not idea WTF you're talking about or I'm feeding a troll.
I currently have 9147 emails in my inbox, more if you count archived items and spam. No speed issues here.
Can you provide some sources for this assertion?
Like I said, when using Subversion your working copy is only a temporary workspace. You merge the repository version into your local copy before you do a commit. As far as merges go, you don't have to use Subversion's merge tool if you don't trust it - you can do a diff and manually pick which changes to keep. Yes, technically the state of your workspace before the merge is "lost forever". But, even with decentralized version control you still need to do a merge at some point. If it's so important to have this intermediate state saved, you can always work on a branch that only you are committing to (however, if all developers are going to do this all the time, you might as well use decentralized version control). I think Subversion gives me many, very useful, features. Again, it comes down to centralized vs. decentralized version control. You certainly wouldn't argue that there is anything better than Subversion for centralized version control?
If I'm hearing you correctly, it sounds like we simply have a difference of opinion on which is better, centralized or decentralized version control. I can see the benefits of both, but my general preference is centralized version control. With Subversion (a centralized version control system), the code in your repository is what's most important, and your working copy is simply a temporary work space. Before you start working, you run an update to make sure you've got the latest stuff from the repository. You then do a unit of work, run another update to merge any changes from the repository into your working copy, and then do a commit to put your changes into the repository. You then move on to the next unit of work.
Where you can get into trouble is in the following situations:
I find this edit-merge-commit model works very well for me. I like having one authoritative copy of the software in my repository and I like the discipline of doing a unit of work and committing it. If you follow the basic work-flow I outlined above, I don't see how subversion doesn't "help you coordinate changes between multiple team members and allow those folks to work as independently of each other as possible without duplicating effort or bumping heads." Simply update and commit often and you're good-to-go. I haven't worked with decentralized version control, but I understand the basic concepts and why it would work for some people. If developers prefer to go for extended periods of time without updating or committing, then decentralized version control would certainly work better.
Yes, I knew what you meant. My point was that Subversion doesn't suck. It would be interesting to hear your specific complaints with it other than "it sucks". My guess is that your complaints are based on a lack of knowledge about basic version control practices and not actually any issues with the software itself. That's why I suggested you read the book I linked to.
Either you're joking, or you're lazy. Subversion is relatively easy to learn and certainly easier than trying to keep a bunch of tarballs in sync. Heck, everything you need to know about Subversion is in the very well written book, Version Control with Subversion. Once you've read it and understood how to work with Subversion, then tell me which is easier.
Umm, I was pointing out the original posters use of caps, otherwise I wouldn't have used caps. Please forgive me for the horrible misspelling, my point must be entirely lost because of it.
Actually, I think the parent (now grandparent) was pretty clear in his/her point:
This is a common misconception, so I thought I'd correct the point. You are absolutely right that it is INPRACTICAL to short pinks or OTC stocks, but, INPRACTICAL is different than CANT, IMHO. I'm not sure if you're reading the same post as me.
http://www.investopedia.com/ask/answers/06/otcpin
You know what they say, it takes money to make money. Those with lots of money can manipulate the market in lots of "interesting" ways to make even more money. Typically it's money managers with lots of other-people's-money to play with that can manipulate the market. Us little investors are just along for the ride :-)
I have not been watching SCOX and have no idea why it's up. However, there are a lot of factors that go into a stock price on any particular day. My guess is that SCOX is heavily shorted by people betting SCOX will go down in price. If a stock is heavily shorted, it can be subject to a short squeeze. Basically, a money manager with a lot of cash can throw money at the stock, causing the price to go up slightly, which causes shorts to cover, which causes a short squeeze and drives the price up even higher. The money manager then cashes out at the higher price and the stock goes back down again. I have no idea if this happened with SCOX, just giving one scenario that could cause a bad stock to go up in price.
Anybody else get the Microsoft Visual Studio 2005 ad on this Slashdot article (screen shot below)?
6 /slashdot_ms.jpg
http://i64.photobucket.com/albums/h165/bradley197
I had this happen to me last winter coming back from Canada. The officer had me turn on and log into my computer and then looked through my files for about 30 minutes. He only had me login as one account on the system, which isn't very smart if they're actually looking for anything. Also, if I had been doing something illegal and he found it, it would have been inadmissible since he was working on my laptop directly, not an imaged copy of my hard drive. Oh, and he didn't bother checking my iPod either.
CEOs are hired to be fired. If things go well, they get credit, if things go poorly they get blamed and possibly fired. CEOs (and others) know this when they take a job and it's why they almost always have a severance package in place as part of their contract. You see, most executives aren't hired to do actual work like us peons.
An interesting post overall. I take issue with only one statement, however:
I am not a psychologist, but my hunch is that a psychopath may actually be less likely to kill in that situation (but would not feel guilt if they did). My reasoning is that a psychopath doesn't feel emotions the same way a "healthy" person does. The jealousy and anger that may drive a person to kill in that situation may very well not be the emotional response of a psychopath in that situation, even though a "healthy" person would be jealous and angry in that situation
I wasn't necessarily saying that they should or shouldn't have used the Google Maps API, just giving an example of where, from a strictly technological point of view, it would have made sense to integrate but they chose not to integrate for whatever reason. I'm guessing that all of the Urchin users that were switched over to Google Analytics have an expectation as to how that feature works and Google wanted to be cautious about changing a feature out from under an existing user base.
Even though they say "YouTube will retain its distinct brand identity" I wonder how much integration they will eventually do with Google Video. Will YouTube videos be search-able on Google Video, for example? Google is usually good at not integrating just for the sake of integrating. For example, Google Analytics still uses a Flash based map instead of the Google Maps API.