Slashdot Mirror

A couple weeks ago, you asked questions of Stanford professor Jonathan Koomey about what has been dubbed Koomey's Law — the idea that the energy efficiency of computing doubles every 1.5 years. Read on for Professor Koomey's answers to the questions you raised. What makes this a non-trivial extension?
by Anonymous

What makes your law a non-trivial extension of Moore's Law, which states that the transistor count would double every 18 months due to an increase in density? E&M theory states that if you cut a wire's length in half, it's resistance cuts in half. Granted density in this case is a 2 dimensional expansion and wire resistance is a 1 dimensional formula, but what makes this different from what a freshman in college can infer from an R = (resistivity * length)/cross sectional area?

Jonathan Koomey: First, it’s important to note that we assessed these trends empirically, using measured power data for each computer system in our dataset, and it’s often valuable to confirm with actual measurements what theory implies. Just because the result sounds intuitive to you after the fact doesn’t mean that it isn’t valuable to confirm with real data that the trends actually exist. And of course we discuss in the paper the driving forces behind the reductions in power use per logical switch (and they involve more than just reductions in I squared R losses in the wires). I’ve pasted below two relevant paragraphs from the article:

For vacuum tube computers, both computational speed and reliability issues encouraged computer designers to reduce power use. Heat reduces reliability, which was a major issue for tube-based computers. In addition, increasing computation speeds went hand in hand with technological changes (like reduced capacitive loading, lower currents, and smaller tubes) that also reduced power use. And the economics of operating a tube-based computer led to pressure to reduce power use, although this issue was probably a secondary one in the early days of electronic computing.

For transistorized and microprocessor based computers, the driving factor for power reductions was (and is) the push to reduce the physical dimensions of transistors, which reduces the cost per transistor. In order to accomplish this goal, power used per transistor also must be reduced; otherwise the power densities on the silicon rapidly become unmanageable. Per transistor power use is directly proportional to the length of the transistor between source and drain, the ratio of transistor length to mean free path of the electrons, and the total number of electrons in the operating transistor, as Feynman (2001) pointed out. Shrinking transistor size therefore resulted in improved speed, reduced cost, and reduced power use per transistor (see also Bohr (2007) and Carver Mead’s thinking in the late 1960s, as summarized in Brock (2006, pp. 98-100)).

In addition, the fact that the trends have now been confirmed empirically means that people can get on with considering the implications of these trends, which I think are under-appreciated. The idea that we’ll be able to use ever more efficient computing technology in distributed applications will revolutionize data collection, communications, and control of processes, and people are only now starting to think about what may become possible.

As one of many examples showing the potential of ultra low power computing, consider the wireless no-battery sensors created by Joshua R. Smith of Intel and the University of Washington (coverage in the NY Times and the Economist). These sensors scavenge energy from stray television and radio signals, and they use so little power (60 microwatts in this example) that they don’t need any other power source. Stray light, motion, or heat can also be converted to meet slightly higher power needs, perhaps measured in milliwatts. The contours of this exciting design space are only beginning to be explored, and they are enabled by the trends identified in our paper.

I wouldn’t underestimate the importance of a shift in industry focus from raw performance to power efficiency for mobile devices. Some of the best engineers will be drawn to the problems of ultra low power computing in the same way as they’ve were drawn to high performance computing (HPC) in the past (no doubt terrific technologists will also continue to focus on HPC, but anytime a new hot area opens up there’s a migration of talent to that new topic).

Finally, I would add that the truly unexpected result was that the trend in computational efficiency extends for a longer period than Moore’s law, all the way back to Eniac in 1946. So these trends in computational efficiency are an inherent characteristic of computers that use electrons for switching, and are not limited to the microprocessor era. I, for one, did not expect that.

Your Take on Futurists?
by eldavojohn

What is your take on the interpretation of Futurists -- like Raymond Kurzweil -- in regards to extrapolating these 'laws' out to extreme distances?

JK: The physicist Neils Bohr once famously said “Prediction is very difficult, especially about the future.” It’s important to be careful in making long-term extrapolations, even if some technological trend has continued for some time. I think it’s fair to say that Moore’s law (and the trends in computational efficiency we identify) have more years to run, given how far we are from theoretical limits, but exactly when we’ll hit a real roadblock it will take someone more brash than me to say. I discuss the theoretical limit based on Feynman’s calculations below, and we will eventually reach that, but there may be ways to sidestep those limits. We’ll have to see how clever we can be!

Lets work this backwards ...
by PPH

... and see where the Babbage Engine fits on the curve.

JK: Since the Babbage engine never operated, I’m not sure how we could do this. I believe that some parts of the engine have been created using modern machining practices, but I don’t think anyone has ever made one in complete form. If someone has, I’d be interested to measure its electricity use and estimate its performance (of course, it was designed before the era of electricity). Nordhaus (2007) reports that

Early calculators were “dumb” machines that essentially relied on incrementation of digits. An important step in the development of modern computers was mechanical representation of logical steps. The first commercially practical information-processing machine was the Jacquard loom, developed in 1804. This machine used interchangeable punched cards that controlled the weaving and allowed a large variety of patterns to be produced automatically. This invention was part of the inspiration of Charles Babbage, who developed one of the great precursor inventions in computation. He designed two major conceptual breakthroughs, the “Difference Engine” and the “Analytical Engine.” The latter sketched the first programmable digital computer. Neither of the Babbage machines was constructed during his lifetime. An attempt in the 1990s by the British Museum to build the simpler Difference Engine using early-nineteenth-century technologies failed to perform its designed tasks. (reference: Swade, Doron. The Difference Engine. New York: Viking Press, 2000.)

Nordhaus, William D. 2007. "Two Centuries of Productivity Growth in Computing." The Journal of Economic History. vol. 67, no. 1. March. pp. 128-159. [http://nordhaus.econ.yale.edu/recent_stuff.html]

Nordhaus does attempt to estimate the speed of computation possible by hand calculations as well as abacuses, to compare to more automatic methods.

Infinity w/ reversible computing?
by DriedClexler

This one doesn't seem to have fundamental physical limits, so long as we eventually transition to reversible computing, in which the computer does not use up useful energy because every process it uses is fully reversible (i.e. the original state could be inferred).

All the limits on computation (except regarding storage) that you hear about (e.g. Landauer limit) are on irreversible computing, which is how current architecture works. It is the irreversibility of an operation that causes it to increase entropy.

Could the whole process be bypassed by the near-infinite efficiency of reversible computers?

JK:Here’s the flip answer: Only if you can afford to wait infinitely long for your answer.

Here’s the more serious answer: in principle, reversible computing could have a revolutionary impact, if we could figure out how to do it, and some folks are working on this. But I haven’t seen any near term applications of such devices—if you know of any, please let me know.

Multicore or System on a Chip Speed bumps?
by eldavojohn

A lot of consumer grade machines have begun focusing on multicore chips with a lower frequency to provide the same or better perceived computing performance than a high frequency single core chip. What happens when a technology like this subverts our craving for higher transistor density? Can you argue that your "law" is immune to researchers focusing on some hot new technology like a thousand core processor or a beefed up system on a chip in order to improve end user experience over pure algorithm crunching speed?

JK: First, I would call it (like Moore implied in his own papers) an empirical observation rather than a law.

But in any case, I don’t think that the transition to multicore has “subverted our craving for higher transistor density,” we’re just using the transistors in a different way. The density of chips (measured in components per square centimeter or equivalent metric) will continue to increase, it’s just that the scaling of clock speeds that drove performance increases for so long is no longer possible (mainly because of high leakage currents inside the chip). So that means we need to make many cores and then modify software to capture that performance.

At the end of the day, WHAT you choose to do with the computing power is unrelated to the trends we identify, but I would argue the focus of device and software design is inevitably moving towards enhancing the end-user experience because these trends in efficiency are allowing ever more mobile devices to serve people’s immediate needs in an ever more personal way.

How will this affect programmers?
by Anonymous

When we eventually hit the physical limits of atoms, will programmers eventually stop their autistic quest for more and more layers, more and more complexity and more and more languages to move a number from one address to another?

How will programmers affect this?
by skids

While sarcastic, the above question is an important one: as computing power has increased, the tendency of coders to just ride over badly coded underlayers rather than redesign them competently and efficiently has increased. Why bother cutting out bloat that causes an 80% penalty on system efficiency when you can just use a more efficient chipset to get the same result?

So my question is whether you have put any thought into similarly quantifying the opposing software bloat factor, and what he sees the total balance of system works out to.

JK: Software bloat is a real issue, and I agree with your analysis that the ever-improving hardware picture has allowed poor coding practices to continue. But with the shift to multicore, there’s been at least some burden on programmers to change their ways—they have to modify their code to take advantage of multicore performance, so their skills are actually needed to capture increased performance (which is new, or at least a throwback to the early days of computing, when the programmers had so few hardware resources to work with that they had to be extremely parsimonious in their coding).

In the paper, we write:

Whether performance per CPU can grow for many years more at the historical pace is an ongoing subject of debate in the computer industry (Bohr 2007), but near-term improvements are already “in the pipeline”. Continuing the historical trends in performance (or surpassing them) is at this juncture dependent on significant new innovation comparable in scale to the shift from single core to multi-core computing. Such innovation will also require substantial changes in software design (Asanovíc et al. 2006), which is a relatively new development for the IT industry and it is another reason why whole system redesign is so critical to success.

This really doesn’t address the serious issue you raise about bloatware, which I think is a generic problem that other people more skilled in software design than me can address much better than I can. It’s hard to quantify it because it is so situation specific, but someone at a university somewhere may have tried to do this—I just don’t know.

Applied to Other Kinds of Computing?
by Anonymous

How well does Koomey's Law fit other kinds of computing? For instance, has the energy efficiency of cell phone microprocessors followed the same trend as desktop computers and servers? What about embedded systems like routers and car engine controllers, or specialized hardware like game consoles?

JK: These are all excellent questions (which we raise in the article) and I’m actively seeking data, but I don’t have anything new to report on this yet. I’m also interested in trends in data transmission power efficiencies, because that’s a key limitation on these mobile devices. And I’m digging around for battery capacity data over time as well.

Moral/Ethical
by vlm

Here is the list of moral / ethical arguments about the path we're on, as seen in your law. You saw the path clearly enough to define a time based law. Are there any issues I'm not seeing on our current path?

1) Lower energy consumption at point of use
2) Higher energy consumption at manufacturing point
3) faster cpu = bigger programs = more bugs = lower quality of life
4) faster cpu = stronger DRM possibilities
5) Better processing * battery life = better medical devices
6) Better processing * battery life = better 1984 style totalitarian devices
7) Lower energy consumption = less air conditioning demand = decreasing average latitude of data centers = population shifts or whatever or something?
8) More money required for both hw and sw development = good for big corps and bad for the little guy

JK: Hmmm, I’m not quite sure where you are going with this. There are pluses and minuses to all technological innovations, but I’m pretty sure the benefits will outweigh the costs in this case (as long as we put proper restraints on how collected data can be accessed by the authorities).

Batter Capacity vs. Processor Speed
by vlm

Have you run into a law relating battery capacity (either per Kg or L) vs processor speed over time? I bet there is some kind of interesting curve for mobile devices. Or, maybe not — that’s why I'm asking a guy with previous success at data analysis in a closely related field...

JK: Great questions. I haven’t seen any quantitative regularity in how battery power densities vary over time, but am actively looking for data. I hope to have something to report about that (along with the other trends I’m investigating, as I describe above). If you know of any good data sources, please let me know.

Queen of Hearts
by Anonymous

What do you think about the following observation: that every X years the amount of computing operations we use to perform basic calculations doubles (by virtue of doing those calculations with more complex software, slower languages...), so when you factor in Moore's law (and your own), the amount of useful calculations we do with computers remain more or less constant.

JK: This is related to the bloatware question above. I haven’t seen any quantitative estimates of the real cost from bloatware, but computing is becoming more widely distributed throughout the society, and it’s hard to believe that will the proliferation of more and more mobile devices and all the chips now incorporated in embedded systems that we’re doing less useful computing work than in the past. Some folks have tried to quantify total computational work being done, but it’s hard to do: Hilbert, Martin, and Priscila López. 2011. "The World's Technological Capacity to Store, Communicate, and Compute Information." Science. vol. 332, no. 6025. April 1. pp. 60-65

Feynman Quote
by yakolev

Mr. Koomey, if we take your numbers from the attached article, which may not have been quoted correctly

