Makes me even happier I switched to Mac...
http://fakesteve.blogspot.com/2007/08/stunning-post-from-microsoftie.html
Ongoing musings, tips, and observations from a Van Couvering, not someone who is going to Vancouver.
Makes me even happier I switched to Mac...
http://fakesteve.blogspot.com/2007/08/stunning-post-from-microsoftie.html
Posted by David Van Couvering at 5:32 PM 0 comments Links to this post
Labels: technology
Some emails I have been reading indicate that not everyone knows there is this cool feature in Java DB/Derby. With a simple call in Java or by setting a property, you can have a VM with an embedded Derby database that also allows other processes to connect to and use this database through the network JDBC driver.
The instructions on how to enable the network server are here.
You either set the property derby.drda.startNetworkServer=true in your derby.properties file or you can start it explicitly:
NetworkServerControl server = new NetworkServerControl();
server.start (null);
Posted by David Van Couvering at 1:55 PM 1 comments Links to this post
Labels: databases, technology
Tim Boudreau is quite a character, and this latest foray, driving a NetBeans truck he painted himself across country as he relocates from the West Coast to the East Coast, is just plain fun and cool.
http://weblogs.java.net/blog/timboudreau/archive/2007/08/the_netbeansmob.html
Posted by David Van Couvering at 11:43 AM 0 comments Links to this post
Labels: technology
I applied the jet lag program I had recommended here, and I also supplemented it with Damon's acupressure/affirmation program that he referred me to in a comment.
Thanks, Damon, that really worked! Another benefit of blogging :) It's right up my alley (being from Berkeley).
Something about pressing all those points and reminding myself to feel good -- I found myself relaxing, breathing better, and feeling refreshed. I had zero jet lag in both directions, on a five day trip. I didn't sit up wide awake in the middle of the night or collapse in the middle of the day.
Yes, it sounds all wooey/New Agey, but hey, I am an open-minded scientist type and will try anything that doesn't sound harmful or cultish. Before you pooh-pooh it, try it yourself.
Posted by David Van Couvering at 10:57 AM 0 comments Links to this post

