Shermer spends a significant number of pages at the outset of the book establishing the theoretical foundation of science and skepticism.  This foundation serves him well throughout the book, as he refers back to hallmarks of logic and illogic to demonstrate precisely how believers of “weird things” go wrong in their thinking.  Unfortunately, by referencing such heavyweight thinkers as Einstein and Hume, the author ensures that the few missteps in thought on his own part are dramatically obvious.

In two chapters of the book (Epidemics of Accusations and How We Know the Holocaust Happened) Shermer uses the concept of the feedback loop.  In the case of the witchcraft loop he lays out the elements of the loop well, documenting how a culture of fear, paranoia, and anger leads to accusations, accusations to punishment, punishment to more accusations, increased accusations to more fear, more fear to more punishment, etc.  Frustratingly, his visual model does not translate this accurate depiction from text to image; rather, he takes the linear series of events (rumors, accusations and trials, mounting skepticism, then accusers becoming accused) and wraps it into a circle.  As mounting scepticism did not lead to a new round of witch trials, and the events in 1944-45 did not lead to another persecution of Jews and other Nazi-despised groups, simply connecting the end a linear series of events to the beginning does not make a feedback loop.

At the end of “Pigeonholes and Continuums”, Shermer uses Kinsey’s work on human sexuality to make his point that genetic variation between individuals is greater than the average variation between groups, which invalidates the scientific argument for a genetic basis of IQ discrepancies between races.  While I don’t believe there is a genetic basis for significant intelligence gaps between races, I don’t buy Shermer’s argument (what about race-specific or selective diseases, such as sickle-cell anemia?).  Nevertheless, the argument seems a valid, if debatable, point… until the following chapter, when he cites research that demonstrates measurable differences in the psyches of first-borns and later-borns.  If the greater disparity between traits of individuals as opposed to average traits of groups is important in one context (race and genetics), why is that same argument ignored in another context (birth order and upbringing)?

What makes these occasional issues frustrating is that the book as a whole is solid.  Shermer advances his argument well, consistently calling for logical consistency and extraordinary proof for extraordinary claims.  He ties common themes of confused thinking together, demonstrating how believers of various debunked (or just plain wrong) claims fall into the same traps.  He also manages to maintain reader interest while generally avoiding an elitist tone by interspersing his scientific arguments with stories and descriptions of the people central to his targeted beliefs, at once establishing their humanity and wrongness.

Why People Believe Weird Things is an entertaining and illuminating book – but it requires that the reader engage in some skepticism with regards to the claims of the author, as well as that which he seeks to disprove.

Luckily, the fix was easy.  Following this quick walkthrough for enabling remote access to PostgreSQL, I just had to edit one line in my /etc/postgresql/8.4/main/postgresql.conf file, from #listen_addresses='localhost' to listen_addresses='*'.  When commented out, it only listens on localhost; when specified to ‘*’, it listens for all connections.

Webmin, looks like a change could improve your PostgreSQL remote administration significantly – when users specify non-localhost TCP/IP hosts, you could check the settings in postgresql.conf.

1. I was skimming pretty quickly, so stupidly didn’t realize that the commands are from the command prompt instead of from the psql console.
2. The location of the files postgis.sql and spatial_ref_sys.sql was not immediately obvious.  Turns out they’re in /usr/share/postgresql/8.4/contrib/.

A quick SELECT postgis_full_version(); shows that I’m on the right version of PostGIS (1.4.0), but it looks like the GEOS & Proj4 libraries I compiled it against are pretty old (4.6 instead of 4.7 for Proj4; 3.0.2 instead of 3.2.0 for GEOS).  On the other hand, the functions list in phppgadmin shows the function I was looking for (st_asgeojson), so I’m calling this one a success.

Using psql is pretty easy – su to the postgres user, then launch, since the postgres user by default has complete access locally.  Connecting over TCP/IP  is a different matter.  By default it’s locked down, so phppgadmin doesn’t allow you to log in as anyone by default.  I suppose that’s why the local (non-web) pgAdmin 3 is the default GUI administration tool.  Unfortunately for me, I’m very accustomed to phpmyadmin, and I’m running my postgres install on a mostly headless box, so the standard tool doesn’t really cut it.

I’ve set up the package before using this great phppgadmin setup walkthrough, but this time it just didn’t work for me.  Messing with pg_hba.conf files, etc. was getting me nowhere, until a random forum post made me realize something really straightforward – I have Webmin installed!  After that, it took about 2 minutes to set up and log in.

PhpPGAdmin setup with Webmin

