Resuscitating the Blog

When I started this blog I used Wordpress. Wordpress is web-based content management system that uses PHP and one of MySQL or MariaDB to store the post data. I used Wordpress for years moving between a few different hosts finally settling on Linode.

Wordpress is a great product and has a healthy, vibrant user community. There are thousands of plugins and themes. There's phone apps for making blog posts on-the-go. However, being a dynamic web tool it is vulnerable to security issues. It is a constant game of whack-a-mole keeping things updated. Plugins add new bugs, and sometimes plugins are written with purposeful backdoors.

Over three years ago I decided to move away from Wordpress to something non-dynamic. Something with fewer vulnerabilities. I initially tried Hugo and found a tool that exports posts from Wordpress to Hugo. However, I found I didn't really like Hugo, and I just kinda... didn't do anything about it for a long time. Years a long time.

A few weeks ago I decided to revisit things. I found Pelican, a Python-based static website builder. It is very similar to Hugo in form and function, but being written in Python it jibes with my knowledge and skills much better than Hugo. Posts and pages are written in reStructuredText or Markdown, or even HTML. I mostly use Markdown, and in a few cases, HTML is the correct choice (e.g. photo galleries). Each document has fields of metadata that Pelican parses to build out a full static website. There are a number of themes and I'm presently using the bootcamp2 theme. Pelican also has dozens of plugins that add plenty of capabilities but zero vulnerabilities.

It took a few weeks to slowly fix up all the posts that previously had been exported from Wordpress into Hugo-flavored Markdown into something Pelican could read. I uploaded a fair number of videos to YouTube, and had to adjust various other media here and there.

At the same time I'm moving my website to a new Linode server. This new server will not run any PHP or other dynamic web content which should keep things much simpler.

I'm going to try to post here more often and more consistently. Let's see if I succeed!


Bye Bye Bitbucket

A few days ago Bitbucket announced that they were ending support for Mercurial and will only support Git starting in about a year. I am a happy Mercurial user. It was the first DVCS system I learned, and have had no reason to switch away from it. Git is more popular than Mercurial, yes, but with useful plugins like hg-git, I never need to use Git even when I am working on a Git repository. Ultimately, the difference between Git and Mercurial is kind of like the difference between Windows and Mac (in that order). One is more popular than the other, but when it comes down to featureset and capabilities, it's very close. Like Windows vs. Mac, the main difference is the experience of using them, and I feel Mercurial is the clear winner.

I only use Bitbucket for their Mercurial support, so I decided to waste no time and abandon them entirely and immediately. In their place I am self-hosting an install of the community (open source) edition of Rhodecode. There are a couple of my repositories publicly viewable here. So far it seems like it has more than enough features to replace Bitbucket.

Update: As of this writing, I turned my self-hosted code server off because I'm lazy.

I feel I should point out that this serves as a reminder to me (and to you, dear reader) that cloud services cannot be relied upon. Companies, even if you are paying them, can stop serving you. This is at least the second time I have had to replace a cloud service with a self-hosted solution. A few years ago I replaced Google Reader with tt-rss. Like I wrote previously, because my new Mercurial hosting service is self-hosted, no one will be taking it away from me. And that is good.

Finally, I don't know why anyone would choose Bitbucket now to host their code repositories. Without Mercurial, all it has it Git, and Github (which has obviously been Git-only from the start) has already won:

Github
Github

Bitbucket
Bitbucket


SSL-Enabled

With help from my friend, Chris, and the new Let's Encrypt service, this website is now SSL-enabled. Look to the address bar of your browser and you should see a green lock indicating that this website is fully encrypting all data sent to you. I know that this site isn't exactly Amazon or your bank (feel free to send me your credit card information, if you like), but encrypting the whole world wide web is a Good ThingTM.


New Hosting Service, Again

Two and a half years ago I moved my website off my father's computer at home to Site5. For a while it was great, especially compared to serving a website over a cable modem connection. However, over the last year or two it's gotten progressively worse, something I discussed in this post about a year ago. Also over a year ago, Site5 promised to move everyone to new servers. It hasn't happened, and my service has gone steadily downhill.

My first two-year prepaid period with Site5 went up in December last year, and I seriously thought about moving. I looked at other shared hosting companies, but I felt I would probably have the same problems on a new shared host. I looked into hybrid solutions, but that too didn't seem a guaranteed improvement. I liked the idea of Virtual Private Servers (VPS), but I couldn't find one with enough disk space in my budget.

A few months ago, my lab mate Rick pointed me towards s3fs, which intrigued me. s3fs puts your data on Amazon S3, but allows the data to appear to be local to the server, like another hard drive. You pay for only what you use with S3, and it has virtually unlimited space. Suddenly, a VPS hosting solution fit into my budget. I could pay for a VPS with less disk space than I needed, but still get the power of VPS. It was also an upgrade because now me and my family could upload as much data as we wanted, and it would be much more secure from disk failure than before.

