There's nothing wrong with "infotainment" as long as it's audio. People have been listening to car radios without problems for many decades.

What makes you imagine Musk can make an electric car company from scratch and Apple can't? Musk is rich, but even so he nearly ran out of money, what with Tesla And SpaceX. He got so near to the brink at one stage he was going to have to pull out of one - but won some space contracts just in time.

As well as the design chops and the desirable brand, Apple has effectively limitless amounts of money to throw at making a car.

Yes, buying Tesla is an option, but there have been car related hires at Apple going on for some time now - if they were going to buy Tesla, you'd expect it to be before the hires.

For the car buying public it is better that they compete. There will be more innovation, quicker that way.

Maybe it's the way you speak.

Utter nonsense. Please don't spread such misinformation.

Bulk collection may indeed be unconstitutional, but the court said nothing about that. What they said was that section 215 did not authorize bulk collection, so if Congress wants to authorize bulk collection they have to pass a law to say so. If Congress does that, then the court will eventually have to rule on constitutionality.

As far as I can see the new String type used by Swift does it right.
Although when using existing Cocoa APIs it's get bridged to NSString anyway, so we're not out of the woods yet.

Without any programming experience it's not likely you'd get hired. While specific language doesn't matter, you have to have sufficient knowledge and ability to be able to have a detailed discussion about solving problems in software design and implementation, and prove that you can write clean, accurate code, and do it quickly.

My recommendation is that you first spend some time working through many of the problems provided by Project Euler, or the Top Coder challenges, or similar. Or maybe one of the coding interview books, like this one.

When you're comfortable that you can take on a not-completely-trivial software problem, design an algorithm to solve it, accurately characterize the big O time and space complexity of your solution (not prove it... though you should be able to prove it, given more time), explain why there aren't any more efficient solutions, code it up on a whiteboard, and explain how you'd go about testing it, all in the course of a 45-minute interview, then you're probably ready.

You guys that are talking about sanitizing the input don't understand the bug. There is absolutely nothing wrong with the input. This is not injection of escape codes. It's valid text in a different language, and changing at at input would constitute a second defect. The problem is connected to the eliding algorithm.

And in fact the argument where in the code the problem lies is not that helpful anyway. The bigger problem is that there wasn't a test case for it.

Amtrak employees are NOT federal employees. Amtrak is a publicly subsidized private for-profit corporation with common stock held by four other railroad companies. The Federal government is an investor, but holds only preferred stock.

For C++ there is no standard answer, because every C++ shop uses a different subset of the language. There are probably a few things that all of them have in common, but it's unreasonable to expect that any entry level C++ programmer can be productive without support from senior programmers while they learn the local ropes. Even experienced C++ programmers will need a little time to get up to speed on the local style guidelines.

C++ doesn't have an extensive set of standard libraries, either, which means that every shop has its own set. So senior programmers have to expect that new people are going to spend a lot of time getting up to speed on those.

Finally, I think the question is fundamentally bad, because it implies a misguided expectation of immediate productivity. That's a common expectation (hope?) throughout much of the industry, but unless you're hiring contractors for six-month jobs, its stupid. What matters in the longer run isn't what your new hires know coming in the door, it's how well they learn, and think. Because whatever they know coming in is invariably inadequate in both short and long term. One of the things I found very refreshing when I joined Google is that they don't much care what you know in terms of languages, libraries and tool sets. It's assumed that capable people will learn what they need to when they need to learn it, and that any new project involves some ramp-up time before people are productive. On the other hand, given a little time to get up to speed capable people will become very productive. Much more so than the less capable person who happened to know the right set of things when hired.

Even the small payload becomes a big logistical challenge when you're looking at doing it globally, for large numbers of devices and want to make it fast (means having data centers in all regions), and make it reliable (means having redundancy, at multiple levels). Oh, and the "all the data is encrypted" bit may expose regulatory problems, too.

What specifically are you looking for? As an alternative, are there some ways that Android could be improved to alleviate whatever concerns you have? If your concerns are non-technical and primarily about insufficient ecosystem diversity (i.e. insufficient fragmentation), then there's probably not much to do. If your concerns are related to technical problems with Android, or privacy concerns about its relationship with Google, there may well be.

I'm an engineer on Google's Android Security team, and I'm actively looking for things that we can do to address security and privacy concerns. One of the ideas I've been kicking around is a "pre-encryption network tap"... basically, what if you could turn on a mode that logs a copy of everything your device transmits and receives? Most of that data is (and should be!) encrypted, but since most apps and all system services use the framework implementations (yes, plural... sigh) of SSL/TLS it should be possible to hook in and grab the plaintext. My goal here is to enable users to examine what their device is sending, and to whom, because I think right now it's too hard to tell, and because specifically I think there are a lot of erroneous assumptions that Google is receiving a lot of data from Android devices without user permission.

The downside, of course, is that adding such a hook into the system makes it a prime target for various sorts of attacks. So I don't think we would want to do that, not as stated, anyway. Though there may be some variant of the idea that isn't too risky.

Anyway, given a system like that, it should be possible to build an alternative ecosystem of apps and services that run on Android and don't use Google's infrastructure, and that would be much easier than building an entirely new platform. You'd still need to address the problems I mentioned at the top, but at least those could be the bulk of the challenge rather than just another piece of it.

As another alternative, I think if Google became more transparent about how it manages user data and what it does with it, many peoples' concerns would be addressed. But although I make that argument regularly, I don't have the same degree of influence there as I do over platform technology.

Or if you have other concerns, what are they, and do you have any ideas about how the platform could address them?

--- but when a Microsoft product offers more than a minimum feature set, the geek is the first to go ballistic.

You're an idiot.

That's what I mean when I say "The hiding of scrollbars". It's not an issue for now because you can turn that off. It's just not a good direction IMHO.

Well, speaking of Amtrak employee accountability, I have a story about that. A few years ago my family took a train ride across the country. When we changed trains in Chicago I noticed that the reading light in my sleeping compartment was stuck on, which of course was bad if I wanted to actually sleep. I found the friendly and helpful attendant and reported it, and her reaction was like watching a balloon deflate.

"What's wrong?" I asked.

"If we report damage they take it out of our wages," she said.

"What! What do you mean take it out of your wages?" I asked.

"If a car is damaged under my watch I have to pay for it," she said.

"Well," I said, taking out my swiss army knife, "I guess there's nothing to see here."

I have to say that I've never encountered such a nice, enthusiastic, friendly group of people with such an abysmally low morale as the crew of a cross-country train. With passengers they're great, but all through the trip I'd see two or three congregated having low muttered conversations. It didn't take me long to figure out they were talking about management. And while the experience was wonderful, the equipment was in horrible shape. It was like traveling in a third world country.

With management that bad, more data doesn't equal more accountability and better performance. It means scapegoating.

Beg to differ all you like, having lived in one of those countries most of my life and another of them for a number of years, I'm not impressed.

Certainly it affects all those things. The drivers get a decent wage, the schedules and routes mean they run all day, and often all night, when purely commercial operations would not operate outside busy hours and routes, and unlike the unlicensed systems you mention, they tend to have stops with electronic countdowns to when the busses are due.

In Britain they partially "deregulated" the busses in the 1980s, and the services got worse and more expensive.

As I said, your opinion is prejudice, not reality.