~bradley

Bash Prompt Customization and the Value of Personalization

Sun, 23 Feb 2020 00:00:00 -0500

It really wasn’t all that long ago that I’d never touched a command line before. Circa 2013, I think I was still using Windows, and the closest I’d come to a prompt was the occasional simple .bat script and the Python IDLE. It was good enough for what I was doing, I guess, and I don’t think I could have bumbled my way into a more optimal path to my current knowledge.

When I first got into Linux, the terminal was understandably foreign. Having spent a childhood and adolescence in a GUI, it was difficult to see the value of having to type things in one at a time and—if things went perfectly—get basically no feedback. (It didn’t occur to me until writing this that the most normal output in the world from a Unix utility is nothing at all.) It became obvious even to me then that there was a lot to learn about this other world.

I’m still learning. I hope to continue as long as I can, in fact, and that’s part of why I’m writing this. In the few years since I first loaded up Ubuntu and launched the terminal, I’ve been staring at basically the same prompt. It looks a lot like this:

bradley@enterprise:~/code/blog$

or if things are getting serious, like this:

root@enterprise:/home/bradley/code/blog#.

This basic format has seen me through hours of debugging, configuring, laughing, crying, and ragequitting. But the problem with something so familiar is that it’s hard to remember that it can be configured, just like anything else. There was a time not long ago when I would have been afraid to irreparably damage my system by trying to make changes so fundamental to my meager operation. I still have the capacity to cause irreparable damage—it’s one of my core competencies—but I have less fear today.

The reason I got thinking about doing this is that I was watching a friend of mine use the terminal on his machine (running Fedora, I think), and the prompt he was running was amazing. I mean, this thing was like a prompt from the future. It had a cool color scheme, it showed the current time, and it was generally compact and neat. “That would be so cool to have,” I thought. “Wait, I could totally have that!”

I won’t actually go over how to do the configuration here—this is easily Google-able, which I know from related personal experience—but I will show you what I did and yammer on a bit more about the value of configuring things for comfort. Okay? Okay.

Here’s my config:

[\d \t] \u@\h \W \$

This results in something like:

[Sun Feb 23 10:12:24] bradley@enterprise blog $

Benefits of this configuration over the default:

shows the date and time that the prompt appeared
only shows the current directory, not the path, thus limiting the length of the prompt (I’ve had some prompts that extend over several lines due to the length of $(pwd), and it’s just madness. This is cleaner.)
There is no third benefit.

I like this tweaked version better than the default for the reasons stated, but it’s also just nice to have personalized yet another thing about my machine. Only recently have I realized that personalizing my space (digital or physical) is actually not a waste of time, as I once thought. I take pride in minimalism and simplicity, but the more nuanced version of that opinion is that you can have those things while making things your own. I guess it’s a human thing to want the stuff around you to be yours, to be controlled. This same impulse drives me to customize my Bash prompt as much as it drives me to look for art to put on my walls or to consider whether or not my desk would be better over there rather than here. It’s mindless and silly, but it makes me feel good and hurts nobody. Really, what else is there?

Rodents, Snakes, and Adhesive

Thu, 09 Jan 2020 00:00:00 -0500

Last week, I proposed a challenge to the relvokcor.xyz mailing list. The challenge was to dust off the public_gopher directory sitting in most users’ home folders and put something neat in it. Gopher was (and is) quite new to me, but not to the world; a team at the University of Minnesota created the protocol in 1991, and it’s been lurking out there on the net ever since.

I guess the story goes that Gopher was initially quite popular, particularly since its terminal-friendly interface dropped cleanly into the prevalent hardware and operating systems of the day. Unfortunately, UMN started charging for use of its server implementation in 1993, and that was more or less all it took for the free Web to take over. The owners of the implementation re-licensed under GNU GPL in 2000, but by then it was too late. Gopher probably would have been crushed by the stampede of interest in the graphical Web anyway, and in a way it’s nice that its owners tripped over their own financial feet and made way for multimedia on the Internet, but it’s also a little sad, I think, that Gopher has been reduced to just a curiosity.

At the moment, there aren’t many Gopher servers left. relvokcor.xyz has one, of course, and there are a few notable others, such as gopherpedia, but beyond that the protocol is mostly dead. The most important development in Gopher’s history in the past fifteen years was probably its appearance as the butt of a joke in an xkcd comic from 2009.