Feynman indicated that there was approximately 100 billion times efficiency improvement possible, and 40,000 times improvement has happened so far.

If we take Feynman's number at face value, this means that if computing efficiency improvements continue at the current rate (doubling every 18 months,) we will reach the theoretical maximum in 2043.

Based on that, do you believe that we will see a dramatic reduction in efficiency improvements in the next 10-20 years as we approach the theoretical limit, or do you think Feynman was conservative in his estimate?

JK: Your math is correct, as is the quotation of those numbers. If computing efficiency doubles every 1.5 years, it will take 21.3 doublings before we reach the theoretical limits identified by Feynman, which means will hit that limit in 32 years (i.e. in 2043).

Here’s what Feynman had to say in the book I cited:

Of course there is a limitation, the practical limitation anyway, that the bits must be of the size of an atom and a transistor 3 or 4 atoms; the quantum mechanical gate I used has 3 atoms. (I would not try to write my bits on to nuclei, I’ll wait till the technological development reaches the atoms before I need to go any further!) That leads us just with (a) the limitations in size to the size of atoms, (b) the energy requirements depending on the time as worked out by Bennett, (c) and the feature that I did not mention concerning the speed of light; we can’t send the signals any faster than the speed of light. Those are the only physical limitations that I know on computers.

If we make an atomic size computer, somehow, it would mean that the dimension, the linear dimension is a thousand to ten thousands times smaller than those very tiny chips that we have now. It means that the volume of the computer is 100 billionth, 1011 of the present volume, because the transistor is that much smaller 1011 , than the transistors that we make today. The energy requirement for a single switch is also about eleven orders of magnitude smaller than the energy required to switch the transistor today, and the time to make the transitions will be at least ten thousands times faster per step of calculation. So there is plenty of room for improvement in the computer and I leave you, practical people who work on computers, this as an aim to get to. (Feynman, Richard P. 2001. The Pleasure of Finding Things Out: The Best Short Works of Richard P. Feynman. London, UK: Penguin Books.)

So the calculation Feynman did was based on a transistor using just three atoms. In theory, one could use individual nuclei (as Feynman suggests) or there may be another as yet totally unknown way to crack this nut. But using Feynman’s calculation as the ultimate limit, in about three decades (and probably before that) we’re going to hit some kind of limit using our current methods.

But even given that, we’ve got at least another decade of improvements (that’s what my friends at Intel tell me) and probably more. Every decade means a factor of 100 improvement in the power efficiency of computing (doubling every 1.5 years) but there are also vast improvements we can make in our software as well as our implementation of power savings in the standby power of these devices (which turns out to be a much bigger power drain than the active power, given that almost all computers have very low average utilization). Hitting these limits may actually force the software designers to get more efficient (we’ll see!). And we’re just at the beginning of using the technologies enabled by these trends to accomplish human goals, so I’m hopeful we’ll be clever and figure out loads of important applications that will become possible with a factor of 100 or 1000 improvements in efficiency over the next 15 years.

Haven`t we already fallen behind?
by Anonymous

The Pentium M (which is powering the computer that I`m using to type this) came out eight years ago. Let`s call it 7.5 and make our "Koomey factor" 2^5=32. The ULV chip ran at 1.1GHz and ate 6.4W, and we can add on the power of the 855PM northbridge which would make the total 8.2W. I don`t see any products on the market that are anywhere close to a 32x improvement on performance per watt. Do you?

JK: Our focus is on system power, not chip power alone. And you need to calculate what your current system is capable of in computations per kWh (which you can calculate from performance per watt) so you can compare to our numbers. But I’ll wager that the current crop of laptops (or the new Mac Mini) will blow away your old machine in terms of computations per kWh at maximum performance (which is what we measure).

A couple weeks ago, you asked questions of Stanford professor Jonathan Koomey about what has been dubbed Koomey's Law — the idea that the energy efficiency of computing doubles every 1.5 years. Read on for Professor Koomey's answers to the questions you raised. What makes this a non-trivial extension?
by Anonymous

What makes your law a non-trivial extension of Moore's Law, which states that the transistor count would double every 18 months due to an increase in density? E&M theory states that if you cut a wire's length in half, it's resistance cuts in half. Granted density in this case is a 2 dimensional expansion and wire resistance is a 1 dimensional formula, but what makes this different from what a freshman in college can infer from an R = (resistivity * length)/cross sectional area?

Jonathan Koomey: First, it’s important to note that we assessed these trends empirically, using measured power data for each computer system in our dataset, and it’s often valuable to confirm with actual measurements what theory implies. Just because the result sounds intuitive to you after the fact doesn’t mean that it isn’t valuable to confirm with real data that the trends actually exist. And of course we discuss in the paper the driving forces behind the reductions in power use per logical switch (and they involve more than just reductions in I squared R losses in the wires). I’ve pasted below two relevant paragraphs from the article:

For vacuum tube computers, both computational speed and reliability issues encouraged computer designers to reduce power use. Heat reduces reliability, which was a major issue for tube-based computers. In addition, increasing computation speeds went hand in hand with technological changes (like reduced capacitive loading, lower currents, and smaller tubes) that also reduced power use. And the economics of operating a tube-based computer led to pressure to reduce power use, although this issue was probably a secondary one in the early days of electronic computing.

For transistorized and microprocessor based computers, the driving factor for power reductions was (and is) the push to reduce the physical dimensions of transistors, which reduces the cost per transistor. In order to accomplish this goal, power used per transistor also must be reduced; otherwise the power densities on the silicon rapidly become unmanageable. Per transistor power use is directly proportional to the length of the transistor between source and drain, the ratio of transistor length to mean free path of the electrons, and the total number of electrons in the operating transistor, as Feynman (2001) pointed out. Shrinking transistor size therefore resulted in improved speed, reduced cost, and reduced power use per transistor (see also Bohr (2007) and Carver Mead’s thinking in the late 1960s, as summarized in Brock (2006, pp. 98-100)).

In addition, the fact that the trends have now been confirmed empirically means that people can get on with considering the implications of these trends, which I think are under-appreciated. The idea that we’ll be able to use ever more efficient computing technology in distributed applications will revolutionize data collection, communications, and control of processes, and people are only now starting to think about what may become possible.

As one of many examples showing the potential of ultra low power computing, consider the wireless no-battery sensors created by Joshua R. Smith of Intel and the University of Washington (coverage in the NY Times and the Economist). These sensors scavenge energy from stray television and radio signals, and they use so little power (60 microwatts in this example) that they don’t need any other power source. Stray light, motion, or heat can also be converted to meet slightly higher power needs, perhaps measured in milliwatts. The contours of this exciting design space are only beginning to be explored, and they are enabled by the trends identified in our paper.

I wouldn’t underestimate the importance of a shift in industry focus from raw performance to power efficiency for mobile devices. Some of the best engineers will be drawn to the problems of ultra low power computing in the same way as they’ve were drawn to high performance computing (HPC) in the past (no doubt terrific technologists will also continue to focus on HPC, but anytime a new hot area opens up there’s a migration of talent to that new topic).

Finally, I would add that the truly unexpected result was that the trend in computational efficiency extends for a longer period than Moore’s law, all the way back to Eniac in 1946. So these trends in computational efficiency are an inherent characteristic of computers that use electrons for switching, and are not limited to the microprocessor era. I, for one, did not expect that.

Your Take on Futurists?
by eldavojohn

What is your take on the interpretation of Futurists -- like Raymond Kurzweil -- in regards to extrapolating these 'laws' out to extreme distances?

JK: The physicist Neils Bohr once famously said “Prediction is very difficult, especially about the future.” It’s important to be careful in making long-term extrapolations, even if some technological trend has continued for some time. I think it’s fair to say that Moore’s law (and the trends in computational efficiency we identify) have more years to run, given how far we are from theoretical limits, but exactly when we’ll hit a real roadblock it will take someone more brash than me to say. I discuss the theoretical limit based on Feynman’s calculations below, and we will eventually reach that, but there may be ways to sidestep those limits. We’ll have to see how clever we can be!

Lets work this backwards ...
by PPH

... and see where the Babbage Engine fits on the curve.

JK: Since the Babbage engine never operated, I’m not sure how we could do this. I believe that some parts of the engine have been created using modern machining practices, but I don’t think anyone has ever made one in complete form. If someone has, I’d be interested to measure its electricity use and estimate its performance (of course, it was designed before the era of electricity). Nordhaus (2007) reports that

Early calculators were “dumb” machines that essentially relied on incrementation of digits. An important step in the development of modern computers was mechanical representation of logical steps. The first commercially practical information-processing machine was the Jacquard loom, developed in 1804. This machine used interchangeable punched cards that controlled the weaving and allowed a large variety of patterns to be produced automatically. This invention was part of the inspiration of Charles Babbage, who developed one of the great precursor inventions in computation. He designed two major conceptual breakthroughs, the “Difference Engine” and the “Analytical Engine.” The latter sketched the first programmable digital computer. Neither of the Babbage machines was constructed during his lifetime. An attempt in the 1990s by the British Museum to build the simpler Difference Engine using early-nineteenth-century technologies failed to perform its designed tasks. (reference: Swade, Doron. The Difference Engine. New York: Viking Press, 2000.)

Nordhaus, William D. 2007. "Two Centuries of Productivity Growth in Computing." The Journal of Economic History. vol. 67, no. 1. March. pp. 128-159. [http://nordhaus.econ.yale.edu/recent_stuff.html]

Nordhaus does attempt to estimate the speed of computation possible by hand calculations as well as abacuses, to compare to more automatic methods.

Infinity w/ reversible computing?
by DriedClexler

This one doesn't seem to have fundamental physical limits, so long as we eventually transition to reversible computing, in which the computer does not use up useful energy because every process it uses is fully reversible (i.e. the original state could be inferred).

All the limits on computation (except regarding storage) that you hear about (e.g. Landauer limit) are on irreversible computing, which is how current architecture works. It is the irreversibility of an operation that causes it to increase entropy.

Could the whole process be bypassed by the near-infinite efficiency of reversible computers?

JK:Here’s the flip answer: Only if you can afford to wait infinitely long for your answer.

Here’s the more serious answer: in principle, reversible computing could have a revolutionary impact, if we could figure out how to do it, and some folks are working on this. But I haven’t seen any near term applications of such devices—if you know of any, please let me know.

Multicore or System on a Chip Speed bumps?
by eldavojohn

A lot of consumer grade machines have begun focusing on multicore chips with a lower frequency to provide the same or better perceived computing performance than a high frequency single core chip. What happens when a technology like this subverts our craving for higher transistor density? Can you argue that your "law" is immune to researchers focusing on some hot new technology like a thousand core processor or a beefed up system on a chip in order to improve end user experience over pure algorithm crunching speed?

JK: First, I would call it (like Moore implied in his own papers) an empirical observation rather than a law.

But in any case, I don’t think that the transition to multicore has “subverted our craving for higher transistor density,” we’re just using the transistors in a different way. The density of chips (measured in components per square centimeter or equivalent metric) will continue to increase, it’s just that the scaling of clock speeds that drove performance increases for so long is no longer possible (mainly because of high leakage currents inside the chip). So that means we need to make many cores and then modify software to capture that performance.

At the end of the day, WHAT you choose to do with the computing power is unrelated to the trends we identify, but I would argue the focus of device and software design is inevitably moving towards enhancing the end-user experience because these trends in efficiency are allowing ever more mobile devices to serve people’s immediate needs in an ever more personal way.

How will this affect programmers?
by Anonymous

When we eventually hit the physical limits of atoms, will programmers eventually stop their autistic quest for more and more layers, more and more complexity and more and more languages to move a number from one address to another?

How will programmers affect this?
by skids

While sarcastic, the above question is an important one: as computing power has increased, the tendency of coders to just ride over badly coded underlayers rather than redesign them competently and efficiently has increased. Why bother cutting out bloat that causes an 80% penalty on system efficiency when you can just use a more efficient chipset to get the same result?

So my question is whether you have put any thought into similarly quantifying the opposing software bloat factor, and what he sees the total balance of system works out to.

JK: Software bloat is a real issue, and I agree with your analysis that the ever-improving hardware picture has allowed poor coding practices to continue. But with the shift to multicore, there’s been at least some burden on programmers to change their ways—they have to modify their code to take advantage of multicore performance, so their skills are actually needed to capture increased performance (which is new, or at least a throwback to the early days of computing, when the programmers had so few hardware resources to work with that they had to be extremely parsimonious in their coding).

In the paper, we write:

Whether performance per CPU can grow for many years more at the historical pace is an ongoing subject of debate in the computer industry (Bohr 2007), but near-term improvements are already “in the pipeline”. Continuing the historical trends in performance (or surpassing them) is at this juncture dependent on significant new innovation comparable in scale to the shift from single core to multi-core computing. Such innovation will also require substantial changes in software design (Asanovíc et al. 2006), which is a relatively new development for the IT industry and it is another reason why whole system redesign is so critical to success.

This really doesn’t address the serious issue you raise about bloatware, which I think is a generic problem that other people more skilled in software design than me can address much better than I can. It’s hard to quantify it because it is so situation specific, but someone at a university somewhere may have tried to do this—I just don’t know.

Applied to Other Kinds of Computing?
by Anonymous

How well does Koomey's Law fit other kinds of computing? For instance, has the energy efficiency of cell phone microprocessors followed the same trend as desktop computers and servers? What about embedded systems like routers and car engine controllers, or specialized hardware like game consoles?

JK: These are all excellent questions (which we raise in the article) and I’m actively seeking data, but I don’t have anything new to report on this yet. I’m also interested in trends in data transmission power efficiencies, because that’s a key limitation on these mobile devices. And I’m digging around for battery capacity data over time as well.

Moral/Ethical
by vlm

Here is the list of moral / ethical arguments about the path we're on, as seen in your law. You saw the path clearly enough to define a time based law. Are there any issues I'm not seeing on our current path?

1) Lower energy consumption at point of use
2) Higher energy consumption at manufacturing point
3) faster cpu = bigger programs = more bugs = lower quality of life
4) faster cpu = stronger DRM possibilities
5) Better processing * battery life = better medical devices
6) Better processing * battery life = better 1984 style totalitarian devices
7) Lower energy consumption = less air conditioning demand = decreasing average latitude of data centers = population shifts or whatever or something?
8) More money required for both hw and sw development = good for big corps and bad for the little guy

