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.

But people get their power from the power grid. Every joule of energy you leave in the grid by using your internal compustion engine results in a joule of energy that doesn't have to be generated. But the generation plants that shut down due to relaxed supply are not those burn coal. Coal is cheap so power producers use coal first when possible. It's the oil and natural gas plants that will slow down when demand drops.

Buring gas in an internal compustion engine is less efficient then either oil or natural gas so it is best to use electricity if available. And if you are worried about the environmental impact of generating power, be sure to support environmental tarrifs/taxes on any new coal based facilities - like that will ever happen.

Not really. It is much less expensive to allow the patches to be integrated into the parent project then it is to patch the project after every update. In addition, others will be able to test/verify that changes don't break the patches if they are given access to them. So it makes sense to feed back as many patches as they can as it greatly reduces the effort required to maintain their port.

That's not the problem here. The flicker that is being observed is not the refresh rate of the LEDs but the refresh rate of the LEDs when masked by the refresh rate of the LCD.

Try looking at a video recording of a CRT screen. The refresh rate of the CRT is plenty fast but, when sampled at the sampleing rate of the video recorder, visual artifacts are introduced. This is why newsrooms always synchronize the CRTs visible from the camera from a single source.

What the original poster described is likely an artifact of the LED and LCD hardware not being designed to work together. The manufacturer probably took off-the-shelf parts to design their product without worrying about how they interfaced with each other. Who knows, the design might have originally worked great but then someone changed one of the parts to save some money. As a result, %5 of the resulting products end up showing flicker.

This is not a hard problem to solve and I assume most high quality manufacturers have done so. But manufacturers that bundle the lowest cost components together could very well see this problem.