OK, Heathrow was hell, but Prague was quite wonderful. I actually was able to get away from the office on Friday afternoon and take a walking tour of Prague. I highly recommend Prague Walks They have all sorts of walking tours - the one I took was three hours with a very knowledgeable guide and included a stop half-way through at a pub for a foot rest and a local beer. What a great way to spend three hours!
More photos can be found here. They're with my crappy cell phone camera, I forgot to bring my regular camera (probably a good thing because it would probably still be sitting in Heathrow in my lost suitcase), but there are some good shots in there considering.
Posted by David Van Couvering at 10:45 AM 2 comments Links to this post
![]() | ![]() |
Posted by David Van Couvering at 10:02 PM 2 comments Links to this post
Labels: culture
A nice quick podcast where we get to hear Cloudscape old-timer Rick Hillegas talk about Java DB. The interview with Rick starts about 6 minutes in. Really direct, informative podcast.
http://today.java.net/pub/a/today/2007/08/27/javamobility-podcast17.html
Posted by David Van Couvering at 10:01 PM 0 comments Links to this post
Labels: databases, technology
A reader asked if password encryption is enabled by default in 10.3. I checked with the Derby team, and the answer is, no, the password is still sent in the clear by default in 10.3. You have to enable it by setting the securityMechanism property on the URL.
See http://db.apache.org/derby/docs/dev/ref/rrefattribsecmech.html for more details.
Posted by David Van Couvering at 10:02 PM 0 comments Links to this post
Labels: databases, technology
In response to my post about the London Cheese Shop (no, not the Monty Python Cheese Shop, they actually have cheese, including Cheddar, and they weren't playing a bloody bazouki), my sister posted info on the name of the shop and their web link, and my Pa then found a US purveyor.
Elizabeth:
The shop is Neal's Yard Dairy - the cheeses are locally produced English ones with the names of the farmers on them! Here's the website:
http://www.nealsyarddairy.co.uk/thecheeses.html#
David tried the Montgomery Cheddar, if you click the link you can see more pictures.
Me dear ol' Pa:
Not only that -- I went to the website and found that they retail in the USA via select fromageries. Voila! Montgomery cheddar!
http://www.bedfordcheeseshop.com/catalog/?id=33
Posted by David Van Couvering at 2:28 PM 0 comments Links to this post
Fake Steve is having some fun about the change from SUNW to JAVA. Ouch, that stings! :)
http://fakesteve.blogspot.com/2007/08/more-big-changes-coming-at-sun.html
http://fakesteve.blogspot.com/2007/08/i-stand-corrected.html
Posted by David Van Couvering at 2:25 PM 0 comments Links to this post
A nice blog from someone showing the performance improvements for sequential scans in the latest PostgreSQL release.
http://www.commandprompt.com/blogs/joshua_drake/2007/08/postgresql_83_its_faster_really_it_is/
Posted by David Van Couvering at 2:06 PM 0 comments Links to this post
Labels: databases, technology
I still feel than this move was bold and audacious. But I think these responses highlight the very good points that (a) Sun is much more than Java and (b) Java may not have legs -- will it still be as big 10 years from now? Hmm...
Posted by David Van Couvering at 2:02 PM 0 comments Links to this post
Russell encounters serial eBay account theft. This is the kind of bad press that can really impact a brand like eBay. Security is and will alway be a major Achilles heel of online business.
Posted by David Van Couvering at 2:36 PM 0 comments Links to this post
I've been seeing a number of posts about the death, or at least increasing irrelevance, of the RDBMS. First I read Nitin Borwankar's article about how Web 2.0 disrupts our database world. Then I found this post by Alex Bundardzic saying that Ruby 1.2 drives the final nail into the RDBMS coffin. Then just today Arnon Rotem-Gal-Oz says that the RDBMS is dead.
What the heck is going on here? Why is everyone claiming the irrelevance or actual death of the RDBMS?
Alex's blog is one I don't fully understand, but then again, I don't think I fully understand his Resource-Oriented Architecture, and I've never used Ruby on Rails. I can't see how REST support in Ruby on Rails somehow gets rid of the need for an RDBMS.
But let's look at the other two. Both Nitin and Arnon are talking about the impact of scale. Nitin also talks about the impact of hierarchical organizations such as social networks that are very hard to translate to a relational model and still get good performance.
To be honest, I think the biggest challenge is scale. Web applications are attracting a user-base that is not just your own company's employees, but an ever-increasing vast sea of global consumers, millions and millions of them. If your web application is successful, you may need to hit levels of scale, reliability, scalability and availability that you never thought possible, and definitely far beyond what relational database vendors thought possible when these systems were first architected.
With this kind of scale, you have to try to eliminate every single point of contention and single point of failure in your system. You need to be able to distribute it across thousands of machines where every request can run independently and on any machine. And the problem is that the database is a big point of contention, because it implements transactional semantics, which thus require centralized locking and storage to disk, creating bottlenecks and slowing everything down.
So I agree with these authors that Web Scale is forcing us to do a major re-thinking of how and when to persist data, and ask questions about how important, really, are ACID semantics and normalized data? Where and when can I let go of atomicity, consistency, integrity and durability (ACID)?
This reminds me of what airlines do. You book a flight, and you have the impression that they have reserved you a seat on the plane. Well, they have, and they haven't. In their case they need to optimize for the fullest flight possible, and people are unpredictable. We commit to being there for the flight, but sometimes we don't show up or cancel at the last minute. So, they overbook. They take the risk that everybody or almost everybody shows up, and if necessary they do a compensating transaction (literally) by paying people to take another flight. This potential cost is worth it to them in the long run.
In the same way, you start making calculated risks because scalability and performance are so important. You risk some loss of data and use a "lazy cache" (at the disk level or above) that batches up writes rather writing to disk for every transaction. You use more relaxed modes of maintaining consistency with things like optimistic concurrency and compensating transactions. You let the client manage some of the durability by sending it a representation of the current state and let it ship that back to your for the next operation (this is the REST model).
Another issue of scaling is the fact that databases tend to be centralized, and this creates a bottleneck. Oracle RAC is clustered, but it can't scale to hundreds of nodes because it's busy managing locks and shipping data around.
The centralized bottlneck of an RDBMS can often be solved at the application level by partitioning your data across multiple databases. This is what eBay does - each request is keyed off of the user id and sent to the appropriate database/app server partition. But this does require a domain model where there is as close to zero data shared across requests. Otherwise you just end up duplicating the bottleneck at the application tier by shipping data between application servers. This is another way where the REST model of shipping relevant state back to the client comes in handy -- the client can provide all the context it needs for each request, and the server doesn't have to keep this stuff around (and potentially share it with another server in the cluster).
Finally, maybe not everything has to be stored in the relational model. Maybe you can get by with a key/value store like Berkeley DB. Or maybe you can just keep some of your data in a clustered in-memory hashtable like memcached or Gigaspaces[1]. If you can do this, it can give you some serious performance wins.
But does all this make the database "dead" or "irrelevant?" I don't think so, and I don't think these authors really think so either (well, I don't know about Alex). I think it's very very good to have something that will give you the ACID guarantees and the power of SQL when you need it. It's a sense of security and safety, like having a home to come back to with a warm fire and a cup of cocoa after having a wild old time on the town.
It just means we have to re-think any tendencies we may have that everything has to be completely correct and perfect and relational when dealing with our data. Sometimes sloppy but quick is the best way to go.
[1] Gigaspaces is actually a lot more than just an in-memory hashtable. Because they store objects, then you can keep your data and logic close together, and in almost all cases this allows you to process a request on a single machine. This can be a very big performance and scalability win.
Posted by David Van Couvering at 1:22 PM 0 comments Links to this post
Japod of the Jersey team talks about how you can install the Jersey implementation as a Glassfish plugin. Pretty cool! Also, I didn't know about the Glassfish plugin framework - that's pretty cool too!
http://blogs.sun.com/japod/entry/jersey_will_soon_be_available
Posted by David Van Couvering at 9:58 AM 0 comments Links to this post
Labels: technology
Wow. Bold, audacious, wild. This guy never stops having fun.
Posted by David Van Couvering at 9:55 AM 0 comments Links to this post
Labels: technology
A very sad and telling article about a growing rabid deletionism in Wikipedia. I liked this quote: "It’s as if there is a Soup Nazi culture now in Wikipedia." Is Wikipedia evolving into irrelevance? Hopefully the pendulum will turn.
http://www.roughtype.com/archives/2007/08/rise_of_the_wik.php
Posted by David Van Couvering at 9:51 AM 0 comments Links to this post
Labels: technology
The java.net editor discovers through a one-line blog that Java Kernel is in the next update of JDK 6. Is this really true? If so, it's time to try it out!
http://weblogs.java.net/blog/editors/archives/2007/08/nobody_told_me.html
Posted by David Van Couvering at 9:51 AM 0 comments Links to this post
Labels: technology
Great blog that nails my own discomfort with this "Web OS" which has always felt kind of vague and hot-airy, a way of trying to shoot barbs at Microsoft. "The web is open and decentralized. Everything is one click away. Remember that."
Posted by David Van Couvering at 9:51 AM 0 comments Links to this post
Labels: technology
During my quick day-trip to London on the way to Prague, my sister Elizabeth and her hubby Henrik took me out on a wonderful trip on the town. They took me on my favorite kind of bus, a London double-decker (top deck of course), to an open market area that is usually completely packed, but today it was quite mellow and peaceful.
Our first stop was a great little tea shoppe where we had fruit scones with clotted cream and jam, little tea cakes, and incredible, delicious Earl Grey tea.
Then we wandered next door to a wonderful cheese shop, full of cheeses made by local British cheese "artisans." They had the infamous Stinking Bishop from Wallace and Gromit.
Henrik had me taste one of the cheddars. Wow! Incredible. Nice smooth fore-taste, and then an everlasting tingling sour/nutty after-taste. Never had anything like, nor do I expect to ever find anything like this in the USA.
I loved the atmosphere of the shop, with its full rounds of cheese and the "cheese waterfall" that kept the shop nice and moist.
![]() | ![]() | ![]() |


Posted by David Van Couvering at 12:19 PM 0 comments Links to this post
I am in the Heathrow Airport, and when I go to my Blogger page, it presents everything in German. Automatically. Isn't that special. I checked the Google FAQ and it says I need to set my default language to English in my browser. But it's already set to English.
I finally found this blog by Amit Agarwal that says I have to remove my temp folder and then set my default language at http://www.blogger.com/language.g. Sheesh! It would be nice if this were documented, rather than me having to search for a blog to do it.
Posted by David Van Couvering at 12:04 PM 0 comments Links to this post
Very interesting note from Nicholas Carr about what David Duffield is up to these days.
http://www.roughtype.com/archives/2007/08/the_end_of_erp.php
Posted by David Van Couvering at 12:06 PM 0 comments Links to this post
Labels: databases, technology
This source code comes from the Derby source base. Very useful in cases where you want to load a particular class or do other things based on which VM you are running in. In Derby's case this is used to load the appropriate JDBC driver.
Posted by David Van Couvering at 12:06 PM 0 comments Links to this post
Labels: databases, technology

I'm going to Prague next week for work, so I'm pulling out this great book that my ex-boss gave to me, called Overcoming Jet Lag.
It is based on research done by the government for travelling officials, and it has a very easy-to-follow program based on principles of the internal clock that they uncovered: light and dark, diet, caffeine, and activity. I've used it before for my trips to Norway, and they have really worked. Highly recommended.
Posted by David Van Couvering at 4:27 PM 2 comments Links to this post
A more and more commonly asked question on the Derby user list is "how do I best migrate my database from MySQL to Derby".
A very useful way to do this is through DDLUtils, a very nice utility that lets you export a database schema from one database and create it in another. Here is the MySQL page from DDLUtils.
But I also thought I'd share what looked like a very useful email from one person who did it. Note the interesting tips about non-standard JDBC that worked in MySQL but which Derby did not accept.
Posted by David Van Couvering at 2:16 PM 1 comments Links to this post
A neighbor of mine (well, he recently moved to Virginia) has ended up doing microfinance consulting with a bank in Arbil, Iraq. He's been sending us amazing missives about his life in the compound. They're in MS Word format, and I'm trying to convince him to turn it into a blog (maybe he doesn't have good enough Internet access for that).
Anyway, I thought I'd share his latest note.
Friday 1 PM
Hi everyone,
We work Sunday through Thursday so today is my day off and I slept in. It is approximately 112 degrees outside. I wanted to address the security issue. I’m getting some inquiries and people are wondering if I am in harm’s way.
Search the internet for a good map of Iraq and look at the top of the country. Kurdistan is sometimes confused with the "northern provinces" and the media continues to not distinguish between ethnic Kurdistan and the northern provinces. Mosul is violent and is up north, yes, but way east over near the Syrian border. Kirkuk is dangerous and there are lots of "incidence" down there and that is why we never entered the city. Even though the micro finance bank that I am consulting for operates there, no westerners in my parent organization enter the city. Everyone thinks that after the November election ( here ); Kirkuk will be ethnically cleansed and all the Arabs that Sadam moved in, will be kicked out…. or whatever. The Kurdish paramilitary is ready and they want the city back as well as the oil.
Anyway, Kurdistan is the three or four provinces that form a little icecap across the top of Iraq and border Turkey and Iran. The nasty genocide that occurred two days ago, for example, was outside of true Kurdistan but the area is obviously still populated by Kurds. The distinction is critical to understand, just because some bombs go off, and it is "up north" and some Kurds die, does not mean it is in Kurdistan. This may seem like trivia but I am depending on it. This city, Erbil, has a ten foot moat, or ditch, dug all the way around it to stop vehicles from entering cross terrain. The only way in is on the paved road, through multiple checkpoints guarded by the Kurd Army and the paramilitary. Voila ! No ethnic Arabs allowed. Period.
Nothing is perfect, and that is why I cannot leave the compound. It ( the compound ) is in a suburb of Erbil somewhere near the airport, and is occupied by a variation of religion that I am not sure of, I think there are Christians here or something. The suburb itself is surrounded by walls with watchtowers and guards. I live in a compound within the suburb that, as you already know, has blast walls, only one vehicle gate in and a different one out. The road to the gate has concrete diversions so an approaching car has to go really slow or it will crash. Everyone stops at the gate and the guards run a mirror under 360 degrees of the car, then the sniffer dog does it again. All supervised by Triple Canopy staff ( Google “Triple Canopy” and you can see the level of security that is provided to westerners ) No bombs allowed ! Worst case scenario is that somehow a person gets in past the gate and starts shooting up the place. They would last about one second. There are literally hundreds of armed people here including heavy duty westerners ( South African mercenaries ), not just the Kurds. Or, if someone drove close enough to the suburb, they could touch off some mortar rounds, but that would be so inaccurate that I don't even think of it.
Sorry for all the details, but information can cause relaxation, and that is what I am trying to convey. After all, there were drive by shootings almost every night on the commute path I took through north Oakland when I came back from the bank in Fremont. One of our friends was held up twice on the foot path between the BART station and his house in North Berkeley. So “safe” is a relative term.
It's noon and I am leaving the house to get lunch. Tonight I am hoping to get a security guy and go out of the compound for dinner. If not, then I will stay here, locked up like a caged rat. There is a big citadel about a mile away ( in the suburb ) and it old and famous. Maybe I can include that in my adventure if and when I can arrange an outing.
Best Regards to all
Posted by David Van Couvering at 10:43 AM 0 comments Links to this post
Labels: culture
With the recent release of Derby 10.3, it's relevant to ask - what happens to the database you created with an older version when you upgrade Derby or Java DB?
Well, Derby is focused on ease of administration and embedded use, and this includes seriously painless upgrade.
There are two types of upgrade: soft upgrade and full upgrade.
With soft upgrade, you can use a new driver to work with a database created under a previous version, but older drivers will still be able to work with the database too -- the database itself is not upgraded to the newer version/format.
This is convenient if you want to just try things out, or if you have a mixed environment where some users are still using older versions of the driver.
The drawback of this approach is that if there are new features in the newer version that rely on a new database format or new system metadata, etc., then you can't take advantage of those new features. For example, Derby 10.3 has added features for security, SQL, and administration that won't work with an older database.
That is where full upgrade comes in.
You don't need to do anything crazy like export all your data, create a new database, and recreate your tables and load your data. All you have to do is set the "upgrade" property to "true" when you connect to the database.
There are two ways to do this. You can set it as a property directly in the URL, e.g
"jdbc:derby:travel;upgrade=true"or you can add it as a property when you get the connection, e.g.
One important caveat: if you have created a database with a non-GA version of Java DB you can not upgrade it. This is because there is no commitment to support upgrade from what is basically an experimental database. All this mean is, please don't deploy a production solution using Java DB with a beta version of Java DB.
String dbURL = "jdbc:derby:travel";
Properties connProps = new Properties();
connProps.put("upgrade", "true");
Connection conn = DriverManager.getConnection(dbURL, connProps);
Posted by David Van Couvering at 9:55 AM 1 comments Links to this post
Labels: databases, technology
From an interview with Larry Ellison:
Regarding future challenges, Ellison dismisses open source as a threat to Oracle.
"Open source is not something to be feared. Open source is something to be explained. Open source wins not because it's open and not because it's free. Open source wins only when it's better," he says.
To me this is another example of Oracle trying to address open source by dismissing it. Of course people only choose something because it is better. But Larry doesn't acknowledge that open source is inherently better because it is open and free.
When it is open, it allows for innovation. When it is open, it prevents you from getting locked into a single vendor. Both OEMs and customers trust it because it is not controlled by someone who may be a competitor either in business or politics. When it is free, it delivers significant price/performance benefits.
Larry goes on to say
the purchase price of software is only about 10 percent of the total cost of ownership of software. So even if the software is free, the most you can save is 10 percent off. Now the question is, what are your other costs of developing applications, of running applications on a daily basis, of dealing with problems when they occur? We think that Oracle is absolutely very competitive with open source
I think what Larry is saying here is that open source, if it is poor quality, gives you longer-term higher costs in terms of day-to-day maintenance. But I don't know if there is any data that shows that PostgreSQL or MySQL is not as stable or reliable as Oracle. And here again he is missing the value of open source: the community makes open source more reliable over time, because there are more eyeballs and more people making fixes. It's true for security, and it's true for quality.
My general feeling is, Larry is trying to pooh-pooh open source, because his customers are looking very closely at lower-cost and independent solutions. So Oracle's job is to dismiss and scare and keep their customers from taking open source databases seriously. But if I were Oracle, I'd be checking my rear-view mirror, because history has shown that open source goes where you never expect it would go: operating systems, applications servers, office suites, and, yes, enterprise databases.
Posted by David Van Couvering at 2:44 PM 1 comments Links to this post
Sun India is having an open source coding contest for university students across India called Code For Freedom - in honor of the freedom of open source and the freedom of India found 60 years ago.
From the site:
Sun Microsystems is happy to announce the Code For Freedom contest where students across India contribute to the technologies that are empowering the participation age. Participating in this contest will provide you with precious industry experience while still learning in college. And there is more. We in turn reward you for your valuable contribution in taking the first steps towards the open source movement.
For more information, see http://in.sun.com/communities/univ/codeforfreedom/
Posted by David Van Couvering at 2:38 PM 1 comments Links to this post

