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.

Older Entries: Newer Entries: Stuff from before Stuff that came after this