Checksum Arcanius

• Commute at least half the time via bike
• Journal or blog at least once per week
• Travel to 12 countries

June 5, 1953

Important decisions about the future development of atomic power must frequently be made by people who do not necessarily have an intimate knowledge of the technical aspects of reactors. These people are, nonetheless, interested in what a reactor plant will do, how much it will cost, how long it will take to build and how long and how well it will operate. When they attempt to learn these things, they become aware of confusion existing in the reactor business. There appears to be unresolved conflict on almost every issue that arises.

I believe that this confusion stems from a failure to distinguish between the academic and the practical. These apparent conflicts can usually be explained only when the various aspects of the issue are resolved into their academic and practical components. To aid in this resolution, it is possible to define in a general way those characteristics which distinguish the one from the other.

An academic reactor or reactor plant almost always has the following basic characteristics: (1) It is simple. (2) It is small. (3) It is cheap. (4) It is light. (5) It can be built very quickly. (6) It is very flexible in purpose (“omnibus reactor”). (7) Very little development is required. It will use mostly “off-the-shelf” components. (8) The reactor is in the study phases. It is not being built now.

On the other hand, a practical reactor plant can be distinguished by the following characteristics: (1) It is being built now. (2) It is behind schedule. (3) It is requiring an immense amount of development on apparently trivial items. Corrosion, in particular, is a problem. (4) It is very expensive. (5) It takes a long time to build because of the engineering development problems. (6) It is large. (7) It is heavy. (8) It is complicated.

The tools of the academic-reactor designer are a piece of paper and a pencil with an eraser. If a mistake is made, it can always be erased and changed. If the practical-reactor designer errs, he wears the mistake around his neck; it cannot be erased. Everyone can see it.

The academic-reactor designer is a dilettante. He has not had to assume any real responsibility in connection with his projects. He is free to luxuriate in the elegant ideas, the practical shortcomings of which can be relegated to the category of “mere technical details.” The practical-reactor designer must live with these same technical details. Although recalcitrant and awkward, they must be solved and cannot be put off until tomorrow. Their solutions require manpower, time and money.

Unfortunately for those who must make far-reaching decisions without the benefit of an intimate knowledge of reactor technology and unfortunately for the interested public, it is much easier to get the academic side of an issue than the practical side. For a large part those involved with the academic reactors have more inclination and time to present their ideas in reports and orally to those who will listen. Since they are innocently unaware of the real but hidden difficulties of their plans, [t]hey speak with great facility and confidence. Those involved with practical reactors, humbled by their experiences, speak less and worry more.

Yet it is incumbent on those in high places to make wise decisions, and it is reasonable and important that the public be correctly informed. It is consequently incumbent on all of us to state the facts as forthrightly as possible. Although it is probably impossible to have reactor ideas labelled as “practical” or “academic” by the authors, it is worthwhile for both the authors and the audience to bear in mind this distinction and to be guided thereby.

Yours faithfully,

H. G. Rickover
Naval Reactors Branch
Division of Reactor Development
U.S. Atomic Energy Commission

via

In January, 2016, I moved to London to spin up a new Source Control team in London for Facebook. So far, the experience has been good — the team here is solid, and living in London has been a good experience. The main thing I need to do more of is travel to the rest of Europe.

In an age of easy sharing, it’s easy to get out of the habit of longer-form writing. However, I have found longer-form writing to be useful for me, so I’m going to strive for more regular updates in this place. I know many people have said such things before; let’s see how I do.

A couple years back, I moved from a full tower for my file server to a small HP Proliant MicroServer (I’ve been very happy with this move). When I made that move, I went from 4x750GB in a RAID 10 configuration to only 2x750GB in a RAID 1 configuration. However, I keep taking photos and I noticed I was running out of space. Since I had the extra Hard Drives just sitting around, I decided to put them back into use. the hardest part was that there are only four HDD slots in the server, and I was using one of them for the boot drive.

However, I had long noticed that there was a 5.25 inch drive bay in the server that was conspicuously unused. All I needed was an adapter. It took me two years to finally get around to this project, but today was the day! I found a drive bay adapater and SATA power and data cables, then got to work. From a physical perspective, it was fairly straightforward once I had all the parts; the hardest part ended up being finding the extra SATA port on the motherboard.

I was a bit wary when I booted the thing — the hard drives I used had previously been a part of the 1.5TB array that the other two came from. Fortunately, everything went smoothly. It was then a rather simple matter of finding this excellent guide on ServerFault to rebuild the array into RAID 10 once again.

Yay technology; internet FTW!

Based on an answer on serverfault, but modified to work on linux:

Use this one-liner to get the bash and sshd processes currently hanging onto the old screen.

ps aux | grep $(ps aux | grep [s]creen | grep -o 'pts[^ ]*') | grep 'sshd\|bash'

Kill these processes and screen is recoverable before the long and arbitrary timeout.

Here’s an interesting security flaw my friend and I discovered today…

I recently upgraded the server behind this site to Ubuntu 14.04 LTS from 12.04 LTS (only about a year late!)

A few things went awry (the PHP install couldn’t talk to MySQL, for example), but a reboot cleared that right now. However, one piece remained broken. Mail wasn’t properly being delivered.

I’m don’t use this server for mail much myself, but some people (like my brother) do. It was broken, and I had no idea why. It didn’t help that the last time I touched the config was over a year ago. It also doesn’t help that mail server setup is basically a dark art. Regardless, after a few days of poking at it and “hoping the problem would go away”, I decided to go at it again today. Hopefully by writing this down I’ll remember a bit more about my setup, but if not, at least I’ll have this handy reference when I forget it again.

The way mail is set up on this server is that Postfix listens for incoming SMTP traffic, which it then forwards to Dovecot for delivery. Dovecot is set up to use the Maildir format, but instead of storing the maildirs in users’ home directories, it stores them in /var/mail/ since not all the users even have home directories. It made sense at the time, and I think it still makes sense now!

At any rate, with Dovecot’s upgrade came a problem, and after digging around, I saw in the logs that Dovecot was unable to deliver mail to /home//Maildir. Of course, those directories didn’t exist, so of course it was failing! However, I had set up the mail_location to be /var/mail/, so what was going on?

It turns out that Dovecot’s Ubuntu distro added a new configuration file, /etc/dovecot/conf.d/99-mail-stack-delivery.conf, which set the mail_location back to /var/mail/, and apparently the last place to set it wins (it was previously set in /etc/dovecot/conf.d/10-mail.conf). I commented out the offending line, and by tailing /var/log/mail.log, I could see that mail was once again delivering.

Now, I don’t know if this means it’s fixed; my brother will have to let me know. Regardless, it’s at least less broken now.