JK: Hmmm, I’m not quite sure where you are going with this. There are pluses and minuses to all technological innovations, but I’m pretty sure the benefits will outweigh the costs in this case (as long as we put proper restraints on how collected data can be accessed by the authorities).

Batter Capacity vs. Processor Speed
by vlm

Have you run into a law relating battery capacity (either per Kg or L) vs processor speed over time? I bet there is some kind of interesting curve for mobile devices. Or, maybe not — that’s why I'm asking a guy with previous success at data analysis in a closely related field...

JK: Great questions. I haven’t seen any quantitative regularity in how battery power densities vary over time, but am actively looking for data. I hope to have something to report about that (along with the other trends I’m investigating, as I describe above). If you know of any good data sources, please let me know.

Queen of Hearts
by Anonymous

What do you think about the following observation: that every X years the amount of computing operations we use to perform basic calculations doubles (by virtue of doing those calculations with more complex software, slower languages...), so when you factor in Moore's law (and your own), the amount of useful calculations we do with computers remain more or less constant.

JK: This is related to the bloatware question above. I haven’t seen any quantitative estimates of the real cost from bloatware, but computing is becoming more widely distributed throughout the society, and it’s hard to believe that will the proliferation of more and more mobile devices and all the chips now incorporated in embedded systems that we’re doing less useful computing work than in the past. Some folks have tried to quantify total computational work being done, but it’s hard to do: Hilbert, Martin, and Priscila López. 2011. "The World's Technological Capacity to Store, Communicate, and Compute Information." Science. vol. 332, no. 6025. April 1. pp. 60-65

Feynman Quote
by yakolev

Mr. Koomey, if we take your numbers from the attached article, which may not have been quoted correctly

Feynman indicated that there was approximately 100 billion times efficiency improvement possible, and 40,000 times improvement has happened so far.

If we take Feynman's number at face value, this means that if computing efficiency improvements continue at the current rate (doubling every 18 months,) we will reach the theoretical maximum in 2043.

Based on that, do you believe that we will see a dramatic reduction in efficiency improvements in the next 10-20 years as we approach the theoretical limit, or do you think Feynman was conservative in his estimate?

JK: Your math is correct, as is the quotation of those numbers. If computing efficiency doubles every 1.5 years, it will take 21.3 doublings before we reach the theoretical limits identified by Feynman, which means will hit that limit in 32 years (i.e. in 2043).

Here’s what Feynman had to say in the book I cited:

Of course there is a limitation, the practical limitation anyway, that the bits must be of the size of an atom and a transistor 3 or 4 atoms; the quantum mechanical gate I used has 3 atoms. (I would not try to write my bits on to nuclei, I’ll wait till the technological development reaches the atoms before I need to go any further!) That leads us just with (a) the limitations in size to the size of atoms, (b) the energy requirements depending on the time as worked out by Bennett, (c) and the feature that I did not mention concerning the speed of light; we can’t send the signals any faster than the speed of light. Those are the only physical limitations that I know on computers.

If we make an atomic size computer, somehow, it would mean that the dimension, the linear dimension is a thousand to ten thousands times smaller than those very tiny chips that we have now. It means that the volume of the computer is 100 billionth, 1011 of the present volume, because the transistor is that much smaller 1011 , than the transistors that we make today. The energy requirement for a single switch is also about eleven orders of magnitude smaller than the energy required to switch the transistor today, and the time to make the transitions will be at least ten thousands times faster per step of calculation. So there is plenty of room for improvement in the computer and I leave you, practical people who work on computers, this as an aim to get to. (Feynman, Richard P. 2001. The Pleasure of Finding Things Out: The Best Short Works of Richard P. Feynman. London, UK: Penguin Books.)

So the calculation Feynman did was based on a transistor using just three atoms. In theory, one could use individual nuclei (as Feynman suggests) or there may be another as yet totally unknown way to crack this nut. But using Feynman’s calculation as the ultimate limit, in about three decades (and probably before that) we’re going to hit some kind of limit using our current methods.

But even given that, we’ve got at least another decade of improvements (that’s what my friends at Intel tell me) and probably more. Every decade means a factor of 100 improvement in the power efficiency of computing (doubling every 1.5 years) but there are also vast improvements we can make in our software as well as our implementation of power savings in the standby power of these devices (which turns out to be a much bigger power drain than the active power, given that almost all computers have very low average utilization). Hitting these limits may actually force the software designers to get more efficient (we’ll see!). And we’re just at the beginning of using the technologies enabled by these trends to accomplish human goals, so I’m hopeful we’ll be clever and figure out loads of important applications that will become possible with a factor of 100 or 1000 improvements in efficiency over the next 15 years.

Haven`t we already fallen behind?
by Anonymous

The Pentium M (which is powering the computer that I`m using to type this) came out eight years ago. Let`s call it 7.5 and make our "Koomey factor" 2^5=32. The ULV chip ran at 1.1GHz and ate 6.4W, and we can add on the power of the 855PM northbridge which would make the total 8.2W. I don`t see any products on the market that are anywhere close to a 32x improvement on performance per watt. Do you?

JK: Our focus is on system power, not chip power alone. And you need to calculate what your current system is capable of in computations per kWh (which you can calculate from performance per watt) so you can compare to our numbers. But I’ll wager that the current crop of laptops (or the new Mac Mini) will blow away your old machine in terms of computations per kWh at maximum performance (which is what we measure).

A couple weeks ago, you asked questions of Stanford professor Jonathan Koomey about what has been dubbed Koomey's Law — the idea that the energy efficiency of computing doubles every 1.5 years. Read on for Professor Koomey's answers to the questions you raised. What makes this a non-trivial extension?
by Anonymous

What makes your law a non-trivial extension of Moore's Law, which states that the transistor count would double every 18 months due to an increase in density? E&M theory states that if you cut a wire's length in half, it's resistance cuts in half. Granted density in this case is a 2 dimensional expansion and wire resistance is a 1 dimensional formula, but what makes this different from what a freshman in college can infer from an R = (resistivity * length)/cross sectional area?

Jonathan Koomey: First, it’s important to note that we assessed these trends empirically, using measured power data for each computer system in our dataset, and it’s often valuable to confirm with actual measurements what theory implies. Just because the result sounds intuitive to you after the fact doesn’t mean that it isn’t valuable to confirm with real data that the trends actually exist. And of course we discuss in the paper the driving forces behind the reductions in power use per logical switch (and they involve more than just reductions in I squared R losses in the wires). I’ve pasted below two relevant paragraphs from the article:

For vacuum tube computers, both computational speed and reliability issues encouraged computer designers to reduce power use. Heat reduces reliability, which was a major issue for tube-based computers. In addition, increasing computation speeds went hand in hand with technological changes (like reduced capacitive loading, lower currents, and smaller tubes) that also reduced power use. And the economics of operating a tube-based computer led to pressure to reduce power use, although this issue was probably a secondary one in the early days of electronic computing.

For transistorized and microprocessor based computers, the driving factor for power reductions was (and is) the push to reduce the physical dimensions of transistors, which reduces the cost per transistor. In order to accomplish this goal, power used per transistor also must be reduced; otherwise the power densities on the silicon rapidly become unmanageable. Per transistor power use is directly proportional to the length of the transistor between source and drain, the ratio of transistor length to mean free path of the electrons, and the total number of electrons in the operating transistor, as Feynman (2001) pointed out. Shrinking transistor size therefore resulted in improved speed, reduced cost, and reduced power use per transistor (see also Bohr (2007) and Carver Mead’s thinking in the late 1960s, as summarized in Brock (2006, pp. 98-100)).

In addition, the fact that the trends have now been confirmed empirically means that people can get on with considering the implications of these trends, which I think are under-appreciated. The idea that we’ll be able to use ever more efficient computing technology in distributed applications will revolutionize data collection, communications, and control of processes, and people are only now starting to think about what may become possible.

As one of many examples showing the potential of ultra low power computing, consider the wireless no-battery sensors created by Joshua R. Smith of Intel and the University of Washington (coverage in the NY Times and the Economist). These sensors scavenge energy from stray television and radio signals, and they use so little power (60 microwatts in this example) that they don’t need any other power source. Stray light, motion, or heat can also be converted to meet slightly higher power needs, perhaps measured in milliwatts. The contours of this exciting design space are only beginning to be explored, and they are enabled by the trends identified in our paper.

I wouldn’t underestimate the importance of a shift in industry focus from raw performance to power efficiency for mobile devices. Some of the best engineers will be drawn to the problems of ultra low power computing in the same way as they’ve were drawn to high performance computing (HPC) in the past (no doubt terrific technologists will also continue to focus on HPC, but anytime a new hot area opens up there’s a migration of talent to that new topic).

Finally, I would add that the truly unexpected result was that the trend in computational efficiency extends for a longer period than Moore’s law, all the way back to Eniac in 1946. So these trends in computational efficiency are an inherent characteristic of computers that use electrons for switching, and are not limited to the microprocessor era. I, for one, did not expect that.

Your Take on Futurists?
by eldavojohn

What is your take on the interpretation of Futurists -- like Raymond Kurzweil -- in regards to extrapolating these 'laws' out to extreme distances?

JK: The physicist Neils Bohr once famously said “Prediction is very difficult, especially about the future.” It’s important to be careful in making long-term extrapolations, even if some technological trend has continued for some time. I think it’s fair to say that Moore’s law (and the trends in computational efficiency we identify) have more years to run, given how far we are from theoretical limits, but exactly when we’ll hit a real roadblock it will take someone more brash than me to say. I discuss the theoretical limit based on Feynman’s calculations below, and we will eventually reach that, but there may be ways to sidestep those limits. We’ll have to see how clever we can be!

Lets work this backwards ...
by PPH

... and see where the Babbage Engine fits on the curve.

JK: Since the Babbage engine never operated, I’m not sure how we could do this. I believe that some parts of the engine have been created using modern machining practices, but I don’t think anyone has ever made one in complete form. If someone has, I’d be interested to measure its electricity use and estimate its performance (of course, it was designed before the era of electricity). Nordhaus (2007) reports that

Early calculators were “dumb” machines that essentially relied on incrementation of digits. An important step in the development of modern computers was mechanical representation of logical steps. The first commercially practical information-processing machine was the Jacquard loom, developed in 1804. This machine used interchangeable punched cards that controlled the weaving and allowed a large variety of patterns to be produced automatically. This invention was part of the inspiration of Charles Babbage, who developed one of the great precursor inventions in computation. He designed two major conceptual breakthroughs, the “Difference Engine” and the “Analytical Engine.” The latter sketched the first programmable digital computer. Neither of the Babbage machines was constructed during his lifetime. An attempt in the 1990s by the British Museum to build the simpler Difference Engine using early-nineteenth-century technologies failed to perform its designed tasks. (reference: Swade, Doron. The Difference Engine. New York: Viking Press, 2000.)

