I have seen it coming. Nokia have been living in their comfortable telco-friendly niche for too long.

1. They have a ton of low-end models, each one seems to have different menus and a lot of missing features, as if telcos got to choose what features to remove so that they can try to sell a new phone contract every year.

2. Their middle-range models also lack in features and the quality does not always reflect the price. I paid 240 EUR and the side keys fell apart in one year.

3. Their high-end phones were basically show off pieces without a proper or at least not developed enough eco-system.

4. Their PC software has become a bit too bloated and it has some basic bugs (some MP3s not showing on the phone list, disk crawler locking up files...).

The combination of these drive many low-end users to experiment with other companies phones and most high-end users to try iPhone or Android.

The sad part of the story is that TEPCO crew apparently knew enough to figure out what was going on (whiteboard photos prove this), but officially they pretended they didn't know and simply omitted strongly suggestive datapoints from public releases. Only now, when enough isotopes have been blown around northern hemisphere that any interested scientist can sample the isotope ratio in the air and work back the numbers they slowly admit some truth, while still covering up what really exploded in reactor number 3.

I've implemented several RTMP servers for gaming, telcos and sideprojects (www.voicehall.com), and found a ton of border cases and a few undocumented features. Besides there are patents on some mechanisms of server implementation, but the ones I've found are not difficult to get around (at least I could get around them for our applications).

As far as transport is concerned, RTSP using a direct TCP connection is quite efficient with barely any slack, however RTSP over HTTP (say behind a firewall that only lets through HTTP requests) is quite nasty and not so efficient. It's not difficult to design a better protocol for streaming over HTTP, especially if you don't care about latency very much. A smart design would also name chunks in such a way that addressing the same (live or not live) streams by multiple clients could allow caching by HTTP proxies. The caching issue alone would be the big plus of a good HTTP streaming implementation, otherwise you can't do much better than RTSP over TCP.

Having actual experience with how lottery works behind the scenes I'd say this particular place was not run by people who knew what they were doing. You can't be so stupid to print something that is correlated to the outcome. This is something that would need statistical evaluation beforehand. Anyways, the way around it is to print independent serial numbers from a totally different random sequence or some strong crypto hash based on this other independent sequence. You can use these independent codes if your sales places are online so that a server can check ticket outcomes stored in a database. One would still want to test for proper stats before the series gets printed.

PC audio testers always forget to test for the influence of power supply on output noise. I noticed simply changing the power supply makes a big difference to the output noise level. Also some ventilators and other PC components draw current in bursts so there are nice clicks on transitions. This will affect both on-board sound and internal audio cards. I can tolerate a few decibels of white noise, but I don't like to feel like a doctor listening to PC internals. So I'd like to know how an audio component performs in worst case power supply scenario.

Would you feel secure if everybody could see and photograph your password? Then it's just a question how easy it is to make a replica that will fool the system.

Besides, I have heard from a major expert on the topic that there are many iris/retina conditions that make the system fail, meaning the system is unable to extract required features or unable to uniquely identify individual. In fact, there's no single biometric method that will work for all the people and uniquely identify them. You have to combine several features to get anywhere close to 100%.

I had tons of linux issues with Broadcom drivers and figured out both driver software and firmware were problematic. The Broadcom binary driver for my Broadcom chip version is not available, only the general linux driver, which nearly works. Now the tricky part is the firmware. Windows drivers update firmware on the fly whereas linux drivers don't. In fact, changes in firmware cause linux driver to work intermittently. Sometimes linux driver will fail to initialize connection due to some problem with firmware connecting to a particular switch, whereas windows driver has no such problem.

The key problem is firmware updates are not included in linux drivers due to legal reasons, it's not too difficult to reverse engineer that part from windows drivers.

So what Broadcom needs to do is to open source drivers and give permission to distribute firmware update code with open source drivers.

I've been dealing with Bayesian methods for a few years, too. I understand the goal of the hardware is not to run everything that is being sold as Bayesian methods. Basically Bayesian calculations mean computing conditional probabilities, which usually gets down to a ton of multiplications and additions. If the analog hardware can produce results for a particular subproblem with sufficient accuracy, then you are saving a lot of power and time. If it can produce estimates that are not entirely accurate but within sufficient bounds, then you can still avoid a whole lot of digital computations by narrowing down on possible solutions.

In the Cairo museum, next to the Tut's collection (it may be part of it, I'm not sure, I was there years ago), I saw a foldable bed frame with metallic hinges. I thought that was the technological high-point of the museum, I haven't seen anything like that from the same time frame anywhere in the world.

Not really, it's one of those cases where criminals get caught because they are not paranoid enough. One of the domains that received info from the botnet was registered using a real name. Another incriminating fact was they got caught connecting to the botnet directly from their own IPs. And to top it all the supposed mastermind was selling the botnet software for peanuts advertising with pricelist and everything on his web page. A paranoid hacker borrowing domains and tunnels from infected servers would not get caught so easily.

Looking at the wavelength (which is the same as bluray) there is little headroom to decrease track pitch and increase bit rate, so it is unlikely they can increase layer density by more than a very small single digit factor over bluray.

So getting to 20 times bluray capacity will require many more layers.

As the disks cannot be spinning much faster it would also be necessary to read several layers or several parallel tracks simultaneously otherwise read speed will be laughably slow compared to capacity.

Obviously, there are quite a few problems to solve. Assuming they are solvable, can they make working prototypes soon enough to get to market while 1T optical capacity still seems exciting compared to other storage and distribution technologies?

Having seen some of the weirdest stuff found in computer forensics cases, I can tell you you have no idea how seeing really sick photos and videos changes even the perception of possible dimensions of sociopathy. Child pornography per example is not illegal because the photons are hitting your retina in an illegal way. It's because really sick people are torturing innocent children for the pleasure of a few other problematic people. Do you want to help them gain their weird pleasures or do you prefer to protect the children?

That's not how they do it. They either attach a second card reader chip to the pins or wires that go to existing head or attach some nearly transparent head+electronics at some external place that's highly likely to be close to the the card stripe.