more terminal thoughts

I want my terminal to be *robust*. That means not crashing, running out of memory, quadratic blowup, or losing data. The amount of work the terminal does should be proportional to the size of the screen.

Some edge cases to consider:

  • What if somebody pastes War and Peace into the prompt? gnome-terminal crashes.
  • What if a program prints out a line which is a gigabyte long? Will we take forever looking for a newline?
  • What if the user accidentally cats a multi-gigabyte file? Will the history fill up? If we limit the size of the history, will the old history all be evicted?

The answers are not always obvious. And none of the answers that come to mind are going to be easy to implement.

We're going to need a per-command history limit. We're going to need a total history limit. We're going to need to be clever about line handling. We're going to need to be able to persist old history to disk and unload it from memory.

In general, the terminal should behave correctly if at all possible; however, in extreme circumstances it is okay to take shortcuts or make approximations. For example, we want to keep the complete history of most commands, but if the output is excessive, it is okay to keep only the first and last few kilobytes. Scrolling in the presense of long lines should behave correctly as if line breaks were added whenever the line reaches the right side of the screen, but if the line is overly long it is okay to break it at an arbitrary point to avoid using too much memory or time.

In other words, if the terminal is operated within reasonable limits, it should behave with precision. If it is operated outside those limits, it may lose precision but should still *function*.

on writing

It's that time again—time for a blog post!

I'm not sure what to write about, but i know that i want to get better at writing. Good writers are intimidating. There's something powerful about being able to precicely communicate an idea. Fixing a point in idea-space. Good writers lend an air of authority to their writing. You can easily spot an amateur writer by the tone of uncertainty and lack of clarity in their writing.

I read two posts on twitter very recently which set my thoughts on this topic into motion. The first was @eevee lamenting at the difficulty of writing concisely. The second was @veorq saying that djb's papers are always straightforward and to-the-point, in contrast to a recent paper which djb co-authored.

Another thing is the podcast Writing Excuses, which is a podcast about the craft of writing (fiction). I discovered it a few months ago and listened to a good chunk of the back-catalog (although i have to admit that i was listening mostly for entertainment, not making an effort to put any of the advice into practice).

The third inciting event was listening to Blackstar by David Bowie, and some of the speculation about the meaning of the album. Wikipedia says that the lyrics are clearly written by someone who was contemplating his own death. Lyrics (and poetry) are an interesting case of writing, since they must me intentionally slightly obscure, but not too obscure. The best lyric writers have a way of talking around something with a cloud of metaphores and allusions, while still making it clear that there is something real in the center, informing their orbits.

I don't have a conclusion.

what i did this week #3

Let's see... when did i last do one of these? Almost 6 weeks ago? Oops.

I'm currently feeling stuck on my final essay for writing class, and i feel like i've been neglecting this blog so i've decided to write a post as a warm-up.

What have i done in the past 6 weeks? I don't know; i've forgotten. I can tell you what i did yesterday: in the spare hours between classes and marimba practice, i worked on optimizing a coding problem from this week's LUG meeting. I got my solution down from like O(2nn) to O(log n) which is, uh, quite a leap.

