A lot of people seem to think that programmer productivity has something to do with lines of code produced. That misconception gets propagated by uninformed managers, who are basically looking for something that is easy to measure.

In reality, productivity has more to do with achieving required behaviors with a minimum of code-writing. When a fresh-out writes 3000 lines of code, discards or changes 2900 of them, and ends up with a 700 line program that only sort-of works and only remotely resembles the design, after 10 weeks of working 70 hours a week, is that really productive? If an older guy thinks about the problem for two weeks, spends a day or two writing docs, writes a couple pages of code in one morning, tests it that afternoon, tweeks it a little the next morning, spends another day improving comments and updating docs, and has the whole thing finished and solid in 3 weeks, is that really less productive?

Uninformed managers reward the guy who works 80 hours a week and writes lots of bugs. The buggy code needs to be fixed, which then requires heroic amounts of overtime. They reward the overtime, without understanding why it was needed. By contrast, the guy who gets it right the first time, and doesn't need to fix it, doesn't have to work those silly hours. The uninformed managers also do not understand why a program doesn't need to be fixed, and why overtime is not really needed, and so the better programmers are not usually rewarded.

Programming is about function and behavior, not lines of code.

Just for fun, I sometimes run 'uncrustify' on a mess of old code, or change a variable name, before doing a small logic change. My nontechnical director gets a report that counts the lines in each commit.

The gay and lesbian hospital association demands nothing less than 100 percent tolerance.

The G&L association even has the solution for color blindness. Six-color stripes, like the rainbow-flag, should be more than enough colors on each item so that even color blind people can tell them apart. Just make some of the stripes wide, and some narrow, like bar-codes.

This could be intuitive, to minimize the training: A wide red-stripe means it has something to do with blood. A wide green-stripe means it has something to do with oxygen. Blue for water. Purple for suction. etc.

Lighting is often the real problem.

The old "T-10" type of fluorescent lights actually flicker at 60 hertz, because they use "magnetic" ballasts operating at the same frequency as the AC electricity supply. The 60 hertz frequency is fast enough that most humans don't notice the flickering, but slow enough to cause eye strain. The new "T-8" type of fluorescent lights flicker at a much higher rate, near 20,000 hertz, which does not cause eye strain.

Many building have far too much light, particularly buildings with the older T-10 fluorescent lights. There was a period of many years when more light was assumed to be better than less light, so many older buildings (most schools) have far too much light. Bright light causes glare, which causes eye strain and headaches.

The headaches and other effects of bad lighting, either flickering or high intensity, are exacerbated when people are looking at computer screens for extended periods. This effect is made worse by the fact that many video displays are preset to emit maximum intensity, to make them brighter so customers will notice them in the store.

For more information, see: http://www.ccohs.ca/oshanswers/ergonomics/office/eye_discomfort.html

Reduce the light to about 1 watt per square foot; replace T-10 fixtures with T-8, turn down the brightness of computers screens, and watch the headaches disappear.

In the bargain, you will save money. Replacing the old T-10 fixtures with T-8 fixtures will reduce electricity usage for lighting by about 40%, even at the same intensity. Reducing the number of fixtures in each room, to reduce the intensity, also reduces electricity usage.

There are two numbers that matter for storage systems. One is the raw number of gigabytes that can be stored. The other is the number of IO's that can be performed in a second. The first limits the size of the collected data. The second limits how many new transactions can be processed per time period. That, in turn, determines how many pennies we can accept from our customers during a busy hour.

We size our systems to hit performance targets that are set in terms of transactions per second, not just gigabytes. Using round numbers, if a disk model can do 1000 IO/second, and we need 10,000 IO/second for a particular table, then we need at least 10 disks for that table (not counting mirrors). We often use the smallest disks we can buy, because we don't need the extra gigs. If the data volume doesn't ever fill up the gigabyte capacity of the disks, that's ok. Whenever the system uses all of the available IO's-per-second, we think about adding more disks.

Occasionally a new SA doesn't understand this, sees a bunch of "empty" space in a subsystem, and configures something to use that space. When that happens, we then have to scramble, as the problem is not usually discovered until the next busy day.

I suspect you are essentially correct about the mass of the assembly, as compared to the mass of one side or component. I also thought that, perhaps, the sides might not all be of equal shape, size, or thickness. The shape may have more or fewer than six faces, or even some curves. Even if it is a polygon, it still doesn't have to be regular. Also, if one side will be toward the sun most of the time, that side might be thicker than the others. Similarly, if another side is to be oriented away from the primary radiation source most of the time, it might be thinner.

Somehow, these "popular" articles seem to leave out the interesting parts. In trying to simplify the presentation, they manage to leave out enough actual information, that the result is actually made even more confusing.

"about 200 kilograms (500 pounds), has walls that measure about a square meter (nearly 9 square feet) in area, about 1 centimeter (a third of an inch) in thickness, and 18 kilograms (40 pounds) in mass. About the size of an SUV's trunk "

