James Richardson
2017 Becomes 2018

Another year has past

Another year is in the books. I suspect it is now appropriate to look backward at what was accomplished, not accomplished, disappointments and maybe even successes. Perhaps it is also appropriate to set goals for the incoming year.

If I look at the blog posts I actually wrote last year, (which are conveniently listed in the sidebar), it seems I didn't do much, or perhaps there is no correlation between accomplishments and frequency of blog posts. I won't do that and instead say I did more things, just didn't write1 about them. Perhaps I will try to write about things more things. There is this wiki thing which may enable such.

What did I actually accomplish last year?

I've actually accomplished quite a few personal and family things, which I won't discuss here as, well, they are personal and not really any of your business. I've actually shut down my personal blog this past year.

I've also accomplished many technical and professional things. I actually gave a talk at SouthEast LinuxFest. The talk was more fun than I expected. It was also well received. Perhaps I'll do another presentation this year.

I've learned a new operating system, GuixSD. Well, it's not really a new operating system, just a different way of putting together a GNU/Linux system. I've also blogged about it.

Learning Guix also gave be a better appreciation of functional programming. I went on to learning Clojure and gnu guile. Still haven't learned Haskell. Maybe this year, maybe not. I'm still not a big fan of static typing and much prefer duck typing. Not saying I won't learn Haskell because of this, Haskell just seems weird to me.

So, what other technical have I done? I've managed build a system around fai to barf out Ubuntu images for $work and setup a system around reprepro for distribution of custom packages. I have possibly created a custom Ubuntu distribution of sorts, but that's for $work, so I can't talk about here. Not a big fan of Ubuntu anyway, much prefer Debian or Guix. I've also become rather proficient at creating Debian packages.

What shall I accomplish in 2018?

Well, won't really know that until 2019 ;).

  • I would like to give more talks at local conferences and meetups. Just don't seem to be many around here.
  • Become better with functional languages. Perhaps even start to understand CLOS or GOOPS.
  • Bring the infrastructure at the house in shape. Lot's of ideas, many half implemented. I need to fix this.
  • Finish the media server thing I actually started a few weeks ago.

  1. If a tree falls in the forest and no one hears it, did it make a sound -- If someone accomplishes a thing and tells no one, is it still an accomplishment? ↩

License: cc by-nd 4.0
James Richardson
I've Mostly Stopped Using GuixSD

Unfortunately, I've had to stop using GuixSD on my primary workstations and on my wife's laptop. As far as my wife's laptop, well she needed packages not yet packaged and I don't have time to package such things at this time. I had to go back to Sid or perhaps Stretch, I don't remember.

At any rate, I think now all of my systems (at least the ones that are actually running right now) are some flavor of Debian with Guix on top. Which is fine, I guess, but does cause some interesting interactions. I have Perl installed in Debian with an assortment of perl modules and perl installed in guix with it's assortment of perl modules.

My idea is that when I have everything I need as a Guix package I can uninstall the Debian one, eventually I can run GuixSD again, maybe. Debian packaging becomes interesting, and I still need to build able to create Debian packages, at least for $work. The Debian packaging tools, (pbuilder, debhelper and friends) rather assume a Debian host system, which GuixSD is not. I don't have a good solution for such yet.

I need to spend more time thinking on this.

James Richardson
System Updates and Configuration

Well, I find myself needing to update systems. I've written before about my (possibly) strange way of thinking about systems, and one would think using such techniques would make life simpler. And to a point it does. But GuixSD is still beta and does work well on managed vps systems1 or ?inside virtual box.

Configuration management