But still, we press on. Why not have a little fun at the end of the world, hmm? If others aren’t using Gopher, that’s okay. Most people don’t even know about HTTP—which is probably for the best, now that I think of it—but that doesn’t stop nerds from nerding about it. Gopher is a neat way to organize information, and I for one find its terminal-first approach pleasing (in other words, it makes me feel l33t), and that’s really all I need from it. Plus, cool name.

So after all that, what does one put in a gopherspace? Well, in my case, I followed the principle of least effort. Rather than make up some new stuff to put there, I decided to just duplicate my existing blog (which is all Markdown files on the backend anyway) and format it as a gopher blog (or phlog, apparently). You can check it out on the relvokcor.xyz Gopher server here. If you don’t notice anything new or interesting, then great! That means it worked.

Just for fun, I thought I’d share the Python script (or “glue”, as I call it) I ~~wrote~~ hacked together to take my existing Jekyll blog and spit out a gophermap (the file that tells Gopher where stuff is) along with the actual text files. It doesn’t handle Liquid templating, images, or anything like that, but it sure does do the minimum viable thing of writing text files. Take a look:

#!/usr/bin/env python3

import os
import regex as re

gopher_path = '/home/bradley/code/blog/_gopher/blog/'

post_path = '/home/bradley/code/blog/_posts/'
gophermap = []
for entry in os.scandir(post_path):
    entry_text = open(entry.path, 'r').read()
    entry_title = re.search('(?<=---\n.*\ntitle: ").*(?=")',
            entry_text).group(0)
    entry_date = re.search('(?<=---\n.*\n.*\ndate: ).*', entry_text).group(0)
    entry_content_start = re.search('---\n\n', entry_text).start() + 5
    entry_content = entry_text[entry_content_start:]
    open(gopher_path + entry.name, 'w').write(entry_title + '\n\n' + entry_date
            + '\n\n' + entry_content)
    gophermap.append('0{0} --- {1}\t/~bradley/blog/{2}\trelvokcor.xyz\t70'
            .format(entry_date, entry_title, entry.name))

gophermap_output = open(gopher_path + 'gophermap', 'w')
gophermap_output.write('''blog - noun; a regularly updated website or web page,
typically one run by an individual or small group, that is
written in an informal or conversational style

gopher - noun; a burrowing rodent with fur-lined pouches on
the outside of the cheeks, found in North and Central
America

gopher + blog = phlog

''')

gophermap = sorted(gophermap, reverse=True)
gophermap_output.write('\n'.join(gophermap))
gophermap_output.write('\n\n..')

Note that in order for the above to work, you at least need the regex module from PyPI, since it implements variable-width lookbehinds. In my deployment script, I source a virtual environment where that module is installed, but you can do it however you want. Email or IRC me if you run into issues, but no guarantees. I release this code into the public domain and relinquish any rights to it whatsoever.

One last thing: the challenge I proposed for this week was to set up or update your blog, so this post is what we in the business call a two-birds-one-stone scenario.

How to Lose Access to Your Data Without Really Trying

Mon, 30 Dec 2019 00:00:00 -0500

Someone told me once that some kinds of dogs that are bred for herding will herd clouds of dust if you keep them inside for too long. The herding instinct is so deep inside their minds that they can’t help but act on it, even if it’s not really productive. I think sometimes that people can be like this, too. Some people, it seems to me, will make art, exercise, build things, or do whatever feeds their soul no matter what situation they’re in. To them, their universe is filled with sheep, and they were born to herd.

This is how I feel about computing systems. Now, I don’t claim to be great at it, and I don’t think I have the drive that many people do—let alone dogs bred for herding—but it sure seems like everything I do eventually leads back to making computers do stuff that pleases me.

Earlier this month, I went back to where I grew up for about a week and half. Since I moved away about seven months ago, I’ve kept in touch with my family there, but I’ve also learned a lot about the world simply by living somewhere slightly different. Returning was a whole process of emotion for me that I won’t go into here, but while I was away I thought I’d try to make sure my home laptop was accessible remotely. You see, my laptop is quite large, and I had already decided to leave it safely on my desk rather than lug it through airport security, as well as all the places I’d visit while I was away. I brought a much smaller machine instead with the expectation that I’d be able to reach back to my home network whenever I wanted.

