Written by: Robert R. Russell on Thursday, April 13, 2023.
I have been needing to digitize some old print documents.
Between trying both groff and LaTex to do that I do have a few thoughts on using
both of them.
If you have simple documents and you want a useable HTML output then use groff
with the MS macro set.
Don’t use the MOM macro set. It doesn’t produce reliable HTML output.
LaTex is better if you have a larger document or need more complex references.
LaTex doesn’t make things easier for outputing html though.
Written by: Robert R. Russell on Tuesday, January 24, 2023.
Why?
Short answer security updates in OpenWRT 22.03.3 and performance
problems related to
this bug.
After some indepth research I have two options, either use a git version of
OpenWRT until a new version comes out using a 5.15 or newer version of the
Linux Kernel, or I can convert the wrt1900ac over to a “dumb” AP and using
something else as the router.
I have decided to use OpenWRT on an older X86_64 machine as the primary router.
I am using OpenWRT both because it works and my assistant network manager is
only familiar with the OpenWRT interface.
Written by: Robert R. Russell on Friday, January 20, 2023.
Over the last few years I have been using various VoIP systems for work. So far
I have come to one conclusion about softphones. They all suck.
Everybody wants you to use their proprietary softphone. This causes two
problems. No support for standards and inconsistent features. The first is
the bigger issue in my opinion. It guarantees that you have to uses their
proprietary softphone app. Without the freedom of choosing your softphone
application you are stuck with the features your telphony provider provides.
Written by: Robert R. Russell on Thursday, January 19, 2023.
Why?
There are two reasons I am migrating over to Hugo from
Wordpress. The first has to with the decline in
support for the Classic or pre Gutenberg editor. The second has to do with the
lack of utility in comments versus the maintenance cost of Wordpress.
Since releasing Gutenberg Wordpress has slowly been migrating all of their
theming over to a collection of CSS files and a loop of php code that simply
prints the blocks HTML. All of the functionality is migrating over to JS
provided by the implementer of the block. This sounds like a good idea because
you don’t need custom themes for adding special stuff to the top of a page or
post. It does come with a problem though. If you like to write longer form
material Gutenberg is not easy to use. However, if you wanted to use a lot
multimedia inside your content Gutenberg is much easier than the Classic editor.
What about comments? Simple, a day or two before writing this I cleaned out the
comment spam folder. It had about 350 spam comments inside it. I have gotten
more positive interactions about a post on Twitter than I have ever gotten on
my actual website itself. There are a handful of websites/blogs that I read
with active comment sections. Active meaning less spam than actual comments.
That does not mean a high signal to noise ratio however. One of the sites in
particular could employee several moderators just dealing with civility and
personal attacks in the comments.
Given the two previous issues I am working on migrating the website over to
Hugo. It will take a few weekends for the migration to be completed. I also need
to figure out some best practices for handling a few large files I have on this
site without polluting the git history.
It looks like I am going to need to use a CDN for some files.
Written by: Robert R. Russell on Saturday, July 30, 2022.
The last few days have been frustrating. The good news is ZFS’s data protections
actually works.
A bit of backstory. I have a storage server for my home network. That storage
server previously had 6 hard drives in it. I used ZFS with in stripe over
mirrors configuration. With only 4 drives this is commonly referred to as
RAID10. One of the drives decided to start returning uncorrected read errors
earlier in the week.
After some emergency drive purchases on Amazon. I started a full rebuild and
migration of the storage array. Since, OpenZFS and
Fedora are a bit less cooperative than
Debian and OpenZFS, I decided to migrate the storage
over to Btrfs. An ongoing performance degradation of this storage array is also
responsible for the change. Btrfs has a data rebalance option which helps
maintain the arrays performance after a longer term of use.
The migration has mostly gone okay. I am still cleaning up a few loose ends from
some other maintenance on the storage server that was in progress before the
storage array became degraded.
I have managed to crash a Btrfs file system. No comments about Btrfs not being
production ready. ZFS wouldn’t have survived that mistake any better.
Written by: Robert R. Russell on Friday, January 14, 2022.
It is now a new year. With that comes job changes and other changes. Right now I
am working on a life insurance career. The job change is cutting into my time
for blogging.
Written by: Robert R. Russell on Saturday, October 30, 2021.
Some backstory
I have needed a tool to manage my local Ubuntu and Debian mirrors. Aptly is
probably the best tool available to do the job right now. However, none of the
available tools are actually great. Most are in varying degrees of
non-maintenance or throw out hordes of errors because they look for every file
variation even though the Ubuntu and Debian mirror creation tools only release 1
or 2 variations.
Why the new tool?
Since I run several physical and virtual machines on my local network, I need a
local software mirror. I am also packaging a few updated or tweaked Debian
packages, so I need a storage location for those packages. As a result, I am
mirroring the stable and testing versions of Debian, and all the versions of
Ubuntu back to the current LTS, Focal Fossa. Add to those a few extra
repositories I mirror, PPA’s basically, and my maintenance scripts are getting
ridiculous. I am getting tired of directly modifying that massive pile of shell
scripting every time a new distro release happens. To help with that, I have
released a new tool that will create the non-PPA chunk of the shell scripts from
scratch.
Why Rust?
After trying to build the same piece of software in Go, PHP, and actual proper
shell, this time, I decided to try Rust. The result was pretty interesting.
Importing dynamic data structures from any configuration file sucks. While I
spent about 12 hours figuring out that the TOML would take longer than I
originally wanted to implement. The hard-coded configuration took about 16 hours
to build and test. You can get a copy from
(https://github.com/rrbrussell/aptly_manager).
I would describe using Rust so far as enjoyable frustration. I use a code, run,
evaluate, repeat development cycle. While cargo build is not as fast as go
build, it is quick enough that I can work at a fairly productive rate. When I
understand the language in front of me. The completion of the first sub-command
to the final v0.1.0 took about one, maybe two hours. I rapidly completed the
last part compared to the fourteen or fifteen hours I spent bumbling around
parsing command lines and figuring out Rust’s borrow checker.
Again Why Rust?
I am more familiar with Go, PHP, Java, and C# now than with Rust. However, even
accounting for the learning curve, I prefer Rust. First off, it integrates
better into Linux than C# or .NET. This would not be a big issue, except I like
using one language for most tasks, and it appears to be easier to get Rust and
GTK working on Windows than C# and GTK working on Linux. There are a couple of
larger projects that I have on the back burner. My options for those projects
boil down to three options
using PHP for the back end, with a .NET UI,
use .NET for both the front and back ends,
use Rust for both the front and back ends.
Go unfortunately does not work for any of the options because it does not
support dynamically loaded plugins or have a useable GUI library available. Rust
may not fully support dynamically loading plugins, but it is probably as safe
and idiot-proof as Go and supports generics. Rust supports C’s foreign function
interface natively, so the worst case is I may write the plugin management code
in C and everything else in Rust.