Professional reviewers are often more biased than unprofessional reviewers, due to being bought out. I don't know about the literary field, but it happens a lot in gaming.
Professional reviews are valuable to whoever is paying for them. If it is a setup like Consumer Reports, where the consumer of the information is paying for it, it is likely to be useful to the consumer. Typically in gaming, the people paying for the reviews are the publishers, and so the reviews are useful to the publishers.
Unprofessional reviews are less likely to be useful to anyone.
The same is generally true of professional anything.
The difference is, as soon as color came it took off. Few movies are shot in b&w these days, and only for effect when they do.
No, it didn't.
Color motion picture film was around in 1899, and was used in feature films in the first decade of the 20th Century, but the big push where color "took off" (and went, in a few years, from a fairly small minority of films to a majority, at least in the US) wasn't until the 1950s.
"3D", on the other hand, has been around for over sixty years.
E.g., about the same length of time color filmmaking was around before it took off.
You think it will finally take off?
I don't think its likely that stereoscopic "3D" (which is only slightly more 3D than traditional film, as most depth cues used by the human brain are already in traditional film, and stereoscopy adds one [but not all] of the missing ones) will ever be as near to universal as color, but I think that as with color, advances that bring down the marginal cost of using it while improving the quality (combined with increased understanding of how to use it effectively) will continue to make it, if you look at the long-term trend, more popular over time.
I think the short-term trend is going to show surges and retreats, though, but I don't think that even the retreats are likely to go back to the point where S3D is such a novelty that you'll go years without a major feature film being released that uses it -- unless projection holography becomes practical and economical, at which point, yeah, S3D is dead.
I'm not sure if Burton's Alice in Wonderland is an appropriate example of 3D done well. It was shot in 2D and then converted in a computer.
3D-done-well is more about how it is used to enhance the ability to convey the desired story/feeling than it is about the mechanics of how the 3D images are generated. It may be that for most cases, 3D-done-well will also happen to be shot-in-3D, but the two aren't fundamentally linked.
While everyone is more interested in the rivalry of Google, Apple and Microsoft, Amazon has steadily charted up year after year building a base that is more resilient than that of any other.
Posted on a day where on of the biggest Amazon customers (Netflix) -- and all of their customers -- might have something to say about that "resilience".
Personally, I find academic code -- that found in textbooks and other teaching materials -- to be poor specimens. These are examples that teach methods and concepts, but utterly fail to account for edge cases and real-world scenarios. Real-world code may not always be pretty, but it is a lot more comprehensive than what you will find in textbooks.
IME, the exact opposite is true; code in textbooks is far more often to address a specifically defined problem domain correctly (often, a problem defined in such a way that edge cases which might be important in a "real world" program are outside of the problem domain, but nevertheless the specified domain is correctly addressed -- the exception being code in textbooks that exists specifically to support exercises which address identifying and addressing edge cases that are within the problem domain), whereas with real world code it is often the case that the problem domain is -- even if you are lucky enough to have design documentation accompanying the code -- poorly specified, and quite often the code is not correct for the problem domain and fails to account for edge-cases and real-world scenarios that occur both in the defined problem domain (to the extent that such a thing exists) and the actual domain in which the program is applied.
Though its true that the real world code is often more "comprehensive", if by that you mean the opposite of "concise" rather than the opposite of "incomplete".
Not at all, most of the real world problems are problems you see solved in academia, very well. The code quality is a direct result of the "coding to the business need" principle, where everything is done based on a business identified function/schedule.
Perhaps more precisely, that the code produced in the "real world" is often "graded", in the immediate term, by a PHB that will be satisfied if it superficially appears to work (they'll eventually get upset at the costs produced by less-obvious defects and poor design, but at the point they often won't be punishing anyone for it, except probably by making them "fix" it -- to the same flawed standards as before -- if they are still around.)
Does the FCC actually have the authority to do this?
This isn't the FCC doing something, its a member of Congress proposing a law directing the FCC to do it. If they pass the law, then the FCC will, ipso facto, have authority to do it (assuming, of course, that Congress has Constitutional authority to pass the law.)
How about congress actually pass a LAW on this, after all, they are supposed to be the legislators, eh?
That's exactly what Senator Wyden is proposing: Congress passing a LAW that would ISPs from imposing data caps without prior approval of the specific cap meeting specific requirements from the FCC.
If you're making $60k now, you're making less than someone making $30k in 1997.
First, this is grossly off-topic.
Second, its also grossly wrong. Adjusted for inflation, $30k in 1997 is equivalent to $43k in 2012. The latest year for which your "$60k now is less than $30k then" is true is 1987.
It proposes, in its general form, that a question should be answered based on something other than what the words in the question mean, but based on how some other entities who are the subject of the question might define the words; this is aggravated by the fact that the entities in question in the specific framing are ones which we have no reason to believe (and plenty of reason not to believe) have the ability to process the kind of abstract ideas that would let them define any words in any case.
Its as if I pointed to a green leaf on a tree and asked if it was blue, and someone responded with "Well, your definition of blue is human-centric. How would the tree define blue? Maybe the leaf is blue, and and maybe its red. We don't really know." Instead of "No, dude, the leaf is green."
Untrue, you can still authenticate when using a self signed cert with username and password.
POP3 does not have the server authenticate to the client with a username and password; in the case at issue, Gmail is the client, the POP3 server (whatever kind of certificate it has) is the server. So, while its abstractly possible to provide some authentication method along with a self-signed certificate in an SSL application, there is none available in a POP3+SSL environment (except presharing the public key through a separate authenticated connection), and certainly there was none being used by Gmail prior to discontinuing support for SSL to POP3 servers with self-signed certs.
There might be room for some debate about whether this was the best way to fix the problem (and, particularly, whether a facility for advance key sharing for servers with self-signed certs might have been a better idea), but there doesn't seem to be much legitimate room to argue that the pre-existing setup was a massive security hole that created MITM opportunities against any POP3+SSL server that Gmail tried to connect to and which needed to be changed, and that disallowing self-signed certs is a net gain even if it isn't the best possible solution.
Lots of people are making arguments about the abstract utility of self-signed SSL certificates but not really understanding the implications in this particular use case.
There is an important difference in the use of SSL provides protection against passive easedropping where an attacker may only be able to listen to but not alter the contents of transmitted data.
Sure, but this is offset against the fact that supporting self-signed certs without presharing means that all SSL connections in Gmail's POP+SSL implementaiton were subject to MITM by way of self-signed cert, not just those made to servers where the real target server used a self-signed cert (since an attacker that can intercept traffic destined for the server with a CA-signed cert can impersonate that server with a self-signed cert, capture the logon credentials, and then use them to establish its own connection to the real target server.) Net, this is a huge loss for security for all users, to support a small gain in security for those users whose POP server operators didn't want to bother with a cert with a trust chain back to a valid CA.
The attacker never knows for sure if the certificate has been trusted out-of-band, so their attack may be immediately detected since it might actually be a trusted cert.
In the abstract SSL case that's true. But the issue here is not the abstract SSL case.
In the concrete case of Gmail's POP+SSL implementation -- where Google's practices and the requirements for using it are well-known and public -- the attacker knows that there is no facility for a self-signed cert used on a POP server that is being contacted by Gmail to be pre-shared with Google, and therefore knows that it is safe to MITM such traffic, both capturing the real data from the POP server and injecting false data to the Gmail client, with a forged self-signed certificate if it intercepts the request. Which is why, in the specific case at issue, self-signed certs provide only illusory security. (This is more generally true of their use in any public system with known policies and no presharing facility; obviously there are uses to which this is not applicable.)
Note particularly that, if an attacker can intercept requests to the POP server, Gmail's support of self-signed certs allows it to impersonate (and MITM a connection with) a server that would legitimately be identified by a cert with a valid CA chain anchored with a trusted CA using a self-signed cert, since Google's server in this case is the POP client and authentication of the client uses username/password rather than a client certificate. So supporting self-signed certificates the way Gmail did compromises the security of users whose POP server has a certificate signed by a trusted CA, it doesn't just merely affect those who are willing to accept the issues around self-signed certs to avoid the effort of getting a CA-signed cert for their POP server.
One can perhaps legitimately argue over whether it would be bettter for Google to require self-signed certs to be pre-shared over a connection authenticated by some other mechanism than to discontinue all support of self-signed certs for its POP+SSL implementation, but I don't see any legitimate argument that the use of POP+SSL with self-signed certs that Gmail had prior to discontinuing support for self-signed certs provided anything but a dangerous gaping hole in the security of all POP+SSL users.
Unauthenticated encryption is vastly more secure than lack of encryption.
Yes, but supporting unauthenticated encryption in a manner which creates a new attack vector that works to bypass authentication of servers which otherwise would have authenticated encryption in order to support unauthenticated encryption for a minority of servers is making security for most users vastly worse.
When I thought that I already knew enough about the job of an arachnologist to stay away from it, I read this. If this also holds true for other insects
Spiders aren't insects. They are arachnids (both insects and arachnids are arthropods.)
The definition of art that you're using was created by humans. If animals defined "art" it'd be totally different and human art wouldn't qualify.
This seems to be a complete non-sequitur, unless you're unstated argument is that questions of the form "is X an example of Y" should be answered on the basis of speculative alternative definitions of Y, rather than the actual definition of Y which is the basis of the question.
No kidding. I think I'm going to start adding a clause to all my service contracts that gives me King's Privilege (i.e., I can fuck your wives and daughters at will), just to see if anyone catches it.
Note in doing so that in many, if not most, jurisdictions exchanging sex acts for goods or services is a crime, as is soliciting such an exchange, and also that a contract in which either parties obligations include the commission of a crime may be void as contrary to public policy. So there's a decent chance that if you do that you will both be committing a crime and providing documentary evidence of the crime, and also invalidating any of the service contracts that actually get signed (not just the part regarding the "King's Privilege", but the whole contract.)
Which reveals the rather key difference to all the prostitution analogies that makes them off-point: the thing that Instagram is seeking your consent for isn't a crime. Its a perfect legitimate exchange of intellectual property rights for services (its funny how many of the same people that call IP rights "imaginary property" get really mad when its their "imaginary property" that is at issue, even when the issue is a simple voluntary exchange that they can turn down by not using a free service.)
So... if I take a picture of a copyrighted photo, then upload that picture to Instagram, Instagram subsequently owns the copyright?
No, because you didn't have the rights you said you had to any photos when you uploaded it, so Instagram can't get those rights from you.
Instead, you've just perpetrated either a fraud or a breach of contract against Instagram.
Hi. How hard is it to setup your own email server at home, for receiving emails?
A little bit harder now, if you want to use Gmail as your mail client and use SSL on the connection to Google (though its not any harder if you want the use of SSL on the connection to provide any actual security.)
This change, after all, only affects what kind of certificate a server has to have to Gmail to make POP3+SSL connections to it.
I know this will get 400 replies about how self-signed certificates don't provide complete security.
I'd buy that argument if Google configured their servers to only accept connections over SSL with trusted certificates, and then refused to connect at all otherwise.
However, they're still allowing unencrypted connections as well.
Self-signed certs don't provide any security advantage in the Gmail use case over no SSL, and SSL takes processing power on both ends (self-signed certs can be useful in security if both endpoints of prior shared knowledge of each other); so it is literally costing Google money to provide you with nothing at all (except perhaps a false sense of security), so it makes sense that Google would discontinue spending money to deceive you with security theater.
Admittedly, there are ways that the POP-over-SSL support in Gmail could be changed to actually be useful in the case of self-signed certs (allowing self-signed certs only if the user has provided the corresponding public key through an authenticated connection to the Web UI, for instance), and one might argue that that would be better. OTOH, its quite likely that the cost of making changes to support that wouldn't be justified by the number of people that would benefit.
But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.
But we're not building those due to the lobbying efforts of environmental groups.
That's an interesting perspective. We're not building them because no one is even applying to build them, and the industry has made clear that it isn't interested in building or operating additional reactors without even more insulation from any responsibility for disasters than they already have. The lobbying effects of environmental groups are relevant insofar as environmental groups are sometimes among the groups opposing the increased socialized risk to support private profit that such additional liability shields involve.
Good move since the major enterprise players are going bespoke and whitebox.
Well, the article you point to says Amazon and Google are going that way, but there's enough -- including government -- that aren't that there is plenty of market for enterprise solutions, especially given the small number of players in the market (Amazon and, especially, Google are arguably more competitors in that market than they are the target customers.)
You must be one of those f*ing CSS/JavaScript-only kids.
You must be one of those f*cking makes-unsubstantiated-assumptions-and-then-argues-as-if-the-assumption-were-demonstrated-fact kids.
You go write a scheduling application, now, for Calendar.
I could, but no one is offering me money to do that.
Tip: retake your Linear Algebra classes, as well as your Optimization classes. Oh you never took those,
Well, again, wrong. I've taken Linear Algebra, though not Optimization; but its not like I haven't studied optimization in general and scheduling in specific outside of a class setting in the decades since I got out of college.
Oh you never took those, that's why you think what Google does is nothing!
Disagreeing with the false characterization that this forces everyone to use their apps is not the same as saying what Google does is nothing. If you want to make up positions to argue against, don't respond to me, just make your own post and make it clear that your intent is to argue with a fantasy that exists only in your head.
It's not an "incomplete solution;" it's a total non-solution. If you want to repeal state laws prohibiting marijuana use, that's one thing -- but these laws that are under discussion explicitly try to legalize something that is illegal under federal law.
They don't "explicitly try" to legalize it under federal law; they do so under state law. You seem to fail to understand that (1) in the U.S., the state and federal governments are separate sovereignties with overlapping jurisdiction, and (2) marijuana is typically illegal under both state and federal law, and (3) the measures do not purport to affect federal law, only state law.
Not only do they give a false sense of security to people who are violating the federal law
There's been considerable media attention to the fact that the acts remain prohibited under federal law, so I doubt that's the case in any significant way.
but they distract attention from the need to change the federal laws
The fact, as evidenced from the news story that is the subject of TFA, that the divergent state and federal approach represented by these new laws against the existing federal laws draws attention from the public and the media and results in widely reported attention and responses from the President demonstrates that, contrary to your claim, these laws draw critical attention to the federal policy.
So they are essentially forcing me to use two applications for my email then, if I want push from them (since they are far from the only email provider I use).
Google isn't forcing other vendors (presumably, your concern is with Apple and iOS mail) not to support the push feature in the open protocol (IMAP) Google supports.
If Apple only supports push via the proprietary Microsoft protocol, and this forces you to use different mail apps for accounts that use open protocols, you should bitch to/about Apple.
How exactly do you get "Gotta use only their apps now" from them discontinuing support for proprietary sync technology (Microsoft Exchange ActiveSync) in favor of open protocols (CardDAV, CalDAV, IMAP)?
Slashdot Mirror
Professional reviews are valuable to whoever is paying for them. If it is a setup like Consumer Reports, where the consumer of the information is paying for it, it is likely to be useful to the consumer. Typically in gaming, the people paying for the reviews are the publishers, and so the reviews are useful to the publishers. Unprofessional reviews are less likely to be useful to anyone. The same is generally true of professional anything.
No, it didn't. Color motion picture film was around in 1899, and was used in feature films in the first decade of the 20th Century, but the big push where color "took off" (and went, in a few years, from a fairly small minority of films to a majority, at least in the US) wasn't until the 1950s.
E.g., about the same length of time color filmmaking was around before it took off.
I don't think its likely that stereoscopic "3D" (which is only slightly more 3D than traditional film, as most depth cues used by the human brain are already in traditional film, and stereoscopy adds one [but not all] of the missing ones) will ever be as near to universal as color, but I think that as with color, advances that bring down the marginal cost of using it while improving the quality (combined with increased understanding of how to use it effectively) will continue to make it, if you look at the long-term trend, more popular over time. I think the short-term trend is going to show surges and retreats, though, but I don't think that even the retreats are likely to go back to the point where S3D is such a novelty that you'll go years without a major feature film being released that uses it -- unless projection holography becomes practical and economical, at which point, yeah, S3D is dead.
3D-done-well is more about how it is used to enhance the ability to convey the desired story/feeling than it is about the mechanics of how the 3D images are generated. It may be that for most cases, 3D-done-well will also happen to be shot-in-3D, but the two aren't fundamentally linked.
Posted on a day where on of the biggest Amazon customers (Netflix) -- and all of their customers -- might have something to say about that "resilience".
IME, the exact opposite is true; code in textbooks is far more often to address a specifically defined problem domain correctly (often, a problem defined in such a way that edge cases which might be important in a "real world" program are outside of the problem domain, but nevertheless the specified domain is correctly addressed -- the exception being code in textbooks that exists specifically to support exercises which address identifying and addressing edge cases that are within the problem domain), whereas with real world code it is often the case that the problem domain is -- even if you are lucky enough to have design documentation accompanying the code -- poorly specified, and quite often the code is not correct for the problem domain and fails to account for edge-cases and real-world scenarios that occur both in the defined problem domain (to the extent that such a thing exists) and the actual domain in which the program is applied.
Though its true that the real world code is often more "comprehensive", if by that you mean the opposite of "concise" rather than the opposite of "incomplete".
Perhaps more precisely, that the code produced in the "real world" is often "graded", in the immediate term, by a PHB that will be satisfied if it superficially appears to work (they'll eventually get upset at the costs produced by less-obvious defects and poor design, but at the point they often won't be punishing anyone for it, except probably by making them "fix" it -- to the same flawed standards as before -- if they are still around.)
This isn't the FCC doing something, its a member of Congress proposing a law directing the FCC to do it. If they pass the law, then the FCC will, ipso facto, have authority to do it (assuming, of course, that Congress has Constitutional authority to pass the law.)
That's exactly what Senator Wyden is proposing: Congress passing a LAW that would ISPs from imposing data caps without prior approval of the specific cap meeting specific requirements from the FCC.
First, this is grossly off-topic.
Second, its also grossly wrong. Adjusted for inflation, $30k in 1997 is equivalent to $43k in 2012. The latest year for which your "$60k now is less than $30k then" is true is 1987.
It proposes, in its general form, that a question should be answered based on something other than what the words in the question mean, but based on how some other entities who are the subject of the question might define the words; this is aggravated by the fact that the entities in question in the specific framing are ones which we have no reason to believe (and plenty of reason not to believe) have the ability to process the kind of abstract ideas that would let them define any words in any case.
Its as if I pointed to a green leaf on a tree and asked if it was blue, and someone responded with "Well, your definition of blue is human-centric. How would the tree define blue? Maybe the leaf is blue, and and maybe its red. We don't really know." Instead of "No, dude, the leaf is green."
POP3 does not have the server authenticate to the client with a username and password; in the case at issue, Gmail is the client, the POP3 server (whatever kind of certificate it has) is the server. So, while its abstractly possible to provide some authentication method along with a self-signed certificate in an SSL application, there is none available in a POP3+SSL environment (except presharing the public key through a separate authenticated connection), and certainly there was none being used by Gmail prior to discontinuing support for SSL to POP3 servers with self-signed certs.
There might be room for some debate about whether this was the best way to fix the problem (and, particularly, whether a facility for advance key sharing for servers with self-signed certs might have been a better idea), but there doesn't seem to be much legitimate room to argue that the pre-existing setup was a massive security hole that created MITM opportunities against any POP3+SSL server that Gmail tried to connect to and which needed to be changed, and that disallowing self-signed certs is a net gain even if it isn't the best possible solution.
Lots of people are making arguments about the abstract utility of self-signed SSL certificates but not really understanding the implications in this particular use case.
Sure, but this is offset against the fact that supporting self-signed certs without presharing means that all SSL connections in Gmail's POP+SSL implementaiton were subject to MITM by way of self-signed cert, not just those made to servers where the real target server used a self-signed cert (since an attacker that can intercept traffic destined for the server with a CA-signed cert can impersonate that server with a self-signed cert, capture the logon credentials, and then use them to establish its own connection to the real target server.) Net, this is a huge loss for security for all users, to support a small gain in security for those users whose POP server operators didn't want to bother with a cert with a trust chain back to a valid CA.
In the abstract SSL case that's true. But the issue here is not the abstract SSL case.
In the concrete case of Gmail's POP+SSL implementation -- where Google's practices and the requirements for using it are well-known and public -- the attacker knows that there is no facility for a self-signed cert used on a POP server that is being contacted by Gmail to be pre-shared with Google, and therefore knows that it is safe to MITM such traffic, both capturing the real data from the POP server and injecting false data to the Gmail client, with a forged self-signed certificate if it intercepts the request. Which is why, in the specific case at issue, self-signed certs provide only illusory security. (This is more generally true of their use in any public system with known policies and no presharing facility; obviously there are uses to which this is not applicable.)
Note particularly that, if an attacker can intercept requests to the POP server, Gmail's support of self-signed certs allows it to impersonate (and MITM a connection with) a server that would legitimately be identified by a cert with a valid CA chain anchored with a trusted CA using a self-signed cert, since Google's server in this case is the POP client and authentication of the client uses username/password rather than a client certificate. So supporting self-signed certificates the way Gmail did compromises the security of users whose POP server has a certificate signed by a trusted CA, it doesn't just merely affect those who are willing to accept the issues around self-signed certs to avoid the effort of getting a CA-signed cert for their POP server.
One can perhaps legitimately argue over whether it would be bettter for Google to require self-signed certs to be pre-shared over a connection authenticated by some other mechanism than to discontinue all support of self-signed certs for its POP+SSL implementation, but I don't see any legitimate argument that the use of POP+SSL with self-signed certs that Gmail had prior to discontinuing support for self-signed certs provided anything but a dangerous gaping hole in the security of all POP+SSL users.
Yes, but supporting unauthenticated encryption in a manner which creates a new attack vector that works to bypass authentication of servers which otherwise would have authenticated encryption in order to support unauthenticated encryption for a minority of servers is making security for most users vastly worse.
Spiders aren't insects. They are arachnids (both insects and arachnids are arthropods.)
This seems to be a complete non-sequitur, unless you're unstated argument is that questions of the form "is X an example of Y" should be answered on the basis of speculative alternative definitions of Y, rather than the actual definition of Y which is the basis of the question.
Note in doing so that in many, if not most, jurisdictions exchanging sex acts for goods or services is a crime, as is soliciting such an exchange, and also that a contract in which either parties obligations include the commission of a crime may be void as contrary to public policy. So there's a decent chance that if you do that you will both be committing a crime and providing documentary evidence of the crime, and also invalidating any of the service contracts that actually get signed (not just the part regarding the "King's Privilege", but the whole contract.)
Which reveals the rather key difference to all the prostitution analogies that makes them off-point: the thing that Instagram is seeking your consent for isn't a crime. Its a perfect legitimate exchange of intellectual property rights for services (its funny how many of the same people that call IP rights "imaginary property" get really mad when its their "imaginary property" that is at issue, even when the issue is a simple voluntary exchange that they can turn down by not using a free service.)
No, because you didn't have the rights you said you had to any photos when you uploaded it, so Instagram can't get those rights from you. Instead, you've just perpetrated either a fraud or a breach of contract against Instagram.
A little bit harder now, if you want to use Gmail as your mail client and use SSL on the connection to Google (though its not any harder if you want the use of SSL on the connection to provide any actual security.) This change, after all, only affects what kind of certificate a server has to have to Gmail to make POP3+SSL connections to it.
Self-signed certs don't provide any security advantage in the Gmail use case over no SSL, and SSL takes processing power on both ends (self-signed certs can be useful in security if both endpoints of prior shared knowledge of each other); so it is literally costing Google money to provide you with nothing at all (except perhaps a false sense of security), so it makes sense that Google would discontinue spending money to deceive you with security theater.
Admittedly, there are ways that the POP-over-SSL support in Gmail could be changed to actually be useful in the case of self-signed certs (allowing self-signed certs only if the user has provided the corresponding public key through an authenticated connection to the Web UI, for instance), and one might argue that that would be better. OTOH, its quite likely that the cost of making changes to support that wouldn't be justified by the number of people that would benefit.
But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.
That's an interesting perspective. We're not building them because no one is even applying to build them, and the industry has made clear that it isn't interested in building or operating additional reactors without even more insulation from any responsibility for disasters than they already have. The lobbying effects of environmental groups are relevant insofar as environmental groups are sometimes among the groups opposing the increased socialized risk to support private profit that such additional liability shields involve.
Well, the article you point to says Amazon and Google are going that way, but there's enough -- including government -- that aren't that there is plenty of market for enterprise solutions, especially given the small number of players in the market (Amazon and, especially, Google are arguably more competitors in that market than they are the target customers.)
You must be one of those f*cking makes-unsubstantiated-assumptions-and-then-argues-as-if-the-assumption-were-demonstrated-fact kids.
I could, but no one is offering me money to do that.
Well, again, wrong. I've taken Linear Algebra, though not Optimization; but its not like I haven't studied optimization in general and scheduling in specific outside of a class setting in the decades since I got out of college.
Disagreeing with the false characterization that this forces everyone to use their apps is not the same as saying what Google does is nothing. If you want to make up positions to argue against, don't respond to me, just make your own post and make it clear that your intent is to argue with a fantasy that exists only in your head.
They don't "explicitly try" to legalize it under federal law; they do so under state law. You seem to fail to understand that (1) in the U.S., the state and federal governments are separate sovereignties with overlapping jurisdiction, and (2) marijuana is typically illegal under both state and federal law, and (3) the measures do not purport to affect federal law, only state law.
There's been considerable media attention to the fact that the acts remain prohibited under federal law, so I doubt that's the case in any significant way.
The fact, as evidenced from the news story that is the subject of TFA, that the divergent state and federal approach represented by these new laws against the existing federal laws draws attention from the public and the media and results in widely reported attention and responses from the President demonstrates that, contrary to your claim, these laws draw critical attention to the federal policy.
That the open protocols used by Google Calendar and Gmail are better alternatives to Exchange nonsense.
Google isn't forcing other vendors (presumably, your concern is with Apple and iOS mail) not to support the push feature in the open protocol (IMAP) Google supports. If Apple only supports push via the proprietary Microsoft protocol, and this forces you to use different mail apps for accounts that use open protocols, you should bitch to/about Apple.
How exactly do you get "Gotta use only their apps now" from them discontinuing support for proprietary sync technology (Microsoft Exchange ActiveSync) in favor of open protocols (CardDAV, CalDAV, IMAP)?