Does it not make more sense to use clean, filtered water to transfer the heat out into the ocean? The heat exchanger can sit in the ocean to facilitate removing heat without the worry of having jellyfish clogging filters. Effective cooling capacity might be reduced without an active water stream going over the heat exchanger, but this can be compensated for by using a larger one.

The only possible problem I can see is the build-up of aquatic life on the head exchanger. They would require periodic cleaning. But unlike filters, you would not have to shut down the cooling system to do so. In addition, you don't have to worry about there being any sudden changes in the cooling capacity of the system so it should be much easier to plan and perform the cleaning.

It was reported that Apple works is a similar fashion - small groups of engineers working on specific projects. When you bring too many engineers in on a project the management overhead becomes immense. The difference was likely with the quality and style of management. The fact that Jobs was a control freak, semi-tech savvy, and personally interested in the products likely worked in Apple's favor. No bickering between different divisions of management when they know Jobs will send them packing - being the ass he reportedly could be. RIMs downfall likely comes down to poor coordination between different sections of management. They had plenty of good engineers at their disposal, but they were not utilized correctly.

One has to give Jobs some credit - he was obviously not in it for money or politics, he wanted to make stuff he thought was great. (And fortunately for Apple, other people also shared in his sense of style.) This differs from other CEOs I've read about in that they appear to be more interested in playing politics to their own benefit. They don't appear to be interested in making anything let alone doing what is best for the company. The next quarter stock price - that is the only thing that is important. (But one tends to only hear about the bad ones so this is probably is not an accurate generalization - although reading SlashDot sure gives one this impression.)

The new AMD flat memory model for GPU / CPU is very interesting. I assume this is what will be used in the upcoming consoles. But you have to realize that the console and PC markets are currently being crushed by the newly created portable market (Android / iOS). The larger market of iOS users combined with the App Store model that limits piracy has game developers making more money with their stupid little Apps then they do with their much more impressive console games. The Android market is also growing and, despite being limited by piracy, will eventually catch up with regards to developer profits.

AMD looks like it's making some impressive products when it comes to GPU / CPU integration. If they could catch up to Intel fabs (now at 14nm) they would be doing great in the market. They might also bring their flat memory model to mobile ARM CPU/GPU chips which would be quite interesting. But the reality is that AMD is not going to dominate the market anytime soon. Those who think otherwise have been drinking too much AMD Koolaid. These changes take time and we don't even know how Intel / Nvidia plan on responding - and they will respond.

Filtering should be performed by the client so there is no uploading of personal data. The server must send clients the filters for various different alert types. The user would then have the option of editing the filters should they not like the default values.

I'm with you on that one.

Alerts are fine so long as filters can be applied to minimize the number of people that receive them. For example, GPS coordinates could be effective at limiting the number of recipients. Add to that accelerometer data to determine if the person is moving or possibly asleep - also helpful.

Alerts must be minimized or else people will start ignoring them. It is similar to how people would just click "Allow" whenever Vista prompted them with a security warning - most people would not even read the message after seeing so many prompts. So use some intelligent filters along with sensor data to minimize the number of alerts or risk all alerts being ignored.

The suggestion was a replacement for maintaining two old boxes - one running VNC and another as a backup. In this situation you are not going to have very many concurrent users - most likely only one user at a time. This solution also requires a VNC client be installed on each client computer.

Serving the application on VirtualBox (or another VM with an RDP server) does not require client software to be installed on 10000 workstations. Windows already provides the required software. Provide a configuration file that the user double-clicks to connect. The configuration file configures their client to connect to the server with appropriate settings for your organization.

Login credentials for the VM can be provided indirectly with Active Directory - depending on the VM software. With VirtualBox, the RDC server can be configured to authenticate users in several different ways - they even provide an API for writing your own. One common method is to authenticate users against users on the host machine. Configure that host to authenticate through Active Directory and you have Active Directory control of the VM.

I am not suggesting an industrial strength solution - for that you will have to rewrite the application. But what I suggested is far more maintainable then installing VNC clients and maintaining / backing up outdated hardware.

Actually useful for medical sensors.

Run VirtualBox on a machine and setup the appropriate guest OS to run your software. Enable remote display in VirtualBox for your newly created guest OS. Now anyone can connect using RDP or VPN - whichever you decide to host. I recommend RDP because the Windows clients will already have client software installed.

This is easier than setting up VM software on every computer. It also removes any restrictions governing which computer you can use to host the VM. And finally, it makes creating backups of your guest OS / application much easier as you just backup the VM image. The ability to take snapshots of the guest OS is also very useful.

Of course, other VM servers would also work. My experience is with VirtualBox and, despite being free, works suprisingly well in this sort of situation.

Standard GCC 4.0, GCC 4.2, and 4.2 with LLVM backend are installed with XCode - at least the current version. Calling "gcc" executes the version with the LLVM backend. If you want the standard GCC backend, just call "gcc-4.2" in place of "gcc".

Complaining that Apple has provided too many compiler options is a little ridiculous. Developers should be able to figure these things out. One expects Apple to simplify things for regular users; but as a developer, I appreciate that various options were made available.

A shortage of pilots is possible but not fighter pilots. The jobs that will require pilots will be the boring jobs - not those where you get the break the sound barrier. For every F22 pilot I'm sure the air force requires 100 other pilots and it's those for which the air force might be hard-up to find replacements.

Not all predators.

Listened to an interview with a "wildlife management officer" in India. He talked about how once a big cat gets a taste of human, nothing else will suffice. The salt content in the blood is what causes the problems. This leads to big cats that prey on humans exclusively - a problem for some. The tell-tale sign is when you have a small village where every month or so, someone goes missing.

Being free had nothing to do with displacing the other big UNIX vendors. When you invest so much money in hardware the cost of a well supported OS is nothing. Linux has displaced these operating systems for a few reasons. First, Linux is now good enough and has most of the features users require. Second, it detaches the user from any one vendor thereby greatly reducing the cost of new hardware. Third, the increased popularity of Linux on standard desktop hardware has produced many users that are more comfortable / productive with the OS.

There are probably other reasons as well, but nobody running a system that costs 6 figures gives a damn about the OS cost.

Brown is not what you want. They are similar to the "blue" keys but with less noise - I actually own both. There is still a significant distance the key must travel (up then down) to register sequential keystrokes. What you really want are the "red" keys. These keys require only a minimal amount of travel and do not have a noticeable "click" when activated. A pain for typists but it allows gamers to press keys at a very high frequency. The "black" keys are similar but require ~50% more force so they're a bit slower.

But all mechanical keyboards are great at minimizing latency - it is because of the differences between switches and capacitors. The chiclet keyboards work my altering observed capacitance - this requires a controller to continuously scan for key changes and then send the appropriate signals to the host. This takes time and results in the latency the original poster was talking about. Mechanical keyboards are simple switches and are faster to scan. I imagine some mechanical keyboards are even interrupt driven resulting in latency measured in microseconds -- but changes in capacitance can't trigger interrupts.

It is saying that drivers require a 90% or better approval rating. If the driver has a major screw-up they will burn a pile of karma (or stars) and might be excluded from the driver pool. A minor screw-up burns less. But to actually understand the rating system you should know the passenger guideline on how to rate drivers. I imagine that a driver that does their job on time, is safe, and doesn't smell too bad gets an automatic 5 stars.

Along those sames lines, I always thought using GPS to track the location and power requirements along any given road could help with automatic transmissions. One really notices the problem when driving up inclines. Espically with lower powered cars, the automatic transmission should know to not change gear all the time. For this to happen the transmission needs to know future power requirements - something that could be obtained via GPS and past driving history.