Nordhaus, William D. 2007. "Two Centuries of Productivity Growth in Computing." The Journal of Economic History. vol. 67, no. 1. March. pp. 128-159. [http://nordhaus.econ.yale.edu/recent_stuff.html]

Nordhaus does attempt to estimate the speed of computation possible by hand calculations as well as abacuses, to compare to more automatic methods.

Infinity w/ reversible computing?
by DriedClexler

This one doesn't seem to have fundamental physical limits, so long as we eventually transition to reversible computing, in which the computer does not use up useful energy because every process it uses is fully reversible (i.e. the original state could be inferred).

All the limits on computation (except regarding storage) that you hear about (e.g. Landauer limit) are on irreversible computing, which is how current architecture works. It is the irreversibility of an operation that causes it to increase entropy.

Could the whole process be bypassed by the near-infinite efficiency of reversible computers?

JK:Here’s the flip answer: Only if you can afford to wait infinitely long for your answer.

Here’s the more serious answer: in principle, reversible computing could have a revolutionary impact, if we could figure out how to do it, and some folks are working on this. But I haven’t seen any near term applications of such devices—if you know of any, please let me know.

Multicore or System on a Chip Speed bumps?
by eldavojohn

A lot of consumer grade machines have begun focusing on multicore chips with a lower frequency to provide the same or better perceived computing performance than a high frequency single core chip. What happens when a technology like this subverts our craving for higher transistor density? Can you argue that your "law" is immune to researchers focusing on some hot new technology like a thousand core processor or a beefed up system on a chip in order to improve end user experience over pure algorithm crunching speed?

JK: First, I would call it (like Moore implied in his own papers) an empirical observation rather than a law.

But in any case, I don’t think that the transition to multicore has “subverted our craving for higher transistor density,” we’re just using the transistors in a different way. The density of chips (measured in components per square centimeter or equivalent metric) will continue to increase, it’s just that the scaling of clock speeds that drove performance increases for so long is no longer possible (mainly because of high leakage currents inside the chip). So that means we need to make many cores and then modify software to capture that performance.

At the end of the day, WHAT you choose to do with the computing power is unrelated to the trends we identify, but I would argue the focus of device and software design is inevitably moving towards enhancing the end-user experience because these trends in efficiency are allowing ever more mobile devices to serve people’s immediate needs in an ever more personal way.

How will this affect programmers?
by Anonymous

When we eventually hit the physical limits of atoms, will programmers eventually stop their autistic quest for more and more layers, more and more complexity and more and more languages to move a number from one address to another?

How will programmers affect this?
by skids

While sarcastic, the above question is an important one: as computing power has increased, the tendency of coders to just ride over badly coded underlayers rather than redesign them competently and efficiently has increased. Why bother cutting out bloat that causes an 80% penalty on system efficiency when you can just use a more efficient chipset to get the same result?

So my question is whether you have put any thought into similarly quantifying the opposing software bloat factor, and what he sees the total balance of system works out to.

JK: Software bloat is a real issue, and I agree with your analysis that the ever-improving hardware picture has allowed poor coding practices to continue. But with the shift to multicore, there’s been at least some burden on programmers to change their ways—they have to modify their code to take advantage of multicore performance, so their skills are actually needed to capture increased performance (which is new, or at least a throwback to the early days of computing, when the programmers had so few hardware resources to work with that they had to be extremely parsimonious in their coding).

In the paper, we write:

Whether performance per CPU can grow for many years more at the historical pace is an ongoing subject of debate in the computer industry (Bohr 2007), but near-term improvements are already “in the pipeline”. Continuing the historical trends in performance (or surpassing them) is at this juncture dependent on significant new innovation comparable in scale to the shift from single core to multi-core computing. Such innovation will also require substantial changes in software design (Asanovíc et al. 2006), which is a relatively new development for the IT industry and it is another reason why whole system redesign is so critical to success.

This really doesn’t address the serious issue you raise about bloatware, which I think is a generic problem that other people more skilled in software design than me can address much better than I can. It’s hard to quantify it because it is so situation specific, but someone at a university somewhere may have tried to do this—I just don’t know.

Applied to Other Kinds of Computing?
by Anonymous

How well does Koomey's Law fit other kinds of computing? For instance, has the energy efficiency of cell phone microprocessors followed the same trend as desktop computers and servers? What about embedded systems like routers and car engine controllers, or specialized hardware like game consoles?

JK: These are all excellent questions (which we raise in the article) and I’m actively seeking data, but I don’t have anything new to report on this yet. I’m also interested in trends in data transmission power efficiencies, because that’s a key limitation on these mobile devices. And I’m digging around for battery capacity data over time as well.

Moral/Ethical
by vlm

Here is the list of moral / ethical arguments about the path we're on, as seen in your law. You saw the path clearly enough to define a time based law. Are there any issues I'm not seeing on our current path?

1) Lower energy consumption at point of use
2) Higher energy consumption at manufacturing point
3) faster cpu = bigger programs = more bugs = lower quality of life
4) faster cpu = stronger DRM possibilities
5) Better processing * battery life = better medical devices
6) Better processing * battery life = better 1984 style totalitarian devices
7) Lower energy consumption = less air conditioning demand = decreasing average latitude of data centers = population shifts or whatever or something?
8) More money required for both hw and sw development = good for big corps and bad for the little guy

JK: Hmmm, I’m not quite sure where you are going with this. There are pluses and minuses to all technological innovations, but I’m pretty sure the benefits will outweigh the costs in this case (as long as we put proper restraints on how collected data can be accessed by the authorities).

Batter Capacity vs. Processor Speed
by vlm

Have you run into a law relating battery capacity (either per Kg or L) vs processor speed over time? I bet there is some kind of interesting curve for mobile devices. Or, maybe not — that’s why I'm asking a guy with previous success at data analysis in a closely related field...

JK: Great questions. I haven’t seen any quantitative regularity in how battery power densities vary over time, but am actively looking for data. I hope to have something to report about that (along with the other trends I’m investigating, as I describe above). If you know of any good data sources, please let me know.

Queen of Hearts
by Anonymous

What do you think about the following observation: that every X years the amount of computing operations we use to perform basic calculations doubles (by virtue of doing those calculations with more complex software, slower languages...), so when you factor in Moore's law (and your own), the amount of useful calculations we do with computers remain more or less constant.

JK: This is related to the bloatware question above. I haven’t seen any quantitative estimates of the real cost from bloatware, but computing is becoming more widely distributed throughout the society, and it’s hard to believe that will the proliferation of more and more mobile devices and all the chips now incorporated in embedded systems that we’re doing less useful computing work than in the past. Some folks have tried to quantify total computational work being done, but it’s hard to do: Hilbert, Martin, and Priscila López. 2011. "The World's Technological Capacity to Store, Communicate, and Compute Information." Science. vol. 332, no. 6025. April 1. pp. 60-65

Feynman Quote
by yakolev

Mr. Koomey, if we take your numbers from the attached article, which may not have been quoted correctly

Feynman indicated that there was approximately 100 billion times efficiency improvement possible, and 40,000 times improvement has happened so far.

If we take Feynman's number at face value, this means that if computing efficiency improvements continue at the current rate (doubling every 18 months,) we will reach the theoretical maximum in 2043.

Based on that, do you believe that we will see a dramatic reduction in efficiency improvements in the next 10-20 years as we approach the theoretical limit, or do you think Feynman was conservative in his estimate?

JK: Your math is correct, as is the quotation of those numbers. If computing efficiency doubles every 1.5 years, it will take 21.3 doublings before we reach the theoretical limits identified by Feynman, which means will hit that limit in 32 years (i.e. in 2043).

Here’s what Feynman had to say in the book I cited:

Of course there is a limitation, the practical limitation anyway, that the bits must be of the size of an atom and a transistor 3 or 4 atoms; the quantum mechanical gate I used has 3 atoms. (I would not try to write my bits on to nuclei, I’ll wait till the technological development reaches the atoms before I need to go any further!) That leads us just with (a) the limitations in size to the size of atoms, (b) the energy requirements depending on the time as worked out by Bennett, (c) and the feature that I did not mention concerning the speed of light; we can’t send the signals any faster than the speed of light. Those are the only physical limitations that I know on computers.

If we make an atomic size computer, somehow, it would mean that the dimension, the linear dimension is a thousand to ten thousands times smaller than those very tiny chips that we have now. It means that the volume of the computer is 100 billionth, 1011 of the present volume, because the transistor is that much smaller 1011 , than the transistors that we make today. The energy requirement for a single switch is also about eleven orders of magnitude smaller than the energy required to switch the transistor today, and the time to make the transitions will be at least ten thousands times faster per step of calculation. So there is plenty of room for improvement in the computer and I leave you, practical people who work on computers, this as an aim to get to. (Feynman, Richard P. 2001. The Pleasure of Finding Things Out: The Best Short Works of Richard P. Feynman. London, UK: Penguin Books.)

So the calculation Feynman did was based on a transistor using just three atoms. In theory, one could use individual nuclei (as Feynman suggests) or there may be another as yet totally unknown way to crack this nut. But using Feynman’s calculation as the ultimate limit, in about three decades (and probably before that) we’re going to hit some kind of limit using our current methods.

But even given that, we’ve got at least another decade of improvements (that’s what my friends at Intel tell me) and probably more. Every decade means a factor of 100 improvement in the power efficiency of computing (doubling every 1.5 years) but there are also vast improvements we can make in our software as well as our implementation of power savings in the standby power of these devices (which turns out to be a much bigger power drain than the active power, given that almost all computers have very low average utilization). Hitting these limits may actually force the software designers to get more efficient (we’ll see!). And we’re just at the beginning of using the technologies enabled by these trends to accomplish human goals, so I’m hopeful we’ll be clever and figure out loads of important applications that will become possible with a factor of 100 or 1000 improvements in efficiency over the next 15 years.

Haven`t we already fallen behind?
by Anonymous

The Pentium M (which is powering the computer that I`m using to type this) came out eight years ago. Let`s call it 7.5 and make our "Koomey factor" 2^5=32. The ULV chip ran at 1.1GHz and ate 6.4W, and we can add on the power of the 855PM northbridge which would make the total 8.2W. I don`t see any products on the market that are anywhere close to a 32x improvement on performance per watt. Do you?

JK: Our focus is on system power, not chip power alone. And you need to calculate what your current system is capable of in computations per kWh (which you can calculate from performance per watt) so you can compare to our numbers. But I’ll wager that the current crop of laptops (or the new Mac Mini) will blow away your old machine in terms of computations per kWh at maximum performance (which is what we measure).

jfruhlinger writes "The long-running security battle has seesawed against RFID cards, as German researchers revealed a way to clone one type of card currently used for a variety of purposes, from transit fares to opening doors in NASA facilities." According to the article, "NXP Semiconductors, which owns Mifare, put out an alert to customers warning that the security had been cracked on its MIFARE DESFire (MF3ICD40) smartcard but saying that model would be discontinued by the end of the year and encouraging customers to upgrade to the EV1 version of the card." This response may sound familiar.

gclef writes "Netflix has apparently decided that spinning off their DVD business into a separate organization was a bad idea after all, and is killing off the 'Qwikster' concept. From the article: 'Less than a month ago, the Netflix said it would split the DVD rental business off on a new website, to be called Qwikster. Subscribers howled at the move, saying they saw Netflix as a destination for movies in general and didn’t want to manage two accounts. “It is clear that for many of our members two websites would make things more difficult, so we are going to keep Netflix as one place to go for streaming and DVDs,” CEO Reed Hastings said in the blog post.'"

jjp9999 writes "The virus that hit Predator and Reaper UAVs could be an internal monitoring system employed by the military. According to security researcher Miles Fidelman, there are vendors that sell security monitoring packages to the Defense Department which are 'essentially rootkits that do, among other things, key logging.' The virus is a keylogger that was found at pilot stations, and could be keeping tabs on keystrokes used by pilots to control the UAVs, found Wired's Danger Room blog. Fidelman adds, 'I kind of wonder if the virus that folks are fighting is something that some other part of DoD deployed intentionally.'"