The way I planned to do this was simple enough. Some months (or years, maybe?) ago, I set up a VPN on my personal Linode server and added my machines to it. After a fair amount of fighting with the config files—this was, after all, the first time I’d done this—I had a reasonably workable system that let me access my machines from practically any place I had a connection. In fact, I’m using it even as I type this via a Google Cloud Shell.

Being a decent engineer—so I thought—I knew that this system had a single point of failure: the VPN connection. In the past, I’d already had issues where the OpenVPN daemon on my machines would just kind of stop working, and I’d have to restart the service. I knew this wouldn’t be possible remotely, so I came up with a “cunning plan”. I’d forward a random high port on my home router to port 22 on my machine, thus allowing me to access the machine in an emergency. I tested it out, and everything worked fine. Great, I thought, now I’ll be safe no matter what. I enabled remote access on my router and set a strong password.

So, off I went. I flew back to my hometown, and after getting settled, one of the first things I tried was to connect to my laptop. Just as planned, I got a shell. I was pleased, perhaps too much, with my design.

It wasn’t long before that pleasure evaporated. Later, maybe the next day, I tried to log in again. Nothing happened. Uh oh. I pulled the ripcord and tried my remote access trick. To my surprise, my machine was listed as disconnected. I messaged my girlfriend to ask her to check the machine for power. She confirmed that it was on. I realized in that moment that something unexpected had happened: my machine had lost its connection to the router.

This, of course, ruined the whole system. Without a connection to the router, the machine was totally inaccessible. Why it had disconnected, I still don’t know. I’d already had problems with the WiFi daemon on BunsenLabs, the OS I was and am running, so maybe it has something to do with that. In any case, it seemed likely to me that the machine had somehow lost its connection to my network and latched onto one of the many open xfinitywifi networks in the area.

I asked my girlfriend to power cycle the router. My hope was that either (a) the xfinitywifi that my machine chose was the one offered up by our router, and that power cycling it would knock it off that network and force it back onto the proper one, or (b) that I was wrong—which I’d now realized again was possible—and something else entirely was going on, and that power cycling would reset things enough to get back to a recoverable state.

My girlfriend dutifully reset the router once, twice, and nothing changed. It was becoming clear that I’d be ten days without my main machine (and she’d be ten days without our Minecraft server, which runs on it). I thought about having her log in, or even power cycle the machine itself, but I didn’t want to have to try to relay my passwords over the phone. She assured me that it wasn’t a big deal, but I still felt pretty dumb.

I learned then that single points of failure can bite you hard, and that it’s important to look for them everywhere. I still haven’t figured out how to tell nmcli to only connect to one network, but that would probably help. I also considered running a cable from the router down to my machine, but that would be pretty involved. In truth, I haven’t got a good solution to this problem, other than that I might switch to stock Debian soon on that machine and see if it plays better with my WiFi hardware.

When I came back, I also learned that I was at least correct about how the system failed. I logged into the idle machine, checked the WiFi daemon, and sure enough it was connected to some random xfinitywifi, doing nothing valuable. I cursed the machine then, but I only had myself to blame.

Lesson learned: never trust a computer if you can avoid it, especially when you program it yourself.

Weekly Webpage Workshops

Tue, 24 Dec 2019 00:00:00 -0500

(This post is about the Weekly Webpage Workshop, a mailing list message I send out every Tuesday or so that challenges you do something different with your ~club pages. If you want to participate, monitor the mailing list here or in your favorite email client.)

This week’s WWW tasks the reader with recreating MySpace’s Top 8. Have a look a the full message on the mailing list here.

At the moment, my Top 8 are the following, in no particular order:

Github Trending, where I find cool projects
Huginn, which I found on Github Trending
Ledger, some neat plaintext accounting software for the terminal
Advent of Code, where I’m currently failing to save Santa Claus
Smash, which I’d never played until yesterday on our Switch, and which I’m not great at but am improving
Python, my first programming lanuage and the source of a lot of joy (and frustration) in my life over the past ten years or so
Mechanical keyboards, which I suddenly am into after a friend gave me the one I’m typing on right now
The Adventure Zone: Graduation, just the latest installment in a wonderful DnD podcast made by three brothers and their dad

