now on git (and hosted on my laptop)

my blog has long been overdue for a new post, so here goes nothing. I haven't been writing lately for several reasons: the main one being that I've had difficulties with bashblog. also, of course, I have been busy with many things in the past few months, some of which I will cover in later posts. I have a lot to write about in the coming months; I'll try to get through it all when I have spare time.

so, bashblog. from my previous post about it, I described some of the changes I had to make to it for my own use. with my new patches, I found that editing old articles is almost impossible without incurring a headache, so my plan was to rewrite the entire script. and since I'd be rewriting it, might as well do it in a language I'm more comfortable with: perl. that was a big project I kept putting off, until one day I thought, "shit, why am I not managing it with a makefile?"

why use make? I first learned proper use of the utility, as well as how to write a proper makefile, when working on my chat client, achlys. I wanted to avoid anything such as automake or cmake due to their complexity, so despite lack of a clear makefile introduction, I went for it anyway, to my success. in addition to its usefulness for building C and C++ projects, it's also useful for its core purpose: smart file-dependency tracking. this is what makes it perfect for a website; the fact that I can write my entire site's content in markdown (what I've already been doing with my blog articles), write a few wrappers to generate the boilerplate HTML, and have it only touch files that would be updated. if I write an article like I'm doing now, I just save it, run make (and make check to ensure the output is conformant XHTML, before I push a broken copy of my website live), and it'll touch just this page, the blog index, and the atom feed. if I decide I want to add a link to the site sidebar, I can just modify the header template and make will generate my entire site. this has the nice side effect of avoiding server-side includes as well. now I don't have to worry about a lot of things; I can focus on writing content.

since it's all backed by git, I have a few benefits from this. I no longer have to sign blog posts individually; I let git take care of signed commits for me. this way, you can not only verify the post, but any edits I make as well. it's all preserved in the commit history for complete transparency, and for something like a mostly-static, archive-quality website, I find this invaluable. I also get natural backups of my site. of course there's the live site copy accessible over http, but also I get to keep a working copy on my desktop, which allows me to use the editing tools with which I'm comfortable, instead of being limited to whatever my server has. I don't like installing too much cruft on any server; the bulk of my convenience programs (such as vim) are at home on my desktop.

you can clone if you're interested in how I generate my site, if you want an archived copy (of the public portions) of my website, or if you want to mirror the site elsewhere (just be kind and link back to, please). I will soon provide access to my other projects on as well as a mirror on, and I will provide cloning instructions on for repositories, since I will not expose these repositories using an interface such as cgit or stagit. I am not really a fan of allowing code to be indexed over HTTP; anyone who is truly interested in my code can clone the repository directly. I will also provide release tarballs for certain projects (such as achlys) for those who do not have ready access to git on their system.

while you may have noticed I have been making changes to my website (the blog index received a makeover, for example, and web pages now have file extensions exposed), I have also made less-visible changes. one thing of note is that I am now hosting on my laptop. I am using quark HTTP server written by some of the people over at suckless, complete with a few bug fixes and modifications for my personal use (potentially more fixes as time goes on). quark is very lightweight, clocking in at just under 3mb memory usage at the time of writing this article. this setup is still served behind nginx, both to proxy my home IP since I still do not have an ISP suitable for hosting directly from home, and to cache requests in order to reduce load on my laptop. also, there are a few nginx-specific rewrites I have for my site, and I cannot yet find a good way to replace these. so for now, nginx still plays a role in my website, and that's fine since I use it for other sites anyway.

I am looking forward to fully self-hosting and all services located on my domain, to reduce my dependency on third-party hosting. it's my definitive home on the internet, so I may as well make it completely mine.

I also hope that others see the simplicity in what I'm doing here, and consider moving away from complex website frameworks, opting to roll their own in a similar fashion to what I am doing. I understand that not everyone may be a programmer or a web developer, but I believe that there are certain tools all of us need to know about, so that we can make the most out of our computers and our time. I can finally manage my site in a sane manner, visualise all its components, know exactly what will show up on the live site, because I am in control of every aspect of its generation. it certainly beats writing all that HTML manually.