published hudson fan shroud, replaced makefile with scripts, added some

drafts

9 files changed, 305 insertions, 131 deletions

diff --git a/Makefile b/Makefile
deleted file mode 100644
index 8dcd6e5..0000000
--- a/Makefile
+++ /dev/null
@@ -1,17 +0,0 @@
-# Written for FreeBSD make(1), or pmake. Not tested with GNU make.
-
-EDITOR = $$EDITOR
-POST_T = includes/template.php
-
-.PHONY: serve post 
-
-serve: 
-	php -S localhost:8000
-
-draft: 
-	@read -rp "Title: " TITLE; \
-	SHORT_DATE=`date +"%Y-%m-%d"`; \
-	FILENAME=drafts/$$SHORT_DATE-`printf "$$TITLE" | tr -Cs "[:alnum:]" '-' | tr "[:upper:]" "[:lower:]"`.php; \
-	sed -i '' "s/{{ title }}/$$TITLE/g" $$FILENAME; \
-	$$EDITOR $$FILENAME
-
diff --git a/drafts/2021-09-26-forget-autorandr-automate-display-switching-with-devd-on-freebsd.php b/drafts/2021-09-26-forget-autorandr-automate-display-switching-with-devd-on-freebsd.php
new file mode 100644
index 0000000..8ae50f7
--- /dev/null
+++ b/drafts/2021-09-26-forget-autorandr-automate-display-switching-with-devd-on-freebsd.php
@@ -0,0 +1,41 @@
+<?php
+$title = "Forget autorandr, Automate Display Switching with devd(8) on FreeBSD";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+<p class="description">
+	<a href="https://github.com/phillipberndt/autorandr"><code>autorandr</code></a> and <a href="https://github.com/libthinkpad/dockd"><code>dockd</code></a> have been around for a while. Both let you automatically switch to or from external displays when your laptop is plugged into a hub or hooked up to a docking station. But those are largely Linux- and Thinkpad-centric solutions. Let's do it the FreeBSD way.
+</p>
+
+<p>
+	Here are my requirements. I have an E-series Dell laptop with a docking station. My docking station is hooked up to one large Dell monitor. When the laptop is attached to the docking station, I want...
+</p>
+
+<ol>
+	<li>The laptop to use the larger, external monitor exclusively (no mirroring)</li>
+	<li>The default sound device to switch to the external monitor's speakers</li>
+	<li>Disable automatic locking via <code>xautolock(1)</code></li>
+	<li>Disable suspend on lid close</li>
+</ol>
+
+<p>When the laptop is removed from the docking station, I want...</p>
+
+<ol>
+	<li>The laptop to switch to its internal display</li>
+	<li>The default sound device to switch back to the internal laptop speakers</li>
+	<li>Automatic locking to re-enable</li>
+	<li>Suspend on lid close to re-enable</li>
+</ol>
+
+<p>To do this we'll need the following:</p>
+
+<ol>
+	<li><code>devd(8)</code> for launching userland applications when kernel events occur</li>
+	<li><code>xrandr(1)</code> for switching displays</li>
+	<li><code>xautolock(1)</code> for automatic locking</li>
+	<li><code>sysctl(8)</code> for changing hardware knobs</li>
+	<li>Some core utilities and a tiny shell script to bring it all together</li>
+</ol>
diff --git a/drafts/2021-09-26-useful-shell-scripting-and-bulk-renaming-files-with-vim.php b/drafts/2021-09-26-useful-shell-scripting-and-bulk-renaming-files-with-vim.php
new file mode 100644
index 0000000..6f0adfe
--- /dev/null
+++ b/drafts/2021-09-26-useful-shell-scripting-and-bulk-renaming-files-with-vim.php
@@ -0,0 +1,6 @@
+<?php
+$title = "Useful Shell Scripting and Bulk Renaming Files with Vim";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
diff --git a/includes/template.php b/drafts/2021-09-27-imagemagick-display-and-svg-patterns.php
index 5ff90f4..16a09ee 100644
--- a/includes/template.php
+++ b/drafts/2021-09-27-imagemagick-display-and-svg-patterns.php
@@ -1,6 +1,8 @@
 <?php
