1. they are. They're just not very good.
2. there's stuff on the back of your phone. If you add on a keyboard, you block those things and/or have to work around them some how.
3. (if you didn't do a slider keyboard) the other options is a folio style. Generic ones exist, but they're very bulky cloth or (faux)leather wallet things with a keyboard shoved on one inner side.
4. more battery needed (takes up room, and it's another thing to charge).

Phones with a built in keyboard can move stuff around the back of the keyboard. They can stick the battery in the keyboard part if they want. It's little things, but they're really needed to make it worthwhile.

As I mentioned above, the Typo keyboard for the iPhone is another alternative that does seem to work. It rips off the blackberry, more-or-less. Something like that *could* be made for other devices, but it's not as desirable in other ways (adds permanent length to already long phones, and puts the keyboard on the portrait side, etc).

Completely agree then.
The biggest issues with the sliding keyboard cases for galaxy S4 and S5 is that the camera, which is centered on the back, gets blocked even when the keyboard is slid out (the cases have an extra hinge so one can then fold it some, which leaves the camera the clearance it needs, and makes it really awkward to use and extra bulky).
The only add-on case I've been able to find that appears to be decent is that typo one for the iPhone. Wish they made them for other phones.

I'm hoping we see keyboards make a short comeback. Between the samsung galaxy S3, S4, and S5, there really weren't many significant changes. It wouldn't take them much engineering to get a keyboard properly integrated with one (or any other maker to do similar), and they could nab some upgrades from folks like me that see no reason to upgrade (only thing the S5 has that I want is the water proofing, which I hope becomes commonplace).

WHAT!??!!
I haven't found a keyboard case for the Samsung Galaxy S4 that I would use (though I really want a keyboard), but keyboard cases exist for the first two you mentioned (haven't looked for the nexus). Or am I misreading your post... are you saying you would NOT buy an iPhone nor Galaxy SIII?

Ex: iPhone (I really like this case): http://istoreworld.com/us/typo...

Here's a sliding one for the iPhone: http://www.amazon.com/Bluetoot...

I have trouble seeing any of the justifications for getting a public CA cert for a name like "Server1" with an internal IP.

You could use your own internal CA, as others have noted. There is overhead to doing so and, being lazy, just buying the public cert may have seemed like an option.

However, one could simply use a real DNS entry, and all would be fine. Ex. server1.int.my-domain.com. Setup the "int.my-domain.com" on dns servers that all your internal hosts can see (they're all internal, so that can't be TOO difficult, and it doesn't hurt if that's visible from external). It's really quite easy to setup DNS, and it's cheaper, and it'll work with the CA just fine, and will work if/when you move the service to a public IP, or if you adopt an internal CA, etc etc etc. Why NOT do this? You can even host your DNS for free somewhere online.

... is that the same risk team that would authorize the purchase of a public cert for "Server1"?

I think the original point was that it takes almost nothing to sign certs. There need not be any significant investment.

Sun-Thu is when you go out for dinner/drinks/fun because on Fri/Sat all the good places are too packed all types of annoying people.
Fri/Sat is when you relax after your long and taxing week, take in some TV, drop off/pick up your laundry, etc.

Perhaps one of these? https://www.youtube.com/watch?...

Not sure telespoking scopes would do any better.

This.

Using some supposedly intelligent avatar instead of a clear, simple, and well designed UI ranks right up there with the automated call interfaces that ask you to speak your answers instead of pressing the number buttons on your phone. People complained because pushing numbers sucked; RCA was incorrect; we ended up with a system 10x's as frustrating that takes 3x's longer to operate.

I've found the self-service check-in's to be rather good, but the physical integration of them has left a lot to be desired. IE. there is no line for them.. there's just a bunch of them scattered about. Then you still have to take your bags somewhere, and figuring out where that line is, and how it differs from the line that includes getting your ticket, is often a complete mess. You often have to wade back through all the folks wandering around the kiosks to find the front of the new line. It should be a LOT simpler and organized much better... though I'm sure this is a per-airport, and possibly per-airline, issue, so YMMV.

Which is basically what I described immediately following that. As long as the registration is something that is not trivial to spam (thus my suggestion for a challenge response akin to DH), then that'd do fine.

But what is the protocol on the wire? One doesn't *have* to go through the app. If the protocol only has a pin in it, then it doesn't matter what app requirements they make. The client must be uniquely and securely identifiable before that 3 strikes and your locked out stuff goes into place, and it has to have some level of complexity to register a client. These are solved problems in public cryptography but, from the sounds of their "hack", I doubt the existing protocol has space for these extra features.

At which point, anyone in the world could very very easily DOS your car.

There are ways around that, but the naive and very very common implementation you describe is trivial to DOS. I'd hope that the users key could still get them in and get an override, but the app should use much stronger auth to avoid DOS issues (ex. challenge response with something that requires largish compute time for the client in order to register and calculate a very large shared key - ie. this would be a one time registration per client app; then use the lock out on a per-registered-client basis; thus is would be costly to generate more client ids, and the lock out would make each only worth a few bad tries before forcing re-handshake). PIN would still be used on top of that (adds another factor, and something easily set/changed on the car side).

I just noticed a couple days ago that newegg.com is also accepting bitcoin. Not sure how long they've been doing that, but it made me wonder how many other places where. The list in TFS was a surprise to me.

This is what I was wondering about the most when I read the summary (not just apple though).
Within Microsoft, I'm guessing there are many different groups, and many are fairly well defined. There's all the runnning-a-business cruft (management, marketing, helpdesk, support, etc), and the various product breakdowns (xbox, office, windows, vs, surface, etc etc etc). Ditto for all those other companies. I'd love to see a headcount of people that actually make stuff per product per company, and the count of those that are getting laid off. I'm actually surprised by how small the headcounts are - I assumed there'd be a ton more overhead (like all the apple people working in retail).

I didn't say 99% did live in big cities. I said that, of those in big cities, the majority there could not make use of this.
FWIW, more than 1% of the population of USA lives in LA. Nearly 3% live in NYC.

For who? Do you want random people getting in your car without any supervision and doing who knows what in there? On the flip side, who wants to get in a driverless car and allow the owner to control what happens to them remotely (I'm assuming you would not allow them to choose its course, else they could easily strand it anywhere they like... talk about inconvenience). Besides, real taxi drivers tend to handle queries like, "hey, I need to get to that theater down by atlantic... you know the one?" much better than I'd expect your personal driverless car to do.

That's extremely subjective. I'm quite certain that parking is free for employees at the vast majority of employment sites. The times when it costs money, you're often in a large city (as you noted, most people don't live in NYC). Within large cities, if you have a garage, you're likely to be living outside the city. If you're making that commute, then:
a) there's a higher likelyhood of tolls exceeding the cost of gas
b) gas cost will be higher if you're that far away
c) WE'D BE DOUBLING THE NUMBER OF CARS ON THE ROAD!

