Yeah, that was my thought too; they'd have to let the car in, because that kind of stupidity is real life human behaviour that the machines are just going to have to deal with in order to operate on real roads. (Simply hanging a sign on the back saying 'road train, do not overtake' isn't an option because you know some moron is going to ignore it.)
So the options are: (a) break the train --- but this is bad, because you're suddenly going to have to alert everybody from the break downstream that they're suddenly going to have to drive on manual, without much warning, or (b) maintain the train, but with a foreign car in the middle.
(b) is actually reasonably plausible; motorways are very regulated environments, and the cars are going to have to cope with foreign vehicles anyway, so it's not that hard a problem. You can still rely on the train for high-level navigation and long distance sensing, which is the bulk of the value. Theoretically you could have the train spread over some distance, interleaved with ordinary traffic... but that's getting a bit hairy. (Plus, you get a potential for train breaks if the cars get too far apart for radio communication.)
OTOH the FAQ on their website specifically says that the entire train changes lane as a unit, at the discretion of the lead driver. So maybe they're not going for that sort of autonomy.
I've heard of a thing called a LiveView, which is a watch-form-factor dumb terminal which speaks Bluetooth to your phone. But I've never seen anyone who had one, and the reviews reckon it doesn't really fly: http://www.engadget.com/2010/12/01/sony-ericsson-liveview-review/
But you're just starting to get genuine smartwatches which run Android. Here's Motorola's: http://www.pcmag.com/article2/0,2817,2397538,00.asp You can also get any number of unbranded Chinese smartphone watches from Alibaba, but I have no idea what they run.
The 8086/286 memory management was actually quite elegant, in a twisted kind of way, and is best thought of as object oriented memory: a segment descriptor refers to an object, and you then indirect via an offset into that object. I once met a 286 Smalltalk implementation that used the 286 MMU like this. It worked rather well.
Of course, with 16-bit segment handles it totally fails to scale to modern systems, and it's completely incompatible with any modern coding practices.
The GEOS SDK is actually available as a free download (although I notice that some of the zipfile links with the documentation in it are broken. Sigh. It's available, you just have to hunt for it). That's the DOS-hosted version. To use the incomprehensible and bug-ridden debugger you'll need a second PC and a serial cable (or virtual versions thereof).
It would actually be interesting to see the source code. I suspect that far too much of it is written in 8086 assembler to be of any use these days, although quite a lot of the platform-specific bits could just be discarded --- block locking is irrelevant these days, for example. But I suspect it won't happen. GEOS had too much licensed third-party code in it...
(I got a job offer from Geoworks once. I turned them down. Probably a wise move.)
I wrote some code for it: see here (including a Linux86 execution environment, that would allow you to directly run Linux86 binaries from GEOS, that I was really rather proud of).
I can sum up the coding experience with the phrase: THE HORROR, THE HORROR.
In order to write code for GEOS you needed a monster, badly written and badly documented SDK and a copy of Borland C. The actual code you wrote was in a C superset called GOC, which was compiled via a buggy preprocessor into incredibly cryptic C, which was then compiled with Borland and linked with a custom linker. Alternatively, if C wasn't your thing, there was an object-oriented dialect of 8086 assembler available. The OO system was bizarre, and allowed for classes to have unspecified superclasses, where the superclass was determined at run time: the system used this to great effect in the UI, where the app author's generic UI was turned into a specific UI implementation for the device. The C bindings were full of bugs, too, including function calls which didn't save all the registers properly...
The actual architecture exploited the hell out of the 8086 segmentation architecture. Memory was organised as a set of relocatable blocks which were referred to by handles (which, under the hood, were usually segment descriptors). To dereference the memory, you had to lock the block, do your manipulation, then mark the block as dirty if you had changed it, and unlock it. The lock/unlock procedure allowed the system to ensure that the block was in memory, by paging it in if necessary, either from EMS RAM or disk. It was incredibly, utterly, un-Posix, and a complete pain to do anything in. The learning curve was insane.
Where GEOS really did well was the application stack, which was subtle and elegant. There was a mechanism to allow you to use a file as a heap backing store (using a very similar but annoyingly different API to the block API described above, but that's not really important). The system automagically loaded and saved data from the file as you locked and unlocked blocks. There were standard components for everything up to and including a complete bitmap paint package, a vector drawing package, and a word processor --- and these all used these file heaps as storage. And, of course, you could have multiple components in the same file. OLE! But done right.
By today's standards, of course, it's all a huge pile of incomprehensible, unmaintainable cruft, all inextricably linked to 16-bit 8086 code. It wasn't just utter mismarketing that killed GEOS: it was the inexorable march of time. It was simply unable to adapt to the 32-bit world. All the clever tricks they did to get decent performance out of an 8086 were liabilities on more modern hardware.
That said, towards the end, when Geoworks was in its death spiral, they did produce two different attempts to rewrite GEOS for 32-bit RISC processors: GEOS-SE and GEOS-SC. I know absolutely nothing about these other than on the wikipedia page, and if anyone has any info, I'd be fascinated to hear about it.
Great-King's War is a free download from The Baen Free Library. Although I'll admit that I couldn't finish it --- it read far too much like a dull blow-by-blow description of a wargame (which I believe it is).
I never had one (although I wanted one). Now, after reading about the horrible hacks that Sinclair's engineers did to make it all work (did you know that they repurposed the Z80's DRAM refresh circuit as a video generator? 'strue) I suspect I'm glad I grew up with the BBC Micro instead.
But I cannot deny that the set of standard manuals had the best cover art on any computer reference book, ever. Mmm, those lovely John Harris paintings... and he sells prints!
This was the last official kubuntu release. And yes, I'm quite sure there's no hardware problem. That said, it was running from a live image on a USB key, and I don't think it was happy; it took ages to boot.
My father's been using Ubuntu for years, and really likes it; he prefers it to Windows. As he's not a Linux geek and installing Linux in such a way as to reliably not wreck anything else on the system is still not foolproof, I've been managing the system for him.
I've been holding off on upgrading him since Unity came out; he's running the last LTS from before that. But that's getting a bit long in the tooth, so when the recent version came out I showed him Unity and Gnome 3. He loathes them both, calling them childish --- he particularly dislikes the huge, unlabelled icons. Eventually we found the (highly non-intuitive) way to shrink the Unity dock bar icons and he says he can live with it, but he really just wants the old Ubuntu back. Gnome 3 he thought was unspeakable. No task bar, no minimise, and above all he dislikes having the dock on a different screen. (He wasn't keen on the Unity launcher screen, either.)
But this is the really telling thing: I tried him out on various systems, to see which one he liked best. His favourite? Haiku.
The action of growing the plants is what absorbs the carbon. This is because plants are mostly made of carbon, hydrogen and oxygen, all of which they get out of the atmosphere. (Plus a handful of trace elements.)
This is why you can keep taking tonnes of plants out of the same patch of soil while all you put back in is a small amount of fertiliser. It's also how airplants work, which have no roots.
You grow the plant and it absorbs carbon. Then you kill it, turn it into ethanol, and burn it. The carbon goes back into the atmosphere. Net carbon offset: zero.
Even when quoting the mass of interstellar objects, the intended meaning of "a pound" is the amount of mass that would produce one pound of force on the surface of the Earth.
I was born in Perth, Scotland, where g is about 9.82 m/s^2. I now live in Reading, England, where g is about 9.81 --- a small difference, but measurable. If I were to go to Mexico City, it would be 9.78.
I'd actually written up a long pedanttastic post on how a ton is defined in terms of pounds and is therefore a unit of weight, while a tonne is defined in terms of kilograms and is therefore a unit of mass; but it looks like they've sneakily redefined the pound (in both the UK and the US) to be a unit of mass. The cads!
But as ton can be either 1000kg, 907kg, 1016kg, or even one of about five volumes, depending who you ask, I'd strongly recommend the metric spelling for clarity...
(It is not true I'm a card-carrying member of the Pedant's Society. It's actually made out of plastic.)
I actually meant NASA --- if they could be persuaded to switch to a more useful license, preferably a standard one, their software would become vastly more useful.
I've just read the license; it all looks pretty standard to me. It's got a requirement for source code distribution alongside binary distributions; it doesn't appear to require that modifications are licensed under the same license (but see below); there's a patent waiver; and there's a number of non-binding clauses that shouldn't be there at all. It's all pretty muddy and unclear.
The only suspicious bit is that there's a requirement that modified versions of the software are labelled as such in a changelog, and that modifiers must be identifiable. This may violate the Debian Dissident Test. However, it doesn't define what 'identifiable' means. It may be possible to argue that a pseudonym would do. You'd have to ask someone who actually knows.
My publishers don't give me stats that distinguish what ebook readers are purchasing my books, so I really don't know what percentage the kindle accounts for. However I also have a few Kindle books (ie exclusively Kindle) and they aren't exactly flying off the (virtual) shelves.
You can't tell us these things!
No, seriously, you can't. Term 7 of the KDP terms and conditions is:
7 Confidentiality. You will not, without our express, prior written permission: (a) issue any press release or make any other public disclosures regarding this Agreement or its terms; (b) disclose Amazon Confidential Information (as defined below) to any third party or to any employee other than an employee who needs to know the information; or (c) use Amazon Confidential Information for any purpose other than the performance of this Agreement. You may however disclose Amazon Confidential Information as required to comply with applicable law, provided you: (i) give us prior written notice sufficient to allow us to seek a protective order or other appropriate remedy; (ii) disclose only that Amazon Confidential Information as is required by applicable law; and (iii) use reasonable efforts to obtain confidential treatment for any Amazon Confidential Information so disclosed. "Amazon Confidential Information" means (1) any information regarding Amazon, its affiliates, and their businesses, including, without limitation information relating to our technology, customers, business plans, promotional and marketing activities, finances and other business affairs, (2) the nature, content and existence of any communications between you and us, and (3) any sales data relating to the sale of Digital Books or other information we provide or make available to you in connection with the Program. Amazon Confidential Information does not include information that (A) is or becomes publicly available without breach of this Agreement, (B) you can show by documentation to have been known to you at the time you receive it from us, (C) you receive from a third party who did not acquire or disclose such information by a wrongful or tortious act, or (D) you can show by documentation that you have independently developed without reference to any Amazon Confidential Information. Without limiting the survivability of any other provision of this Agreement, this Section 7 will survive three (3) years following the termination of this Agreement.
Note that section (3) indicates that all sales data is confidential and therefore you are not allowed to disclose it. You don't even seem to be allowed to say anything about Amazon, including 'I spoke to Amazon today about the misprint in my latest book.' Luckily, as the T&Cs themselves are publically available without having signed the T&Cs --- naturally enough --- it's possible to discuss them (see (A)).
I was intending to sign up for this, but the above clause seems unusually draconian to me.
It appears that Amazon have recently changed their DRM so that each book is encrypted with its own key --- certainly, I've been unable to decrypt the last (and only) book I've bought. (Neal Stephenson's Anathem. If there's ever a case for ebooks, it's Neal Stephenson; because now I can lift one of his books in one hand.)
This is with a Kindle 3 using the latest firmware.
2000m below 'Lunar standard sea level', i.e. what people generally consider to be altitude 0, which is a sphere 1737.4 km in radius. Take a look at the settings if you're interested. (I think it's all up-to-date in hg.) 2000m was picked arbitrarily to give a decent balance of land and sea.
However, the moon is actually hideously lopsided, due to tidal effects caused by Earth; the near side is noticeably bigger than the far side. This makes the lunar gravitational field uneven. Therefore the surface at which water will actually settle to (which is known as a geoid) is not a sphere. Luckily, Lunar prospector mapped this shape too, so I can compensate for it. That's relatively small, a mere 100kB PNG file.
I have a slow-going project to render the moon using Povray. Except, because I'm awkward, I've terraformed it. There are some very slightly better (but still very poor) videos here and here.
I'm using a monster dataset from the Kaguya spaceprobe for the terrain data, which, at maximum resolution, ends up as a 270MB 16-bit greyscale PNG file. Even so, it's only about 4 pixels per degree and, as you can tell from the videos above, the terrain is way too smooth to be interesting. I've experimented with adding algorithmic complexity with some pretty good results, and need to render the videos, but it's cripplingly slow and is, of course, cheating. [*]
So a higher-resolution dataset is great news for me. Now I just need to figure out how to get a global DEM at the highest possible resolution, which is not easy (I can see DEMs at 64 pixels/degree, but the 256 pixels/degree data appears to be available only in tiles with odd projections).
[*] Also, procedural code in Povray is very slow. I have been looking into rewriting the whole thing in Renderman but my model is too pathologically weird for most Renderman implementations --- I'm viewing a very, very large sphere with huge displacement shaders from very, very close up, and the open source Rendermans I've tried so far just curl up and die. Any suggestions gratefully appreciated.
I reckon they're salt pans, partially filled with water. I can see distribution channels, a feed canal coming from the north, and the telltale fractal structure of evaporating salt.
Incidentally, all these sites have (or claim to have) Panoramio pictures nearby, although it's impossible to tell how accurate the positioning is.
Slashdot Mirror
Yeah, that was my thought too; they'd have to let the car in, because that kind of stupidity is real life human behaviour that the machines are just going to have to deal with in order to operate on real roads. (Simply hanging a sign on the back saying 'road train, do not overtake' isn't an option because you know some moron is going to ignore it.)
So the options are: (a) break the train --- but this is bad, because you're suddenly going to have to alert everybody from the break downstream that they're suddenly going to have to drive on manual, without much warning, or (b) maintain the train, but with a foreign car in the middle.
(b) is actually reasonably plausible; motorways are very regulated environments, and the cars are going to have to cope with foreign vehicles anyway, so it's not that hard a problem. You can still rely on the train for high-level navigation and long distance sensing, which is the bulk of the value. Theoretically you could have the train spread over some distance, interleaved with ordinary traffic... but that's getting a bit hairy. (Plus, you get a potential for train breaks if the cars get too far apart for radio communication.)
OTOH the FAQ on their website specifically says that the entire train changes lane as a unit, at the discretion of the lead driver. So maybe they're not going for that sort of autonomy.
*shrug* I'd be interested to know more.
Good luck getting an extra 22,000 lbs of metal off the moon and back to earth in one piece.
SpaceX will never develop the technology to do that.
Their vehicles only lift kilograms.
What's the difference between a bomb and a rocket?
Bombs blow things up. Rockets blow things up.
Apparently it's really popular in South Korea, too. Go figure.
We also have it here in the UK; although we call it 'rounders', and it's usually played only by little girls.
I've heard of a thing called a LiveView, which is a watch-form-factor dumb terminal which speaks Bluetooth to your phone. But I've never seen anyone who had one, and the reviews reckon it doesn't really fly: http://www.engadget.com/2010/12/01/sony-ericsson-liveview-review/
Oh, and here's a more recent one by Sony: http://www.pcmag.com/article2/0,2817,2403098,00.asp
But you're just starting to get genuine smartwatches which run Android. Here's Motorola's: http://www.pcmag.com/article2/0,2817,2397538,00.asp You can also get any number of unbranded Chinese smartphone watches from Alibaba, but I have no idea what they run.
The 8086/286 memory management was actually quite elegant, in a twisted kind of way, and is best thought of as object oriented memory: a segment descriptor refers to an object, and you then indirect via an offset into that object. I once met a 286 Smalltalk implementation that used the 286 MMU like this. It worked rather well.
Of course, with 16-bit segment handles it totally fails to scale to modern systems, and it's completely incompatible with any modern coding practices.
The GEOS SDK is actually available as a free download (although I notice that some of the zipfile links with the documentation in it are broken. Sigh. It's available, you just have to hunt for it). That's the DOS-hosted version. To use the incomprehensible and bug-ridden debugger you'll need a second PC and a serial cable (or virtual versions thereof).
It would actually be interesting to see the source code. I suspect that far too much of it is written in 8086 assembler to be of any use these days, although quite a lot of the platform-specific bits could just be discarded --- block locking is irrelevant these days, for example. But I suspect it won't happen. GEOS had too much licensed third-party code in it...
(I got a job offer from Geoworks once. I turned them down. Probably a wise move.)
I wrote some code for it: see here (including a Linux86 execution environment, that would allow you to directly run Linux86 binaries from GEOS, that I was really rather proud of).
I can sum up the coding experience with the phrase: THE HORROR, THE HORROR.
In order to write code for GEOS you needed a monster, badly written and badly documented SDK and a copy of Borland C. The actual code you wrote was in a C superset called GOC, which was compiled via a buggy preprocessor into incredibly cryptic C, which was then compiled with Borland and linked with a custom linker. Alternatively, if C wasn't your thing, there was an object-oriented dialect of 8086 assembler available. The OO system was bizarre, and allowed for classes to have unspecified superclasses, where the superclass was determined at run time: the system used this to great effect in the UI, where the app author's generic UI was turned into a specific UI implementation for the device. The C bindings were full of bugs, too, including function calls which didn't save all the registers properly...
The actual architecture exploited the hell out of the 8086 segmentation architecture. Memory was organised as a set of relocatable blocks which were referred to by handles (which, under the hood, were usually segment descriptors). To dereference the memory, you had to lock the block, do your manipulation, then mark the block as dirty if you had changed it, and unlock it. The lock/unlock procedure allowed the system to ensure that the block was in memory, by paging it in if necessary, either from EMS RAM or disk. It was incredibly, utterly, un-Posix, and a complete pain to do anything in. The learning curve was insane.
Where GEOS really did well was the application stack, which was subtle and elegant. There was a mechanism to allow you to use a file as a heap backing store (using a very similar but annoyingly different API to the block API described above, but that's not really important). The system automagically loaded and saved data from the file as you locked and unlocked blocks. There were standard components for everything up to and including a complete bitmap paint package, a vector drawing package, and a word processor --- and these all used these file heaps as storage. And, of course, you could have multiple components in the same file. OLE! But done right.
By today's standards, of course, it's all a huge pile of incomprehensible, unmaintainable cruft, all inextricably linked to 16-bit 8086 code. It wasn't just utter mismarketing that killed GEOS: it was the inexorable march of time. It was simply unable to adapt to the 32-bit world. All the clever tricks they did to get decent performance out of an 8086 were liabilities on more modern hardware.
That said, towards the end, when Geoworks was in its death spiral, they did produce two different attempts to rewrite GEOS for 32-bit RISC processors: GEOS-SE and GEOS-SC. I know absolutely nothing about these other than on the wikipedia page, and if anyone has any info, I'd be fascinated to hear about it.
750 pounds is 35 million dollars? Has the value of the dollar against the pound slipped again?
Great-King's War is a free download from The Baen Free Library. Although I'll admit that I couldn't finish it --- it read far too much like a dull blow-by-blow description of a wargame (which I believe it is).
I never had one (although I wanted one). Now, after reading about the horrible hacks that Sinclair's engineers did to make it all work (did you know that they repurposed the Z80's DRAM refresh circuit as a video generator? 'strue) I suspect I'm glad I grew up with the BBC Micro instead.
But I cannot deny that the set of standard manuals had the best cover art on any computer reference book, ever. Mmm, those lovely John Harris paintings... and he sells prints!
This was the last official kubuntu release. And yes, I'm quite sure there's no hardware problem. That said, it was running from a live image on a USB key, and I don't think it was happy; it took ages to boot.
Actually, I did. We spent ten minutes trying to figure out how to work the desktop. Then it crashed and hung and I had to power cycle it.
My father's been using Ubuntu for years, and really likes it; he prefers it to Windows. As he's not a Linux geek and installing Linux in such a way as to reliably not wreck anything else on the system is still not foolproof, I've been managing the system for him.
I've been holding off on upgrading him since Unity came out; he's running the last LTS from before that. But that's getting a bit long in the tooth, so when the recent version came out I showed him Unity and Gnome 3. He loathes them both, calling them childish --- he particularly dislikes the huge, unlabelled icons. Eventually we found the (highly non-intuitive) way to shrink the Unity dock bar icons and he says he can live with it, but he really just wants the old Ubuntu back. Gnome 3 he thought was unspeakable. No task bar, no minimise, and above all he dislikes having the dock on a different screen. (He wasn't keen on the Unity launcher screen, either.)
But this is the really telling thing: I tried him out on various systems, to see which one he liked best. His favourite? Haiku.
The action of growing the plants is what absorbs the carbon. This is because plants are mostly made of carbon, hydrogen and oxygen, all of which they get out of the atmosphere. (Plus a handful of trace elements.)
This is why you can keep taking tonnes of plants out of the same patch of soil while all you put back in is a small amount of fertiliser. It's also how airplants work, which have no roots.
You grow the plant and it absorbs carbon. Then you kill it, turn it into ethanol, and burn it. The carbon goes back into the atmosphere. Net carbon offset: zero.
I was born in Perth, Scotland, where g is about 9.82 m/s^2. I now live in Reading, England, where g is about 9.81 --- a small difference, but measurable. If I were to go to Mexico City, it would be 9.78.
There's a wikipedia page with a big table.
I'd actually written up a long pedanttastic post on how a ton is defined in terms of pounds and is therefore a unit of weight, while a tonne is defined in terms of kilograms and is therefore a unit of mass; but it looks like they've sneakily redefined the pound (in both the UK and the US) to be a unit of mass. The cads!
But as ton can be either 1000kg, 907kg, 1016kg, or even one of about five volumes, depending who you ask, I'd strongly recommend the metric spelling for clarity...
(It is not true I'm a card-carrying member of the Pedant's Society. It's actually made out of plastic.)
I actually meant NASA --- if they could be persuaded to switch to a more useful license, preferably a standard one, their software would become vastly more useful.
Yes, you're right --- I did read that bit, but didn't realise what it meant.
Sigh. Shame, really. I wonder if there's any way someone could talk sense into them?
I've just read the license; it all looks pretty standard to me. It's got a requirement for source code distribution alongside binary distributions; it doesn't appear to require that modifications are licensed under the same license (but see below); there's a patent waiver; and there's a number of non-binding clauses that shouldn't be there at all. It's all pretty muddy and unclear.
The only suspicious bit is that there's a requirement that modified versions of the software are labelled as such in a changelog, and that modifiers must be identifiable. This may violate the Debian Dissident Test. However, it doesn't define what 'identifiable' means. It may be possible to argue that a pseudonym would do. You'd have to ask someone who actually knows.
My publishers don't give me stats that distinguish what ebook readers are purchasing my books, so I really don't know what percentage the kindle accounts for. However I also have a few Kindle books (ie exclusively Kindle) and they aren't exactly flying off the (virtual) shelves.
You can't tell us these things!
No, seriously, you can't. Term 7 of the KDP terms and conditions is:
7 Confidentiality. You will not, without our express, prior written permission: (a) issue any press release or make any other public disclosures regarding this Agreement or its terms; (b) disclose Amazon Confidential Information (as defined below) to any third party or to any employee other than an employee who needs to know the information; or (c) use Amazon Confidential Information for any purpose other than the performance of this Agreement. You may however disclose Amazon Confidential Information as required to comply with applicable law, provided you: (i) give us prior written notice sufficient to allow us to seek a protective order or other appropriate remedy; (ii) disclose only that Amazon Confidential Information as is required by applicable law; and (iii) use reasonable efforts to obtain confidential treatment for any Amazon Confidential Information so disclosed. "Amazon Confidential Information" means (1) any information regarding Amazon, its affiliates, and their businesses, including, without limitation information relating to our technology, customers, business plans, promotional and marketing activities, finances and other business affairs, (2) the nature, content and existence of any communications between you and us, and (3) any sales data relating to the sale of Digital Books or other information we provide or make available to you in connection with the Program. Amazon Confidential Information does not include information that (A) is or becomes publicly available without breach of this Agreement, (B) you can show by documentation to have been known to you at the time you receive it from us, (C) you receive from a third party who did not acquire or disclose such information by a wrongful or tortious act, or (D) you can show by documentation that you have independently developed without reference to any Amazon Confidential Information. Without limiting the survivability of any other provision of this Agreement, this Section 7 will survive three (3) years following the termination of this Agreement.
Note that section (3) indicates that all sales data is confidential and therefore you are not allowed to disclose it. You don't even seem to be allowed to say anything about Amazon, including 'I spoke to Amazon today about the misprint in my latest book.' Luckily, as the T&Cs themselves are publically available without having signed the T&Cs --- naturally enough --- it's possible to discuss them (see (A)).
I was intending to sign up for this, but the above clause seems unusually draconian to me.
It appears that Amazon have recently changed their DRM so that each book is encrypted with its own key --- certainly, I've been unable to decrypt the last (and only) book I've bought. (Neal Stephenson's Anathem. If there's ever a case for ebooks, it's Neal Stephenson; because now I can lift one of his books in one hand.)
This is with a Kindle 3 using the latest firmware.
2000m below 'Lunar standard sea level', i.e. what people generally consider to be altitude 0, which is a sphere 1737.4 km in radius. Take a look at the settings if you're interested. (I think it's all up-to-date in hg.) 2000m was picked arbitrarily to give a decent balance of land and sea.
However, the moon is actually hideously lopsided, due to tidal effects caused by Earth; the near side is noticeably bigger than the far side. This makes the lunar gravitational field uneven. Therefore the surface at which water will actually settle to (which is known as a geoid) is not a sphere. Luckily, Lunar prospector mapped this shape too, so I can compensate for it. That's relatively small, a mere 100kB PNG file.
I have a slow-going project to render the moon using Povray. Except, because I'm awkward, I've terraformed it. There are some very slightly better (but still very poor) videos here and here.
I'm using a monster dataset from the Kaguya spaceprobe for the terrain data, which, at maximum resolution, ends up as a 270MB 16-bit greyscale PNG file. Even so, it's only about 4 pixels per degree and, as you can tell from the videos above, the terrain is way too smooth to be interesting. I've experimented with adding algorithmic complexity with some pretty good results, and need to render the videos, but it's cripplingly slow and is, of course, cheating. [*]
So a higher-resolution dataset is great news for me. Now I just need to figure out how to get a global DEM at the highest possible resolution, which is not easy (I can see DEMs at 64 pixels/degree, but the 256 pixels/degree data appears to be available only in tiles with odd projections).
[*] Also, procedural code in Povray is very slow. I have been looking into rewriting the whole thing in Renderman but my model is too pathologically weird for most Renderman implementations --- I'm viewing a very, very large sphere with huge displacement shaders from very, very close up, and the open source Rendermans I've tried so far just curl up and die. Any suggestions gratefully appreciated.
I reckon they're salt pans, partially filled with water. I can see distribution channels, a feed canal coming from the north, and the telltale fractal structure of evaporating salt.
Incidentally, all these sites have (or claim to have) Panoramio pictures nearby, although it's impossible to tell how accurate the positioning is.
...you followed that last link, expecting it to lead to an opera version of the adventures of the famous Stainless Steel Rat, James Bolivar diGriz...
Confusingly, the director's name is Harrison, too. Wayne Harrison.