bs0d3 writes "Recently, many people from Belgium have been joining The Pirate Bay's and Telecomix's IRC channels, asking for help with the Telecomix DNS, saying that it doesn't work to access www.thepiratebay.org. This is true. The court was very specific in its order, which was to block the domains www.thepiratebay.org, www.thepiratebay.net, www.thepiratebay.com, www.thepiratebay.nu, www.thepiratebay.se, www.piratebay.no, and www.ripthepiratebay.com, or else face a daily penalty of 1000 EUR for every day when defendants do not implement such 'DNS-blocking' in their DNS-servers'. So, obviously in defiance of that, people testing their DNS servers go to the domain www.thepiratebay.org — except, thepiratebay doesn't have the www domain turned on. At one point it redirected to the main page, at the URL thepiratebay.org; now it doesn't, probably because of negligence from the admins. What's interesting is that the court only ordered the block of the www subdomains, so if an ISP wants to make a fuss they should be able to avoid the penalties until a later ruling."

Facebook's recent move to scan for malicious URLs sounded like a pretty good idea, but itwbennett writes with word that it's already been bypassed.'Hatter,' a member of hacking think-tank Blackhat Academy, provided a live demonstration, which involved posting the URL to a JPEG file on a wall. Facebook crawled the URL and added a thumbnail image to the wall post, however, clicking on its corresponding link actually redirected users to YouTube. This happened because the destination page was able to identify Facebook's original request and served a JPEG file. Earlier this week, Facebook signed a partnership with Websense to use the security vendor's cloud-based, real-time Web scanner for malicious URL detection. Blackhat Academy has now provided proof-of-concept code, which, according to its advisory, can be used to bypass it."

An anonymous reader writes "Remember Fabrice bellard's [Linux-booting PC emulator in JavaScript] ? This modified version [Note: click on "emulator.html" in that directory to see it in action] allows the same emulator to boot the most recent linux kernel, 3.0.4, as well as providing the user with persistent storage. It is achieved by building a virtual block device, which stores data in HTML5 local storage. The block device can be partitioned and formatted as ext2, so it can be easily used."

jfruhlinger writes "Nearly four years ago, Microsoft tried to buy Yahoo, but eventually withdrew the offer in the face of resistance from Yahoo's leadership. This week rumors resurfaced that Microsoft was once again bidding on the struggling Internet pioneer, this time for significantly less money. But even at a discount, it might be a pretty bad idea for Microsoft to get involved in the unfocused, money-losing Yahoo."

jfruhlinger writes "Nearly four years ago, Microsoft tried to buy Yahoo, but eventually withdrew the offer in the face of resistance from Yahoo's leadership. This week rumors resurfaced that Microsoft was once again bidding on the struggling Internet pioneer, this time for significantly less money. But even at a discount, it might be a pretty bad idea for Microsoft to get involved in the unfocused, money-losing Yahoo."

An anonymous reader writes "The significant Linux kernel power regression reported back in April, which ended up being attributed to PCI-E Active State Power Management, is still not resolved even as Ubuntu 11.10 and Fedora 16 approach. Until Linux is able to handle ASPM in a manner more like Windows or the device drivers explicitly set the ASPM flag, users of many modern laptops need to use the "pcie_aspm=force" option to regain much of their battery life. At least a power bug affecting newer Intel hardware with the "energy performance bias" feature has been fixed. There's more information in this LaunchPad bug report and in the latest power consumption testing."

An anonymous reader writes "The significant Linux kernel power regression reported back in April, which ended up being attributed to PCI-E Active State Power Management, is still not resolved even as Ubuntu 11.10 and Fedora 16 approach. Until Linux is able to handle ASPM in a manner more like Windows or the device drivers explicitly set the ASPM flag, users of many modern laptops need to use the "pcie_aspm=force" option to regain much of their battery life. At least a power bug affecting newer Intel hardware with the "energy performance bias" feature has been fixed. There's more information in this LaunchPad bug report and in the latest power consumption testing."

holy_calamity writes "Slashdot noted in September that Google had bought 1023 patents from IBM. Now IP analytics firms IPVision says they're a 'mixed bag' of mostly unrelated patents that won't be much use in defending against competitors such as Microsoft or Apple. Patents are most useful when they are tightly linked into clusters by references, such that they cover every angle on an idea, something Google's new collection lacks."

An anonymous reader writes "Unreal Engine now runs in Flash and Crytek is considering porting CryEngine to Flash, but perhaps the Source Engine could go a different route. A software developer who works for Motorola Mobility has managed to get the engine and a level from Team Fortress 2 running in a browser using WebGL. There are still a few features and effects missing, but he claims it achieves a solid 60fps and has a video to prove it. Hopefully this gives Valve ideas; it'd be cool if older Source games became playable in your favorite browser, or even directly in Steam."

astroengine writes "On Oct. 5, less than two months before it will be launched, Mars Science Laboratory 'Curiosity' was sealed between its heat shield and back shell at Kennedy Space Center's Payload Hazardous Servicing Facility. The next time the one-ton rover sees daylight will be on Aug. 6, 2012, as the heat shield separates after successful entry through the Martian atmosphere, shortly before Curiosity touches down inside Gale Crater."

Long-time readers will know that we try not to clutter the front page of Slashdot with much stuff about the site itself; this is a rare exception, but we hope you'll like the reason: we want your opinions. You should see above a link to take a survey about Slashdot, and (just to be heavy handed) here's the direct link. The questions there are simple, but we're going to read the answers carefully. The reminder bar up there will remain active for some time, but this story will scroll down the page like all Slashdot stories. Comments are welcome below; surveys have their limitations, after all, but please don't comment without also giving the survey a visit — if it makes sense, feel free to cut-and-paste any answers from there as comments, too. The engineers who build this site (and the editors, too!) are counting on your honest opinions and hoping for some great ideas; ideas outnumber the hours we have to do things, so we hope you'll make a case for the ways that Slashdot should change (and the ways it shouldn't!).

A few weeks ago, UBS employee Kweku Adoboli (universally described as a "rogue trader") ran up a $2 billion loss for his employer; many readers wondered how it is the systems which allow trades to happen at all aren't better tuned to catch such massive cash flows without triggering alerts. Now, reader DMandPenfold submits a report from Computerworld UK in which the bank claims that such triggers were in place — they were simply not acted on. From the article: "UBS has insisted its IT systems did detect unusual and unauthorised trading activity, Interim chief executive Sergio Ermotti, who is running the company following Oswald Grubel's resignation last month, sent a memo to employees saying the bank is aware that its systems did detect the rogue activity. In the memo, Ermotti wrote: 'Our internal investigation indicates that risk and operational systems did detect unauthorised or unexplained activity but this was not sufficiently investigated nor was appropriate action taken to ensure existing controls were enforced.'"

gbrumfiel writes "Two weeks ago, researchers claimed particles called neutrinos were travelling faster-than-light and violating the laws of special relativity. But now it looks as though general relativity might be behind the experiment's unusual result. An independent analysis claims that the original experiment, known as OPERA, failed to take into account differences in earth's gravitational field between the neutrino source and the OPERA detector. As Nature News reports, gravity can distort time according to Einstein's theory, and the effect could explain why neutrinos appear to arrive 60 nanoseconds ahead of schedule. The OPERA team is now reviewing the new analysis."

iONiUM writes with a CNET article outlining the next step in Microsoft's plans for cable television, which he says "seems like yet another step forward in killing traditional cable companies." From the article: "[Microsoft] announced this morning that nearly 40 television content providers — including Comcast, Verizon, and HBO in the United States — will roll out programming over Xbox Live. The company also has deals lined up with providers in the U.K., Spain, Canada, Mexico, Germany, and Italy."

Back in 2009 we ran a story about a Chicago based non-profit company that trained high-functioning autistic people to be software testers. Two years later Aspiritech has grown to offer services in Belgium, Japan and Israel. Autistic debuggers are used by large clients like Oracle and Microsoft and have proven to be so good in fact that companies are now recruiting to meet demand. From the article: "Aspiritech's board of directors includes social service providers, therapists, a vocational expert and a software engineer. The nonprofit also received start-up advice and consultation from Keita Suzuki, who has co-founded a similar company, called Kaien, in Japan. Aspiritech has hired and trained seven recruits with Asperger's syndrome. These recruits have since worked on software-testing projects for smartphone and cloud-computing applications. Aspiritech now offers functional-, compatibility- and regression-testing, as well as test-case development, with experience in cloud-computing platforms including Salesforce."

Michael J. Ross writes "Most computer and web programming books are written entirely by a single author, while the remaining are written by more authors, typically with each one tackling several chapters. The latter approach can suffer from redundant material undetected by editors, and inconsistency in the writing style from one chapter to the next. Yet it offers the significant advantage that the subject matter of each chapter can be presented by an authority on that topic — who can focus on making that explication the best possible, without the burden of completing an entire book. That was one of my first thoughts (and hopes) when hefting the 1112 pages and 4.1 pounds of the Definitive Guide to Drupal 7." Read on for the rest of Michael's review. Definitive Guide to Drupal 7 author A cast of thousands. pages 1112 pages publisher Apress rating 8/10 reviewer Michael J. Ross ISBN 978-1430231356 summary A wide-ranging exploration of the latest version of Drupal. This tome was published on 19 July 2011, under the ISBN 978-1430231356, by Apress (who kindly provided a review copy). As of this writing, it appears to be the longest Drupal book in existence — more than 400 pages longer than the nearest two contenders. Fortunately, no single author ended up in an insane asylum as a consequence of trying to write such an extensive work on his own. Rather, this book is largely due to the efforts of 34 writers in total — more specifically, 30 authors (listed on the front cover, roughly in descending order of how many of the pages they wrote) and four more contributors (added to the list on the title page). This may be a new record in technical book publishing. The entire authorial crew won't be listed here, but it should be mentioned that Benjamin Melançon was the lead author, and contributed to many of the chapters.

The book's material is organized into 38 chapters and nine appendices — all grouped into eight parts: Getting Started, Site Building Foundations, Making Your Life Easier, Front-End Development, Back-End Development, Advanced Site-Building Topics, Drupal Community, and Appendix. The chapter and appendix titles won't be listed here, but can be found on the publisher's book page, which also offers a description of the book, a section for reported errata (none as of this writing), links to purchase the print and electronic versions of the book, and a downloadable archive of the source code. Unfortunately, the code is apparently available only as a Git repository, and thus is inaccessible if you cannot — or do not want to — install Git on your computer. Consequently, it would be more difficult for such a reader to follow along and implement the example code while reading the book.

The authors have created their own website for the book, where visitors can sign up for e-mail notification of updates and free chapters, view a chapter outline (which features some bonus material), see author photos and bios, offer suggested changes for future editions, and learn of reported errata (three, at this time). Throughout the book, readers are told to access that site for additional information related to the chapters' topics; yet there does not appear to be any such information, even after registering a new account and logging in. This will be most disappointing in those cases where the reader is enticed by the promise of valuable information, only to find that it is absent. The authors state (page lv) that there are forums, one per chapter; but those do not yet exist. In general, there seems to be a huge disconnect between that website and the claims made in the book as to what extra material readers will find there.

The book begins with some introductory material, consisting of three mini-chapters: "What's New in Drupal 7" briefly describes some of the terrific improvements over version 6. "How to Use the Book" reassures the prospective reader that the book "does not presume any specific prior curriculum", although this seems inconsistent with the back cover's user level of "Intermediate-Advanced". Also, readers may be perplexed by the claim that the URL path admin/people/permissions/rules will go to admin/help (page lv). The last section, "How Drupal Works", oddly does not explain how Drupal works, but instead discusses some common terms and the typical phases of a website development project.

The first part of the book comprises two chapters, the first of which has the promising title of "Building a Drupal 7 Site", and provides a cursory summary of site planning, wireframing, Drupal installation, the Administration menu, the Shortcut toolbar, color schemes, and modules. The chapter continues with sections on content types, blocks, taxonomy, and other key concepts — all grouped under the chapter head "Allowing People to Register and Log in with OpenID", even though those topics are unrelated to OpenID. All of the chapter's topics are illustrated by stepping the reader through building, from scratch, the beginnings of the Drupal 7 website — namely, one similar to the authors' site mentioned earlier. Unfortunately, some of the instruction in the book does not match the actual website design, e.g., no introductory text (page 20). Readers may be amused by the tip on page 11, which refers to "the remaining 800 pages of the book". Perhaps the remaining 1101 pages can be chalked up to scope creep! The second chapter explains the basics of how to install and use Drush and Git, but not for Windows users. Readers should find the material instructive and consistent, except for the claim that Git is "easy(ish)" even though "getting the hang of Git [is] a lifelong learning process".