-$title = "{{title}}";
+$title = "imagemagick display and svg patterns";
 if (isset($early) && $early) {
-	return;
+return;
 }
 include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
diff --git a/drafts/2021-reading-list.php b/drafts/2021-reading-list.php
index 46d4707..a204d0e 100644
--- a/drafts/2021-reading-list.php
+++ b/drafts/2021-reading-list.php
@@ -1,9 +1,10 @@
 <h1>Adam's 2021 Reading List</h1>
 
 <ul>
-  <li>Scott, Cavan. <em>Dooku: Jedi Lost (Star Wars)</em></li>
-  <li>Sachar, Louis. <em>Holes</em></li>
-  <li>Steinbeck, John. <em>The Pearl</em></li>
-  <li>Fitzgerald, F. Scott. <em>The Great Gatsby</em></li>
-  <li>Wells, H.G. <em>War of the Worlds</em></li>
+	<li>Scott, Cavan. <em>Dooku: Jedi Lost (Star Wars)</em></li>
+	<li>Sachar, Louis. <em>Holes</em></li>
+	<li>Steinbeck, John. <em>The Pearl</em></li>
+	<li>Fitzgerald, F. Scott. <em>The Great Gatsby</em></li>
+	<li>Wells, H.G. <em>War of the Worlds</em></li>
+	<li>Tolkien , J. R. R. <em>The Fellowship of the Ring</em></li>
 </ul>
diff --git a/drafts/its-not-rust-vs-go.php b/drafts/its-not-rust-vs-go.php
index c9273ff..1ec29a8 100644
--- a/drafts/its-not-rust-vs-go.php
+++ b/drafts/its-not-rust-vs-go.php
@@ -1,150 +1,191 @@
-<h1>"Rust or Go?" is not the question</h1>
-<h1>Part 2: (But Rust is definitely the answer)</h1>
-<h1>Part 3: Rust is definitely production ready</h1>
--> part 2 include coworker conversation tidbits draft notes:
+<?php
+$title = "'Rust or Go?' Is Not the Right Question (but Rust Is Still the Right Answer)";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+<p class="description">
+	I have used Rust professionally for two production projects that see daily usage in our company. One is a rewrite of a small C# HTTP application service. The second is a from-scratch automation library with CLI and HTTP service end-user applications. I chose Rust for its safety, runtime speed, and useful abstractions. <br>
+	On several occasions I've received strange messages or suggested reading from coworkers that usually goes something like "here, look at this: this is why Go is better than Rust. You should have used Go." <br>
+	Here's what I think.
+</p>
+
+<h2>"Rust or Go?"</h2>
+
+<p>
+	I don't believe there is a single right tool to do any job. I do believe there are better tools for doing some jobs, and tools that are decent for most jobs. I also believe that Go and Rust are two very different tools for doing very different jobs. Why do these programming languages get compared a lot? Is it because they're both AOTC, statically-typed, "server-side" langauges?
+</p>
+
+<p>From <a href="https://web.archive.org/web/20210917125023/https://golang.org/">golang.org</a>:</p>
+
+<blockquote>
+	Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
+</blockquote>
+
+<p>And from <a href="https://web.archive.org/web/20210918013407/https://www.rust-lang.org/">rust-lang.org</a>:</p>
+
+<blockquote>
+	A language empowering everyone to build reliable and efficient software.
+</blockquote>
+
+<p>Wow, yeah looks like they are both trying to solve the same problem. Both claim to allow programmers to build reliable and efficient software. So maybe the difference isn't <em>what</em> they're trying to solve, maybe it's <em>how</em>they're each trying to solve it.
+
+
+<p>Let's look a little deeper. From the <a href="https://web.archive.org/web/20210909115254/https://golang.org/doc/">Go documentation</a>:</p>
+
+<blockquote>
+	The Go programming language is an open source project to make programmers more productive.
+
+	Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
+</blockquote>
+
+<p>And, from the <a href="">Rust book</a>:</p>
+
+<blockquote>
+	Rust is for people who crave speed and stability in a language. By speed, we mean the speed of the programs that you can create with Rust and the speed at which Rust lets you write them. The Rust compiler’s checks ensure stability through feature additions and refactoring. This is in contrast to the brittle legacy code in languages without these checks, which developers are often afraid to modify. By striving for zero-cost abstractions, higher-level features that compile to lower-level code as fast as code written manually, Rust endeavors to make safe code be fast code as well.
+</blockquote>
+
+<p>Now we're starting to see some differences in objective. Go is designed to make it really fast to write Go code. It is supposed to be concise (so you type less) and quick to compile. It aims to feel like an interpreted language to work with. Meanwhile, Rust is preoccupied with delivering fast safety and stability.
+
+
+	Meanwhile, Rust is looking to make higher-level abstractions as fast as large, manually-written, lower-level code. It's also preoccupied with <em>safety and stability</em>.</p>
+
+
+
+------
 <ul>