This week celebrates 60 years of independence for India. I have always, always been struck with the way that India obtained its independence. Here in America, we fought with gun and musket; in India, it was fought completely with non-violent means. As always, India is giving the world deep and profound teachings.
Many people complain about our jobs being taken to India. But I know for a fact that Indians have been a huge component of the technical revolution from the beginning. And I want to honor and thank all of the contributions from the great Indian community.
I also want to thank India for giving me personally a vast and deep ocean of wisdom from which I can draw. Great statements such as tat tvam asi ("Thou Art That") and chittam mantraha ("The mind is mantra") have been food for years of contemplation and practice.
And the Indian people - sweet, kind, patient, funny, hard-working, passionate, disciplined. I want to thank and honor all of my Indian friends and colleagues.
Happy Independence Day!
Posted by David Van Couvering at 2:29 PM 1 comments Links to this post

A great interview with Alan Weisman, who has a book out which predicts what would happen if humans were to disappear tomorrow. I've always wondered what it would be like if/when nature takes over.
Posted by David Van Couvering at 1:57 PM 0 comments Links to this post
Labels: green
This email from Bruno Souza, community manager for NetBeans, outlines the plans to provide an EA version of NetBeans 6 that will be dual-licensed with CDDL and GPL v2 with Classpath exception. Very cool!
For more information, see the FAQ.
Posted by David Van Couvering at 12:12 PM 0 comments Links to this post
Labels: technology
![]() | ![]() |
Posted by David Van Couvering at 11:20 AM 0 comments Links to this post
Labels: databases, technology
Roumen hits the same frustration that I did about varying Wiki formats. Someone please save us all...
Posted by David Van Couvering at 8:58 PM 0 comments Links to this post
Labels: technology
Alex Bunardzic presents a series of blogs on the concept of Resource Oriented Architecture, or ROA. He is emphasizing the fact that a resource and its representation are two different things, and a model of web-based programming that embraces this.
http://jooto.com/blog/index.php/category/resource-oriented-architecture/
Posted by David Van Couvering at 7:32 PM 0 comments Links to this post
Labels: technology
An interesting forum thread discussing the problems of too many frameworks and too much complexity . I really liked evickroy's comment about how easy it is to deploy Java WebStart apps. I wouldn't mind seeing more of that...
http://forums.java.net/jive/thread.jspa?messageID=230579&tstart=0#230579
Posted by David Van Couvering at 4:50 PM 0 comments Links to this post
Labels: technology
One blogger's take on VMWare Fusion vs. Parallels. Fusion is looking pretty attractive...
http://www.damnhandy.com/2007/08/13/where-vmware-fusion-shines-over-parallels-desktop/
Posted by David Van Couvering at 4:50 PM 0 comments Links to this post
Labels: technology
A great blog, particularly his post-script. Here's one smart techie with his thoughts on the future. Interesting comments on Erlang.
http://www.tbray.org/ongoing/When/200x/2007/08/13/Prognostication
Posted by David Van Couvering at 4:50 PM 0 comments Links to this post
Labels: technology
I am sooo glad this guy is still writing. This one is just a gem. Siooma!
http://fakesteve.blogspot.com/2007/08/my-lunch-with-fester.html
Posted by David Van Couvering at 4:50 PM 0 comments Links to this post
Labels: technology

