There is no need to get rid of Tor: in theory, Tor could have a "hidden service policy" mechanism not much different to the exit policy mechanism. HS Policies would allow a node operator to state that they aren't willing to act as an introduction point for a list of hidden services (or point to lists maintained elsewhere to stop fast-flux type behaviour).

Tor already accepts that not all relay operators will want to support all kinds of behaviour and that some kinds of traffic can be abusive, that's why they implement exit policies which allow exits to ban port and IP ranges. Taking this philosophy to hidden services seems like the next natural step. After all, Tor volunteers are ultimately acting as human shields for other people's anonymous behaviour. Requiring them to shield everything just restricts the number of people who would be willing to donate bandwidth to general privacy but are not interested in enabling botnets.

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.

Not sure what you're getting at, but the Azul collector is well known for pulling off apparently magical GC performance. They do it with a lot of very clever computer science that involves, amongst other things, modifications to the kernel. I believe they also used to use custom chips with extended instruction sets designed to interop well with their custom JVM. Not sure if they still do that. The result is that they can do things like GC a 20 gigabyte heap in a handful of milliseconds. GC doesn't have to suck.

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.

I think it's more likely that more people are becoming obese because of exactly one factor: age. They are living artificially prolonged lifetimes due to access to adequate food and to medicine. It's easier to get fat when you are 50 than when you are 30 because of the natural changes in your metabolism.

If it really was difficult to find programmers they'd have at least considered training some of those workers in the desired skills, workers with a known history rather than some stranger off the street (or from across an ocean).

When wages go down as prices don't, that's actual hardship. It's called "cost of living" rather than "cost of luxury" for a reason.

And software process methodologies as hokey as that game.

http://www.youtube.com/watch?v=k0mRfECsHrc

With little models of the LEM and Command Module on their desks? Pointing at things with their pens, as they described technical aspects of docking and landing?

It was quite a different world.

I was 5. We were painting the walls of the Television Room - what we called it then - in Avacado. Shag carpet was coming in next. Neil stepped down the ladder, whil ethe set was swaddled in an old sheet for drips...

Like yesterday, almost.

Ripple, before the name was bought by a Silicon Valley company and changed into something a bit different, was more or less exactly this.

There's a video on the original web page that explains this concept quite nicely. You could set up debt relationships between people and denominated in any currency, including ones you invent on the fly like hours of The Real Mike's time. However it never really took off in a big way, perhaps because it was rather complicated, and bootstrapping such a system from the internet (full of strangers who don't know each other, don't trust each other and may not even exist) is presumably very difficult.

However if the concept sounds interesting you could do worse than check out the original thinking by Ryan Fugger behind Ripple. Satoshi once told me that Ripple was interesting because it was the only system that does something with trust other than centralise it.

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?"

Ready with everything but time. :-)

It establishes a conversational rapport with a group or audience, correctly delivered - and can be used as a framing device to explore what might be a foot note or parenthetical comment, if rendered in text. I can be varied with "I find it interesting..." or "You might also think this interesting:..."

Unless the text is conveying an overall, conversational style, I think usage is dubious and should be employed after consulting the general context.