Github Trending is Cool

Sat, 14 Dec 2019 00:00:00 -0500

As a pseudo-Christmas present, a dear friend of mine gave me my first mechanical keyboard. Naturally, I’m now looking for all sorts of things to type, just so I can hear the clicky-clacky sounds that I find so satisfying. If you’re wondering, the box says “60% Anne” and that the switches are brown. I don’t really understand what that means—other than that it indicates the size and switch clickiness—but I’m enjoying it all the same.

One benefit of being prompted to type more things may be that I post more stuff here than usual. One minor problem is that this may also result in stuff that’s poorly-planned and short. To this I say meh, as well as clickity-clack-clack.

Just yesterday, for some reason I decided to browse Github Trending, which I have pretty much never done. My goodness, what a wonderful collection of code. All sorts of interesting projects seem to show up there, and the majority of them have permissive licenses, in addition to being open source. I thought I had a good idea of the number of meaningful open source projects, but I can see now that there is much more out there than I had imagined. I certainly don’t mind being wrong. If you care about code, give Trending a look.

Here are a few repositories I starred while browsing Trending. Perhaps you’ll find them interesting, as I do.

Huginn is more or less self-hosted IFTTT. A simple idea, to be sure, but beautifully-executed, to my eye. There already appear to be lots of “agents” available that talk to various other services. I suppose you have to set up API keys with some of these external services yourself, but once you get it all working, I suspect that Huginn more than returns the time investment. Plus, what a cool way to frame the problem and solution; Huginn is the name of one of the two ravens that sit on Odin’s shoulders and report whatever they see back to him. I will definitely be setting this up on my server soon, and it may even push me to learn some Ruby so I can write my own agents.
Public Pentesting Reports is a repository containing just that. I’ve only browsed this a little, but I can already see that this is a good collection of security-related information. These seem to be copies of reports that are generated by actual penetration testing firms, and since they’re meant to teach the companies that hired them how to fix their systems, they naturally inform any reader to the techniques and tricks used by the penetration testers. I plan to cozy up with a few of these at some point, perhaps even hard copies, and read through them over some tea.
Rustlings is a companion repository for The Rust Book, a sort of online textbook introduction to Rust. Some time ago, I spent a few hours going through the first chapters of The Rust Book, but I got a little bored by the technical detail. Had I known that this repository existed—or perhaps though to search for it—I may have continued and become a power Rustacean. (That’s what they’re called, right?) Anyway, in my surely limitless spare time I hope to eventually learn some useful Rust, and these exercises may help me to do just that.

So yeah, Github Trending. If you need to kill two (or two hundred) hours and like code, look no further.

We Put Up the Tree and Nobody Can Stop Us

Sat, 09 Nov 2019 00:00:00 -0500

Growing up, my family had well-defined rules and regulations surrounding the periods during which certain holidays could be celebrated and in what ways. It wasn’t as bad as it sounds—in fact, it marked the year in a pleasing way—but my situation is different now, and it feels appropriate to make changes to these traditions to suit my preferences and the preferences of those in my immediate family.

The most obvious and deliberate of these changes is when to put up the Christmas tree. In my family, it was held with high importance that no Christmas holiday-ing shall be enjoyed until after Thanksgiving has concluded. This means no carols, no tree, not even a tiny prickle of garland until the time had come. Officially, the Christmas season didn’t begin until Santa Claus appears in the Thanksgiving Day Parade in New York City, but practically this meant that the day after Thanksgiving was Day One.

I appreciated the separation between Thanksgiving and Christmas, since it’s seemed to me for some time that Thanksgiving gets sort of skipped over. Thanksgiving is perhaps the purest holiday left, in my estimation, and it’s important—to me, anyway—that it be observed well.

Still, a different argument has been put to me recently. While Thanksgiving is important and shouldn’t be ignored, Christmas can still be ongoing in the background while Thanksgiving occurs. In other words, the two aren’t mutually exclusive or incompatible. Therefore, it ought to be perfectly acceptable to put up the tree and enjoy it beforehand. This argument moved me, and so we’ve gone ahead and moved our canonical tree-putting-up period to right around Veterans Day. (Any earlier would be risking putting it up around Halloween, which would simply be obscene.)

