I just installed the Mac OS X El Capitan “GM” (golden master) release. I was surprised to find doing so had deleted all the historical log files from my
/var/log directory (e.g.,
/var/log/system.log.0.gz). I had been running the beta builds since they were announced. It is possible, in fact likely, that first beta build behaved the same way and I didn’t notice. Regardless it is pretty obnoxious for an operating system upgrade to delete files that cannot possibly impact the upgrade.
Not surprisingly, given how the /var/log directory was handled, the El Capitan GM release install also deleted every file in the /var/log/apache2 directory. The “upgrade” also replaced my custom /etc/apache2/httpd.conf with a generic config and didn’t even make a backup of the existing config. Jebus H. Christ on a pogo stick!
Thankfully I made a full backup using SuperDuper! before doing the upgrade so I only lost a couple of hours of Apache log data. I’m really disappointed that Apple doesn’t understand that deleting log files during an upgrade is stupid.
I appreciate the flexibility of Dtrace. But, at least on Mac OS X, the dtruss command is inferior to the classic truss command of UNIX System V that I’m used to using. Primarily because
a) You can’t run dtruss as yourself against a process you own. You have to run dtruss as the root user.
b) Using dtruss has a very noticeable impact on every other process even when tracing a specific PID (process ID). When I say “noticeable” I mean that UI events such as changing the window focus is noticeably affected. Which is unacceptable unless you are desperate to see what is happening within a specific process.
Even more annoying is that the standard dtruss command does not have any option for including wall-clock timestamps in its output. This makes correlating the dtruss output with output from the program being traced or other sources more challenging than it should be. Other people agree with me. Such as MadLab from which I based my own improvement to the Mac OS X dtruss enhancement.
A major problem with the solution by MadLab is that it relies on the brain-dead “printf(%Y)” specifier which has a resolution of one second and a format that isn’t easily handled by other programs; thus violating one of the primary tenets of UNIX programs. My solution is to also print the walltimestamp value using the “printf(%u)” specifier.
To make this useful enhancement simply copy /usr/bin/dtruss to a private directory in your $PATH. Then every place there is a
OPT_printid ? printf precede that line with these two lines:
OPT_wallts ? printf("%u ", walltimestamp) : 1;
OPT_wallts ? printf("%Y ", walltimestamp) : 1;
The other changes to add the
OPT_wallts option are fairly obvious but I include the patch below. This omits all the places where the aforementioned
printf statements would be added.
> # krader: This is the Mac OS X standard /usr/bin/dtruss modified to include a
> # -w option to display the wall-clock timestamp with each syscall.
< while getopts ab:cdefhln:op:st:L name
> while getopts ab:cdefhln:op:st:Lw name
< opt_printid=1; opt_cpu=1 ;;
> opt_printid=1; opt_cpu=1; opt_wallts=1 ;;
> w) opt_wallts=1 ;;
> inline int OPT_wallts = '$opt_wallts';
> OPT_wallts ? printf("%-21s ", "TIMESTAMP") : 1;
Update 2015-02-07: The OS X Yosemite 10.10.2 update broke the F710 USB receiver. See my latest post.
Update 2014-08-15: It turns out that the Xbox360Controller driver isn’t necessary. XCOM, and probably all Steam games, recognize controllers using the DirectInput API and work just fine with the Logitech when it’s mode switch is in the “D” position. Also, even after I hacked the source for the aforementioned driver to recognize the USB vendor and product IDs of the F710 it didn’t recognize it.
[end of updates]
I had an opportunity to play the game “XCOM: Enemy Unknown” on an Android tablet. It’s an impressive remake of a 90’s turn based simulation game for PCs. I just replaced my four year old 11 inch Macair laptop with the new 2014 model of the 13 inch Macbook with retina display. So I decided to get a copy of the game so my laptop isn’t just for work.
The next question was whether to play XCOM in K+M (keyboard plus mouse) mode or with a gamepad controller. After some googling I opted to pick up a Logitech F710 wireless controller from my local Fry’s store. I plugged it in and the OS X System Profiler app showed that it was detected.
More googling revealed that the stock OS X gamepad driver implements the older DirectInput standard. Fortunately the Logitech F710 has a switch to select either DirectInput mode or the newer XInput mode. Note the XInput mode is most commonly associated with Xbox 360 controllers. XInput mode is preferable because it is allows two of the four triggers on the controller to operate as analog rather than digital inputs.
To use a Xbox 360 controller (i.e., a controller which implements the XInput standard) requires the use of a third-party driver. This YouTube video describes the process as does this article at Cult of Mac. The driver can be found at tattiebogle.net.