Is Human Immortality Possible?

It sure is.

I was reading an interesting article about "shared-death" experiences, in which a skeptic claims an "immortal soul" is impossible because there is no physical mechanism by which human cognition could continue after death. This is a straightforward and common position, but there are several alternatives that could make it invalid; here are a few of my favourites.

One possibility is that we live in a simulation. If we do, then the simulator could capture our mental states at the moment of death and continue simulating them in another context. This doesn't violate any physical laws and strictly speaking, it's compatible with atheism. It even seems plausible in the sense that (given enough resources) we could ourselves simulate a universe (not like ours) in which intelligent life exists and we implement an afterlife for those beings.

Another possibility, probably still the most popular one, is that dualism is true after all --- that souls exist and interact with the brain in some manner to produce consciousness. There are still some strong arguments for this.

However, if a God exists who cares about us, then he can implement an afterlife even if we don't have persistent souls. Basically he can take the role of the simulator in the simulation argument. (There are some important differences between the simulation argument and theism, e.g. the simulator(s) would not be omniscient, but those differences aren't relevant here.) When we die, he continues running our minds in some other context, and ultimately creates new bodies for them. In a Christian context, this would be Christian physicalism. (Personally I'm somewhere between dualism and Christian physicalism.)

Another basis for immortality that does not require theism is any multiverse theory that implies the existence an infinite number of universes like our own, e.g. the many-worlds interpretation of quantum physics, or eternal inflation. Such a theory (combined with the assumption of materialism) implies that any given mental state appears in an infinite number of contexts. In particular, there are (an infinite number of) mental states of people who remember being "you" dying. (Permutation City is a good book based on this.)

Any or all of these options may seem far-fetched, but each of them are taken seriously by respectable thinkers.

In the context of the original article, I think of those possibilities dualism has the most power to explain near-death or shared-death experiences, followed by the theistic or quasi-theistic possibilities of an intentionally-implemented afterlife.

One more thing:

“That’s the problem with all of them – they’re all anecdotal evidence and science doesn’t deal with anecdotal evidence,” Nickell says.

Indeed, but that represents a limitation of science, not a limitation on what's true. That Napoleon was defeated at Waterloo is not a scientific fact, but it's still a fact.

Queen Charlotte Track

From Sunday to Wednesday I was walking the Queen Charlotte Track with family in the Marlborough Sounds. The weather was excellent; the whole trip was wonderful.

It's a 71km walk and we did it in four days. We flew from Auckland to Blenheim on Saturday and stayed in Picton on Saturday night. On Sunday morning we took a Cougar Line boat to the start of the track at Ship Cove (where Captain Cook careened and resupplied his ships on five separate occasions), then spent five hours walking to "The Woolshed", homestay-ish accommodation at the head of Endeavour Inlet. Remarkably, though the lodges and homes around the Endeavour Inlet are far from any road, they have mains electricity and broadband Internet connectivity good enough to stream video.

The next day we walked three-and-a-half hours to stay at Punga Cove Resort, arriving before 11:30am. Since we had so much time left in the day I decided to try a solo side trip from the resort (sea level) to the summit of Mt Stokes --- at 1200m, the highest point in the Sounds region. I didn't really know what I was letting myself in for; Mt Stokes was nearly 7 hours return from the resort, and a tough uphill slog for much of that, so I was quite exhausted when I finally got back to Punga Cove around 6:15pm. However it was definitely worth it for the amazing views.

Tuesday was the toughest day for the rest of our group, as we walked for about eight hours from Punga Cove along ridges all the way to Portage, staying at Debrett's Backpackers. It's just a long day of up-and-down. We had a decent rest at Black Rock Shelter, which has magnificent views over the Sounds to Picton with snow-capped mountains in the far distance.

Wednesday, yesterday, we did another six hours to reach the trail end at Anikawa around 2:45pm.

The places we stayed were each quite different in character, but all very good. We ate out every night (at Furneaux Lodge, at Punga Cove Resort, and at the Portage Hotel); all the meals were expensive but all also very tasty. We didn't have to carry sleeping bags or cooking gear; we could have made the walk even easier by using the boat service to ferry our overnight bags from one location to the next, but didn't.

This is a really lovely walk and was a great way to experience the Marlborough Sounds. The Sounds are beautiful --- lots of ocean, coastline, hills and islands almost entirely covered with different kinds of native forest. The track is in excellent condition, long but not difficult. You constantly feel compelled to stop and take a photograph of the dazzling view. A remarkable place; a great trip.

rr 3.0 Released With x86-64 Support

I just pushed the release of rr 3.0. The big milestone for this release is that x86-64 support is fully functional! On 64-bit machines, we build a 64-bit rr that can record and replay 64-bit processes with the same set of features and performance-enhancing tricks that we developed for 32-bit. Not only that, but 64-bit rr can also record and replay 32-bit processes or even a mix of 32-bit and 64-bit processes in the same process tree. 64-bit support is mostly due to Nathan Froyd and we hope it significantly lowers barriers to using rr.

Many other internal improvements and sundry bug fixes have landed since 2.0. Some highlights:

• rr can record executables that use a #! interpreter, e.g. bash scripts. Naturally the entire process tree is recorded, so this simplifies debugging of applications that use complex wrapper scripts.
• A new rr ps command lists the processes recorded in an rr trace, making it easier to select the process you want to debug.
• To make that even easier, rr replay -p <command> automatically attaches to the first exec of <command>. E.g. to debug e10s Firefox's first content process, use rr replay -p plugin-container.
• Sometimes you record a trace, then modify the program but later want to replay the original trace, which requires the original program binaries. rr now uses hardlinks to save files in the trace so that in many cases, old traces are still replayable after a rebuild. Thanks to Karl Tomlinson for the idea.
• Some small changes in command-line syntax were made to regularize the syntax and prepare for future expansion.
• Many bug fixes to broaden the range of recordable applications. E.g. LibreOffice and QEMU work now.

Development carries on; visit rr-dev for exciting updates.

Have fun using rr!

Portland

Portland was one of the best Mozilla events I've ever attended --- possibly the very best. I say this despite the fact I had a cough the whole week (starting before I arrived), I had inadequate amounts of poor sleep, my social skills for large-group settings are meagre, and I fled the party when the music started.

I feel great about Portland because I spent almost all of each workday talking to people and almost every discussion felt productive. In most work weeks I run out of interesting things to talk about and fall back to the laptop, and/or we have lengthy frustrating discussions where we can't solve a problem or can't reach an agreement, but that didn't really happen this time. Some of my conversations had disagreements, but either we had a constructive and efficient exchange of views or we actually reached consensus.

A good example of the latter is a discussion I led about the future of painting in Gecko, in which I outlined a nebulous plan to fix the issues we currently have in painting and layer construction on the layout side. Bas brought up ideas about GPU-based painting which at first didn't seem to fit well with my plans, but later we were able to sketch a combined design that satisfies everything. I learned a lot in the process.

Another discussion where I learned a lot was with Jason about using rr for record-and-replay JS debugging. Before last week I wasn't sure if it was feasible, but after brainstorming with Jason I think we've figured out how to do it in a straightforward (but clever) way.

Portland also reemphasized to me just how excellent are the people in the Platform team, and other teams too. Just wandering around randomly, I'd almost immediately run into someone I think is amazing. We are outnumbered, but I find it hard to believe that anyone outguns us per capita.

There were lots of great events and people that I missed and wish I hadn't (sorry Doug!), but I feel I made good use of the time so I have few regrets. For the same reason I wasn't bothered by the scheduling chaos. I hear some people felt sad that they missed out on activities, but as often in life, it's a mistake to focus on what you didn't do.

During the week I reflected on my role in the project, finding the right ways to use the power I have, and getting older. I plan to blog about those a bit.

I played board games every night, mostly Bang! and Catan. It was great fun but I probably should cut back a bit next time. Then again, for me it was a more effective way to meet interesting strangers than the organized mixer party event we had.

We Aren't Really Going To Have "Firefox On iOS"

Whatever we decide to do, we won't be porting Firefox as we know it to iOS, unless Apple makes major changes to their App Store policies. The principal issue is that on iOS, the only software Apple allows to download content from the Internet and execute it is their built-in iOS Webkit component. Under that policy, every browser --- including iOS Chrome, for example --- must be some kind of front-end to Apple's Webkit. Thus, from the point of view of Web authors --- and users encountering Web compatibility issues --- all iOS browsers behave like Safari, even when they are named after other browsers. There is some ability to extend the Webkit component but in most areas, engine performance and features are restricted to whatever Safari has.

I certainly support having a product on iOS and I don't necessarily object to calling it Firefox as long as we're very clear in our messaging. To some extent users and Web developers have already acclimatised to a similar confusing situation with iOS Chrome. It's not exactly the same situation: the difference between iOS Chrome and real Chrome is smaller than the difference between iOS Firefox and real Firefox because Blink shares heritage and still much code with Webkit. But both differences are rapidly growing since there's a ton of new Web features that Chrome and Firefox have that Webkit doesn't (e.g. WebRTC, Web Components, ES6 features, Web Animations).

In the meantime I think we need to avoid making pithy statements like "we're bringing Firefox to iOS".