The half dozen chapters that compose Part II first introduce some of the most commonly-used Drupal modules, with extensive coverage of Views and later Organic Groups. A couple chapters explain how to keep one's site secure, partly by updating Drupal core and modules. The last chapter continues the development of the example site, using modules presented earlier. All of these chapters' narrative is valuable, although a couple pronouncements are too severe (e.g., "User input is evil", on page 127); but overall the advice is well warranted. Yet the chapter that will most likely aggravate readers is the eighth one. It seems to presume that the reader's test site was not affected by the exercises of the previous chapters, such as the Organic Groups. Secondly, some key information is incorrect, e.g., "Content: Image" (page 159) should be "Content: Headshot". Lastly, the authors refer to items not yet created as though they were, e.g., a "Table of Contents" menu link, an "Outline of Chapters" menu, and a "Twitter" field (pages 162-164). Unfortunately, the effects of all these problems compound, and, combined with the changes in Views since Drupal 7.0, make it increasingly difficult to follow along and implement the instructions.

Part III offers another half dozen chapters, in this case devoted to higher-level, less technical matters — specifically, how to: best participate in the Drupal community, plan and manage a Drupal-based project, craft effective documentation for your sites' end users and support staff, set up a workable Drupal development environment, launch and back up a new website, and stay sane while doing all of this. The information presented is worthwhile, with only a couple peculiarities: Firstly, why is the book organized so that some technical information is presented in the early chapters, as well as later chapters, while a group of "softer" topics are sandwiched in between? Secondly, for Chapter 12, why is the reader told, halfway through the chapter, that she will need "A computer able to connect to the Internet" and "An Internet connection" (page 233)? No one who has worked through the preceding dozen chapters needs to be reminded of this. Perhaps this chapter, on how to set up a development environment, should be made an appendix, as was the other installation and setup topics (Appendices F-I).

The next few chapters, Part IV, explore front-end development — namely, theming and jQuery. The first two chapters were penned by Jacine Luisi, who heads up the HTML5 initiative for Drupal 8. Readers learn about Drupal's core themes, theme engines, theme administration, metadata files, regions, layout, template files, global template variables, theme functions and hooks, preprocess and process functions, render arrays, theming forms, and more. The discussion is competent and thorough, as well as comprehensible, aside from the repeated use of the verb "print" to apparently mean "display". Chapter 17 demonstrates the use of JavaScript and jQuery in Drupal, and finishes by showing how to use jQuery UI to implement animations, such as accordions and progress bars.

Part V, "Back-End Development", comprises seven chapters that explain how to develop custom Drupal modules using the APIs. Because they provide an introduction to Drupal's system of hooks and overrides, they probably should have been located before the earlier chapters on theming, which rely upon those features of Drupal. Regardless, Chapters 18-20, by Benjamin Melançon, attempt to demystify the key topics in module development. Because this subject area is so critical to real-world Drupal development, and because the concepts can be quite intimidating to neophytes, any presentation of it must proceed at a reasonable pace, with clear explanation of how each aspect relates to the next. Like similar discussions in other Drupal books, this one begins quite approachable, but becomes more daunting, with a few places where readers will likely be perplexed — such as the hook_form_alter() discussion (page 411), which doesn't seem to match the resultant HTML. Yet this is such a challenging subject area that entire books have been devoted to it, and this one ventures into areas untouched by other books, such as how to create new database tables. Drupal coding standards are presented, although apparently not always followed in the example code (e.g., preceding internal function names with underscores). Part V is rounded out with chapters on porting modules to Drupal 7, writing "glue" modules, performing functional testing, and writing extendable/API modules.

Part VI, "Advanced Site-Building Topics", consists of ten chapters covering a variety of topics: building an online store using Commerce module (authored by the project's founder and lead, Ryan Szrama); Drush (which overlaps with Chapter 2); caching and storage mechanisms (MySQL and MongoDB); RDFa and the Semantic Web; Drupal's routing system; Drupal's internal operations for presenting a requested page; Solr module; UX enhancements in Drupal 7; completing the book's website; and Drupal distributions. All of the information and guidance appears correct, except for a couple problems: The instructions (page 568) to install Commerce Physical Product module, which does not have a Drupal 7 release, as of this writing, and certainly as of the book's publication date. Drune is a music player used as an example throughout Chapter 34, but its website, drune.org (pages 805 and 817), appears to be dead at this time.

Throughout this book, one will find a strong sense of community, with frequent encouragement for the reader to participate and contribute. This is evidenced by Part VII, which comprises four chapters that present: Drupal's history, how to make a living as a Drupal developer, how to maintain a contributed project, and further thoughts on how to contribute to the overall Drupal community. The book concludes with Part VIII, consisting of nine appendices, most of which focus on how to install Drupal on various platforms. This part is strangely titled "Appendix", yet contains multiple appendices (more scope creep?).

Given the somewhat stunning length of this book, its multitude of authors, and its wide coverage of most aspects of Drupal, it should be expected that the book has both strengths and weaknesses. Consider first that latter category. The authors and publisher should have sought ways to reduce the length of the book. For instance, the overview of PHP in Chapter 18 is not needed for this book's audience, and could be replaced by references to outside, more-detailed resources. The same is true of the section on Drupal coding standards. The book does not need to be made any longer than it already is, without good reason. Speaking of which, most of the longer chapters end with summaries, which are not worth the extra space taken up. Drupal's hook system is explained in at least three different chapters, and Git in two. The many authors should have been aware of this, had they been referencing the book's website, which was presumably built before the text describing it was written. Furthermore, the publisher and its chosen technical reviewers should have also spotted this.

The remarkably large number of authors is probably the primary reason for the book's noticeable unevenness, from one chapter to the next, in the quality of the writing — including the clarity of the explanations, which is arguably the most important factor. In a book written by advanced Drupal developers, it is to be expected that they will use Drupal-specific terminology. That is fine, but such terms should be defined at least once, before encountered by any readers unfamiliar with them. For instance, page xxxv alone mentions "d.o", "D8", and "contrib" — all meaningless to someone learning Drupal. There are places in the text where the descriptions do not match the corresponding screenshots (e.g., the "Required field" on page 18), and where, in the narrative, the lack of quotation marks around field labels makes it jarring and difficult to understand (e.g., throughout Chapter 8). There are some inconsistencies in spelling (e.g., "web site" and "website", even in the same sentence, on page lii), some inconsistencies in italicizing menu links (e.g., page 13), some misused phrases (e.g., "cannot be understated", on pages lix and 225, when "cannot be overstated" was called for), some baffling allusions (e.g., "aiee-the-alligator-is-going-to-get-me", on page 492), curly quotes in the code (e.g., pages 277 and 356-9), a repeated paragraph (page 507), an oxymoron ("libertarian communism"; xlvi), and the obligatory conflation of "depreciated" and "deprecated" (page 495) found in countless programming books.

This book contains numerous errata: "co-maintainer [f]or Drupal 7" (page xxxiv), "and." (xxxv), "bi-lingual" (xxxviii), "able [to] handle" (xlix), "don' think" (lv), "criteria[:] type" (lviii), "able [to] fill" (11), "th[r]ough the" (14), "an a" (19), "ask question questions" (29), "install [the] X-ray" (38), "You [] requests nuggets" (49), "you want to you" (56), "on [the] system" (57), "menu of option[s]" (57), "Rather [than] saving" (57), "menu(" (58), "you[r] Views" (59), "These setting[s]" (61), "that what" (66; should read "than what"), "might for use" (67), "you would chose" (67), "the next sort criteria" (67; should read "the next sort criterion"), "by click[ing]" (74), "you are make" (85), and "have [to] click" (85). At this point, not even 8% of the way in, I stopped recording them — although an amusing one is worth mentioning: "gather shook information" (452). Lastly, how did "Drurpal.org" (854) make it past the spelling check? It turns out that the entire book is peppered with such errors, and that first batch was merely the beginning. It is difficult to believe that so many obvious errata could have made it through any professional copy editing process.

Readers who are following along, and likely using the latest version of Drupal (7.8 as of this writing), will notice some differences between what they see on their screens and what is shown in the book's screenshots — most if not all of which are based upon Drupal 7.0. This is especially noticeable in Chapter 3, which covers Views, a module affected by ongoing enhancement. For instance, Views exporter submodule (page 52) is now gone; "Access all views" (page 53) has been altered; "Display Status" (page 62) is gone; there are no broken link icons to indicate overrides; "views/edit" (in the URL, page 71) is now "views/view"; and the Fields configuration dialog (page 75) is different. Fortunately, none of these cases of obsolescence should have any impact on the value of the information as a whole.

On the positive side of the ledger, this book offers much to be commended. As with any worthwhile programming book, this one makes extensive use of code snippets and screenshots to illustrate concepts discussed. These appear to be correct, except in the flowchart of Figure 30-3, where the conditional symbol's arrows are missing values. The text contains some welcome humor (e.g., a kittens photo request, on page 43) and some apt phrases (e.g., Permission module's "wall of checkboxes", on page 156). Some of the chapters were written by the contrib module developers/maintainers, i.e., those who arguably know those modules best. This is unique among the growing list of Drupal books, in that it devotes entire chapters to topics neglected by its competitors — such as documentation, installation profiles, module porting, Drush, Git, and working profitably as a Drupal professional. Some of this information emphasizes the value of project management (both for your individual projects, and Drupal as a whole).

On balance, the pluses outweigh the minuses. The book has a lot of good information, and many of the problems stem from sloppy writing that should have been caught by the publisher's editing team. It may not be the best source for some key subject areas, such as security or site building options. But if you seek a sole source that offers more information in total, then this is your book. For some topics — such as upgrading Drupal, crafting and testing modules, building installation profiles, and the inner secrets of the menu system — it goes into far more detail than any other. Definitive Guide to Drupal 7 is an impressive attempt to be just that, and no other single book currently matches it.

Michael J. Ross is a freelance web developer and writer.

You can purchase Definitive Guide to Drupal 7 from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Michael J. Ross writes "Most computer and web programming books are written entirely by a single author, while the remaining are written by more authors, typically with each one tackling several chapters. The latter approach can suffer from redundant material undetected by editors, and inconsistency in the writing style from one chapter to the next. Yet it offers the significant advantage that the subject matter of each chapter can be presented by an authority on that topic — who can focus on making that explication the best possible, without the burden of completing an entire book. That was one of my first thoughts (and hopes) when hefting the 1112 pages and 4.1 pounds of the Definitive Guide to Drupal 7." Read on for the rest of Michael's review. Definitive Guide to Drupal 7 author A cast of thousands. pages 1112 pages publisher Apress rating 8/10 reviewer Michael J. Ross ISBN 978-1430231356 summary A wide-ranging exploration of the latest version of Drupal. This tome was published on 19 July 2011, under the ISBN 978-1430231356, by Apress (who kindly provided a review copy). As of this writing, it appears to be the longest Drupal book in existence — more than 400 pages longer than the nearest two contenders. Fortunately, no single author ended up in an insane asylum as a consequence of trying to write such an extensive work on his own. Rather, this book is largely due to the efforts of 34 writers in total — more specifically, 30 authors (listed on the front cover, roughly in descending order of how many of the pages they wrote) and four more contributors (added to the list on the title page). This may be a new record in technical book publishing. The entire authorial crew won't be listed here, but it should be mentioned that Benjamin Melançon was the lead author, and contributed to many of the chapters.

The book's material is organized into 38 chapters and nine appendices — all grouped into eight parts: Getting Started, Site Building Foundations, Making Your Life Easier, Front-End Development, Back-End Development, Advanced Site-Building Topics, Drupal Community, and Appendix. The chapter and appendix titles won't be listed here, but can be found on the publisher's book page, which also offers a description of the book, a section for reported errata (none as of this writing), links to purchase the print and electronic versions of the book, and a downloadable archive of the source code. Unfortunately, the code is apparently available only as a Git repository, and thus is inaccessible if you cannot — or do not want to — install Git on your computer. Consequently, it would be more difficult for such a reader to follow along and implement the example code while reading the book.

