How many times have grep’d a file, and then piped the output in order to grep again, and then piped that again to grep? Sometimes when I am search a file, I could end up piping maybe a dozen times while searching the file. Just for fun, I wanted to write a recursive grep program, rgrep in rust. However, as a first step, I figured I could write it in bash first.
As you may know, OpenBSD recently released version 6.5. With this new release, came a updated version of tmux, which has implemented a number of configuration changes that may require an updated tmux.conf. While -current has had these updates for awhile, I had simply ignore tmux’s warnings. However, since updating my systems to 6.5, I was finally complied and updated my conf.
I know it’s a simple program, but a few months ago I wrote a little python script to find prime numbers. The little python script was able to find all the prime numbers up to 10,000,000 in 2:40 minutes. I wonder if rust can beat that?
Following up on my previous posting about the programming language rust, I figured I may as well release the code I have written so far. It’s really been a fun journey, and I don’t claim at all to be a rust expert by any means, but here you go.
Recently, I started using a new language on the block: go. However, I found myself quickly reading about other new languages that have showed up recently within the last few years.
One such language was rust.
My original nfstest script on OpenBSD was tweaked for use on Linux recently. While modifying the script, I realized that there were some shortcomings to my original script.
Rsync was the original transfer method; however, after some testing and research, I realized that this method may have a little more overhead than originally realized.
At the behest of a fellow admin, who apparently digests solely rss feeds, and not content directly, my project this weekend became one to enable rss feeds within hugo.
Due to the relative simplicity of hugo, I figured that this task should be rather easy. Luckily, it was so.
Part two NFS performance tuning. I have some new data to publish. I reran the full NFS test, this time with the script transferring three files, with one sync and unmount in between the three transfers. I saw more interesting behavior that is worth noting, as well as publishing the script used to compile these logs.
Recently I’ve starting using my FreeBSD server as an active NFS server again, instead of just a giant file storage system for old pictures and docs. I prefer to keep as much data on a central storage system, that way, individual client machines can be rebuilt at a moments notice with no data loss.
Until a few months ago, my home desktop was running CentOS. Now it is a OpenBSD desktop running CWM, and I have noticed that the NFS client performance didn’t seem that great compared to the old Linux desktop. So, I figured it was time for some performance testing.
Since it has been a couple weeks since first starting to work with wireguard on OpenBSD, I figured it was about time to figure out how to get my OpenBSD desktop to act as a wireguard client. Who knows, perhaps this will one day allow me to drop my PIA VPN and shift exclusively to running my own personal VPN’s.
Well, I am no networking pro. I know there is a wg-quick script out there, but the couple of times that I tried it out on OpenBSD, it failed. I figured that there shouldn’t be that much to a wireguard tunnel, all I have to do is figure out how to establish the tunnel and force data out the tun device.