The regulations kick in when they're going to production. If they're not prepared to do safety testing and think through how their product interacts with cars in order to make sure that it won't kill people, then they shouldn't be able to sell it. Giving up on that in the US, which is relatively lightly regulated, means that they're certainly out of the EU, Japan, etc. They can probably sell in China, as long as they give 51% of the company to someone with good connections to the Chinese government.
Correction: the FBI is not reopening the case, they're assessing some emails that they found in a different investigation to see if they are relevant. If they are relevant to Clinton, and if they contain classified information, then it's possible in the future that they might reopen the case. But that's not what the FBI said - that's all speculation by politicians looking for a "hook" to keep attacking Clinton.
Revealing which models of devices they bought doesn't reduce their security, unless they're using units with widely known security flaws that they leave open.
Either they're really, really stupid or they think we are. Perhaps both?
If they're basing this on owning the copyright to the Olympics, this isn't going to work - owning a copyright on the name of a thing doesn't mean that you can prevent anyone from talking about your thing, just that nobody else can sell it. Lawsuits like this fail often - confused people think that they can use copyright to do more than control the right to copy...
Why not let users send their position by hitting a button? I'm thinking that it could insert text giving your location in text, or speech into a phone call, if you hit a "send my location" button. Then it'd work not just magically with E911 services (which, of course, is a great thing) but could work on normal phone calls (e.g. a kid calling Mom for help) or SMS (e.g. a kid texting Mom for help). The phone has the info, and it'd be easier to deploy, because it doesn't require any integration to anything outside of the phone.
Actually, collision data is quite clear - reducing speed of collision saves lives because the fatality rate of the accidents drop. The reason is pretty simple - F=MA. Mass of a car, person, etc., are constant. So the faster a car is going, the more acceleration is required to stop the car (i.e. during the collision), and thus the more force acting on the driver and passengers. And enough force kills people.
There's also quite clear aggregate data that highway driving fatality rates dropped when speed limits were reduced, both nationally and at the state level. Of course, at various times seatbelt, airbags, etc., also helped...
The car requires you to manually confirm that you understand that you're responsible for being alert and ready to take over from Autopilot, every single time you enable it. And exactly the same as Autopilot in airplanes, used by pilots for decades. In both cases, the Autopilot is a driver assist, automating a boring task, but ultimately the driver is responsible. Some people might not understand that (as evidenced by some really stupid YouTube videos, and your post) but Tesla is quite clear about the what Autopilot means, communicated consistently to every Tesla driver with Autopilot, and it's consistent with industry use of the term "Autopilot".
In the case of this accident, as often happens in truck under-run collisions, the driver didn't see the truck. Happens many times a year without Autopilot. It's possible that the driver this time wasn't being alert, but truck under-runs kill alert drivers (without Autopilot) routinely, so it's not clear that you particularly need to find anyone to blame this time.
To put it in perspective, look at the numbers. Tesla is 1 fatality for 130m miles driven, or 0.7 per 100m miles. The US average is 1.2 fatalities per 100m miles driven. So while you can't prove anything with small sample sizes (wait for 1B miles driven with Autopilot), it certainly indicates that Autopilot is relatively safe.
Exactly - the car knows speed limits from the maps. The reason that they don't enforce speed limits (outside of residential areas) is that buyers of high-end sports cars don't want speed limits enforced.
If there were a wall across the road, Autopilot would have seen that. Though avoiding a wall that suddenly appears across a highway might be problematic.
In this case, though, it wasn't a brick wall, it was a truck with a raised body. Which means that Autopilot saw clear road ahead (under the body of the truck), with a large flat object above it, like a sign over a highway. Incorrect in this case, but since people make the same mistake routinely (truck under-runs are common) it's not a trivial case. Should Autopilot be better than human drivers? Sure. But that takes lots of experience on the road, tuning the software. So, "silver lining", this accident will make future Autopilot versions safer.
I agree that people can be stupid, and that the software should be improved. Legally, though, since pilots have been flying airplanes with Autopilot that does the same thing Tesla's Autopilot does, and Tesla informs drivers repeatedly that they need to stay alert and ready to take over, just like airplane pilots, I suspect that Tesla's legal situation is pretty clean. The legal/regulatory situation will get more complex once cars are autonomous, rather than semi-autonomous. Until then, drivers are responsible for driving their cars safely, and it's more a matter of education that people learn to use the various safety mechanisms appropriately. If someone intentionally drove into a wall, they can't sue because the anti-collision braking didn't prevent them from doing so.
Might as well ask if they'd like to lose their pilot's license. They're required by law (and ethics) to always be prepared to take control away from the Autopilot, in a fraction of a second.
To support your post, Autopilot has already demonstrated that it's more situationally aware, always alert, and has faster reflexes, than a human driver.
The guy who died in the accident previously posted a video where Autopilot saved his life. A truck changed lanes into his car (presumably he was in the truck's "blind spot"). Autopilot saw the car, and got out of the truck's way, avoiding the accident, in less than a second. A human driver would have been side-swiped by the driver during reaction time.
Perhaps. But airplanes have been flying with Autopilot for decades, and the legal situation is quite clear - the pilot is responsible for flying the plane, and the Autopilot is just an assist that automates some of the boring stuff. But the pilot is required to be alert and prepared to jump in and take over whenever needed. Exactly the same as Tesla's Autopilot - probably why they named it Autopilot was to remind people of that.
Airplanes have had Autopilots for decades, and the pilots are responsible for flying the airplane. And every time you turn on Tesla's Autopilot you have to manually confirm that you know that the driver has to remain alert and hands-on-wheel.
"We just don't have the kind of evolving programs that you think we do."
First, you misread the OP. He didn't say that AI would fix the problem, he said that the software would be improved as a result of this accident, making future cars safer. Which you agreed with.
Second, people have been doing ML with software tuning itself on production data, for several decades now. More recently, perhaps you've heard of Google, Facebook and Amazon? Hand-coded rules don't scale and are nearly-impossible to QA in complex situations, which is why people using large volumes of data use a wider range of techniques, including machine learning / AI. In particular, computer vision is an area that uses tuned neural nets and such quite often, so in this case it's highly likely that Tesla would in fact be retraining their computer vision networks (etc.) to recognize trucks from the side as an obstacle rather than as a billboard over a highway.
One correction - truck under-runs are common for drivers, and highly fatal. While you'd think a truck would be easy to see, it turns out that in reality a light truck pulled square across a road, against a light sky, is surprisingly hard to see. In particular, keep in mind that you can see the road ahead under the truck's elevated body. So, in reality, not trivial to avoid.
There are countries that require trucks to have side walls and bumpers, which would make the truck more visible, and make collisions with them less fatal.
As a data point, so far AutoPilot has 1 fatality for 130m miles driven (a month ago, more now), which is about 0.7 fatalities per 100m miles driven. The US average is about 1.2 fatalities per 100m miles driven. The numbers are small so they don't prove anything (wait for 1B miles driven to start drawing real conclusions) but it certainly suggests that AutoPilot is relatively safe.
No, Autopilot is specifically NOT autonomous driving, it's a driver-assist, where the driver is required to be alert and hands-on-wheel. This is displayed and agreed to by the driver every single time Autopilot is enabled.
That being said, truck under-runs are common and highly fatal for non-automated drivers, even at low speeds, because the raised truck bed bypasses all of the safety measures that cars have in place for car-to-car collisions. Bumpers, crumple zone, seat-belts, anti-collision sensors, etc., are bypassed, and the truck body hits the car roof and driver's head at full speed. IMO, the solution is for trucks to have bumpers running along the side of the truck at the height of car bumpers, so that at least lower-speed collisions are less fatal. Or put in place much more intelligent safety systems in all vehicles, so they all know where everything is...
They released a statement right after the accident saying that there was no indication that either AutoPilot or the driver tried to decelerate. That's consistent with an under-run accident where they didn't see the white trailer against a bright sky. Sadly, trucks are harder to see than you'd expect, so these accidents aren't rare.
MongoDB is clearly a database. It's not an SQL database, but that's kinda the point, in that not being SQL-based makes it much more efficient for developers, and more performant and flexible in accommodating semi-structured data.
I'm not sure why you think anyone would switch languages so frequently they don't release any functional software. I've never seen that happen on any project, other than research where the point was learning the language, not building functionality.:-)
You don't switch languages for no reason. Generally you only do a full ground-up replatforming of a system very rarely (10-15 years), and then because the advantages of the new platform over the old one are compelling. And there could have been hundreds of releases. For example, converting a system with thousands of users from Citrix/VB/Access to Angular/Node/MongoDB has lots of advantages.:-) But you don't do that sort of thing to a system on a weekly basis...
We replatformed a legacy C# app to a modern stack including Node.JS, and are very happy. The "win" wasn't so much the Node.JS language itself as that it was part of a platform that gives us fantastic code development velocity and fluidity. The "stack" includes CircleCI and Docker, MongoDB and Mongoose, Node.JS for a thin web services layer, and Angular (JavaScript) for the user experience, all integrated into HipChat for "ChatOps". Selenium and BrowserStack for end-to-end testing.
I'll agree that JavaScript isn't my favorite language, but the tooling around it is fantastic, making development teams very productive.
The benefits of using Node.JS in the overall stack include: - Same language for the whole stack, so a single developer can implement a whole feature (story). This eliminates the coordination cost of having three different people (front-end JavaScript, server-side C#, and database SQL) having to coordinate for use cases, giving much better velocity. - Node/JavaScript has fantastic testing support, making it fairly easy for us to maintain 90%+ unit code coverage, and end-to-end testing of user paths. This is integrated into the CircleCI builds means that after every code commit we have a fully built, unit and end-to-end tested, and deployed (to a test environment) application. - npm is awesome. It's a great tool, and the community support means many things are very easy. - Mongoose is awesome. - it's very easy to run Node.JS in AWS Lambda, which makes operations easier and is absurdly cheap to run, since you only pay for the compute you actually utilize, measured in fractions of a second. We're building one project in Lambda, and if that works well we'll likely move all the Node.JS code into Lambda, and save a lot of money at AWS. - Yeah, event-driven programming is complex. Luckily promises make it much easier. But in return for wrapping your head around a more complex programming model, you can more scalable applications. Similar tradeoff to multi-threaded programming.
Yes, none of this is about the Node.JS language itself.
Encrypted storage these days works quite well, and is built into Windows and MacOS at no cost. When we have employees working in insecure areas (such as shared offices) we encrypt their hard drives, and there's no noticeable performance impact. If they forget their credentials they lose access to their hard drive, but they also can't get to their email, calendar, file servers, etc., so that's hardly insurmountable.
And the value of encrypting storage is pretty high - if a laptop is lost or stolen, encrypting storage protects source code, email, documents, etc.
To be fair, five years ago the situation was different - the encryption software back then could rendering machines painfully slow, and the productivity cost was too high. But either from faster CPU and disk, or better software, these days disk encryption is free and painless, so it's worth doing.
There are a dew distinct aspects to this (IMO): - There's a fundamental difference between "police can hack into iPhones" and "Apple puts a backdoor into iPhones so that iPhones are trivially hackable by anyone with the key", because Apple's role in the process matters. If Apple's job is to make iPhones secure, the police (and criminals) can of course still hack phones, but any vulnerabilities are treated as bugs to be fixed, and the iPhone gets more and more secure over time. If the police can force Apple to put a backdoor into the iPhone, then when the key is leaked (which always happens, when you give a key to thousands of police departments and other agencies, their contractors and vendors, etc., just as happened with DVDs) then anyone who can get the key can hack any iPhone, rendering it fundamentally insecure, and because it's required by a law, Apple cannot make the iPhone more secure, forever. - The iPhone will never be 100% secure, because there's no such thing as 100% secure - the goal of security measures is to increase the cost/time of a successful attack, but infinite money/time can always ultimately succeed. For example, AES 256 is quite secure, but that just means that brute forcing a key would take enough time and harder (e.g. https://www.reddit.com/r/theyd...) that it's not worth it - you'd have to be a government to have the resources to do so, and very few secrets are worth spending a building full of supercomputers to hack. Every so often new techniques or technologies emerge that can change the equation (quantum computing...) but the same is true of physical locks - if you can photograph a key you can 3D print a duplicate. So it's always been a game of "cat and mouse" between lock-makers and lock-breakers. - Because encryption is software, which can't be controlled globally, any laws restricting encryption only limits what can be embedded in systems from US manufacturers. But it won't have any control over anyone with internet access, since the rest of the planet can (and does) produce uncompromised security systems with no backdoors, which anyone on the planet can download and use (including good open source, free tools). So any law against secure systems won't help against real criminals, because presumably they'll either avoid digital communications (i.e. what real terrorists do now) or use true end-to-end encryption, but it'll certainly make it easier to eliminate privacy for the rest of us. Compare, for example, how the data collected by the government's massive surveillance of phone calls and emails hasn't helped against terrorists at all, but has been used for other purposes, such as to allow a government agent to spy on his wife to see if she was cheating on him.
I've been a long-time (and happy) Pebble wearer, from the first Kickstarter model to the Pebble Time Steel (color). But I'd been keeping an eye on Apple Watch, and last week I made the jump.
Why?
The biggest driver is that Apple Watch has amazing app support, while Pebble's app support are "OK". Not only does the Apple Watch have many more apps, the apps are better integrated. In part this is because of the APIs (Pebble's SDKs are very good, but Apple's are better, and very easy for iOS developers to work with), but I think the largest issue is market share - developers are clearly putting more effort into Apple Watch apps than Pebble Apps. From reports, Apple Watch is something like 75% of the smart watch market share (e.g. http://nypost.com/2015/07/30/a...), making it hard for developers to justify investing in competing platforms. And Pebble, while having an early lead in developers (very nice SDK, etc.) is showing very little new third-party app support - most Pebble apps are released and then never updated, and Pebble having layoffs after a series of price drops is probably not a great sign of their future.
In addition, the quality of the Apple Watch hardware (case, bands and display), are worlds better than Pebble. It's a beautiful watch and band, with a brilliant display, while the Pebble Time Steel is a good looking watch case, the display is quite slow and washed out. So yes, Apple Watch costs a little more ($299 is the least expensive Apple Watch which is metal body, plastic band, color display, while the cheapest Pebble (plastic, B&W) is $99, $199 for the Pebble Time Round, $249 for the Pebble Time Steel).
Really the main thing going for Pebble is the lower price for the low-end units, and longer battery life. Both of those are good things, and I think that Pebble will have a market segment just based on that. At least, I hope so. But the nicer Pebbles cost almost as much as the Apple Watch, and for battery life, the Apple Watch lasts two days, and charges so fast that I can wear it all day and night (for sleep monitoring), and charge sufficiently in the morning while getting dressed that it's not an issue.
My conclusion was that I am only going to wear one watch, and I want that watch to have a great display, and I'm willing to put up with charging every day. So Apple Watch wins.
Slashdot Mirror
The regulations kick in when they're going to production. If they're not prepared to do safety testing and think through how their product interacts with cars in order to make sure that it won't kill people, then they shouldn't be able to sell it. Giving up on that in the US, which is relatively lightly regulated, means that they're certainly out of the EU, Japan, etc. They can probably sell in China, as long as they give 51% of the company to someone with good connections to the Chinese government.
Correction: the FBI is not reopening the case, they're assessing some emails that they found in a different investigation to see if they are relevant. If they are relevant to Clinton, and if they contain classified information, then it's possible in the future that they might reopen the case. But that's not what the FBI said - that's all speculation by politicians looking for a "hook" to keep attacking Clinton.
Apple II used 5.25" floppies. Mac is what forced 3.5" disks into the market.
Revealing which models of devices they bought doesn't reduce their security, unless they're using units with widely known security flaws that they leave open.
Either they're really, really stupid or they think we are. Perhaps both?
If they're basing this on owning the copyright to the Olympics, this isn't going to work - owning a copyright on the name of a thing doesn't mean that you can prevent anyone from talking about your thing, just that nobody else can sell it. Lawsuits like this fail often - confused people think that they can use copyright to do more than control the right to copy...
Why not let users send their position by hitting a button? I'm thinking that it could insert text giving your location in text, or speech into a phone call, if you hit a "send my location" button. Then it'd work not just magically with E911 services (which, of course, is a great thing) but could work on normal phone calls (e.g. a kid calling Mom for help) or SMS (e.g. a kid texting Mom for help). The phone has the info, and it'd be easier to deploy, because it doesn't require any integration to anything outside of the phone.
Actually, collision data is quite clear - reducing speed of collision saves lives because the fatality rate of the accidents drop. The reason is pretty simple - F=MA. Mass of a car, person, etc., are constant. So the faster a car is going, the more acceleration is required to stop the car (i.e. during the collision), and thus the more force acting on the driver and passengers. And enough force kills people.
There's also quite clear aggregate data that highway driving fatality rates dropped when speed limits were reduced, both nationally and at the state level. Of course, at various times seatbelt, airbags, etc., also helped...
The car requires you to manually confirm that you understand that you're responsible for being alert and ready to take over from Autopilot, every single time you enable it. And exactly the same as Autopilot in airplanes, used by pilots for decades. In both cases, the Autopilot is a driver assist, automating a boring task, but ultimately the driver is responsible. Some people might not understand that (as evidenced by some really stupid YouTube videos, and your post) but Tesla is quite clear about the what Autopilot means, communicated consistently to every Tesla driver with Autopilot, and it's consistent with industry use of the term "Autopilot".
In the case of this accident, as often happens in truck under-run collisions, the driver didn't see the truck. Happens many times a year without Autopilot. It's possible that the driver this time wasn't being alert, but truck under-runs kill alert drivers (without Autopilot) routinely, so it's not clear that you particularly need to find anyone to blame this time.
To put it in perspective, look at the numbers. Tesla is 1 fatality for 130m miles driven, or 0.7 per 100m miles. The US average is 1.2 fatalities per 100m miles driven. So while you can't prove anything with small sample sizes (wait for 1B miles driven with Autopilot), it certainly indicates that Autopilot is relatively safe.
Exactly - the car knows speed limits from the maps. The reason that they don't enforce speed limits (outside of residential areas) is that buyers of high-end sports cars don't want speed limits enforced.
If there were a wall across the road, Autopilot would have seen that. Though avoiding a wall that suddenly appears across a highway might be problematic.
In this case, though, it wasn't a brick wall, it was a truck with a raised body. Which means that Autopilot saw clear road ahead (under the body of the truck), with a large flat object above it, like a sign over a highway. Incorrect in this case, but since people make the same mistake routinely (truck under-runs are common) it's not a trivial case. Should Autopilot be better than human drivers? Sure. But that takes lots of experience on the road, tuning the software. So, "silver lining", this accident will make future Autopilot versions safer.
I agree that people can be stupid, and that the software should be improved. Legally, though, since pilots have been flying airplanes with Autopilot that does the same thing Tesla's Autopilot does, and Tesla informs drivers repeatedly that they need to stay alert and ready to take over, just like airplane pilots, I suspect that Tesla's legal situation is pretty clean. The legal/regulatory situation will get more complex once cars are autonomous, rather than semi-autonomous. Until then, drivers are responsible for driving their cars safely, and it's more a matter of education that people learn to use the various safety mechanisms appropriately. If someone intentionally drove into a wall, they can't sue because the anti-collision braking didn't prevent them from doing so.
Might as well ask if they'd like to lose their pilot's license. They're required by law (and ethics) to always be prepared to take control away from the Autopilot, in a fraction of a second.
To support your post, Autopilot has already demonstrated that it's more situationally aware, always alert, and has faster reflexes, than a human driver.
The guy who died in the accident previously posted a video where Autopilot saved his life. A truck changed lanes into his car (presumably he was in the truck's "blind spot"). Autopilot saw the car, and got out of the truck's way, avoiding the accident, in less than a second. A human driver would have been side-swiped by the driver during reaction time.
Perhaps. But airplanes have been flying with Autopilot for decades, and the legal situation is quite clear - the pilot is responsible for flying the plane, and the Autopilot is just an assist that automates some of the boring stuff. But the pilot is required to be alert and prepared to jump in and take over whenever needed. Exactly the same as Tesla's Autopilot - probably why they named it Autopilot was to remind people of that.
Airplanes have had Autopilots for decades, and the pilots are responsible for flying the airplane. And every time you turn on Tesla's Autopilot you have to manually confirm that you know that the driver has to remain alert and hands-on-wheel.
"We just don't have the kind of evolving programs that you think we do."
First, you misread the OP. He didn't say that AI would fix the problem, he said that the software would be improved as a result of this accident, making future cars safer. Which you agreed with.
Second, people have been doing ML with software tuning itself on production data, for several decades now. More recently, perhaps you've heard of Google, Facebook and Amazon? Hand-coded rules don't scale and are nearly-impossible to QA in complex situations, which is why people using large volumes of data use a wider range of techniques, including machine learning / AI. In particular, computer vision is an area that uses tuned neural nets and such quite often, so in this case it's highly likely that Tesla would in fact be retraining their computer vision networks (etc.) to recognize trucks from the side as an obstacle rather than as a billboard over a highway.
Yes, the report is that the truck pulled square across a road with oncoming traffic (the Tesla). Presumably the truck didn't see the Tesla.
One correction - truck under-runs are common for drivers, and highly fatal. While you'd think a truck would be easy to see, it turns out that in reality a light truck pulled square across a road, against a light sky, is surprisingly hard to see. In particular, keep in mind that you can see the road ahead under the truck's elevated body. So, in reality, not trivial to avoid.
There are countries that require trucks to have side walls and bumpers, which would make the truck more visible, and make collisions with them less fatal.
As a data point, so far AutoPilot has 1 fatality for 130m miles driven (a month ago, more now), which is about 0.7 fatalities per 100m miles driven. The US average is about 1.2 fatalities per 100m miles driven. The numbers are small so they don't prove anything (wait for 1B miles driven to start drawing real conclusions) but it certainly suggests that AutoPilot is relatively safe.
No, Autopilot is specifically NOT autonomous driving, it's a driver-assist, where the driver is required to be alert and hands-on-wheel. This is displayed and agreed to by the driver every single time Autopilot is enabled.
That being said, truck under-runs are common and highly fatal for non-automated drivers, even at low speeds, because the raised truck bed bypasses all of the safety measures that cars have in place for car-to-car collisions. Bumpers, crumple zone, seat-belts, anti-collision sensors, etc., are bypassed, and the truck body hits the car roof and driver's head at full speed. IMO, the solution is for trucks to have bumpers running along the side of the truck at the height of car bumpers, so that at least lower-speed collisions are less fatal. Or put in place much more intelligent safety systems in all vehicles, so they all know where everything is...
They released a statement right after the accident saying that there was no indication that either AutoPilot or the driver tried to decelerate. That's consistent with an under-run accident where they didn't see the white trailer against a bright sky. Sadly, trucks are harder to see than you'd expect, so these accidents aren't rare.
MongoDB is clearly a database. It's not an SQL database, but that's kinda the point, in that not being SQL-based makes it much more efficient for developers, and more performant and flexible in accommodating semi-structured data.
I'm not sure why you think anyone would switch languages so frequently they don't release any functional software. I've never seen that happen on any project, other than research where the point was learning the language, not building functionality. :-)
You don't switch languages for no reason. Generally you only do a full ground-up replatforming of a system very rarely (10-15 years), and then because the advantages of the new platform over the old one are compelling. And there could have been hundreds of releases. For example, converting a system with thousands of users from Citrix/VB/Access to Angular/Node/MongoDB has lots of advantages. :-) But you don't do that sort of thing to a system on a weekly basis...
We replatformed a legacy C# app to a modern stack including Node.JS, and are very happy. The "win" wasn't so much the Node.JS language itself as that it was part of a platform that gives us fantastic code development velocity and fluidity. The "stack" includes CircleCI and Docker, MongoDB and Mongoose, Node.JS for a thin web services layer, and Angular (JavaScript) for the user experience, all integrated into HipChat for "ChatOps". Selenium and BrowserStack for end-to-end testing.
I'll agree that JavaScript isn't my favorite language, but the tooling around it is fantastic, making development teams very productive.
The benefits of using Node.JS in the overall stack include:
- Same language for the whole stack, so a single developer can implement a whole feature (story). This eliminates the coordination cost of having three different people (front-end JavaScript, server-side C#, and database SQL) having to coordinate for use cases, giving much better velocity.
- Node/JavaScript has fantastic testing support, making it fairly easy for us to maintain 90%+ unit code coverage, and end-to-end testing of user paths. This is integrated into the CircleCI builds means that after every code commit we have a fully built, unit and end-to-end tested, and deployed (to a test environment) application.
- npm is awesome. It's a great tool, and the community support means many things are very easy.
- Mongoose is awesome.
- it's very easy to run Node.JS in AWS Lambda, which makes operations easier and is absurdly cheap to run, since you only pay for the compute you actually utilize, measured in fractions of a second. We're building one project in Lambda, and if that works well we'll likely move all the Node.JS code into Lambda, and save a lot of money at AWS.
- Yeah, event-driven programming is complex. Luckily promises make it much easier. But in return for wrapping your head around a more complex programming model, you can more scalable applications. Similar tradeoff to multi-threaded programming.
Yes, none of this is about the Node.JS language itself.
Encrypted storage these days works quite well, and is built into Windows and MacOS at no cost. When we have employees working in insecure areas (such as shared offices) we encrypt their hard drives, and there's no noticeable performance impact. If they forget their credentials they lose access to their hard drive, but they also can't get to their email, calendar, file servers, etc., so that's hardly insurmountable.
And the value of encrypting storage is pretty high - if a laptop is lost or stolen, encrypting storage protects source code, email, documents, etc.
To be fair, five years ago the situation was different - the encryption software back then could rendering machines painfully slow, and the productivity cost was too high. But either from faster CPU and disk, or better software, these days disk encryption is free and painless, so it's worth doing.
There are a dew distinct aspects to this (IMO):
- There's a fundamental difference between "police can hack into iPhones" and "Apple puts a backdoor into iPhones so that iPhones are trivially hackable by anyone with the key", because Apple's role in the process matters. If Apple's job is to make iPhones secure, the police (and criminals) can of course still hack phones, but any vulnerabilities are treated as bugs to be fixed, and the iPhone gets more and more secure over time. If the police can force Apple to put a backdoor into the iPhone, then when the key is leaked (which always happens, when you give a key to thousands of police departments and other agencies, their contractors and vendors, etc., just as happened with DVDs) then anyone who can get the key can hack any iPhone, rendering it fundamentally insecure, and because it's required by a law, Apple cannot make the iPhone more secure, forever.
- The iPhone will never be 100% secure, because there's no such thing as 100% secure - the goal of security measures is to increase the cost/time of a successful attack, but infinite money/time can always ultimately succeed. For example, AES 256 is quite secure, but that just means that brute forcing a key would take enough time and harder (e.g. https://www.reddit.com/r/theyd...) that it's not worth it - you'd have to be a government to have the resources to do so, and very few secrets are worth spending a building full of supercomputers to hack. Every so often new techniques or technologies emerge that can change the equation (quantum computing...) but the same is true of physical locks - if you can photograph a key you can 3D print a duplicate. So it's always been a game of "cat and mouse" between lock-makers and lock-breakers.
- Because encryption is software, which can't be controlled globally, any laws restricting encryption only limits what can be embedded in systems from US manufacturers. But it won't have any control over anyone with internet access, since the rest of the planet can (and does) produce uncompromised security systems with no backdoors, which anyone on the planet can download and use (including good open source, free tools). So any law against secure systems won't help against real criminals, because presumably they'll either avoid digital communications (i.e. what real terrorists do now) or use true end-to-end encryption, but it'll certainly make it easier to eliminate privacy for the rest of us. Compare, for example, how the data collected by the government's massive surveillance of phone calls and emails hasn't helped against terrorists at all, but has been used for other purposes, such as to allow a government agent to spy on his wife to see if she was cheating on him.
I've been a long-time (and happy) Pebble wearer, from the first Kickstarter model to the Pebble Time Steel (color). But I'd been keeping an eye on Apple Watch, and last week I made the jump.
Why?
The biggest driver is that Apple Watch has amazing app support, while Pebble's app support are "OK". Not only does the Apple Watch have many more apps, the apps are better integrated. In part this is because of the APIs (Pebble's SDKs are very good, but Apple's are better, and very easy for iOS developers to work with), but I think the largest issue is market share - developers are clearly putting more effort into Apple Watch apps than Pebble Apps. From reports, Apple Watch is something like 75% of the smart watch market share (e.g. http://nypost.com/2015/07/30/a...), making it hard for developers to justify investing in competing platforms. And Pebble, while having an early lead in developers (very nice SDK, etc.) is showing very little new third-party app support - most Pebble apps are released and then never updated, and Pebble having layoffs after a series of price drops is probably not a great sign of their future.
In addition, the quality of the Apple Watch hardware (case, bands and display), are worlds better than Pebble. It's a beautiful watch and band, with a brilliant display, while the Pebble Time Steel is a good looking watch case, the display is quite slow and washed out. So yes, Apple Watch costs a little more ($299 is the least expensive Apple Watch which is metal body, plastic band, color display, while the cheapest Pebble (plastic, B&W) is $99, $199 for the Pebble Time Round, $249 for the Pebble Time Steel).
Really the main thing going for Pebble is the lower price for the low-end units, and longer battery life. Both of those are good things, and I think that Pebble will have a market segment just based on that. At least, I hope so. But the nicer Pebbles cost almost as much as the Apple Watch, and for battery life, the Apple Watch lasts two days, and charges so fast that I can wear it all day and night (for sleep monitoring), and charge sufficiently in the morning while getting dressed that it's not an issue.
My conclusion was that I am only going to wear one watch, and I want that watch to have a great display, and I'm willing to put up with charging every day. So Apple Watch wins.