This website and other sites that were on the old server are now being hosted on a machine from linode.com. I'm using their lowest option, which has 10GB of space. I installed Ubuntu Hardy Heron which seems like a solid Linux distribution. s3fs has proven to be reliable and fast enough, although it's much slower than having the data on a local disk. Using Apache rewrites, my father and I have made it such that when a web browser asks for items on a page that exists on S3, the request goes there instead from this server, which saves lots of time. I've also figured out how to shoehorn Gallery2 into using S3.

So far I am very happy with the new server.


Site5 Could Be Better

A week ago I saw a posting on digg about how Dreamhost sucks. It got me thinking about the problems I've been having with my account with Site5. Let me say that at no point has my experience been anywhere as bad as the one described in that link.

My hosting plan is on a shared webserver. Here is an informative page (broken link) about my machine, named iaso. It has four Intel 2.8Ghz Xeon processors, and four gigabytes of RAM. It runs Linux which is a solid server OS.

My big problem are periods when this very website is unresponsive. There are lots of other websites on the same computer. And by lots I mean on the order of 600 websites:

-bash-3.00$ cat /etc/passwd | grep -v nologin | wc -l<br />
646

The number of users with logins is not a one to one list of websites served, but it's probably a good estimate. All it takes is one of the 600 users with a bad webpage to clog up the machine.

Below is a plot of the load level for iaso over the course of 15 days last month. Without going into specifics, a load level of one means that there is one process needing a processor at any given moment. It will be many different processes, and that's fine. Practically, a machine can stay responsive with up to about a load of three or four per processor. So, on a four processor machine like iaso, a load level of 10-15 is about the highest comfortable level.

iaso

What you see above are many occasions when iaso went well above load levels of 25. The highest peak was a load of 230. In my experience, once the load reaches 25 my website becomes more than slow: it doesn't work anymore.

For comparison, below is a plot of the same thing on one of the nodes of the supercomputer I use, Datastar. This is the node where scientists do heavy-duty analysis on their datasets. For instance, I use this node to process my multi-gigabyte datasets using IDL. People also run Mathematica and other very computationally intensive tasks on this machine. It's got 32 1.7Ghz Power4 processors and 256GB of RAM (what do you have on your workstation, huh?). It runs IBMs AIX 5.3. As you can see below, for the first four days, the load level stays below one process per processor. In the fifth day something happens and it goes above 60 for a while, before the machine gets rebooted and things return to normal.

Datastar

The kind of processes that run on the two computers above are very different. However, the supercomputer is supposed to run big jobs and get beat on. A webserver isn't. Anytime the webserver's load goes above 25, it's like the supercomputer's load shooting to 256. At no time did the supercomputer shoot to 256, while the webserver goes above 25 many times. Of course, I'm comparing 15 days to 5 days in the two plots, but I think the differences are clear.

Site5 pays a third party to monitor their webservers, with results listed here (link broken). iaso (link broken) has 99.8% uptime overall and 99.4% over the last month. This is bad enough that apparently I'm due a 5% credit on my next billing cycle. iaso isn't even living up to Site5's own service standards.

Every time I catch my website being slow, I contact Site5 tech support. I know that this is a common problem with shared hosting. I'm sure that Site5 is aware that these outages, and does what they can when they happen. But, when it does happen, it's annoying. It shouldn't happen in the first place. Sometime this summer, Site5 is changing their hosting solution which may help with these problems. We'll see.


New Hosting Service

Hello from an entirely new server and address! The old steve.yikes.com (which equalled stephen.kicks-ass.net) is now stephen.phratry.net. The old site was hosted on my father's 933Mhz G4 using his residential cable modem connection (which was throttled to 40 kb/s for uploads). This new one is hosted by Site5 which offers feature-packed deals for not very much money.

You may be wondering what phratry means. According to Dictionary.com it means

  1. A kinship group constituting an intermediate division in the primitive structure of the Hellenic tribe or phyle, consisting of several patrilinear clans, and surviving in classical times as a territorial subdivision in the political and military organization of the Athenian state.
  2. Anthropology. An exogamous subdivision of the tribe, constituting two or more related clans.

Since I wanted to have other family members & possibly friends use this domain & hosting service, I wanted to think of a domain that wasn't too specific to any of us, but was descriptive. Although none of us are a member of a Hellenic tribe, the general idea is phratry refers to an extended family group, which describes the situation. I also kind of like the word because it's not very common and has an odd spelling.

The cool thing is everything is so fast! Downloading photos off of the old hosting situation was pretty painful. This should be much nicer.


Pages

  • 30 Years On
  • About Stephen Skory
  • My Cycling History
  • Solar Water Heater