The only problem is what to do with the grown-ups who don't want to work 100 hour weeks anymore.
Do you have any evidence that people at Microsoft do work 100-hour weeks? I see this assumption on slashdot a lot, often applied to my employer (Google) where I know it isn't true. I suspect that it's also not true at Microsoft (hmm, I know a couple of people who used to be at MS; I'll ask them next time we chat).
Is there any reason why those negative things are inherent to unionizing?
That's debatable. It may be something like asking whether the abuses and poverty seen in every attempt to implement communism are inherent to the system. They're clearly not its aim, but they always seem to accompany it.
Union rules seem always to evolve in favor of either purely seniority-based systems or very flat compensation structures. Either one eliminates motivation to work hard. The problem is that their quest for fairness makes it impossible for employers to exercise any judgement in pay or promotions, because there's always at least a little subjectivity in such decisions. Attempts to document and justify everything to remove subjectivity results in a complex maze of rules and a great deal of overhead, so the rules are made very simple and in the process most motivation for hard work and efficiency is removed.
Unions are great when they focus on things like benefits and median pay. But even if they start there, they never stop there, because they have to justify their continued existence and expense.
Their quest for World Domination(tm) may come back to bit them.
But Google's quest for world domination won't?
A competitive duopoly is much better for consumers than a monopoly. Even more players would be better, but network effects are going to inherently favor the emergence of a small number of big online retail and distribution systems. Two major competitors with a handful of minor players seems to be the common pattern that emerges.
It has been looking like we were running headlong toward an online retail monopoly, and I don't see how anyone other than Google (or maybe Microsoft... but it would be much tougher for them) could have both the capital and the online mindshare needed to make a go of it. Frankly, I'm still quite skeptical that Google will succeed.
This, by the way, is what I think is really foolish about the EU ruling about Google Shopping. The real competition isn't between Google and the small players who were complaining about not getting free placement on Google's search engine. That's a sideshow. The real competition is between Google and Amazon. Increasingly, people (myself included, frankly) don't search for products they want to buy on Google, they go straight to Amazon. Hindering Google's ability to provide broad-reaching and useful product searches is just going to cement Amazon's monopoly position, and there's no obvious anti-trust play to limit Amazon, because they've managed to define their market space as "Everything".
Don't get me wrong. I really like Amazon. I search for stuff I need to buy there because I know I'll find it, the price will be reasonable, it'll show up quickly (I generally filter for Prime only), and if I have problems they'll take care of me. It's a very rare day at my house that one or more boxes with Amazon logos don't show up on my porch. But I get nervous when a single player controls an entire market. I'd like to use someone other than Amazon from time to time, just to ensure there's some competition in the online retail space.
Google is the only company positioned to have a prayer of being that competing service, and Google is very far from having everything needed to do it. Google + Wal-mart + Target have the pieces, but integrating them all into an operation as smooth-running as Amazon's is going to be a bitch, and it's extremely likely that friction between the companies is going to doom the effort. Wal-mart in particular is well-known for being incredibly hard to work with, used to dictating terms to everyone, and it's clear that nothing less than the threat of Amazon could have motivated them to work with anyone. Google and Target seem well-matched, but Target by itself doesn't have enough reach; they need Wal-mart's enormous distribution network.
So... this is a very good thing for consumers. The only question to me is whether it's enough, soon enough. It would have been much better if these companies decided to team up three or four years ago. It would be even better if another competitor or two could emerge, but I really don't see how that's possible.
(Disclosure: I work for Google, but that really has nothing whatsoever to do with my attitude about this. In fact, given the fact that I get paid partly in Google stock, I'm a little worried that this move may drag Google's profits down. But as an economically-literate consumer I'm really glad to see it.)
Arguments about how much something "should" cost are silly. Things should cost what people are willing to pay for them, period. There's a soft lower bound (cost of production and distribution), but the upper limit is set by the buyers and the competition. There is no "should" in pricing, only what works and what doesn't.
So I'm supposed to believe that all of the engineers at Google can't figure out how to adjust the sensitivity of this sensor. I think it's far more likely that they simply got caught.
If Google intended the devices to listen all the time, they were rather stupid. They forgot to stop the "I'm listening" lights from coming on all the time, and forgot to scrub the "extra" audio recordings from the list shown on the user's Google Home page.
If this is Google being sneaky, they're really, really bad at it.
You can't decompile the binary if you can't get to it - if its encrypted in firmware and taking the lid off the chip destroys it.
In that case, and if it's not feasible to patch it, and if you've really done your due diligence (pen testing), then secrecy might make sense. But, really, it's the "not feasible to patch it" that is the reason for and justification of secrecy, not the rest.
Nit: if the firmware is inaccessible, there's no reason to encrypt it. Unless you have another even more secure component inside which holds the decryption key? And there's no point in that unless that other more secure component not only decrypts the firmware but also plays some other more crucial role in the secure operation, meaning it is your true trust boundary.
Also note that it's never completely inaccessible. You can raise the bar, make penetration very expensive, but you cannot make it impossible. Therefore, unless you have some constraint that makes reactive security (patching) impossible to exercise in a timely fashion, you should get as much scrutiny of your design and implementation as possible and fix all of the vulnerabilities found, quickly. Even if it's inside "secure" hardware.
The systems I was referring to did in fact have sealed boxes where if tampering was detected the memory was wiped.
Then the obscurity wasn't *completely* pointless. But still mostly pointless. If your algorithm is broken, "adding a few bits" is extremely unlikely to make any difference. If it's not broken, then adding a few bits makes no difference... and by keeping it secret you're running the risk that you have serious flaws that you don't know about, which could completely destroy the security. Bad idea.
More generally though by keeping code secret, even on publicly available software, you'd be forcing a state funded actor to put the resources to decompiling the code.
Which takes seconds.
The code would then have to be examined for vulnerabilities. By handing over the original code there's much more information to work with.
A little, sure. Enough to matter? Not at all. I work with a lot of people who do reverse engineering for a living. Not having source slows them down very, very little.
Also, I note that you did not confirm that your organization had outside penetration testing done. That right there proves that your organization doesn't know how to write secure software. Please tell me what hardware we're talking about so I can avoid it.
Oh come on, you think nobody has thought of that and doesn't game the algorithm to make a load of pointless and unnecessary memory accesses in order to fool anyone with a logic analyser sitting on the bus? These days the speed hit doing so is almost irrelevant.
The speed hit is not irrelevant. Performance is still a significant challenge for many applications, even on desktop and server class machines -- and definitely for mobile and embedded.
And it wouldn't matter much anyway. Worst case (and very unlikely) it might make the attacker have to bother with decompiling.
By keeping the algorithm a secret then we have effectively added a few more bits to the key.
You didn't, really.
If the attacker has your binary, decompiling it is not hard. I don't even have to decompile it in most cases, merely watching how the pattern of memory accesses is generally enough to identify at least the class of algorithm used (there aren't that many), and examination of S boxes etc., tells the rest. And if the algorithm you used is remotely close to breakable -- by brute force or any other means -- then you're hosed.
Obscurity is very foolish except in one case: security hardware which has internal storage, and can't practically be updated. A good example is a smart card chip. In that case, all you can do is do the best job you can on the software, and the best job you can do on the hardware (whose job is partly to deny the attacker access to your software), and then keep it secret. Assuming the hardware doesn't leak it, and you don't leak it, then the attacker can only blindly fuzz the device to look for vulnerabilities.
In practice, though, smart card makers don't do that either. They do provide full details of hardware and software, including source code, to a couple of highly-capable test labs, who spend many months poring through all of it as well as fuzzing it, attempting physical penetration of the hardware and everything else they can think of.
If your organization did that, hired multiple outside teams of extremely talented people to attack your implementation, and you kept the attacker away from the binary as well as the source, then perhaps you gained something from the obscurity. If not, you just fooled yourselves, and made your product weaker than it would have been if you had published the design and the source code for the world to beat on.
It's a distinction with an enormous difference -- around 90% difference, which is the proportion of vehicles which are not replaced every year.
As for the volumes... The Netherlands buys about 400K vehicles per year. That's not going to be a problem given the number of car manufacturers tooling up for EVs. How they're going to manage charging for all of the apartment dwellers that park on the street, that may be a problem. But, I think, a manageable one. Especially since most of those apartment dwellers will probably just give up having a car before 2030, preferring instead to use self-driving taxis.
It is very important to note that Apple and Alphabet will definitely stop innovating and will reach a point of stasis if there is no alternative.
I don't think this is the case at all... and I don't think that just because I work on the Android OS. I think that because I recognize the power of the network effect at work.
There are many, many examples. In most cases, the network effect leads not to a duopoly, as in the iOS / Android case, but a monopoly or near monopoly. In the case of operating systems, there has never been a class of machine with a large variety of operating system, not after computing was commercialized. Perhaps the closest thing we ever saw to a really diverse ecosystem was the proliferation of Unix variants for high-end workstations and servers in the late 80s and early 90s, and that only happened because POSIX made them a single platform with variations, with strong source compatibility. On the desktop, we've never seen a diverse ecosystem: Microsoft has owned it with Apple maintaining a small niche.
What about operating systems lends itself to a network effect? Several things, but the biggest one is applications. Where there are lots of users, there are lots of application developers. Where there are lots of application developers, there are lots of users. In fact, the rise of the web as a super-platform, a platform that runs on a variety of other platforms, has softened the network effect in desktop operating systems and enabled OS X to rise to double digit market share and Linux-based OSes (notably, ChromeOS and Ubuntu -- in that order) to rise above a rounding error. But Windows still rules the roost.
The only thing that has actually managed to unseat Windows was the rise of an entirely new platform. Microsoft had a chance to own that one as well, but screwed it up. Apple managed to carve out an even bigger niche through a first mover advantage and more fragmentation in the competition, but still ultimately lost to the OS that ran on more kinds of devices and addressed more price points. Had Google standardized the Android phone as thoroughly as IBM standardized the IBM PC, Apple's market share would be even smaller. But because Google open sourced the Android OS, hardware makers could customize it and the resulting fragmentation has helped to keep iOS in the game.
And smartphones have, like desktops, reached a point of stable maturity. There is innovation left to be done (there always is), but it's in the decimal places, as it were. The shape, primary feature set and user interface metaphors have crystallized. Perhaps something as radical as arbitrarily bendable devices, or radically different I/O technologies can break it loose again, but without that, smartphones are essentially what they're going to be. Oh, they'll keep improving in small ways, but that's it.
Likewise, the phone app space is pretty stable and mature. There is already an app (or 20) to do most everything that users want to do, on both the Apple App Store and the Google Play Store. Any new smartphone operating system will find it extremely difficult to compete against those app stores. Honestly, the best way to do it right now is probably to be Android-compatible, but to try to do something different that is sufficiently useful. But it's really not obvious what that could be. Andy Rubin is trying with the Essential Phone, but it's not going well.
No, I think that what is going to unseat Android and iOS is an OS for another entirely new platform. My bet is that it will be some form of wearable, but I have no idea what kind. Perhaps watches (so far they aren't compelling), perhaps networked processors built into all of our clothing, I don't know.
I wouldn't count on that next platform shift to unseat Apple and Google, though. Apple has already proven itself agile enough to make the leap (though that was with Jobs, which made a difference. He was an asshole, but he was good at seeing what people want), and I think Google is equally capable of doing it (though with more of a shotgun-and-see-what-sticks approach). I'd give each company at least a 30% chance.
They are shifting the cost of protecting customer information on to the customer. Which is a bad idea - merchants have the resources to protect that info
Who cares if your 1 mWh battery pack, which has been in use for 20 years, now only stores 500 kWh?
Pretty much anyone who operates a battery facility will care - because practically none will ever be built with 100%+ space margins. Space and square footage cost money to build, and money to maintain.
You should look at the pictures of the systems Tesla has installed. The batteries are in cabinets set outdoors, in large open spaces adjacent to ranks of solar panels. Lots of room for more battery cabinets. Given that you need such large open areas for solar panel farms, it seems extremely unlikely that any installation is going to be so space-constrained they can't throw in some more batteries.
As long as the color of the link isn't overly distracting - darker shades of green, blue, grey, etc work well if the text itself is black - then I am fine with it.
How do you know? Are you just reporting your subjective perception, or have you actually tested it?
Subjective perceptions of cognitive performance are often terrible.
No, I'm willing to accept a solution that lowers highway accidents across the board. Keep in mind that being a good driver does not keep you safe on the road.
The point that you're ignoring is that the relevant companies have expressed their intent to accept full liability for any accidents caused by their systems. That's the truly compelling argument.
As all the current SDCs in existence require a human anyway
As far as I know currently available lithium batteries still wear out after 1,000 cycles and slightly more for LiFePo4.
Powerpacks are warrantied for 10 years, and it's not like they just suddenly "die" after that. Li-ions suffer their most capacity drop in their first year of operation / first 50-100 cycles, but the rate of loss declines after that. As an example with Teslas, the average capacity loss is 4% in the first year, but by year 5, typical total capacity loss averages only 6-7%.
Once vehicle power packs have lost a significant percentage of their capacity, their energy/mass and energy/volume ratios drop enough that t makes sense to swap them out for new ones. But except in locations with unusual space restrictions, land-based batteries have no such concerns. Who cares if your 1 mWh battery pack, which has been in use for 20 years, now only stores 500 kWh? Unless something else is wrong with it, you don't replace it, you just install an additional 500 kWh battery to make up the lost capacity.
For that matter, as the use of electric vehicles grows, all of those EV batteries that have lost 10-20% of their capacity after years of hard use and need to be swapped out can easily be repurposed for bulk energy storage. This will make a large supply of very inexpensive batteries available.
Slashdot Mirror
The only problem is what to do with the grown-ups who don't want to work 100 hour weeks anymore.
Do you have any evidence that people at Microsoft do work 100-hour weeks? I see this assumption on slashdot a lot, often applied to my employer (Google) where I know it isn't true. I suspect that it's also not true at Microsoft (hmm, I know a couple of people who used to be at MS; I'll ask them next time we chat).
Is there any reason why those negative things are inherent to unionizing?
That's debatable. It may be something like asking whether the abuses and poverty seen in every attempt to implement communism are inherent to the system. They're clearly not its aim, but they always seem to accompany it.
Union rules seem always to evolve in favor of either purely seniority-based systems or very flat compensation structures. Either one eliminates motivation to work hard. The problem is that their quest for fairness makes it impossible for employers to exercise any judgement in pay or promotions, because there's always at least a little subjectivity in such decisions. Attempts to document and justify everything to remove subjectivity results in a complex maze of rules and a great deal of overhead, so the rules are made very simple and in the process most motivation for hard work and efficiency is removed.
Unions are great when they focus on things like benefits and median pay. But even if they start there, they never stop there, because they have to justify their continued existence and expense.
Their quest for World Domination(tm) may come back to bit them.
But Google's quest for world domination won't?
A competitive duopoly is much better for consumers than a monopoly. Even more players would be better, but network effects are going to inherently favor the emergence of a small number of big online retail and distribution systems. Two major competitors with a handful of minor players seems to be the common pattern that emerges.
It has been looking like we were running headlong toward an online retail monopoly, and I don't see how anyone other than Google (or maybe Microsoft... but it would be much tougher for them) could have both the capital and the online mindshare needed to make a go of it. Frankly, I'm still quite skeptical that Google will succeed.
This, by the way, is what I think is really foolish about the EU ruling about Google Shopping. The real competition isn't between Google and the small players who were complaining about not getting free placement on Google's search engine. That's a sideshow. The real competition is between Google and Amazon. Increasingly, people (myself included, frankly) don't search for products they want to buy on Google, they go straight to Amazon. Hindering Google's ability to provide broad-reaching and useful product searches is just going to cement Amazon's monopoly position, and there's no obvious anti-trust play to limit Amazon, because they've managed to define their market space as "Everything".
Don't get me wrong. I really like Amazon. I search for stuff I need to buy there because I know I'll find it, the price will be reasonable, it'll show up quickly (I generally filter for Prime only), and if I have problems they'll take care of me. It's a very rare day at my house that one or more boxes with Amazon logos don't show up on my porch. But I get nervous when a single player controls an entire market. I'd like to use someone other than Amazon from time to time, just to ensure there's some competition in the online retail space.
Google is the only company positioned to have a prayer of being that competing service, and Google is very far from having everything needed to do it. Google + Wal-mart + Target have the pieces, but integrating them all into an operation as smooth-running as Amazon's is going to be a bitch, and it's extremely likely that friction between the companies is going to doom the effort. Wal-mart in particular is well-known for being incredibly hard to work with, used to dictating terms to everyone, and it's clear that nothing less than the threat of Amazon could have motivated them to work with anyone. Google and Target seem well-matched, but Target by itself doesn't have enough reach; they need Wal-mart's enormous distribution network.
So... this is a very good thing for consumers. The only question to me is whether it's enough, soon enough. It would have been much better if these companies decided to team up three or four years ago. It would be even better if another competitor or two could emerge, but I really don't see how that's possible.
(Disclosure: I work for Google, but that really has nothing whatsoever to do with my attitude about this. In fact, given the fact that I get paid partly in Google stock, I'm a little worried that this move may drag Google's profits down. But as an economically-literate consumer I'm really glad to see it.)
Hard to figure why it should even cost that much.
Arguments about how much something "should" cost are silly. Things should cost what people are willing to pay for them, period. There's a soft lower bound (cost of production and distribution), but the upper limit is set by the buyers and the competition. There is no "should" in pricing, only what works and what doesn't.
So google disables a feature on a pre-production product someone got for free as a promotional giveaway because they have found it defective.
FTFY.
Sounds to me like google should be providing a replacement instead of just disabling it and calling it a day.
Google gave two replacements to the guy who reported the bug. The production devices people buy will not have this defect.
So I'm supposed to believe that all of the engineers at Google can't figure out how to adjust the sensitivity of this sensor. I think it's far more likely that they simply got caught.
If Google intended the devices to listen all the time, they were rather stupid. They forgot to stop the "I'm listening" lights from coming on all the time, and forgot to scrub the "extra" audio recordings from the list shown on the user's Google Home page.
If this is Google being sneaky, they're really, really bad at it.
There's a name for governments that dictate what people can and cannot buy, that's a dictatorship.
By this definition, every government in the world is a dictatorship.
You can't decompile the binary if you can't get to it - if its encrypted in firmware and taking the lid off the chip destroys it.
In that case, and if it's not feasible to patch it, and if you've really done your due diligence (pen testing), then secrecy might make sense. But, really, it's the "not feasible to patch it" that is the reason for and justification of secrecy, not the rest.
Nit: if the firmware is inaccessible, there's no reason to encrypt it. Unless you have another even more secure component inside which holds the decryption key? And there's no point in that unless that other more secure component not only decrypts the firmware but also plays some other more crucial role in the secure operation, meaning it is your true trust boundary.
Also note that it's never completely inaccessible. You can raise the bar, make penetration very expensive, but you cannot make it impossible. Therefore, unless you have some constraint that makes reactive security (patching) impossible to exercise in a timely fashion, you should get as much scrutiny of your design and implementation as possible and fix all of the vulnerabilities found, quickly. Even if it's inside "secure" hardware.
I can assure you that the organization I worked for does know how to write secure software.
Maybe, but I'm skeptical.
The point is, and you admit to it, that not having the source code will slow down an attack.
Trivially.
We can debate how much but knowing it will slow down an attack is sufficient to go through the effort of keeping certain design choices secret.
No. That is not enough to justify reliance on secrecy. There has to be some other reason, or it's just self-deception.
The systems I was referring to did in fact have sealed boxes where if tampering was detected the memory was wiped.
Then the obscurity wasn't *completely* pointless. But still mostly pointless. If your algorithm is broken, "adding a few bits" is extremely unlikely to make any difference. If it's not broken, then adding a few bits makes no difference... and by keeping it secret you're running the risk that you have serious flaws that you don't know about, which could completely destroy the security. Bad idea.
More generally though by keeping code secret, even on publicly available software, you'd be forcing a state funded actor to put the resources to decompiling the code.
Which takes seconds.
The code would then have to be examined for vulnerabilities. By handing over the original code there's much more information to work with.
A little, sure. Enough to matter? Not at all. I work with a lot of people who do reverse engineering for a living. Not having source slows them down very, very little.
Also, I note that you did not confirm that your organization had outside penetration testing done. That right there proves that your organization doesn't know how to write secure software. Please tell me what hardware we're talking about so I can avoid it.
BasilBrush already replied adequately, so I won't bother.
Oh come on, you think nobody has thought of that and doesn't game the algorithm to make a load of pointless and unnecessary memory accesses in order to fool anyone with a logic analyser sitting on the bus? These days the speed hit doing so is almost irrelevant.
The speed hit is not irrelevant. Performance is still a significant challenge for many applications, even on desktop and server class machines -- and definitely for mobile and embedded.
And it wouldn't matter much anyway. Worst case (and very unlikely) it might make the attacker have to bother with decompiling.
By keeping the algorithm a secret then we have effectively added a few more bits to the key.
You didn't, really.
If the attacker has your binary, decompiling it is not hard. I don't even have to decompile it in most cases, merely watching how the pattern of memory accesses is generally enough to identify at least the class of algorithm used (there aren't that many), and examination of S boxes etc., tells the rest. And if the algorithm you used is remotely close to breakable -- by brute force or any other means -- then you're hosed.
Obscurity is very foolish except in one case: security hardware which has internal storage, and can't practically be updated. A good example is a smart card chip. In that case, all you can do is do the best job you can on the software, and the best job you can do on the hardware (whose job is partly to deny the attacker access to your software), and then keep it secret. Assuming the hardware doesn't leak it, and you don't leak it, then the attacker can only blindly fuzz the device to look for vulnerabilities.
In practice, though, smart card makers don't do that either. They do provide full details of hardware and software, including source code, to a couple of highly-capable test labs, who spend many months poring through all of it as well as fuzzing it, attempting physical penetration of the hardware and everything else they can think of.
If your organization did that, hired multiple outside teams of extremely talented people to attack your implementation, and you kept the attacker away from the binary as well as the source, then perhaps you gained something from the obscurity. If not, you just fooled yourselves, and made your product weaker than it would have been if you had published the design and the source code for the world to beat on.
That's a distinction without a difference.
It's a distinction with an enormous difference -- around 90% difference, which is the proportion of vehicles which are not replaced every year.
As for the volumes... The Netherlands buys about 400K vehicles per year. That's not going to be a problem given the number of car manufacturers tooling up for EVs. How they're going to manage charging for all of the apartment dwellers that park on the street, that may be a problem. But, I think, a manageable one. Especially since most of those apartment dwellers will probably just give up having a car before 2030, preferring instead to use self-driving taxis.
It is very important to note that Apple and Alphabet will definitely stop innovating and will reach a point of stasis if there is no alternative.
I don't think this is the case at all... and I don't think that just because I work on the Android OS. I think that because I recognize the power of the network effect at work.
There are many, many examples. In most cases, the network effect leads not to a duopoly, as in the iOS / Android case, but a monopoly or near monopoly. In the case of operating systems, there has never been a class of machine with a large variety of operating system, not after computing was commercialized. Perhaps the closest thing we ever saw to a really diverse ecosystem was the proliferation of Unix variants for high-end workstations and servers in the late 80s and early 90s, and that only happened because POSIX made them a single platform with variations, with strong source compatibility. On the desktop, we've never seen a diverse ecosystem: Microsoft has owned it with Apple maintaining a small niche.
What about operating systems lends itself to a network effect? Several things, but the biggest one is applications. Where there are lots of users, there are lots of application developers. Where there are lots of application developers, there are lots of users. In fact, the rise of the web as a super-platform, a platform that runs on a variety of other platforms, has softened the network effect in desktop operating systems and enabled OS X to rise to double digit market share and Linux-based OSes (notably, ChromeOS and Ubuntu -- in that order) to rise above a rounding error. But Windows still rules the roost.
The only thing that has actually managed to unseat Windows was the rise of an entirely new platform. Microsoft had a chance to own that one as well, but screwed it up. Apple managed to carve out an even bigger niche through a first mover advantage and more fragmentation in the competition, but still ultimately lost to the OS that ran on more kinds of devices and addressed more price points. Had Google standardized the Android phone as thoroughly as IBM standardized the IBM PC, Apple's market share would be even smaller. But because Google open sourced the Android OS, hardware makers could customize it and the resulting fragmentation has helped to keep iOS in the game.
And smartphones have, like desktops, reached a point of stable maturity. There is innovation left to be done (there always is), but it's in the decimal places, as it were. The shape, primary feature set and user interface metaphors have crystallized. Perhaps something as radical as arbitrarily bendable devices, or radically different I/O technologies can break it loose again, but without that, smartphones are essentially what they're going to be. Oh, they'll keep improving in small ways, but that's it.
Likewise, the phone app space is pretty stable and mature. There is already an app (or 20) to do most everything that users want to do, on both the Apple App Store and the Google Play Store. Any new smartphone operating system will find it extremely difficult to compete against those app stores. Honestly, the best way to do it right now is probably to be Android-compatible, but to try to do something different that is sufficiently useful. But it's really not obvious what that could be. Andy Rubin is trying with the Essential Phone, but it's not going well.
No, I think that what is going to unseat Android and iOS is an OS for another entirely new platform. My bet is that it will be some form of wearable, but I have no idea what kind. Perhaps watches (so far they aren't compelling), perhaps networked processors built into all of our clothing, I don't know.
I wouldn't count on that next platform shift to unseat Apple and Google, though. Apple has already proven itself agile enough to make the leap (though that was with Jobs, which made a difference. He was an asshole, but he was good at seeing what people want), and I think Google is equally capable of doing it (though with more of a shotgun-and-see-what-sticks approach). I'd give each company at least a 30% chance.
They are shifting the cost of protecting customer information on to the customer. Which is a bad idea - merchants have the resources to protect that info
BWAHAHAHAHAHA! /me wipes tears from eyes.
Do you not pay any attention to the news?
i just can't be blind to their past track record.
What track record are you referring to, specifically?
Pretty much anyone who operates a battery facility will care - because practically none will ever be built with 100%+ space margins. Space and square footage cost money to build, and money to maintain.
You should look at the pictures of the systems Tesla has installed. The batteries are in cabinets set outdoors, in large open spaces adjacent to ranks of solar panels. Lots of room for more battery cabinets. Given that you need such large open areas for solar panel farms, it seems extremely unlikely that any installation is going to be so space-constrained they can't throw in some more batteries.
As long as the color of the link isn't overly distracting - darker shades of green, blue, grey, etc work well if the text itself is black - then I am fine with it.
How do you know? Are you just reporting your subjective perception, or have you actually tested it?
Subjective perceptions of cognitive performance are often terrible.
who wants a battery on their head, its extra weight.
Who wants a wire to their head? It gets caught on stuff and tangled.
Tradeoffs. Personally, I'll take the battery over the wire. But you can actually have wired if you want. It just goes to a different port.
No, I'm willing to accept a solution that lowers highway accidents across the board. Keep in mind that being a good driver does not keep you safe on the road.
Are you commenting on some other thread now? Your responses are increasingly unrelated to what we've been talking about.
As all the current SDCs in existence require a human anyway
Google's doesn't.
Powerpacks are warrantied for 10 years, and it's not like they just suddenly "die" after that. Li-ions suffer their most capacity drop in their first year of operation / first 50-100 cycles, but the rate of loss declines after that. As an example with Teslas, the average capacity loss is 4% in the first year, but by year 5, typical total capacity loss averages only 6-7%.
Once vehicle power packs have lost a significant percentage of their capacity, their energy/mass and energy/volume ratios drop enough that t makes sense to swap them out for new ones. But except in locations with unusual space restrictions, land-based batteries have no such concerns. Who cares if your 1 mWh battery pack, which has been in use for 20 years, now only stores 500 kWh? Unless something else is wrong with it, you don't replace it, you just install an additional 500 kWh battery to make up the lost capacity.
For that matter, as the use of electric vehicles grows, all of those EV batteries that have lost 10-20% of their capacity after years of hard use and need to be swapped out can easily be repurposed for bulk energy storage. This will make a large supply of very inexpensive batteries available.
The "evidence" you referred to in your OP was gained from -always-alert drivers correcting the SD software in perfect conditions.
Nope. I've seen how the Google testing is done. And you're still ignoring the more compelling second point.