The authors have created their own website for the book, where visitors can sign up for e-mail notification of updates and free chapters, view a chapter outline (which features some bonus material), see author photos and bios, offer suggested changes for future editions, and learn of reported errata (three, at this time). Throughout the book, readers are told to access that site for additional information related to the chapters' topics; yet there does not appear to be any such information, even after registering a new account and logging in. This will be most disappointing in those cases where the reader is enticed by the promise of valuable information, only to find that it is absent. The authors state (page lv) that there are forums, one per chapter; but those do not yet exist. In general, there seems to be a huge disconnect between that website and the claims made in the book as to what extra material readers will find there.

The book begins with some introductory material, consisting of three mini-chapters: "What's New in Drupal 7" briefly describes some of the terrific improvements over version 6. "How to Use the Book" reassures the prospective reader that the book "does not presume any specific prior curriculum", although this seems inconsistent with the back cover's user level of "Intermediate-Advanced". Also, readers may be perplexed by the claim that the URL path admin/people/permissions/rules will go to admin/help (page lv). The last section, "How Drupal Works", oddly does not explain how Drupal works, but instead discusses some common terms and the typical phases of a website development project.

The first part of the book comprises two chapters, the first of which has the promising title of "Building a Drupal 7 Site", and provides a cursory summary of site planning, wireframing, Drupal installation, the Administration menu, the Shortcut toolbar, color schemes, and modules. The chapter continues with sections on content types, blocks, taxonomy, and other key concepts — all grouped under the chapter head "Allowing People to Register and Log in with OpenID", even though those topics are unrelated to OpenID. All of the chapter's topics are illustrated by stepping the reader through building, from scratch, the beginnings of the Drupal 7 website — namely, one similar to the authors' site mentioned earlier. Unfortunately, some of the instruction in the book does not match the actual website design, e.g., no introductory text (page 20). Readers may be amused by the tip on page 11, which refers to "the remaining 800 pages of the book". Perhaps the remaining 1101 pages can be chalked up to scope creep! The second chapter explains the basics of how to install and use Drush and Git, but not for Windows users. Readers should find the material instructive and consistent, except for the claim that Git is "easy(ish)" even though "getting the hang of Git [is] a lifelong learning process".

The half dozen chapters that compose Part II first introduce some of the most commonly-used Drupal modules, with extensive coverage of Views and later Organic Groups. A couple chapters explain how to keep one's site secure, partly by updating Drupal core and modules. The last chapter continues the development of the example site, using modules presented earlier. All of these chapters' narrative is valuable, although a couple pronouncements are too severe (e.g., "User input is evil", on page 127); but overall the advice is well warranted. Yet the chapter that will most likely aggravate readers is the eighth one. It seems to presume that the reader's test site was not affected by the exercises of the previous chapters, such as the Organic Groups. Secondly, some key information is incorrect, e.g., "Content: Image" (page 159) should be "Content: Headshot". Lastly, the authors refer to items not yet created as though they were, e.g., a "Table of Contents" menu link, an "Outline of Chapters" menu, and a "Twitter" field (pages 162-164). Unfortunately, the effects of all these problems compound, and, combined with the changes in Views since Drupal 7.0, make it increasingly difficult to follow along and implement the instructions.

Part III offers another half dozen chapters, in this case devoted to higher-level, less technical matters — specifically, how to: best participate in the Drupal community, plan and manage a Drupal-based project, craft effective documentation for your sites' end users and support staff, set up a workable Drupal development environment, launch and back up a new website, and stay sane while doing all of this. The information presented is worthwhile, with only a couple peculiarities: Firstly, why is the book organized so that some technical information is presented in the early chapters, as well as later chapters, while a group of "softer" topics are sandwiched in between? Secondly, for Chapter 12, why is the reader told, halfway through the chapter, that she will need "A computer able to connect to the Internet" and "An Internet connection" (page 233)? No one who has worked through the preceding dozen chapters needs to be reminded of this. Perhaps this chapter, on how to set up a development environment, should be made an appendix, as was the other installation and setup topics (Appendices F-I).

The next few chapters, Part IV, explore front-end development — namely, theming and jQuery. The first two chapters were penned by Jacine Luisi, who heads up the HTML5 initiative for Drupal 8. Readers learn about Drupal's core themes, theme engines, theme administration, metadata files, regions, layout, template files, global template variables, theme functions and hooks, preprocess and process functions, render arrays, theming forms, and more. The discussion is competent and thorough, as well as comprehensible, aside from the repeated use of the verb "print" to apparently mean "display". Chapter 17 demonstrates the use of JavaScript and jQuery in Drupal, and finishes by showing how to use jQuery UI to implement animations, such as accordions and progress bars.

Part V, "Back-End Development", comprises seven chapters that explain how to develop custom Drupal modules using the APIs. Because they provide an introduction to Drupal's system of hooks and overrides, they probably should have been located before the earlier chapters on theming, which rely upon those features of Drupal. Regardless, Chapters 18-20, by Benjamin Melançon, attempt to demystify the key topics in module development. Because this subject area is so critical to real-world Drupal development, and because the concepts can be quite intimidating to neophytes, any presentation of it must proceed at a reasonable pace, with clear explanation of how each aspect relates to the next. Like similar discussions in other Drupal books, this one begins quite approachable, but becomes more daunting, with a few places where readers will likely be perplexed — such as the hook_form_alter() discussion (page 411), which doesn't seem to match the resultant HTML. Yet this is such a challenging subject area that entire books have been devoted to it, and this one ventures into areas untouched by other books, such as how to create new database tables. Drupal coding standards are presented, although apparently not always followed in the example code (e.g., preceding internal function names with underscores). Part V is rounded out with chapters on porting modules to Drupal 7, writing "glue" modules, performing functional testing, and writing extendable/API modules.

Part VI, "Advanced Site-Building Topics", consists of ten chapters covering a variety of topics: building an online store using Commerce module (authored by the project's founder and lead, Ryan Szrama); Drush (which overlaps with Chapter 2); caching and storage mechanisms (MySQL and MongoDB); RDFa and the Semantic Web; Drupal's routing system; Drupal's internal operations for presenting a requested page; Solr module; UX enhancements in Drupal 7; completing the book's website; and Drupal distributions. All of the information and guidance appears correct, except for a couple problems: The instructions (page 568) to install Commerce Physical Product module, which does not have a Drupal 7 release, as of this writing, and certainly as of the book's publication date. Drune is a music player used as an example throughout Chapter 34, but its website, drune.org (pages 805 and 817), appears to be dead at this time.

Throughout this book, one will find a strong sense of community, with frequent encouragement for the reader to participate and contribute. This is evidenced by Part VII, which comprises four chapters that present: Drupal's history, how to make a living as a Drupal developer, how to maintain a contributed project, and further thoughts on how to contribute to the overall Drupal community. The book concludes with Part VIII, consisting of nine appendices, most of which focus on how to install Drupal on various platforms. This part is strangely titled "Appendix", yet contains multiple appendices (more scope creep?).

Given the somewhat stunning length of this book, its multitude of authors, and its wide coverage of most aspects of Drupal, it should be expected that the book has both strengths and weaknesses. Consider first that latter category. The authors and publisher should have sought ways to reduce the length of the book. For instance, the overview of PHP in Chapter 18 is not needed for this book's audience, and could be replaced by references to outside, more-detailed resources. The same is true of the section on Drupal coding standards. The book does not need to be made any longer than it already is, without good reason. Speaking of which, most of the longer chapters end with summaries, which are not worth the extra space taken up. Drupal's hook system is explained in at least three different chapters, and Git in two. The many authors should have been aware of this, had they been referencing the book's website, which was presumably built before the text describing it was written. Furthermore, the publisher and its chosen technical reviewers should have also spotted this.

The remarkably large number of authors is probably the primary reason for the book's noticeable unevenness, from one chapter to the next, in the quality of the writing — including the clarity of the explanations, which is arguably the most important factor. In a book written by advanced Drupal developers, it is to be expected that they will use Drupal-specific terminology. That is fine, but such terms should be defined at least once, before encountered by any readers unfamiliar with them. For instance, page xxxv alone mentions "d.o", "D8", and "contrib" — all meaningless to someone learning Drupal. There are places in the text where the descriptions do not match the corresponding screenshots (e.g., the "Required field" on page 18), and where, in the narrative, the lack of quotation marks around field labels makes it jarring and difficult to understand (e.g., throughout Chapter 8). There are some inconsistencies in spelling (e.g., "web site" and "website", even in the same sentence, on page lii), some inconsistencies in italicizing menu links (e.g., page 13), some misused phrases (e.g., "cannot be understated", on pages lix and 225, when "cannot be overstated" was called for), some baffling allusions (e.g., "aiee-the-alligator-is-going-to-get-me", on page 492), curly quotes in the code (e.g., pages 277 and 356-9), a repeated paragraph (page 507), an oxymoron ("libertarian communism"; xlvi), and the obligatory conflation of "depreciated" and "deprecated" (page 495) found in countless programming books.

This book contains numerous errata: "co-maintainer [f]or Drupal 7" (page xxxiv), "and." (xxxv), "bi-lingual" (xxxviii), "able [to] handle" (xlix), "don' think" (lv), "criteria[:] type" (lviii), "able [to] fill" (11), "th[r]ough the" (14), "an a" (19), "ask question questions" (29), "install [the] X-ray" (38), "You [] requests nuggets" (49), "you want to you" (56), "on [the] system" (57), "menu of option[s]" (57), "Rather [than] saving" (57), "menu(" (58), "you[r] Views" (59), "These setting[s]" (61), "that what" (66; should read "than what"), "might for use" (67), "you would chose" (67), "the next sort criteria" (67; should read "the next sort criterion"), "by click[ing]" (74), "you are make" (85), and "have [to] click" (85). At this point, not even 8% of the way in, I stopped recording them — although an amusing one is worth mentioning: "gather shook information" (452). Lastly, how did "Drurpal.org" (854) make it past the spelling check? It turns out that the entire book is peppered with such errors, and that first batch was merely the beginning. It is difficult to believe that so many obvious errata could have made it through any professional copy editing process.

Readers who are following along, and likely using the latest version of Drupal (7.8 as of this writing), will notice some differences between what they see on their screens and what is shown in the book's screenshots — most if not all of which are based upon Drupal 7.0. This is especially noticeable in Chapter 3, which covers Views, a module affected by ongoing enhancement. For instance, Views exporter submodule (page 52) is now gone; "Access all views" (page 53) has been altered; "Display Status" (page 62) is gone; there are no broken link icons to indicate overrides; "views/edit" (in the URL, page 71) is now "views/view"; and the Fields configuration dialog (page 75) is different. Fortunately, none of these cases of obsolescence should have any impact on the value of the information as a whole.

On the positive side of the ledger, this book offers much to be commended. As with any worthwhile programming book, this one makes extensive use of code snippets and screenshots to illustrate concepts discussed. These appear to be correct, except in the flowchart of Figure 30-3, where the conditional symbol's arrows are missing values. The text contains some welcome humor (e.g., a kittens photo request, on page 43) and some apt phrases (e.g., Permission module's "wall of checkboxes", on page 156). Some of the chapters were written by the contrib module developers/maintainers, i.e., those who arguably know those modules best. This is unique among the growing list of Drupal books, in that it devotes entire chapters to topics neglected by its competitors — such as documentation, installation profiles, module porting, Drush, Git, and working profitably as a Drupal professional. Some of this information emphasizes the value of project management (both for your individual projects, and Drupal as a whole).

On balance, the pluses outweigh the minuses. The book has a lot of good information, and many of the problems stem from sloppy writing that should have been caught by the publisher's editing team. It may not be the best source for some key subject areas, such as security or site building options. But if you seek a sole source that offers more information in total, then this is your book. For some topics — such as upgrading Drupal, crafting and testing modules, building installation profiles, and the inner secrets of the menu system — it goes into far more detail than any other. Definitive Guide to Drupal 7 is an impressive attempt to be just that, and no other single book currently matches it.

Michael J. Ross is a freelance web developer and writer.

You can purchase Definitive Guide to Drupal 7 from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Hummdis writes "After more than a month of being offline due to a security breach at Kernel.org, they're back! While they were down, they took the time to 're-architect' the site for developers and users. A statement reads: 'As noted previously, kernel.org suffered a security breach. Because of this, we have taken the time to re-architect the site in order to improve our systems for developers and users of kernel.org. To this end, we would like all developers who previously had access to kernel.org who wish to continue to use it to host their git and static content, to follow the instructions here. Right now, www.kernel.org and git.kernel.org have been brought back online. All developer git trees have been removed from git.kernel.org and will be added back as the relevant developers regain access to the system. Thanks to all for your patience and understanding during our outage and please bear with us as we bring up the different kernel.org systems over the next few weeks. We will be writing up a report on the incident in the future.'"

