Sunday, August 31, 2014

Ireland Day Three: The Ring of Kerry

Our room is so comfortable that we sleep late.

But hey! It's our 29th anniversary. I think we are allowed.

We pile in the car and set out on the Ring of Kerry.

As described by several books (esp. Rick Steves), we are driving clockwise, while the tour buses always drive counter-clockwise. The main point of this is that the attractions that we visit in the morning are those which the tour buses will visit in the afternoon, thus hopefully we avoid most of that activity.

Our first stop is Staigue Fort, a prehistoric ring fort built at the top of a river canyon with a commanding view of the bay. For a 2,500 year old building, it is in remarkably good shape.

The walls are built of large flat stones laid without mortar, but the stones haven't budged an inch and are as solid as you could imagine. An ingenious arrangement of open staircases inside the ring allows you to easily climb to the top of the walls.

The only entrance is narrow, set such that you have to inch through sideways.

A large moat around the outside makes the walls effectively 25 feet tall. It is easy to see how this fort provided a formidable and effective defense for centuries.

Our second stop is Derrynane House, home of Daniel O'Connell, "the liberator."

The house is set on a beautiful plot of land on the waterfront, and there are acres of walking trails to explore, wandering through meadows and beaches.

Daniel O'Connell's house, itself, isn't all that interesting, but his life is fascinating beyond words.

As a youth he witnessed the French Revolution firsthand, while studying in Paris.

He became a lawyer and practiced trial law in Dublin, becoming one of the most famous and successful lawyers of his time. He was challenged to a duel at the conclusion of a case and killed his challenger (the pistols are displayed at the house).

He founded the Catholic Organization and grew it to hundreds of thousands of members in just a few years. He ran for election and was elected the first Catholic Member of Parliament. He refused to take the Oath of Supremacy, resulting in Parliament overturning the law.

He organized the "Monster Meetings" to protect the treatment of Catholics and was thrown into jail. When he was freed, he was paraded through Dublin on an enormous chariot (also on display at the house).

After leaving Derrynane, we make our way through Waterville and out the Skellig Ring to St. Finian's Bay. The Skelligs Chocolate Factory makes yummy chocolate, though we have been misled by the guidebooks into anticipating that their cafe had food for lunch.

We walk down to the beach and write our names in the sand.

Coming back through Ballinskelligs, Donna spies a castle and we stop to investigate (already, one of our Rules For Traveling In Ireland has become: "when you see a castle, stop").

We find ourselves at Ballinskelligs beach, where there is a lovely little beach cafe where I have a scone and Donna has cabbage and potato soup.

Then we walk down to ruined McCarthy's Castle and Donna climbs to the top of the walls (this will become a pattern throughout the trip, as well!).

Then we walk up the beach to the ruins of the old Augustinian Priory, which it turns out was founded by the Skellig Michael monks and subsequently destroyed by Cromwell.

The beach is a most fascinating discovery; we later decide that this is our favorite spot in all of Ireland: ocean, mountains, beaches, castles, churches, and lunch.

On our return to Parknasilla, we enjoy some of the paths through the grounds, and we're particularly taken by their delightful Fairy Tale Walk (according to the Internet, there was another such trail at Derrynane Park, but somehow we missed it, sigh).

Ireland Day Two: Dingle

For some reason, I am awake early. We enjoy the hotel's breakfast buffet, but soon I am ready to leave.

Just down the road is Adare's Augustinian Abbey, which dates back to the 13th century but is now the parish Anglican church. The deacon is there, and tells us that, this spring, storms struck the area. There was a bad day: trees fell down, the Abbey's roof was damaged. He has opened the church and we visit briefly, pay our respects, and move on.

We have decided to avoid Tralee. The Rose of Tralee Festival is underway, and even though it would be fun to attend, we are more interested in visiting Dingle.

When we were preparing to visit Ireland, we spoke to many people. Person after person told us to visit Dingle. After a while, I lost count; still, it was a nearly universal suggestion. Because of our itinerary, this is our only chance to see Dingle, so today it must be, and today it will be.

We drive out of County Clare and into County Kerry, stopping briefly at the overlook above Castleisland to take in the marvelous view.

We strike west, out on to the peninsula, and stop for a walk on Inch Beach. The wind is howling; dogs are barking; children are playing, surfers are riding the waves. It is a special place.

On we go, and finally we arrive in Dingle, which is just as delightful as everyone promised it would be. A beautiful harbor, fun shops, and a great ice cream store with locally-made ice cream: "carmelized brown bread" is the flavor we choose.

We buy a bit of this and that. Today is the annual Dingle Regatta; youths are racing boats on the harbor.

Time is passing; we leave Dingle around 2:30 PM and drive to Killarney by way of Killorglin and the Ring of Kerry. Killorglin, of course, is the home of the famous Puck Fair, but we are one week too late.

Along the road, we have been noticing a large gray bird with black wings and a black head. Once we get some Internet service, we do a bit of research; it turns out that these are Hooded Crows, common to this area but completely new to us.

Somewhere between Killorglin and Killarney we pass Fossa and Aghadoe, but I am unaware and we just zoom on by. I'm not sure why my guide books didn't alert me more to Aghadoe, as I think I would have really enjoyed stopping there.

By 3:15 or so we are in Killarney. It is time to get out of the car, so we park in the lot at St Mary's Cathedral, which is truly a magnificent church, and we spend some time there. We walk into downtown Killarney and tour the shops; it is a fun place to while away the hours.

I stop into the local pub for a moment, my attention attracted by the game on TV. It is Gaelic Football, a most unique game, played only here in Southwest Ireland. It turns out that we drove right past the GAA field in Fossa just before we entered Killarney; I noticed that there were players on the field, but otherwise had no idea. The match on TV is Tipperary vs Cork, an important and hotly-contested battle, and we watch for a while.

The drive from Killarney to Sneem is extremely dramatic, past lakes and mountains, winding along the cliffside, often only a single lane road, with massive tour buses racing along in the opposite direction. Eventually, we reach Sneem, and Parknasilla Resort, site of our anniversary celebratin, and an oasis of calm and beauty and a destination well worth the trip.

As you can tell by the view from our room!

Saturday, August 30, 2014

Ireland Day One: Arriving and Driving

Because of the carriers we used, we found ourselves flying in and out of the brand new Terminal 2 (the "Queen's Terminal") at London Heathrow. This is truly a beautiful facility and I was very impressed by it: spacious but easy to navigate, with nice shops and restaurants and plenty of seating to accomodate travelers with time to spare.

Perhaps I should say a bit more about those "shops and restaurants", though. We had two very nice meals at the WonderTree Cafe in Terminal 2, and I recommend it highly. But the signature shops and restaurants for which Terminal 2 is known are, well, pretty high end (Burberry, Gucci, Bulgari, Bottega Veneta, Harrods, etc.); perhaps you might want to have a look at the menu for the Prunier Seafood Bar?

Enough of that; it's on to Ireland!

