That actually surprised me, too. Loss of precision is nothing new. When you use floats to do the arithmetic, you lose precision in each operation, and particularly when you multiply two numbers with different scales (exponents). The thing that surprised me was not that a calculation could lose precision. It was the assertion that any precision would remain, at all.
Numeric code can be written using algorithms that minimize loss of precision, or that are able to quantify the amount of precision that is lost (and that remains) in the final answers. But, if you don't use those algorithms, or don't use them correctly and carefully, you really cannot assert _any_ precision in the result.
If you know your confidence interval, you can state your result with confidence. But, if you don't bother to calculate the confidence interval, or if you don't know what a CI is, or if you are not careful, it usually ends up being plus-or-minus 100 percent of the scale.
This morning, I drove about 20 miles in extremely dense traffic. "Bumper to bumper", and about 15 miles below speed limit. I could see the lead vehicles at every curve in the road. They were side by side, matching speeds. In front of them, there were no cars (none!) on the road, as far as the eye could see.
"Drafting" might help fuel economy, but the only way it could reduce congestion or travel times would be if we can also get some of the idiots off of the road.
In about 1984-1987, I worked on device drivers for PDP-11 hosts (not DEC OS's, though), including drivers for ethernet devices. They did DMA at that time, and had a queue of transmit and receive buffers. There were vendor-provided drivers available for RSX and RT-11 operating systems at that time, also. So the invention of ethernet interface that does DMA with multiple-buffering was clearly not new in 1992. Even at that time, various devices provided host-visible buffers, so that element is not new, either.
The important thing in any patent case is the "claims". If the defendant in the suit can present prior art that has all of the elements of a claim, the court will invalidate that claim. And, if the thing that the defendant made does not include some element of a claim, then it does not infringe that claim.
I have not seen the actual claims of the patent cited in this case, or any details about the allegations of infringement. There must be more to this than just doing DMA with multiple buffers.
There are two conceptual problems here: One is storing all of that data in a single server, which could possibly fail and destroy all of the data; The second is storing all of that data under the management control of a single MBA, who could possibly make a very dumb decision and destroy all of the data.
It appears that the second of those actually occurred.
In previous decades, for the most part, the company that operated the computing center considered the data to be valuable, and took great care to prevent data loss. They knew that the hardware could fail, and so they made multiple copies of each data file. They did backups, and they checked and tested the backups. Most even stored some copies off-site to hedge against the possibility of catastrophic loss of the entire data center.
At present time, many young people have never seen data loss. Many people do not realize that hardware failure is even possible. If they make backups, they rarely check or test the fidelity or reliability of those backups. Those same people are administering the data center operations. Managing the disk farm, replacing failed mirrors, and making backups of customers data, are all activities that are part of the service. As far as many of the MBA types are concerned, all of those are just costs to be minimized.
A single disk might have a MTBF of 30 years. But a system that uses ten thousand disks will have a MTBF of about a day. (On average, a disk will fail somewhere in the system, every day.) RAID systems do not eliminate the issue, because simultaneous disk failure is possible. And a power-supply failure, fire, explosion, software failure, or employee can kill a whole bunch of disks all at once.
In my own organization, I want to know where my data is. I want mirrored disks to minimize the operational effects of common hardware failure, and off-line/off-site backups so we can stay in business after an uncommon failure. I want to review the backup schedule. I want regular verification of backup status. I want periodic audits of the backups, to be sure they really exist and that they can really be read. And, when the data is vital to the continuance of my business, that verification and auditing must not be outsourced.
Whenever your MBAs want to cut the cost of doing backups, you really should check with the underwriter of your business-continuation insurance.
Yes. TCP was/is designed to detect and correct data transmission errors. The information coding is highly redundant, and the error correction and detection is implemented in each of several layers. (See, http://www.faqs.org/rfcs/rfc793.html ). The probability of an undetected error is very small. The datalink layer in most networks typically provide an undetected error rate in the neighborhood of 2^-32. Then the upper layer tcp does another layer of error coding, providing a combined error rate of something like 2^-64. That is fine for most practical purposes.
You can improve on the available error detection if you want, by computing a checksum of the file, transmitting both the file and the checksum, and then recomputing and comparing the checksum on the receiving end. Various algorithms are available for such a purpose. Two good hash algorithms that comes to mind are MD5 and SHA-1. (See, http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions ).
...all my friends have gmail accounts. It's not easily accessible to the government (assuming google's internal traffic is not tapped)
Don't be ridiculous. Every single gmail account is fully accessible to NSA, and to any other part of the government that wants it. So is every other kind of user account provided by every ISP and every web site. All they need is a warrant, or an NSL, or just to ask nicely and pay the cost.
Reading other peoples email is not any great technical feat. It is actually very easy for the administrators of any ISP to see just about anything in their own system. And, it is just as easy for just about any kind of law enforcement to get the same level of access.
There are two things that keep most administrators from peeking: they just don't have time to waste on that nonsense; and most companies have an ethics policy that says not to peek without an actual business reason. In reality, administrators that do spend time peeking at users files end up not getting their own work done, and then get fired.
Ask a computer programmer to "rig" an election, to make it come out with exactly a six-percent margin, in a closed-source proprietary system. And then ask a person to "rig" an election the same way, except that the person has to count the votes in front of dozens of witnesses, and show each ballot to each witness. If you had to stake your freedom on catching the election rigging, which one do you think would be more likely to get caught?
It isn't the accuracy of "counting" that matters. It is the ease of "rigging".
If anyone says Emacs or Vi they are insane and have never done 10k lines of code in a modern environment.
I don't recall the last time I worked on anything that was only 10K LOC. The system I work on most of the time is millions of lines. Most of the individual directories have at least 10K LOC in them, and most have much (much!) more than that. There are hundreds of header files, and hundreds of library files. We use imake to generate the makefiles. Even the makefile's are huge -- There are hundreds of them, and most of them have thousands of lines of make-language code.
Periodically, someone tries to load this system into an IDE. It doesn't fit. They spend a few months trying, and eventually give up. One part of the problem is that a significant fraction of the code is actually written in application-specific languages. The compilers for those languages are built as part of the system. Another part is that just maintaining the list of required libraries in the 'project' file of an IDE is labor intensive, and must be done for each executable. Using imake to generate the makefiles allows us to automate most of that drudgery.
But xemacs has no difficulty, at all. We have an xemacs mode adapted for each specialized language. Some of the developers prefer vi, of course. They both work.
Just for the record, I have done a few 10K LOC programs in a "modern" IDE. I then had to re-do all of the 'project' stuff to move that code to a new IDE, just this year. I enjoy working with a nice GUI IDE on small projects at home. I suppose if you are working on a commercial system that only has a handful of executables, and only KLOCs for each, those same IDE tools might be useful. But seriously big systems require serious, portable, and maintainable tools.
Nonsense. You get about 90% of your efficiency on the day you choose your algorithm and data structure. Choose those well, then code them clearly and correctly, and you will rarely need to use a profile tool. The profile tools can be useful for finding the slow parts of the program, of course, after it is written. It usually turns out the the slow parts are those that were written by the fresh-out who didn't pay attention in the "algorithms and data structures" course.
You are right that "peephole" optimizations are best ignored until late in the process. But, if you choose your algorithms well, you shouldn't ever need to do that sort of "optimization". A straightforward quick-sort, with no "optimizations" at all, is faster than the most highly "optimized" bubble sort on all but the smallest data sets.
The beauty of libraries is that the library classes implement most of the good "standard" algorithms. I haven't needed to code a sorting algorithm for at least ten years. Any more, I only need to decide when to use one, versus using a map (hash or tree) class or a database table. Unfortunately, the fresh-outs who didn't pay attention in class still manage to make bad choices, and they still manage write code that is both slow and incorrect.
I have fitted my whole house using ULA brand CFL lights. The box says >90% power factor. I have measured the power factor of several of these bulbs, and they have actually measured between 92% and 94%.
And, they are dimmable. (Ok -- they don't dim as much as incandescent lights, and some of them want to flicker. But dimming doesn't destroy them immediately.)
In the bargain, they are cheap. (At least, they are cheap in California, and on ebay from CA sellers, until the PGE subsidy runs out.)
So, you have to pay attention to power factor when you buy anything that is not incandescent. But if you pay attention, you can still get a good deal.
Many critical systems normally are accessible from the internet. They often are not isolated by much more than a vpn router.
The reasons for this are obvious. Most of the accessibility is due to a genuine desire to allow the engineers who can fix it to be able to access it when it breaks. When the system crashes, and the one engineer who can fix it is a thousand miles away, the manager wants that engineer to have a laptop and the ability to get into the system to fix it.
They try to do this in a reasonable way -- using VPN security, strong encrption, etc. But reasonable security one year is laughable security two or three years later.
The real, operational question is: When your power goes out while the power companies chief systems engineer is on vacation a thousand miles away, do you want them to restore it in a couple hours, or do you want to wait till a week from Monday?
Yes. The printer and scanner both work just fine with the mac systems. It is configured as a network printer, and is shared among all the machines in the house. The "scan-to" feature on the 2840 allows the user to select the target machine from the front panel, to send the scan to that machine.
No. I'm comparing eight (8) macs with ten (10) windows systems. The current inventory is four (4) macs and four (4) windows systems. Of course, they are not all heavily used. Older boxes are retained as long as they are potentially useful.
And, No. I did not present any statistics. I presented an anecdote, which is entirely different from a statistic.
There are other factors, as well... Support and Configuration.
In the last two weeks, I have spent multiple days and nights trying to get my partners new HP notebook to talk to an HP LaserJet 2840 all-in-one machine. The HP software for the HP host to communicate with the HP scanner just does not work. Some similar hardware or network or software compatibility issue soaks up a whole week every few months.
By comparison, my current Apple MacBook Pro has had zero difficulty. Zero. Nada. Each new thing just works.
Of course, I've only been using PCs and Macs for about 25 years. This is my eighth mac, I think, and about the tenth pc in the house. Every mac has had zero issues. Every PC has had multiple issues, and required a lot of work to get it to work.
If I multiply my hourly rate by the time spent getting those machines to work, the PC machines have been hugely more expensive than the Macs.
One of my favorite assignments to give is: "Find an error in the textbook." It gets the students to actually read the book closely. (Of course, I need to be sure that there is at least one error in the book before giving that assignment. That usually isn't too difficult. Most undergraduate texts have numerous small errors.)
I live in Fort Lauderdale. The stoplight at the exit from my neighborhood has been adjusted, just a couple weeks ago. They recently installed cameras on this intersection. The new cycle appears to be: 1 second of green, 1 second of yellow, 28 seconds of red. The main street is getting 27 seconds of green, and 1 second of yellow, and 2 seconds of red. There appears to be no overlap of the red.
The state law says the yellow must be 4 seconds, if I recall correctly. But even if the camera-tickets can be successfully challenged in court, and even if a judge eventually orders the city to change the timing, it is still tying up the traffic. And, there have been more collisions at that intersection in the last two weeks than there were in the previous 20 years.
Economic decisions need to be based on numbers, not anecdotes.
If the cooling would cost X $/day, and the equipment failures due to not cooling would cost Y $/day, then if Y > X, you cool, and if X > Y, you don't. Both costs are statistical (expected values), of course, but with large enough sample sizes you can estimate them pretty closely. This same decision process can be applied to each degree of cooling, if you can estimate both costs for each temperature.
In our data center, the cost of a typical single processor failure (for the hardware, labor, lost productivity, etc.) greatly exceeds the cost of cooling the whole place for a day. We have a few thousand processors. In the past, on days when the old cooling system failed, we usually suffered multiple processor failures. We now have redundant cooling systems, either of which has enough capacity to cool the whole place.
By far, a much larger cost savings can be had by just selecting equipment that uses less electricity and produce less heat in the first place. You save money by not creating the heat in the first place, and then save even more by not having to remove so much heat from the building.
The courts have held, many times, that the right to speak means nothing if other people do not have a right to listen. And, that the right to publish means nothing if other people do not have a right to read. Censorship of reading, by which a person is forbidden to read a certain type of material, is not different from censorship of publishing.
s there any reason this card needs RFID as opposed to a standard credit-card style chip which requires physical contact?
Yes, of course there is a real reason. It's the same reason as in many other government procurements: The company that makes the chips wants to sell a hundred million of them to the government for $100 each. The government bureaucrat who made the decision also owns the company, and wants to transfer the $10,000,000,000 to that company. That's a real reason, indeed.
The current wind power production capacity was mostly built using government grants. The federal government directly paid for about 40% of the cost, and the power companies got states to fund grants and approve utility surcharges for the rest. Essentially all of the money came from government, or was extracted from individuals using government authority. Without those grants and taxes for renewable energy, there would be extremely little wind power in the US.
If there is no browser on a host when it comes out of the box, how does a user visit the download site to get a browser?
One possible answer is to use ftp, of course. I understand how to do that, since I use ftp for other things every week. But I dread having to explain it to an average nontechnical user. Typing ftp commands is a lot like using a shell prompt. There is a conceptual hurdle the average user just cannot or will not get past.
Alternatively, some enterprising person could put a browser installer on a CD and put it in a pretty box. A hard-copy manual could give the box some heft, and give the average user the warm fuzzy feeling that she got something for her $29.
Anyone who has a house, with air conditioning, in a hot climate. Lack of insulation makes it worse. A swimming pool pump and electric hot-water-heater take a lot of power, too. The computers and other electronics are usually only a very small faction of the total.
Where I live, in Florida, $400/month is not at all unusual. The hot, humid climate makes air conditioning mandatory; almost every house has a swimming pool; and older homes are often completely uninsulated.
Also, how will they discern between travel on public roads, versus travel on private roads?
That's the excuse for the tracking system. If they don't know where each mile is driven, they have to charge the same amount per mile. To give a discount for miles driven private roads, they would have to know which roads you drove those miles on.
Don't be silly. The frequency of regenerations is limited from below by the time that the current Doctor both gets audience share, and is willing to work without a raise. The number of regenerations is limited from above by the willingness of television audience to watch the commercials that accompany the show, and the resulting willingness of advertisers to pay for it. Inside the logic of the show, of course, they may have to come up with an explanation, but that is a task for the writers.
Slashdot Mirror
That actually surprised me, too. Loss of precision is nothing new. When you use floats to do the arithmetic, you lose precision in each operation, and particularly when you multiply two numbers with different scales (exponents). The thing that surprised me was not that a calculation could lose precision. It was the assertion that any precision would remain, at all.
Numeric code can be written using algorithms that minimize loss of precision, or that are able to quantify the amount of precision that is lost (and that remains) in the final answers. But, if you don't use those algorithms, or don't use them correctly and carefully, you really cannot assert _any_ precision in the result.
If you know your confidence interval, you can state your result with confidence. But, if you don't bother to calculate the confidence interval, or if you don't know what a CI is, or if you are not careful, it usually ends up being plus-or-minus 100 percent of the scale.
This morning, I drove about 20 miles in extremely dense traffic. "Bumper to bumper", and about 15 miles below speed limit. I could see the lead vehicles at every curve in the road. They were side by side, matching speeds. In front of them, there were no cars (none!) on the road, as far as the eye could see.
"Drafting" might help fuel economy, but the only way it could reduce congestion or travel times would be if we can also get some of the idiots off of the road.
In about 1984-1987, I worked on device drivers for PDP-11 hosts (not DEC OS's, though), including drivers for ethernet devices. They did DMA at that time, and had a queue of transmit and receive buffers. There were vendor-provided drivers available for RSX and RT-11 operating systems at that time, also. So the invention of ethernet interface that does DMA with multiple-buffering was clearly not new in 1992. Even at that time, various devices provided host-visible buffers, so that element is not new, either.
The important thing in any patent case is the "claims". If the defendant in the suit can present prior art that has all of the elements of a claim, the court will invalidate that claim. And, if the thing that the defendant made does not include some element of a claim, then it does not infringe that claim.
I have not seen the actual claims of the patent cited in this case, or any details about the allegations of infringement. There must be more to this than just doing DMA with multiple buffers.
There are two conceptual problems here:
One is storing all of that data in a single server, which could possibly fail and destroy all of the data;
The second is storing all of that data under the management control of a single MBA, who could possibly make a very dumb decision and destroy all of the data.
It appears that the second of those actually occurred.
There is one difference.
In previous decades, for the most part, the company that operated the computing center considered the data to be valuable, and took great care to prevent data loss. They knew that the hardware could fail, and so they made multiple copies of each data file. They did backups, and they checked and tested the backups. Most even stored some copies off-site to hedge against the possibility of catastrophic loss of the entire data center.
At present time, many young people have never seen data loss. Many people do not realize that hardware failure is even possible. If they make backups, they rarely check or test the fidelity or reliability of those backups. Those same people are administering the data center operations. Managing the disk farm, replacing failed mirrors, and making backups of customers data, are all activities that are part of the service. As far as many of the MBA types are concerned, all of those are just costs to be minimized.
A single disk might have a MTBF of 30 years. But a system that uses ten thousand disks will have a MTBF of about a day. (On average, a disk will fail somewhere in the system, every day.) RAID systems do not eliminate the issue, because simultaneous disk failure is possible. And a power-supply failure, fire, explosion, software failure, or employee can kill a whole bunch of disks all at once.
In my own organization, I want to know where my data is. I want mirrored disks to minimize the operational effects of common hardware failure, and off-line/off-site backups so we can stay in business after an uncommon failure. I want to review the backup schedule. I want regular verification of backup status. I want periodic audits of the backups, to be sure they really exist and that they can really be read. And, when the data is vital to the continuance of my business, that verification and auditing must not be outsourced.
Whenever your MBAs want to cut the cost of doing backups, you really should check with the underwriter of your business-continuation insurance.
Yes. TCP was/is designed to detect and correct data transmission errors. The information coding is highly redundant, and the error correction and detection is implemented in each of several layers. (See, http://www.faqs.org/rfcs/rfc793.html ). The probability of an undetected error is very small. The datalink layer in most networks typically provide an undetected error rate in the neighborhood of 2^-32. Then the upper layer tcp does another layer of error coding, providing a combined error rate of something like 2^-64. That is fine for most practical purposes.
You can improve on the available error detection if you want, by computing a checksum of the file, transmitting both the file and the checksum, and then recomputing and comparing the checksum on the receiving end. Various algorithms are available for such a purpose. Two good hash algorithms that comes to mind are MD5 and SHA-1. (See, http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions ).
...all my friends have gmail accounts. It's not easily accessible to the government (assuming google's internal traffic is not tapped)
Don't be ridiculous. Every single gmail account is fully accessible to NSA, and to any other part of the government that wants it. So is every other kind of user account provided by every ISP and every web site. All they need is a warrant, or an NSL, or just to ask nicely and pay the cost.
Reading other peoples email is not any great technical feat. It is actually very easy for the administrators of any ISP to see just about anything in their own system. And, it is just as easy for just about any kind of law enforcement to get the same level of access.
There are two things that keep most administrators from peeking: they just don't have time to waste on that nonsense; and most companies have an ethics policy that says not to peek without an actual business reason. In reality, administrators that do spend time peeking at users files end up not getting their own work done, and then get fired.
Ask a computer programmer to "rig" an election, to make it come out with exactly a six-percent margin, in a closed-source proprietary system. And then ask a person to "rig" an election the same way, except that the person has to count the votes in front of dozens of witnesses, and show each ballot to each witness. If you had to stake your freedom on catching the election rigging, which one do you think would be more likely to get caught?
It isn't the accuracy of "counting" that matters. It is the ease of "rigging".
I don't recall the last time I worked on anything that was only 10K LOC. The system I work on most of the time is millions of lines. Most of the individual directories have at least 10K LOC in them, and most have much (much!) more than that. There are hundreds of header files, and hundreds of library files. We use imake to generate the makefiles. Even the makefile's are huge -- There are hundreds of them, and most of them have thousands of lines of make-language code.
Periodically, someone tries to load this system into an IDE. It doesn't fit. They spend a few months trying, and eventually give up. One part of the problem is that a significant fraction of the code is actually written in application-specific languages. The compilers for those languages are built as part of the system. Another part is that just maintaining the list of required libraries in the 'project' file of an IDE is labor intensive, and must be done for each executable. Using imake to generate the makefiles allows us to automate most of that drudgery.
But xemacs has no difficulty, at all. We have an xemacs mode adapted for each specialized language. Some of the developers prefer vi, of course. They both work.
Just for the record, I have done a few 10K LOC programs in a "modern" IDE. I then had to re-do all of the 'project' stuff to move that code to a new IDE, just this year. I enjoy working with a nice GUI IDE on small projects at home. I suppose if you are working on a commercial system that only has a handful of executables, and only KLOCs for each, those same IDE tools might be useful. But seriously big systems require serious, portable, and maintainable tools.
Nonsense. You get about 90% of your efficiency on the day you choose your algorithm and data structure. Choose those well, then code them clearly and correctly, and you will rarely need to use a profile tool. The profile tools can be useful for finding the slow parts of the program, of course, after it is written. It usually turns out the the slow parts are those that were written by the fresh-out who didn't pay attention in the "algorithms and data structures" course.
You are right that "peephole" optimizations are best ignored until late in the process. But, if you choose your algorithms well, you shouldn't ever need to do that sort of "optimization". A straightforward quick-sort, with no "optimizations" at all, is faster than the most highly "optimized" bubble sort on all but the smallest data sets.
The beauty of libraries is that the library classes implement most of the good "standard" algorithms. I haven't needed to code a sorting algorithm for at least ten years. Any more, I only need to decide when to use one, versus using a map (hash or tree) class or a database table. Unfortunately, the fresh-outs who didn't pay attention in class still manage to make bad choices, and they still manage write code that is both slow and incorrect.
I have fitted my whole house using ULA brand CFL lights. The box says >90% power factor. I have measured the power factor of several of these bulbs, and they have actually measured between 92% and 94%.
And, they are dimmable. (Ok -- they don't dim as much as incandescent lights, and some of them want to flicker. But dimming doesn't destroy them immediately.)
In the bargain, they are cheap. (At least, they are cheap in California, and on ebay from CA sellers, until the PGE subsidy runs out.)
So, you have to pay attention to power factor when you buy anything that is not incandescent. But if you pay attention, you can still get a good deal.
Many critical systems normally are accessible from the internet. They often are not isolated by much more than a vpn router.
The reasons for this are obvious. Most of the accessibility is due to a genuine desire to allow the engineers who can fix it to be able to access it when it breaks. When the system crashes, and the one engineer who can fix it is a thousand miles away, the manager wants that engineer to have a laptop and the ability to get into the system to fix it.
They try to do this in a reasonable way -- using VPN security, strong encrption, etc. But reasonable security one year is laughable security two or three years later.
The real, operational question is: When your power goes out while the power companies chief systems engineer is on vacation a thousand miles away, do you want them to restore it in a couple hours, or do you want to wait till a week from Monday?
Yes. The printer and scanner both work just fine with the mac systems. It is configured as a network printer, and is shared among all the machines in the house. The "scan-to" feature on the 2840 allows the user to select the target machine from the front panel, to send the scan to that machine.
No. I'm comparing eight (8) macs with ten (10) windows systems. The current inventory is four (4) macs and four (4) windows systems. Of course, they are not all heavily used. Older boxes are retained as long as they are potentially useful.
And, No. I did not present any statistics. I presented an anecdote, which is entirely different from a statistic.
There are other factors, as well... Support and Configuration.
In the last two weeks, I have spent multiple days and nights trying to get my partners new HP notebook to talk to an HP LaserJet 2840 all-in-one machine. The HP software for the HP host to communicate with the HP scanner just does not work. Some similar hardware or network or software compatibility issue soaks up a whole week every few months.
By comparison, my current Apple MacBook Pro has had zero difficulty. Zero. Nada. Each new thing just works.
Of course, I've only been using PCs and Macs for about 25 years. This is my eighth mac, I think, and about the tenth pc in the house. Every mac has had zero issues. Every PC has had multiple issues, and required a lot of work to get it to work.
If I multiply my hourly rate by the time spent getting those machines to work, the PC machines have been hugely more expensive than the Macs.
One of my favorite assignments to give is: "Find an error in the textbook." It gets the students to actually read the book closely. (Of course, I need to be sure that there is at least one error in the book before giving that assignment. That usually isn't too difficult. Most undergraduate texts have numerous small errors.)
I live in Fort Lauderdale. The stoplight at the exit from my neighborhood has been adjusted, just a couple weeks ago. They recently installed cameras on this intersection. The new cycle appears to be: 1 second of green, 1 second of yellow, 28 seconds of red. The main street is getting 27 seconds of green, and 1 second of yellow, and 2 seconds of red. There appears to be no overlap of the red.
The state law says the yellow must be 4 seconds, if I recall correctly. But even if the camera-tickets can be successfully challenged in court, and even if a judge eventually orders the city to change the timing, it is still tying up the traffic. And, there have been more collisions at that intersection in the last two weeks than there were in the previous 20 years.
Economic decisions need to be based on numbers, not anecdotes.
If the cooling would cost X $/day, and the equipment failures due to not cooling would cost Y $/day, then if Y > X, you cool, and if X > Y, you don't. Both costs are statistical (expected values), of course, but with large enough sample sizes you can estimate them pretty closely. This same decision process can be applied to each degree of cooling, if you can estimate both costs for each temperature.
In our data center, the cost of a typical single processor failure (for the hardware, labor, lost productivity, etc.) greatly exceeds the cost of cooling the whole place for a day. We have a few thousand processors. In the past, on days when the old cooling system failed, we usually suffered multiple processor failures. We now have redundant cooling systems, either of which has enough capacity to cool the whole place.
By far, a much larger cost savings can be had by just selecting equipment that uses less electricity and produce less heat in the first place. You save money by not creating the heat in the first place, and then save even more by not having to remove so much heat from the building.
The courts have held, many times, that the right to speak means nothing if other people do not have a right to listen. And, that the right to publish means nothing if other people do not have a right to read. Censorship of reading, by which a person is forbidden to read a certain type of material, is not different from censorship of publishing.
s there any reason this card needs RFID as opposed to a standard credit-card style chip which requires physical contact?
Yes, of course there is a real reason. It's the same reason as in many other government procurements:
The company that makes the chips wants to sell a hundred million of them to the government for $100 each. The government bureaucrat who made the decision also owns the company, and wants to transfer the $10,000,000,000 to that company. That's a real reason, indeed.
The current wind power production capacity was mostly built using government grants. The federal government directly paid for about 40% of the cost, and the power companies got states to fund grants and approve utility surcharges for the rest. Essentially all of the money came from government, or was extracted from individuals using government authority. Without those grants and taxes for renewable energy, there would be extremely little wind power in the US.
If there is no browser on a host when it comes out of the box, how does a user visit the download site to get a browser?
One possible answer is to use ftp, of course. I understand how to do that, since I use ftp for other things every week. But I dread having to explain it to an average nontechnical user. Typing ftp commands is a lot like using a shell prompt. There is a conceptual hurdle the average user just cannot or will not get past.
Alternatively, some enterprising person could put a browser installer on a CD and put it in a pretty box. A hard-copy manual could give the box some heft, and give the average user the warm fuzzy feeling that she got something for her $29.
Who the hell uses that much electric power?
Anyone who has a house, with air conditioning, in a hot climate. Lack of insulation makes it worse. A swimming pool pump and electric hot-water-heater take a lot of power, too. The computers and other electronics are usually only a very small faction of the total.
Where I live, in Florida, $400/month is not at all unusual. The hot, humid climate makes air conditioning mandatory; almost every house has a swimming pool; and older homes are often completely uninsulated.
Also, how will they discern between travel on public roads, versus travel on private roads?
That's the excuse for the tracking system. If they don't know where each mile is driven, they have to charge the same amount per mile. To give a discount for miles driven private roads, they would have to know which roads you drove those miles on.
Don't be silly. The frequency of regenerations is limited from below by the time that the current Doctor both gets audience share, and is willing to work without a raise. The number of regenerations is limited from above by the willingness of television audience to watch the commercials that accompany the show, and the resulting willingness of advertisers to pay for it. Inside the logic of the show, of course, they may have to come up with an explanation, but that is a task for the writers.