athornton

I'd had my eye on Tim Molloy and Chris Willett's Painted Wastelands for some time. I'm a huge fan of Luka Rejec's Ultraviolet Grasslands and this had a similar vibe and art style. Indeed, I was a little worried it would be suspiciously similar (it isn't). Sure, there's UVG in it, but there's also Acid Death Fantasy, Isle Of The Unknown or Carcosa, and Lovecraft's Dreamlands. The visual style is (like Rejec's) quite Moebius-influenced but Molloy goes for a ... well, I guess there's a better word for this, but, a very Oglaf color palette, lots of purples and pinks and blues, not the more muted tones of most of UVG.

The beta PDF arrived, and the same week a friend who runs a UVG group, who didn't want to put in his usual prep because it was his birthday, asked me to do a guest slot. We had an absolute blast.

I'm not going to explain anything about the following. If you've got the PDF you will recognize these things, and if you don't, you may be intrigued.

I murdered the party in the long hall of Tomb Of Horrors to start (I didn't tell people much about what we were playing, and started them off in a place that, knowing me, they quickly recognized and feared), and then they came to in a canyon where they met The Painted Skull and then were rescued by Gorto, although my Gorto's name was the first seven notes of the Terrapin Station main theme (as with the UVG game I ran for a couple years, I've leaned heavily into the 1970s psychedelic rock aspect; the end of the game included a long discussion of the merits of various eras of Blue Öyster Cult renditions of "The Last Days Of May").

He sent them to get one of the Perpetual Concert tapes, which took them via the Sorcerer's Market to the King Forgotten To The Ages (since it was a one-shot, I montaged most of the actual travel) and eventually the King's treasure room. The grasping chains turned out to be a tougher fight than I expected, although later on they got very lucky with the Knight and he didn't last long. Since I'd planned that to be the climactic fight I was slightly disappointed, but the dice were on my players' side.

My players are excited to go back sometime and play through some of the other locations and stories. Prolix The Bleak seemed to be a fan favorite. We played with Risus rules, and one of my characters needed to heal off some damage to her Eco-Terrorist cliché; Prolix, in his trove of forbidden knowledge, naturally enough had a book on tape of Edward Albee reading The Monkey Wrench Gang. The Market in general was a very good place for the players to get a feel for the vibe of the world, meet some weirdos, and get some leads on where to go next; having specific merchants made it easy for me to know who was selling what and to not have them be Generic Fantasy Shops.

The whole thing riffs really well. It was very easy to roll with whatever weird-ass direction my players wanted to take things (and with Risus, you tend to get very lateral-thinking solutions to problems). The Molloy art is delightfully specific. Not that I don't adore Luka Rejec's art as well as writing, but in UVG it is rare that I can describe something and then just paste a picture of that thing into the group chat. In this four-hour game, I probably dropped ten pieces of artwork on my players to show them exactly what they were seeing.

The Painted Wastelands setting is not just fun to look at and read, it works really well at the table too, which is not something I can say about all the cool RPG things I've picked up over the years. If you're into a desert hexcrawl informed by stoner rock, you'll enjoy it.

Current Music: BÖC, "The Last Days Of May"

I recently was told one of the sweetest things I've ever heard.

It came from Sam. Sam is the son of Simon. They were both players in my UVG game. Simon died early this year of cancer, and I miss him greatly.

Sam decided to start running his own Ultraviolet Grasslands campaign and invited me to join. As it happens, I'm the only legal adult in the game--everyone else, broadly speaking, is Sam's age, which is to say "in high school."

So I thanked him, saying, "thank you for putting up with an old fart like me," and he replied, "you're not an old fart you're basically the Aragorn to our hobbits," which is one of the sweetest things anyone has ever said to me.

Current Mood: grateful

Truly we live in an age of miracles.

$70 for half an ounce. When I was in HIGH SCHOOL--which was, let's be clear, 35 years ago--weed cost the same, $35 a quarter. And that was not some fancy "Banana Hammock" hybrid strain weighing in at 16.71% THC, no, that was for shitty Georgia ditchweed where what was getting me high was probably the paraquat sprayed on it.

Seventeen-year-old me would have been astounded at the following sentence on so many levels: "Yeah, I mean, sure, the tax break is nice, but honestly I don't smoke enough weed to justify the expense of the medical card."

Current Mood: high

I literally watched capitalism claim another victim today.

I went to the 1702 Brewery with my friend Amanda, who is leaving my project. It was her birthday and I wanted to take her out and visit a little before she left.

1702 was slated to close tomorrow because it just couldn't stay profitable.

We ordered some beer and pizza. Eric, the owner, brought it out. He said "hot hot hot" and set the pizzas down. And then he kneeled down and grabbed Amanda's arm. We asked "are you OK?" and he didn't answer. Then after a few seconds he said "I'm sorry" and keeled over and started kicking and screaming.

I froze up, but fortunately someone said "YOU. CALL 911," and one of my old UA friends, Nirav Merchant, who was also having a closing-it-down-lunch at 1702 stepped up to do first aid.

I got to rip the cushion off a chair (I mean fuck it they're closing tomorrow, right) and get that under his head so he didn't hit it while seizing, and eventually the paramedics got there and got him a little post-ictal, and took him away.

So I don't think 1702 will be open for its last day tomorrow, and I hope I wasn't the final straw for Eric, but...well, fuck capitalism.

I'm not Greek.

I was introduced to this dish, which is the present-in-many-cultures chicken soup convalescent food. This version is cobbled together from several different internet sources and then some experimentation.

What follows is a slightly time-intensive, but not labor- or thought-intensive, rendition from someone who doesn't have the cultural background to know what this soup is supposed to be.

In short, your Greek grandmother will probably curse me if you ever make this and serve it to her.

Makes a little more than a half gallon.

8 to 10 cups of water
1 or 1-1/2 lbs of chicken (once the bones are removed)
2 lemons
3 or 4 medium-to-large eggs
1 onion
1 cup rice
1-2 tablespoons (yes, I said tablespoons) whole black peppercorns
2 carrots
2 stalks celery
4 cloves garlic
4-6 bay leaves
a little olive oil
salt

Peel and roughly chop the onion (into quarters or eighths). Put the onion chunks, the chicken, and the peppercorns into the water. Bring to a boil, then reduce to a simmer. Let simmer for 45 minutes.

While it's doing that, chop the carrots and celery. Sautee the carrots, celery, and bay leaves in the olive oil for a few minutes, and then add the garlic. Turn the heat off quickly, so the garlic is sauteed but not caramelized. Leave the sauteed stuff on the stove for now.

After the 45-minute simmer is done, get the chicken out of the pot and put on a cutting board. Strain the stock, reserve two cups separately (with the rest back in the pot), and throw away the onion pieces and peppercorns.

Add the rice to the stock, bring to a boil, reduce to a simmer, and let cook for 20 minutes.

Shred the chicken (with two forks, or your fingers).

After the 20-minute simmer is done, add the sauteed vegetables and chicken back to the pot. Salt to taste (I use maybe 2 teaspoons for the whole pot; other people like salt more than I do). Bring back to a simmer.

While that's simmering, squeeze the lemons and strain out the seeds and lemon solids. Beat the eggs in a smallish bowl. Then beat in the lemon juice. Then, slowly at first, pour the two cups of hot stock you reserved into the eggs to temper them, beating them while you do (this keeps them from separating in the soup; if you make Hollandaise or Bearnaise sauce, this is a similar process). Once that's done, add the contents of the bowl to the cooking pot, stir to mix thoroughly, turn off the heat, and it's ready to serve.

I like it with crusty bread, but that's a lot of starch and (along with the rest of the recipe) not authentic.

It'll last a couple days in the fridge and quite a while in the freezer. When reheating it, don't let it boil: get it to just-barely-a-simmer. You don't want the eggs to separate.

Current Mood: sympathetic

This one's a little happier. Andrew Thornton of Glen Burnie, MD, is scheduled for his second vaccine dose on March 10. Good for him!

Current Mood: listless

You may know the XKCD comic https://xkcd.com/1279/ "Reverse Identity Theft".

That's me. I get dozens of misaddressed emails a day. Most of them are harmless: there's some guy in England who really likes sports bikes and spends a lot of money on them. Someone keeps buying gas and I get her receipts.

Occasionally there has been family drama that I have been inadvertently witness to.

But today. Oh boy.

I got an email with a form that the recipient was to sign and return ASAP. It was a form someone's daughter was signing on behalf of her mother, to move her to palliative hospice care. The daughter had to sign because the mother was unresponsive.

I wrote back and strongly suggested they find another means of contact so they could find the daughter's actual email address.

This has torn me up emotionally, way more than I expected. I'm sure most of it is my anxiety about my parents and COVID-19.

Tell your loved ones that you love them.

Current Mood: sad

Luka Rejec, author and artist of Ultraviolet Grasslands, asked me to write this up as a blog post. So here we are.

In my UVG/Troika! game, the party has decided to fund their trip to the Black City by staging gladiatorial combats at the places they stop, either just against one another, or against local heroes. In other words, they are basically a professional wrestling promotion, but they use real weapons. (They also use metal folding chairs, fluorescent light bulbs, tacks, and barbed wire, because that's the way hardcore wrestling works.)

I am using a very simple mechanic for this: combat proceeds as usual, but any hit does only one actual stamina damage. The rolled damage is applied to "apparent stamina" which starts the same as real stamina at the beginning of the fight. When apparent stamina is 0 or less, a combatant is out of the fight.

But there's a twist. If someone critically hits, that's real stamina damage (and, of course, since it's critical damage, it's doubled!). This introduces an element of real risk, since just less than 3% of all swings are going to be critical hits.

It seems to be working well so far.

Current Mood: nerdy

Seriously, dude,

What the fuck does he have on you?

It's not just that you're gay, because _duh_. We've all known that for years. No one cares.

So it must be something much, much worse.

What the hell is it?

Sincerely, the American People.

I got a sincere question today.

"Any advice for a new GM?"

The answer to this depends on how much time you've got. An answer could take seconds, or years.

I'm just going to start typing thoughts, in no particular order.

Players are dumber than you think, but also smarter than you think. Constructing clever puzzles for them is going to be frustrating for you, for them, or both. If you think of a thing and a way to solve it, odds are good that they won't think of it. And if they come up with something else and you don't allow that to work, they're going to be mad.

So come up with problems, and for at least problem it's probably a good idea to come up with at least one solution, just so that if they all die you don't look like the jerk when they say "how were we supposed to survive that?" and you answer "no clue. Figured you'd come up with something. Sucks to be you."

Don't be afraid to steal things from movies and books. Your players are likely not to recognize them, and if they do, so what? And if they just start replaying however the hero of the book or movie solved it, well, you can either let that work, or you can change the script. You thought this was _Big Trouble In Little China_? Well forget it, Jake, it's _Chinatown_.

Your role is to enable fun. It's not to show off how clever you are. It's not to beat the players. Nor is it to give them everything they demand. The point of a game is that you take risks in order to win rewards. Both the risks and the rewards have to be real (in the fictive universe of the game) for it to be fun. And part of the fun is the knowledge that it could have gone horribly wrong.

Don't be afraid to kill characters. Killing them without warning is kind of a dick move, unless you've pre-given that warning by, for instance, saying, "OK, kids, tonight we're playing _Tomb of Horrors_ so pull up your big boy pants and get ready to meet a horrible fate." Basically you're in the memory-creation business, and people remember their characters' demises, particularly if they were the result of epic failure or epic stupidity. No one is gonna remember being whittled to death by a pack of 10 orcs twenty years later, but they sure as hell will remember clamping a stick of dynamite between their jaws, lighting the fuse, and then diving into Father Dagon's mouth.

No one cares about your worldbuilding. No one cares about your NPCs. No matter how cool either one is, none of your players are going to pay enough attention to see how hard you worked. Sure, if doing the work, so that there *are* all the hidden connections that make it all make sense, is something you enjoy, knock yourself out. But your players will never know whether you invented an entire culture with its own internally-consistent constructed language, or just plopped down three elves that you named after prescription medications. You're almost certainly not J.R.R. Tolkien or M.A.R. Barker, and it's exhausting to try. Just name your Dark Lord Of Evil "Chad" and be done with it.

Don't sweat the small stuff. Don't sweat rules mastery. If your players try something and you don't know the rules around it for goodness sake don't bring everything to a halt for 25 minutes while you try to make sense of the grappling rules. Is it something that's a 50/50 shot? Great, flip a coin. Probably won't work, but not a bad idea _per se_? Works on 1-2 on d6. Long shot? 1-in-6. Sure, try it if you really want? 1 in 20. And do get a set of place value dice so you can actually roll a one-in-a-million shot. You'll almost certainly never see it happen, but if it does you and your players will be talking about it until your dying day.

Likewise, don't sweat nickels and dimes. If it's pretty reasonable a character could find a thing and afford it, then let 'em have it. If it's ridiculous, make them go on a perilous quest to get it. No one is going to care how exquisitely balanced the game was in ten years, either.

Rolling dice is inherently risky. If you're rolling, something bad could happen. The better way is to present a plan so the GM nods and says, "sure, that'd work." The best way is to make the GM laugh.

Failure is often more fun, and cooler, than success. A nice thing about fantasy RPGs is that there are plenty of fates worse than death. But even so, capturing the players and then putting them in a situation they must escape from is probably more fun than shaving their hit points away until they finally keel over. And if some of the party dies, it's always fun to stage a raid on Hell to get the dead characters back.

Your NPCs and your monsters don't want to die either. There's no reason they have to fight to the death. They probably don't even want to fight. If the party doesn't seem like chumps, then the anatgonists are probably going to want to run away rather than risk trying to kill you and maybe failing. NPCs and monsters can surrender too. Or have changes of heart and decide to come work for the party. Or surrender and keep looking for their chance to escape or betray. All of these are more interesting than just subtracting hit points until someone runs out.

That's probably enough for a brief answer. Maybe I'll write more of this if I think of good stuff. Maybe I won't.

Current Mood: pensive

This recipe is based on the one I got from Vanika Hill. It's easy to make, but it assumes you've already sourced a scoby from somewhere.

Makes 1 gallon.

Ingredients:

20 teabags; sure, you could do this (probably more cost-effectively) with bulk tea as well. It'd be about a half-cup of tea leaves. I have had good results with the following:

* 6 teabags Constant Comment
* 6 teabags Earl Grey
* 4 teabags Green Tea
* 4 teabags Citrus Chamomile tea.

1 cup sugar

1 gallon of water

Process:

Put teabags and sugar in water, bring water to boil, let it boil for 10 minutes or so, depending on how astringent you like your kombucha, cover it, let it cool down to room temperature (which generally means: overnight).

Once cool, pour into a glass container, slide your scoby in, and cover with a cheesecloth or a paper towel secured by a rubber band. The point is to use something that will allow the scoby to breathe, but will keep out dust, flies, dog hair, and all the other nasty stuff floating around your kitchen.

Let it sit on the counter at room temperature for at least a week, up to a month.

When you're ready to stop the fermentation and drink it, pull out the scoby, put it in a glass container, and cover with a little of the tea, and then put the cheesecloth/towel back over it. As long as you keep it wet with something that has some sugar in it, the scoby will be fine more or less indefinitely. You can turn right around and start a new batch, or you could also let the scoby rest for a while.

Then strain the remaining tea through a fine strainer into another container, which you then put in the fridge.

You're probably going to want to strain your kombucha when pouring it to drink, too: even though you strained out most of the scoby, some bits of it got through, and it will happily grow inside your fridge, just at a reduced rate. Nothing bad happens to you if you consume it, but it is kind of like unexpectedly swallowing the world's biggest loogie, so I prefer to strain before drinking.

Current Mood: thirsty

There are two major themes throughout the work of Gene Wolfe: you become what you imitate, and you are what you eat.

This obviously invites the questions, "what should we imitate? What should we eat?"

The answer in both cases is the same: God.

All cops are bastards. Fuck Donald Trump, and fuck the police.

Thank you for coming to my TED talk.

Current Mood: angry

EASY KIMCHI

I based this recipe on https://www.feastingathome.com/how-to-make-kimchi/ but have simplified it somewhat.

Ingredients:

head of cabbage
garlic (I use a head per head of cabbage, but that is a lot of garlic for most people)
ginger (I use maybe a 6" piece for a head of cabbage; that's a lot of ginger too)
chili flakes (use whatever; pizza-pepper red pepper works fine, or you can use something Asian. I use El Guapo Chile Queberado because it's cheap)
And then optional stuff: carrots, radishes, fish sauce, shrimp paste--all things you can add to flavor or color the kimchi, but all totally optional and it will work fine without any of them

Tools/Containers:

Two large bowls
Colander
Jars or bottles (one head cabbage is going to make 3-4 quarts of kimchi)
Paper towels/clean T-shirts/something that lets air but not much solid through
Rubber bands, one per jar/bottle
Vegetable peeler/paring knife
Chef's knife
Strainer or slotted spoon
Blender or food processor, or a knife and a lot of patience

It's really a very easy thing to make, and the resulting product is (at least, I think so) really tasty. It's also not precise at all. As long as you have enough salt in your brine and you have some sort of breathable-but-keeps-random-kitchen-inhabitants out for the fermentation jar, it's going to work, and don't worry about the proportions much.

DAY ONE

First, wash your hands.

Start with the head of cabbage. Peel off the outer two layers of leaves and discard; those are the ones that other shoppers have touched with their filthy COVID-19 hands. Peel off another layer and set those leaves aside (you will need them in a day or so, so a Ziploc bag in the fridge is a good idea).

Chop the cabbage into 3/4" or so chunks. The way I do it is this: cut the head in half. Cut out the solid core at the base. Then take each half, put it flat side down, and just slice it, on one pass vertically and on the other horizontally, with the cuts 3/4" or so apart. Then kinda bash at the stacks thus created to separate them out into individual leaves.

Take a big bowl, and add 1/4 to 1/2 cup of salt and two quarts of water. Stir until all the salt that's going to dissolve dissolves. Put the cabbage in the salt water, and then put a lid over it. It doesn't have to fit the bowl, just make sure that almost all the cabbage chunks are under the water.

Leave this on the counter overnight. At least 8 hours, as much as 24...or probably more. When I make it, this is Day One, and then I come back sometime the next day to continue.

DAY TWO

First, wash your hands.

Peel your garlic and ginger. I use a whole head of garlic and about six inches of ginger for a head of cabbage, but this makes for a very pungent kimchi. If you live with another human, or don't like garlic as much as I do, you might want to ease off the throttle a little. Once peeled, chop them coarsely--you're about to blend them so no point in going crazy here.

Put the chopped ginger and garlic in a blender or food processor, and add the chili flakes. 2 Tbsp is pretty mild, a whole 3/4 oz. package is fairly aggressive. You could also add fresh chilies or whatever here. Dip a little brine out of the cabbage bowl and put it in the blender so that everything will blend. 1/4 cup is probably enough.

If you want to add fish sauce or shrimp paste for a little funk and _umami_, this is the time to do it. It'll be fine if you don't; I like a couple tablespoons of fish sauce in it.

Blend it to a fairly smooth, pungent paste.

Drain the cabbage. Take your other bowl, put the colander in it, and strain out the cabbage into the colander. Once you've done that, press it to squeeze the brine out. Take the collected brine and pour it into the first bowl, and put the cabbage into the second bowl.

If you want to add any other things to the kimchi, this is the time to grate or chop them and put them in the second bowl. Carrots, radishes, celery, whatever. All totally optional, as much to make it look more interesting as to flavor it. "Nothing" works fine here too.

Add the paste to the cabbage (and other items if you added them) and toss it around, getting everything all coated.

Now, take the chili/ginger/garlic-covered cabbage and put it into the jars. When it's mostly full, pour enough brine in to cover the cabbage. You may need to shake the jar to let the brine get all the way through the cabbage. Once you have the cabbage submerged, put one of the saved cabbage leaves on top--this will keep the kimchi from floating up and not being submerged.

Now put the paper towel or cloth or whatever on top of the jar and secure it in place with a rubber band, so fermentation gases can get out and air can get in, but flies/dust/fingers can't get in. Set it on a counter or somewhere out of the way, and leave it there for three days (or more).

Now, wash your hands before you touch your eyes. Trust me on this one.

DAY FIVE

Put a lid on the jar and put it in the fridge. It's ready to eat at this point, but don't feel like you have to be in a hurry.

Kimchi keeps pretty much forever. If you have stuff on top that isn't fully submerged, it might get slimy or even moldy. If that happens, you don't have to throw away the whole container. Just fish out the nasty stuff and throw it away--everything that's still under the brine is fine. It is fairly unlikely, if you like kimchi, that you're going to have it long enough for that to happen.

Current Mood: hungry

The dreams won't stop.

Visions of endless steppes stretching from horizon to horizon, dotted with strange beasts, semi-savage tribes, ancient and malevolent machines of the Long Long Ago, ruins of forgotten technology or magic or both. Endless weeks and months of crawling beneath the unforgiving sky, towards the sunset. Sometimes you'll see it on the horizon: the Black City, slumping blocks piled atop each other, in endless almost-repeating patterns, crouching on the shore of an oily, sullen ocean. It wants you. You want it.

You've been having these dreams every time you try to rest for months now. Lately you've been seeing the visions while you're awake too.

Maybe you're a Rainbowlander, one of the inheritors of the dying earth. Maybe you hail from one of the hermetic societies of the Fast Stars, sent to the surface as an opportunity or a punishment. Maybe you're from one of the Old Colonies on other of the tired sun's planets or their moons. Might be you're a cacogen from beyond the Slow Stars, brought here by chance, accident, or plan--aboard a Golden Barge sailing the humpbacked sky, or frozen in a sleeper-ship. You might even be from another time, or another celestial sphere. Maybe you're human, maybe you're not. Possibly the question of whether or not you are isn't meaningful anymore.

It doesn't matter.

What matters is that you heard the Call, or it might have been that the Call found you. It wasn't difficult to find out where to go: you're not the only person to have received this summons. Far from it.

And so, however you got here, you've arrived at the Violet City, at the Left End of the Right Road. Beyond here, there are no roads, but it's not as if the steppes are entirely unknown. There are caravans. The Ultraviolet Grasslands have things the Rainbowlanders want, and the Rainbow Lands produce things that the peoples of the Grasslands desire. The caravans are always going and coming. They're always looking for people. A lot of people who go to the Grasslands don't come back. Violent mechanicals take some of them. Others just drift off in search of their visions. Maybe they find enlightenment. Hard to say.

So, if you need a frame story: you all meet in a tavern in the Foreigners' Quarter of the Violet City. You have learned to recognize your fellow pilgrims by the haunted light in their eyes. Caravan masters recognize that look too. All that remains is to introduce yourself to your tablemates, choose a caravan, and start the journey.

==========================

What this means in practice:

I'm running an _Ultraviolet Grasslands_ game, using _Troika!_ rules (mostly) (see below for links). It will occur on Thursday evenings at something like 6PM MST and go for 3 or 4 hours a session. It will initially be online, probably over Google Hangouts. Once COVID-19 has passed or become an unremarkable feature of society, we will start having a local table in Tucson videoconferenced in to remote participants.

This game will be an episodic, location-based, pointcrawl. There is no particular need for session-by-session continutity. If you're not there for a while, the assumption will be that you went off with another caravan, and those caravans have met again somewhere in the wastes. Typically each episode will be travel, trade, and/or exploring a location or structure looking for valuable trade items.

However, the campaign as a whole is going to work by Rientsian rules, such that if you're still in the middle of an adventure (as opposed to safely(ish) back at camp) when session time runs out, there's going to be some terrifying table you roll on to determine your fate, which might range from escaping-with-only-a-minor-loss-of-wealth-or-health to wide-distribution-of-your-soul-across-time-and-space.

It's a FLAILSNAILS game. Bring in a character you like and I'll work with you to write it into a Troika!-looking format, or create a new character just for this game. I don't think we're going to care much about jejune matters like game balance. Most things out in the UVG are pretty squishy. Many are not. Some might as well be gods. Maybe some are, or once were, or aspire to someday be, gods. There will always be things you can defeat easily, and things that can crush you without blinking. These things will not always be easily categorized without engagement, so combat should rarely be your first resort.

The flotsam and jetsam of a trillion crystal spheres have washed up on the edge of the Circle Sea. Your character can be anyone or anything. Don't feel like they have to fit any particular genre.

If you lose a character--and you very well may--well, a new one can always jump on board the caravan at the next oasis.

The goal, if there is one, is for your character to make their way to the Black City and meet/confront/embrace whatever it is that's been drawing them. It's a very long way through the Ultraviolet Grasslands from the Violet City to the Black City. There might be some sort of emergent arc. There might not. Maybe you can create one. Isn't it pretty to think so?

====================

How to join: just let me know. You probably saw this on Discord, and direct messaging me there will work. I'm not on Facebook or Twitter. I read my email, but only occasionally--you can try emailing me but no promises it's going to work very well.

Be persistent. I'm disorganized. If I don't reply I probably just didn't see your request.

====================

Resources:

The Ultraviolet Grasslands are a psychedelic-metal inspired setting. You can get a free version at https://www.drivethrurpg.com/product/241606/The-Ultraviolet-Grasslands--Free-Introduction
. Troika is a system that simulates...I dunno, British New Wave SF if
you poured a whole bunch of Gene Wolfe all over it? https://www.scribd.com/document/346627037/Troika-Free-Artless-Edition-10539920-pdf

Things to listen to: Blue Öyster Cult, Sleep (especially Dopesmoker), Godspeed You! Black Emperor, early Black Sabbath. Watch _Heavy Metal_. Smoke too much indica and wander around Ico or Shadow Of The Colossus. Or even maybe Zelda: Breath of the Wild.

Current Mood: worried

I started out with a bunch of simh (well, and klh-10, and dps8...) processes running on a couple of Raspberry Pis; I had their consoles set up under GNU Screen, which let me attach and detach easily, and have everything more-or-less in one place.

For non-console access things were a hodgepodge of telnet-reachable ports; most of the systems had virtualized dz devices (dx busy-waits, which made it undesirable for packing a lot of guest systems onto a small number of hosts) listening on a host port, but some had full TCP/IP stacks and their own telnet daemons.

I got a little sick of remembering which port was which system, so I wanted to build a menu to manage that for me. Remember the early 90s, before consumer TCP/IP was really a thing, where you'd dialup into a terminal server (a text-mode thing then, not the fancy-pants remote desktops we have now), and type the name of the host you wanted to connect to? Like that.

I'm going to tell this story as if it all happened in a logical fashion and made sense, but the actual development was a lot more chaotic. You know how it is.

For writing the menu system I had a couple of design goals. First, since I plan for the list of systems accessible to change as I play with different things, it needed to be document-driven rather than keeping the menu in the code. Second, I wanted to write it in Go, because I haven't really gotten to use Go since changing to my current job back in 2016, and I miss it.

The basic design was very simple: show a menu, take an input selecting a menu item, and exec telnet with the proper parameters to connect the user session to the guest system. Once I'd blown the dust off my Go knowledge, it didn't take a lot of implementation. https://github.com/athornton/tmenu .

Well, that certainly helped; I just needed to run my menu and I didn't have to remember what host and port each system was accessible on. Next I figured I could make this network-accessible, and went to set it up as an inetd service. Well, really these days, it's a systemd service, but same idea: hook up a port to the process standard input and output.

Turned out I was going to have to implement telnet options in both the front and back end to do things like not-echoing-the-password when a user connected, and that didn't seem like fun, and so I decided, "hey, why don't I just put it inside a web-accessible terminal?"

I knew this was likely to work. I work on JupyterLab in my day job, and it has an excellent terminal emulator in it, which is based on xterm.js. So now the problem collapsed to "is there already a websocket terminal application?"

A little Googling got me to "gotty". It seems to have been abandoned, and it didn't quite build with current Go versions, but a little bit of work got me to a version that works just fine. I submitted a pull request, in case it hasn't been abandoned. You can get a buildable version from https://github.com/yudai/gotty/pull/259 .

So now I could run gotty from systemd, and be listening on a particular port (I chose 6180) for HTTP connections, which would upgrade to websocket connections, and let me run my menu.

Well, that's nice and all, but still cleartext, and would require me to open a cleartext port back into my network to expose it. However...at this point, given a web server, which I have, it shouldn't be hard to build a reverse proxy. I use Apache 2.4, which is a little trickier than Nginx (which is what my project at work uses), but it wasn't too tough. The magic setting that took a while to figure out was ProxyPreserveHost On.

With that in place, I just gave the thing a name ("mvsevm.fsf.net"), added it to my Let's Encrypt names, acquired a certificate for it, and then I had a proxied TLS-encrypted web interface to a text-mode front end for a bunch of ancient systems.

Current Mood: nerdy

EXPLORING OLD UNIXES

INTRODUCTION

I recently bid on a PDP-11/70 and a VAX-11/730. I don't expect to win either of those bids, but I thought I'd spend some recreational time installing operating systems on (emulated) PDP-11s to get more familiar with the architecture. I run an OpenVMS system on an emulated VAX and have installed NetBSD on it as well, so I feel like I'm already pretty familiar with the VAX architecture.

I also have an 11/23 in need of restoration. Once I trace its power supply problems (it keeps blowing fuses) it's probably just going to run RT-11 since it only has an RX-02 drive, 256KB of memory, and no MMU. I think I can initially boot it from tu58fs and then build an RT-11 boot floppy pretty easily, and then that's about as far as that one goes. RT-11 is basically like DOS or CP/M: little, single-foreground-process, command-line interface. Boot it, swap floppies, and load your BASIC environment or MACRO-11 or whatever. It doesn't take long to feel like you've basically seen what it's about.

It's the larger PDP-11s that are a bit more interesting, and I thought I'd give the various Unixes available for them a try with SIMH. Think of this as a companion piece to my review of The Unix-Hater's Handbook (https://athornton.dreamwidth.org/14272.html), with a similar methodology: try it out and see what it feels like these days. I'm going to go chronologically by version, rather than by the order I tried them in.

It's worth remembering that Unix was developed as, basically, a word processing and typesetting system for production of Bell Labs patent documents: the system existed to support "roff", a descendant of Multics "runoff". The syntax of "roff" is basically the same typesetting language that still exists in man pages today. If you have a Unix-like system handy, say MacOS or Linux, open a terminal and type "man roff" (if that doesn't work, try "man groff") and you'll find out about the historical environment for which Unix was developed, delivered to you through that very text processing pipeline, almost 50 years later.

PDP-7 UNIX

The earliest Unix available, and very nearly the earliest Unix, period, is a pre-v1 Unix for an 8kword (words are 18 bits) PDP-7. SIMH supports the PDP-7 nicely. This version is basically an archaeological reconstruction. A lot of the original material has been lost, and there's a project on GitHub that builds a runnable system: https://github.com/DoctorWkt/pdp7-unix .

The runnable system build relies on a hosted toolchain to assemble sources and to build a filesystem image. Once it's done that, you can boot from a paper tape and get a shell (kind of) inside the Unix kernel. It's also got a DCI interface for a serial-attached terminal, which SIMH presents as a TCP port, so you can telnet to that port and work from a terminal that is not the system console, if you like.

The user experience here isn't much like Unix. Directories don't work like they later would--rather than a hierarchical filesystem as such, you link things from other directories (there is, I think, only one layer of directories) into your current directory. Good old "ed" is at least familiar enough to use, so you can create a file and then put it on the console with "cat". "ls" works; "ls -l" is even there. It took me a while to figure out that "rm" was "chrm" and required a first argument of the directory from which to remove the file.

Once it's booted, it's possible to reassemble the kernel, which results in a 5767 word(?) file. I have no idea from there how to install the kernel in a bootable location, but presumably that's possible.

UNIX V1 KERNEL WITH V2 USERLAND

From here on out we're looking at the PDP-11: a sixteen-bit architecture, with various schemes to allow 18 or 22-bit physical addresses and various methods to overlay physical address ranges into the 16-bit space.

This particular Unix is the earliest PDP-11 Unix available, and basically the earliest there is, although the userland is v2 rather than v1. It runs on a 32KB PDP-11/20.

This one also relies on a GitHub project to build a bootable system. https://github.com/jserv/unix-v1 is the repository. It functions much the same as the PDP-7 version, but from significantly more complete sources. You build a cross-assembler and a filesystem creation tool, assemble a kernel, and then load it by depositing a bootloader at a particular memory location. In SIMH this is loading a binary file into the simulator; I think you would have had to toggle this into the front panel to cold-boot Unix on a real PDP-11/20. (Once cold-booted, there's a bootloader that gets copied to the warm-boot area of the disk, so if it's not completely powered down, a restart would be much easier.)

Version 1 feels significantly more like Unix, mostly because of the hierarchical filesystem. You use chdir (not cd, and I can almost guarantee you will type "cd" the first time almost every time you try to change directories) and slash-separated paths to move around; most of the devices in /dev look familiar ("mem", "tty", "tty[0-8]", "tap[0-7"], and so forth); the passwd file is in a colon-separated format.

As far as I can tell there's not anything in the way of terminal handling yet, and pipes won't show up for a couple versions yet, but the shell is mostly-familiar, there's a userspace tape-handling program, and quite a few of the utilities we know and love ("who", "wc", "sort", "od", "nm", etc.) and, maybe most importantly, there's a C compiler.

It's a pre-K&R C (described at https://www.tuhs.org/Archive/Applications/Early_C_Compilers/primevalC.html, and some idiosyncracies are mentioned in https://www.tuhs.org/Archive/Distributions/Research/Dennis_v3/Readme.nsys ) which is kind of interesting. It lets you play even faster and looser with char-to-int-to-pointer casts than K&R, and "+=" is backwards, but it's recognizably C.

It only produces files named a.out, so you have to move the file into place yourself, but there's a script to build the last1120c compiler, which can, once built with that script, build itself. Fascinating stuff, and this system manages to feel Unixy in a way that the PDP-7 version just didn't. Like it, you get some terminal devices, although lacking a screen handling library, you're still pretty much using a teletype, whether at the system console or not.

THE GAP

As far as I was able to determine, there are no V2 kernels, and no V3 or V4 Unix, that survive in an easily-runnable form. This is too bad, because two of the very Unixy things happened during this gap.

The first is that Doug McIlroy twisted Dennis Ritchie's arm into introducing pipes to Unix during the v3 period, although separating pipe syntax from redirection by using "|" rather than ">" didn't appear until V4. That made composability of small, sharp tools easy. If you read the "roff" man page earlier, you may have noticed the section "The roff Pipe" which talks about the use of a pipeline in the text-formatting role for which Unix was designed, in which pre- and post-processors, chained together with pipes, perform tasks within the typesetting workflow such as rendering tables ("tbl") or equations ("eqn") within the overall markup processing.

The second and arguable even more crucial item, is that V4 marks the point at which Unix was rewritten in C, making ports to architectures other than the PDP-11 contemplatable. This, however, was not actually done until V6.

It *is* possible, with a good deal of elbow grease, to run a system from between V3 and V4 (closer to V4, according to Warren Toomey): that V3 "Readme.nsys" describes how, armed with a V5 system, you could take the "nsys" tape image as modified by Warren Toomey and produce a V4ish system on a V5 filesystem, that would mostly work. That said, the V4- you get doesn't have the pipe() system call and therefore doesn't have the thing that distinguishes the environment--and arguably Unix As We Know It--the most from the V1/V2 we already have. I have not myself made the effort to run it.

The late, great Mike Mahoney (disclaimer: he was my thesis advisor for the Ph.D. I never completed) did an interview with Doug McIlroy that's still hosted on the Princeton History of Science web pages, that tells a gorgeous story about pipes and about how the evolution of the "Unix philosophy" was a combined...not really effort, more of a jazz-riffing combination of Doug, Brian, Ken, and Dennis all playing together. It's at https://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm and you should read it. There are also interviews with Brian, Ken, and Dennis, and you should read those too. The thing is, the index page doesn't point to the right pages, so you follow the same pattern: https://www.princeton.edu/~hos/mike/transcripts/<lastname>.htm, where "<lastname>" is replaced by one of "kernighan", "thompson", or "ritchie".

It's also in the Unix V4 manual that we are proudly told "there are now more than 20 Unix installations." In 2019 I'm willing to bet there are more than two *billion* Unix installations, if we count Linux and thereby Android as Unix (which we absolutely should). The majority of them are Android devices, in second place we have iOS (which, like MacOS, is basically a BSD userland atop a Mach kernel), and non-Android Linux runs a distant third. Everything else except maybe MacOS is down in the noise, but it's worth noting that Microsoft Windows now ships Windows Subsystem For Linux, which means there's very little out there these days with anything you could call a general-pupose OS (which, as computing gets cheaper, becomes smaller and smaller and sillier and sillier devices) that doesn't have some Unix somewhere in it.

A SLIGHT DIGRESSION (OR IS IT?)

While I was writing this, I came upon the new (at the time of writing) paper "A fork() in the road" at https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

Its basic thesis is "fork() considered harmful" but it's very interesting to consider in terms of the Unix philosophy as we're playing with these early Unixes.

It is probably true that fork() is no longer the best way to do process management if you have complex user-facing applications with many threads of control inside a single process.

Which, er, is why we have posix_spawn(), which gives a lot more control to the user over how the process works. But it's a kind of funny place we've ended up in.

It's not obvious from a modern perspective, but if you look at process creation and *especially* passing open filehandles between parent and child processes in other late 1960s/early 1970s designs, it's a mess.

Unix did something very elegant with fork(): it's a complete copy of the first program, including its open file descriptors. The only difference is the return code, which lets the process determine if it's the parent or the child (or if the call failed). Traditionally then the child would immediately exec() to replace the in-memory process image with one loaded from disk--but retaining the same open file descriptors.

This is an amazingly easy way to do it compared to...pretty much all of Unix's contemporaries. And in a model where a process was expected to do one thing, and that thing was generally: take input on stdin; transform that input somehow; put output on stdout; put errors, if any, on stderr, then that's a wonderful fit.

But in today's world, because we have billions of Unix devices, the predominant applications are no longer byte-stream transformers. They are user-facing, multithreaded, interactive applications, for which fork() really isn't a very appropriate model after all.

Nevertheless, the authors draw the wrong conclusion entirely. It's a whole lot easier to explain fork() than posix_spawn(); it's perfectly fair to say, though, "if you're writing a mobile app, which statistically you probably are, don't do process creation the old-school way anymore."

But isn't it weird and wonderful that a system that was designed for sequential stages of text processing (formatting patents for Bell Labs) has ended up in the position where it's running most of the world's handheld devices?

UNIX V5

The surviving V5 is a single disk image. Consequently it's pretty easy to get going. Of note here is that there's now a disk bootloader; no need to feed the system a paper tape, or deposit a bootloader into memory with the front panel. You just have an RK05 image, you boot from the RK05 device, and when it says "@" you type "unix" (which loads /unix into memory) and away you go.

Once you're there...it's a Unix system. The command "cd" is still spelled "chdir". It doesn't seem to have "tar" or "tap", and there's no "man" yet. The lack of man pages means that the behavior of "stty" is still mysterious, but finally there's source code (in /usr/source/s2/stty.c), but you can't do very much with it, not even set the baud rate.

The kernel is a whopping 25802 bytes. There's "sync" but no "halt", so finally you can at least type "sync" three times (the second and third are to give your fingers something to do while the disk is actually syncing) before you pull the plug (or, much more likely, type Control-E to break to the SIMH command line, and type "q").

I think with a good bit more work this image *could* have a lot of software built for it and it would be a pretty useful Unix, but the image that is available and easy for hobbyists to run isn't really it. So I pretty quickly moved on.

UNIX V6

There are two primary reasons V6 is known and remembered. The first is John Lions' magnificent opus, the _Commentary_. Its Wikipedia page is https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code

. Distributed as _samizdat_ for many, many years, it's how people just a

tiny bit older than me first learned about Unix internals; I first saw it in nth-generation photocopied form in a three-ring binder, but didn't actually get a copy of my own until the 1996 release of the Peer-to-Peer Communications version. It's still a wonderful read; the 6th edition source is clear and lucid (but still very much terse C which doesn't care much about fussy distinctions between ints and pointers), and the explanatory commentary is masterful. If you're interested in the construction of elegant systems in constrained spaces, you should read it. A number of free softcopy versions are linked from the Wikipedia article.

The second reason is that it was the first Unix to be ported to something other than a PDP-11; in this case the Interdata 7/32, which was a 32-bit platform. You can run that as well in SIMH, but I stuck with the PDP-11.

This Unix is the first to be installed in SIMH more or less as you would have done it on the real iron. Instructions are at http://gunkies.org/wiki/Installing_Unix_v6_(PDP-11)_on_SIMH, and it goes like this: you tell SIMH your tape image is write-locked, attach three rk06 drives, toggle in a six-word octal sequence that's a minimal tape bootloader, and run that to slurp the beginning of the install tape into low memory. Having done that, you jump to address 0 and that puts you into a standalone tape-to-disk restore program. You copy a boot block from tape to the first disk's first block, copy the rest of the root filesystem image to the rest of the disk, and then boot from the disk.

That gets you a single-user Unix. Rebuild the kernel (this is a time before scripting languages, so you build a little C program that accepts a very terse definition of devices you want to build into the kernel on stdin, which then builds a little assembly language routine that specifies the available devices). Move the resulting kernel (30346 bytes, if you're doing the stock SIMH install) into place at /unix, build your devices with mknod, use dd to copy the next couple of tape files to /usr/src and /usr/doc (on the second and third rk06 devices), put the mount statements in /etc/rc (yes, a time before /etc/fstab!)...and generally do a bunch of other stuff to turn your system into a workable multiuser Unix system.

This is very recognizable as installing a Unix system from scratch. You can imagine needing to do this in a modern context if for some reason you needed to install a system with truly minimal distribution media and no network; it's not that much worse than bringing up Linux in the mid-1990s before distributions were really a thing.

There's *still* no "halt", "cd" is *still* spelled "chdir", but at least "stty" lets you set a reasonable bit rate on your terminal and remap erase and kill. You still have to use Control-? as break.

In any event, it's about time to move on.

UNIX V7

Version 7 is the Big Dog. There's a contingent that stridently insists that this is the last *real* Unix before AT&T commercialized it and screwed everything up and kicked off the fragmentation that became the Unix Wars. It is the last Research Unix from Bell Labs.

You install this one from the install tape (this time, no toggled bootloader needed). You format your disks with the first non-bootstrap file on the tape (users of more modern Unixes may be surprised that there's no partitioning step; there were not very many varieties of disk and their geometries are hardcoded, so the system knows how big your rp06 is and there's no way to split it into multiple partitions that I know of), restore the root partition from the next, boot the kernel into single-user mode, and proceed pretty much as before.

There are already some nifty convenience features: there's a makefile in /dev which creates a bunch of devices for you, for instance. The "stty" program *finally* accepts '^h' for an erase character and knows it means Control-H. Most importantly, from my perspective, "cd" works, but it's also really nice that "man" is installed. The shell is, finally, Bourne shell. The C compiler is the language described in the "white book"--that is, K&R C at last.

There's still no "halt". Sync three times and pull the plug.

Good old /usr/include is there too. While V7 doesn't ship with "curses.h" I'm sure it's available...although you'll note there's something very very important to Unix that has been missing all through this narrative, and is still missing here.

Right. There's no TCP/IP stack.

This isn't actually that big a deal; there were multiple implementations of TCP/IP for V7, and "tar" is present in all its glory, so it wouldn't actually be that much work to take an implementation, tell SIMH to treat the tarball as a tape device, and it's K&R C, which I speak reasonably fluently. It's nice that "make" is already there, too.

The primary impediment is that the system editor is *still* "ed".

V7 is a thoroughly usable Unix. If you've used one of the minimal containerization-focused Linuxes, where you get busybox (and a shell that is much closer to Bourne than to bash) and not much else, and imagine that with development environments (you also get F77 in V7), you're not far off in terms of feel.

It is in fact so usable that I have followed some instructions from the 'net to replace the included serial driver (DCI) with the DZ driver, which is interrupt driven and therefore doesn't burn a CPU spinning and polling. The tricky bit was driving ed and sed to edit some assembly files; compiling the driver and linking into the kernel was child's play. My v7 kernel is now 54866 bytes, so you can see the bloat beginning to happen.

But most of the reason I didn't worry about TCP/IP for V7 was that it was just easier to install the next and final PDP/11 Unix in my survey.

2.11BSD

This is the end of the line. I leapfrogged a bunch of other Unixes that would run on the PDP-11. 2.11BSD was released in 1992, so it's basically contemporaneous with the release of Linux on the i386.

Installation is still a lot like V7. Boot from tape, do disk partitioning from the first file on tape (you still, in 1992, had to know your disk geometry and calculate sector ranges and stuff yourself), format your disks with the second file, use the third file to restore the fifth file to the root partition, and then boot your system from the disk to restore the rest of the partitions (/usr and /usr/src).

It's a little odd; the console comes up in single-user mode and you have to exit the resulting shell to go to multiuser. I didn't bother to set up terminal devices, because 2.11BSD comes with a TCP/IP stack. I'm running mine on an emulated PDP-11/70 with 3MB of memory, and SIMH uses the Linux tap device to create a virtual ethernet. So I can just telnet to the machine.

This is a modern Unix. If you've used a BSD, you know how to drive this. Kernel source is in /usr/src/sys, the configs live in the "conf" subdirectory, you copy GENERIC to the name of your choice, and edit a bunch of configuration statements, which are largely whether you have any of a particular kind of peripheral, and if so, how many.

Since this is a modern Unix, you've got vi, so you don't need to grit your teeth and struggle with ed anymore. Rebuilding the kernel is as easy as editing your config in /usr/src/sys/conf, running "config" in the same directory with the name of your config as its argument, changing to the directory thus created, and running "make" followed by, if successful, "make install".

However, we can also see why this is the end of the line. If you're doing much--for instance, recompiling Adventure--you're going to be getting a bunch of messages like this:

May 28 13:31:06 pdp11bsd vmunix: coremap: overflow, lost 560 clicks at 055755 May 28 13:31:06 pdp11bsd vmunix: coremap: overflow, lost 608 clicks at 057035 May 28 13:31:06 pdp11bsd vmunix: coremap: overflow, lost 446 clicks at 044566 May 28 13:31:06 pdp11bsd vmunix: coremap: overflow, lost 1 clicks at 012174

What's going on here? That 64K address space just isn't big enough, even with clever overlays and memory management, and even when instructions and data live in separate segments. You can tweak this in the kernel definitions in your configuration, and you can move overlay pieces around in the Makefile, but there's very little room to play. I'm getting these errors all over the place with NBUF set to a conservative 32, MAXUSERS a measly 4, and and NDE (DEC Ethernet) and NSL (Serial Line IP) enabled. I would get a little more room back if I turned off SLIP, but the fundamental problem is that a kernel plus an Ethernet driver plus a TCP/IP stack doesn't leave a lot of room for user programs.

And indeed we see that in the kernel image: /unix is 139573 bytes. 2.11BSD and a TCP/IP stack is about far as we can push a 16-bit system. Of course, by 1992 PDP-11s were nearing the end of their lifespan as general-purpose computing machines (they survived for a great deal longer--some to the present day--in process control and industrial applications). The availability of the Intel 386, a 32-bit extension of the 8086 architecture line, in inexpensive PCs, meant that by the early 1990s you could run Unix or a Unix-like system on a relatively inexpensive microcomputer (I installed Linux the first time in 1992 or 1993 on a 4MB i386 that I got when I went to college; I think the system cost around $2000 new in 1990. I installed the brand-new and still-quite-shaky Linux rather than 386BSD (or was it BSD/386?) for the very pragmatic reason that Linux let me defragment my hard drive and repartition it so I could share the disk between DOS+Windows 3.0 and Linux; as an undergrad there was no way I could afford another disk).

THE SIMULATION ENVIRONMENT

It's worth noting that my explorations here all happened on a Raspberry Pi Model 3. That's a Linux computer. It has a 4-core 32-bit ARM CPU running at about 1GHz, and it has 1GB of system memory. It costs $35 brand new (you do have to supply your own mass storage in the form of an SD card; a 16GB class 10 card is going for $6.40 at Amazon at the time of writing). The case probably added another eight bucks, so total system price is about $50. It's the size of a deck of playing cards. Power consumption is usually well under a watt and maximum draw is about five watts.

The PDP-11 emulator running V7 is being a hog and consuming 12.2% of a CPU core and 1.4% of the memory, while the Honeywell 6180 on the same machine running Multics is consuming 4.6% of one CPU core (remember, there are four cores) and 14.3% of the memory. The TOPS-20 system is roughly 2%/4% and ITS is using about 0.7%/0.7%. So all three of the beloveds of the Unix Haters, plus a pretty big PDP-11/70, are collectively consuming about 6% of the total CPU and about a fifth of the total memory.

Granted, those machines are basically idle; but even when an emulator consumes an entire CPU core, I can still run all four flat out at once. Response time is basically instantaneous; I am sure that performance of any of them is far better than it would have been on the actual machine.

And, of course the system running these simulations is Linux, which is to say, fundamentally Unix. Not bad for a 50-year-old typesetting system, really.

My editing stack is also Unix. Specifically, it's MacOS Mojave 10.14.5, which is a BSD userland atop a Mach microkernel (but which provides all the usual BSD system calls through a compatibility layer). I'm writing this in GNU Emacs 26.2, with line wraps injected at word breaks before 72 columns by text mode with auto-fill, and when I'm done I'm going to format it for my blog with a tool that dates back to ancient days: "fmt" with an argument of "-w 9999" to make each paragraph a single line so the HTML rendererer can do its own job of layout.

USABILITY

This is largely a callback to my earlier review of The Unix Hater's Handbook (https://athornton.dreamwidth.org/14272.html). In that I talked about Multics, TOPS-20, and ITS, three systems remembered very fondly in the early 1990s by people who hated Unix.

I basically stand by what I said there, although I'm using ITS a bit more (I'm trying to port Frotz to it as part of my abiding fondness for Infocom games). I still don't like it and I don't think DDT is a pleasant programming environment.

However: where do these systems stand in usability with respect to very early Unixes, rather than one with all the modern conveniences of windowing systems and well-integrated networking and capable ANSI terminals?

That in turn comes down to "which would I rather use?"

Let's start from newest and work our way back. I'm certainly more productive in 2.11BSD than I am in TOPS-20 or Multics. Now, granted, a lot of that is that I am very comfortable in Unix, and the other two are pretty foreign to me. But if I had to spend a week writing documents or code to perform a task in any of them, it'd be BSD.

Would it be V7 Unix? That's the interesting question. I think it probably would, but I'd cheat. The big thing it's missing out of the box (OK, OK, other than a networking stack) is a screen editor, and more generally sophisticated terminal handling. But it in practice would not be that big a deal: I'd find a curses implementation for V7, I'd get it built, and then I'd get a screen editor built on top of that. Give me vi and I can get by. I'd prefer Emacs, and I presume Gosmacs or an early GNU Emacs exists in some form that will build on a PDP-11. Armed with Emacs and V7, I'd have an easier time than in TOPS-20 or Multics. (Even armed with vi and V7, I'd have an easier time, but I'd resent not having the editor that I've now got more than 30 years of muscle memory for.)

Also, it's basically the 7th Edition that Kernighan and Pike _The Unix Programming Environment_ documents, and like so many other people I read that book to pieces. Because of that, probably more than anything else, 7th Edition feels like home in a way the earlier ones don't.

Maybe that's why I'm not sure I'd say the same about V5 or V6 being more comfortable than TOPS-20 or Multics. A lot of it's cosmetic but I feel like I'd have to do a lot more work to get the system in a shape I'd like to use. The combination of having to write my own "cd" wrapper (OK, OK, that's not really hard), having a shell that isn't quite Bourne yet (as it were), a dialect of C that's not quite K&R, no "man"...effectively, I'd have to fight a lot to turn the userland into something resembling V7 before I wanted to use it, and I feel like it'd be more pleasant to just use Multics or TOPS-20. V5 is still better than ITS.

I can't say the same about V1 kernel plus V2 userland, or PDP-7 Unix. But both of these are the equivalent of the dinosaur skeleton that's mostly concrete with a few original bones imbedded in it. Even so, I can't imagine that the original systems were much more functionally pleasant than their reconstructions. I can do more in ITS than I can in them, and there's a better existing software library, and, crucially, several high-level languages. Sure, ITS C is pre-K&R and is probably basically equivalent to the dialect that exists in the V2 userland, but it at least exists, as well as FORTH and LISP...and also LOGO if I feel an irresistable urge to do turtle graphics.

CONCLUSION

By V7 Unix was about as usable as Multics ever had been, in terms of the experience for a programming or engineering end-user. It existed on machines that could be bought for a fraction of the price of the Honeywells that could run Multics in 1975, when 7th edition was released: the Honeywell 6180 cost about $7 million. A well-specced PDP-11/45 would have been roughly 1% of that: $70,000.

I have had less luck finding the price of a PDP-10, but it looks like large PDP-10 processors cost in the quarter-million dollar range, so it's probably not too wrong to figure that a PDP-10 beefy enough and with enough peripherals to run TOPS-20 happily (TOPS-20 wouldn't be released until 1976, but from this distance, that counts as contemporaneous with V7) is, logarithmically speaking, halfway between the Honeywell and the PDP-11: that is, on the order of $700,000.

And ITS fans...I still think it's some weird combination of nerd snobbery, Stockholm Syndrome, back-in-my-day-uphill-both-ways-blizzardism, and blindingly rosy nostalgia goggles. You could have an equivalently miserable experience elsewhere for a lot less money--which pretty much tracks what I have heard about the MIT experience in general, come to think of it.

So I think my reaction to The Unix Haters' Handbook is still quite reasonable. In some ways the user could get a better experience on a TOPS-20 or Multics system, and a given system could support many more users, but the price tag put these machines far out of reach for almost all of the customers who could afford a reasonably high-end PDP-11. Sure, the documentation was generally better and the overall feel a lot less scruffy, but given the price differential and the fact that the day-to-day user experience was just about as good...well, Ken and Dennis and Doug and Brian and Rob really knocked it out of the park, didn't they?

Current Mood: nerdy

(note: this was first posted on Google Plus in something like May of 2018)

_The UNIX-HATERS Handbook_

Edited by Simson Garfinkel, Daniel Weise, and Steven Strassmann

_The UNIX-HATERS Handbook_ dates from 1994. I read it when it came out or very shortly thereafter, I think. I was a lot more invested in operating system wars back then.

Almost twenty-five years later I decided to revisit it. From today's perspective, it's an interesting cultural artifact.

The tl;dr is:

This book has not aged well. As a book it's incoherent. It's a bunch of loosely-agglomerated chapters about things people hated about Unix in the late 1980s and early 1990s; most of it is drawn from the UNIX-HATERS mailing list starting in about 1987.

The thing it reminded me most of, to be frank, was some dreadful book my late grandfather-in-law had about Obama. That book devoted a whole lot of energy to How Horrible The Negro-In-Chief was without ever stopping to consider that if he was a secret Muslim then he probably wasn't taking orders from a honkey-hating Christian minister, and if his wife was the brains and brawn behind their marriage then he probably wasn't a mastermind of the Black Illuminati. Like that, this thing is a litany of Things Someone Hates About Unix, whether or not those things are mutually contradictory.

From a two-decades-plus-later perspective, the gripes can be filed into one of just a few categories.

The first is, "no, you're wrong. This actually was a sensible way of doing it." That applies to things like "files are just streams of bytes" and "pipe things together." I mean, it's not like we haven't had our share of pipeline systems that dealt with things at the object level. The two I happen to know reasonably well are Powershell and CMS-PIPELINES. Both of those have much, much more complicated interfaces. That makes them somewhat more powerful (in that you don't have to explicitly serialize your stream before passing records or objects to the next stage) but also way, WAY harder to use and to document, because you have to care what your input records are. Now, I adore CMS PIPELINES, and Powershell is...OK, I guess?...but the cool part about Powershell isn't that you're passing complex objects around, it's that you have access, from the shell, to all the DLLs in the system, and thus every single library call. (Apparently you can sort of fake this on Linux (and other Unix?) systems with D-Bus.)

The second category is "yeah, that was annoying, and in the intervening time it got fixed." That applies to the "the GUI sucks" category (I'm writing this on a Mac OS box, and you probably have either an Android or an IOS device in your pocket, don't you?). It applies to the "the shell is clunky" category--and already did by 1994. I remember vividly having to get the muscle memory for tab completion switched over from esc-completion when I started using bash on Linux systems rather than csh on SunOS (or whatever) systems. The Berkeley Fast File System is another target, and, yeah, it has limitations, so we got ext2-and-3-and-4 and reiserfs and ZFS and all the experimental file systems of the last 25 years. But that's also the third category.

There were a lot of things assumed to be essential features of Unix that, in retrospect, were only Unix-adjacent. Sendmail and Usenet are the big two in this particular book. Sendmail is instructive. Yes, sendmail.cf is utterly horrific, and the m4 macros designed to make it suck less were only kind of better. And then we had qmail, which, well, Dan Berenstein and speaking of toxic personalities, and then the world settled down on Postfix, written by someone who was a fairly nice guy, and configurable in a fairly straightforward manner. I myself stayed with Exim, because Phil Hazel was awesome and I understood Exim syntax. And now in the 201xs, it doesn't matter anymore because to a first approximation everyone outsources their mail to Google or Microsoft. (not me! I still run my own Exim system and do my own spam filtering and boy howdy is it wretched since I don't have Google's training corpus)

And finally there's the fourth category: things the book is right about. Yeah, NFS file locking is still terrible, even now. Like, literally the project I am working on right now has to do local locks, which of course means that two people on different machines better not edit the same file at the same time. But twenty-five years later I feel like we can definitively state that distributed filesystems are indeed pretty hard. Another completely reasonable observation of _The Unix Hater's Handbook_: Unix man pages are prickly, incomplete, inconsistently designed, and not very helpful if you don't already know what you're looking for. And while not every system did it better, well, Multics, TOPS-20, and VM/CMS all certainly did, so the dire state of Unix documentation is a fair criticism.

If you want a chapter-by-chapter critique, I will recommend that you read Eric Raymond's review of _The Unix Hater's Handbook_ from 2008: http://esr.ibiblio.org/?p=538 . I'm not a big ESR fan in the general case, but he pretty much gets this right.

There's another thing about this book that is only clear from a modern perspective. When it was written (though perhaps not when it was published), it looked like Unix was likely to win but it wasn't a _fait accompli_. (In the mid-to-late 90s it looked like Windows might manage to strangle all the Unices.)

From the vantage point of 2018, well, Unix won. Unix (which I mean in a broad sense, specifically one that includes Linux) won everything but the corporate desktop. Anything running in the cloud or any service at a data center? Probably Unix. Your smartphone? Almost certainly either IOS or Android. The kernel might or might not be Unix, but the programming model and userland? Unix.

You're probably stuck using Windows at work. But hell, these days, Windows 10 comes with a Linux compatibility layer. Google just released gVisor, which is basically a Linux-syscall proxy layer written in Go. Plop that on top of Fuchsia and you can suddenly run a great many Linux applications, unmodified, on top of a much, much simpler underlying system. So even if you don't *want* to run a modern Unix from a resource perspective--it's what your developers are developing to.

But this is a very strange book, even for 1994. It makes no mention of Linux, which, OK, I guess that's on the edge of acceptability. It makes no mention of Windows, and that's a little weirder. Most of what it seems to be bemoaning is that Unix was winning in the early 90s, and not a descendant of something better. Now it reserves a bit of spleen for VMS, so "something better" seems to mostly mean "TOPS-20, ITS, WAITS, Multics, or a LISP Machine."

DMR, may he rest in peace, addressed this his Anti-Forward:

"The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below."

And at this juncture something is fairly easy that wasn't when ESR wrote his review, and wasn't even possible when the book was written.

I've installed TOPS-20, ITS, and Multics on emulators so that I can evaluate for myself how true this is. I have not emulated a LISP Machine, alas.

You'll note that the first two of those only ever ran on DEC-10s, which were never cheap machines. ITS was pretty much an MIT-specific environment running on a single machine, and WAITS was its Stanford counterpart. Nifty, but of limited reach (although greatly influential in later development of systems). Likewise, Multics was only ever available on extremely large, expensive, and, let's be frank, also-ran machines. I'd love to have a Symbolics LISP machine but they didn't react fast enough when Sun cut the floor out of the workstation market.

So, in a nutshell:

People aren't kidding about Multics. It's a very nice-feeling system, with useful online help. I can absolutely see how if you wanted to kind-of-replicate the Multics experience on the very, very much cheaper hardware of a PDP-11, you'd end up with something like early Unix. But that, of course, is one of the points that _The UNIX-HATER's Handbook_ resolutely fails to acknowledge. A whole lot more people had access to PDP-11s than to GE-645s.

TOPS-20 is also kind of nice. The command editing is well-done. The help system is, once again, definitely superior to Unix's. I can understand why someone would prefer it to early Unix.

A brief parenthetical aside: I found it slightly curious that the retrospectives on the personal computers of my youth (C-64, ZX Spectrum, Amiga, et al) always focussed on games. I mean, sure, those are generally the most visually appealing things on the system, and of course you wouldn't want to try to use those systems' productivity software now, while their games are still fun. And then I found myself installing all these ancient large-computer systems, and what do I run on them? Adventure. Zork. Moria.

And then we get to ITS.

Seriously, people? This is the embodiment of the dark side of the MIT attitude expressed as software. A system that gives you the hardware debugger as its shell, proudly calls its userbase "lusers", and is very forthrightly smug about "if you don't already know everything there is to know about the PDP-10 architecture as modified at MIT, die in a fire." This is a command environment that not even a mother could love. The user experience is dreadful. Sure, I know that Macsyma and Scheme and Zork all came out of here, but...sheesh. This is not merely unusable in the 21st century, it's the epitome of a user-hostile environment.

So, from my brief experiments: sure, there were a few systems around prior to Unix that were better in many ways. They also existed only on extremely high-end and expensive machines and so were inaccessible to the vast majority of people who _could_ afford a PDP-11. ITS is just horrific to use.

I've enjoyed writing this on Emacs on MacOS, which is to say, an editor that first appeared on ITS, but was rather quickly ported to Unix. MacOS is a Mach microkernel with a BSD Unix userland on top of it. I get a perfectly adequate GUI, and I also have a bunch of terminal windows open in which I can do all the traditional Unixy stream-of-bytes pipeline stuff. One of the things about the worse-is-better not-much-there-there model is that it's pretty easy to port things to a Unix/C world, and so it's easy to grab an editor from a different OS lineage and get it working in the Unix model.

This book was whiny and ludicrous when it first came out. It has only gotten more so since. It's still got a few valid criticisms of Unix, but the really interesting thing is how much of what its authors complained about turned out to not be intrinsic at all, and to get fixed rather quickly. I still believe, and the state of computing in 2018 seems to bear this out, that Unix was a good compromise, that gave usability and an easily-articulated-and-implemented philosophy, on top of (relatively) cheap hardware.

Note that this doesn't explain Linux's hegemony. For that we would need an analysis of Free Software and a discussion of the Unix Wars, and this review isn't the place for that. But it does explain why DMR was right, and the authors of _The UNIX-HATER's Handbook_ were wearing rosy-tinted goggles and exercising very selective memory when loudly and inaccurately proclaiming that the world was so much better when they were immersed in the cesspit of ITS.

Some thoughts on race and privilege in the US.
I had a strange experience last night.
To set the stage: my spouse, Amy, was supposed to teach a dog class. I had received an urgent call to get my ass down the street to the bus stop, about half a mile away, in the Smart Car, so I could give that to Amy, because the left rear tire on the van (which Amy had been driving) had gone flat.
So I went down there, turned over the car, and called AAA while getting back to my house. I got the dogs inside, met the driver, and went down there while he chiselled the rusted-on spare from the underside of the van where it had been peacefully spending the last decade, determined that it would sort-of hold air, and put it on, whereupon I drove the little distance back home.
It was there that I determined that our newish Great Dane foster, Jamaica, had left a half-deflated-soccer-ball-sized dump on the living room floor. He's a sweet dog, but very very stubborn and, charitably, not bright. We'd spent nearly an hour outside with him immediately before Amy left, during which he peed but adamantly denied he had to poop. Then I left him unsupervised for less than half an hour, and Turdmageddon.
So anyway. I clean up this massive shit-pile, and take the bag of crap and paper towels out to the trash can at the side of my house. It's now like 9:15, and mostly dark: there's still some gray in the sky, and you can see silhouettes but not much else. That's the east side of the house, and there are stairs that go up along it to the back yard. I have several pots there containing hops and morning glories, and so I decided to water them, as although we have been getting a lot of rain, the rain comes in from the west, and so the east side of the house doesn't actually get rain in the usual case.
So I've gone up the stairs and back with a hose with a sprinkler head on the end, and I'm standing at the end of the stairs when I hear a whole bunch of barking from the front door. Now, I am aware I've been bad and not closed the front door, but just the screen door, because, well, I had my hands full of a bag of dog shit. So it's entirely normal that the dogs crowd the door and bay madly if they see, well, anything the least bit unusual. I think to myself, "I'd better hurry up and get back in before someone complains."
And that's when I see there's a guy walking quickly up the driveway towards me. I can only see the shape, but I think it's a black guy, maybe in his 30s? Not shaped like a kid, anyway. I'm pretty dazed from hiking back to the car and the excitement and unpleasantness of dealing with the dog shit, and I'm taking a while to form the thought, "I guess I should ask him what he wants or if I can help him."
While I'm standing there half dazed, he suddenly darts left and breaks into a dead run into the little gully between my house and the house on the street behind me, and disappears into the bushes. "What the hell?" I think, turn off the hose, and go inside.
It takes me a couple hours to realize what happened from his perspective. He's in the cul-de-sac, and suddenly there are a bunch of ferocious dogs barking at him from behind a flimsy screen door. He's trying to walk away quickly, and suddenly there's a silhouette of a white dude, holding what very easily could be a gun, in front of him, who evidently came out of the same house that the ferocious dogs are in.
So I probably caused someone to need to change his pants last night.
Now, I don't know who this guy was, or what he was doing in my cul-de-sac. If I were of a suspicious turn of mind, I might suspect he was casing houses to see if any looked worth robbing. If that is what he was doing then I think he probably won't be back any time soon. On the other hand, it very much could have been someone just cutting through, on foot, to get to wherever he was going more quickly. Or just someone out for a walk who got a little scared by several big dogs that did not appear well-restrained, and then a lot scared by what looked like a Missouri cracker with a gun.
But that's the thing: *I* never felt scared, or threatened. And that is all down to white privilege. Even if it had been a robber, what, he'd've gotten the forty bucks in my pocket, and could have taken a shitty minivan with a Thoroughly Corroded -3 Continental Spare Tire. (Seriously, the spare on this thing would have been perfect for pudding farming and not much else, and if you don't play _Nethack_ this sentence won't make any sense.)
But for a black man, trespassing on someone else's driveway, and suddenly seeing what appeared to be a white homeowner with a gun? No wonder it was terrifying.

Current Mood: sad

Three Prisons: The Cursed Chateau by James Maliszewski (cover by Yannick Bouchard, graphic design and interior art by Jez Gordon), England Upturn'd by Barry Blatt (cover by Jason Rainville, graphic design and interior art by Sarah Richardson), and Maze of the Blue Medusa by Zak Sabbath and Patrick Stuart (cover and interior art by Zak Sabbath).

I've recently received three RPG books about imprisonment. Two of these are recent Lamentations of the Flame Princess releases, and one is the first thing from Satyr Press. These reviews will not be spoiler-free; if you're planning on playing the modules, rather than reading and running them, you may want to put off reading this piece until you've been through them.

The Cursed Chateau is an expansion and rerelease of James Maliszewski's earlier piece of the same name, which makes it sort of like Death Frost Doom or Carcosa. However, although I've read the earlier versions of each of those, I had never read The Cursed Chateau before.

The Cursed Chateau is a haunted house. It makes this quite explicit in the introduction, and structurally it stays very much within the expectations thus established. Rather delightfully, Maliszewski identifies the specific haunted houses he's evoking as not, in fact, being the haunted houses from crappy horror movies of the 1970s, as you might expect, but rather the (much scarier) haunted houses imagined by the kid whose parents did not let him see these movies but had to imagine them from his friends' breathless reports.

The translation of these movies into D&D modules points to the two modules Maliszewski specifically calls out: Tegel Manor and Castle Amber. I myself see a lot more Castle Amber than Tegel Manor in The Cursed Chateau. But then Tegel Manor makes me think of Scooby-Doo rather than anything, y'know, scary.

A lot of the Amberness is the French setting of The Cursed Chateau. However, I think Maliszewski is going for a more weary and decadent feeling than Castle Amber; more Baudelaire than Clark Ashton Smith. Indeed, the foreward to Les Fleurs du Mal could just straight-up be slapped onto The Cursed Chateau and it would fit just fine. As a matter of fact, the tl;dr summary of The Cursed Chateau could probably be "Roll Castle Amber around in Les Fleurs du Mal for a while." (One might also note that Room 22 of Castle Amber itself is named "Flowers of Evil.")

Funhouse dungeons get a lot of their fun from how gonzo and, generally, ridiculous, the juxtaposition of stuff-that-doesn't-make-sense is. Tegel Manor has very little in the way of organization or theme (beyond, "Rump Family! Kooky House! Go!"); it's a terrible read, but it's a delightful setting to actually play in. (If you're ever at Gary Con and Kevin Kelly is running Tegel Manor, do try to play.)

Castle Amber (and The Cursed Chateau) are far less goofy, although they certainly contain their share of WTFfery. Neither one is the sort of anything-goes kitchen-sink lunacy that Tegel Manor is. Their tone comes a lot closer to Gothic Horror than to Scooby-Doo.

The Cursed Chateau begins by trapping the party in the Chateau and its grounds; once they enter, there's an impenetrable force field that keeps the party imprisoned until they sufficiently amuse the undead Lord Joudain, master of this domain, which will break the curse that holds them inside the Chateau. (Note the similarity to the fetch-quest required in Castle Amber to break the curse and dispel the gray mist preventing the party from leaving; however, the exit criteria seem much more discoverable in Castle Amber.)

Joudain and his entire staff are undead, and trapped in eternal ennui (along with any unfortunate visitors) until someone can lift the curse by sufficiently amusing Joudain.

The goal of the module, therefore, is simply to perform enough amusing actions (with few enough tiresome ones) to fill Lord Joudain's Fun Meter. This is unlikely to be discovered quickly by the party. In turn, this implies that the party is going to spend much of its time aimlessly wandering the house and grounds, encountering the various undead NPCs.

The NPCs are quite good. They are certainly the best part of the module. Each one typically has one or a few strongly distinguishing traits, which would help an even minimally observant party tell them apart, and perhaps piece together the history of the Chateau and the nature of the curse. They have relationships with one another. Some are implacably hostile to the party, and some may be neutral or friendly. I am particularly fond of the young Guilhèm and Landri the long-suffering majordomo.

There's a hedge maze with a lilac bush I recognized (as Stetson's) from Eliot but which likely comes originally from a Symbolist. There's also a basement dungeon with a batrachian theme; some sort of Arnesonian nod, I guess. It all hangs together pretty well, in a world-weary decaying-finery kind of way.

The whole thing is--by design--pretty dour and joyless. This is certainly meant to reinforce the themes of the scenario, but it makes the module kind of tough going. And therein lies the problem.

I'm pretty sure I'm never going to run this module for any of my current groups. None of them pay enough attention, and thus they will never figure out how to break the curse. Everyone will get cranky and butthurt. If you have a group of players who like solving mysteries and don't mind a fairly slow pace, you might get better mileage out of The Cursed Chateau. For my use, well, I just can't see it producing much enjoyment for me or my players. That's no indictment of the work, just a realization that I want more freewheeling gonzo and less mannered melancholy, and that my players tend not to be detail-oriented.

The PDF is cleanly laid-out, in black, brown, and tan. What the PDF does not make obvious is that if you buy the physical book, all the "tan" is metallic ink, and it's a much more golden color than you'd expect from the PDF. Yes, this drives up the cost of the book a lot. Is it worth it? I'm on the fence here. The book is otherwise a typical LotFP hardcover: slick cover, slightly-larger-than-digest size, solidly bound. Still, 27.50 € is pretty steep, and this isn't a book that is stunningly beautiful the way Maze of the Blue Medusa is. If you want a melancholic haunted house, and you want a pretty physical book, it's worth getting. The PDF is $7.50 at DriveThruRPG, which seems reasonable for what you get.

In summary: not my cup of tea, but if you want a gloomier Castle Amber, it might be yours.

Next we have England Upturn'd by Barry Blatt. As you might guess from the title, it's set during the English Civil War, and it owes a great deal of its setting to Christopher Hill's magnificent book The World Turn'd Upside Down. That all by itself endears it to me.

The premise is insane and wonderful. Basically, Bad King John was a sorceror, who came into possession of a phylactery to hold his soul upon his death. That phylactery was lost somewhere in the Lincolnshire Fens in 1216 with the Crown's treasure, and John's soul entered it upon his death a couple weeks later; it has remained imprisoned there ever since.

Back in the present of the module--which, not coincidentally, happens to be the spring of 1642, just before the English Civil War boils over--the Crown has now given out private charters to drain the fens; if a wealthy man drains the fens, he gets to claim the drained land (which was previously common-use) as his own. I'm sure that any current political allegory is entirely coincidental, and anyway, those guys draining the fens were actually doing something kind of useful, unlike modern financial services. I seem to have gotten off in the weeds.

So you have England simmering in a state of economic unrest. You have Ranters, Diggers, and Levellers. You have Irish Catholics looking to foment religious trouble. You have the usual LotFP collection of Rich Guys Who Are Right Bastards And Also Secret Diabolists. Andrew Smeaton is ostensibly draining a swamp, but he knows that John was a sorcerer and is looking for his magical artifacts so he can gain great sorcerous power. Of course, this being LotFP, the phylactery is with the stuff he really wants, and when that phylactery is popped open and releases the soul of Bad King John from its long imprisonment, the results will be disastrous. They will almost certainly involve a PC being possessed by John. Hilarity will ensue.

But that's not even the crazy part. No, the crazy part is the Swedish Witchfinder Niklas Brahe. He thinks he's an avatar of Odin, and might actually be, and his plan is to enact the ritual that gives the module its name. That's right: turns out we're not talking about social upheaval, but a curse that will flip a big chunk of Lincolnshire into the Hollow Earth and the corresponding chunk, populated with Niflungr (scary sea-faerie types), into Lincolnshire. The bad-assest of them will be--of course they will--in a castle on the back of a giant turtle, and they're looking for King John to exact their revenge.

Since he died 400 years ago, that'd be a problem--except that now he's probably back, and likely inhabiting the body of a PC.

I don't know that I'm ever going to play straight-up LotFP, and I don't know that I particularly want to run a game set in an almost-historical Thirty Years' War, which is the LotFP setting. Still, I feel like I am a lot more likely to use this than The Cursed Chateau. Although most of this stuff is pretty grounded in the setting, it would be trivial to steal "old king's soul imprisoned in just-unearthed treasure" or indeed "big chunk of underworld flips into game world, or vice versa."

There is one rule-system change that warms the cockles of my heart: Alignment changes. The Law-Chaos axis is replaced with Cavalier-Roundhead, and Good-Evil with Royalist-Republican (the chart on p. 106 seems to be incorrect in the lower right and should be Republican Roundhead, I think).

I freely admit that I came to this module primed to enjoy it. As I said earlier, I love Christopher Hill, and in fact my grad school roommate's Ph.D. thesis was about the draining of the fens. Also, I've played in and enjoyed some of Barry's games. In short, though, it does not disappoint.

The historical research here is good; not just Ranters, Diggers, and Levellers, and their songs, but, most crucially, Muggletonians. Seriously, these guys actually existed, and are the finest Christian cult ever. Although their God is probably slightly shorter than the Jesus of Silver John, they...well, wow. Mad props to Barry Blatt for not only pulling them into LotFP, but making their cosmology ontologically correct within that world. I'm also a big fan of using the Sephiroth and Tarot to drive game-world occurrences, and it's a thing that pops up over and over in my games, so again, yay Baz Blatt Confirmation Bias!

On the other hand, it seems pretty cruel to ask the reader to peruse Liber 777 to do more Sephiroth/Tarot-associative magic. However, if you really do pick up Liber 777, tell me that it doesn't read like David Hargrave's Arduin tables. Seriously, I'm thinking of doing a web quiz that is "Crowley or Hargrave?"

In summary: England Upturn'd is highly recommended. As a physical artifact, it's an LotFP paperback. Well-constructed, looks nice. It's not terribly expensive at 16.50 €. If you want physical books, great, you won't be disappointed, and if you are happy with PDFs, then there you go; also $7.50 at Drive Thru RPG.

And that brings us to Maze of the Blue Medusa.

Holy shit, is this thing big.

It's going to take a lot of preparation to run this successfully. There are lots of factions and an immense number of NPCs with their own agendas and complicated interlocking plots. The titular character has spent ages in her Maze, largely acting as a prison guard. There are the three perfect Torn sisters, imprisoned. There's a lich who's in love with one of them. There are, in fact, several alliterative liches. There are cannibal art critics in a gallery where metabolism runs way too fast. There's a wedding frozen in time mid-cataclysm involving a machine that turns souls into gold. There's the Medusa's father the trapped-in-an-endlessly-rekeying-puzzle-box devil. There's a Garden Of Live Flowers from Through The Looking Glass only sexier and deadlier. There are the remnants of an ancient Saurid empire and its library, with mummies each stuffed with a particular genre of book. There's a creepy and genuinely helpful child-ghost. There are a pair of petrified werewolf lovers. There are ....

You get the idea.

There's more than 300 rooms of this, and almost none of them are low-cognitive-load rats and 2000 copper pieces.

I've read through it once, all the way, and didn't manage to retain enough of the structure to feel like I can run it. I'm on my second pass now.

The fundamental physical structure of the megadungeon is that it's one of Zak S's hyperdetailed pieces, with lots and lots of geometric spaces of differing sizes, each with an image in it. This then is used to generate a colored, unillustrated, numbered map, and the dungeon is the map of numbers to room contents (which are illustrated in the actual painting). The dungeon is divided roughly into regions: Gardens, Archives, Prisons, and so forth. This makes it slightly easier to keep track of what's going on, although there's still a lot of classic-fun-house things-next-to-each-other-with-little-rhyme-or-reason juxtaposition room-to-room. I don't mind this, but I imagine it's not to everyone's tastes. There's a lot of thematic consistency, but not so much tactical consistency, which makes it feel different than, say, Tegel Manor on the one hand, or the Caves of Chaos on the other.

There's also a Random Encounter table which generates stuff that the party will have to deal with, and provides for mixing of the dungeon regions as inhabitants wander around.

The Patrick/Zak collaboration is a delightful one. A lot of this feels like the same sort of actinic lunacy that powered Deep Carbon Observatory. In terms of bang-per-page I'd have to give the nod to DCO but there is, rest assured, plenty of bang here too. I'm pretty sure that the groanworthy puns are Patrick's ideas (such as the Lampen Proletariat). There's also a shout-out to Baudelaire, if you're keeping score.

Maze of the Blue Medusa seems like it'd be a hard thing to mine for parts. I suppose some of the NPCs could be stripped out of it and dropped into another game pretty easily, but a lot of what makes reading it fun is figuring out who is trying to put one over on whom, and trying to keep track of the web of social plots. It would diminish most of the characters to disentangle them from the others. In general, I think if you're going to run this, you don't have a lot of choice but to run it as a 300-room megadungeon, which may or may not let players leave once they enter. The obvious way out (which is to say, "the way we came in") comes with a fairly strict time limit, although if the players do the obvious thing, the prisoner they immediately free will be back in a couple weeks with her own small army, presenting another escape opportunity.

I'm not actually sure under what circumstances I'd run it. If I had a weekly game with a stable player roster, it'd probably work, assuming they were the sort of players who liked traversing deadly environments, thinking about what they were doing, and keeping track of the relationships of the people in the game. Murderhobos will probably not fare well in here. Since my current group meets more-or-less monthly, and we rotate between three campaigns, we're not going to attempt this: a quarterly run at it is not going to get very far, and no way will my players remember in July any details of what happened in April--and this module will punish them for not remembering. In fact, there's a living mosaic who makes a point of calling out a party that wasn't paying attention when she delivered her riddle.

The titular Medusa, Psathyrella, might or might not be the villain of the piece. She's very likely to be an adversary, but she's a pretty reluctant jailor. She makes a very good case, to the players and to the reader, that killing her is just going to make things a whole lot worse. One of my favorite items in the book is Levalliant Green, Supervillian. He's a perfectly ordinary guy whose superpowers are that he anticipated it all with DMly prescience, and that he didn't do any of the first d4 things the players thought of. This is genius.

And then there's the physical artifact. This book is every bit as beautiful as Red and Pleasant Land, in many of the same ways: robust fabric binding, clean layout, heavy paper. It is larger than Red and Pleasant Land and will not remind you of fairy-tale books you had as a child. But gosh golly is it ever gorgeous. If you're going to buy this, spring for the physical copy, not just the PDF. The PDF is fine; it's totally readable (although my aging eyes require that I zoom in on it). But...damn, the physical book is magnificent. It is right up there with Red and Pleasant Land as "one of the prettiest RPG books I have ever seen." The hardcover is $50. The PDF is a fucking steal at $5. And in this case, I'm recommending you spend the extra $45 for the physical book--but I'm kind of a fetishist when it comes to books, so cum grano salis and all.

Should you buy Maze of the Blue Medusa? Yes. If you like pretty books, this is a hell of a lot of pretty book for fifty bucks, and if you don't, five bucks is less than two cents a room.

So, to summarize: The Cursed Chateau left me lukewarm, but if you want to run a straight-up haunted house scenario, it's quite well-done. England Upturn'd is an insane, and delightful, picture of a 1642 that wasn't quite. Finally, The Maze Of The Blue Medusa is one of the prettiest RPG books you will ever see, and if an incredibly socially-complex madhouse megadungeon appeals to you, or if you collect beautiful books, you need a copy.

Current Mood: thoughtful

Profile

athornton

October 2024

S	M	T	W	T	F	S
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Syndicate

Page Summary

Style Credit

Style: Dark Blue for Funky Circles by ninetydegrees

Expand Cut Tags

No cut tags

Page generated Jun. 1st, 2025 10:49 am

Recent Entries

The Painted Wastelands

Something sweet

The Times, They've Been A-Changing.

Capitalism

Inauthentic Avgolemono

Misaddressed email, part two

Misaddressed email in the age of COVID-19

Show fights in UVG/Troika!

Open letter to Lindsey Graham

GM advice

SIMPLE KOMBUCHA RECIPE

Understanding the works of Gene Wolfe

A brief note on current events

Super-simple kimchi

Ultraviolet Grasslands

Making Old Systems Accessible Via The Web

Exploring old Unixes

The UNIX-HATERS Handbook, a review

Thoughts on race and privilege in America

Three Prisons