So that’s that. Tradition: changed. It’s all arbitrary anyway, but it does make me feel a little more connected to the long line of people who’ve come before me and done this strange thing of bringing a tree (or in my case, a plastic facsimile) into the home when it gets cold. Perhaps the humanity of traditions is in the tweaking.

Plus, our cat quite likes to sit under it, and I have nothing against that.

Uh Oh, Factorio

Tue, 15 Oct 2019 00:00:00 -0400

So yeah, Factorio stole my Columbus Day weekend.

I place all blame on ~audiodude, who knowingly, willfully, and intentionally set up and promoted a relvokcor.xyz-specific server last week. Fortunately, it’s only up on the weekends. (Unfortunately, Factorio does have a single player mode…)

Shortly after launch, ~audiodude, ~benharri, and I had set up a basic factory and were having a grand old time optimizing and expanding it. I took down some quotes for your enjoyment.

Regarding time investment:

It’s just time.

Start over!

No, that’s too easy.

Soonish, like in the next couple hours.

Alright, we’re gonna have to move everything over one column.

Regarding design and engineering:

If you’re not writing bugs, you’re not writing code.

I think it’s very close to being cool.

New and improved belt machine! Now with belts!

I’m just gonna double this up, then.

I learned that one from a YouTube video.

Miscellany:

You’re an arborcidal maniac.

Basically, steel ore is iron plates.

Smelt, smelt, smelt, smelt!

I just built a car!

I am gonna split a brick.

Also, I elected to record two or so hours of solo play on the server and compress it into a timelapse. I took one frame every ten seconds, and the result is played at four frames per second. You can find that here. (Caution: ~200 MB)

Joking aside, Factorio is tons of fun, and even moreso with like-minded companions. We welcome any tildezens who may wish to play with us. Also, check out the wiki.

Determinism

Fri, 11 Oct 2019 00:00:00 -0400

I have a degree in physics. To get that degree, I had to jump through a lot of hoops, many of them made from dry-erase markers, exams, and the tears of overworked graduate students. In the process of learning how to jump through those hoops, several principles were beaten into me and my classmates.

Among these was the principle that everything that happens in the universe is the result of consistent, explainable rules that we like to call Laws. This is perhaps the core tenet of physics: the Laws are the same no matter where or when you go in the universe. We don’t know what all the Laws are yet, but in attempting to figure them out we proceed with the expectation that the complete set will have some character, some nature that’s consistent. If it turns out that the Laws change based on your position in spacetime, well, that would probably ruin some people’s whole day. Others would be ecstatic.

Anyway, the implication of this tenet is that nothing can exist outside the realm of the Laws. Everything, we assume, must obey them. Otherwise, either our Laws would be incomplete, or we would be forced to conclude that some things are extraphysical (read: magic). That’s just no fun, so we assume that it’s not true. So far, there hasn’t been any good evidence to disprove that assumption, so after a few centuries of building we’ve become pretty confident in it.

Many systems in the universe are complex. That is, they’re so large and have so many pieces that we—collectively or individually—can’t take them up in our minds very well. They don’t fit, because our minds are more or less the products of evolution, and our ancestors didn’t have a lot of quarks to interact with in the savanna (at least, as far as they knew). For this reason, we often need to abstract systems into smaller pieces so we can fit them into our thinking mouths and chew on them. The problem with these abstractions is that they necessarily discard some of the information in their creation, sort of like how you have to discard some wood shavings in order to whittle a duck, or whatever. Discarding information is critical to their function, after all, but it’s still an unfortunate consequence. If we keep doing this and abstract away too much, then what we’re left with is an over-simplified model of the real thing.

Abstractions make it easy to forget our fundamental assumption (at least, in physics) that the universe operates according to physical Laws. That’s important, because assumptions like that have critical implications for questions that seem like they couldn’t be further from physics, such as the question of free will.

Can you do what you want? You may think so, but you’re wrong. You—your body, anyway, which is what you are—exists in the universe. You’re made of matter, and as far as anybody can tell empirically, your body obeys the same physical Laws as anything else in the universe. Inside your body is a little chemical computer that does some fantastic work in real time to take inputs from the rest of your body and send outputs back to it. That’s how you’re reading these words, and it’s how I’m able to send them to you, more or less.

