June 30, 2014, 3:54 p.m.
I've got a Moxa U1610 connected via USB to my Dell XPS Developer Edition laptop, which I've upgraded to Ubuntu 14.04 (kernel 3.13.0-29). The drivers on the Moxa site do not work with a kernel this new, nor do the beta drivers you can find floating around on the web. Here are the steps that worked for me: 1. Get the latest source for the kernel (I got mine from here: https://github.com/torvalds/linux/blob/master/drivers/usb/serial/mxuport.c) 2. Download the tarball for Ubuntu 14.04 and unpack it somewhere. 3. Copy the mxuport.c kernel module from the Linux source to the drivers/usb/serial directory in your copy of the Ubuntu source. 4. Run "make xconfig" or the equivalent in your copy of the Ubuntu distribution and make sure that kernel modules are enabled, and the mxuport kernel module is enabled. What I found easiest was running "make xconfig" and searching for "mxuport". 5. Save the configuration and run "make" from the top of your Ubuntu distribution. 6. When the build is done, copy mxuport.ko from the same Ubuntu drivers/usb/serial directory to your local /lib/modules/3.13.0-29-generic/misc directory. 7. Run depmod as root. 8. Run "modprobe mxuport" as root. 9. Run dmesg and confirm the module got loaded.
June 20, 2014, 10 p.m.
I was able to boot from a USB I created using UNetbootin (http://unetbootin.sourceforge.net) on my Mac. I used the USB stick to install Windows 8.1 on a Dell XPS 13. I didn't have to do anything after UNetbootin to get the USB drive to boot. Ubuntu 12.04 and Tuxboot did not create a bootable stick. I tried both the legacy and UEFI options on the Dell, but it's like the stick wasn't there. Once I tried UNetbootin on the Mac, the USB drive showed up automatically as a UEFI boot option.
March 28, 2014, 12:43 a.m.
After upgrading to OS X 10.9 and LLVM 5.1, I've been fighting an error when compiling: err: clang: error: unknown argument: '-mno-fused-madd' [-Wunused-command-line-argument-hard-error-in-future] The fix is to run export CFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future in your shell to turn the error into a warning.
Oct. 22, 2013, 8:03 a.m.
I had a stored proc that returned in a few seconds when run in SSMS, but kept running for 10-15min plus when executed from the context of a console app or web service. One of our DBAs showed me that forcing a recompile of the proc every time would fix the issue. The proc is using the BETWEEN keyword in a WHERE condition to return a range of rows. When SQL Server knows the parameter values at compile time, it can optimize the query plan. It turns out that creating dummy variables in the proc and setting them to the value of the parameters being passed in forces a partial compile. This is called parameter sniffing. Read the article below for more info. http://www.sommarskog.se/query-plan-mysteries.html