Selection and other sundries for MP-WP

Filed under: MP-WP — Jacob Welsh @ 04:49

Here are four patches to the V-tree for Mircea Popescu's Wordpress, which amount to an approximation of the changes I've been running since initial setup of Fixpoint, reground to build upon subsequent improvements by billymg and Diana Coman.

I plan to sign them shortly unless cause for revision comes to light (such as for example server-side selection being implemented outside the theme-specific code).

Quoth the manifest:

624752 mp-wp_remove-textselectionjs-pop3-etc jfw Remove the unreliable JS-based selection, posting by POP3 login, and a stray .php.orig file. Neutralize and comment the example pingback updater.
624752 mp-wp_svg-screenshots-and-errorreporting jfw Allow .svg extensions in theme screenshot search. Don't clobber the user's errorreporting level without WP_DEBUG.
624752 mp-wp_serverside-selection jfw Add server-side text selection to example htaccess and themes, roughly as seen in (xmlrpc.php changes not included)
624752 mp-wp_footnote-link-tweaks jfw Avoid turning double-quotes into backquotes in footnote tooltips. Expand the link part of footnote identifiers to cover the pre_identifier and post_identifier strings, for a larger clickable area.


V in Perl with parsing fix, keksum, and starter, plus the ill-fated vdiff

Filed under: Software, V — Jacob Welsh @ 17:50

Following my prior adventures, I reoriented my efforts toward some simpler changes to the tree, abandoning hopes of a robust patch creation tool built on Busybox diff.

I've split the changes into two patches. The first is "v_strict_headers", which I think would be of interest to any user. It tightens vpatch parsing to prevent false-positive header matches that could cause incorrect or nonsensical antecedent information to be extracted from valid vpatches. Following the precedent of the vtools vpatch program, this is done by requiring the string "diff " at the start of a line preceding the header, which works because all other lines of a diff "packet"(i) start with either @, +, -, or space characters. This patch also backfills the manifest file and brings it fully in line with the spec.

The second patch, "v_keksum_busybox", swaps keksum and patch in for ksum and vpatch, making V presses possible again on systems with little more than a C toolchain, Busybox utilities and Perl.

I have also mirrored the rest of the VTree and contributed my own seals, which can be found in the same directory.

For deployment on systems with no previous V, there's a starter tarball which includes the tree pressed to v_keksum_busybox, the keksum code, and an install script. Take a look at what it does, then run as root, from the extracted directory:

# sh


The ill-fated vdiff

What follows is my abandoned attempt at vdiff in awk, supporting any conforming diff program. It identifies headers using a three-state machine to recognize the ---, +++, @@ sequence. This would still be fooled by a ---, +++ sequence followed immediately by another hunk, except that the lines of context prevent this, unless the change comes at the end of the file in which case there can't be another hunk prior to the next file header.

It works as far as parsing both GNU and Busybox diff output, produces working vpatches in the GNU case, and could even be expanded to do the same for Busybox. But since fully-reproducible output seems to be desirable, I can't presently justify further work in this direction or recommend it over the vtools vdiff.