Our Aer Lingus flight to Shannon airport takes barely an hour, although unfortunately the cloud cover is extensive and I am only able to see a little bit at takeoff and a little bit at landing, enough though I suspect we flew over some beautiful territory (Wales, St George's Channel, as well as most of south-central Ireland).

Shannon Airport is small and friendly and easy to handle. We simply walked across the street from the terminal to the car park to pick up our rented Renault and we were off on the Great Ireland Adventure!

We deliberately scheduled an extremely short trip on our first day in Ireland, because we knew that it would take some time to get the hang of driving in Ireland.

Really, though, there are only four elements to master in order to drive in Ireland:

  1. Drive on the left.

    In Ireland, you drive on the opposite side of the road as compared to America, and the steering wheel is on the opposite side of the vehicle. I kept chanting to myself: "look to the right, keep to the left". But really, this didn't take very long to get used to; I was rather surprised about that.

    It did seem like, each morning, I would have to re-remind myself about how things go, and it was a bit of a challenge to re-train myself to look over the correct shoulder when I was checking for things in my mirrors.

  2. Get the hang of the roundabouts.

    In Ireland (at least in the areas we visited), there are almost no traffic lights or stop signs. Instead, most intersections are roundabouts, so you need to know how to navigate a roundabout properly. Mostly that means:

    • Look to your right when entering the roundabout
    • Yield to the traffic already in the roundabout before entering it
    • Pay attention to the sign as you're approaching the roundabout, so that you know which exit you want as you leave the roundabout
    Heck, it's really not that hard: just look at the video.
  3. Distances and speeds are in Kilometers, not in Miles.

    So when you see that the speed limit through town is 50 km/hr, you instinctively might think that's rather startling, because 50 MPH in America is far too fast to drive through these tiny villages. But, of course, 50 km/hr is much slower, and perfectly appropriate.

  4. Drive country roads carefully.

    In the part of Ireland we were visiting, there were only a few super speedways (called "motorways" in Ireland). Most of the roads we found ourselves driving were absolutely gorgeous, among the most scenic roads I've ever driven in my life, but they were narrow, curvy, and had very restricted visibility. So just

    • Go slow
    • Give the other drivers plenty of room
    • Be patient
    • Enjoy the beauty of the roads
    • Oh, and yes: go slow!
    It frequently amused us to see a sign on a country road telling us that the speed limit was 80 km/hr or even 100 km/hr, when the road itself could clearly be driven only at 40, 50, or 60 km/hr.

    Driving the country roads safely was definitely the most challenging part of driving in Ireland, but I'm pleased to report that we had a trouble-free time of it!

So, anyway, we left the airport and got on the road.

A few miles from Shannon Airport is Bunratty Castle and Folk Park, an interesting place.

If you've read McCarthy's Bar, you'll recall that Bunratty Castle is the site of the funniest episode in the entire book, an absolutely hilarious adventure involving country roads, pubs, a medieval banquet, and two sisters from Philadelphia who have brought their children to Ireland.

Really, you have to read the book.

I wish we had taken the time to go in to Bunratty Castle and take the tour and visit the park, but we were still Ireland novices and I made a bad decision and decided to push on. This was perhaps one of only two bad decisions I made in Ireland about where to go and what to do, so I'm not going to beat myself up about it too much, but I'm definitely a bit disappointed to have only seen the castle from the outside (where it is still quite impressive).

So after waving to some of the children who were Way Up There at the top of the castle, we climb back into the car and venture on.

We drive into downtown Limerick and walk through the busy commercial center. We get some nice shots of King John's Castle from the river front, pick up a few necessities from the Dunnes Store in Limerick ("Umbrellas! How did we fail to pack umbrellas?"), and on we go.

We take the motorway out of Limerick, then exit to the N21. Just 4 km before Adare, traffic crawls to a stop and Garda with alert lights flashing zip by us. We crawl into Adare at barely 10 km/hr, but the scenery is delightful and, did I mention this, WE'RE IN IRELAND!

As we reach Adare, the problem is clear: a tourist bus has broken down. But here is our destination, the Dunraven Arms Hotel! A wedding is underway and we must park far, far in the back.

The hotel is a delight. Quaint as all get out, but comfortable and stylish at the same time. Our room is beautiful, with a four poster bed and a large window onto a lovely courtyard garden.

We walk through the gardens and the swallows are everywhere, swooping and darting and catching dinner. It seems there is a nest in every awning and eave.

Adare is often called "the prettiest village in Ireland" and with good reason. Thatched houses line the street, centuries-old abbey and friaries are just off the road, and the thousand year old castle is just across the river.

We walk up and down the town streets, buying some fudge from a local creamery, and later having a Beamish and a Caledonia Smooth to accompany our sandwich and soup at Auntie Lena's Pub.

After our meal, we walk through the Adare Town Park, which is far too scenic and pleasant for that simple name, then return to the hotel to unwind, check email, and plan the next day.

Friday, August 29, 2014

Central London in Two Days: Day Two

We slept like exhausted travelers, but awoke refreshed and ready for more. Could we have a better second day? Why not?

We popped back on the Tube and exited at Westminster, hoping that by arriving early we'd have fewer crowds.

After a short wait, we are inside Westminster Abbey, where we pick up headsets for the audio tour (narrated by Jeremy Irons).

Touring Westminster Abbey is extremely fascinating. To start with, it is a beautiful building, with plenty of art and architecture to experience.

And it is packed with history and tradition. Just the day before, while viewing the Crown Jewels, we had paused to view the video of Queen Elizabeth II's coronation in 1953, so it was quite interesting to be standing in Westminster Abbey, just a few feet from the raised platform where the coronation occurred, and to see the Coronation Chair (now no longer with the Stone of Scone).

But Westminster Abbey is also overwhelming; a thousand years of history, religion, arts and sciences, warfare and country are all jumbled together and deposited upon us at once.

For myself, I was most taken by the tombs and memorials to the scientists (Newton, Darwin, John Harrison, etc.), and the artists (Chaucer, George Frideric Handel, etc.), but I do try to pay attention to the Kings and Queens.

(I must admit to be rather naive or uneducated in one respect: for some reason it didn't occur to me that everyone was buried in the church itself; I somehow had it in my head that churches were churches and graveyards were graveyards, but at any rate, as Donna says, I'm not confused about that anymore.)

After what seemed like hours of viewing the Abbey, we were both quite pleased, but also thoroughly tired, so when we found ourselves in the old 13th century monastery section of the Abbey (called the Cellarium), where to our surprise there was a delightful small cafe, we immediately stopped in.

Donna, in a moment of inspiration, spots that they are serving high tea, and so we have our tea, scones and all, and it was just superb!

After finishing our tea, we walk and walk and walk.

We cross through Parliament Square and over to St James's Park, where we walk through the park along the lake. Most of the birds are quite familiar (ducks, geese, swans, pelicans, coots, etc.) but it is fun to see them here in the heart of the city, and all the passers-by are delighted by them.

I was confused by the maps I'd read into thinking that Buckingham Palace Gardens is an open space like the other royal parks, but of course it is not, so we detour a few blocks and walk over into Belgravia, by Eaton Square and up Upper Belgrave Street.

We walk past simply dozens of foreign embassies; I have fun guessing them as we approach by spotting their flags.

Near the French Embassy in Knightsbridge, we enter Hyde Park. This can be confusing to us Yanks, because in New York, Hyde Park is a town (home of FDR), and in Illinois, Hyde Park is a town (well, a neighborhood of Chicago), but in London, Hyde Park is a park.

Anyway, we walked along the Serpentine as children played on the shore and paddleboats coasted gently through the water.

Just before we arrive at the bridge over the Serpentine, we arrive at the Lady Diana Memorial Fountain. As we near the fountain, the sun is shining and children are playing in the water.

The memorial is open, informal, and family-friendly, with little pomp or ceremony; in this way it seems to me entirely appropriate for Diana.

Just a short distance away (is this coincidence?) is another memorial to another unusual royal: the Albert Memorial. While the Victoria Memorial is right in front of Buckingham Palace, the Prince Consort's memorial is miles away in South Ken, but visually the two memorials have much in common: both are massive pedestals, adorned with statues and embellishments, and topped with gold figures.

We walk down through South Kensington past the Royal Albert Hall and by the V & A museum, its entranceway mobbed with families and street vendors.

The Royal Albert Hall, I notice, is holding its summertime series of "prom concerts," which I later look up and discover means "promenade" concerts, originally because they were held outside and the audience walked around freely, but which now means that you stand up for the show in standing-only areas!

From South Ken we ride the Underground on the District Line over to Temple. We walk up the Strand past the Royal Courts of Justice and Temple Bar, admiring the various sights along the way.

When the Strand becomes Fleet Street we stop at tiny Twining's Tea shop: 305 years in the same location!

We pass two other Christopher Wren churches, then read the magnificent St Paul's Cathedral with its enormous dome. We can just barely make out visitors enjoying the view from the tower atop the dome, but there is no time to rest, we have much more to do!

We walk down and across the delightful Millenium Bridge. A street artist has been working here this summer, painstakingly painting tiny micro-paintings between the non-skid bumps on the bridge's walkway.

He is there on the bridge now, talking with tourists and fans, and we stop and photograph some of his work.

We admire the reconstructed Globe Theatre. An afternoon show is in progress, so we can't take the tour, but we are amused when we see a number of actors come running around the side of the theatre and disappear through a back door, evidently exiting "stage left" in order to re-enter "stage right".

We walk along the south bank of the Thames. Past Blackfriar's Bridge we stop in Doggett's for a pint of Marston's and a rest. Fortified, we walk along the river until we reach the London Eye, passing a nifty statue of Laurence Olivier out in front of the National Theatre.

A large summer festival is taking place along the waterfront and the area between the Eye and County Hall is jammed.

We snap the classic pictures of the Houses of Parliament and Big Ben across the river, then cross Westminster Bridge.

We take the Tube back to the hotel and use the (free!) guest laundry while sharing a plate of fish and chips and watching the Bayonne vs Toulon rugby match on T.V.

I am baffled by Rugby.

But the fish and chips is delicious.

Thursday, August 28, 2014

Two days in Central London: Day One

We found ourselves with two entire days to explore Central London.

The weather was glorious (at least, it seemed glorious to us), and, since neither of us had ever been to London, everything was new and exciting and interesting and fascinating.

So, naturally, it wasn't a question of what to do, but rather of trying not to overdo it.

Which I don't think we totally achieved, but still, we had a fabulous two days!

Here's how Day One went.

We got off the Underground at Green Park and walked through the park to Buckingham Palace.

We spent a while admiring the Victoria Memorial, and the palace gates, and the Queen's Guard, and the whole scene, then we walked down past the Wellington Barracks and the Ministry of Justice to Parliament Square.

It was already 11:00 AM, and there was an imposing line at Westminster Abbey, and so we decided to defer the tour. So we took pictures of Big Ben, just as it was tolling the hour.

We walked around to the back side of the Houses of Parliament (known as Victoria Tower Gardens, where unfortunately the Rodin sculpture The Burghers of Calais was not on display because it was out on loan to the Henry Moore Museum), because somehow I thought that we'd be able to walk entirely around Parliament, but of course you can't; you can only walk to the edge of the Thames but not along it, there.

So we walked back, past the statues of Richard Lionheart and Oliver Cromwell, and started walking up Whitehall.

As we went, we were accompanied by the Horse Guard, who were just changing the guard at that moment. It was so much fun to watch them that we walked right past Number 10 Downing Street without even noticing it.

I did enjoy seeing the Banqueting House, and the Gwydyr House of Wales, and the back side of the Ministry of Defense, and a few other buildings along Whitehall.

And found ourselves at Trafalgar Square, staring up at Admiral Nelson on his perch.

We made our way through Leicester Square and on into Covent Garden. I particularly enjoyed the "Seven Dials" intersection, and we both had fun walking through Neal's Yard, which was just as colorful and eccentric as the Internet had promised it would be.

We were feeling a bit peaked, so we took a break and stopped at the Bloomsbury Tavern on Shaftesbury Avenue to rest for a bit.

Suitably revived, we cross a street or two and find ourselves at the British Museum, the sun shining brilliantly, the courtyard jammed with families picnicking, children running about. We stop at one of the food trucks and split a sandwich.

Oh, dear reader, you will find this horrifying, appalling, but it is true: we toured the British Museum in one hour.

What do you see in just that time? Well: the Rosetta Stone; the Parthenon Marbles; the Lewis Chessmen; Egyptian mummies; Persian ceramics; Roman statues. Someday maybe I will have a week just to visit the museum, but for this day an hour made do.

Coming out of the museum there was a light rain coming down, so we high-tailed it to Holborn Station and rode the tube down to Tower Hill, transferring at the unspeakably complex Bank/Monument transfer station.

We arrived at the Tower of London just after 3:00 PM.

Can you see the entire Tower of London in two hours?

Why yes, you can!

The White Tower, the Bloody Tower, the Traitor's Gate, the Wall Walk, the Crown Jewels, the Royal Armor, the inner and outer yards, the ravens, the Scaffold Site.

Wait, did I mention the CROWN JEWELS?!

Two hours, in many ways, is just about the perfect amount of time to spend at the Tower of London. You certainly could spend more, and there was certainly more to see, but we saw everything we wanted and saw as much of it as we wanted.

And we were both fascinated by the art exhibit taking place on the grounds of the tower: Blood Swept Lands and Seas of Red.

The rain was becoming more steady, so we rode over to Victoria Station and I had a Doom Bar in the Belgravia Pub. It was a nice enough place, but the cigarette smoke in all the pubs is rather hard on a reformed smoker, so we decided to look elsewhere for dinner.

Down the road and around the corner was da Scalzo, an acceptable Italian restaurant, which served us an acceptable pizza, and it was time to declare the day done, and head back to the hotel.

The Art of Racing in the Rain: a very short review

One of the things about traveling, and about 10 hour trans-Atlantic plane flights in particular, is that you have a lot of time to read.

So I recently read Garth Stein's The Art of Racing in the Rain.

I envision that the author's thought process must have been something like this:

I know: what if I wrote a book from the point of view of the family dog?

That is, I'll have the dog be the narrator!

Hmmm... I'll need to have a story for the dog to tell.

Perhaps the story isn't all that important, because the interesting part is that it's told by the family dog.

Well, anyway, there you go.

Tuesday, August 26, 2014

Back to driving on the right side

We're back from a two week trip to Ireland and England.

I'll try to put up some pictures and thoughts over the next few days.

But right now ...

... must ...

... sleep


Tuesday, August 12, 2014

Kasparov fails in FIDE election

The world of professional chess is again in turmoil.

The results of the FIDE presidency election are in, and once again Kirsan Ilyumzhinov has been reelected.

Now both Karpov and Kasparov have failed to unseat Ilyumzhinov.

What will happen next?

I have no idea.

Monday, August 11, 2014

ShadowRun Returns: DragonFall: a very short review

Last spring I talked briefly about ShadowRun Returns.

I had a few spare hours over the summer, so I picked up ShadowRun Returns: DragonFall.

Yes, just as the other reviewers have said, DragonFall is even better!

Better writing, better characters, more interesting tactics, great locations.

These are fun games!

I hope the folk over at HareBrained Schemes can keep up the great work.

I may have to try playing StrikeFleet Omega on my wife's iPad one of these days...

Sunday, August 10, 2014

Fun Home: a very short review

Somewhat accidentally, I found myself reading Alison Bechdel's Fun Home: A Family Tragicomic.

Let me see if I can set the stage for you a little bit.

It's a graphic novel.

About childhood.

Called Fun Home.

Nope, you're wrong: whatever you're thinking, you're wrong.

The Fun Home of the title was the funeral home where Bechdel's father worked, and her story is anything but a gentle reminiscence of her peaceful childhood days.

Bechdel more-or-less takes three swings at describing her childhood: once as she saw it as a child, growing up; once as she revisited it once she was an adult and had moved away; and once with the benefit of time and reflection. All three viewpoints are intertwined and interleaved: she dances around, describing the same events and observations from different angles and distances.

The book is beautifully written and drawn, and the story is fascinating. Bechdel is a lively and literate author, and I found her literary allusions, her cultural observations, and her autobiographic reflections to be compelling, even riveting.

But the tale she tells is raw and heartbreaking, it is indeed a tragic story from a tragic time.

I'm glad I read it, although I guess I should be a little bit more careful what books I "stumble into," because here, to strain the old proverb, you certainly can't tell a book from its cover.

Saturday, August 9, 2014

git rebase

I've been studying the heck out of git rebase recently.

I mean, I've really been making an effort. It's no exaggeration to say that I've spent the last 3 months of my life having the primary focus of my (professional) life being to really, deeply, truly understand git rebase.

This is no trivial task. To start with, about all you can say about the documentation for git rebase is that it's a disaster. For a piece of software as powerful, flexible, and astonishingly amazing as git rebase, its official documentation is a mirror image of that. It's more than just badly written and misleading; it's almost as though it actively defies your attempt to understand.


With any piece of truly sophisticated software, I've found that there are always three levels of understanding:

  1. What does it do?
  2. How does it do that?
  3. WHY would you do that?

I think that software shares this with many other human creations, like cooking, or home repair, or jet aircraft design. At one level, there are recipes, and you can learn to follow the recipes, and make a nice Creme Brulee: now you know what the recipe does.

And then, you can study some more, and you can learn how the recipe works: that you cook the custard in a water bath to insulate the cream-egg mixture from the oven's heat and prevent the eggs from cooking too fast, and that you carmelize the sugar not just to change its taste, but also to provide a different dimension to the dessert by forming a hard shell over the smooth creamy custard below.

But you still don't know why you should use this recipe, when it is the right thing to do, and when it is not.

Well, anyway, I don't want to talk about cooking, because I'm an engineer at heart, not a chef.

Rather, I want to talk about git rebase.

And how hard it is to achieve that third level of understanding.

Because, even though the documentation is horrific (did I mention that already?), you can fairly quickly pick up the ideas about what you can do with git rebase:

  • Bring a branch up to date with its parent
  • Re-arrange the work in a branch, perhaps splitting it into several branches, or re-parenting it on a different parent branch
  • Revise the work in a branch, perhaps eliminating some of the work, excising some of the clutter left by mis-steps or dead ends or false summits, or re-ordering it, or collapsing and removing some of the intermediate steps

And, although the documentation doesn't help with this, you can, with a bit more study, understand how git rebase accomplishes these tasks.

To get a feel for how git rebase does what it does, let me recommend these resources:

  1. the Git Rebasing chapter in Scott Chacon's book
    In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.
  2. Git for Computer Scientists
    Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph.
  3. Git from the bottom up
    This state of affairs most directly represents what we’d like done: for our local, development branch Z to be based on the latest work in the main branch D. That’s why the command is called “rebase”, because it changes the base commit of the branch it’s run from.

Of course, there are many more resources for git, but these are among my favorites.

So after some amount of time reading, and experimenting, and thinking, you will find that you can understand what git rebase does, and how it does it.

But why? Why would you choose to forward-port commits? Why would you choose to re-order, re-word, squash, split, or fixup commits? What is the purpose of this incredibly powerful tool, and how are you ever going to understand how to use it properly, and not instead shy away from it in complete terror?

Unfortunately, I can no longer recall where I stumbled across this resource, but somehow I found Norman Yarvin's web site, where he has collected random collections of stuff.

And, one of those collections is an amazing series of email messages from Linus Torvalds (and a few others): git rebase.

Now, this is not easy stuff to read. Don't just plunge into it, until you've gone through the other resources first.

But when you're ready, and you've done your homework, go and read what Linus has to say about when and why you should use rebase, and think deeply about passages like:

But if you do a true merge, the bug is clearly in the merge (automatedly clean or not), and the blame is there too. IOW, you can blame me for screwing up. Now, I will say "oh, me bad, I didn't realize how subtle the interaction was", so it's not like I'll be all that contrite, but at least it's obvious where the blame lies.

In contrast, when you rebase, the same problem happens, but now a totally innocent commit is blamed just because it happened to no longer work in the location it was not tested in. The person who wrote that commit, the people who tested it and said it works, all that work is now basically worthless: the testing was done with another version, the original patch is bad, and the history and _reason_ for it being bad has been lost.

And there's literally nothing left to indicate the fact that the patch and the testing _used_ to be perfectly valid.

That may not sound like such a big deal, but what does that make of code review and tested-by, and the like? It just makes a mockery of trying to do a good job testing any sub-trees, when you know that eventually it will all quite possibly be pointless, and the fact that maybe the networking tree was tested exhaustively is all totally moot, because in the end the stuff that hit the main tree is something else altogether?

Don't get me wrong at all. Rebasing is fine for stuff you have committed yourself (which I assume was the case here).

Rebasing is also a fine conflict resolution strategy when you try to basically turn a "big and complex one-time merge conflict" into "multiple much smaller ones by doing them one commit at a time".

But what rebasing is _not_ is a fine "default strategy", especially if other people are depending on you.

What I do try to encourage is for people to think publicising their git trees as "version announcements". They're obviously _development_ versions, but they're still real versions, and before you publicize them you should try to make sure that they make sense and are something you can stand behind.

And once you've publicized them, you don't know who has that tree, so just from a sanity and debugging standpoint, you should try to avoid mucking with already-public versions. If you made a mistake, add a patch on top to fix it (and announce the new state), but generally try to not "hide" the fact that the state has changed.

But it's not a hard rule. Sometimes simple cleanliness means that you can decide to go "oops, that was *really* wrong, let's just throw that away and do a whole new set of patches". But it should be something rare - not normal coding practice.

Because if it becomes normal coding practice, now people cannot work with you sanely any more (ie some random person pulls your tree for testing, and then I pull it at some other time, and the tester reports a problem, but now the commits he is talking about don't actually even exist in my tree any more, and it's all really messy!).

Rebasing branches is absolutely not a bad thing for individual developers.

But it *is* a bad thing for a subsystem maintainer.

So I would heartily recommend that if you're a "random developer" and you're never going to have anybody really pull from you and you *definitely* don't want to pull from other peoples (except the ones that you consider to be "strictly upstream" from you!), then you should often plan on keeping your own set of patches as a nice linear regression.

And the best way to do that is very much by rebasing them.

That is, for example, what I do myself with all my git patches, since in git I'm not the maintainer, but instead send out my changes as emails to the git mailing list and to Junio.

So for that end-point-developer situation "git rebase" is absolutely the right thing to do. You can keep your patches nicely up-to-date and always at the top of your history, and basically use git as an efficient patch-queue manager that remembers *your* patches, while at the same time making it possible to efficiently synchronize with a distributed up-stream maintainer.

So doing "git fetch + git rebase" is *wonderful* if all you keep track of is your own patches, and nobody else ever cares until they get merged into somebody elses tree (and quite often, sending the patches by email is a common situation for this kind of workflow, rather than actually doing git merges at all!)

So I think 'git rebase' has been a great tool, and is absolutely worth knowing and using.

*BUT*. And this is a pretty big 'but'.

BUT if you're a subsystem maintainer, and other people are supposed to be able to pull from you, and you're supposed to merge other peoples work, then rebasing is a *horrible* workflow.


It's horrible for multiple reasons. The primary one being because nobody else can depend on your work any more. It can change at any point in time, so nobody but a temporary tree (like your "linux-next release of the day" or "-mm of the week" thing) can really pull from you sanely. Because each time you do a rebase, you'll pull the rug from under them, and they have to re-do everything they did last time they tried to track your work.

But there's a secondary reason, which is more indirect, but despite that perhaps even more important, at least in the long run.

If you are a top-level maintainer or an active subsystem, like Ingo or Thomas are, you are a pretty central person. That means that you'd better be working on the *assumption* that you personally aren't actually going to do most of the actual coding (at least not in the long run), but that your work is to try to vet and merge other peoples patches rather than primarily to write them yourself.

And that in turn means that you're basically where I am, and where I was before BK, and that should tell you something. I think a lot of people are a lot happier with how I can take their work these days than they were six+ years ago.

So you can either try to drink from the firehose and inevitably be bitched about because you're holding something up or not giving something the attention it deserves, or you can try to make sure that you can let others help you. And you'd better select the "let other people help you", because otherwise you _will_ burn out. It's not a matter of "if", but of "when".

Now, this isn't a big issue for some subsystems. If you're working in a pretty isolated area, and you get perhaps one or two patches on average per day, you can happily basically work like a patch-queue, and then other peoples patches aren't actually all that different from your own patches, and you can basically just rebase and work everything by emailing patches around. Big deal.

But for something like the whole x86 architecture, that's not what te situation is. The x86 merge isn't "one or two patches per day". It easily gets a thousand commits or more per release. That's a LOT. It's not quite as much as the networking layer (counting drivers and general networking combined), but it's in that kind of ballpark.

And when you're in that kind of ballpark, you should at least think of yourself as being where I was six+ years ago before BK. You should really seriously try to make sure that you are *not* the single point of failure, and you should plan on doing git merges.

And that absolutely *requires* that you not rebase. If you rebase, the people down-stream from you cannot effectively work with your git tree directly, and you cannot merge their work and then rebase without SCREWING UP their work.

The PCI tree merged the suspend branch from the ACPI tree. You can see it by looking at the PCI merge in gitk:

 gitk dc7c65db^..dc7c65db
and roughly in the middle there you'll find Jesse's commit 53eb2fbe, in which he merges branch 'suspend' from Len's ACPI tree.

So Jesse got these three commits:

 0e6859d... ACPI PM: Remove obsolete Toshiba workaround
 8d2bdf4... PCI ACPI: Drop the second argument of platform_pci_choose_state
 0616678... ACPI PM: acpi_pm_device_sleep_state() cleanup

from Len's tree. Then look at these three commits that I got when I actually merged from you:

 741438b... ACPI PM: Remove obsolete Toshiba workaround
 a80a6da... PCI ACPI: Drop the second argument of platform_pci_choose_state
 2fe2de5... ACPI PM: acpi_pm_device_sleep_state() cleanup

Look familiar? It's the same patches - just different commit ID's. You rebased and moved them around, so they're not really the "same" at all, and they don't show the shared history any more, and the fact that they were pulled earlier into the PCI tree (and then into mine).

This is what rebasing causes.

So rebasing and cleanups may indeed result in a "simpler" history, but it only look that way if you then ignore all the _other_ "simpler" histories. So anybody who rebases basically creates not just one simple history, but a _many_ "simple" histories, and in doing so actually creates a potentially much bigger mess than he started out with!

As long as you never _ever_ expose your rewriting of history to anybody else, people won't notice or care, because you basically guarantee that nobody can ever see all those _other_ "simpler" histories, and they only see the one final result. That's why 'rebase' is useful for private histories.

But even then, any testing you did in your private tree is now suspect, because that testing was done with the old history that you threw away. So even if you delete all the old histories and never show them, they kind of do exist conceptually - they existed in the sense that you tested them, and you've just hidden the fact that what you release is different from what you tested.


That was a lot of quoting, and I'm sorry to do that.

But so many of the web pages out there only point to Linus's Final Word On The Subject.

You know, the one which reads:

I want clean history, but that really means (a) clean and (b) history.
Now, that last essay is indeed brilliant, and you should print it out, and post it on your wall, and read it every morning, and think about what it is he's trying to say.

But if you just can't figure it out, well, go digging in the source material.

And then, I believe, it will finally all make sense.

At least, it finally did, to me.

Friday, August 8, 2014

Stuff I'm reading, lazy Friday afternoon edition

So here we are in the dog days of summer. Woof!

As usual, doncha know, I'm all over the place:

  • Too bad everything seems to be a "freemium" game nowadays. Godus: Another Baffling, Bizarre Peter Molyneux Game
    Speaking of light touch, the most interesting thing about Godus is that you’re actually touching your world and peoples instead of wielding a mouse pointer. There’s something about delicately tapping the landscape, even through a glass veneer, that personalizes the experience. If keyboard and mouse exemplify media theorist Marshall McLuhan’s notion that inanimate objects become extensions of ourselves, Godus is partly about removing that extension: You’re god, after all, and god doesn’t play dice with a gamepad.
  • Planet Generation - Part I
    For this chapter I will start by making the simple geometry for the basis of the planet. At later posts I will add more detail including height data, lighting, atmospheric scattering and level of detail which will allow the amount of data the planet contains to increase dramatically.
  • Planet Generation - Part II
    Libnoise is a portable, open-source, coherent noise-generating library for C++. This sounds good for my needs as I am running the code on my Nexus 5 Android phone and the library supports a SetSeed function so it fills the requirement of being able to replicate the same results given a seed.
  • This is a really super essay about the role of plot and narrative in video game implementations: Designing game narrative
    Here’s an example from the first Portal game. In this game, you play as a test subject with a portal gun, trying to advance through different test chambers. Near the end, you are riding a slowly moving platform to what you are told is a reward for your good test performance. Suddenly, it’s revealed that the platform is actually taking you to a fiery death. When I was playing this scene, I genuinely panicked: I was deeply immersed in the game at this point, feeling good about myself for beating the puzzles, ready to be rewarded for it, and now I was being betrayed. Without thinking, my eyes lead me to an ideal surface for firing my portal gun, and I created an exit for myself, escaping certain death. For just a moment, I genuinely thought I broke the system. I had outsmarted the enemy with my wits!
  • Announcing UberPool, Carpooling with Uber
    This is also a bold social experiment. There’s the interaction between riders in an UberPool—should they talk to each other? When is that cool and when is it, well, annoying? We’re going to find out how this brave new world of UberPooling works—we’ll iterate on this beta product and get it right, because the larger social implications of reducing the number of cars on the road, congestion in cities, pollution, parking challenges… are truly inspiring.
  • The BobbyTables Culture
    Countless posts on Stack Overflow are vulnerable to SQL injection attacks. Along with several other users, I always raise this when it shows up – this is something that really just shouldn’t happen these days. It’s a well-understood issue,and parameterized SQL is a great solution in almost all cases. (No, it doesn’t work if you want to specify an column or table name dynamically. Yes, whitelisting is the solution there.)
  • Your computer is already a distributed system. Why isn’t your OS?
    Our goal is to make it easier to design and construct ro- bust OSes that effectively exploit heterogeneous, multi- core hardware at scale. We approach this through a new OS architecture resembling a distributed system.
  • The Network is Reliable
    much of what we believe about the failure modes of real-world distributed systems is founded on guesswork and rumor. Sysadmins and developers will swap stories over beer, but detailed, public postmortems and comprehensive surveys of network availability are few and far between. In this article, we'd like to informally bring a few of these stories (which, in most cases, are unabashedly anecdotal) together. Our focus is on descriptions of actual network behavior when possible and (more often), when not, on the implications of network failures and asynchrony for real-world systems deployments. We believe this is a first step toward a more open and honest discussion of real-world partition behavior, and, ultimately, toward more robust distributed systems design.
  • The US Intelligence Community has a Third Leaker
    Everyone's miscounting.
  • Building Carousel, Part II: Speeding Up the Data Model
    In Carousel, we wanted to fix the experience for users with more than a single page of photos by using a different model for loading photo metadata off of disk. When it comes time to render the view to the user, it doesn’t matter how we store the user’s data on disk as long as we can quickly bind data to the view. We prepare an in-memory “view model”, a data structure that provides exactly this: an index on our metadata that is fast enough to query on the UI thread at render time.
  • Open Source Dickishness
    In a blog post, StrongLoop announced the move as a great next step in the evolution of the project. The blog post masks a commercial transaction as an act of good will by calling it a “transfer of sponsorship”. If all they wanted was to “pitch in and help”, why did they need to take over and move the project? Why is their first public act a blog post and not a pull request?
  • StrongLoop & Express
    Did I consult every contributor that there has ever been on the project? No, maybe I should have? Ultimately I don’t see this as the huge problem that everyone else does, the two primary contributors benefit, the community benefits by having full-time employees improve a project, the company benefits from being closely associated with the project.
  • Non-Transparent Memory Safety
    after using Deputy for a while, its genius became apparent. First, whenever I needed to tell Deputy something, the information was always available either in my head or in a convenient program variable. This is not a coincidence: if the information that Deputy requires is not available, then the code is probably not memory safe. Second, the annotations become incredibly useful documentation: they take memory safety information that is normally implicit and put it out in the open in a nice readable format. In contrast, a transparent memory safety solution is highly valuable at runtime but does not contribute to the understandability and maintainability of our code.
  • Princeton likely to rescind grade deflation policy
    After the policy went into effect in 2005, grades were flat for a few years and then started rising again. So what changed grading practices was not the 35% guideline but the simple fact that faculty were discussing and thinking more deeply about grading policy during the period before the current policy was even a concrete proposal. The policy that worked was “grade mindfully”, not “give 35% A’s”.
  • Silver Village
    Historic structures in the mountains of California are being wrapped, Christo-style, in reflective silver sheets to help protect them against the heat of wildfires.
  • Today is a good day. I just had a call from a telemarketer.
    Like a good IT administrator I put my skills to use for their benefit.
  • Over a Billion Passwords Stolen?
    I've been doing way too many media interviews over this weird New York Times story that a Russian criminal gang has stolen over 1.2 billion passwords.
  • Bruce Schneier is skeptical, but Brian Krebs says it's legit: Q&A on the Reported Theft of 1.2B Email Accounts
    Alex isn’t keen on disclosing his methods, but I have seen his research and data firsthand and can say it’s definitely for real. Without spilling his secrets or methods, it is clear that he has a first-hand view on the day-to-day activities of some very active organized cybercrime networks and actors.
  • The hidden perils of cookie syncing
    The most common use of cookie syncing is to enable real-time bidding between several entities in an ad auction. It allows the bidder and the ad network to refer to the user by the same ID so that the bidder can place bids on a particular user in current and future auctions. Cookie syncing raises subtle yet serious privacy concerns, but due to the technical complexity of explaining it, didn’t receive much press coverage. In this post I’ll explain cookie syncing and why it’s worrisome — even more so than canvas fingerprinting.
  • A Closer Look At Personas: What They Are And How They Work (Part 1)
    A persona is a way to model, summarize and communicate research about people who have been observed or researched in some way. A persona is depicted as a specific person but is not a real individual; rather, it is synthesized from observations of many people. Each persona represents a significant portion of people in the real world and enables the designer to focus on a manageable and memorable cast of characters, instead of focusing on thousands of individuals.
  • PostgreSQL page size for SSD
    What struck me is that there is a significant impact of smaller page size on OLTP performance (6% better for 4 kB, 10% better for 2 kB, with 8 kB as the reference), suggesting that the 8 kB default is not necessarily the best choice, especially when using SSD.
  • Explaining Ark Part 4: Fixing Majority Write Concern
    When a replica set has two primaries, the two primaries should never produce oplog entries whose positions interleave, and primary that produces smaller oplog positions should step down.
  • Everything We Know About Facebook's Secret Mood Manipulation Experiment
    For one week in January 2012, data scientists skewed what almost 700,000 Facebook users saw when they logged into its service. Some people were shown content with a preponderance of happy and positive words; some were shown content analyzed as sadder than average. And when the week was over, these manipulated users were more likely to post either especially positive or negative words themselves.
  • Did OkCupid send a bunch of incompatible people on dates on purpose?
    The question is whether the potential damage of the interventions justifies the lack of informed consent outside of OkCupid's normal terms and conditions. The first experiment is the least troubling on these grounds, since everyone was informed the change was coming, rather than it being rolled out surreptitiously
  • We Experiment On Human Beings!
    We noticed recently that people didn’t like it when Facebook “experimented” with their news feed. Even the FTC is getting involved. But guess what, everybody: if you use the Internet, you’re the subject of hundreds of experiments at any given time, on every site. That’s how websites work.
  • Why don't OKCupid's experiments bother us like Facebook's did? 
    The tone of the OKC post is just so darned charming. Rudder is casual, self-deprecating. It's a blog post! Meanwhile, Facebook's "emotional contagion" scholarly paper was chillingly matter-of-fact. In short, the scientism of the thing just creeped us the fuck out.
  • Premier League preview links
    It’s a week until the season starts, so here are some club by club preview links
  • If Google was a Guy

The Hannibal Procedure

I'm following up on a question I wrote about a week ago: What are Halachic Considerations?.

A fascinating and intense and disturbing story in the New York Times sheds some light: Israeli Procedure Reignites Old Debate.

It was one of the rare invocations of the Israeli military’s “Hannibal procedure,” one of its most dreaded and contentious directives, which allows commanders to call in extra troops and air support to use maximum force to recapture a lost soldier. Its most ominous clause states that the mission is to prevent the captors from getting away with their captives, even at the risk of harming or endangering the lives of the captured Israeli soldiers.

It has been official procedure of the Israeli military for decades:

The Hannibal edict was drawn up by three senior officers in Israel’s northern command in the 1980s after two Israeli soldiers were captured by Hezbollah in Lebanon.

But it doesn't fully explain the recent event:

There was no contact or engagement between the soldiers who entered the tunnel and the captors, Colonel Lerner said. But he said some evidence found in the tunnel later helped the military determine that Lieutenant Goldin could not have survived the initial attack. He was declared killed in action by late Saturday night.

I know more than I did a week ago, perhaps less than I could, but perhaps as much as I should, or need.

And I appreciate the journalist who helped me understand things a bit better.

Thursday, August 7, 2014

Disappointing article on Ars Technica

Normally Ars Technica is one of my favorite web sites; they do strong, well-researched reporting and have good writers and editors.

But this recent article, which is getting a fair bit of attention, disappointed me greatly: How Microsoft dragged its development practices into the 21st century.

The author attempts to tell a story about changing development process approaches over the last few years, using Microsoft as his source of examples, and specifically uses the Visual Studio team in Microsoft as a focus of his discussion.

Avoiding any hard data, the article tries to use a narrative approach, spreading a wide net, touching on a vast universe of subjects, and dropping anecdotes spanning a 20-year time frame.

But the article fails on many levels.

It starts off poorly by making the classic mistake of trying to compare completely unrelated industrial processes, when clearly the author knows nothing about any of the industries and how they actually operate:

In industries such as manufacturing and construction, design must be done up front because things like cars and buildings are extremely hard to change once they've been built. In these fields, it's imperative to get the design as correct as possible right from the start. It's the only way to avoid the costs of recalling vehicles or tearing down buildings.

The design of cars, and the design of buildings, is in fact extremely iterative. Car designers and building architects use all sorts of tools (design sketches, scale models, 3d printers, computerized visualizations) to get all sorts of feedback during the design process.

Then he compounds his error by trying to compare completely unrelated types of software development, comparing the development of products like Windows, SQL Server, Exchange, or Microsoft office with an entirely different sort of software:

For example, lots of companies develop in-house applications to automate various business processes. In the course of developing these applications, it's often discovered that the old process just isn't that great. Developers will discover that there are redundant steps, or that two processes should be merged into one, or that one should be split into two. Electronic forms that mirror paper forms in their layout and sequence can provide familiarity, but it's often the case that rearranging the forms can be more logical.

Developing a custom in-house application, with users who are part of the same organization that performs the development, to solve a specific problem for that organization, has almost nothing in common with developing a general-purpose piece of software like SQL Server or Windows, which is used in all sorts of different environments, by organizations that have nothing to do with Microsoft, for all kinds of different purposes, by users who have never been, nor ever will be, Microsoft employees.

And a process that works for a 3 person team building an internal website has no hope of scaling to a process that allows 1,500 or more individuals to collaborate on an operating system used on several billion computers across the planet.

And the article descends into tragedy when the author reveals that he has never been part of a team that tried to build truly reliable software to address a truly complex project:

the result was a two-year development process in which only about four months would be spent writing new code. Twice as long would be spent fixing that code.

I've worked on database servers, on web middleware, on networking protocols, on operating systems.

You start by carefully hiring the best possible developers you can find. You give them the best possible conditions you can provide (quiet environment, access to plenty of computer resources, meeting rooms to work out ideas cooperatively, excellent development tools to make them as efficient as possible).

You provide them with immense amounts of support: testing tools, hardware labs with test resources, testing experts, interaction designers, brilliant technical writers, and so on.

But even with all of this, building a product like SQL Server or Windows 8 is just HARD.

It's more than hard, it's nearly impossible.

If Microsoft manages to ONLY spend twice as long testing, stabilizing, and bullet-proofing their software as it took them to design and build it in the first place, I'm frankly astonished. I would have predicted 3-4 times as long.

And the fact that they can continue to roll out new releases of Office, of Windows, of SQL Server, every 2-3 years, on code bases that are nearly 3 decades old, with products that have to provide backward compatibility and upgrade paths for billions of users and existing installations, is a track record that nobody else in the industry can match.

Face it, software of this type is just fundamentally incredibly hard to build.

So while it's useful to look at alternate processes and techniques, and suggest things that might help improve the process, to walk up to a 25-year-old organization like Microsoft, who certainly have their faults, but who have figured out how to deliver an amazing stream of powerful and widely-accepted software, and then provide nothing but anecdotes and bad analogies, is just not what I expect of a publication like Ars Technica.

Maybe I totally missed the point of this article.

If so, drop me a line and tell me where I went wrong!

Wednesday, August 6, 2014

Memory Matters

I loved this recent essay from one of the top PostgreSQL developers: Memory Matters.


Under any circumstances, reading from disk is vastly slower than reading from memory, but reading data from disk sequentially is 10 to 100 times faster than random I/O. Unfortunately, it's often the case that the task which is evicting data from memory is writing data sequentially while the underlying database workload is typically accessing some working set of pages in a more-or-less random fashion. The result is that data is removed from the cache at a vastly higher rate than it can be read back in. Even after the bulk operation terminates and the cache-purging ceases, it can take a painfully long time - sometimes many hours - for random I/O to bring all of the hot data back into memory.

I think it's possible that he meant "reading data sequentially," not "writing data sequentially,", but that's a nit.

The whole essay is great. I probably give this advice about 3x a week at work, and never word it anywhere nearly so well, so it's nice to have a great reference to point to.

And I really love his two final points:

  1. If adding memory doesn't seem to help, it's possible that you just haven't added enough.
  2. Memory is different: because of the way operating system and PostgreSQL caching works, it's likely that substantially all of your memory will be in use all the time


Monday, August 4, 2014

Maryn McKenna on Ebola

Maryn McKenna was feeling my confusion, and steps in with a super article packed with information: Ebola in Africa and the U.S.: A Curation

Having said all that, here are a few pieces that I think would be worth your time to read.

Down the road, let's please have less coverage of Donald Trump, and more strong reporting like this.

Sunday, August 3, 2014

Looking for more information about the West Africa Ebola crisis

It's been hard to find good reporting about the West Africa Ebola crisis, at least here in the states.

Most of the coverage has involved the Dr. Kent Brantly story, which is certainly a compelling story, but there is much more I'd like to know.

I've found a few good articles, though.

A detailed article carried by ABC News helps in explaining why it is so hard to combat the epidemic: Ebola Outbreak Feeds on Fear, Anger, Rumors

Many health care workers and aid workers have said one cause for the rapid spread of the Ebola virus is the public's general mistrust of the government. Among the rumors about this disease:
  • Ebola does not exist and government workers are using it as an excuse to steal organs to sell on the black market.
  • The government is pretending Liberia has Ebola so they'll have an opportunity to receive and then abuse donated funds.
  • If a person goes to the hospital with a disease that has symptoms that mirror those of Ebola, such as malaria, that person will end up getting Ebola from the hospital.
  • Medical staffers are so afraid to catch Ebola, they neglect patients in the quarantine unit and let them starve to death.
  • Because of the noxious fumes that come from the solution workers use to spray affected areas, some people believe the spray is meant to kill them, and they don't want workers to come into their communities.
Rumors such as the ones listed above overshadow the work done by the overextended aid workers and local medical professionals who risk their lives on the front lines of the battle against Ebola. Fear and mistrust has caused some community members to sometimes react violently to the arrival of medical professionals in their communities.

On the NPR site, transcripts of two interesting interviews:

  • Fear, Caution As Doctors Fight Ebola On The Ground
    SAYAH: We need more people. We need more actors to be involved in educating the population, the communities, sensitizing them about the fact that the key to resolving this is that people come and get treated and not hide their sick and not have secret burials. We have a lot of work ahead. It's now in three countries in multiple sites. We've never seen it before. Doctors Without Borders has stretched its capacity to respond. We're doing the best we can but I think many more actors need to be mobilized.
  • Sierra Leone, Struggling With Ebola, Passes On Africa Summit
    FOFANA: Well, it has been difficult because it's never been here before. And health workers were not prepared for Ebola when eventually it did emerge. And lots of the health workers have died in all three countries. About in the region of 100 health workers have contracted the virus and at least half that number have died. We have been told by some nurses that the personal protective gear that they have been given is not good enough. They say the clothing is very thin, and they do not feel very much secure in them.
And the BBC has been doing some excellent reporting:
  • Living in the shadow of Ebola
    I spent an instructive couple of hours at the weekend with a woman from Finland. Eeva was once a midwife, but she's just finished a five-week stint with a Red Cross team that has been going door to door in Kailahun province, the border region where Ebola first arrived in Sierra Leone.

    She was on what's known as a sensitisation mission, explaining to people exactly how the virus spreads and how to avoid it.

    There are three simple rules, she told me.

  • Ebola outbreak: US experts to head to West Africa
    Dr Thomas Frieden, director of the Centers for Disease Control and Prevention, announced the new US measures in an interview with ABC's This Week.

    "We do know how to stop Ebola. It's old-fashioned plain and simple public health: find the patients, make sure they get treated, find their contacts, track them, educate people, do infection control in hospitals."

Let's continue talking about privacy and surveillance

It's been 14 months now since the Edward Snowden story broke.

During that time, there has been a conversation of sorts. I wish that more had participated; I wish that more had resulted.

But I'm pleased, at least, that the conversation continues.

Some have been focusing on the economic and commercial aspects of the conversation:

  • Personal Privacy Is Only One of the Costs of NSA Surveillance
    The economic costs of NSA surveillance can be difficult to gauge, given that it can be hard to know when the erosion of a company’s business is due solely to anger over government spying. Sometimes, there is little more than anecdotal evidence to go on. But when the German government, for example, specifically cites NSA surveillance as the reason it canceled a lucrative network contract with Verizon, there is little doubt that U.S. spying policies are having a negative impact on business.
  • Report Says Backlash From NSA's Surveillance Programs Will Cost Private Sector Billions Of Dollars
    Also directly affecting US companies is a future full of increased compliance costs as countries move towards data sovereignty. This means tech companies like Facebook and Google will need to build local data centers if they wish to keep citizens in affected countries as users. The European Parliament's new data protection law could easily result in massive fines for US companies.

Others have been looking at the changing relationship between the American scientific community and its most important patron, the U.S. Government:

  • Mathematicians Discuss the Snowden Revelations
    The only reason I am putting these words down now is the feeling of intense betrayal I suffered when I learned how my government and the leadership of my intelligence community took the work I and many others did over many years, with a genuine desire to prevent another 9/11 attack, and subverted it in ways that run totally counter to the founding principles of the United States, that cause huge harm to the US economy, and that moreover almost certainly weaken our ability to defend ourselves.
  • The Mathematical Community and the National Security Agency
    We face a variety of threats -- from car accidents, which take about as many lives each month as the 9/11 tragedy, to weather (ranging from sudden disasters, such as hurricanes Katrina and Sandy, to the dangers from climate change), to global avian flu pandemics. The moves taken in the name of fighting terrorism, including the intrusive NSA data collection that has recently come to light and more generally the militarization of our society, are not justified by the dangers we currently face from terrorism.
  • NSA and the Snowden Issues
    NSA's intelligence activities stem from a foreign-intelligence requirement -- initiated by one or more Executive Branch intelligence consumers (the White House, Department of State, Department of Defense, etc.), vetted through the Justice Department as a valid need -- and run according to a process managed by the Office of the Director of National Intelligence.
And still others are looking at other aspects of the privacy-vs-surveillance debate:
  • Why were CERT researchers attacking Tor?
    CERT was set up in the aftermath of the Morris Worm as a clearinghouse for vulnerability information. The purpose of CERT was to (1) prevent attacks by (2) channeling vulnerability information to vendors and eventually (3) informing the public. Yet here, CERT staff (1) carried out a large-scale, long-lasting attack while (2) withholding vulnerability information from the vendor, and now, even after the vulnerability has been fixed, (3) withholding the same information from the public.
  • Cryptographer Adi Shamir Prevented from Attending NSA History Conference
    As a friend of the US I am deeply worried that if you continue to delay visas in such a way, the only thing you will achieve is to alienate many world-famous foreign scientists, forcing them to increase their cooperation with European or Chinese scientists whose countries roll the red carpet for such visits. Is this really in the US best interest?

    Best personal wishes, and apologies for not being able to meet you in person,

    Adi Shamir

  • US State Department: Let in cryptographers and other scientists
    I’ve learned from colleagues that, over the past year, foreign-born scientists have been having enormously more trouble getting visas to enter the US than they used to. The problem, I’m told, is particularly severe for cryptographers: embassy clerks are now instructed to ask specifically whether computer scientists seeking to enter the US work in cryptography. If an applicant answers “yes,” it triggers a special process.
  • The ultimate goal of the NSA is total population control
    The lack of official oversight is one of Binney’s key concerns, particularly of the secret Foreign Intelligence Surveillance Court (Fisa), which is held out by NSA defenders as a sign of the surveillance scheme's constitutionality.

    “The Fisa court has only the government’s point of view”, he argued. “There are no other views for the judges to consider.

None of these topics are simple; none of these conversations are easy.

We must keep the discussion going.