An anonymous reader writes "Facebook is once again setting its datr cookie via the Like button and other social plugins on third-party websites. The datr cookie can be used for tracking users whether you are logged in or logged out of the service. Facebook has confirmed this is indeed a bug, but says that it is limited in scope and that it will be fixed today. Talk about damage control."

pafein writes "Hacktivist cluster Telecomix released 54 gigabytes of Syrian censorship log data. The anonymized log data was collected from seven of 15 Bluecoat SG-9000 HTTP proxies used by Syrian government telco and ISP STE. Preliminary analysis revealed such keywords as proxy and Israel were blocked. And of course, much porn. The data set provides a unique look at Internet censorship from the inside. Internauts who enjoy regexes and charts are invited to help make a pretty infographic. Telecomix's #opsyria has been fighting censorship and facilitating communications [note: French language link] in Syria for the past few weeks, providing TOR, VPNs and technical advice and support via IRC. They've also been providing DNS service for The Pirate Bay."

mikejuk writes "Bletchley Park has secured a £4.6 million Heritage Lottery Fund Grant for the establishment of a visitor center dedicated to the World War II Codebreakers. This year saw the unveiling of a new memorial to the Codebreakers in the grounds of Bletchley Park by the Queen. Shortly after her visit, a new fundraising campaign for the restoration of the iconic huts where the code-breaking teams worked was inaugurated, with help and sponsorship from Google. The grant will enable the restoration of Codebreaking Huts 1, 3 and 6, and create a world-class visitor center and exhibition in the currently derelict Block C. The Bletchley Park Trust has launched the 'Action This Day' campaign to raise the match funding now needed."

An anonymous reader writes "Government contractor SAIC just can't seem to get a break. Still fresh off of the Citytime scandal, they've now had a data breach in which backup tapes holding 4.9 million personal health records were stolen from an employee's car. To add insult to injury, evidently the tapes were not encrypted either: 'Tricare did not indicate whether SAIC encrypted the information on the stolen tapes, but Raley said, "It's very hard to encrypt a backup tape."'"

First time accepted submitter Gastrobot writes "Stanford University is offering some computer science classes for free. This has been discussed here twice before. The classes begin on Oct. 10th. At this point in time I'm aware of Stanford offering an Intro to Databases course, an Intro to AI course, and a Machine Learning course."

First time accepted submitter Gastrobot writes "Stanford University is offering some computer science classes for free. This has been discussed here twice before. The classes begin on Oct. 10th. At this point in time I'm aware of Stanford offering an Intro to Databases course, an Intro to AI course, and a Machine Learning course."

He's Canadian, he's proven himself a successful comedic actor and writer, filmmaker, and musician, but (no matter what else he does) in many people's minds he will always be James Tiberius Kirk, captain of the USS Enterprise. Now, William Shatner has agreed to answer your questions. We'll pass on to him a selection of the best reader questions; you might want to read up on Shatner's official home page (and the Wikipedia link above) to knock out some of the most obvious ones. We'll pass on to him a selection of the best questions. Note: it's tempting to pile them on, but please try to follow the interview question guidelines by posting one question per post — ask as many questions as you'd like, though. Shatner is on vacation right now, but will work on answering your questions when he gets back.

jfruhlinger writes "Nokia's announcement that it was developing a Linux distro for low-end smartphones, shortly after abandoning the Linux-based Meego OS for Windows Phone 7, was a little puzzling. But it actually makes good business sense in the smartphone world. While WP7 aims for the high end, there's a market for cheaper and less complex phones that still beat boring old feature phones, especially in emerging economies. And, unlike Symbian and the heavily tweaked Meego, Linux can be quickly and cheaply brought to market as a low-end smartphone OS."

First time accepted submitter recrudescence writes "Slashdot readers might remember the Touchbook announcement from Always Innovating stirring up a lot of excitement in the Slashdot community back in 2009 (almost a year before the iPad was announced and essentially killed this off, and way before the Asus Transformer, which is essentially the same idea). The company's new product seems to support Hot multi-OS switching, supposedly with a minimal performance penalty. What seems strange to me is, why haven't other developers jumped in on this already? Macs, for instance, made a huge campaign of their products' new ability to finally support Microsoft Windows, yet (disregarding emulation options) they're still limited to booting to a single working system at any time."

jfruhlinger writes "Much of the initial reaction to Amazon's Silk browser was interest in how it uses the cloud to speed up browsing. But at what cost? There are privacy concerns, of course, as Amazon will have a record of your browsing; but in a larger philosophical sense, Silk is of a piece with Facebook and Apple's iOS walled garden, an intermediary between you and the Internet."

theodp writes "Google is following in the footsteps of Apple and Microsoft. The London Evening Standard reports that the world's first 'Google Store' has opened in a PC World on London's gadget street, Tottenham Court Road. Officially known as 'the Chromezone,' the 285sq. ft. pop-up 'shop within a shop,' which only sells Google's Chromebook laptop and a few accessories such as headphones, will run for three months up to Christmas. But if the low-key experiment is successful, Google could follow Apple in opening permanent stores around the world. 'It is our first foray into physical retail,' said Google's Arvind Desikan. 'This is a new channel for us and it's still very, very early days. It's something Google is going to play with and see where it leads.'"

sydneyhype writes "Facebook's recently announced Timeline feature is up against legal action from an online social-scrapbooking company that has been in business since 2008. The company, Timelines.com, filed a trademark-infringement suit yesterday against Facebook, claiming it is to prevent being 'rolled over and quite possibly eliminated by the unlawful action by the world's largest and most powerful social-media company, Facebook.'"

tekgoblin writes "AT&T has started tossing out warnings for users that fall into the top 5% of data users on their wireless network. AT&T announced this change back in July and is now starting to actually enforce it."

New submitter quax writes "Michael Nielsen, who co-authored the book on Quantum Computing, released a set of short video lectures on his blog this summer (link to Google cache). They make a great introduction to the subject. But here's the catch: Due to other work responsibilities, he stopped short of completing the course, and will only complete it if he sees enough interest in the videos. Let's show him some numbers."

hackingbear writes with an article from Reuters about Foxconn's plans to move iPad production to Brazil. From the article: "A much-hyped $12 billion plan for Taiwanese manufacturer Foxconn to produce iPads in Brazil, announced in April by President Dilma Rousseff during an official visit to China, is 'in doubt' due to stagnant negotiations over tax breaks and Brazil's own deep structural problems such as a lack of skilled labor and bad infrastructure, government sources tell Reuters. '(Foxconn) is making crazy demands' for tax breaks and other special treatment, the official added. Local media have reported that Foxconn is also seeking priority treatment at Brazilian customs, which is notoriously slow even by the standards of emerging markets."

jfruhlinger writes "One of Oracle's stated purposes when it bought Sun more than two years ago was to create full-stack appliances: SPARC servers running Solaris or Oracle Linux and Oracle's suite of app servers and of course its omnipresent database. Its new T4 processor is a reaffirmation of that strategy. But has the company painted itself into a corner? While it's cautiously embraced the cloud, its cloud services don't work with Windows or other companies' offerings, which kills much of their potential value; meanwhile, they've managed to alienate open source developers and big swaths of the Java community. It seems that Oracle's inability to play well with others is locking them out of the multipolar future."

jfruhlinger writes "One of Oracle's stated purposes when it bought Sun more than two years ago was to create full-stack appliances: SPARC servers running Solaris or Oracle Linux and Oracle's suite of app servers and of course its omnipresent database. Its new T4 processor is a reaffirmation of that strategy. But has the company painted itself into a corner? While it's cautiously embraced the cloud, its cloud services don't work with Windows or other companies' offerings, which kills much of their potential value; meanwhile, they've managed to alienate open source developers and big swaths of the Java community. It seems that Oracle's inability to play well with others is locking them out of the multipolar future."

Back in 1982, John Flansburgh, John Linnell, and a drum machine formed They Might Be Giants. Over the last 29 years TMBG have released 15 studio albums, won 2 Grammy Awards, and have become one of the most nerd-loved bands ever. In addition to projects like Dial-A-Song, TMBG were one of the first bands to create their own online music store, and have been making podcasts on a semi-monthly basis since 2005. The band has agreed to answer all your questions about the naming conventions of Turkish cities, building spiritual bird houses, and the music business. As usual, ask as many questions as you'd like, but please keep it to one question per post.

An anonymous reader tips news that Mozilla has released the beta version of Firefox 8, only a few days after going live with the final version of Firefox 7. According to the announcement, the big changes this time around include the ability to use Twitter as a default search engine, more versatility in restoring tabs on startup, and improved user control over add-ons. "Users will receive a one-time notification to review and confirm third party add-ons they want to keep, disable or delete. When Firefox starts and finds that a third-party program has installed an add-on, Firefox will disable the add-on until the user has explicitly opted in, giving users better control over their Web experience."

An anonymous reader writes "Boston Dynamics, the company that created the BigDog quadruped robot, has unveiled a new, bigger system called AlphaDog. AlphaDog, a DARPA-sponsored project, can carry a payload of 400 pounds for up to 20 miles without having to refuel, and it's also much quieter than BigDog. The robot is designed to assist humans in carrying heavy equipment over rough terrain, and Boston Dynamics' schedule has the first walk-out of AlphaDog taking place sometime in 2012, when U.S. Marines will begin to put the robot to the test for real."

snydeq writes "Despite early successes on the Web, the latter years of Flash have been a tale of missed opportunities, writes Fatal Exception's Neil McAllister. 'The bigger picture — which I've touched on before — is that major platform vendors are increasingly encouraging developers to create rich applications not to be delivered via the browser, but as native, platform-based apps. That's long been the case on iOS and other smartphone platforms, and now it's starting to be the norm on Windows. Each step of the way, Adobe is getting left behind,' McAllister writes. 'Perhaps Adobe's biggest problem, however, is that it's something of a relic as developer-oriented vendors go. How many people have access to the Flash runtime is almost a moot point, because Adobe doesn't make any money from the runtime directly; it gives it away for free. Adobe makes its money from selling developer tools. Given the rich supply of free, open source developer tools available today, vendors like that are few and far between. Remember Borland? Or Watcom?'"

itwbennett writes "The patent licensing agreement between Microsoft and Samsung this week set off a firestorm of childish tit-for-tat between Microsoft and Google. But more telling is what Samsung had to say about its relationship with Google: 'Samsung knows it can't rely on Google. We've decided to address Android IP issues on our own,' a Samsung official told The Korea Times. The only good news to come from all of this, says blogger Brian Proffitt, is that we may be headed for a courtroom showdown over just what patents Microsoft believes are in violation, which really is what should have happened to begin with." Update: 09/30 20:05 GMT by S : As it turns out, the so-called "Samsung official" cited by The Korea Times turned out to be patent blogger Florian Mueller.

Trailrunner7 writes "Earlier this week, Microsoft released an announcement about the disruption of the Kelihos botnet that was responsible for spam messages, theft of sensitive financial information, pump-and-dump stock scams, and distributed denial-of-service attacks. The botnet had a complex, multi-tiered architecture as well as a custom communication protocol and three-level encryption. Kaspersky Lab researchers did the heavy lifting, reversing the protocol and cracking the encryption and then sink-holing the botnet. The company worked closely with Microsoft's Digital Crimes Unit (DCU), sharing the relevant information and providing them with access to our live botnet tracking system."

m.ducharme writes "Slashdot's recently departed editor and Fearless Leader muses about the security implications of Amazon's Silk, which uses Amazon's massive cloud computing services to provide 'pre-caching' for the new Fire devices." Another potential downside to bear in mind (depending on exactly how much Silk relies on the AWS infrastructure) is that it provides a single point of failure, and sometimes cloud services go down.

m.ducharme writes "Slashdot's recently departed editor and Fearless Leader muses about the security implications of Amazon's Silk, which uses Amazon's massive cloud computing services to provide 'pre-caching' for the new Fire devices." Another potential downside to bear in mind (depending on exactly how much Silk relies on the AWS infrastructure) is that it provides a single point of failure, and sometimes cloud services go down.

m.ducharme writes "Slashdot's recently departed editor and Fearless Leader muses about the security implications of Amazon's Silk, which uses Amazon's massive cloud computing services to provide 'pre-caching' for the new Fire devices." Another potential downside to bear in mind (depending on exactly how much Silk relies on the AWS infrastructure) is that it provides a single point of failure, and sometimes cloud services go down.