Yes.

You read that right. I’m finally ditching my 2006ish design and will be updating to a more common flow than the deprecated blog-style (although it fits, er, my blog quite well).

I discovered several plugins I have used are not PHP7 compliant, and I don’t know how many I really wish to maintain- I gave up my own homebrew blog software in favor of TextPattern over a decade ago to avoid having to maintain my own code; I no longer had the time or inclination.

It might actually be time to rebuild with a new code base, rather than keeping these older tools running.

Just in case those of you who still use your handy-dandy VCR codes in the TV listings opposite the comic page aren’t aware, there is some rather simple mathematics used in the creation of the “VCR Plus” codes which inhibit it from working after 2049 – this is a recreation of the logic:

[...]
    g_year_today = year_today % 100;
[...]
	if (g_year_today < 50)
		g_year_today += 100;
	if (g_year_today < 1900)
		g_year_today += 1900;

So, in a very similar to the Y2K issue, VCR+ assumes any year after [YY]50 is 2000+, and any before that is 1900+[YY] So, we have less than 32 years before we’ll have to set the clock back 100 years on our VCRs to record our shows using numerical shorthand.

I hope that together we can bring awareness to his issue and address it accordingly before airplanes are falling out of the sky, and VCRs are recording Jerry Springer against the owners’ wishes! Make your newspaper aware, even if they haven’t published these codes in at least eight years!

One of the things that I’ve been using for nearly 20 years under X11 is John’s Bradleys’ infamous XV tool.

It’s had plenty of community patches over the years to add new formats (PNG, et al), and to handle multibyte languages. One of the things it hasn’t had- is a stable maintainer.

No, I’m not going to take it over- but I did fork a debian build with virtually all patches pre-applied. This made my life much, much easier.

I’ve built a nearly-static binary which should run on virtually any Linux/amd64 glibc based host with the stock X11 libraries; jpeg, tiff, png, et all are compiled into the program itself, so there’s no worry about mismatches between distributions.

$ ldd ./xv
	linux-vdso.so.1 (0x00007fff375e3000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fdbf8964000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fdbf8617000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fdbf8262000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fdbf803a000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fdbf7e36000)
	/lib/ld-linux-x86-64.so.2 (0x00007fdbf931c000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fdbf7c33000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fdbf7a2e000)

You will find the XV binary by itself here. Use xz to decompress, chmod it to execute, and enjoy. As with anything else, you might want to think twice before running any program you find off of a random website- there is no warranty, and sorry, I can’t help you if it doesn’t work for you.

If you aren’t aware – a bug that has persisted for over a decade has come to light with how speculative branching in CPUs (not only Intel, writers) can lead to people able to access others’ volatile data in kernelspace.

What this means, essentially, is that any multiuser system is inherently insecure for any local user access. This is not a good thing.

Patches have been made against the most recent Linux kernels, and should be installed!

If you are running debian stretch, for example, here’s a simple way to get “up to date” with the debian security branch (assuming you are running x86_64):

$sudo $SHELL
#echo 'deb http://security.debian.org/debian-security stretch/updates \
  main contrib non-free' >> /etc/apt/sources.list
#apt-get update
#apt-get install linux-image-4.9.0-5-amd64 iucode-tool
#wget http://ftp.us.debian.org/debian/pool/non-free/i/intel-microcode/\
intel-microcode_3.20171215.1_amd64.deb
#dpkg -i intel-microcode_3.20171215.1_amd64.deb && rm \
  intel-microcode_3.20171215.1_amd64.deb
#reboot

What this does is add debian-security to your apt sources, update the list, install the latest (stock) 4.9.x kernel with the patches against Meltdown, and install a current microcode patch – which only supports a few processors right now, but will likely be updated, so a subsequent update should pull in any future firmware patches.

Of course, this assumes a stock kernel/Debian 9 configuration. If you’re using stretch-backports, there is not yet a 4.14 release available with patches at the time of this post.

One of the annoying things about LetsEncrypt- if you run multiple zones from the same IP, it tends to make them Aliases of the primary zone.

Recently, I’ve worked to break away a couple projects from the primary zone, and it’s not gone all that well, with LE refusing to remove them or renew the other zones with those certificates still being part of the bundle.

So, I’m going to take one on the chin and rebuild all of the certs separately, which causes minimal more load for them, and a big headache for me.