-  <li>These are two very different languages</li>
-  <li>These two languages are solving two very different problems</li>
-  <li>
-    What attracted me to Rust is the error handling and borrow checker. You
-    don't need a runtime and you don't need to worry about a variety of memory
-    pitfalls.
-  </li>
-  <li>
-    Rust is not just a systems-level language, and Go is not just a server-side
-    language.
-  </li>
-  <li>Rust isn't *really* about speed or performance. It's about safety.</li>
-  <li>Rust is just plainly a more powerful language.</li>
-  <li>
-    Go is for Python developers who need speed. Rust is for C++ developers who
-    need safety.
-  </li>
-  <li>
-    Rust has opt-in concurrent runtimes and opt-in garbage collection. These are
-    standard in Go, there's no getting out of them.
-  </li>
+	<li>These are two very different languages</li>
+	<li>These two languages are solving two very different problems</li>
+	<li>
+		What attracted me to Rust is the error handling and borrow checker. You
+		don't need a runtime and you don't need to worry about a variety of memory
+		pitfalls.
+	</li>
+	<li>
+		Rust is not just a systems-level language, and Go is not just a server-side
+		language.
+	</li>
+	<li>Rust isn't *really* about speed or performance. It's about safety.</li>
+	<li>Rust is just plainly a more powerful language.</li>
+	<li>
+		Go is for Python developers who need speed. Rust is for C++ developers who
+		need safety.
+	</li>
+	<li>
+		Rust has opt-in concurrent runtimes and opt-in garbage collection. These are
+		standard in Go, there's no getting out of them.
+	</li>
 </ul>
 
 <p>
-  Go has great concurrency. Goroutines are high-performance, parallel green
-  threads. Rust's concurrency is provably-correct.
+	Go has great concurrency. Goroutines are high-performance, parallel green
+	threads. Rust's concurrency is provably-correct.
 </p>
 
 <p>
-  Why is the immediate question when someone says they wrote something in Go,
-  "why not rust?". The inverse is true. When I tell a dev I wrote something in
-  Rust, the immediate response is "you should have used Go, it's better." This
-  is false.
-</p>
+	Why is the immediate question when someone says they wrote something in Go,
+	" why not rust?". The inverse is true. When I tell a dev I wrote something in Rust, the immediate response is "you should have used Go, it's better." This is false. </p>
 
 <p>
-  What does suck about Rust? The compiler is slow. It will probably always be a
-  degree of magnitude slower than another compiler for a similar target.
+	What does suck about Rust? The compiler is slow. It will probably always be a
+	degree of magnitude slower than another compiler for a similar target.
 </p>
 
 <p>
-  It's not Rust vs Go, it's when to use Rust and when to use Go. And the number
-  one argument I get for why Go should be used is it's simpler and faster to
-  learn and work with. There's the answer! The answer is use whichever one works
-  best for you. There's no better or worse, or superiority. Redditors will say
-  otherwise.
+	It's not Rust vs Go, it's when to use Rust and when to use Go. And the number
+	one argument I get for why Go should be used is it's simpler and faster to
+	learn and work with. There's the answer! The answer is use whichever one works
+	best for you. There's no better or worse, or superiority. Redditors will say
+	otherwise.
 </p>
 
 <p>sources</p>
 
 <p>
