HAHAHAHAHahahaha.... oh wait, you were serious.

How did you manage to miss the entire point? And further, where did you learn logic and economics?

Getting denied access to a cost=1x device and instead being pointed to an inferior cost=10x device is not about the profit motive at all. It's about avoiding fraud. As a previous poster said, if Medicare actually approved iPhones for speech impairment, we would, overnight, see an epidemic of speech impediments in the US, orders of magnitude over what the base rate is now.

Now if Apple made an iPhone with app store, internet, voice, and iPod functionality disabled that could run this application only, then I suspect that Medicare would approve it. But Apple won't (because of the profit motive). Designing, building, and marketing devices is expensive. It's hard to bring a device to market that will only be bought and used by a small number of people, and such devices tend to be clunky (just good enough because elegant design is expensive and time consuming and you're already fighting expense) and expensive (because you can't take advantage of economies of scale). Government certification (because in the US, they often foot the bill) is also expensive.

Bad example. Comparing infant mortality rates between countries is not an apples-to-apples comparison; making such an assumption inaccurately assumes that we count the same way. We don't. In fact the way we count guarantees that we will have among the highest counts.
http://health.usnews.com/usnews/health/articles/060924/2healy.htm

Infant mortality numbers do not indicate that the US health care system is in any way inferior to anyone else'. There may be compelling arguments to support such a proposition, but infant mortality is not one of them.

BTW why are we discussing this in a copyright thread?

A far more serious issue will be sustained engineering - patches and so forth.

The AC is a retard.

NTFS reads blocks. If your hosts file is smaller than 1 block, it doesn't make a disk I/O difference HOW BIG each address is.

String parsing is fast. Perhaps it would be a reduction of a couple dozen CPU cycles to read a "0" rather than "127.0.0.1", but that actually might be offset if the code to look for 0 caused a page fault due to code bloat to support special cases. Under the covers Windows would still have to alloc a SOCKADDR so we're only talking about a difference in parsing complexity.

Plus, the AC poster obviously isn't familiar with Windows DNSClient service. It is not actually necessary to parse LMHOSTS every time a network connection is made by name; the file is only parsed when it changes.

None of these are better, as they will all be interfered with or blocked by NATs and inline IDS. The sole exception is extra ACKs, which might be caught and cause a channel reset with some IDS devices.

The payload in a retransmitted packet will be carried unaltered regardless of intervening network hardware.

Detecting retransmits can be done and statistical anomalies detected. However most router, proxy & firewall vendors will probably not want to save the extra state per-connection (last seq# transmitted + retransmit count) per active connection which is required to do the detection.

Nothing prevents the retransmit payload from being encrypted. However I suggest a more subtle strategy: copy the first X bytes of the original packet and then add encrypted payload. Anyone who happens to look at one of these packets will see the "garbled" message and assume it's a TCP stack bug on the transmitting host.

Answer: not enough information

OK I'll bite. African or European?

Won't work. If there is a policy mechanism to "always allow" (e.g. "don't annoy me any more for this program"), then clever software developers will figure out how to to solve the "UAC Problem" _once_ in their setup routine (by pre-setting the policy), rather than fixing their programs to run as non-admin. Then they just use and adapt the same setup.exe for all their programs.

Then everyone is back to where we started- everything runs as admin.

I suspect that the Microsoft dev team considered that before they decided to annoy the shit out of their customers. One has to assume that they are neither stupid nor contemptuous of the people who pay their bills...

There is a process to put a driver in the box with Windows, thousands of devices do so. The RAZR didn't exist when Windows XP shipped and Motorola hasn't seen fit to either identify the device over USB generically (so an in-box driver would be used) or gone through the WHQL process to put their driver on Windows Update (for example, by providing driver verifier results to Microsoft to demonstrate a minimum quality bar) so that it would be automatically downloaded and installed when you first plugged in the phone.

Microsoft provided a way for Motorola to solve this problem for customers; Motorola made the choice not to do so. It's not Microsoft's problem or fault.