I could explain the problem, but i don't feel like it, so instead i'll just point you at the official description and let you figure it out. (I'll also point out that M can be computed directly, without computing F, and that although the computation appears to be O(n), each step is linear and so can be represented with a matrix and optimized the same way as the fibonacci function in SICP).

Other things that happened in the past six weeks: i applied to the open source lab and got turned down again; i read the genderswapped Twilight novel; i resolved a bunch of pull requests for the pokedex; i backed Kill Doctor Lucky; i went to a halloween party; i got sick twice; and i spent most of my remaining waking hours keeping up with schoolwork.

I also figured out that i write the same way i code, but that's a story for another time.

Book review: Armada by Ernest Cline

Zach Lightman lived a pretty normal life until one day an alien ship from straight out of his favorite video game landed in the front of his school.

Armada is a novel which asks the question: what if video games aren't just mindless entertainment, but actually secret training programs? What if all the movies about alien invasions have been setting us up to prepare for the real invasion?

The deconstruction of classic alien invasion tropes drew me in, but the steady armada of pop culture references kept me entertained throughout. Ernest Cline is clearly a huge nerd. I don't think i got even half of the references that Cline litters every page with, but despite that, they help make the characters instantly relatable. This is a cast which has watched all the same movies as you, read all the same books, listens to the same music. It's like watching your best friend go on an adventure.

I worry, though, that the book won't age well. This is not a timeless tale. It is a tale very firmly fixed in the here and now. In 100 years, its story may still be relevant, but they way in which it chooses to tell that story may be unintelligible. Sort of like how Alice In Wonderland is littered with jokes that we simply don't get any more.

That said, for now, Armada is very timely and thought-provoking. I'll probably pick up Cline's other book, Ready Player One in the near future.

What i did this week #2

I'm trying to do these retrospective blog posts every week. We'll see how it goes.

This week I finished my steam_api.dll hack. It works! I can totally play CC2 now! So I have been. A lot. I'm up to level 121.

I meant to make a release of the steam_api.dll code, but i haven't yet. Mostly because there are a few api calls which are in the exe but i've never seen called, so i haven't implemented them yet.

I also started working on a python script to dump the level format. Here's a snapshot of the current code. I managed to figure out a few fields that aren't on the wiki or in Brian's notes, so that's cool.

Playing CC2 inspired me to resurrect some of my work on Tile World. Back in 2009, Tile World had no public source repo. So when i created my iceblock patch, i threw the source code from the 1.3.0 release tarball into a brand new git repository and called it good. Fast forward to 2015, and Brian has converted his private CVS repo into a public git repo hosted on github (and has also released version 1.3.2.) So this week i rebased my iceblock branch on top of the official repo and merged it with the current code. You can see the result in my tworld fork. I also uploaded my libtworld branch, which is an attempt to invert the control flow in tworld and make it more useful as a library.

In other news, the OSU LUG held its linux installfest this week, which was a madhouse. I think we helped like 20-30 people install linux.

Security club held its second meeting of the year. Not much to say about that.

What i did this week #1

Most of the past couple weeks has been spent getting adjusted to life at school, but i've managed to find time to work on some of my own projects as well.

Those projects have mostly been related to Chip's Challenge. The biggest news is that i moved my ancient Chip's Challenge website (pretty much the only part of my website that is worth keeping, other than some of the Pokémon stuff) to tilde.town. As part of that process, I also (with the help of git-weave) created a git repo which combines the history from my public_html repo with some manual backups i had created before I started tracking my web site in git. That's all on github now.

Revisiting that also got me thinking about CC2 and Tile World. Since the graphics for CC2 have been posted publicly on the Steam Community forums, i started making a CC2 tileset for Tile World. I mostly finished that, but ran into the problem that CC2 has many 8-frame animations, but Tile World only supports 4-frame animations. Okay, well, yes, i could just drop a few frames, but i wonder if i can hack Tile World to support more frames...

To make a long story short, no. Tile World runs at 20fps, which only gives you 4 frames per 1/5 seconds. To run at 40fps would probably involve changes all over the codebase, so that plan is getting pushed to the back burner for a while.

This also got me thinking, however, about the Lynx graphics. There's a Lynx tileset on the Yahoo! group, and the readme says something about having to adapt the animations to Tile World's limitations. From playing the Lynx version in an emulator a while ago, i remember that Chip alternates moving his left and right arms when walking. (CC2 doesn't exhibit this behaviour, thankfully.) I decided to see if i could extract the Lynx tiles myself and determine exactly what Lynx did. I couldn't find them in the ROM, but with the help of Handy, i found them in the RAM and quickly wrote a script to dump them (as PPMs, because i was in a hurry). That's about as far as i got with that.

I also revisited my "Silly World" tileset - which is just the Tile World beta tileset, resized for MSCC. The first version used some sort of actual downscaling algorithm (bicubic or whatever), which looked fairly good except it messed up the transparency. That always bugged me. Once i tried redrawing all the tiles myself at the lower resolution, but that didn't go anywhere. This week I realized that i would probably get better results if used the trick of upscaling with scale2x(2x2x) and then downscaling with nearest neighbor. And it did! Except the keys and boots don't look great, so i want to touch them up before releasing it.

The last CC-related thing i did this week was try to crack CC2. As far as i can tell, all the Steam-related stuff is in steam_api.dll, which means that to play the game without a Steam account all i theoretically need to do is write my own steam_api.dll which replaces all the APIs that CC2 uses with stub functions. I have a proof-of-concept working which gets to the start of Lesson 1 and then crashes.

Problems with Gentoo

I don't know why rolling-release distros don't seem to get along with rolling-release software. Or maybe it's that Gentoo has delusions of stability.

Long story short, i tried to install mplayer last night, and the compile failed because of version skew with ffmpeg. Turns out Gentoo still defaults to mplayer 1.1, which was released three years ago, after which the mplayer team sort of dropped the concept of stable releases and just said "build from trunk". Gentoo has ebuilds based on more recent snapshots, but they are marked as unstable and you have to mess around with portage.accept_keywords to install them.

Now, I haven't synced my portage tree in like a year, and the latest snapshot wasn't much newer than 1.1, so i opted to install mplayer-9999, which builds from trunk instead of any particular version, but that didn't work either. Mplayer downloads and builds the latest version of ffmpeg as part of its install, but Gentoo decided to do some hackery to make it build with the system ffmpeg or something, which had fallen out of date.

At this point, i gave up on Gentoo's build system and just cloned the mplayer repo into my home dir and built it myself. It worked flawlessly. One ./configure && make later, i had a fully-working mplayer.

Remind me why we need OSs?

terminal prior art

I've been thinking about how to build a better terminal, so here is a list of prior art for future reference. This list will be updated as i find more examples.

  • gargoyle is a very beautiful interactive fiction interface
  • and in general, glk deals with the same kind of ui problems that terminal applications face
  • 9term is the plan 9 terminal, in which all the text on the screen, including output from commands, could be edited
  • sam is an editor for plan 9 which works very efficiently over the net.
  • acme is an editor, a window system, and a shell all rolled into one.
  • libvterm is a library for vt220 emulation
  • pangoterm is a terminal which uses libvterm
  • the author of libvterm and pangoterm has some thoughts about an abstract ui
  • a whole new world is gary bernhardt's talk about editors and terminals
  • mosh is a replacement for ssh which works by running a terminal emulator on the server and synchronizing the screen state with the client (SSP)
  • terminus is a terminal which supports HTML output, including images
  • eternal terminal maintains a connection that gracefully recovers from disconnections (added 2019-11-26)
  • Mathematica is a REPL for physics which has inline images and lets you edit past inputs (added 2019-11-26)
  • Jupyter notebooks are an open source alternative to Mathematica. there are kernels for various languages. (added 2019-11-26)

today i learned tmux has two titles

Or rather, each pane has both a name and a title. Both can be set with escape sequences. The name can be set with ^[kyour name here^[\. The title can be set with ^[]2;your title here^G.

The latter of these happens to be the same sequence screen uses, which you would think would be good news because tmux sets TERM to screen by default, so theoretically other programs can pick up on that and use it to set tmux titles.

Unfortunately, screen's terminfo entry does not include the tsl or fsl entries.

Actually, that's not true. Screen comes with a correct terminfo file, but the version shipped by ncurses is out of date.

Actually, wait, that isn't true either — the entries we are looking for are present under the screen-s and screen-256colors-s names. Because, you know, we wouldn't want any useful features to work by default.

Ahem.

Although you can set the name and title manually, tmux has a few options to manage them automatically for you. The automatic-rename option sets the window name to the name of the program that the shell is currently running. You can also rename a window manually within tmux with the rename-window command or the C-b , keybinding.

how i fixed my problem with solarized in the terminal

I lamented recently that because i've been running vim in the terminal, i can't use my favorite colourscheme, solarized.

The reason is that solarized requires 24-bit color support to look any good. Solarized was designed with very specific attention to contrast — solarized is much lower contrast than most colourschemes.

There is a fallback mode for 256-color terminals, but all the colors are slightly off, ruining the effect.

(On the left is how solarized is supposed to look. On the right is how the 256-color fallback looks. It may look better or worse depending on your monitor, but for me the result is ugly enough that i prefer vim's default colors in the terminal.)

One way to get around this issue — and one endorsed by the project — is to reassign your terminal's ANSI colors to solarized. The problem with this is that solarized doesn't really fit into the ANSI mold. The ANSI color palette has 8 colors in two shades each. Solarized, in contrast, has a base which consists of 8 shades of blue and yellow, plus 8 accent colors with approximately equal brightness.

xterm colors
solarized colors

As you can imagine, this leads to interesting results when you inflict it on unsuspecting programs. The ANSI colors may not be pretty, but they're what everything expects. So if you go this route, you either have to change every program that uses colors to use solarized-compatible color choices, or live with everything except vim being ugly. What i really want is to just keep my normal terminal colors.

I toyed with the idea of hacking rxvt-unicode and vim to support 24-bit color escapes, but then i realized that there was a simpler solution: i can still change the colors, but instead of changing the ANSI colors, i'll change the xterm colors.

As i said before, solarized has a 256-color fallback mode which uses the closest colors in xterm's extended color cube. And, as i said before, those colors are a little off, but i can fix them. I can override the particular colors that solarized uses to be exactly what solarized thinks they should be. This way, vim looks pretty, my ANSI colors stay the same, and nothing else really cares.

You can assign colors for rxvt-unicode in your .Xresources file, but not for colors past 16, so i ended up putting the following lines in my .zshrc which simply emit control codes which tell rxvt-unicode to assign a new color to one of the color entries.

if [[ $TERM == rxvt-unicode ]]; then
    # Adjust xterm colors to match solarized colors
    print -n '\e]4;234;#002b36\x9c'
    print -n '\e]4;235;#073642\x9c'
    print -n '\e]4;239;#586e75\x9c'
    print -n '\e]4;240;#657b83\x9c'
    print -n '\e]4;244;#839496\x9c'
    print -n '\e]4;245;#93a1a1\x9c'
    print -n '\e]4;187;#eee8d5\x9c'
    print -n '\e]4;230;#fbf6e3\x9c'
    print -n '\e]4;136;#b58900\x9c'
    print -n '\e]4;166;#cb4b16\x9c'
    print -n '\e]4;124;#dc322f\x9c'
    print -n '\e]4;125;#d33682\x9c'
    print -n '\e]4;61;#6c71c4\x9c'
    print -n '\e]4;33;#268bd2\x9c'
    print -n '\e]4;37;#2aa198\x9c'
    print -n '\e]4;64;#859900\x9c'
fi

Here's what the color cube looks like now. You can see where some of the colors don't fit in. If another program happens to use one of the modified colors (and 256-color-using programs are sadly not that common), it will be not quite what it's expecting but it'll probably be close enough that i won't notice.

writing practice

Here i am again. I've sort of made a resolution to write more, although if you use adjectives like "sort of" to describe something i'm not sure it counts as a resolution.

In any case, i'm not sure where i was going with that. The reason i've sort-of-resolved to write more is that i feel like i'm not very good with words. I have trouble explaining things; i have trouble backing up my arguments; i have trouble talking to people in general.

I hate talking about myself. I'm not sure why. If you can get me talking about my latest project, i'll talk your ear off, but if you start asking personal questions i'll clam up.

That's not the point. The point is that the only way to get good at something is to practice it. Ergo, if i want to get better at speaking my mind, i should seek out situations and places which force me to do that. In other words, i should get in to arguments on the internet.

The other thing i can do is just write more, thus this post.

the post with no name

Currently suffering from insomnia, so what better way to pass the time than to write a blog post!

Well. I say insomnia but i'm just having a hard time getting to sleep. I've only been awake for 16 hours so it's not like i'm totally sleep deprived or anything. The problem is just that i spent all day coding so while my body is on the verge of sleep, my mind is still racing.

What is there to report? I guess there's the fact that i ripped X/Y encounters for veekun today, only 19 months after the games came out. They'll be up as soon as i poke eevee to deploy.

I'm also planning on ripping OR/AS data soon.

On the subject of veekun, last week i set up Travis CI integration for pokedex, so the tests are run every time we push. Check it out.

Another thing i worked on last week, although it hasn't been merged yet, was an experiment with splitting pokemon_moves into three tables. You can see the results in the split-pokemoves branch.

The basic goal is to try and reduce a lot of the duplication in the table. Movesets don't usually change too much within a generation, but sometimes they do. A few pokemon will usually gain a TM or a new level up move in each new version, and because of that we have to store another copy of every pokemon's movesets.

Even in the cases where the moveset changes, it's usually just that something was added. All the old moves are still there; deletions are rare.

Some kinds of moves are more turbulent than others. Egg moves hardly ever change, but each version usually introduces a bunch of tutor moves.

The basic idea behind the split is that we can divide the moveset into reusable chunks. In other words, if pikachu has ten egg moves in G/S and Crystal adds another one, instead of storing a 10-move moveset for G/S and a new 11-move moveset for Crystal, we can store two sub-movesets: a 10-move moveset, call it A, and a single-move moveset, B. Then we can say that pikachu learns moveset A in G/S, and movesets A and B in Crystal.

To top it all off, i used a wacky feature of sqlalchemy to make the three moveset tables look exactly like the old, single table.

Most people who use sqlalchemy use the declarative extension, which lets them declare tables as classes, but this is just a convenience: you can also define the class and table separately, and then tell sqlalchemy to how to map the table to the class.

It turns out that sqlalchemy can also map arbitrary queries to classes. So the trick is that we take the old class definition, but instead of mapping it to a table, we map it to the join of the three moveset tables. The way the moveset tables are constructed, this gives you exactly the same data that was in the old table.

College log week nine: akrasia

Why do i avoid some hard things but not others? I'll gladly jump into hours of frustrating debug work, but the thought of working on the speech i'm supposed to give just a few days from now makes me recoil in fear.

Which is why i'm writing this blog post, of course. Anything to distract myself from the elephant in the room.

I typed "how to do things you don't want to do" into duckduckgo, and the first few results say basically the same thing: acknowledge your feelings, try to reframe the task in a positive light, and just get the damn thing done.

When it comes down to it, "get the damn thing done", is both strikingly effective and stunningly unhelpful. If it were that easy, i wouldn't be looking for advice, now would i. But it also seems to be the only way out.

Aaron Swartz's advice is to remember that growth is always accompanied by pain and to lead into the pain. I was going to see what Less Wrong had to say until i remembered that they are very short on practical advice.

Observation: i don't mind feeling stuck when it sneaks up on me. Once i have a problem in my teeth i rarely let it go. And yet, if i can see the problem coming i find something else to do.

Is this some kind of natural defense mechanism? Perhaps i'm attempting to optimize my time by avoiding roads that led to failure in the past. If so, that explains a few things.

Perhaps the difference between writing code and writing speeches is that i am already comfortable with writing code. I know that even if i encounter trouble, there's always a way out — and if not, nobody will judge me. Whereas with the speech, i have very little experience and i'm getting graded on my performance.

College log week four: midnight walk

I just went on an hour-and-a-half walk around campus. I think i was feeling pretty stressed today, for various reasons, although i didn't really realize it till afterwards.

Whatever the reason, i left around 23:20, headed west, and walked until the sidewalk ended. It was a side of campus i hadn't really seen before - both the geography and the darkness - and the weather was really beautiful; cloudy but dry, partially moon-lit and pleasantly cool.

While i was walking, i got thinking about starting a regular thing: Midnight walks; Different route every week. I could advertise on the Facebook group, and try to get my friends into it. Maybe i would meet other night people who enjoy the contemplative silence of the night.

Of course, getting introverts to join a group is a bit of a challenge.

On the way back, i tried to go to the MU but it was locked - there's something alluring about empty buildings - so i went to Kelley instead. I headed up to the top of the staircase in the center of the atrium and listened to the ambience. Climbing the stairs was more exhausting than the walk.

I sat for maybe fifteen minutes, thinking. I thought about playing the piano. I thought about why i might have gone on such an impusive journey. I decided that maybe it was because i needed to relieve some stress.

I have midterms coming up. I have to make decisions about housing in the Fall. I'm in the middle of applying for a job. I have homework which i haven't done yet.

To top it off, i dropped and broke my plate today. One of the wheat-pattern plates that were from Grandma. My favorite plates in the world. The most unique plates we own.

I almost wanted to cry when it broke, but i didn't. Instead i went to the front desk, got a broom and dustpan, and swept up the pieces. Then i went to the lobby and studied for two hours.

The broken pieces are sitting in my closet, where the whole plate used to be. Sitting with the hope that we can somehow glue them together. Kintsugi.

I'm not the sort of person who looks for meaning in everything. I don't think that the broken plate somehow represents my life falling apart. The only moral i see is that i should be more careful when i wash the dishes.

It did hurt though.

Not knowing

The worst/hardest part of any project is the not-knowing.
Not knowing what to type, what to write, what to say, what to do.
Once you know what to do it's just a matter of doing it.
But not knowing what to do leaves you in a limbo of nothingness.
No direction. No purpose. No way forward.
The pain of not knowing is so great that it is easier to ignore it.
To turn your head. Look somewhere else. Find something distracting.
But you cannot. You must lean into the pain if you are to make progress.

College Log: week three

Today i learned how important practicing a speech is.

To give some background, i'm taking a public speaking class this term, and i'm giving my first real speech tomorrow.

I got an outline knocked out on Sunday, but today i finally tried running through the whole thing out loud.

My first attempt took 20 minutes! That's bad. We only get 2-3 minutes; 4 max.

I've had to cut a lot of stuff and streamline some other stuff.

Part of the problem is that i'm still figuring out what to say, and how to say it, and what comes after what. I haven't figured out yet which digressions to take and which to wisely defer to another time.

I worked on my outline this afternoon, but practicing is giving me very important feedback on what to leave in and what to leave out.

In the future, i think i'll start by jumping right in and doing the speech, maybe even before the outline. But definitely not the night before the speech.

College Log: week two

So I'm supposed to give my first speech for Comm 111 on Friday. Well, not exactly first. We already gave an impromptu introduction and a reading of another speech. But my first real speech, where I have to write an outline and everything.

The topic is a self-introduction, and to make matters harder we have to bring an object in to use as a jumping-off point for the introduction of the speech.

I don't like to talk about myself. I don't know if it's just part of my personality, because i'm so introverted, or if it stems being told not to put personal details on the internet as a child, or what. I imagine that the person who designed the curriculum thought that this would be an easy speech because everyone likes to talk about themself! But i would much rather start with a speech where i talk about something completely unrelated to myself and i don't have to give up any personal information.

So you can imagine that i was having a hard time getting started on the speech. Luckily, however, one of the Academic Learning Assistants knocked on the door of our dorm room today to ask how we were doing, and if we needed any help. I mentioned that yeah, i could probably use a little help with my speech and she said that i could go talk to the Writing Tutor who hangs out on the fourth floor at certain hours tonight.

So i did.

And it was really helpful! All i really needed was someone to talk to, to bounce ideas off of. I was able to come up with several things that i could talk about, but that i wasn't really sure about, and she helped me pick out the good ones and flesh them out and sort of organize them into the topic-subtopic structure of a speech.

There's still work to be done, of course, but talking about it was a massive help. And now i have an outline that i can work on and refine.

Kill Doctor Lucky

I want to get my thoughts down about Kill Doctor Lucky. This seems relevant because the designer of the game, James Ernest, is in the process of revising it for a 20th anniversary edition this fall.

As i mentioned, i played a game of classic Kill Doctor Lucky last night (we didn't even use the spite rules from the latest edition because i forgot about them) and i have to agree that the hallways are a big problem. As James says,

Here’s the statement of concern: Hallways have always been a problem in Lucky Mansion, because they are basically traps. You don’t want to go in without a good plan for getting out, because Doctor Lucky activates players by moving into rooms with them, and he never moves into the hallways. Thus, people don’t move much, and feel trapped in corners of the board.

That's exactly what happened - the players that stepped into hallways got trapped there, while the smarter players planted themselves in a room and just drew cards. (I should probably mention that, aside from me, all the players were new to the game.)

Ernest's proposed solution is to make hallways a "free move" — if you enter a hallway you can make another move. I haven't tried it yet, but i can already see how it would totally change the feel of the game. I plan to incorporate that rule next time, and i'm sure it will work great.

I'm also excited to try the new rule about drawing cards—to wit, that you can't draw a card if anyone, including the good doctor, can see you. Not only should it neuter the "doctor lucky train", i think it will also encourage players to spread out more. During the first half of yesterday's game, the other players all hung out in the lower left corner of the mansion, totally thwarting any potential murder attempts because they could all see each other; meanwhile, i scurried all over the rest of the mansion and made several attempts to kill Doctor Lucky.

I think there were a few different factors keeping them together. First, people squatted in rooms that they had a good weapon card for. Second, the hallways boxed people in. And third, there's no incentive to explore and every incentive to stay put and rack up cards. Typically the player with the largest hand wins.

Changing the draw rule would remove the incentive to stay put where another player can see you, because you'd be wasting turns doing nothing at all instead of building up an arsenal. The new hallway rule will also, by taking away the penalty for entering a hallway, encourage players to explore more.

There are a bunch of other changes that Ernest says he wants to make — and, i'm sure, many others that he hasn't posted about — but i think those are the big ones.

He talked about getting rid of the rule that says you can't draw in hallways, but with the invention of the free move rule, i don't think that's necessary.

He is tweaking the board design: changing lines of sight, adding and removing doors, etc. One important tweak is that all the named rooms are numbered now. On the original board, Doctor Lucky skipped some of the rooms. On the prototype boards that Ernest has posted, it looks like the doctor will be visiting all the rooms. I'm guessing one of the original reasons for the unnumbered rooms was to break up long chains of rooms—interrupt the "lucky train"—but with the train now taken care of by the draw rules, i guess it isn't as vital for the board to intercede on the Doctor's behalf.

One final change i want to mention is one that Ernest hasn't talked about at all: the deck. If you look some of the photos he took of playtest games, you'll notice that not only are the cards bigger, there is a new type of card: murderers, presumably inspired by or taken from Get Lucky (the Kill Doctor Lucky card game that kickstarted a couple years ago). If you have very keen eyes, you'll also notice that the weapon and room cards now have room numbers on them—a most welcome change.

Anyway, that's all i have to say for now. Can't wait to try the new rules, and for the kickstarter to be announced.

College log

So it was my third day on campus, and my first full day. People are starting to show up at the dorms after spring break. I met my roommate properly today, as well as all my suitemates (except C's roommate).

What else did i do today? It was a day of firsts. I had my first breakfast in the dorm kitchen. I bought my textbooks (well, most of them). I'm renting a textbook for the first time. It is a stupidly expensive math textbook - $225 new. I could get it for $155 used, and sell it back for probably $112, costing me about $40 in the end. Instead i'm renting it for the term for $56, which i think of as basically ensuring that i can "sell it back", and also impacting my bank account sligtly less in the meantime (even though i'll ultimately be spending $13 more). Of course, i have to be sure that i don't actually want to keep it or else they'll charge me for the whole book (in addition to the $56).

But I'm getting ahead of myself. I rode my bike today! For the first time in years! It felt really good, although my thighs were burning a little. It'll be better when i get in shape. Bike riding is definitely the way to get around campus. It's not too hilly, and everything is close but not too close.

After buying textbooks i headed over to the library to cut up the Kill Doctor Lucky cards i printed. It was pretty tedious, and the paper cutter wasn't ideal for the task. It was a rotary cutter, and it had this protective shield near the blade path which blocked a couple inches of the cutting surface and made it really difficult to place the paper for some of the smaller cuts. It also didn't have a backstop (also known as a paper guide) so i had to improvise with a book. That worked for the large cuts, but for cutting the individual cards, the book couldn't get close enough to the blade because it was blocked by the protective shield, so i had to use a couple sheets of paper (weighed down by the book) as the backstop edge, which was as finicky as it sounds.

I did it though, after which i ran into my roommate and some of his friends and we adjourned to the dining hall for dinner. After which we proceded back to the dorm for a game of Kill Doctor Lucky (note to self: print the rules next time).

And to wrap everything up, i headed to the library to see if i could rip CDs on their computers. Verdict: yes! That'll be nice, since my laptop's CD drive doesn't work.

fluxx and death

I'm glad that Andy Looney has started to back off on Creepers, but I'm also a little sad.

Creepers debuted Zombie Fluxx, where they were entirely appropriate, but since then they started to appear in every Fluxx game. Unlike Creepers in later games, the zombies in Zombie Fluxx didn't do anything on their own; instead, about half of the goals posited their absense. In every subsequent Fluxx game, however, the Creepers have carried a clause which prevents you from winning.

One of the things that i like about Fluxx, and still draws me to the original version, is that the Keepers are icons of sorts. They are concepts like Love and War, but also the Moon and Cookies. The major arcana of a new age. It appeals to me that something like Death and Cookies are on the same footing; equals.

Andy has defended his choice to make Death and company Creepers, but I disagree. He says that they aren't good Keeper material, but I argue that neither are they good Creeper material. Death at least has a sligtly interesting power - it makes you discard cards - but War and Taxes are not more interesting as Creepers. Aside from minor interactions with Peace and Money, respectively, they are just your bog-standard win-preventing deadweights.

The problem with Creepers is that they aren't any fun. In general, cards that prevent you from winning are no fun. Zombies were interesting because half the time they were actually useful. A card that simply prevents you from winning just drags down the game. You can't get anywhere until you draw a card which lets you get rid of it.

Death's power is interesting on its own. Making you discard a card every turn is incredibly powerful and irritating. You don't need to throw the Creeper rules (must play, can't win) on top of it.

As i said, I'm glad that Andy is starting to use Creepers with more discretion, and recognizes that not every Fluxx game needs them. I'm glad that Fluxx 5.0 has no Creepers, but i wish it still had Death.

[Footnote: I didn't mention the Radioactive Potato. I think that it is a fun card, but it worked better as a promo. It doesn't need to be in the core game.]

more packaging thoughts

Build system requirements for packagers and developers are different.

Developers build the software over and over again, so incremental compilation is a valuable time-saver. Packagers build software from scratch each time, so incremental compilation - and all the dependency management mechanism that comes with it - is unnecessary.

This fact was first pointed out to me by the redo project, which provides a small shell script that implements the entire build system, but without any dependency management (it always rebuilds everything).

Developers typically build and test on a single system. They aren't overly concerned about portability. Packagers also build on a single system, but it is likely a different system than the developers use. Also, distributions have varying standards about where files end up - /usr/bin versus /usr/local/bin for example. They also like to split programs up into shared libraries as much as possible, and dislike programs that don't link with the system libraries.

thoughts on package management

Modern package managers split the build process into several steps:

  • Download sources and extract into a temporary directory
  • Prepare sources (configure, apply patches, etc)
  • Build
  • Install into another temporary directory

The contents of the temporary directory are then zipped up along with a file manifest and maybe some install scripts. This is the package.

The install process is similar:

  • Download packages
  • Verify package signatures
  • Unpack into root filesystem

Actually i guess they aren't that similar, except superficially.

Anyway.

Developers like to rag on autotools for being a steaming pile of kludges, but the chorus from the distributors' side seems to be that autotools makes their life way easier.

There must be some way to satisfy both camps.

Y'know, one of the problems with configure is also one of its strengths: the fact that it tests for features dynamically—that it probes the system directly—means that it is usually right, but also that you can't configure a program for any system other than the one you're running. Given that one of autotools's touted benefits is easy cross-compiling, this seems a little contradictory.

I note with interest that the Debian upstream guidelines discourage using Scons or waf, two build systems which i frequently see developers praising.

aaron swartz

Today is the two year anniversary of Aaron Swartz's death. I'm not sure what to say. His death was (and remains) a tragedy, but of course that's what everybody else is saying so why repeat it.

Aaron was someone on my list of people to keep an eye on. Smart people doing good things. My biggest regret is that i never learned much about him until after his death.

röyksopp - the inevitable end

The first track, Skulls, is killer—a toe-tapping number that makes me want to get up and dance. The rest of the album... less so. Most of the remaining tracks are more relaxed and drawn-out. Which isn't necessarily bad, it just gave me a bit of mood whiplash.

I'm a little sad that the remix of Monument dropped the saxophone section, but life goes on.

eh, skip the first post

I have to write this down while it is still relatively fresh in my mind.

We were watching Sonic Highways—the episode about LA—and they were talking the band Kyuss, and the unique sound they created in the desert. This was interesting to me because my brother used to listen to Kyuss. For all i know, he still does.

Anyway, long story short i got their breakout album, Blues for the Red Sun, from the library and gave it a spin.

First impression: it is quiet! Or at least, the vocals are way down in the mix. I ended up playing it around 20 dB louder than normal because that's where i could actually start to hear the vocals, and it's where the music popped.

Of course, at that volume, the music is pretty loud. But Kyuss seems to play almost exclusively in the bass register. The songs have this incredibly muddy, distorted guitar sound. Dave Grohl says they had their instruments tuned lower than anybody else at the time. I think the vocals can be so low in the mix because they really aren't competing with anything.

Overall, i'm not sure if it's my favourite music, but the sound is really fantastic and exciting and unique. My hat is off to the producer for capturing that sound.