How is that not a down side? (you stated there were none)

Getting in the way of everyone else, and likely during rush hour. If it had a driver, he would get out, possibly ask for help, and push the car to a safe location. Without a driver, everyone else is up shit creek until the tow truck comes.

Most accidents do not result in an unconscious driver, and hit and runs are a rare percentage of accidents. If a driver is there, even if unconscious, you have immediate access to their ID and, likely, their contacts (via their phone). Driverless car - it's just going to sit there and clog up the road way until the tow truck comes.

No need for driverless for any of these.

Like what? Picking your kids up from school? Busses solved that ages ago. We don't need every parent sending their driverless cars around to pick up their kids individually, wasting loads of resources, clogging the roads, making it far easier for kids to be irresponsible (let along easier for the kid to take the wrong car and end up who knows where).
Parking for you? First, are you really that freaking lazy!?! Second, an automated parking attended would be much more efficient, and would work with all cars on the road today (pull into a drive through carwash type of thing). Lastly, no one wants to wait for the giant line of driverless cars that had been asked to come pick up their lusers way too early.

I predict that, should driverless cars happen, they'll become one of the most annoying things we have to deal with day to day.
Please note, none of my comments are against greatly enhanced cruise control - even fully automated. I'm only saying that an empty car should not, IMO, be driving around.

No. That's not the point being discussed. We're talking about driverless cars, not cars that can drive themselves. There is a fine line between them, but it has a very significant side effects.

The cars google has been testing for a long while on the actual highways... they're cars that can drive themselves while on the highway. They do not start out on their own, empty of a passenger, and make the whole trip as a programmed route (though they now have some that can do that).

The newer automation allows the car to do things on its own with no one inside it (zero or more people).

Both have the same potential for positive safety impact while driving. However, driverless has a whole lot of side effects for all the myriad of edge cases where it stops working or does weird stuff or is misused or abused etc.

In both of your examples, a driverless car is not mentioned. Your 1hr drive to work, and your 6hr drive to your family, can both be done with self driving cars that are not driverless. I'm fine with that; I'd encourage that especially for the long highway trips where many fatal and near fatal accidents happen due to drivers getting bored, dozing off, getting distracted, all while cruising along at high speeds. Computers are quite good at handling that type of situation - damn near perfect.

I'm much more concerned with the downsides to driverless cars, like what all the assholes will do with them when they are even slightly inconvenienced (stopping at a store with no good parking spots - just set it to drive around the lot in circles indefinitely until your done; ditto to avoid paying for temporary parking). The benefits of driverless do not come close to out weighing the negatives.