Being a Microsoft customer isn't causing people to be targeted. The callers are posting as Microsoft technicians, making it relevant only to Microsoft customers.
The age of the cars matters as well, as does the relative state of maintenance.
It's a reasonable assumption/statement that all Tesla Model S cars are essentially new and likely to be in near perfect maintenance condition.
If the gasoline car fire numbers were adjusted to only include cars within the age range of Tesla Model S cars and (if possible) the number of cars still within factory warranties, I would imagine the number of gasoline car fires would be significantly lower.
If you're going to take that route, then you need to exclude from both lists the cars that have had fires as a result of impacts. Now you're at some number of gas cars and zero Tesla vehicles. Because once you get into an impact, the age of the car is largely irrelevant.
The cold hard fact is, though, that Musk is right -- there's vastly more energy that wants to burn in a gas tank and associated fuel lines. An accident can easily rupture them, as can age corrode through them. (Even ignoring the added corrosion of ethanol these days.)
Yeah, I'd be more concerned about the "over the air" updates.
If he wanted you dead, all he has to do is push an update that tells the car to not brake or tell the suspension to slam you into the ground.. or to overdraw the batteries causing a fire.. or take over the steering and slam you into a wall. Or discharge all the airbags while you're traveling highway speeds... you get the idea.
I wonder what kind of security that communication system has.
GM cars with OnStar can get updates OTA, as well. I'd bet most (if not all) cars with telematics systems can do it.
No matter what technical solution you end up with, if it takes you nine years to switch to a new platform, you can be pretty damn certain where you ended up isn't where you want to be or should be.
Of Boston's NPR this morning having a series on prostitution in Boston, and talking about the frequency that Boston cops are seen... well, lets just say not arresting the girls...
Lastly, the support is, bar none, better than anything you can get from Google or Amazon. It may cost me some money -- or a lot of money -- but I can get someone from MS on the phone who will work through an issue, or something we simply want to do in a different way, until it gets done.
Compared to which AWS support tier? I've never had a problem with their Enterprise support.
As I mentioned, its been a while, so I don't recall... and it may be less of a differentiator now, so that may have been a bit stronger of a statement than it should've been. I'm comfortable saying its, at worst, equal... but that'd be a BIG compliment to Amazon/Google. (And, Google support has been a trainwreck every time I've tried to interact with them, so... I would be SHOCKED if its gotten any better.)
Okay since I got modded Flamebait -- and it wasn't intended as a flame, it was intended to be a specific sarcastic response suggesting the OP was an idiot -- I'll follow up.
Lesson number one in secure programming is to know where your threat boundaries are. A statement about checking return codes all the time, and its association with security, is just plain moronic because there may not be a threat at that point in the code. In this case, you're authenticating via services that need valid credentials to generate a token, and you need that valid token going forward in order to access any subsequent services... so who cares, other than for user feedback, if something like that fails? You're not bypassing security, you're just blowing up the UI.
Consider the hundreds of millions of lines of code at Microsoft, and the *constant* attack they're under. Now consider how relatively infrequent there are actual real security incidents -- especially in hosted services. (Its hard to be truly secure on a local machine because most users run in ways that make the administrative barrier not a barrier... and once you're an admin, you can access kernel memory and all bets are off.) Note how infrequent real remote code exploits are... most exploits are user mode, and only a risk to the current user.
That suggests that -- no flame intended -- the OP is, in fact, an idiot and the people who wrote the code he was looking at actually ARE smarter than him and actually understand the process it takes to write secure software. And nothing makes software more insecure than moronic statements like "always check return codes" trumping a real understanding of the threat model of the system.
Thank you for your response. You are exactly the type of user I wanted to hear from.
If I may ask, what do your servers do? Enterprise services, web application, customer facing, ecommerce?
Bit of all of that -- a web application, public and internal services supporting it, some enterprise integration (WAAD/ACS federation, etc), and a couple corporate websites running WordPress.
Yes, but with a replaceable battery, you can carry a spare.
I don't know what the deal is with thin -- beyond a certain point it just doesn't matter and in fact, makes the phone harder to hold really. But I don't think people will be happy till phones are as thin as a razor -- who cares about the gashes and gushes of blood so long as the phone is thin thin thin!
If I'd replied yesterday, I would've said I'd never ran a battery out on my current phone -- only the second I've owned without a replaceable battery. Of course, yesterday I managed to kill it for the first time.
But in 20+ years of owning a cell phone, I've never carried a spare battery and never swapped mid-day. So its a complete non-issue for me.
- We do, 50-100 servers depending on what the elastic scaling is doing. Even mix between Linux VMs and.NET services, distributed across three Azure data centers - We also make good use of TFService (now Visual Studio Online) -- 80% of the code in it being Java code not.NET code. Integration with Eclipse is really fantastic. The task and bug tracking tools are great. Price was really great when free, but is still very competitive for other hosted services now that its a paid service.
The question of why Azure vs AWS/Google? That's a tougher one... but briefly: - The tooling is just better. AWS and Google just seems to take more time to do the same task. YMMV - Ancillary services. The Service Bus, Azure ActiveDirectory, the easy integration between enterprise systems and the Azure services, ease of monitoring via centralized performance counters and logs, etc... basically its the whole package rather than bits and pieces.
I have extensively used Amazon's various services four or five years ago and liked them, but they tended to be more simplistic on the service side and heavier weight on the compute side (having to maintain my own VMs, etc).
Cost is another factor -- particularly when you get up into high usage and can commit to that usage, the prices really start to drop quickly.
Lastly, the support is, bar none, better than anything you can get from Google or Amazon. It may cost me some money -- or a lot of money -- but I can get someone from MS on the phone who will work through an issue, or something we simply want to do in a different way, until it gets done. There's a point in a business that support like that becomes the most important thing, because its cheaper than putting a dev or two on some puzzle and have them experiment their way through it.
I learnt recently that these baseband processors are controlled over a serial connection, and talk old-school Hayes AT commands.
So if this is true, then it should be reasonably easy for hobbyists to buy baseband processors off the shelf and interface them to microcontrollers or Arduino or whatever fairly easily, and get instant Wi-fi/Bluetooth/cellular data support?
Yes, and pretty much every site that sells Arduinos and other microcontrollers sell them.
Have you never actually looked? Do a search on "GSM" on any of those sites, there's a zillion modules with various GSM chipsets. Trivial to make calls, handle data, send/receive SMS, etc...
The driver has admitted to driving the car after an accident, ignoring all warnings until told that the car had a problem so big that it was going to stop ( on fire). I would be interested in seeing the insurance companies response this this...
Yes, cars are still covered even if they were damaged by provable negligence. (If you wreck your car while drunk driving, its still covered...)
I used to have a classic 60's Porsche 911. They put the carburetors directly above the coil and distributor...
We used to say, if the car wasn't on fire, you're probably out of gas...
Of course, that was still safer than the auxiliary heat -- which sprayed burning gas directly into the hot air flow into the cabin... ensuring when you died in a horrific conflagration, at least the carbon monoxide had already dulled the pain.
> "Google doesn't want you as a customer if supporting your old browser costs more than the revenue you bring in"?
FTFY
That's not a huge cost relative to tens or hundreds of millions of users. Google isn't click-testing its software -- you can be sure of that. Once you've got the automated tests, its a matter of updating them. The cost is low.
While the "three latest versions" rule is a good rule of thumb, IE9/10/11 are all virtually identical relative to the functionality that Google is using.
I think this is more about getting people on XP to use Chrome instead of upgrading to Windows 8.
FWIW, what you called out is just one kind of fault -- and not the kind they're talking about here.
In this case, the concern is that the process is creating new (or growing existing) faults that would've otherwise been stable. That's the reason for the statistics -- you can't see what is happening down deep, but you can certainly see statistically significant changes.
That's why its so easy for both sides of the fracking debate to confuse the general public -- on something like this, you need to be in the sweet spot of the Venn diagram of geologist and statistician to really evaluate it.
These sort of results are scientifically important because there isn't a lot of good science one way or another on the impact of fracking. Its a lot of statistics, not a lot of hard data, and a lot of unknowns. (Contrast that to the greenhouse impact of increased use of natural gas because of fracking -- that is well understood science, and thus not as interesting to those doing the actual work of science rather than the work of politics.)
The standard model has over 50 fudge factors...its broken. What If there are particles and/or forces outside of our little sphere that would enable this?
I don't think we've even scratched the surface yet.
You might as well claim that magical pixie dust and the hand of Jesus will push spaceships faster.
The standard model, except on quackery websites, isn't broken. There are no particles found that don't match it, and the ones it predicts get found. That's the point -- there's plenty of room to fill in details but something fundamentally breaking special relativity is not hiding in those cracks. The whole shebang is completely and totally wrong from the ground up, if so... and theories that are accurate to this level simply aren't overthrown like that.
Its almost infinitely more likely you are letting wishful thinking cloud your judgment (assuming you have any qualifications to have a judgment on this topic) than that ever happening.
Unless, of course, y'know, we don't know everything there is to know about physics.
We don't know everything, but we know the broad strokes to a staggering level of accuracy. There's dark corners and more than enough details to go around for aspiring PhDs, but its just wishful thinking and imagination to believe there are major swaths of physics we're so completely and totally wrong about.
Maybe they exist, but have you ever seen a company that actually could deploy or upgrade SAP faster than building something in house?
Depends how complete their understanding of their immediate, short term and mid-term requirements are.
I'd say yes, for companies that actually had a good handle on their requirements. I also think most companies are bad about calculating the real costs of doing a complex system like that DIY. Its easy to enumerate the up front costs, but much harder to enumerate the costs over time of support, enhancements, and hardest of all, operational inefficiencies because the system couldn't do "X" and there wasn't time, resources, understanding, etc, to implement it.
When every organization did the same thing, had in-house staff to support it, and didn't have to bother with consultants. It can be a problem to keep track of all the different legal changes in the various locations though.
And hope, in 24 years, they've still got some geezers on the payroll who remember that old "Java" language from the early 21st century running on a crufty emulator no one can remember how to reinstall and can figure out all the places the engineers had said 4 bytes were plenty to hold a timestamp.
Slashdot Mirror
Being a Microsoft customer isn't causing people to be targeted. The callers are posting as Microsoft technicians, making it relevant only to Microsoft customers.
There's a vast difference between the two.
Google can answer that question pretty easily, at least roughly.
Tesla: 1 fire per 25 million miles (approx. 3 in 75 million)
Others: 1 fire in 865000 miles (approx. 290,000 in 250 billion)
So, you're 4.6 times more likely to have a fire in a non-Tesla vehicle.
The age of the cars matters as well, as does the relative state of maintenance.
It's a reasonable assumption/statement that all Tesla Model S cars are essentially new and likely to be in near perfect maintenance condition.
If the gasoline car fire numbers were adjusted to only include cars within the age range of Tesla Model S cars and (if possible) the number of cars still within factory warranties, I would imagine the number of gasoline car fires would be significantly lower.
If you're going to take that route, then you need to exclude from both lists the cars that have had fires as a result of impacts. Now you're at some number of gas cars and zero Tesla vehicles. Because once you get into an impact, the age of the car is largely irrelevant.
The cold hard fact is, though, that Musk is right -- there's vastly more energy that wants to burn in a gas tank and associated fuel lines. An accident can easily rupture them, as can age corrode through them. (Even ignoring the added corrosion of ethanol these days.)
Yeah, I'd be more concerned about the "over the air" updates.
If he wanted you dead, all he has to do is push an update that tells the car to not brake or tell the suspension to slam you into the ground.. or to overdraw the batteries causing a fire.. or take over the steering and slam you into a wall. Or discharge all the airbags while you're traveling highway speeds... you get the idea.
I wonder what kind of security that communication system has.
GM cars with OnStar can get updates OTA, as well. I'd bet most (if not all) cars with telematics systems can do it.
Hope someone lost their job over that ...
No matter what technical solution you end up with, if it takes you nine years to switch to a new platform, you can be pretty damn certain where you ended up isn't where you want to be or should be.
Of Boston's NPR this morning having a series on prostitution in Boston, and talking about the frequency that Boston cops are seen ... well, lets just say not arresting the girls ...
No wonder they don't want GPS in the cars ...
Or, for that matter, on search.
Good at PR, though.
Lastly, the support is, bar none, better than anything you can get from Google or Amazon. It may cost me some money -- or a lot of money -- but I can get someone from MS on the phone who will work through an issue, or something we simply want to do in a different way, until it gets done.
Compared to which AWS support tier? I've never had a problem with their Enterprise support.
As I mentioned, its been a while, so I don't recall... and it may be less of a differentiator now, so that may have been a bit stronger of a statement than it should've been. I'm comfortable saying its, at worst, equal... but that'd be a BIG compliment to Amazon/Google. (And, Google support has been a trainwreck every time I've tried to interact with them, so... I would be SHOCKED if its gotten any better.)
Okay since I got modded Flamebait -- and it wasn't intended as a flame, it was intended to be a specific sarcastic response suggesting the OP was an idiot -- I'll follow up.
Lesson number one in secure programming is to know where your threat boundaries are. A statement about checking return codes all the time, and its association with security, is just plain moronic because there may not be a threat at that point in the code. In this case, you're authenticating via services that need valid credentials to generate a token, and you need that valid token going forward in order to access any subsequent services... so who cares, other than for user feedback, if something like that fails? You're not bypassing security, you're just blowing up the UI.
Consider the hundreds of millions of lines of code at Microsoft, and the *constant* attack they're under. Now consider how relatively infrequent there are actual real security incidents -- especially in hosted services. (Its hard to be truly secure on a local machine because most users run in ways that make the administrative barrier not a barrier... and once you're an admin, you can access kernel memory and all bets are off.) Note how infrequent real remote code exploits are... most exploits are user mode, and only a risk to the current user.
That suggests that -- no flame intended -- the OP is, in fact, an idiot and the people who wrote the code he was looking at actually ARE smarter than him and actually understand the process it takes to write secure software. And nothing makes software more insecure than moronic statements like "always check return codes" trumping a real understanding of the threat model of the system.
Thank you for your response. You are exactly the type of user I wanted to hear from.
If I may ask, what do your servers do? Enterprise services, web application, customer facing, ecommerce?
Bit of all of that -- a web application, public and internal services supporting it, some enterprise integration (WAAD/ACS federation, etc), and a couple corporate websites running WordPress.
Yes, but with a replaceable battery, you can carry a spare.
I don't know what the deal is with thin -- beyond a certain point it just doesn't matter and in fact, makes the phone harder to hold really. But I don't think people will be happy till phones are as thin as a razor -- who cares about the gashes and gushes of blood so long as the phone is thin thin thin!
If I'd replied yesterday, I would've said I'd never ran a battery out on my current phone -- only the second I've owned without a replaceable battery. Of course, yesterday I managed to kill it for the first time.
But in 20+ years of owning a cell phone, I've never carried a spare battery and never swapped mid-day. So its a complete non-issue for me.
Who here is using Azure?
What, exactly, are you using it for?
Why did you choose it over self hosted?
Why did you choose it over AWS or Google?
That's a long answer, but a few bullets:
- We do, 50-100 servers depending on what the elastic scaling is doing. Even mix between Linux VMs and .NET services, distributed across three Azure data centers .NET code. Integration with Eclipse is really fantastic. The task and bug tracking tools are great. Price was really great when free, but is still very competitive for other hosted services now that its a paid service.
- We also make good use of TFService (now Visual Studio Online) -- 80% of the code in it being Java code not
The question of why Azure vs AWS/Google? That's a tougher one ... but briefly: ... basically its the whole package rather than bits and pieces.
- The tooling is just better. AWS and Google just seems to take more time to do the same task. YMMV
- Ancillary services. The Service Bus, Azure ActiveDirectory, the easy integration between enterprise systems and the Azure services, ease of monitoring via centralized performance counters and logs, etc
I have extensively used Amazon's various services four or five years ago and liked them, but they tended to be more simplistic on the service side and heavier weight on the compute side (having to maintain my own VMs, etc).
Cost is another factor -- particularly when you get up into high usage and can commit to that usage, the prices really start to drop quickly.
Lastly, the support is, bar none, better than anything you can get from Google or Amazon. It may cost me some money -- or a lot of money -- but I can get someone from MS on the phone who will work through an issue, or something we simply want to do in a different way, until it gets done. There's a point in a business that support like that becomes the most important thing, because its cheaper than putting a dev or two on some puzzle and have them experiment their way through it.
Anyway, that's my experience. YMMV.
Nice example of insecure code at their login screen (http://go.microsoft.com/fwlink/?LinkId=309297&clcid=0x409&slcid=0x409):
What if InsertOrUpdate() or Save() fails? Lesson number one in secure programming: ALWAYS check return codes of functions.
Yes, you're smarter than the people who wrote and reviewed it.
I learnt recently that these baseband processors are controlled over a serial connection, and talk old-school Hayes AT commands.
So if this is true, then it should be reasonably easy for hobbyists to buy baseband processors off the shelf and interface them to microcontrollers or Arduino or whatever fairly easily, and get instant Wi-fi/Bluetooth/cellular data support?
Yes, and pretty much every site that sells Arduinos and other microcontrollers sell them.
Have you never actually looked? Do a search on "GSM" on any of those sites, there's a zillion modules with various GSM chipsets. Trivial to make calls, handle data, send/receive SMS, etc ...
That is why it is getting increasingly tough to find a phone with a replaceable battery.
Or people just like the aesthetics of a phone without a battery cover.
But by all means, tinfoil on.
The driver has admitted to driving the car after an accident, ignoring all warnings until told that the car had a problem so big that it was going to stop ( on fire).
I would be interested in seeing the insurance companies response this this...
Yes, cars are still covered even if they were damaged by provable negligence. (If you wreck your car while drunk driving, its still covered...)
I used to have a classic 60's Porsche 911. They put the carburetors directly above the coil and distributor...
We used to say, if the car wasn't on fire, you're probably out of gas...
Of course, that was still safer than the auxiliary heat -- which sprayed burning gas directly into the hot air flow into the cabin... ensuring when you died in a horrific conflagration, at least the carbon monoxide had already dulled the pain.
... they mean it's something new scientists haven't seen before, and haven't figured out yet.
Kinda like the same way you meet someone you don't know, you are dumbfounded by them.
Visit the Midwest -- everyone there dumbfounds me.
Not really.
And why would you think that accurately represents corporate usage?
> "Google doesn't want you as a customer if supporting your old browser costs more than the revenue you bring in"?
FTFY
That's not a huge cost relative to tens or hundreds of millions of users. Google isn't click-testing its software -- you can be sure of that. Once you've got the automated tests, its a matter of updating them. The cost is low.
While the "three latest versions" rule is a good rule of thumb, IE9/10/11 are all virtually identical relative to the functionality that Google is using.
I think this is more about getting people on XP to use Chrome instead of upgrading to Windows 8.
Now, I am no geologist
Yes, that is certainly true.
FWIW, what you called out is just one kind of fault -- and not the kind they're talking about here.
In this case, the concern is that the process is creating new (or growing existing) faults that would've otherwise been stable. That's the reason for the statistics -- you can't see what is happening down deep, but you can certainly see statistically significant changes.
That's why its so easy for both sides of the fracking debate to confuse the general public -- on something like this, you need to be in the sweet spot of the Venn diagram of geologist and statistician to really evaluate it.
These sort of results are scientifically important because there isn't a lot of good science one way or another on the impact of fracking. Its a lot of statistics, not a lot of hard data, and a lot of unknowns. (Contrast that to the greenhouse impact of increased use of natural gas because of fracking -- that is well understood science, and thus not as interesting to those doing the actual work of science rather than the work of politics.)
The standard model has over 50 fudge factors...its broken. What If there are particles and/or forces outside of our little sphere that would enable this?
I don't think we've even scratched the surface yet.
You might as well claim that magical pixie dust and the hand of Jesus will push spaceships faster.
The standard model, except on quackery websites, isn't broken. There are no particles found that don't match it, and the ones it predicts get found. That's the point -- there's plenty of room to fill in details but something fundamentally breaking special relativity is not hiding in those cracks. The whole shebang is completely and totally wrong from the ground up, if so... and theories that are accurate to this level simply aren't overthrown like that.
Its almost infinitely more likely you are letting wishful thinking cloud your judgment (assuming you have any qualifications to have a judgment on this topic) than that ever happening.
Unless, of course, y'know, we don't know everything there is to know about physics.
We don't know everything, but we know the broad strokes to a staggering level of accuracy. There's dark corners and more than enough details to go around for aspiring PhDs, but its just wishful thinking and imagination to believe there are major swaths of physics we're so completely and totally wrong about.
Maybe they exist, but have you ever seen a company that actually could deploy or upgrade SAP faster than building something in house?
Depends how complete their understanding of their immediate, short term and mid-term requirements are.
I'd say yes, for companies that actually had a good handle on their requirements. I also think most companies are bad about calculating the real costs of doing a complex system like that DIY. Its easy to enumerate the up front costs, but much harder to enumerate the costs over time of support, enhancements, and hardest of all, operational inefficiencies because the system couldn't do "X" and there wasn't time, resources, understanding, etc, to implement it.
When every organization did the same thing, had in-house staff to support it, and didn't have to bother with consultants. It can be a problem to keep track of all the different legal changes in the various locations though.
And hope, in 24 years, they've still got some geezers on the payroll who remember that old "Java" language from the early 21st century running on a crufty emulator no one can remember how to reinstall and can figure out all the places the engineers had said 4 bytes were plenty to hold a timestamp.