-  Go vs Rust discussions are ridiculous. It should be more like: When to use Go.
-  When to use Rust. When to use X… — Inanc Gumus (@inancgumus) September 19,
-  2019
-  <a
-    href="https://twitter.com/inancgumus/status/1174728131925676032?ref_src=twsrc%5Etfw"
-    >source</a
-  >
+	Go vs Rust discussions are ridiculous. It should be more like: When to use Go.
+	When to use Rust. When to use X… — Inanc Gumus (@inancgumus) September 19,
+	2019
+	<a href="https://twitter.com/inancgumus/status/1174728131925676032?ref_src=twsrc%5Etfw">source</a>
 </p>
-<a
-  href="https://insights.dice.com/2020/08/27/rust-in-trouble-after-big-mozilla-layoffs/"
-  >Is Rust in Trouble After Big Mozilla Layoffs?</a
->
-<a href="https://foundation.rust-lang.org/posts/2021-02-08-hello-world/"
-  >Hello World! (Rust Foundation)</a
->
+<a href="https://insights.dice.com/2020/08/27/rust-in-trouble-after-big-mozilla-layoffs/">Is Rust in Trouble After Big Mozilla Layoffs?</a>
+<a href="https://foundation.rust-lang.org/posts/2021-02-08-hello-world/">Hello World! (Rust Foundation)</a>
 
 <a href="https://killedbygoogle.com/"> Killed by Google</a>
 
 <a href="https://dart.dev/overview">The Dart Programming Language</a>
 
-<a
-  href="https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=c8caad873419"
-  >Discord swapped Go for Rust</a
->
+<a href="https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f?gi=c8caad873419">Discord swapped Go for Rust</a>
 
 <blockquote>
-  Both Microsoft and Amazon have just recently announced and released their new
-  officially supported Rust libraries for interacting with Windows and AWS.
-  Official first party support for these massive APIs helps make Rust people's
-  first choice when deciding what to use for their project.
+	Both Microsoft and Amazon have just recently announced and released their new
+	officially supported Rust libraries for interacting with Windows and AWS.
+	Official first party support for these massive APIs helps make Rust people's
+	first choice when deciding what to use for their project.
 </blockquote>
-<a href="https://blog.rust-lang.org/2021/05/15/six-years-of-rust.html"
-  >Source</a
->
-
-<a href="https://hub.packtpub.com/is-dart-programming-dead-already/"
-  >Dart -- apples to oranges? I'm not trying to say that go is going the way of
-  dart, I'm trying to say that industry-leading companies aren't always stewards
-  of their creations. take FreeBSD. It's a thriving, excellent operating system
-  capable of "industry-leading company" usage. See the usuals (Netflix, Sony,
-  etc). Look at the FreeBSD foundation. Now look at RedHat and IBM. Again,
-  apples to oranges? No, just a bad argument to make in the first place.</a
->
+<a href="https://blog.rust-lang.org/2021/05/15/six-years-of-rust.html">Source</a>
+
+<a href="https://hub.packtpub.com/is-dart-programming-dead-already/">Dart -- apples to oranges? I'm not trying to say that go is going the way of
+	dart, I'm trying to say that industry-leading companies aren't always stewards
+	of their creations. take FreeBSD. It's a thriving, excellent operating system
+	capable of "industry-leading company" usage. See the usuals (Netflix, Sony,
+	etc). Look at the FreeBSD foundation. Now look at RedHat and IBM. Again,
+	apples to oranges? No, just a bad argument to make in the first place.</a>
 
 <p>quotables</p>
 
 <blockquote>
-  Take a look Go as well. I think you will find Go much faster to program in.
-  The other aspect is threading. They have very different threading models. Not
-  sure if you had the chance to research that yet or not
+	Take a look Go as well. I think you will find Go much faster to program in.
+	The other aspect is threading. They have very different threading models. Not
+	sure if you had the chance to research that yet or not
 </blockquote>
 <blockquote>