Suppose you turn off the device you’re reading this on, perhaps because you think I’m a pretentious prick for trying to leverage a moderate level of science education into a definitive answer to the free will question. Did you decide to do that? Well, let’s work backward. Lastly, your body moved in such a way that the device turned off. That required that some muscles move around, converting stored chemical energy into motion and some waste heat. Before that, your brain sent signals to your muscles to expend that energy precisely in that way. Before that, your brain took in inputs from your surroundings via various sensors. Before that, you were reading the last paragraph.

Nowhere in that process is anything like a decision or a thought. We have names for those things because it feels to us like they’re happening—like our minds are places we can go to—but the reality is quite different. Really, we are wonderful machines that operate according to Laws, no different than stars or starfish. We don’t have free will, because nothing does. We just do whatever the matter in our bodies does.

Consider this: almost nobody would argue that an atom can think. Cells don’t make the cut either, and neither do muscles, bones, or any other organs besides the brain. And yet, the brain is made up of the same matter as everything else. The emergent properties of the complex system that is the human brain aren’t unexplainable magic. They’re the impressive output of a machine whittled over eons to do what it does.

You may think this is a frightening conclusion. Perhaps you think that being predictable, even in principle, lessens your existence. I don’t think so. By fantastic chance, we all have the sensation of making decisions and thinking, even though we’re not. That’s a wonderful thing, and we should be happy to have received such a beautiful gift. Still, remember that we are physical beings, and unless we allow extraphysical magic, there can be nothing more to our existence than the natural course of the complex play that is the universe and its Laws.

Numbers-Only Hash

Wed, 09 Oct 2019 00:00:00 -0400

Maybe two years ago, I encountered something that made me think. (I mean, that wasn’t the only time, I’m just… look, never mind.) I was committing something to some git repository, and the truncated commit hash (e.g. f151b8e) was all numbers. Not one of the possible letters a through f appeared in it. Of course, the full hash (e.g. f151b8e71a17fd7c7e074bc4c1500f2dc05da742) had plenty of letters, but by chance those first 7 nibbles were all less than a.

Hmm, I thought. How likely is that? Well, that’s a pretty easy problem. Let’s assume all hashes are equally likely. That means we can consider each character of the hash independently. Each character can be one of sixteen possible values (0 through f), but we want the cases where each character is a member of the subset 0 through 9. That means that the probability of getting a digit for a given character in the hash is given by the following.

$P_{1} = \frac{10}{16} = 0.625$

Simple enough, but that’s just for one character. To get all seven characters as digits, we need to raise this value to the power 7.

$P_{7} = \left(\frac{10}{16}\right)^{7} \approx 0.0373$

So about 1 out of every 27 commits or so should contain nothing but digits in the first seven characters. To my mind, that’s infrequently enough to be interesting while still frequently enough to be fun.

Other Interesting Parameters

What other neat constraints can we put on?

Well, an obvious one is to expand our digits-only hash from 7 characters to the full 40. In that case, the probability is considerably smaller.

$P_{40} = \left(\frac{10}{16}\right)^{40} \approx 6.8 \cdot 10^{-9}$

That’s about 1 in 146 million, so we can probably say that there might be a commit out there that only has digits. I bet a focused effort could even find it, but I leave that as an exercise for the reader (or maybe me in the future).

What about a short hash that’s in ascending order? We’ll include letters again, so it could be something like 24569bf. Notice that each character’s value is less than the one after it.¹

How could we go about solving this? Well, somebody told me once that probability is just fancy counting, so let’s count. We know there are sixteen possible values and seven spots for them to go in. When we pick the first character, it can be any character up to 9, inclusive, since anything more wouldn’t leave us enough room to fit strictly-increasing characters.

That means that the only case for 9 looks like this: 9abcdef. For 8, there can be one “jump” in the sequence, and that jump can be anywhere, so 8abcdef and 89abcde are both valid. That jump can be in any of seven positions (after the first, after the second, etc.), so for 8 there are seven cases.

7 is where it starts to get more difficult. Here, there can be two jumps of value 1 or one jump of value 2. We know from 8 that the jump of value 2 can be in any of seven positions (e.g. 789cdef). A better way to count these along with the jumps of value 1 might be to think of the jumps as additive. That is, jumps are always of value 1, but if more than one happen to occupy the same position, they “stack up” and become a jump of a larger value. This makes the counting easier, because now we can consider the jumps individually.

