And since all of this stuff is open source and will be standardized, Google can never run and/or control it completely.
Standardized by whom?
I don't know which organization. I'd guess W3C. I'm sure you could google it.
Is Google going to consult apple, mozilla, opera, microsoft, etc before deciding on features to NaCl?
Yes. Not only does Google have a long history of cooperating well with standards bodies, Google's real goal with all of this stuff is to be able to use it in its own applications, and Google does not want those applications to work only on Chrome. Unless you're also assuming that Chrome is going to wipe out all browser competition, in which case NaCl is the least of the concerns.
e.g. Acer forced to cancel their "non compatible" android fork
Acer wasn't forced. They could have continued, with no legal repercussions. Google just wouldn't have treated them as a member of the club. Amazon has gone very incompatible with their fork and not only is there nothing Google can do about it, I don't think there's even any interest in stopping them.
Google locks in its paying customers, not users. The users are just fodder to be mined and exploited.
Google views both as customers. And Google doesn't lock in its paying customers, either.
As soon as they did, forks would spring up to compete.
No, they wont. When a codebase crosses a million lines of code, it is practically impossible for a completely new team to even fully comprehend the codebase, much less begin to modify it in any important way. Its much easier to begin afresh - which never happens and would take years of additional work.
Nonsense on the "easier to begin afresh" point. That's a common fallacy among software engineers; starting over is almost never cheaper/easier unless you're also redesigning, and often not even then. As for the rest, there are plenty of counterexamples.
An incompetent or corrupt manager can screw his underlings whether there's a formal or informal review process in place.
This is one of the things I like best about the Google process: Managers don't do the reviews. The reviews are done by neutral parties, based on writeups by employee peers and the manager -- and the manager's input is not focused on performance evaluation but on project evaluation -- how important/impactful is the project.
Also, manager ratings are heavily influenced by the ratings of their employees in addition to the team results, so they're motivated to help their employees be ranked highly as well as to be successful.
The first problem with managing at the team level is that you don't have any way to identify which are your strong contributors and which are dragging the team down. It's possible that while the team met its goals, it would also have met them just as well, and at lower cost, if one or two team members were removed, or perhaps it would have accomplished more if one of them were replaced with someone better. In pathological cases it can be true that removing a person increases team effectiveness, though those cases tend to be so bad that it's very visible to everyone in the vicinity of the team.
A related problem is that without a way to identify the strong contributors, you don't have a good way to grow those people into greater levels of responsibility and impact. And it's harder for employees to move between teams, even at the same level of responsibility, without some sort of objective measure the receiving manager can use to evaluate whether or not the person is going to be a good contributor. These issues are related to lack of individual measurements, rather than not tying measurements to employment and pay, but if the measurements aren't tied to employment and pay, odds are the measurements aren't going to be very good, because few will really care about them.
Finally, it fails to scale, in at least two ways. One, it's almost guaranteed to drag a lot of deadwood along when you get larger teams (this is the first problem, but it gets worse with scale, fast). Two, as you expand your scope to a much larger level, with many dozens (or hundreds) of teams, with lots of different managers, it leaves you with no way to ensure any level of consistency with how employees are being treated and managed. Excessive inconsistency has all sorts of negative effects.
But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud...
maybe a less if you have you own supercomputer, but even at $1M it sound a lot...
So why warn away from SHA1 NOW? what are we going to use? md5? md4?
Because SHA1 has known weaknesses, even if they're not practically exploitable, and because attacks always get better. Would it shock you to hear tomorrow about a new attack on SHA1 that allows collisions to be generated for a few hundred dollars of computation? It wouldn't shock me. I don't expect it, but it would not be surprising.
The alternative to SHA1 right now is SHA2. Or if you want you can use Keccak as published, but you may have to change it when the final standard is released. Depending on the context that may be reasonable.
Microsoft is just repeating here what the security community has been saying for a few years now: SHA1 is okay, but new systems should be designed with SHA2, and old systems should be prepared to move if SHA1's weaknesses get much worse. As soon as SHA3 is standardized (or the community decides to pick an alternative as a standard, as bill_mcgonigle suggests), then new systems should use that.
I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.
Well, yes, there is that.
I should also mention that RC4 is in much the same boat as SHA1. As long as you discard enough of the initial keystream bytes, it's fine for use today and for the foreseeable future. But the cracks in its shell mean that new systems should use something better. AES is the obvious, and perfectly adequate, solution. In counter mode if you need a stream cipher.
Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good.
Passwords have a variety of problems but being subject to brute force attacks needn't be one of them. Their security (or lack thereof) relies on exploiting the asymmetry of effort required to verify vs crack, and reasonable passwords have on the order of 30 bits of entropy. That does require that the password be fairly good, but not "unrealistically good". The key is to calibrate the computation required to verify the password so that searching is infeasible. For example, if it takes 1/10th of a CPU-second to verify the password, then it will take ~3 CPU years to search the password space. If that's not enough for your application, slow the password-verification algorithm down so it takes a second, or whatever other value is appropriate.
There are several key derivation functions (e.g. PBDKF2, bcrypt, scrypt) which allow the run-time cost of the algorithm to be adjusted as needed.
The biggest problem with passwords is password reuse. You can't realistically expect people to manage tens, much less hundreds, of reasonably good passwords. Honestly, two or three is about the limit. And all it takes is for one system to do a bad job with password hashing and storage, and then lots of accounts on lots of systems are compromised/
I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed.
Either multiple algorithms, or a structure that allows new algorithms to be swapped in quickly, or both. One thing working in our favor is that there is usually plenty of warning before someone finds a practical collision generation algorithm. And even MD5 still doesn't have any second pre-image attacks. Arguably, MD5 is just fine for signatures even today, as long as the rest of the protocol is designed to limit the value of random collision pairs.
Measuring people is fine. Giving the measurements an impact on employment and pay destroys collaboration, and as a secondary effect it attaches a larger incentive to working fast (so you can show your manager a big list of accomplishments) instead of attaching an incentive to doing high quality work (which might lead to a shorter list of accomplishments, but fewer security holes and other errors that need to be fixed later).
Giving the measurements an impact on employment and pay is necessary, and it needn't destroy collaboration or incent accumulation of technical debt; it depends how the measurements are defined. Doing it well is hard, and requires judgment and regular fine tuning, but you have to have some way of making those employment and pay decisions, and doing it as objectively and as measurably as possible is much better than the alternative.
Once Google has control of the UI we all use and the API, they get to say what applications run on it
Except that after Google proves out an idea (or while Google is proving out an idea), they also work with standards committees to help turn the new technologies into standard which all browsers can implement, and which any web app developers can use.
Don't forget that currently, all NaCL applications are approved by Google and are exclusively distributed by "Google Play".
Umm, that's not... oh, you already know that's not true.
You may say there are alternative markets, but those are fragmented and most are riddled with malware and pirated software. Anything commercially viable, apart from maybe Cydia is run and/or controlled by Google.
So what you're saying is that Google doesn't run and/or control everything. Agreed. And since all of this stuff is open source and will be standardized, Google can never run and/or control it completely. Of course, if they do such an excellent job that no one has any incentive to set up a competing system, it'll appear that they're in charge, but only in the same sense that Linus Torvalds runs and/or controls Linux. Yes, he does... but only as long as and to the extent his decisions and actions serve most everyone's interests. Open source is like that.
People that own an official Android device will in the near future have the ability to use all their Android apps on all their devices
Cite? I work for Google and I haven't heard this. It would seem to make sense, but I haven't heard of anything in that direction. And I don't see how it's related to NaCl, given that Android is a Java-based platform and it would be easier to use existing JVMs plus an appropriate set of libraries to support Android apps on other devices.
providing they run Google's Chrome, not some other browser that just happens to support NaCl
Uh, why will Chrome be required? And I'm still not clear how NaCl relates. You've lost me.
This will mean a very large domination of the application market for Google, rendering all other web browsers and end-user operating systems insignificant.
That would be a bad outcome for Google. Seriously. Not only would it offend the sensibilities of the 20+K engineers at Google (that's putting it mildly... I see torches and pitchforks at TGIF), it would put Google in a very tenuous position with respect to anti-trust regulators. Google has already been facing anti-trust investigations, and has largely beaten them all precisely because Google is careful not to lock users in.
I think we have a right to be worried here. It's not about the ability, but the viability of a fork. Even if it were technically superior, it'd still lose.
It would only lose as long as Google didn't actively exploit the control you're theorizing. As soon as they did, forks would spring up to compete. Heck, there's already at least one serious and successful fork of Android: Amazon's OS, which has a non-trivial fraction of the Android tablet market and which pretty much completely locks Google out.
(ObDisclaimer: I work for Google, but I don't speak for Google.)
That's not the problem. I mean, it's a problem. But the real problem is trying to apply numerical methods to personal subjective assessment.
There's nothing wrong with that. Given enough subjective rankings you can assemble them into something quite objective.
The problem is in applying statistical distributions to small samples. Given a few hundred employees, a bell curve may well be a good descriptor. Given five, it's a bad one with very high probability (you can actually calculate the probability for a given measure of deviation).
Also, even if you have a sufficiently large sample so that the curve is a good model for performance, that doesn't mean the lower tail of the curve should be fired. If the worst employee in the bunch still generates more revenue than his or her net cost, then there's a good argument that no one should be fired. You can also take the view that those bottom people are probably worse than whoever you'd hire to replace them... but that's a slippery argument, and one that is often made without full consideration of the cost of separating one person and onboarding another, and without consideration that perhaps the poor performer just needs some encouragement, or is only doing badly because of some concerns outside of work which may be resolved before too long, or could be resolved faster with a little assistance.
Curves are useful models if you have statistically-significant populations, but even then they still have to be applied with intelligence.
FWIW, Google uses stack ranking, too, although in a different way. I would expect Marissa is bringing more of a Google approach to Yahoo than the MS approach, but I could be wrong.
In Google's version, the rankings are done by peers, not managers, and they don't rank all of their peers, just a randomly selected subset (3-4 of them). I'm guessing all of the separate stacks get combined somehow (pairwise voting algorithms like the Condorcet method would work well) to provide some overall stack, but even then the result is only used as one input to performance evaluations, and not a heavily-weighted one. I'm told that its function is to double check the main evaluation method.
Meh. I have several drives with no reallocations, but I also have several with many reallocations... and they've been ticking along that way for years.
My home file server has eight drives, half have reallocations, half don't. The drive that died a few months ago had no reallocations in daily SMART log when it failed.
Of my three desktop machines (between home and office), one has a drive with reallocations, one has a drive with none, and one has an SSD.
But this is all anecdotal. The 2007 Google study (covering hundreds of thousands, perhaps millions, of drives) found that there is a correlation between reallocations and failures, but it's only a predictor of moderately-increased likelihood of failure, not a guarantee. Given the direction of drive designs in the last few years, I'd expect that predictor to have weakened.
Many musicians use lyrics sites to check if it's an original idea versus a existing one.
Then they can use any of the handful of lyrics sites which license the lyrics and can legally distribute them. This isn't going to make the lyrics unavailable, just reduce the number of sites that all distribute the same content.
It's six years old now, so perhaps drive failure characteristics have changed, but this study got some different results from a study published by Google in 2007. Google's study obviously involved a lot more than 25,000 drives.
For one, Google didn't observe a strong bathtub curve. They did see some infant mortality, but it was during the first 3-6 months, and the first-year failure rate was still lower than in subsequent years, so what "bathtub" there was hit the low point prior to the one-year mark and then began to climb.
The failure rates Google observed were also much lower. Perhaps drives have gotten less reliable.
Google also reported a lot of detail about how various SMART-reported values correlated with failures. Too bad Backblaze didn't do the same. It would have been very interesting.
Having said that, I count sector reallocation as a failure. In my experience, as soon as a disk has non-zero value in Reallocated_Sector_Ct and Reallocated_Event_Count, it usually fails completely within a few weeks or months.
How old is this experience, and what size drives are you using?
Modern drives have gotten so big, and so aggressive with the way data is packed onto them, that failed sectors are normal. When you have billions of sectors, the error rate that would be required to never have a failure is infeasibly low, so modern drives are designed to monitor and reallocate as necessary, and they have large pools of sectors available for reallocation.
If you're really returning any drive with a reallocated sector I'm not surprised in the least that you're seeing a high failure rate. In fact, I'm more surprised that you manage to keep any drives for more than a few months. I suspect you're returning a lot of perfectly good drives.
But did consumption go up or did video bit rate go up?
Maybe more people are now selecting "HD" streaming than they used to.
And they're probably torrenting higher video bit rates, too.
My money is on the first supposition in the summary being right: The legal services have gotten good enough, and cheap enough, that people have less incentive to reach for illegal torrents.
Google really doesn't want to track you if you don't want to be tracked.
with
Virtually everything that we want to do, I think, is somewhat at odds with locking down all of your information for uses you haven’t contemplated yet. - Larry Page
If you don't want to be tracked, Google will not be able to provide you with the services Page was talking about. There's no contradiction, particularly when you realize that Page is thinking about services like Google Now, which use information about you to predict what information you need and proactively help you. If you lock down all of your information it is impossible to provide those services.
Google wants to make its services so compelling and useful that you'll actually find sharing your personal data with Google to be a net positive for you, but at the same time wants you to make that decision, and will honor your choice. I repeat, there is no contradiction.
If you have one, you might want to do some soul-searching about the evil company you work for.
Right, because giving people a lot of awesome free services in exchange for seeing some targeted ads is really terrible. Your definition of "evil" is more than a little bit skewed.
Whatever that means, YouTube and Google+ are two different websites in the most basic literal sense; they have different urls.
Meh. Youtube.com and www.youtube.com are different URLs, too, as are gmail.com and mail.google.com, and if I thought about it I could come up with a dozen different examples where the same content is accessible from different hostnames at the same level in the hierarchy as well. I fail to see how any of this matters. The same content is visible to the same people (everyone, or a more limited set if you chose to limit it).
If road/car safety was left to the "invisible hand" then people would still be driving around with "DIY LPG conversions" - An 80kg LPG cylinder strapped to the roof racks of station wagons, like a torpedo waiting to be launched in the event of a frontal collision.
Nonsense. People care about safety of their vehicles. A lot. The one thing that government regulators did that really made a difference was to establish safety testing protocols and mandate that they be applied. Vehicle safety has far outstripped the regulatory baseline requirements, because once reliable vehicle safety information was available it became a major selling point, which caused the invisible hand to get really serious about safety.
IMO, this illustrates the most effective form of government regulation: Ensure that high-quality, reliable comparative product information is widely available, then let purchasing decisions drive the market. Granted there are cases in which an information-only approach isn't sufficient, but they're not the common case, and it's always better to try the light touch first in the absence of compelling evidence that it won't work.
"Control" here means that youtube comments don't wind up being posted anywhere but in youtube.
Well, until someone decides to copy them, anyway. Trying to control stuff you post on the public Internet is... optimistic.
In any case, I think you're under some misapprehension that Google+ is somehow distinct from YouTube. YouTube comments aren't "being posted" on Google+. It's the same system.
I quit Facebook after I absently clicked on a video of "Miley Cyrus shows off new bikini body" in HULU, and Facebook informed everyone I went to high school with.
Yeah, I dropped Facebook for the same kind of crap, except that I didn't wait for them actually to spread something about me around. As soon as I noticed they had lowered my privacy settings without even notifying me, I deleted the account. Google doesn't do that sort of thing. Well, they did a milder form of it once (Buzz auto-friending), but learned the lesson -- and got slapped with an FTC consent decree that mandates all sorts of internal and external review of Google's privacy-related actions, so even if Google hadn't internalized the lesson already, the FTC watchdogs are there to make sure.
Slashdot Mirror
And since all of this stuff is open source and will be standardized, Google can never run and/or control it completely.
Standardized by whom?
I don't know which organization. I'd guess W3C. I'm sure you could google it.
Is Google going to consult apple, mozilla, opera, microsoft, etc before deciding on features to NaCl?
Yes. Not only does Google have a long history of cooperating well with standards bodies, Google's real goal with all of this stuff is to be able to use it in its own applications, and Google does not want those applications to work only on Chrome. Unless you're also assuming that Chrome is going to wipe out all browser competition, in which case NaCl is the least of the concerns.
e.g. Acer forced to cancel their "non compatible" android fork
Acer wasn't forced. They could have continued, with no legal repercussions. Google just wouldn't have treated them as a member of the club. Amazon has gone very incompatible with their fork and not only is there nothing Google can do about it, I don't think there's even any interest in stopping them.
Google locks in its paying customers, not users. The users are just fodder to be mined and exploited.
Google views both as customers. And Google doesn't lock in its paying customers, either.
As soon as they did, forks would spring up to compete.
No, they wont. When a codebase crosses a million lines of code, it is practically impossible for a completely new team to even fully comprehend the codebase, much less begin to modify it in any important way. Its much easier to begin afresh - which never happens and would take years of additional work.
Nonsense on the "easier to begin afresh" point. That's a common fallacy among software engineers; starting over is almost never cheaper/easier unless you're also redesigning, and often not even then. As for the rest, there are plenty of counterexamples.
An incompetent or corrupt manager can screw his underlings whether there's a formal or informal review process in place.
This is one of the things I like best about the Google process: Managers don't do the reviews. The reviews are done by neutral parties, based on writeups by employee peers and the manager -- and the manager's input is not focused on performance evaluation but on project evaluation -- how important/impactful is the project.
Also, manager ratings are heavily influenced by the ratings of their employees in addition to the team results, so they're motivated to help their employees be ranked highly as well as to be successful.
There are many problems with that approach.
The first problem with managing at the team level is that you don't have any way to identify which are your strong contributors and which are dragging the team down. It's possible that while the team met its goals, it would also have met them just as well, and at lower cost, if one or two team members were removed, or perhaps it would have accomplished more if one of them were replaced with someone better. In pathological cases it can be true that removing a person increases team effectiveness, though those cases tend to be so bad that it's very visible to everyone in the vicinity of the team.
A related problem is that without a way to identify the strong contributors, you don't have a good way to grow those people into greater levels of responsibility and impact. And it's harder for employees to move between teams, even at the same level of responsibility, without some sort of objective measure the receiving manager can use to evaluate whether or not the person is going to be a good contributor. These issues are related to lack of individual measurements, rather than not tying measurements to employment and pay, but if the measurements aren't tied to employment and pay, odds are the measurements aren't going to be very good, because few will really care about them.
Finally, it fails to scale, in at least two ways. One, it's almost guaranteed to drag a lot of deadwood along when you get larger teams (this is the first problem, but it gets worse with scale, fast). Two, as you expand your scope to a much larger level, with many dozens (or hundreds) of teams, with lots of different managers, it leaves you with no way to ensure any level of consistency with how employees are being treated and managed. Excessive inconsistency has all sorts of negative effects.
The trouble is that VLHC does not enrich the friends of the politicans and so will not be looked on favourably.
Maybe we should encourage Halliburton to get into the supercollider construction business?
I can understand RC4.
I can understand MD5.
But SHA1? right now, according to wikipedia, a full collision attack requires something like $2.77M of computing power on the cloud... maybe a less if you have you own supercomputer, but even at $1M it sound a lot...
So why warn away from SHA1 NOW? what are we going to use? md5? md4?
Because SHA1 has known weaknesses, even if they're not practically exploitable, and because attacks always get better. Would it shock you to hear tomorrow about a new attack on SHA1 that allows collisions to be generated for a few hundred dollars of computation? It wouldn't shock me. I don't expect it, but it would not be surprising.
The alternative to SHA1 right now is SHA2. Or if you want you can use Keccak as published, but you may have to change it when the final standard is released. Depending on the context that may be reasonable.
Microsoft is just repeating here what the security community has been saying for a few years now: SHA1 is okay, but new systems should be designed with SHA2, and old systems should be prepared to move if SHA1's weaknesses get much worse. As soon as SHA3 is standardized (or the community decides to pick an alternative as a standard, as bill_mcgonigle suggests), then new systems should use that.
I'll start taking microsoft seriously on this once they phase out MD4, RC4, MD5 from their existing standards and products.
Well, yes, there is that.
I should also mention that RC4 is in much the same boat as SHA1. As long as you discard enough of the initial keystream bytes, it's fine for use today and for the foreseeable future. But the cracks in its shell mean that new systems should use something better. AES is the obvious, and perfectly adequate, solution. In counter mode if you need a stream cipher.
Playing devils advocate no password hash is really secure even if you check salt, algorithm and amplification boxes unless password itself is unrealistically good.
Passwords have a variety of problems but being subject to brute force attacks needn't be one of them. Their security (or lack thereof) relies on exploiting the asymmetry of effort required to verify vs crack, and reasonable passwords have on the order of 30 bits of entropy. That does require that the password be fairly good, but not "unrealistically good". The key is to calibrate the computation required to verify the password so that searching is infeasible. For example, if it takes 1/10th of a CPU-second to verify the password, then it will take ~3 CPU years to search the password space. If that's not enough for your application, slow the password-verification algorithm down so it takes a second, or whatever other value is appropriate.
There are several key derivation functions (e.g. PBDKF2, bcrypt, scrypt) which allow the run-time cost of the algorithm to be adjusted as needed.
The biggest problem with passwords is password reuse. You can't realistically expect people to manage tens, much less hundreds, of reasonably good passwords. Honestly, two or three is about the limit. And all it takes is for one system to do a bad job with password hashing and storage, and then lots of accounts on lots of systems are compromised/
I think the guys who designed original TLS PRF conceptually had the solution about right XORing multiple hash algorithms such that if one fails the underlying thing is not totally doomed.
Either multiple algorithms, or a structure that allows new algorithms to be swapped in quickly, or both. One thing working in our favor is that there is usually plenty of warning before someone finds a practical collision generation algorithm. And even MD5 still doesn't have any second pre-image attacks. Arguably, MD5 is just fine for signatures even today, as long as the rest of the protocol is designed to limit the value of random collision pairs.
MD5 is broken, SHA1 has been weakened slightly but it isn't broken. The term broken is only used when it is trivial to crack and/or forge.
Sorry to nitpick it really depends on how you use the algorithm. MD5 is broke for signatures yet still perfectly acceptable for other purposes.
This is true of anything. All statements about security are relevant only within a given set of threat models.
Measuring people is fine. Giving the measurements an impact on employment and pay destroys collaboration, and as a secondary effect it attaches a larger incentive to working fast (so you can show your manager a big list of accomplishments) instead of attaching an incentive to doing high quality work (which might lead to a shorter list of accomplishments, but fewer security holes and other errors that need to be fixed later).
Giving the measurements an impact on employment and pay is necessary, and it needn't destroy collaboration or incent accumulation of technical debt; it depends how the measurements are defined. Doing it well is hard, and requires judgment and regular fine tuning, but you have to have some way of making those employment and pay decisions, and doing it as objectively and as measurably as possible is much better than the alternative.
Once Google has control of the UI we all use and the API, they get to say what applications run on it
Except that after Google proves out an idea (or while Google is proving out an idea), they also work with standards committees to help turn the new technologies into standard which all browsers can implement, and which any web app developers can use.
Don't forget that currently, all NaCL applications are approved by Google and are exclusively distributed by "Google Play".
Umm, that's not... oh, you already know that's not true.
You may say there are alternative markets, but those are fragmented and most are riddled with malware and pirated software. Anything commercially viable, apart from maybe Cydia is run and/or controlled by Google.
So what you're saying is that Google doesn't run and/or control everything. Agreed. And since all of this stuff is open source and will be standardized, Google can never run and/or control it completely. Of course, if they do such an excellent job that no one has any incentive to set up a competing system, it'll appear that they're in charge, but only in the same sense that Linus Torvalds runs and/or controls Linux. Yes, he does... but only as long as and to the extent his decisions and actions serve most everyone's interests. Open source is like that.
People that own an official Android device will in the near future have the ability to use all their Android apps on all their devices
Cite? I work for Google and I haven't heard this. It would seem to make sense, but I haven't heard of anything in that direction. And I don't see how it's related to NaCl, given that Android is a Java-based platform and it would be easier to use existing JVMs plus an appropriate set of libraries to support Android apps on other devices.
providing they run Google's Chrome, not some other browser that just happens to support NaCl
Uh, why will Chrome be required? And I'm still not clear how NaCl relates. You've lost me.
This will mean a very large domination of the application market for Google, rendering all other web browsers and end-user operating systems insignificant.
That would be a bad outcome for Google. Seriously. Not only would it offend the sensibilities of the 20+K engineers at Google (that's putting it mildly... I see torches and pitchforks at TGIF), it would put Google in a very tenuous position with respect to anti-trust regulators. Google has already been facing anti-trust investigations, and has largely beaten them all precisely because Google is careful not to lock users in.
I think we have a right to be worried here. It's not about the ability, but the viability of a fork. Even if it were technically superior, it'd still lose.
It would only lose as long as Google didn't actively exploit the control you're theorizing. As soon as they did, forks would spring up to compete. Heck, there's already at least one serious and successful fork of Android: Amazon's OS, which has a non-trivial fraction of the Android tablet market and which pretty much completely locks Google out.
(ObDisclaimer: I work for Google, but I don't speak for Google.)
That's not the problem. I mean, it's a problem. But the real problem is trying to apply numerical methods to personal subjective assessment.
There's nothing wrong with that. Given enough subjective rankings you can assemble them into something quite objective.
The problem is in applying statistical distributions to small samples. Given a few hundred employees, a bell curve may well be a good descriptor. Given five, it's a bad one with very high probability (you can actually calculate the probability for a given measure of deviation).
Also, even if you have a sufficiently large sample so that the curve is a good model for performance, that doesn't mean the lower tail of the curve should be fired. If the worst employee in the bunch still generates more revenue than his or her net cost, then there's a good argument that no one should be fired. You can also take the view that those bottom people are probably worse than whoever you'd hire to replace them... but that's a slippery argument, and one that is often made without full consideration of the cost of separating one person and onboarding another, and without consideration that perhaps the poor performer just needs some encouragement, or is only doing badly because of some concerns outside of work which may be resolved before too long, or could be resolved faster with a little assistance.
Curves are useful models if you have statistically-significant populations, but even then they still have to be applied with intelligence.
FWIW, Google uses stack ranking, too, although in a different way. I would expect Marissa is bringing more of a Google approach to Yahoo than the MS approach, but I could be wrong.
In Google's version, the rankings are done by peers, not managers, and they don't rank all of their peers, just a randomly selected subset (3-4 of them). I'm guessing all of the separate stacks get combined somehow (pairwise voting algorithms like the Condorcet method would work well) to provide some overall stack, but even then the result is only used as one input to performance evaluations, and not a heavily-weighted one. I'm told that its function is to double check the main evaluation method.
It's also possible his body simply became more efficient with handling the same number and type of calories each day
You mean less efficient.
Meh. I have several drives with no reallocations, but I also have several with many reallocations... and they've been ticking along that way for years.
My home file server has eight drives, half have reallocations, half don't. The drive that died a few months ago had no reallocations in daily SMART log when it failed.
Of my three desktop machines (between home and office), one has a drive with reallocations, one has a drive with none, and one has an SSD.
But this is all anecdotal. The 2007 Google study (covering hundreds of thousands, perhaps millions, of drives) found that there is a correlation between reallocations and failures, but it's only a predictor of moderately-increased likelihood of failure, not a guarantee. Given the direction of drive designs in the last few years, I'd expect that predictor to have weakened.
The sectors that were re-allocated before the drive left the factory don't show up in this number.
And? Reallocations happen all the time.
Many musicians use lyrics sites to check if it's an original idea versus a existing one.
Then they can use any of the handful of lyrics sites which license the lyrics and can legally distribute them. This isn't going to make the lyrics unavailable, just reduce the number of sites that all distribute the same content.
It's six years old now, so perhaps drive failure characteristics have changed, but this study got some different results from a study published by Google in 2007. Google's study obviously involved a lot more than 25,000 drives.
For one, Google didn't observe a strong bathtub curve. They did see some infant mortality, but it was during the first 3-6 months, and the first-year failure rate was still lower than in subsequent years, so what "bathtub" there was hit the low point prior to the one-year mark and then began to climb.
The failure rates Google observed were also much lower. Perhaps drives have gotten less reliable.
Google also reported a lot of detail about how various SMART-reported values correlated with failures. Too bad Backblaze didn't do the same. It would have been very interesting.
Having said that, I count sector reallocation as a failure. In my experience, as soon as a disk has non-zero value in Reallocated_Sector_Ct and Reallocated_Event_Count, it usually fails completely within a few weeks or months.
How old is this experience, and what size drives are you using?
Modern drives have gotten so big, and so aggressive with the way data is packed onto them, that failed sectors are normal. When you have billions of sectors, the error rate that would be required to never have a failure is infeasibly low, so modern drives are designed to monitor and reallocate as necessary, and they have large pools of sectors available for reallocation.
If you're really returning any drive with a reallocated sector I'm not surprised in the least that you're seeing a high failure rate. In fact, I'm more surprised that you manage to keep any drives for more than a few months. I suspect you're returning a lot of perfectly good drives.
But did consumption go up or did video bit rate go up? Maybe more people are now selecting "HD" streaming than they used to.
And they're probably torrenting higher video bit rates, too.
My money is on the first supposition in the summary being right: The legal services have gotten good enough, and cheap enough, that people have less incentive to reach for illegal torrents.
How do you reconcile,
Google really doesn't want to track you if you don't want to be tracked.
with
Virtually everything that we want to do, I think, is somewhat at odds with locking down all of your information for uses you haven’t contemplated yet. - Larry Page
If you don't want to be tracked, Google will not be able to provide you with the services Page was talking about. There's no contradiction, particularly when you realize that Page is thinking about services like Google Now, which use information about you to predict what information you need and proactively help you. If you lock down all of your information it is impossible to provide those services.
Google wants to make its services so compelling and useful that you'll actually find sharing your personal data with Google to be a net positive for you, but at the same time wants you to make that decision, and will honor your choice. I repeat, there is no contradiction.
If you have one, you might want to do some soul-searching about the evil company you work for.
Right, because giving people a lot of awesome free services in exchange for seeing some targeted ads is really terrible. Your definition of "evil" is more than a little bit skewed.
Whatever that means, YouTube and Google+ are two different websites in the most basic literal sense; they have different urls.
Meh. Youtube.com and www.youtube.com are different URLs, too, as are gmail.com and mail.google.com, and if I thought about it I could come up with a dozen different examples where the same content is accessible from different hostnames at the same level in the hierarchy as well. I fail to see how any of this matters. The same content is visible to the same people (everyone, or a more limited set if you chose to limit it).
Swillden wrote:-
People care about safety of their vehicles
Some do. Some don't.
Enough do.
Well, demand is inelastic if you assume it to be.
If road/car safety was left to the "invisible hand" then people would still be driving around with "DIY LPG conversions" - An 80kg LPG cylinder strapped to the roof racks of station wagons, like a torpedo waiting to be launched in the event of a frontal collision.
Nonsense. People care about safety of their vehicles. A lot. The one thing that government regulators did that really made a difference was to establish safety testing protocols and mandate that they be applied. Vehicle safety has far outstripped the regulatory baseline requirements, because once reliable vehicle safety information was available it became a major selling point, which caused the invisible hand to get really serious about safety.
IMO, this illustrates the most effective form of government regulation: Ensure that high-quality, reliable comparative product information is widely available, then let purchasing decisions drive the market. Granted there are cases in which an information-only approach isn't sufficient, but they're not the common case, and it's always better to try the light touch first in the absence of compelling evidence that it won't work.
"Control" here means that youtube comments don't wind up being posted anywhere but in youtube.
Well, until someone decides to copy them, anyway. Trying to control stuff you post on the public Internet is... optimistic.
In any case, I think you're under some misapprehension that Google+ is somehow distinct from YouTube. YouTube comments aren't "being posted" on Google+. It's the same system.
I quit Facebook after I absently clicked on a video of "Miley Cyrus shows off new bikini body" in HULU, and Facebook informed everyone I went to high school with.
Yeah, I dropped Facebook for the same kind of crap, except that I didn't wait for them actually to spread something about me around. As soon as I noticed they had lowered my privacy settings without even notifying me, I deleted the account. Google doesn't do that sort of thing. Well, they did a milder form of it once (Buzz auto-friending), but learned the lesson -- and got slapped with an FTC consent decree that mandates all sorts of internal and external review of Google's privacy-related actions, so even if Google hadn't internalized the lesson already, the FTC watchdogs are there to make sure.
I think we're going to see a surge in the prevalence of natural gas-powered ICE vehicles as well, plus a gradual rise in EVs.
I'll ignore your silly Republican-baiting.