What do these latest Intel/AMD/ARM/etc CPU problems actually mean? Likely nothing for most users- provided nothing runs on your computer that you can’t trust.

So, what does this actually mean to you? If you are the only person to use your computer at one time- most likely relatively little, as long as you can trust the programs running.

These issues break down to this: If someone else is on your computer at the same time, they might be able to see what you’re doing in somewhat plausible conditions.

Still confused? Let me break it down a little more- for people who don’t have PhDs in nerdology.

If you were a child in the 1970s, or 1980s, you might remember those handheld walkie-talkie units that ran on batteries. If someone in your neighborhood had the same model- there was a good chance you could hear each-other when you weren’t talking to them, even if you didn’t mean to. If you were talking to your buddy in the treehouse, and someone else had one built similarly, they possibly heard you.

Were you an early 90s child rocking the bangles and HyperColor shirts? It was exactly the same, but for wireless landline phones.

This is what is possibly happening on your computer.

If you’re all there, nearby, and someone is “snooping”, there’s a chance that someone could “listen in”.

To come back to today: How you phone, tablet, Echo, or whatever- know when you talk to it? It’s listening to you. These people are evesdropping on it while it’s listening to you.

What these “patches” do is to essentially turn off the mic when you let go of the key, to return to a simplex analogy.

They essentially make it so that it can’t listen in; You have to press the button to tell it what you want it to do. It does slow down things quite a bit, but does make things more secure.

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.