I have completed the migration of this site from Jekyll to Hugo. After using Jekyll for a few days, I quickly discovered many of its limitations, and felt it would be useful to provide a bit of a comparison.

• Common
  • Both are static site generators, and use fairly similar configuration formats.
  • Both prefer Markdown for page markup. Both also contain specific implementations of Markdown, and so will likely differ slightly in their interpretation of the poorly-defined ill-conceived “specification” of Markdown. As long as I stick with one particular implementation, I can probably get reasonable results.
  • Jekyll is written in Ruby, and Hugo in Go. There seems to be a lot of influence of Rails’ convention over configuration in Jekyll. I found it more difficult to do things differently than the particular conventions it was set up for. To me, this also has the advantage that Hugo compiles to a single executable, and doesn’t require an external environment manager (bundle) to be able to run the tool. I can copy the built executable to other machines and just run it.
  • Using Jekyll for blog-style writing only seems to work with a small subset of the themes. It seems that the blog support is more a feature of particular themes than of Jekyll itself.
  • Themes in Jekyll are managed through gem dependencies. This restricts the themes available within Github pages (basically one blogging theme). In Hugo, the themes are in a subdirectory, and are typically brought in through a git submodule.
• Disadvantages of Hugo
  • The BlackFriday Markdown parser in Hugo is, unfortunately, strict about requiring 4 spaces for indentation of nested lists. This tends to look weird in the input source, and two character indented lists get flattened. Apparently, the creator of Markdown thought tabs were 4-spaces (they are not), and that lists should be indented with tabs.
• Advantages of Hugo
  • Hugo also supports Emacs org mode as a markup format. I have not experimented with this, but it may be useful for rendering data that is primarily list oriented.
  • Hugo seems to be a bit better at typography. For example, it converts plain ASCII quotation marks into typography quotes, as in “This is quoted”. It recognies two hyphens as an n-dash: 5–7; three hyphens as an m-dash—such as this.
  • There seem to be a lot more support for things built-in to Hugo. Perhaps these are available as extensions to Jekyll. I will perhaps investigate using LaTeX style math if I ever need that.

I’ll perhaps update this post a bit as I discover other things I like or dislike about Hugo.

Last night, I finally got all of the pieces together for hosting of this site. Here, I will summarize what solution I ended up going with, and a little about my future plans.

Static site

After convincing myself that Markdown is only terrible (instead of utterly terrible), and that it would be ok for short postings like I intend to make here. I got this site set up with Jekyll for static site generation.

This post is going to focus on some particular security issues in the embedded space (the IoT space, if you will). I regularly work with microcontrollers (MCUs) based on variants of the Cortex-M architecture. These are ARM processors that typically have a small amount of ROM (½–1 MiB) and an even smaller amount of RAM (16–128 KiB).

Traditionally, security has not been much of a focus on these types of devices (think toasters, washing machines, and the likes). However, with increased connectivity, we are starting to see more and more security problems with the code in these devices.

Today, I migrated my primary Ubuntu 17.04 development machine to put the root volume onto a thinly provisioned volume. There was a bit of a comedy of errors, so I want to outline what I should have done, vs what actually happened.

What I should have done

As in anything like this, it is important to start with known good backups. In my [backup post]({% post_url 2017-09-10-backups %}), I describe how I’m doing that, and even testing it. Then things would roughly following the following steps:

For my first post, I’d like to discuss some of my strategy that I use for backups.

Backups are one of those things that most people realize are important, yet most people don’t really do them consistently. Aside from that, I’ve found that very few people test their backups.

There are two scenarios that backups are important for:

1. Disaster recovery. After a hard disk crash or other failure, how can I recovery a machine to the state it was in before the crash.
2. Accident recovery. When something is accidentally erased or modified, how can I recovery that file or directory in a state it was in in the past.

These scenarios place different demands on the backup system. They also combine in interesting ways. For example, if after a disaster recovery, how can an older version of a file be restored.