If you're that close, the existing bluetooth and WiFi should be able to manage nicely.

TFS and TFA say 'up to' 500 meters.

That would be an interesting application, but I doubt the carriers are going to hand over sufficient control to implement that.

The dhcp client in OS X runs sandboxed (I believe), so there's less potential for an attacker to exploit it if they can make it run arbitrary things - it doesn't have general filesystem access.

The issue I'be had with it is that it doesn't really do merging, it does 'server always wins'. This means that if you delete an event locally, on the next sync it will reappear. It's fine for new events created on the device and for events created elsewhere if you just want to view them on the device. I use owncloud on the server and iCal on my laptop and editing things on either of those is fine.

The reason I stopped using the search engine was that they made a UI that pissed me off enough to make me quit. I've not found Google UIs to be particularly well designed in general - I could file a few hundred UI bug reports on the general Android system, including a lot that are regressions.

One use case that's often touted for this kind of thing is having appliances that can work on spot pricing for electricity. Over the course of the day, you get spikes from solar and wind (and tidal and so on) production when electricity is cheap. You get periods when power plants need to reduce capacity for maintenance when it is expensive. There are massive power storage facilities that profit from this: there is one near where I used to live that pumps water up a hill into a reservoir when electricity is cheap and then lets it flow down again and generate power when it's expensive. Now imagine if your fridge or freezer could get this information in real time and could run the compressor a bit more when electricity is very cheap, then use the cooled coolant to keep your food cold when the price goes up.

Almost 50% of the electricity generated in the USA is wasted because the supply can't adapt to demand fast enough. There are some very big savings to be made by having demand adapt to supply.

Really? About the only Google app that I haven't replaced with something better (and open source, so money / distribution rights are not an issue) is Google Play, and that's only because my bank and a few other companies only make their app available via Google Play.

A few of the HTC apps were nicer than the AOSP versions and the same is true of the Motorola ones. The problem for people who don't drink the Google kool-aid is that hardly anyone is working on the AOSP versions of most apps. If you buy a new Android device, there's no calendar app that can talk to a CalDav server (which, for example, any iOS device and most open source calendar apps for desktop can do out of the box). F-Droid has one that is designed to, but it has a terrible UI and doesn't integrate nicely with the rest of the system. There are a couple of sync adaptors, but Google has increasingly broken the sync APIs for things that are not Google.

Or they could just say no and if the U.S. want to jump into a hidey hole and pull the opening in after it, so be it.

No. The cause of the delay was that he could unintentionally (and even inattentively) violate the security setup. If nobody is supposed to go that way then it shouldn't be possible at all. If only some people are supposed to go that way then someone should be posted to make sure only authorized people do that.

If it was such a security emergency, shouldn't someone have seen him sooner and led him back the right way so he wouldn't contact anyone already screened?

But only with people close enough to walk over and talk face to face.

I see no evidence that you are one of the people who assures that electricity comes out of the socket. After all, when I make any vaguely technical statement to support my point you ignore it as if I offered you the plague.

The people griping to legislators aren't either. They're more the making sure that bonuses and dividends come out of the customers type.

You're not even listening. I was quite clear that there is justification to split the billing for grid services from billing for power. The former can probably be similar to the 95th percentile billing for network traffic. The average non-solar customer should see no difference.

No, I'm resuming that if they can deal with things that can only be predicted on a rough statistical basis like power poles being knocked down, they can deal with things that can be predicted reasonably well in the short term like the shadow path of a cloud going overhead.

It is clear that you have made your mind up that solar is evil and no force on heaven or earth can ever change your mind, including the distinct lack of burning transformers in rich neighborhoods. I might as well go to the nearest serpent handling poison drinking church and share the evidence for evolution with them.

I completely agree. If you try to become involved with an open source project because you think it would be fun, your enthusiasm will likely fizzle out fairly quickly. If you try to become involved with an open source project because you actually want to use it and want want to improve it, then every time that it doesn't do something that you need then you'll find yourself with a project. One of the nice things about a project like FreeBSD (to give an example of a project that I'm heavily involved in - there are others that have this attribute) is that there are enough small parts that it's easy to find small projects in the individual components to keep yourself occupied.

The real problem has nothing to do with types, it has to do with design compromises to work around the fact that UNIX lacked shared libraries. Rather than provide a glob function that everyone could use (as with later versions of UNIX, after shared libraries were added), they put globing in the shell. This meant that the shell became responsible for handling some arguments, the command for handling others. As a natural consequence, you needed to provide a mechanism to escape the command-line arguments that you didn't want the shell to get at. And then you start using shell invocations as your mechanism of running programs (via the system() C library call) and now you need double escaping or triple escaping and so on.