Here’s a quick bash script I used to generated a “vanity” PGP key with the last two bytes (four characters) set to FFFF. #!/usr/bin/env bash while : do gpg --debug-quick-random -q --batch --gen-key << EOF Key-Type: RSA Key-Length: 2048 Name-Email: user@domain Name-Real: Real Name Passphrase: yourverylongpassphrasegoeshere EOF if gpg -q --list-keys | head -4 | tail -c 5 | grep FFFF then echo Break exit 1 else gpg2 --batch -q --yes --delete-secret-and-public-key `gpg -q --list-keys | head -4 | tail -n 1` fi done I also added no-secmem-warning to ~/.

The C programming language has no built-in garbage-collection mechanism – and it very likely never will. This can (and does) lead to memory leaks by even the best programmers. It is also an imputes for the Rust language. However, depending on your use-case, it is still possible to structure your code to use the stack as a sort of zero-cost “garbage collector”. Lets jump directly into the code! This is how many applications instantiate and utilize a structure or arbitrary object.

I needed some code that produces SHA1 digests for a project I am working on. I hunted through the FreeBSD’s sha1(1) code and produced this minimal snippet. Hopefully this helps someone else in the future.

Warning: This is a hack that involves modifying the build scripts. tldr; modify /usr/src/sys/conf/kern.pre.mk to change all references of -O2 to -O0. Have you ever had dtrace(1) on FreeBSD fail to list a probe that should exist in the kernel? This is because Clang will optimize-out some functions. The result is ctfconvert(1) will not generate debugging symbols that dtrace(1) uses to identify probes. I have a quick solution to getting those probes visible to dtrace(1).

In my third installment of FreeBSD vs Linux, I will discuss underlying reasons for why Linux moved away from ifconfig(8) to ip(8). In the past, when people said, “Linux is a kernel, not an operating system”, I knew that was true but I always thought it was a rather pedantic criticism. Of course no one runs just the Linux kernel, you run a distribution of Linux. But after reviewing userland code, I understand the significant drawbacks to developing “just a kernel” in isolation from the rest of the system.

Even with our modern technology, hard-disk operations tend to be the slowest and most painful part of any modern system. As such, modern operations implement buffering mechanism. In this schema, when an application calls write(2), rather than immediately performing physical disk operations, the operating stores data in a kernel buffer. When the buffer exceeds a certain amount or the when an application falls the fsync(2) system call, the kernel begins writing to the disk.

I am currently working on expanding FreeBSD’s rtwn(4) wireless device driver. I have the basics down, such as initialization, powering on and off, loading the firmware, etc, and am now trying to fill in specific ifconfig(8) methods. This requires having an in depth knowledge of how ifconfig(8) commands pass are ultimately delivered to the driver. I could not find concise documentation that outlines each stage of the process. So I wrote one!

This is the tale of how I reverse-engineered a Motorola CPS radio protocol to make it work on Linux. While this may have been of questionable legality and thus lost interest in the project, I learned a lot on how to reverse engineer. I’m writing this entry more than a year after I initially did this, so I may be a little rusty on the details, but this is the gist of it.

I love FreeNAS. Its awesome, well built, well-supported. But as my needs increased, I wanted to use my FreeNAS box for more than the basics. In particular, I was moving towards a single host to run as a: Family NAS server Development server IRC client VM server Web server Email Server Git Server Home Firewall Home IPv6 gateway IPv6 VPN and Jump box FreeNAS could easily do all of this. But I found myself using the device for everything but a NAS server.

I am currently writing a FreeBSD device driver and find myself lugging around the entire src. As you can imagine, this is quite large, especially if you are using any sort of version tracking system. So following the example here, I extracted out: /usr/src/sys/modules/rtwn/ /usr/src/sys/dev/rtwn/ into /home/user/src/rtwn/sys/modules/rtwn/ /home/user/src/rtwn/sys/dev/rtwn/ However, when I ran make(1) in the /home/user/src/rtwn/sys/modules/rtwn, I received an error saying: make: don't know how to make r92c_attach.c. Stop This error message is extremely non-descriptive of the actual issue.