I’m starting this series about my homelab. It’s an easy thing to blog about and I really want to start getting more content out on this site. Finally, for purely selfish reasons this will work as a good journal of “why” I’ve done some of these things which I’ve used this blog for in the past. Today we’re going to cover how I host the homelab and I went with the boring option: Proxmox. Proxmox is a hypervisor built on KVM and Debian Linux. It’s enterprise grade but free. Why Proxmox I tried lots of solutions to avoid actually using VMs like Fedora Server + Podman, NixOS, etc. All in all I was never gonna escape running some VMs and Proxmox is the best most robust solution I could find in the price point of free. It’s not totally without issues but it’s well documented and supported.

As part of the 8.0 pre-release announcement, the OpenSSH project stated that they consider the scp protocol outdated, inflexible, and not readily fixed. They then go on to recommend the use of sftp or rsync for file transfer instead. Many users grew up on the scp command, however, and so are not familiar with rsync. Additionally, rsync can do much more than just copy files, which can give a beginner the impression that it’s complicated and opaque. Especially when broadly the scp flags map directly to the cp flags while the rsync flags do not. This article will provide an introduction and transition guide for anyone familiar with scp. Let’s jump into the most common scenarios: Copying Files and Copying Directories. Copying files For copying a single file, the scp and rsync commands are effectively equivalent. Let’s say you need to ship foo.

I have a problem. My problem is that I like Macbooks, but I don’t like macOS. macOS is just enough like Linux to feel familiar but different enough to make that feel like an uncanny valley and frustrate my workflows. So anyone who has read this blog knows that back in 2018 I switched to a T480 and couldn’t have been happier. Couldn’t have been happier is probably an overstatement. I hated that hardware. The keyboard was excellent, because that’s what ThinkPads do, and I was coming from MacBook. Still, everything else (especially the screen) was atrocious. I recently did a stint in England, where I was forced to use that laptop as a laptop for 3 weeks. The entire time I was daydreaming about having my Macbook with me instead. This experience motivated me to seek out other options. I needed a machine that could replace or be better than my Macbook in terms of hardware but run Linux.

The other day I had the idea to do what I suspect, is a weird thing. I wanted to bind keys to other key’s characters in Emacs. This led me on an interesting journey through the Emacs source code until I finally found a solution. But Why I’m a software developer, so I hit a lot of keys. One of the reasons I love Emacs (+evil) is that it allows me to minimize the amount of keys I need to press to complete common actions throughout the day. I have hand problems (not related to Emacs, I swear). This means I sometimes go to extreme lengths to remove key presses for common actions, especially those involving pinky usage. It recently occurred to me that, during my day, I type *, (, ) and " far more often than their “unshifted” counterparts, or at least I do when typing code or documentation.

Vagrant wrapper allows you to store a single Vagrantfile in a predefined location $VAGRANTW_DIR and use that across multiple projects with ease. Think like the popular virtualenvwrapper but for Vagrant. An Example Let’s say for instance I have a project that looks like the following: ./example └── main.c 0 directories, 1 file And I need to test if it compiles on Ubuntu when I’m running on a Mac or Fedora. In this situation you have a few options: Spin up a VM using Vagrant The problem here is then I’d have to add a Vagrantfile to this projects repo and either commit it or Gitignore it. This becomes more arduous when you have multiple projects like this since you have to maintain a Vagrantfile per project. So our project looks like this: ./example └── main.c └── Vagrantfile 0 directories, 1 file Use a docker container The problem with docker containers is shared with that of the above solution of ‘Vagrant per project’.

As anyone in my proximity knows by now, I bought a new laptop. I’m kind of excited about it since it’s been a year, which is a long stretch for me (I have a problem I know), since I bought a laptop. To put some context on this review I think a little back story is in order. If you don’t care about the backstory and just want the review, here is a handy link Backstory So for about 14 years I’ve been Linux user. For the first 8 I was a part time, read: dual booting, desktop Linux user. For the last 6 I was full time Linux on the desktop / laptop. That is until last year. Last year I moved to New York City from Cincinnati to work for MongoDB. Ironically, while this was a dream come true in that I would now get paid to work on Open Source it came with some challenges.

The Beginning of an Obsession Anyone who has been in my vicinity for than 5 minutes will know that I LOVE Emacs. More than any man should reasonably love any program, let alone a programm from the 70’s. I spend countless hours tweaking my config (and yes I use Spacemacs, which is still customizable), and I’m a frequent attendee of New York City Emacs. The thing that I love most about it is how customizable and programmable it is. Since, I spend most of my day interacting with text on a computer having a platform for automating text interaction allows me to remove a lot of pain from my day. Unfortunately many people I preach to don’t quite understand how this can be a benefit. Today, I’m going to document a use case where the power of Emacs saved me hours of programming.

I went to Kansas Linuxfest this weekend and had a fantastic time. I decided to post my notes to the website just in case they’re useful to anyone else. This won’t be a great post to “read” but, if you’re curious about the kind of topics and things you can learn at a Linuxfest this will give you a pretty good idea. The Git Historian by Aaron Sumner Take Aways git log –grep searches commit messages git log -S searches changes / code in commits git log has a ridiculous amount of other ways to search You can use git log with any pager Use rebasing to reduce commit noise and combine many commits that you didn’t mean to separate git commit –fixup git commit –squash git rebase –autosquash Project Caua by Jon Maddog Hall Jon “Maddog” Hall is starting Project Caua, which allows young people in Latin America to use their entrepreneurial talents to build a business and sell it to fund their schooling and the next generation of project Caua students.

This post is for people wanting to start a FOSS project. Specifically a FOSS project which is bigger than a weekend hackfest. Though most of the advice applies there pretty nicely too. I’m going to assume that you have some idea of what you want to build. If not this post will still have some value as it will give you ideas of how I came up with building Praelatus. The Why What makes you want to build something? Change the world For fun To replace something you hate To satisfy your own itch To learn a new technology To make money Why are you making whatever you’re making? A large part of my day job right now is supporting a JIRA instance and I hate it with a passion. It’s slow buggy and I spend an inordinate amount of time reverse engineering it to fix it.

So anyone who knows me will know that I love tools that are configured with dotfiles. Generally I find these tools are more powerful and faster than their (generally) graphical counterparts. I love dotfiles so much that I even wrote a tool to help me manage them: DFM. With all that said I’ve spent many years and hours tweaking my dotfiles and after sharing them with my good friend Chas Busenburg he remarked at how much useful stuff was in my bashrc. I had never really thought about it, I see it as piles of hacks and duct tape, but it does have quite a few useful functions and tricks probably unknown to many Bash users / enthusiasts. So it is on that note that I welcome you to the guided tour of my bashrc. If you’re looking for the full version for reference you can find it with the rest of my dotfiles here.