Let’s try it. Each jump can occupy any of seven positions, and for 7 there are two jumps. That’s a total of $7^{2} = 49$ cases. For 6, there are three possible jumps, so that’s $7^{3} = 343$. In general, we can sum everything up using the following expression.

$N_{\text{ascending}} = \sum_{i=1}^9 7^{n} = \text{47,079,207}$

As you might expect, most of the cases come from the last term of the sum, when $n=9$.

Now, all we need to do is count up the number of possible arrangements of any sort and divide the two values to come up with the probability. Since there are sixteen possible values for seven different positions, finding the total number of possibilities is pretty straightforward.

$N_{\text{all}} = 16^{7} = \text{268,435,456}$

And so is dividing the two values.

$P_{\text{ascending}} = \frac{N_{\text{ascending}}}{N_{\text{all}}} = \frac{\text{47,079,207}}{\text{268,435,456}} \approx 0.175$

This value is surprisingly high to me. I wouldn’t have guessed that nearly 1 in 5 truncated commit hashes meet my strictly-increasing criterion, but apparently they do.

We could continue on like this forever.

There are endless criteria we could place on commit hashes (or other nearly-meaningless strings). I encourage the reader to set one or more and try to work out the probability. It’s good for the soul, or whatever.

Now, some of you may be smugly thinking that you know the term for this property—as I did mere moments before writing these words—but you’re (probably) wrong. The parameter I’ve arbitrarily stated explicitly disallows repeating the same value, but a monotonic function can have plenty of repeated values if it wants, as long as the values never start going back the way they came. ↩

Markers and Erasers

Mon, 07 Oct 2019 00:00:00 -0400

When I was in the fifth grade, we were sometimes given dry-erase markers and small whiteboards to draw on. Occasionally, we’d use them for lessons, but mostly they came out when it was raining and we couldn’t go outside to play. For a time, my friends and I would play a “video game” with these unlikely implements. One person would draw a target, another would slowly move the marker up and down a vertical edge of the board, and a third—the player—would choose the precise moment when they wanted the marker-bearer to “shoot”. The marker-bearer would then “simulate” a “shot” with “realistic gravity” at the target, and we would all judge damage incurred on the target as well as the veracity of the simulation. Curiously, the player would only call the simulation unfair if he didn’t hit the target, and the target-drawer would always take the opposite position.

In remembering that little game, I also remembered a strange assumption—an extrapolation, really—about markers and erasers. I knew, of course, that markers could leave ink on the board and that erasers could wipe it away. That was obvious. I further knew that the ink left by the markers was a physical substance, since the erasers got dirty, and accumulated ink would form a sort of dust that could be pushed around. To me, it seemed that markers and erasers were opposites; one created, one erased. It was as if the Expo corporation had at their disposal the immense power to instantiate two equally-powerful forces in the universe, intended to work together, but never to meet.

Somewhere along the way, nine-year-old me formed a question with frightening implications: what would happen if you touched a marker directly to an eraser? My little mind raced. Well, I thought, since the marker marks and the eraser erases, the only possibility is that touching the marker directly to the eraser would result in all of the ink in the marker getting sucked out of it and into the eraser instantly. I recall being afraid for some time after that to ever touch the two halves of this reaction together, lest I ruin both. (I may have also inserted that memory after repeated rememberings over the years, but I can’t say.)

Obviously, this is an incorrect conclusion. Touching a marker to an eraser, while counter-productive and a little silly, doesn’t result in some matter-antimatter annihilation phenomenon. At some point, I gathered up the courage to try it, and I remember being both relieved and a little disappointed at the uninteresting result.

Every time I’ve remembered that story since, I’ve idly searched for some meaning in it. It sounds like it could be profound, at least to me. Perhaps this is the core of some commentary on creation and deletion, sources and sinks, good and evil. Or maybe it’s the hook in a cautionary tale about blind extrapolation without evidence. It could even start a discussion about childhood curiosity and learning.

I’ve yet to come up with anything satisfying to say about it. Maybe the whole thing is nothing more than a story about a child who thought a thing was true and turned out to be wrong. I don’t know, but I know for sure that I like remembering it.