I notice a few issues in this description, which also appears in the article. Some fact-checking might be in order.

How can a single thing be 200 kg, and also be 18 kg? You would think that a single thing would have only one mass.

Then, of course, a square meter is slightly more than 10 square feet.

How can a single square meter of material be made into all six sides of a box the size of a SUV trunk, without slicing it into thinner sheets. A square meter might make one side of such a box, but not all six. If all six sides of a cube total 1 square meter, each side would be about 40.8 cm square. Of course, the box doesn't have to be a cube, but the sum of the areas of the six sides still cannot exceed the total of the material.

Titanium has density of 4.5 g/cm^3. So a 100x100x1 cm piece of it would be 45 kg, not 18 kg.

Dedicated circuits do not achieve security if the circuit passes through any unsecured location. The security between two endpoints can be achieved only by security-oriented communication protocol such as encryption, or by physically securing the entire path between the endpoints. Even then, the resulting implementation must be examined constantly by multiple parties, each with a goal of finding a security defect. And then, we can only hope that each defect is found by a friendly party.

Part of the problem with infrastructure is that it is very highly distributed. We aren't just talking about big power plants and water plants. We are also talking about every electric transformer, every telco switching device, every traffic light at an intersection, every radio in a police car or fire truck, and every water main. Those things are scattered throughout the entire country. Millions of power and telco devices are mounted on utility poles. Physical security just isn't an option.

Another part of the problem is that millions of those devices are old. Many have some remote control capability, but very little in the way of processing power or software upgrade capacity. The cost (in materials and labor) to upgrade all of those devices is just astronomical. And, after replacing an individual device, there is no guarantee that the (new) device cannot be hacked in the future.

And, of course, keeping two networks separate is hard to do. When two networks have millions of nodes each, they are likely to touch somewhere. Even one device with two interfaces can potentially route between the networks. And, even one entry-level installer who gets confused or bribed, can install that one device.

So, it's just a really big problem, with lots of parts, so the solution is going to have lots of parts. Dedicated lines for some specific applications might be part of the solution. An upgrade program for the basic hardware/software units is clearly part of the solution. A sensor system to detect intrusion is clearly needed as part of the solution. A control system to shut down or disconnect the source of an intrusion after it is detected, might be part of the solution (though that might introduce another vulnerability). Firewalls to limit the scope of an intrusion, or at least to slow down the spread, is surely part of the solution. No one of these approaches can address the whole thing.

And, the whole process is going to take time. Security is a never-ending process, not a one-time project. Each time a new vulnerability is identified, a new response is needed, and each new response takes time to roll out. So, part of the solution is to set priorities -- to focus each new response on the most important resources, first.

have those commands input manually by someone you reach directly by phone.

A little social engineering, maybe:

"Hi Ben, This is Frank over at the . We have a little problem here. Actually, it's a big problem. We got a fire. Four buildings, so far. We can't put it out because the connection with is live. We need you to pull so we can get close enough to put out the fire."

I never got a root password by hacking. Every one I ever got was by asking nicely.

The traffic jams due to too many people trying to get pictures of tornados, are only temporary. Within a year or two at the most, a tornado will turn toward the caravan of cars and trucks, and a lot of people will be killed. Very quickly after that, it will become common knowledge (again) that chasing a tornado is dangerous and foolish. Then, the majority of people will quit this foolishness, and stay out of the way.

I wonder if the professionals could use airplanes, or perhaps remotely piloted drones, for some of their data collection. Is there some part of their work that must be done at ground level by a heavy vehicle?

The summary neglects to mention the number of miles for each vehicle, making it impossible to compute the right answer, even for a mathematician. The amount of fuel used can be computed as miles divided by miles-per-gallon. A 10-mpg truck that is only used for 20 miles in a month consumes only 20/10, or 2, gallons during that month. A 33-mpg car that is driven 1500 miles in a month consumes 1500/33, or about 45, gallons each month. (BTW -- I have a 10-mpg truck, which I actually *NEED* once or twice a month to carry something big or heavy. The rest of the time, I drive a car.)

This entire discussion about how best to present the concept of "fuel efficiency" so that that the average innumerate American will best understand, really misses the point. The only numbers that most Americans seem to understand are the ones that have dollar signs in front of them.

The only question to which most innumerate Americans will listen to the answer is, "How much does it cost?"

So, the only way to present this information that those Americans will understand, is using units that involve dollars.

Most people will understand "dollars-per-mile", or "dollars-per-thousand-miles".

"Who the hell can remember a new eight-digit string of nonsense every month?"

You only have to remember ONE string of nonsense, and it only has to be eight characters long?

I have to use 35 different passwords for work, for different access domains. Each of them has a different required change schedules, and different rules about what characters are required. I also have a couple for home, a couple of PINS for debit cards, and a few dozen for online accounts. Even if I don't count those others, the ones just for work are completely unmanageable without writing them down.

The time spent TYPING passwords eats up 20 minutes a day... never mind the trouble of keeping track of them all.

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.