-  Yes, a big thing is threading. Unfortunately, Rust uses a similar model as
-  Java for threads :(. Go is based on Fibers approach which so much faster for
-  temporary, lightweight requests. Go is definitely superior for HTTP REST API
-  apps. Rust can be better for a single-thread app or general "systems"
-  programming.
+	Yes, a big thing is threading. Unfortunately, Rust uses a similar model as
+	Java for threads :(. Go is based on Fibers approach which so much faster for
+	temporary, lightweight requests. Go is definitely superior for HTTP REST API
+	apps. Rust can be better for a single-thread app or general "systems"
+	programming.
 </blockquote>
 
 <p>
-  Rust is not a "systems programming" language. Systems programming is not a
-  genre of languages. It's not like saying Italian is a "Romantic language".
-  Systems programming is a specific, targeted programming *application*. It's
-  the destination, the use-case that a language is being applied to. Rust is a
-  general-purpose programming language. I have used it to write a variety of
-  tools, low- and high-level, server-side and client-side, graphical and CLI.
-  Yes, I used it for some systems programming. Also used it to make a very
-  simple and robust web service digested by a variety of other developers at our
-  company.
+	Rust is not a "systems programming" language. Systems programming is not a
+	genre of languages. It's not like saying Italian is a "Romantic language".
+	Systems programming is a specific, targeted programming *application*. It's
+	the destination, the use-case that a language is being applied to. Rust is a
+	general-purpose programming language. I have used it to write a variety of
+	tools, low- and high-level, server-side and client-side, graphical and CLI.
+	Yes, I used it for some systems programming. Also used it to make a very
+	simple and robust web service digested by a variety of other developers at our
+	company.
 </p>
 
 <blockquote>
-  The only way is to learn and try both. That's what I did. Most of the info
-  from both sides is biased...Go is definitely very fast and [garbage
-  collection] is not the issue people make it out to be. I started last month
-  porting [a chess] engine to Rust. I recently took a break from it because the
-  syntax and borrow checking were getting insane to deal with. Once I learned
-  about the threading issues in Rust, I have put it on the shelf for now. Rust
-  is still evolving which is good and bad. It needs better IDE and Debugging
-  support than current levels. Hopefully that will continue to improve. There
-  was a big Mozilla shakeup (Nov 2020) where they let go of the Rust developers
-  and cancelled the project. AWS hired them. So honestly, I am not sure which
-  direction the language is going in. Meaning, now that AWS owns the braintrust,
-  I don't know where they are headed. My guess is that AWS is using Rust for
-  some behind the scenes script-like stuff. Not sure. Will be important in the
-  next year or two on which direction things end up going. For Rust to benefit
-  long-term, it needs the support of a corporate backer
+	The only way is to learn and try both. That's what I did. Most of the info
+	from both sides is biased...Go is definitely very fast and [garbage
+	collection] is not the issue people make it out to be. I started last month
+	porting [a chess] engine to Rust. I recently took a break from it because the
+	syntax and borrow checking were getting insane to deal with. Once I learned
+	about the threading issues in Rust, I have put it on the shelf for now. Rust
+	is still evolving which is good and bad. It needs better IDE and Debugging
+	support than current levels. Hopefully that will continue to improve. There
+	was a big Mozilla shakeup (Nov 2020) where they let go of the Rust developers
+	and cancelled the project. AWS hired them. So honestly, I am not sure which
+	direction the language is going in. Meaning, now that AWS owns the braintrust,
+	I don't know where they are headed. My guess is that AWS is using Rust for
+	some behind the scenes script-like stuff. Not sure. Will be important in the
+	next year or two on which direction things end up going. For Rust to benefit
+	long-term, it needs the support of a corporate backer
 </blockquote>
 
+<p>IDE support? See rust language server, rust-analyzer, rustfmt, and cargo</p>
+
 <p>Rust is absolutely ready for production use.</p>
 <p>
-  Anti-Rust zealotry is just as strong as pro-Rust zealotry. The hype goes both
-  ways. No, your talking points shouldn't come from Reddit.
+	Anti-Rust zealotry is just as strong as pro-Rust zealotry. The hype goes both
+	ways. No, your talking points shouldn't come from Reddit.
 </p>
+
+<p>Everything isn't great in goland either. Gofmt and the go module structure were harsh and annoying for me to use. I don't prefer languages with rigorous whitespace requirements anyways. The opinionated standard library is fickler than I would imagine, and the drama churned up over the introduction of generics (a useful, modern programming concept) is popcorn-worthy</p>
+
+<p>The hidden cost of Go: go might be faster to actually type in. But I spend much less time debugging in Rust. The compiler/borrow-checker tells me why I can't write to memory that's already been dropped or borrowed someplace else, and suggests what I need to paste in to fix it. These kinds of bugs take a long time to track down by stepping-through Go code. Some might not even get caught. I don't use a debugger for Rust because I rarely need to step through my code one line at a time to figure out where something became NULL</p>
diff --git a/new.sh b/new.sh
new file mode 100755
index 0000000..0664940
--- /dev/null
+++ b/new.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+read -rp 'Title: ' title
+draft=drafts/$(date +'%Y-%m-%d')-$(printf "$title" | tr -Cs '[:alnum:]' '-' | tr '[:upper:]' '[:lower:]').php
+
+cat > "$draft" << EOF
+<?php
+\$title = "$title";
+if (isset(\$early) && \$early) {
+return;
+}
+include(\$_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+EOF
+
+$EDITOR "$draft"
+
+read -rp 'Publish? [y/N]: ' choice
+[ 'y' = "$choice" ] && mv "$draft" posts/ || echo Saved draft.
+
+read -rp 'Go live? [y/N]: ' choice
+[ 'y' = "$choice" ] && git commit && git push origin && git push live || echo Deferred publish.
diff --git a/posts/2021-10-01-shroud-your-rad-for-an-ice-cold-hudson.php b/posts/2021-10-01-shroud-your-rad-for-an-ice-cold-hudson.php
new file mode 100644
index 0000000..d546554
--- /dev/null
+++ b/posts/2021-10-01-shroud-your-rad-for-an-ice-cold-hudson.php
@@ -0,0 +1,76 @@
+<?php
+$title = "Shroud Your Rad for an Ice-cold Hudson!";
+if (isset($early) && $early) {
+	return;
+}
+include($_SERVER['DOCUMENT_ROOT'] . '/includes/head.php');
+?>
+
+
+<p class="description">
+	Note: This mod requires the 1970s Dodge truck/van radiator conversion, and has not been tested with stock Hudson radiators. The Dodge radiator is a popular mod, and offers better cooling capacity than stock. If it could keep a big V8 cool, it can keep a big straight-six cool too! This mod also uses the stock Hudson mechanical water pump fan.
+</p>
+
+<p>
+	Hudsons, like many early post-war cars suffer from poor engine cooling, especially in "parade" traffic. In our opinion, this mostly boils down to the lack of a fan shroud. But not this one! I like to drive this car, and our Virginia summers are HOT, so Dad (<a href="https://forum.hetclub.org/profile/discussions/DavidC">DavidC</a>) and I did this modification to be able to drive this car in all weather. I've been in traffic jams in my car in upwards of 95℉ and 90% humidity. While I have experienced vapor lock under these conditions, I've never once overheated my old engine.
+</p>
+
+<h2>The Final Product</h2>
+
+<p>
+	Here are some snapshots of the shroud when installed.
+	<img src="https://nextcloud.53hor.net/index.php/s/jFMzyKc2j4BTt3i/preview" />
+	<img src="https://nextcloud.53hor.net/index.php/s/5owtggwxJYSQGcs/preview" />
+	<img src="https://nextcloud.53hor.net/index.php/s/2GRL2sTWNfEafFd/preview" />
+	<img src="https://nextcloud.53hor.net/index.php/s/KoSsge8NL4oSSxd/preview" />
+</p>
+
+<h2>The Kit</h2>
+
+<p>
+	The shroud kit we used is PN Z40026 by HR Performance. Some other manufacturers sell this kit as well. The dimensions we used are 18-1/8" x 28-1/8" x 2-1/2". It generally looks like this, and is broken up into a large, rectangular shroud and a circular ring for the fan shroud/guard. It typically comes with a variety of fasteners and tabs to mount it to the radiator mounting brackets or the upper radiator supports.
+	<img src="https://nextcloud.53hor.net/index.php/s/GtPziK8BCDAb9AN/preview" />
+</p>
+
+<h2>Kit Modification Tips</h2>
+
+<p>
+	The kit requires some modification to get it to work in this application. First, the height has to be shortened to match the height of the Dodge rad. In doing this, we preserved the geometry by cutting out and raising the lower trapezoid of the body and pop-riveted it higher in the shroud. We then cut off the excess shroud body.
+</p>
+
+<p>
+	Second, we decreased the overall depth of the rectangular shroud body. We did this pretty drastically, about an inch, to allow for an AC condenser in front of the Dodge rad. The depth is only important to getting the circular shroud ring completely around the fan blades without the fan sticking too far forward into the rectangular body of the shroud, or so far out that it's completely outside of the shroud. See the picture below for a good idea of the shroud depth in relation to fan insertion.
+</p>
+
+<p>
+	Finally, we relieved the quarter-circle of the ring that gets close to our AC compressor (where the factory generator is located). See below picture for an idea of this relief. Most of all, it makes it easier to remove the AC compressor without removing the shroud, if the need should arise.
+	<img src="https://nextcloud.53hor.net/index.php/s/WdMWTw4S8iyG4bk/preview" />
+</p>
+
+<h2>Assembly Tips</h2>
+
+<p>
+	We mounted the circular fan guard higher than the rectangular shroud body, almost in line with the rad filler neck (you can see this in the above picture). This is because the Dodge rad sits lower than the stock Hudson fan, and we wanted to keep the original mechanical fan. This meant using additional aluminum material (either included in the kit or leftovers) as a front to the circular ring where it protrudes above the rectangular body. This piece was cut into a semicircle and pop-riveted to the front of the circular ring.
+</p>
+
+<p>
+	We used varying lengths of U-shaped rubber channel to protect the rad from sharp/hard aluminum edges, since the shroud mounts directly up against the fins of the rad. We also used this material in between pieces of folded aluminum at the bottom of the shroud.
+</p>
+
+<p>
+	The shroud is fastened to the radiator support mounts with the included fasteners and small aluminum tangs. We later removed the shroud entirely and brought it to a local welder who works with aluminum. They welded all of the open joints and replaced all of the pop-rivets with beautiful welded beads. They also ground off and filled in the rivets. This made the shroud look much more professional.
+</p>
+
+<p>
+	<em>Note on choice of stock, mechanical fan vs aftermarket, electrical fans</em>: we have found the stock mechanical fan performs more than adequately. With this shroud, the flow is excellent, and will vacuum a shop towel up against the grill of the car while idling. It is less noisy than an electrical fan, and looks nicer than plastic electric "pusher" style fans that some folks put in front of their rad.
+</p>
+
+<h2>Results, Additional Info</h2>
+
+<p>
+	The proof is in the increased usability and drivability of the car. The cooling performance is fantastic. The coolant temperature has rarely passed 210℉, even just idling in traffic. I have never belched coolant from the overflow or been stranded on the side of the road as a result of overheating.
+</p>
+
+<p>
+	<em>A note on our coolant mixture.</em> Our coolant is primarily 50/50 ethylene glycol. We also mix in a bottle of RedLine Water Wetter and some water-soluble oil. We got this from one of Walt Mordenti's tech tips, and we owe him a great deal for the drivability and performance of this Hudson.
+</p>
diff --git a/serve.sh b/serve.sh
new file mode 100755
index 0000000..e7f2b4c
--- /dev/null
+++ b/serve.sh
@@ -0,0 +1,2 @@
+#!/bin/sh
+php -S localhost:8000