• Log in to Webmin
• Select Servers -> PostgreSQL Database Server
• Select PostgreSQL Users
• Under the list of users, select Create a new user
• Enter username, password, & general permissions, then click Create
• Go back to the database list, then select Allowed Hosts
• Click on Create a new allowed host
• Check Host Address -> Network/CIDR.  If your local network is like mine (most devices assigned an IP via DHCP, you’ll want to put in the IP address for our local machine (192.168.11.5 for me), then set CIDR length to 24.  This tells postgres to allow users from 192.168.11.x; the CIDR length specifies how many parts of the IP address to ignore (32 means it matches against the entire number; 24 = first 3 parts; 16 = first 2; 8 = first 1).
• I allowed access to all databases
• Under Users select listed users, and type in the name of the user you just created
• Set the authentication mode to MD5 password
• Click Save

Worked perfectly.

• The steps for compiling are pretty straightforward – ./configure, make, make install, make check.  However, the documentation makes it seem like make check comes before make install, when it actually comes after.
• The default Postgres install grants all rights to the user postgres.  Installing PostGIS requires administrative rights at some point (or at least the ability to modify some system directories), which the postgres user doesn’t have by default.  My default user had not been granted any rights in Postgres.  It wound up being easier to temporarily add the user postgres to the admin group, run the full compile/install from the postgres home directory, then remove the user from the group when done.

The make check and user rights/Postgres rights issues are really straightforward to deal with, almost non-issues, but they did cost me a fair amount of head-scratching time.  Make check was really worth figuring out.  It’s a great utility for verifying your PostGIS install and ensuring that the various functions you’re looking for (GeoJSON support, in my case) are there and working.

Working backwards from a couple of internet walkthroughs, I uninstalled then reinstalled the postgresql-8.X, postgresql-client, and postgresql-contrib packages.  After doing so the client programs, particularly psql, were still a mess, and postgres didn’t appear to have been launched.  Manually launching it didn’t seem to work, and even Webmin couldn’t find or launch the service.  I did notice while poking around that the installation files didn’t seem to be in the same place as in the standard Postgres install documented at their site.  Finally launching a GUI package manager resolved the problem – on Ubuntu, postgres is installed by default with a package called postgresql-common, which modifies the installation directories to allow multiple instances of Postgres (8.2, 8.3, and 8.4, for example) on the same box.  Since I don’t really need that, the solution was easy – remove the postgresql-common package, then install like normal.  Worked beautifully.

Hope this saves someone the several hours of frustration it caused me.  Now to upgrade PostGIS – since the standard apt-get package for 8.04 doesn’t have GeoJSON support, it may be a frustrating adventure into the land of make/make install.

One thing Minneapolis could be doing to add some sort of value to vacant lots is to plant them with a prairie mix.  Right now it looks like once the house is demolished they’re just leveled and left to sit.  The city could easily equip their public works crews with a few bags of a MnDOT seed mix and have them spread seed after a demo.  The rewards for this aren’t massive, but they are straightforward – nicer looking lots with wildflowers & prairie grasses are way better neighbors than lots with bare dirt and weeds.  With essentially no outlay in expense, the city could make a difference, even a slight one, in property values and bird & insect habitat.

There are other proposals about what to do with vacant lots.  This Daily Planet article has a comment offering a suggestion about community gardens that I’ve heard before, for example.  The advantage of seeding with a prairie mix is that it’s not a case of doing one instead of the other.  You can always plant prairie while you’re waiting for the paperwork to line up for a garden.  Establishing a better mix of plants in urban areas is a cheap win-win.

First project – large scale, efficient electricity storage.  Wired talks about the future of the grid with seven separate reforms to meet our current energy goals.  In the context of major infrastructure, efficient long-distance transmission and battery storage are the two best candidates for direct government funded action.  The barriers to transmission are mostly political, so a federal push right now is well timed.  Storage, on the other hand, just hasn’t passed the point in research where a full on federal program is likely to create an economically viable outcome in the long term.

There are a lot of potential avenues to explore to store energy – the Wired article talks about compressed air, flywheels, and pumped water.  I’ve heard a lot about high-capacity capacitors, for instance.  Obviously in the past 10 years or so batteries have become far more efficient, but they’re still not up to the task of storing energy from irregular green generators like solar and wind.  There’s certainly a lot of research to be done, but that’s a far cry from stimulating the economy by funding a transformation in the infrastructure with a proven solution.  Once there’s an accepted approach to large-scale energy storage a massive federal program might work; until then, money needs to go into smaller scale pilot projects to test a variety of directions.

Second project – driverless vehicles.  We’re a lot closer than we were ten years ago.  Most of the elements are already in place – GPS devices tied to road maps, automatic braking systems, adaptive cruise control and automatic parking, and of course the dramatic improvement of contestants in the DARPA Grand Challenge all show that the various elements required for self-piloted vehicles are available; what remains is to stitch them together.

The problem is pretty similar to the energy storage problem – there haven’t been any pilot programs or tests of automated vehicle systems in an urban environment apart from DARPA, probably because it’s extremely dangerous.  That means that there’s no general consensus on a national standard for automating vehicle traffic.  Should roads have embedded navigation indicators, like breadcrumbs for cars?  How should cars be alerted about construction projects?  To what degree should vehicles communicate with each other, or to what degree should they be controlled by a centralized system?  Again, all of these questions are good ones for government to be spending money on answering.  If the research were about fifteen years further along this would be a golden opportunity.

I focused on energy storage and automated vehicles because I see those as the two upcoming changes to our infrastructure that will A) require or benefit from government intervention, and B) create a great deal of economic opportunity in the long term.  Not being required to drive your car means you can start work during your commute (or read a book and extend your leisure time, if you’re not a died-in-the-wool workaholic).  Long term storage of electricity opens the way for a much bigger investment in renewable energy, from massive thermal-solar plants down to widespread photovoltaic units on individual homes, replacing aging coal infrastructure.  I think that Obama’s desire to take advantage of the crisis is dead on; it’s just unfortunate that the two upcoming changes that massive infusions of federal cash would help the most are too far out to invest in.