internal fragmentation

a personal journal of hacking, science, and technology

F*cking magnets, how do they work?

Mon, 8 Nov 2010 16:47 by mpm in Uncategorized (link)

Perhaps you’ve seen the meme going around the internet about magnets and how they work. Today, I watched a video of the Richard Feynmann explaining why explaining magnets was hard and my roommate remarked that he didn’t do it very well. That’s ironic, as Richard Feynmann has arguably done more to more to explain magnets than anyone else in human history by formulating the theory of quantum electrodynamics (QED).

So, how do they work? Push two magnets together in one direction, and you can feel a repulsive force. Most explanations go something like this: a magnet is made of a bunch of iron atoms with the spins of their electrons all aligned so their magnetic fields all add up into one large magnetic field.

In short: magnets are made of lots and lots of very small magnets. This is not a very satisfying answer and it hasn’t told us anything about what a magnetic field is. And the usual explanation for that is: a magnetic field is a field that results from a moving electric field. James Clerk Maxwell figured that out in 1864. But he also figured out that an electric field is the result of a moving magnetic field, so he was left with a bigger combined question: what the hell is electromagnetism? And none of that really gives any sense of how the force gets from here to there across empty space.

Which is where Feynmann and QED comes in. The forces of electromagnetic fields are transmitted by photons. And we already know about photons: that’s how light works. And just like light, magnetic repulsion is simply electrons in one magnet sending out photons that deflect electrons in another.

Simple enough, right? Unfortunately no, because the photons in the field theory of QED are not real photons! In other words, magnets attract and repel each other with virtual light, light that only potentially exists. And it’s worse than that: QED requires summing all possible paths these photon can take between two electrons. Or, to put it more mind-blowingly: it involves an infinite amount of virtual light, that can be thought of as travelling forwards and backwards in time. Which is beginning to sound too crazy to be true. But physicists are pretty sure QED is right: the predictions of QED are the most accurately tested in all of science.

So, magnets are a macroscopic manifestation of the deeply weird subatomic world of quantum physics. Just like flashlights, radios, mirrors, static cling, solid objects, etc. F*cking solid objects, how do they work?

October Mercurial Fellowship Update

Thu, 4 Nov 2010 17:57 by mpm in Uncategorized (link)

A busy month of travel and coding and wiki hacking. Mercurial highlights:

  • 1.7 sprint in Chicago
  • reviewed and merged 249 changesets
  • authored 26 changesets
  • 106 mailing list messages
  • 299 edits to 200 wiki pages
  • numerous bugfixes and prep for 1.7 release
  • IRC office hours

November looks set for a lot of interesting coding.

The 1.7 Mercurial Sprint

17:47 by mpm in Uncategorized (link)


1.7 sprint participants from left to right: Steve Borho, Brodie Rao, Benoit Boissinot, Mads Kiilerich, Nicolas Dumazet, Augie Fackler (front), Martin Geisler (Back), Matt Mackall, Dan Christiansen, Jesper Noehr, Justen Stepka (front), Patrick Mezard, and Benjamin Pollack.

A bunch of the Mercurial team got together in October for our 1.7 sprint. We had a total of 13 attendees, with 6 from the US, 6 from Europe, and one from Australia. A big thanks to Google and Atlassian for funding, and to Google for giving us pretty much an entire floor of their Chicago office for the weekend!

Over three days, we had a huge amount of discussion, feature development, and bug stomping. Here are some highlights:

  • Online help – given our extensive built-in help engine, it makes sense to have help browsable in hgweb. So we went ahead and implemented this for 1.7, see here for an example. More work to be done here, including generating nice HTML output.
  • Merging new features – we discussed the process for rolling large new features into the core. The consensus is that it’s ok to put development features into the core and cover them with config flags so that they’re not accidentally used. The not-yet-complete parentdelta support in 1.7 is a good example. Other large features like subrepos are being developed more incrementally with a steady evolution towards complete support (see the addition of numerous new subrepo pieces in 1.7).
  • Development cycle – we discussed our release plan and support for old versions. As we generally aim to make upgrading completely painless, we’re not going to do continued support releases of old versions. If users are going to upgrade, there’s very little risk in upgrading to the latest available release.
  • Advanced resolve – another new feature which extends resolve to handle more types of merge conflicts, including things we can’t currently handle well like case collisions. Steve Borho has a prototype implementation of this ready for testing.
  • “LiquidHG” – a newly proposed feature for tracking which changesets can be safely changed or discarded. This feature would make MQ and rebase and the like much less problematic. In our discussion, we unified this approach with the related “DeadHeads” approach for handling discarded lines of development. We’ll probably begin working on this in the 1.8 cycle.
  • Revitalizing the wiki – the wiki hasn’t gotten much attention lately and isn’t particularly well-organized. I proposed implementing a style guide and a cleanup plan to improve matters. Since the sprint, there’s been a huge amount of editing to implement these.
  • Revitalizing the book – we also discussed updating the Mercurial book to be more current. This probably means turning it into an active community-based project. We kicked around ideas a wishlist of ideas for improving the book, and have just begun discussing this again on the mailing list.
  • Replacing our bug tracker – we’re not terribly happy with the features and maintenance overhead of our current bug tracker, so we did an experiment with converting our database to Trac. We haven’t come to any decisions though.
  • Google Summer of Code – we had a debrief with all the people involved in our GSoC efforts and decided we need to have a more stringent selection process and more feedback to students about their performance to avoid surprises.
  • Our bug stomping session was also extremely productive and we resolved a huge number of outstanding issues and fine-tuned some of our bug-handling practices.

Once every two releases seems to be a good interval for sprints, so we’ve made tentative plans to have the next sprint before 1.9. However, just about everyone agreed that having more time between the sprint and the code freeze would be best, so we’ll probably aim for meeting in Europe some time in early spring 2011.