I disagree: the Model S was the right car to do first. All electric cars before it were simply crap. Worthless, horrible rides that only a hippie would drive. Yech. The Tesla is fine for many uses, and the main thing is: it's overpriced in a market where it's normal to be overpriced; it's overweight in a market where it's fine to be overweight (the S class was 3 tons not that long ago). It's a nice car, nicer than a Camry, where instead of the refinement of a luxury car for the price difference, you get the novelty of an electric car. And at that price range, you probably also have a gas car (or if not, you can rent one as needed).

Electric car tech simply isn't ready yet for low-margin vehicles. High margin cars, where intangible value is a big part of price, they work fine. It makes perfect sense to me to start there, and gradually come downmarket as they get the hang of it.

Also, most US families have 2+ cars, so one short range car isn't a problem I don't, so I'm skipping the Model S for now, but I'd love a similar car with a 50 HP gas generator under the hood. It doesn't need to provide enough power to run on, just enough to recharge given a few hours in the parking lot. None of this fancy, sure-to-break, parallel hybrid nonsense, but the great "fixie" Tesla drivetrain with a purely separate generator so I can recharge using gasoline as needed.

Any language except C has classes that prevent buffer overruns. Heck, I did assembly programming for 5 years, and the natural way to move data around avoided buffer overruns (mainframe assembly). The tools are right there, people just don't pick them up.

It's not about the language, and it's certainly not about "don't screw up", it's about a coding style that's not amenable to the mistake, and that's practical is most any language except C, really.

(Really, C and Managed aren't the only choices out there.)

The trouble with these things is that they want to "phone home" too much. For energy conservation, Nest talks to a Nest, Inc. server and tells it too much. The info it needs (outside temp, power grid load status) is freely available from read-only web sites. (Given a ZIP code, the National Weather Service site will return info in XML.) But no, it has to talk to the "cloud" and give out personal information. That's totally unnecessary.

By providing one, I would refute myself. :p

This is the problem at the heart of climate science. The key details for models are not published, and (despite being largely paid for by our money), not even available apparently under FOIA to "avoid competitive harm".

That sounds very much like commercial software development and very little like reproducible science, or even open source! WTF, guys? You wonder why so much of the public has a hard time taking climate science seriously? This shit is why.

Good science defeats skeptics through openness. "Look, here's the experiment, do it yourself if you don't trust me." Heck, even experiments on vastly expensive particle accelerators eventually become reproducible through cleverness or technological advance at other universities.

Openness, and beyond openness: the willingness to explain clearly, in detail, and in layman's terms led to the talk.origins FAQ, which takes seriously and answers seriously every common popular question and dispute about evolution, and likely led to the shift from old-school creationism to ID (which at least is progress). This is severely lacking in climate science.

The Mustang is a heck of a car these days, if you can get past the horrid cheap interior. I'd imagine it will do well.

My Sony alarm clock has been my most robust piece of gear (I recently had to replace my Logitech gaming mouse, so that's off the list). The Sony clock is particularly ironic.

The Japanese use the phrase SOny timer for planned obsolescence, both in a general sense and a specific assertion that all Sony products have such a timer to kill the device one day after the warrantee is up (except the PS, because they need to sell the games). Funny that the clocks are the only Sony product without the "Sony timer".

Communities and prevailing attitudes are pretty different.

And speaking as a gay person, I'm not very interested in the "gay communities". I'm interested in a place that I can live as an openly gay person without having to give a shit about it. Closest in the US to that is the Bay Area, definitely not Texas.

I have several Teletype machines from the 1926 to 1940 period. All are in good working order. They're completely repairable; it's possible to take one apart down to the individual parts and put it back together. But they're high-maintenance. There are several hundred oiling points on a Model 15 Teletype. There are things that have to be adjusted occasionally, and manuals and tools for doing that. Every few years, the entire machine has to be soaked in solvent to clean off excess oil, then relubricated and adjusted. This is the price of building a complex machine good for a century or more.

(The Model 33 of the minicomputer era is not one of the long-lived machines. This was by design. The Model 35 was the equivalent long-lived, high-maintenance product; the 33 required little mainenance but had a llimited life.)

The problem is C. Programs in all the languages that understand array size, (Pascal, Modula, Ada, Go, Erlang, Eiffel, Haskell, and all the scripting languages) don't have buffer overflow problems.

It's not an overhead problem. That was solved decades ago; compilers can optimize out most subscript checks within inner loops.

I've proposed a way to retrofit array size info to C, but it's a big change to sell. There are many C programmers who think they're so good they don't need subscript checks. Experience demonstrates they are wrong.

Long ago IBM split itself in to 7 internal subdivisions that could to a certain extent compete. At the time all of IBM's equipment ran on chips made by IBM for IBM products. The florida area sub-unit which didn't actually make any computers, put one together from intel chips. It was dubbed the PC. The OS was contracted out to some kids from Seattle.

Sony's products division is constantly at war with it's content division, leading to the constant hedging on content protection that defeats their products by using non-standard formats with DRM.

Perhaps Samsung, which is really a humungously diverse set of industries, just has different competing segments within itself. Each has a strategy that is aimed at competing with the other divisions strategy but has to be distinctly different due to the internal politics, just like IBM's PC did.

Its not s strategy to do everything, that's just the result.

Of course if you're comparing to southern California, I've encountered a sufficient amount of racism re: Mexicans there for one lifetime.

It's not about how fast you patch, it's about how fast you can get patches to your customers. And for the OpenSSL flaw, there were devices where the patch process is "throw it away and buy a new one".

Anyhow, Microsoft is far and away the worlds leading expert at distributing security patches - no one really has more experience or such a well-tuned corporate ecosystem. MS pushed a critical security patch out to WU, and every major corporation knows just what to do, and understand the urgency, and has a well-travelled path for it. The more modern players are good at patching consumer endpoints, but haven't really addressed corporate customers.