diff -uNr $1 $2 | awk -v sq=\' '
function shell_quote(s) {
	sub(sq, sq "\\" sq sq, s);
	return sq s sq;

function vhash(path) {
	if (path == "/dev/null") return "false";
	qpath = shell_quote(path);
	cmd = "test -e " qpath " && keksum -s256 -l512 -- " qpath;
	gotline = cmd | getline rec;
	if (!gotline) return "false";
	split(rec, parts);
	return parts[1];

function print_header(line) {
	split(line, parts);
	print parts[1], parts[2], vhash(parts[2]);

	if (state == 0) {
		if ($0 ~ /^---/) {
			from = $0;
			state = 1;
		else {
	else if (state == 1) {
		if ($0 ~ /^\+\+\+/) {
			to = $0;
			state = 2;
		else if ($0 ~ /^---/) {
			print from;
			from = $0;
		else {
			print from;
			state = 0;
	else if (state == 2) {
		if ($0 ~ /^@@/) {
			state = 0;
		else if ($0 ~ /^---/) {
			print from;
			print to;
			from = $0;
			state = 1;
		else {
			print from;
			print to;
			state = 0;

	if (state == 1) {
		print from;
	else if (state == 2) {
		print from;
		print to;
  1. Or what else do you call the header and sequence of hunks associated with a single file? [^]


Adventures in the forest of V

Filed under: Historia, Software, V — Jacob Welsh @ 19:11

It started as what I thought a simple enough job: take the existing SHA512 I'd been using to press the Bitcoin code, or rather the VTree that grew from it, swap out the hash with my own keksum so as to avoid a hefty and otherwise unnecessary GNAT requirement, add my version of the classic vdiff modified likewise, bundle up a "starter" to cut the bootstrapping knot, and publish the bunch as my own tested and supported offering for wherever a V may be needed.

Such a thing would still require Perl, itself not an insignificant liability. While work had been underway to replace that, the results fell short of completeness, and from the ensuing discussion I decided it would be best to shore up my own grounding in the historical tools before venturing deeper into the frontier. I suppose I should be glad, because I got even more of that grounding - or swamping, more like - than I had asked for.


One pitfall I already knew was that file header lines in the "unified diff" format used by V, which begin with "---" and "+++", cannot be accurately distinguished from deleted lines beginning "--" and inserted lines beginning "++", if parsing linewise and statelessly as done by the original "one-liner" vdiff. This was discovered in practice through an MP-WP patch containing base64-encoded images, and the potential damage is hardly restricted to that; for instance both SQL and Ada programming languages use "--" as comment marker. This was part of the motivation behind vtools, which took the approach of avoiding the system's existing "diff" program in favor of a stripped-down version of the GNU codebase with integrated hashing. My own approach had been more lightweight: tightening up the awk regex to at least reduce the false positive cases. It wasn't too satisfying, but had worked well enough so far.


The first surprise I hit (stupidly late in the process, after I'd already signed my patch and starter) was that the Busybox version of "diff -N" replaces the input or output file path with "/dev/null" for the cases of creation and deletion respectively.

This reflects a larger reservation I have about Busybox code: it's been hacked extensively toward the goal of minimizing executable and memory footprint, which sometimes but only sometimes coincides with clear code and sensible interfaces. In this case, from brief inspection I surmise that it literally uses /dev/null so as to avoid some kind of null check in the downstream code that compares and emits the header. It's clever, but breaks compatibility with the GNU format in unforeseen ways.(i) In fairness to Busybox, the format was poorly specified in the first place - and nobody involved with V apparently found this important enough to remedy either.


Another surprise for me was that the sloppy parsing affects not just diffing but pressing too. At least and exhibit the same sort of blind regexing in extracting antecedent information from vpatches. (I'd guess that use of somewhat tighter regexes has prevented this from causing trouble in practice yet.) Further, extracts file paths only from the "---" part of the header which suggests it would indeed be broken by "/dev/null" style patches. On the extended vtools side, vfilter makes yet another assumption not backed by either such documentation as exists for the format or the Busybox version: a line showing a diff pseudo-command at the start of the header.


Finally, I've noticed what strikes me as a design problem affecting all V implementations, which I haven't seen mentioned before: it's not possible to have the same (path, hash) pair as an output of two different patches in the same VTree. More simply put, you can't have a patch that changes a file back to a previous state, contrary to the suggestion that "adding and removing the null character from the manifest file in every other patch would work" seen in the manifest spec. The reason is that both patches would end up in the antecedent set of a patch referencing either version of the file, in some cases producing a cyclic graph.(ii)

Stay tuned for the aforementioned patch and starter that make progress on a few of these fronts.

  1. A related annoyance I've had is Busybox "diff -qr" doesn't report added or removed directories, while adding -N replaces "Only in ..." messages with the less helpful "Files ... differ". [^]
  2. At this point I must say I wonder why V wasn't made to simply include in the header of each patch the hash of its antecedent patch as a whole. It would have neatly bypassed all these problems, forcing a tree topology and simplifying implementation. Would it have smelled too much like Git, or what? [^]


Virus terror shuts down Panama City

Filed under: News — Jacob Welsh @ 00:27

On a normal Tuesday rush hour, this would be a busy sidewalk.


There wouldn't be space between cars on Via EspaƱa.


Three cops rolled out purposefully. Maybe there's a gathering to be suppressed.


At the supermarket, the normal street-level entrance was closed. The masked - and gloved, for good measure! - guard at the exit was a bit distracted and didn't at first notice me stroll in, but then hollered and pointed me to the parking entrance.


The bread lines are here - not for lack of bread, as yet, but for limited headcount permitted inside.


Maybe the checkout lines at least go faster now. I have my doubts: they seem to be always just a bit understaffed by design. I didn't stick around to find out.

I wonder how often they miss someone leaving and don't let the next in.

The chino's shelves are holding up fine, on the offchance they have something you'd want to buy.


Back at the cell block, celebrations prohibited, and a first hint of concern about the water supply, though that's not uncommon here as the growth of the city outpaced its internal improvements and maintenance for years. At least there's clip art!


But yes, I'm holding out fine so far, thanks.


JFW's 130 top Trilema picks to date

Filed under: Bitcoin, Hardware, Historia, Lex, Paidagogia, Philosophia, Politikos, Software, Vita — Jacob Welsh @ 16:25

Inquiring minds have asked of me to please shed a bit more light on what this Republic thing and that Popescu fellow in particular are all about. Is there more to it than the ravings that first meet the eye, of sluts and slaves and scandalous sexual predations and every "ism" and trigger word known to man or woman? What's the value I see in it that keeps me coming back? And what's the plan for this world domination thing anyway?

I gave the most accurate response I could, if not the most helpful: see, all you gotta do is read a couple thousand articles in multiple languages averaging maybe a thousand words each, a couple times over, and likely a bunch of the imported cultural environment and extensive chat logs besides, and then all will become clear! At least as clear as it can be so far. At least I think it will. But what would I know, I'm a long ways from being there.

Well great, so couldn't I at least give an executive summary? Not exactly an easy task either. Short of that, here's an attempt at picking some of the especially interesting, informative or significant articles on Trilema from my reading so far, a map of sorts of enticing entries to the rabbit hole.

The very unfair process that articles went through to make this list was as follows:

  1. I extracted an initial set of 957 items from my presently accessible browsing history, using some CLI magic.(i)
  2. I narrowed the list to those where I believed I recalled something of the article, going off the title alone. This brought it down to 424.
  3. I further selected based on roughly the above "interesting, informative or significant" standard in my subjective perception, again by memory from title alone.(ii) I also ended up skipping some that would have met this by way of having especially horrified me; not sure if I've done anyone any favors thus, but there it is.

The ordering within each publication year is merely alphabetical (because I can't quite see a pressing need to do it better in this context).

Enjoy... if you dare. What can I say, it's not for everyone.










  • The slap and human dignity
  • Fin.

    1. You know Firefox keeps this in a SQL database, yes? Because they told you about it in the manual, and documented the schema and all? [^]
    2. At times I was overpowered by the temptation to go check, with the inevitable expenditure of time on re-reading which, useful as it can be, I hadn't planned on getting drawn into just now. And while my shiny tools got this down to a minimal "this button to keep, that button to skip" flow, they were entirely powerless to speed up the thinking. [^]


Bitcoin transactions and their signing, 2: attachment

Filed under: Bitcoin, Software — Jacob Welsh @ 20:10

Having outlined the shape of the building block provided by digital signatures, we now face the potential problem of how to attach signatures to the messages they sign. The one hard requirement for any attachment scheme is that the verification function can work, that is, can answer unambiguously whether a signature is valid for a specific message and key. I will explore the space of possible approaches here,(i) then describe the one used in Bitcoin.

The simplest approach is to say: "what problem?" That is, treat the message and signature as separate objects (bitstrings, numbers, files or however you like to think of them) and use some external system to organize them. This is known in the traditional GPG toolset as detached signing. It has its advantages, besides the obvious "less work to implement". The original, unmodified message is directly available to the reader and his tools. New signatures can be added to a collection without duplicating or modifying the message object, and thus without needing further verification that they in fact refer to the same message. These properties are exploited in present manifestations of the V version control concept.

Assuming one does indeed want attached signatures, then, the first option is to package the message and signature together in some container format. Depending on how it's done, this can preserve the advantage that at least a semblance of the original message is readily visible in plain text, as with GPG clearsigning.(ii) New signatures can be added either with support from the container format, producing a single multiply-signed document, or without such support, either by nesting (such that each new signature references the previous stack) or duplication.

A second option, when the message represents a formal data structure, is to embed signatures in that structure itself in an application-specific way. At first sight this appears to be a circular data dependency: how can a signature be computed for a message that includes a representation of that signature?(iii) However, this can be worked around by applying a transformation to clip or whiteout the signature field at both signing and verification time.

The third and final option is to generalize the previous into a flexible or perhaps even universal embedding scheme. For example, signatures can be wrapped in whatever comment delimiters are available in a programming language, as seen in Mircea Popescu's recent proposal.(iv)

Bitcoin transactions, we can now say, use option #2: format-specific embedding, though with some added complications as follows.

The signature on each input is wrapped using the "script" encoding, in a field originally named "scriptSig", and its interpretation is determined by a corresponding script in the linked output being spent, originally "scriptPubKey". If we constrain our interest to transactions in the standard pay-to-pubkey-hash form, these considerations reduce to a formality.

The whiteout procedure is basically to replace the scriptSig on each input with an empty script. This implies the signatures are independent of each other. The twist, though, is that for the input for which a signature is being computed, the scriptSig is replaced instead by the corresponding scriptPubKey. I can't see any security advantage in doing this, since the previous output is already referenced by a unique identifier(v) covered by the signature. The result is that a different message must be signed for each input, and transaction verification takes quadratic time with respect to the number of inputs. This makes for a good reminder that the Bitcoin protocol externalizes much of the cost of transacting onto all node operators, and unless a satisfactory solution to that tough problem is deployed, transaction throughput must be kept a scarce resource.

To be continued.

  1. I struggled more than usual in writing about these, perhaps indicating I didn't grasp them as well as I'd thought. I don't claim to be equipped to discuss why one choice might be philosophically preferable to others; yet neither can I take a "purely technical" approach since cryptography is necessarily shaped as much from above by its utility to human society as from below by mathematical possibility. Maybe search the logs? [^]
  2. That format however incurs further complexity from tackling the additional perceived problems of linefeed normalization and in-band bracketing for inclusion in a larger text, with the drawback of having to quote instances of the magical bracket sequence in the signed message. [^]
  3. Such a message can be conceived as a fixpoint of the hash-sign-attach pipeline, but finding one in practice would seem to constitute a severe break in the cryptographic primitives. [^]
  4. It's not yet clear to me if or how this can be implemented reliably. For starters, how would you distinguish actual signatures from, say, quoted signatures, without knowing the lexical rules of the target language? How would the "whiteout" work to produce the same hash after addition of new signatures, without knowing same? [^]
  5. Well, not quite unique but at least identifying its contents including the scriptPubKey in question, to the extent you trust SHA256. And if you don't trust that, the signature hash would seem to be the bigger problem. [^]


Bitcoin transactions and their signing, 1

Filed under: Bitcoin, Software — Jacob Welsh @ 23:42

As my offline Bitcoin signer nears completion, it's a good time to introduce just what Bitcoin transactions are anyway, how they are signed, and not least of all how it could go horribly wrong if we're not careful. This first part will cover the basics that I consider required knowledge for anyone who handles the currency.

A Bitcoin transaction is a message with particular structure and binary encoding rules,(i) specifying the transfer of given quantities from one set of accounts to another.

Transactions are composed of inputs and outputs. Each output specifies a monetary value and a destination address.(ii) Each input contains a reference to a previous transaction output(iii) and a signature authorizing its spending. In a quirk of implementation, the "accounts" mentioned above don't explicitly exist in the system; outputs are considered either unspent or spent in full by inclusion in a subsequent transaction. Your available balance, then, is the total value of unspent outputs for which you are able to issue valid signatures. Since the amount to be sent isn't usually an exact sum of previous outputs, a "change" output is added so as to overshoot and send the excess back to the original owner.

Observing that the scheme as presented so far rests on the strength of the signature, let's briefly expand on that concept, leaving the mathematical details as a black box for present purposes. A digital signature scheme provides three high-level operations: key generation, signing, and verification. Key generation takes some cryptographic entropy as input and produces a public/private key pair. Signing takes a fixed-length message hash, a private key, and possibly some further entropy and produces a signature. Verification answers whether a purported signature is valid for a given hash and public key. This gives a high degree of confidence that the signature could only have been issued by someone with knowledge of the private key (as long as some underlying unproven mathematical assumptions hold, which they appear to have so far despite ample incentive to break them). Note the distinct advantage over traditional pen-and-paper signatures: simply seeing one does not grant an ability to forge it or pass it off as covering some other message, despite the susceptibility of digital information to perfect copying and easy modification.

To be continued.

  1. Due to an unfortunate misallocation of brain cycles by Satoshi and the others who imagined themselves Bitcoin developers in the early days, there's a whole cocktail of encodings with, for example, at least four different ways to represent integers. While this makes for some added implementation complexity, the details aren't especially important for normal usage. [^]
  2. Technically a "script", but for simplicity we'll consider only the standard "pay-to-pubkey-hash" form. [^]
  3. Except in the case of "coinbase" transactions which issue mining rewards. [^]


Warm and cold, new and old, fresh and salt 4: free falling

Filed under: Vita — Jacob Welsh @ 05:11

Continued from part 3.

A ski trip was about the only suggestion I had for my Christmas list, and for this time around I was treated to a generous three-day stay at Sunday River, one of the top East Coast resorts. I hadn't made it to the slopes since a 2014 Colorado trip; while there are some decent options in Virginia and nearby, the season is on the shorter side making December visits a hit or miss affair.

We stayed at the Snowcap Inn; while on the property, it wasn't really in gear-laden waddling distance to the ski area, and the room was on the basic side for the price. I figure lodging in town would be the better value; the dining certainly was.


The first day followed on the heels of a nice New Year's Eve powder dump, leaving things a bit on the lumpy side, easy to catch an edge especially when as rusty as me. Nothing I couldn't bounce back from though, and the skills and confidence came back soon enough. Conditions were excellent and temperatures quite comfortable the next two days.



The views are fantastic.



Lift rides can be a good chance to strike up conversation with strangers, though many seem to actively avoid it.



Looking down to the halfway-up Peak Lodge, the favored spot for a hot lunch or just a hot chocolate.













Salvation's closed, obsession's the only way.


In what's surely a metaphor for life, the harder trails tend to be easier than the noob ones - once you're good enough to handle them - because of less traffic.


People even live out there in that nowhere.


Yours Truly.





We have to shovel? Life is hard!



$5 got you a large Belgian waffle. The olfactory advertising covering a good 50 foot radius was all it needed.


Frosted spruce trees, don't they look tasty? (I'll hazard a guess that the aim made sense earlier in the day due to wind.)



"Airglow", heading off to the right, was probably my favorite: steady don't-forget-to-breathe downhill thrills yet nothing too treacherous.



Thin cover in parts.


I'm a decent skier, though I still steer clear of the double-diamonds (highest difficulty rating), so there'll be no view from past the event horizon.

Growing up I only had a couple trips - mainly through Boy Scouts - which were enough to know I loved it but not nearly enough to get over the initial ineptitude. I made the investment in college, picking up some gear of my own, a season pass, and arranging my spring semester schedule to fit the twice weekly carpool with the ski and snowboard team.



One alone stands tall.


The golden hour.




Back at the inn.



Sadly not a real wood fire, though still cheery.



Stretching out a bit and checking the joints were still in working order.


The end of the trip brought the end of the holiday, after a last night at home, some morning reflection and farewells.


Connecting through Newark (EWR), the C gate was filled with a microphone and camera array posing as an entertainment and shopping system. It was eerie.


Somehow it was my camera that stuck out as odd?


America loves its veterans, and makes sure the supply keeps coming.




The chairs being bolted down at the designated sitting distance from the desks turned what was trying hard to be a comfortable setup into just another reminder that yes, you're in a public airport.


We have the figure at 5,596 iPads, on the good authority of Oatly.


If they were gonna be watching me, it was the least I could do to return the favor!



But not to worry, they delete the officially announced images. And it's probably even true: who could possibly be bothered to sort through it all?




Warm and cold, new and old, fresh and salt 3: downtown Portland

Filed under: Vita — Jacob Welsh @ 03:24

Continued from part 2.

Let's proceed to a stroll downtown, starting from the Waterfront (Old Port) district (archived). It's all very brick and granite.






I hear the standard baking is excellent; we'll have to stop by on the next round.



Custom house.



The Thomas Block at 100 Commercial Street, dating to the mid-nineteenth century.


All the key financial services, except for the free cash machine.

BITCOIN Sold Here, lottery, ATM

Heading inland; at left is the Time And Temperature Building with rooftop display of... guess what.





John Ford surveys the intersection from the director's chair.







Driving was complicated more by the artificial obstacles of turn-only and bike lanes coming and going without warning than by any actual hazards.


The Maine Lobsterman depicted in the square outside the Nickelodeon Cinemas.




Woodman Building


We've seen the Thomas, now here's the Thompson Block on Middle Street. There's not much construction predating 1867, on account of much of the city having been destroyed by a fire in 1866.



Works Progress Administration conduit #376. Er, I mean Morgan Stanley.


Some new growth.



Karen McDine entertained over dinner and craft beers at a singer-songwriter showcase hosted at Blue, with songs flowing from the ever-abundant streams of love, loss and longing. This Tim guy followed, whose baseball cap entirely shadowed whatever expressions he might have had and whose indistinct crooning became unbearable in short order. My mom, who has no trouble letting you know what's on her mind, initiated the escape plan, though we were slowed by not having arranged for the check.


In the guest bedroom upstairs, parts of the relocated library were looking tempting; more so than the first few thousand times the spines had passed through my field of vision at any rate. I ended up sticking with what I'd brought though.


To be continued.


Warm and cold, new and old, fresh and salt: part 2

Filed under: Vita — Jacob Welsh @ 23:55

Continued from part 1.

My last morning in Rutland we met up with a prospective client. He was affable, seemingly enthusiastic about our digital security training offering, and efficient in the meeting itself, though in its circumstances showed some fluid notions about time.

Robinson planned to see me off with a famous Gill's Grinder for lunch, but there was a lineup running nearly out the door, so we stopped instead at the apparently underrated Maxie's.

Back in Maine, I observed that my nose wasn't taking so well to the climate and I'd been waking every morning constricted. We figured the problem was the dryness, so made a stop at the aptly named Maine Hardware to pick up a humidifier and other sundries.

The bum seated at left (only one I noticed on the trip) asked for change, adding at once that it was for coffee and he didn't drink.


The shop was indeed well stocked on all sorts of hardware and the staff eager to help.

The humidifier seemed to help somewhat - or at any rate gave the feeling of doing something to be in control.


I'm just now noticing the broken glass and boarded windows at the "OPEN" Halaal market.


There's an Eastern and Western Promenade adjoining some older upscale neighborhoods, with hillside views of city and water. Here, the Western.







My guide takes in the scenery.


Thomas Brackett Reed, who resigned from the House while Speaker over the Spanish-American War.



On the distant horizon, possibly the White Mountains.


Golden hour in the suburbs.



There's an extensive network of walking trails in and around the woods. Here, fluffed out cattails.


Putting together some lunch at the new place.



We headed across the street for a delicious, ample and somewhat chaotic Christmas dinner with the extended family. (Having a kids' table works in theory...)




We headed up to Boothbay to do some further winterizing of the cottage. There used to be a pine forest on the rocky ridge nearby, but what with being a rocky ridge and all, the trees weren't deeply rooted. Much of it had to be cleared out after some went down in a heavy storm.


Log cabin in the woods, better hidden in summer.


Cottage interior.



Views of the Sheepscot River from nearby Porter Preserve.



Ducks (or possibly cormorants), osprey nest, locals and tourists.





Among the rocks was a small sandy area with signs of assorted flora and fauna.



We went down to the touristy harbor area and dined at an Italian place that struck our fancy.



Whale watch, boat trip and puffin cruise on pier 7. In season, we haven't gone for those larger scale things, instead finding our sea legs on ferries to the outlying islands or on the Schooner Eastwind. For more vigorous and independent adventures there's kayak rental, and one year we found a guy able to rent us a small outboard skiff. Skippering that all around (after some instruction from dad) was probably the most fun I ever had on the water; sadly the litigious climate was making business increasingly risky and I doubt such a rental could be found anymore.


Every time I go back, the place feels a little bit smaller, though it still has its charm.




Up the road, the Coastal Maine Botanical Garden was putting on a light show to attract some off-season traffic.




Moose crossing!


A local tradition is to have the kids build and furnish these "fairy houses".







It was pretty cool! Easily the same scale if not larger than the similar ZooLights in DC. The hot chocolate did brisk sales.

Back in Portland, we had an item to return at a small branch library so I took a peek inside.







It was a short drive south to see the iconic Portland Head Light.

There was a memorial for the USS Eagle-56 sub-chaser:


This is not the light.


This is!



Quoth the plaque:

Henry Wadsworth Longfellow often walked from Portland to visit this Lighthouse. The Keepers were his friends and it is believed he sat here for inspiration for his poem "The Lighthouse"

"Sail on: Sail on ye stately ships,
And with your floating bridge the ocean span.
Be mine to guard this light from all eclipse
Be yours to bring man near unto man."


Watching the watcher.



People can have interesting reactions to finding themselves in the camera's sights. A common one seems to be assuming that they're in the way.


200 years of keepers of the light.


What does he see?


Just some wiring, comms and a model in storage.


It turns out paint doesn't make for the most lasting of memorials.





Of course I'll have to go check out the cliffs.


Town of Cape Elizabeth and possibly some of Portland.



Abandoned naval fort.


Turns out the light was commissioned by Washington himself!



Special delivery, one shed.


And down to the water.




A vein of Shiny White Rock (technical term).


There's a park area around the old Fort Williams.



It was a prolific year for acorns; they have this cycle apparently.


Back in Portland to see the Eastern Prom.


The same fort from earlier, from the other direction.




I can just see it going through the Panama Canal.




Sailboats in storage, behind some large barge.


USS Portland monument.




To be continued.

Older Posts »

Powered by MP-WP. Copyright Jacob Welsh.