I grew up in Porsgrunn, Norway, a city which had two such cable transport systems:
Both of them were used to transport limestone, the largest one moved the output north from the Kjørholt mines to the Hydro fertilizer factory on Herøya. It passed over several ravines and steep cliff faces and ran for decades with very little maintenance, although the amount of limestone rock underneath it, as well as the occasional lost carrier wagon laying on the ground showed that it would probably not be safe to climb up and hitch a ride in one of the (empty) returning wagons.
(I do remember being very tempted though, despite the warning signs and barbed wire wrapped around the supporting pylons!)
On this sat image you can easily see the remains of the system, in the form of the totally straight road "Gravavegen" and the four concrete supports which held a pylon where the system crossed the small bay "Versvika".
The other cable system ran more or less in parallel with the first, starting from an open quarry about 5 km east of the fertilizer factory and going south to the Norcem cement factory which also needed limestone as a raw material.
This one is much harder to locate on sat images, the most obvious sign is this wide stripe in the forest:
Intel needs AMD really badly, the only thing that keeps Intel out of monopoly charges is that they can point to AMD and say, with full honesty:
"See, the x86 marketplace is really competitive, the one time we tried to do something about it (Itanium) it backfired badly when AMD invented the x64 extensions."
My daughter has dual (US/Norwegian) citizenship, she is currently applying to both US and Norwegian colleges.
She's a _very_ avid reader (~200 books/year, most of them from the main branch of the Oslo public library), so when Berkeley asks for the books she has read during the last year (3/6 months?) there's no way she can fit the list into the given number of words, right?
By trial and error she discovered that using a colon (:) as the separator between author and title would not count as a word separator, unlike a space, a comma, or a dash.
To me it seems pretty obvious that the only logical endpoint of all this security theater is to require all passengers to go nude through security, with zero carry-on luggage.
Body cavity search and/or full x-rays are optional (to the TSA, not you).
After the checkpoint you might be given a robe or towel, in order to reduce the need for cleaning the airline seats between each flight.
The key difference between this research chip and the other Multicore chips Intel have worked on, like Larrabee, is that it is explicitly NOT cache coherent, i.e. it is a cluster on chip instead of a single-image multi-processor.
This means, among many other things, that you cannot load a single Linux OS across all the cores, you need a separate executive on every core.
Shortly after 9/11 (Oct/Nov 2001 in fact) I took my family on a vacation trip from Norway to the US, to go on a cruise from Miami.
We flew Oslo-Copenhagen-Chicago-Miami and the same way back on the return trip.
There are four of us, our kids were 12 and 10 at the time, and for some very strange reason our youngest was flagged (with "SSSS" on her boarding card) for extra security checks on all the US airports.
The M16-toting National Guard got really upset when I wanted to accompany my kid, but finally relented when I explained that she didn't speak english.
This paper is really about how it is still possible to fingerprint CPUs, even without using the non-privileged CPUID instruction.
First of all, they state that using CPUID might trigger behavioral malware scanners/detectors.
Well, guess what: More or less every single program out there contains at least one CPUID instance somewhere in the runtime library code, some of them in order to avoid known bugs (like the Pentium FDIV case), and some in order to determine which forms of SIMD instructions are available (x87 vs SSE, scalar vs MMX/SSE/SSE2/SSE3/SSSE3/SSE4 etc.
Secondly, before CPUID turned up around the 486/Pentium changeover we used exactly the same kind of fingerprinting code to determine cpu versions: 8088/8086/80186/80286/386/486.
Some of them were based on known bugs (i.e. an 808x would not disable interrupts for the instruction following a segment register load), some on the handling of undocumented opcode sequences, like an ascii arithmetic instruction with the decimal constant replaced by another value, and some on the varying length of the instruction prefetch buffer.
Finally, the specific example they use early on (calculating square roots) is totally broken: Square root is one of the core functions in IEEE 754 arithmetic, which means that every single cpu has to generate the same result for all possible inputs, said result being the exact answer rounded correctly according to the current rounding mode and final precision (float/double).
The somewhat better example later in their paper uses trancendental functions, which is a much better choice since they do tend to change between processor families and sometimes even between different versions from the same vendor.
One measure of town-ness is the amount of normal "town" infrastructure you can find there.
In Longyearbyen you have schools, from kindergarten all the way to university, a church, several sporting goods stores (best selection I have ever seen in cold weather gear!), parking lots (both cars and snowmobiles), a police station, a hospital etc.
The most important thing missing is probably a regular maternity clinic: Any pregnant woman have to fly to the mainland well before their baby is due.
I've been called many things in my life, "a complete and total tool" is a first!:-)
I guess I should have said something more about the use of alternative light sources:
I do of course realize that both compact and traditional FLs require more resources to produce than old style bulbs. For 12V halogen lights it is probably the opposite, since each light source is so much smaller and therefore needs less raw materials and cost much less to transport.
The most important consideration here is the huge difference in lifetime: Incandescent bulbs have to be replaced far more often.
LED lights are somewhat problematic since they require raw materials which are (afaik) in short supply, but the additional factor of 2-3 in lifetime means that I don't have to throw away used bulbs nearly as often.
(BTW, since I started that replacement program, I have also started to turn off the lights at night: With IBs it really didn't save any energy to do so as long as a single thermostat-controlled electric heater was active. I do so now in order to increase the lifetime of the light sources, not to save energy.)
Power from hydro-electric plants have traditionally been quite inexpensive here in Norway, it is only over the last 10 years or so that we've gotten to the point where other forms of heating (particularly heat pumps) have started to become really attractive.
(BTW, since we have no domestic gas grid, we instead sell all our North Sea gas to Britain, Germany, Holland and other EU countries.)
We need some form of home heating maybe 8-9 months a year, so it made perfect sense to me to leave more or less all electric lights on all day, except in the middle of summer when it doesn't really get very dark at all.
Ten years ago I started to replace old bulbs with more energy-efficient alternatives like halogen, these days I put in LED instead.
For a new house we're having built we've decided on using very energy-efficient construction (25 cm/10") wall isolation, (35 cm/14") roof isolation, top grade glass and a balanced ventilation setup with a heat exchanger.
BTW, this is just a small step above the latest legislated minimum requirements for new homes in this country.
15+ years ago I started exactly such a team for my then employer (Hydro, Norway's second largest corporation), I ran it until Hydro was split into multiple independent units, some of them sold off.
They way I set it up was to pick one or two top guys from each of the crucial departments (LAN/WAN/FW, Oracle & MSSQL dbs, Java, C#/.Net, C(++) developers, Unix & Win* admins, etc.).
Each of these departments got the money to hire some extra help, in return I could grab any of the required people for a specific assignment with 2 hours warning. From then on we'd all work on nothing else beside the current task.
I had one requirement for the group (business unit/division) that declared such an emergency: They had to designate one person to work with my team full time, and that person would have authority to accept any kind of change in the project, both technical and economic.
This requirement alone reduced the number of "emergencies" by 75%.:-)
So how did it work?
Pretty good actually: With a total of more than 100 such projects over a 15-year period, we had just two failures.
The key message she had was that she was sick & tired of the way NRK have been abusing their temp worker setup:
Call them in with very short notice, at any time of day or night, for the maximum time period allowed before a temp worker automatically gains full employment (i.e. 4 years), then fire them.
GPS is the canonical answer here, but not in the form you use in your car or while hiking.
Instead they use the same setup as a surveyor who measures a piece of land:
You have one stationary receiver (the Base station) and one that you move around to measure (the Rover), while a radio link sends information from the base station to the rover.
By observation of the same set of satellites from two points you can lock on to the 1.5 GHz (20 cm wave length) carrier wave, this gives you ~10mm or better resolution within a short time.
For plate tectonics you do the same, but over significantly longer time periods to compensate for the much larger offsets between the two stations.
Before GPS you could do similar stuff with radio telescopes observing pulsars (Very Long Baseline Interferometry), but you still need very carefully synchronized clocks at the two sites, and these days GPS is used for that (i.e. clock sync) as well!
This is one of many, many attempts to make the problem seem to go away, unfortunately enough their choice of 1000 seconds for the smoothing period is close to the worst possible: 1 second in 1000 is 1000 parts per million or 1000 ppm.
NTP has a maximum slewing rate of 500 ppm or half a second every 1000 seconds, so if your NTP upstream server was to start such an adjustment period, every single connected client would drop out of sync and be forced to do several steps each time the offset got above 128 ms.:-(
To make this work every single computer clock would need to be updated, while all the national radio standards, like the German 77,5 MHz transmitter, would have to disregard the new standard because the radio receivers would be unable to track it when it started the adjustment period.
You are totally right: The LI (Lawful Intercept) interface is a required part of all relevant telecomms standards, i.e. you cannot manufacture/sell a GSM/3G/LTE setup which doesn't have that LI interface.
Terje (Currently working on the architecture of a large national cell phone network.)
I've worked with NTP for nearly 20 years now, and the leap second adjustments isn't a real problem.
The crux of the matter is that we've insisted (in both Unix and Windows) on measuring calendar events in seconds:
The proper solution is to use Julian Day Number as the basic unit for calendars and (SI) seconds for any kind of short-term measurement. If you really need second/sub-second precision for long-term (multi-day) measurements, then you have to accept that the conversion is not just a matter of multiplying/dividing by 86400.
Calendar appointments and similar things should be defined by day number and some form of fractional day, not SI seconds.
NTP is somewhat to blame though: Even though it has full support for leap second handling (both adding and subtracting), the core of the protocol pretends that UTC seconds (without leap adjustments) is sufficient, i.e. NTP timestamps are defined to be in a 64-bit fixed-point format with 32 bits counting seconds since 1900-01-01 and 32 bit for the fractional seconds, i.e. sufficient to handle a 136-year block with a quarter of a ns resolution.
This causes small hiccups for an hour or so after each adjustment: The primary servers and those that either have a leap-second aware source or a cluefull operator keep in sync throughout the adjustment, while the remainder will slowly detect that their local clocks seems to be a full second off. Since this is way more than the default +/- 128 ms which NTP is willing to handle with gradual adjustments, NTPD will instead step the clock (backwards for an added leap second) and restart the protocol engine, after discarding all history.
Modern versions of NTP have been rewritten to use a vote between all otherwise good servers: If a majority claim that there will be a leap second at the end of the current day, then the local deamon will believe them, and thereby stay in sync even during the actual leap second itself.
No warrants have ever been served to rsync.net, or rsync.net principals or employees. No searches or seizures of any kind have ever been performed on rsync.net assets, including:
ALL San Diego locations ALL Denver locations ALL Zurich locations ALL Hong Kong locations
(from www.NewYorkTimes.com)
In Crackdown on Energy Use, China to Shut 2,000 Factories
By closing some steel mills, cement works and other energy-intensive factories, the government said it hoped to improve energy efficiency. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD)
Tournament results is what ELO really tries to predict, and there you are absolutely correct, i.e. everyone plays both White and Black equally often.
However, the current challenge is NOT to predict how well each player is going to do in the aggregate, but to minimize the error for each individual game. THIS IS CRUCIAL!
I.e. the error term is the RMS of the difference between the predicted and actual result for each individual game, not the sum of the normal pair of games against each competitor. ELO otoh is really trying to predict the result of the pair of games, not each of them individually, since it is the sum which correlates with the final result.
Simply biasing the ELO-prediction by something like +/-5% depending upon White/Black would correct for the known advantage of playing White.
The differences are indeed quite small, but it seems obvious that you should be able to do better than ELO by splitting it into two parts:
Games played as White and games played as Black.
In fact, this seems so obvious that I suspect there's something I have overlooked!:-)
As the contest site mentions, there's a very significant advantage to White, enough so that in their training data set White has 30+% win vs 20+% for Black.
I suggest that taking the normal ELO-predicted outcome and then biasing it according to this known historical trend, would have to result in slightly better predictions than the naked ELO number.
Slashdot Mirror
I was surprised to see that nobody had made the connection to Heinlein's wonderful short story, "The Long Watch".
The main parallel would be the willingness to submit oneself to dangerous or even fatal radiation levels in order to prevent a disaster.
Terje
I grew up in Porsgrunn, Norway, a city which had two such cable transport systems:
Both of them were used to transport limestone, the largest one moved the output north from the Kjørholt mines to the Hydro fertilizer factory on Herøya. It passed over several ravines and steep cliff faces and ran for decades with very little maintenance, although the amount of limestone rock underneath it, as well as the occasional lost carrier wagon laying on the ground showed that it would probably not be safe to climb up and hitch a ride in one of the (empty) returning wagons.
(I do remember being very tempted though, despite the warning signs and barbed wire wrapped around the supporting pylons!)
On this sat image you can easily see the remains of the system, in the form of the totally straight road "Gravavegen" and the four concrete supports which held a pylon where the system crossed the small bay "Versvika".
The other cable system ran more or less in parallel with the first, starting from an open quarry about 5 km east of the fertilizer factory and going south to the Norcem cement factory which also needed limestone as a raw material.
This one is much harder to locate on sat images, the most obvious sign is this wide stripe in the forest:
Norcem
Terje
Sorry about the title typo. :-(
Intel needs AMD really badly, the only thing that keeps Intel out of monopoly charges is that they can point to AMD and say, with full honesty:
"See, the x86 marketplace is really competitive, the one time we tried to do something about it (Itanium) it backfired badly when AMD invented the x64 extensions."
Terje
Are you forgetting that 2010 was the year Magnus Carlsen became the youngest ever FIDE top-rated chess player in the world?
http://en.wikipedia.org/wiki/Magnus_Carlsen
This did happen in January, so you could be forgiven for not remembering so far back. :-)
Terje
My daughter has dual (US/Norwegian) citizenship, she is currently applying to both US and Norwegian colleges.
She's a _very_ avid reader (~200 books/year, most of them from the main branch of the Oslo public library), so when Berkeley asks for the books she has read during the last year (3/6 months?) there's no way she can fit the list into the given number of words, right?
By trial and error she discovered that using a colon (:) as the separator between author and title would not count as a word separator, unlike a space, a comma, or a dash.
Terje
To me it seems pretty obvious that the only logical endpoint of all this security theater is to require all passengers to go nude through security, with zero carry-on luggage.
Body cavity search and/or full x-rays are optional (to the TSA, not you).
After the checkpoint you might be given a robe or towel, in order to reduce the need for cleaning the airline seats between each flight.
Terje
The key difference between this research chip and the other Multicore chips Intel have worked on, like Larrabee, is that it is explicitly NOT cache coherent, i.e. it is a cluster on chip instead of a single-image multi-processor.
This means, among many other things, that you cannot load a single Linux OS across all the cores, you need a separate executive on every core.
Compare this with the 7-8 Cell cores in a PS3.
Terje
Shortly after 9/11 (Oct/Nov 2001 in fact) I took my family on a vacation trip from Norway to the US, to go on a cruise from Miami.
We flew Oslo-Copenhagen-Chicago-Miami and the same way back on the return trip.
There are four of us, our kids were 12 and 10 at the time, and for some very strange reason our youngest was flagged (with "SSSS" on her boarding card) for extra security checks on all the US airports.
The M16-toting National Guard got really upset when I wanted to accompany my kid, but finally relented when I explained that she didn't speak english.
Terje
This paper is really about how it is still possible to fingerprint CPUs, even without using the non-privileged CPUID instruction.
First of all, they state that using CPUID might trigger behavioral malware scanners/detectors.
Well, guess what: More or less every single program out there contains at least one CPUID instance somewhere in the runtime library code, some of them in order to avoid known bugs (like the Pentium FDIV case), and some in order to determine which forms of SIMD instructions are available (x87 vs SSE, scalar vs MMX/SSE/SSE2/SSE3/SSSE3/SSE4 etc.
Secondly, before CPUID turned up around the 486/Pentium changeover we used exactly the same kind of fingerprinting code to determine cpu versions: 8088/8086/80186/80286/386/486.
Some of them were based on known bugs (i.e. an 808x would not disable interrupts for the instruction following a segment register load), some on the handling of undocumented opcode sequences, like an ascii arithmetic instruction with the decimal constant replaced by another value, and some on the varying length of the instruction prefetch buffer.
Finally, the specific example they use early on (calculating square roots) is totally broken: Square root is one of the core functions in IEEE 754 arithmetic, which means that every single cpu has to generate the same result for all possible inputs, said result being the exact answer rounded correctly according to the current rounding mode and final precision (float/double).
The somewhat better example later in their paper uses trancendental functions, which is a much better choice since they do tend to change between processor families and sometimes even between different versions from the same vendor.
Terje
One measure of town-ness is the amount of normal "town" infrastructure you can find there.
In Longyearbyen you have schools, from kindergarten all the way to university, a church, several sporting goods stores (best selection I have ever seen in cold weather gear!), parking lots (both cars and snowmobiles), a police station, a hospital etc.
The most important thing missing is probably a regular maternity clinic: Any pregnant woman have to fly to the mainland well before their baby is due.
Terje
I've been called many things in my life, "a complete and total tool" is a first! :-)
I guess I should have said something more about the use of alternative light sources:
I do of course realize that both compact and traditional FLs require more resources to produce than old style bulbs. For 12V halogen lights it is probably the opposite, since each light source is so much smaller and therefore needs less raw materials and cost much less to transport.
The most important consideration here is the huge difference in lifetime: Incandescent bulbs have to be replaced far more often.
LED lights are somewhat problematic since they require raw materials which are (afaik) in short supply, but the additional factor of 2-3 in lifetime means that I don't have to throw away used bulbs nearly as often.
(BTW, since I started that replacement program, I have also started to turn off the lights at night: With IBs it really didn't save any energy to do so as long as a single thermostat-controlled electric heater was active. I do so now in order to increase the lifetime of the light sources, not to save energy.)
OK?
Terje
Power from hydro-electric plants have traditionally been quite inexpensive here in Norway, it is only over the last 10 years or so that we've gotten to the point where other forms of heating (particularly heat pumps) have started to become really attractive.
(BTW, since we have no domestic gas grid, we instead sell all our North Sea gas to Britain, Germany, Holland and other EU countries.)
We need some form of home heating maybe 8-9 months a year, so it made perfect sense to me to leave more or less all electric lights on all day, except in the middle of summer when it doesn't really get very dark at all.
Ten years ago I started to replace old bulbs with more energy-efficient alternatives like halogen, these days I put in LED instead.
For a new house we're having built we've decided on using very energy-efficient construction (25 cm/10") wall isolation, (35 cm/14") roof isolation, top grade glass and a balanced ventilation setup with a heat exchanger.
BTW, this is just a small step above the latest legislated minimum requirements for new homes in this country.
Terje
15+ years ago I started exactly such a team for my then employer (Hydro, Norway's second largest corporation), I ran it until Hydro was split into multiple independent units, some of them sold off.
They way I set it up was to pick one or two top guys from each of the crucial departments (LAN/WAN/FW, Oracle & MSSQL dbs, Java, C#/.Net, C(++) developers, Unix & Win* admins, etc.).
Each of these departments got the money to hire some extra help, in return I could grab any of the required people for a specific assignment with 2 hours warning. From then on we'd all work on nothing else beside the current task.
I had one requirement for the group (business unit/division) that declared such an emergency: They had to designate one person to work with my team full time, and that person would have authority to accept any kind of change in the project, both technical and economic.
This requirement alone reduced the number of "emergencies" by 75%. :-)
So how did it work?
Pretty good actually: With a total of more than 100 such projects over a 15-year period, we had just two failures.
Terje
That's actually a very good translation!
The key message she had was that she was sick & tired of the way NRK have been abusing their temp worker setup:
Call them in with very short notice, at any time of day or night, for the maximum time period allowed before a temp worker automatically gains full employment (i.e. 4 years), then fire them.
Terje
(from Oslo, Norway)
Since I first learned to swim, I've always felt that moving around in a 3D environment under water is similar to flying.
Snorkeling on a reef is _very_ similar imho.
Terje
I guess I'm a counterexample then:
I'm 53.
I believe (hope?) most people who know me would say that I'm still a pretty good programmer.
Terje
GPS is the canonical answer here, but not in the form you use in your car or while hiking.
Instead they use the same setup as a surveyor who measures a piece of land:
You have one stationary receiver (the Base station) and one that you move around to measure (the Rover), while a radio link sends information from the base station to the rover.
By observation of the same set of satellites from two points you can lock on to the 1.5 GHz (20 cm wave length) carrier wave, this gives you ~10mm or better resolution within a short time.
For plate tectonics you do the same, but over significantly longer time periods to compensate for the much larger offsets between the two stations.
Before GPS you could do similar stuff with radio telescopes observing pulsars (Very Long Baseline Interferometry), but you still need very carefully synchronized clocks at the two sites, and these days GPS is used for that (i.e. clock sync) as well!
Terje
On Danish and Norwegian keyboards we have a dedicated key for it, along with Ø and Å.
BTW, the US insurance company Aetna used to be spelled Ætna afaik.
Terje
PS. Ætna is an old Norse/Icelandic word, I found the following link to an icelandic definition: http://snara.is/s4.aspx?sw=tna+&dbid=&%23205;slenska&action=search
This is one of many, many attempts to make the problem seem to go away, unfortunately enough their choice of 1000 seconds for the smoothing period is close to the worst possible: 1 second in 1000 is 1000 parts per million or 1000 ppm.
NTP has a maximum slewing rate of 500 ppm or half a second every 1000 seconds, so if your NTP upstream server was to start such an adjustment period, every single connected client would drop out of sync and be forced to do several steps each time the offset got above 128 ms. :-(
To make this work every single computer clock would need to be updated, while all the national radio standards, like the German 77,5 MHz transmitter, would have to disregard the new standard because the radio receivers would be unable to track it when it started the adjustment period.
Terje
You are totally right: The LI (Lawful Intercept) interface is a required part of all relevant telecomms standards, i.e. you cannot manufacture/sell a GSM/3G/LTE setup which doesn't have that LI interface.
Terje
(Currently working on the architecture of a large national cell phone network.)
I've worked with NTP for nearly 20 years now, and the leap second adjustments isn't a real problem.
The crux of the matter is that we've insisted (in both Unix and Windows) on measuring calendar events in seconds:
The proper solution is to use Julian Day Number as the basic unit for calendars and (SI) seconds for any kind of short-term measurement. If you really need second/sub-second precision for long-term (multi-day) measurements, then you have to accept that the conversion is not just a matter of multiplying/dividing by 86400.
Calendar appointments and similar things should be defined by day number and some form of fractional day, not SI seconds.
NTP is somewhat to blame though: Even though it has full support for leap second handling (both adding and subtracting), the core of the protocol pretends that UTC seconds (without leap adjustments) is sufficient, i.e. NTP timestamps are defined to be in a 64-bit fixed-point format with 32 bits counting seconds since 1900-01-01 and 32 bit for the fractional seconds, i.e. sufficient to handle a 136-year block with a quarter of a ns resolution.
http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap
This causes small hiccups for an hour or so after each adjustment: The primary servers and those that either have a leap-second aware source or a cluefull operator keep in sync throughout the adjustment, while the remainder will slowly detect that their local clocks seems to be a full second off. Since this is way more than the default +/- 128 ms which NTP is willing to handle with gradual adjustments, NTPD will instead step the clock (backwards for an added leap second) and restart the protocol engine, after discarding all history.
Modern versions of NTP have been rewritten to use a vote between all otherwise good servers: If a majority claim that there will be a leap second at the end of the current day, then the local deamon will believe them, and thereby stay in sync even during the actual leap second itself.
Terje
RSync.net, the online backup company, has been using a "warrant canary" for many years now:
Every week they update a special page with a PGP-signed dated article stating something like this:
http://www.rsync.net/resources/notices/canary.txt
The current message is here:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
2010-08-09
No warrants have ever been served to rsync.net, or rsync.net principals or employees.
No searches or seizures of any kind have ever been performed on rsync.net assets,
including:
ALL San Diego locations
ALL Denver locations
ALL Zurich locations
ALL Hong Kong locations
(from www.NewYorkTimes.com)
In Crackdown on Energy Use, China to Shut 2,000 Factories
By closing some steel mills, cement works and other energy-intensive factories, the government said it hoped to improve energy efficiency.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
iD8DBQFMYFymBzwoLX1vgGwRAsgCAJ9HU6xDNuJot7PlS39/zGAfGEed+gCffWrJ
ltsbJAqoiTwyWbKFuP+UOt8=
=reux
-----END PGP SIGNATURE-----
Terje
Not pointless at all!
Tournament results is what ELO really tries to predict, and there you are absolutely correct, i.e. everyone plays both White and Black equally often.
However, the current challenge is NOT to predict how well each player is going to do in the aggregate, but to minimize the error for each individual game. THIS IS CRUCIAL!
I.e. the error term is the RMS of the difference between the predicted and actual result for each individual game, not the sum of the normal pair of games against each competitor. ELO otoh is really trying to predict the result of the pair of games, not each of them individually, since it is the sum which correlates with the final result.
Simply biasing the ELO-prediction by something like +/-5% depending upon White/Black would correct for the known advantage of playing White.
Does this make sense?
Terje
The differences are indeed quite small, but it seems obvious that you should be able to do better than ELO by splitting it into two parts:
Games played as White and games played as Black.
In fact, this seems so obvious that I suspect there's something I have overlooked! :-)
As the contest site mentions, there's a very significant advantage to White, enough so that in their training data set White has 30+% win vs 20+% for Black.
I suggest that taking the normal ELO-predicted outcome and then biasing it according to this known historical trend, would have to result in slightly better predictions than the naked ELO number.
Terje