This is a general problem with devices that are "paired". How do you securely establish the initial connection, when neither side knows anything about the other?

The secure solutions involve some shared secret between the two devices. This requires a secure transmission path between the devices, such as typing in a generated key (like a WPA2 key) or physically carrying a crypto key carrier to each device (this is how serious cryptosystems work).

Semi-secure systems involve things like creating a short period of temporary vulnerability (as with Bluetooth pairing). There's a scheme for sharing between cellphones where you bump the phones together, and they both sense the deceleration at close to the same time.

Apple's reputation management service is reacting faster now. It used to take them an hour to mod criticism down. Now it only takes 15 minutes. Who are they using?

This may be the backdoor known as DROPOUTJEEP, which was described in some Snowden-leaked documents last year.

Looks like Apple sold out, put in a backdoor, and then lied about it.

"Smoke me a kipper, I'll be bake for breakfast!"

Consider trying QNX, the message-passing real time OS, for this. This is a message passing problem, and Linux doesn't do message passing well. QNX has a scheduler optimized for message passing. You should be able to handle the UDP front end and fan-out without any problems. You can give the front-end process a higher priority than the other processes, which should let you get all the UDP packets into the fan-out program without losing any. That's what real-time OSs are for.

Trying to do anything high-performance with CPython's threads is hopeless. Watch this presentation on performance issues with Python's Global Interpreter Lock, Python has an internal scheduler, and it behaves very badly under load.

So each Python process should be single-thread. Have as many as you need, set up to get work via MsgReceive and reply by MsgReply. Don't set them up as "resource managers".

Python under QNX is being used by the robotics community, where real-time matters for some things, but not others.

QNX - great technology, marketing operation from hell.

That level of control probably belongs at the cluster management level. We need to do less in the OS, not more. For big data centers, images are loaded into virtual machines, network switches are configured to create a software defined network, connections are made between storage servers and compute nodes, and then the job runs. None of this is managed at the single-machine OS level.

With some VM system like Xen managing the hardware on each machine, the client OS can be minimal. It doesn't need drivers, users, accounts, file systems, etc. If you're running in an Amazon AWS instance, at least 90% of Linux is just dead weight. Job management runs on some other machine that's managing the server farm.

There is a serious bipartisian proposal in Congress to reduce the tax deduction for advertising. Call your Congressional representative and tell them you support the elimination of tax deductions for advertising.

Because the US savings rate is so low (most people are spending almost all they earn), advertising does not increase demand. It just moves it around a bit. All advertising does is increase prices. There are many products, from movies to medications, where the advertising cost exceeds the cost of production. Let's put the brakes on advertising.

It's not just about Wikipedia. Mr. Barry's press agent claims he is also suing the National Post (Canada) for publishing a critical article, "The world according to Yank: Montrealer with checkered past gets Nobel nod, or does he?"

That jet-powered locomotive was neverintended as a useful means of propulsion. It was just to test track-train dynamics at higher speed. Not much was done with the info, since Amtrak wasn't into high speed rail.

The next big advances in high speed rail were Japan's Tokaido line and San Francisco's BART, both around 1970. The original Tokaido trains had conventional wheel arrangements, and required a very good and very high maintenance roadbed. The SF BART system had the first trains with an active suspension, with each car body supported on a triangle of three air bags controlled by electronic controls. This allowed a higher body height at higher speed, allowing more wheel travel and a softer suspension. Also, all wheels were powered, as is normal in transit operations.

The French TGV brought both of those ideas together - high speed plus active suspension with more suspension travel, with all wheels powered. This allowed high speed trains without excessive track wear. (That's a big problem with high speed rail. A French test in 1955 reached 331 km/h, but damaged the track seriously in only one run. There were serious doubts for years whether steel wheel on steel rail could ever go that fast in routine operation.)

As with cars, there's been more than enough power to go fast for decades. Wheel and suspension issues are what limit speed.

You want, of course, to block all email from pseudonyms.

What "software renaissance"? The writer means the appcrap boom - millions of small bad programs, with a few good ones. Many, maybe most, "apps" could just as well be web pages.

The appcrap boom seems to be winding down. Developers realize that writing a quickie app has roughly the success percentage of starting a garage band. That's a good thing.

It's a great time to code, if you have a problem to solve. The tools are cheap if not free, the online resources are substantial, and there's vast amounts of cheap computing power available on every platform from wrist to data center. If you don't have a problem to solve, coding is sort of pointless.

Heating, ventilating, and air conditioning. The job sucks, but it's steady. Automation of ductwork installation and repair is a long way off. Unlike construction, there's maintenance work; someone always needs their A/C fixed.

A "web based password manager" has one job - keeping the passwords secure. That's all it does. If anyone easily finds a vulnerability in that, the service is a failure.

MakerBot has never before sold through a retail outlet that takes returns. A lot of those machines will come back.

Come on. The article is a joke. " A chess facilitator brain implant would be wired between perception and cognition. You would just look at the board and know if it is checkmate." Did the original poster not realize this?