I am a subscriber to Science News, and I always learn at least one new cool thing in each issue. The July 21 edition had an article where scientists have uncovered that England was separated from the rest of Europe by a single mega-flood when a huge lake from the melting ice of the last ice age burst its banks. Sorry, you have to be a subscriber to read this, but the New Scientist has a for-free article on this.
There are many examples of sudden massive geologic and ecological change like this. Another megaflood I learned about yesterday from my brother was the one from another ice-age lake bursting that carved out the Channeled Scablands in Washington. This flood came all the way from Montana.
Then there are the super-volcanos that cause mass extinctions and the comet and asteroid hits, including the one that eliminated dinosaurs.
Interesting, but so what, right?
Well, Pa was explaining what is happening with the Greenland Ice Sheet. This sheet is the last remnant of the last Ice Age, and in some areas is many miles deep. And it is melting very rapidly as the melting water lubricates the sheet where it grips the rock. Many of us know this, but what isn't talked about much (at least I couldn't find anything) is how quickly this could actually happen.
According to my father, it's possible that the Greenland Ice Sheet will literally slide off the rock like snow slides off a metal roof once it melts to a certain point, and that sea levels will rise 20 feet not in 100 or 500 years but in just a few years. Moving vast populations of our coastal cities 20 feet uphill in a matter of a few years: doesn't sound like fun.
It's uncomfortable hearing these things from a fairly cynical scientist. He also made me aware of methane hydrates and the methane cycle. Methane is actually a significantly more powerful greenhouse gas than carbon dioxide. And if the oceans get too warm, vast amounts of methane currently frozen up in methane hydrates may be released, increasing global warming and releasing more hydrates and and and...
In a great book called A Short History of Nearly Everything, I read that the situation where we have temperate zones and an ice sheet is a very very rare situation for Earth. It is much more common to have a