Category: Uncategorized

Your brain is not a computer, you are

In an article published on Aeon, Dr. Robert Epstein declared:

Your brain does not process information, retrieve knowledge or store memories. In short: your brain is not a computer

Dr. Epstein laments the emergence and pervasiveness of the IP (information processing) metaphor for the human brain; that is, that the brain operates in the way that modern computers do (though presently with vastly different capabilities). He discusses the difference between a computer’s approach (strict instructions, perfect recall) and a human’s (experiential evolution of knowledge), ultimately concluding that trying to compare a brain and a computer is a flawed undertaking.

Approaching the problem from this angle, Dr. Epstein makes a compelling argument against the ability to compare a brain and a computer directly, though there may be a mismatch in metaphors. A bit in a register and an electrical pulse in a neuron only make sense in the context of a larger system, and it’s the sophistication of that system that determines how those bits and pulses are interpreted. Computer-based systems have a long way to go before matching every level of brain sophistication.

However, when I think about the phrase “the brain is a computer”, rather than approaching the problem from the perspective of algorithms and memory, I think a more appropriate (and more interesting) comparison is with respect to inputs and outputs.

From a computer’s perspective, the concepts of “input” and “output” are straightforward. The device you’re reading this on accepts inputs (via entry points like the touchscreen, keyboard, mouse, or microphone), does *something*, then produces outputs (via exit points like the display, speakers, or vibrating motors). Regardless of what happens in the middle (that is, how the information received via the inputs is changed and turned into information produced via the outputs), the device is, in one way or another, interacting with the physical world.

Computers and humans (and all living beings really) function in a similar fashion, with varying levels of sophistication. Humans, like computers, have several ways to accept information (starting with the five senses) and one fundamental way to produce information (triggering muscles to move parts of our bodies, such as our fingers or vocal chords). The way our brains convert the input that we receive into output via muscle activity is certainly different (for now), but that system is still bookended by physical interactions.

We may be missing the point if we ask the question: “Do computers and humans represent and process information in the same way?” Computers may eventually be designed to process information in the same way as humans and they may not. Instead we should be asking: “Can computers be designed to accept inputs and produce outputs in a way that is increasingly similar to humans?” This is the goal of AI assessments like the Turing Test: to determine if an artificially intelligent system can emulate human cognition and behavior, simply evaluate whether the output it produces can be distinguished from human output.

Ultimately, if you accept that computers are physical objects that accept inputs, process them in some way, and produce outputs, your brain may not be a computer; but you are.

Better Qmail on Ubuntu – now with TLS support

On February 9th, 2016, Google announced that emails received via an insecure connection would be marked with an open red padlock, indicating that the contents of the email could be viewed while in transit. Given the attention that online security is getting these days, it’s refreshing to see that SMTP connections are finally in someone’s crosshairs.

Securing Email Systems

On the server  administration side, email-related encryption comes into play on 3 fronts:

  1. Reading email (POP/IMAP connections)
  2. Receiving email (inbound SMTP connections)
  3. Sending email (outbound SMTP connections)

Regardless of your mail system’s native support for encrypted connections, items #1 and #2 can be worked around with other packages; I’ve used stunnel and courier to secure POP/IMAP connections, and nginx’s reverse mail proxy to secure inbound SMTP connections.

However, fixing item #3 without native support for TLS is trickier – outbound connections can’t be proxied in the same way. Using a persistent secure tunnel to an external relay is possible, but that external relay would likely be a paid service like Mandrill or Sendgrid, introducing an additional layer of complexity into the architecture.

Fortunately a TLS patch for Qmail exists, so to remove the red padlock from outbound emails from my systems, I’ve added the patch to my netqmail package for Ubuntu. It’s been running in production on multiple servers for the last two months without problems, so I’m relatively confident that I’ve correctly translated the patch.

If you choose to install or upgrade to this version of netqmail, please note that there are a couple caveats. I hope to find ways to fix them in the installation, but until then, here’s what you need to know:

1. TLS is *not* enabled by default – you need to generate a private key and certificate

The OpenSSL command will prompt you for information about your system to generate your certificate. The most important item is the Common Name (CN) field: it should match the MX record that points to the server. As long as the certificate doesn’t use weak/outdated encryption, Google (and other providers) don’t seem to be penalizing self-signed certificates.

The server certificate is also symlinked to the client certificate file; the same certificate can be used to secure both inbound and outbound connections.

2. dh2048.pem and rsa2048.pem are not immediately generated

Diffie-Hellman parameters are necessary for the server side of the connection, and can either be cached or are generated on the fly when new connections are initiated. Generation of these parameters is expensive, however, and can take a long time, so normally they’re regenerated daily by a cron job. This cron job is included in the netqmail package.

Given that parameter generation takes an indeterminate and potentially long time, it’s not performed as part of the installation. Therefore, prior to these parameters being generated and cached for the first time (within 24 hours of installation), server connections may take (much) longer than normal. After installation, I recommend immediately generating these parameters:

Other Notes

The Launchpad repository now upgrades the qmail-run package as well; the overhead of TLS support increases the memory required for the SMTP server. Hence, the tcpserver softlimit has been increased.


Got all that? Great! Your Ubuntu Qmail installation is now capable of sending and receiving email securely. There are additional configuration directives that impact qmail-smtpd and qmail-remote, but the defaults should be fine for most installations.

Using Better Qmail on Ubuntu? I’d like to hear about your experiences with it in the comments.

A welcome upgrade

For at least 5 years, the website at looked like this:

Simple, handmade, and more than a little ugly, but adequate as a minimum viable web presence. However, as content has started to fragment into the familiar silos (Facebook, Twitter, Flickr, LinkedIn, and more), it seems to be the right time to make a change and consolidate onto a self-hosted publishing platform.

So here we are, starting anew with a WordPress blog, a theme that satisfies (for now), and a single, primary source for creating and distributing content.

© 2021 Ryan Buterbaugh

Theme by Anders NorenUp ↑