The true origin of "the NUXI Problem"

A bit of computer history today.

The Cathedral and Bazaar website defines the NUXI Problem and various other web pages have elaborated on how it is due to endianess of the CPU interacting with data transfer.

All well and good, but the name given to the problem dates from before data transfer. In those days, telecommunications was slow and data transfer was by magnetic tape. So it wasn't due to encountering problems with FTP or something like that, Internet Protocol had not come to Unix yet.

Rather it was named after the glitch observed on the console upon booting up a port of Unix V6 to, my unreliable memory tells me, the Interdata 7/32. The ports were done independently at two places, Bell Labs and University of Woolongong. Here is the story from the veteran of the UW port.

The PDP/11 is little-endian and the recipient of the port was big-endian so when Unix V6 booted up, the message on the console was supposed to be:

UNIX V6...

which came out as:

NUXI...

Obviously a fix had to be applied to the order of bytes within words in compiler generated code for C strings.

I don't know which team encountered this symptom first. The tale was told to me by Piers Lauder, the Unix guru at the time at Basser Dept. of CS at the U of Sydney.

Ancient EPROMS: 2516, 2716, 2532, 2732

I needed to burn a 16kb (2kB) EPROM as part of a restoration project on an old piece of equipment. When I couldn't burn the EPROMs on my TL-866 programmer, I started investigating. Here's what I found out, summarised for your benefit.

Programming voltage

Practically all EPROMs of this era require 25V programming voltage. That's why my TL-866 couldn't do it, it failed on the first byte, it can only go up to 21V. I can understand why it's not supported, only a tiny fraction of chips require 25V programming. Maybe your programmer supports 25V. However some parts suffixed with A are 21V programmable so try that voltage first. I didn't have any A parts.

Pinouts

This article goes into detail about the differences. To summarise:

For the 2716, the Texas Instruments equivalent is 2516. The TI 2716 is a different beast, fortunately quite rare.

For the 2732, this time TI came out with the 2532, with a different pinout from the more widespread 2732. So TI 2532 != other 2732. Again my programmer cannot program 2532s, not just insufficient voltage but different algorithm too. If you need to only read them, say you want to put 2732 EPROMs in a machine using 2532 EPROMs, it's possible to make an adaptor that reroutes three pins. The article is only for subscribers, but if you click on the PDF image of the PCB, it will be obvious what they have done to the three pins 18, 20 and 21.

From the 2764 onwards, TI fell in line.

EEPROM substitutes

So I had no programmable EPROMs in my spares box, but fortunately I had a Xicor 2816 which is an EEPROM with pinout compatible with the 2716. It speeds up my development too as I don't need to go through the UV erase step.

28pin to 24 pin adaptor

If you can't get hold of a suitable chip or programmer, another way out is to build an adaptor using two IC sockets and patch wire so that you can use the much more widespread 28 pin EPROMs (2764 and above). Fortunately I don't have to do this (yet).

pdftk cannot open some protected PDFs

I receive some documents as protected PDFs. I got tired of inputting the password every time I viewed them with okular so I decided to batch unprotect all the ones I have. This is on a computer which only I use.

I tried the recommended pdftk command:

pdftk protected.pdf input_pw secret output plain.pdf

but it kept telling me OWNER PASSWORD REQUIRED. Eventually I decided it was pdftk's fault, not mine, so I switched to qpdf, using the command:

qpdf --password=secret --decrypt protected.pdf plain.pdf

and that worked.

A web search showed various complaints about this. I haven't investigated when or why the problem occurs.

Perl complaining about not being able to set locale?

If you are getting this error when running Perl, usually from a ssh session:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
       LANGUAGE = (unset),
       LC_ALL = (unset),
       LC_CTYPE = "en_US.UTF-8",
       LANG = "en_AU.UTF-8"
   are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_AU.UTF-8").

You are missing the locale mentioned in LC_CTYPE. Run:

dpkg-reconfigure locales

select the missing locale, in this case en_US.UTF-8 and generate it. Voilà, error fixed.

crond runs /bin/sh not /bin/bash

Got caught by this today. Cron jobs normally run /bin/sh, not /bin/bash. It's probably required POSIX behaviour.

Normally most commands run out of cron are not affected because they are not dependent on bash, or the shell script starts with #!/bin/bash. However commands like vncserver which start up desktops (e.g. with the @reboot time spec) can be sensitive to the shell used because of environment scripts in /etc/profile.d.

Therefore if you want to ensure that the cron job works the same whether run interactively or from a crontab, specify the shell. E.g.

@reboot SHELL=/bin/bash /usr/bin/vncserver ...

VM in VirtualBox using unbound WiFi interface on host

I have a Linux host with 2 interfaces, a wired gigabit Ethernet and WiFi. Currently only the wired interface is connected. I wanted to experiment using WiFi interface by a VM guest in VirtualBox. There are various scenarios for this. I might want to test network routing by using the WiFi in conjunction with a smartphone offering tethering. Or access the Internet using from a VM on the desktop using the smartphone when the broadband connection is down.

The short answer is yes, this is eminently possible. The key points to take away are that, 1. the host has to configure the WiFi interface, i.e. load the appropriate driver and authenticate to the access point but not assign an IP address to it, and 2. the guest has to use bridging to access the host's WiFi interface. In fact it will appear to be a wired interface to the guest. All the usual IP configuration methods are available, static or DHCP, depending on what the access point allows. Also note that the MAC address seen by the gateway will be the MAC of the guest, not the MAC of the WiFi interface.

XFS partition created under CentOS 7 cannot be mounted on CentOS 6

Found this out the hard way. Error message is invalid FS type, i.e. not backward compatible. You have to backup the contents and restore to a partition created under CentOS 6.