Systems upgrades are really just an artifact of configuration management. If I need to upgrade from wheezy to stretch, it should be just a matter of updating /etc/apt/sources.list, and running the normal apt-get update && apt-get upgrade && apt-get dist-upgrade. Of course enabling such magic requires everything is properly packaged. GuiSD is similar, one just has to run guix pull && guix package -u, still everything has to be packaged or have a package recipe. Guix packages are somewhat easier to create than debian packages, I think mainly because the entire package description is a single function definition2, but such may just be my perception. So things that are properly packaged should just work. Oh wait, what about configuration files and executables that need weird setuid or setguid permissions or data files that need special permissions to be secure or any of the above that need to adhere to PCI, SOX, or other regulatory requirements? Regulatory requirements are outside the scope of this post, as I don't have to worry about such things at the house or my vps systems.

My current thinking is if the packaging is done properly, configuration management largely takes care of itself. So the key then is to package things appropriately.


I largely use Debian with Guix on top. I have a few systems running GuixSD. Packaging applications that don't have configuration files is relatively straight forward in Debian and Guix and well documented, so I won't speak to those here, other that to say Debian has more things already packaged than Guix. ;) I'll start blogging about Debian packaging with the tag deb. Briefly, I am using pbuilder, git buildpackage, amongst other tools.

To help handle configuration, I've found config-package-dev which handles packaging configuration files sanely, by hooking into dpkg-divert so upgrades work out right.

To manage distribution of these custom packages I've built a debian package repository with reprepro.

That leaves things such as file permissions and drift. I suspect tools such as CFengine, Puppet, Chef and their cousins are still the proper tool for such a job. Although none of them work with Guix.

  1. At least on linode and presumably on other kvm providers. ↩

  2. By extension, then I would have to say creating rpms are easier than creating debs as the definition is in a single spec file. Scriptlets are still external. ↩

James Richardson
Oh Look, Now I Have Two Problems

Oh Look, Now I Have Two Problems

As I have mentioned previously, I have started working on a media server, which seems to have morphed into more of an UPnP/DLNA explorer. I guess that is fine, I've learned a lot, even have exploratory code. ;) I find I need a different UI, sure watching messages appear in a console or a REPL is okay to a point, but I need something a little, well, friendlier. I'm thinking maybe a web front end. I start thinking exactly how to go about doing such a thing. Surely this shouldn't be hard. Many have done this before. As I start thinking about this, I quickly remember Jamie Zawinski's quote which I will paraphrase as: Some people when building an application, think, "I know, I'll add a web front end." Now they have two problems. When I first started down this road, I was just intending to write a minimal mediaserver so that I could organize my media files on my fileserver like I wanted and have all the devices in my house that can stream media find it. All the devices already have a UI that interact with mediaservers so I figured I wouldn't really need a UI. I seem not to be smart enough to write a mediaserver straight from the specs, although if I actually knew how to interact with SOAP apis, I probably could have pulled this off.

Now that my mediaserver has morphed into an UPnP/DNLA explorer... Well, what good is an explorer type application without a useful UI?

So now I have to learn how to build a web front end1, or rather architect and application that supports a web front end. I'm thinking if the backend supports a RESTful (or rest-ish, at least) APIs, the front and back ends can be developed independently.

Think about designing a web front end is very foreign to me. UI/UX design is very foreign to me. I've decided that I want a grid layout, and should use one of the CSS frameworks2. Foundation and bootstrap seem to be popular and do what I want, or rather according to the documentation, they will do what I think I want. The latter being a very different statement from the former.

So now I have to sort out how to put this together in guile. I've not been able to fund much prior work, which is rather unfortunate. Perhaps I have opportunity to set direction, instead of just follow. I think one reason is the guile has just recently got a web server, but I'm just guessing. I did actually find a web framework, GNU Artanis, but I don't particularly like to the way it is structured and it seems rather opinionated. I also found a few projects guile-web, forward, and guile-websocket trying to do web things in guile. Not sure those actually fit my use case, but I have gleaned some ideas. I've also created a code repository.

  1. Well, I guess it doesn't have to be web, it could be curses or GTK, but this is 2018 and most devices (at least that can stream media) have a web client. ↩

  2. I have a problem. I know, I'll use a CSS framework. Now I have two problems, and a recursive blog post.  ↩