Sorting out clock wierdness on dual boot Windows and OSX/Linux

I just installed Windows 7 on my MacBook and Windows STILL stores the local time in the hardware clock (as opposed to UTC) so when you reboot between the two OSes the time changes - dang! It turns out that there's a secret registry key that gets Windows to behave 'normally' in this respect. You just need to add a new DWORD key, called RealTimeIsUniversal (which should be set to 1), at the following place in the registry (and then reboot to make it take effect):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

Here's all the details from a man who knows....

Google Chrome: SPDY (Speedy)

So Google have now deployed their 'go faster' SPDY (Speedy) web page delivery protocol - which is not only in Chrome but also running on various Google services including gmail.

Google's performance figures on SPDY look good - and I think their figures are impressive. So if you want speeded up Google services then run Chrome!

There's all the dirt on SPDY here and of course they have a 'magic' URI/URL you can tap into your Chrome browser to see the internal stats:

about:net-internals

So how radioactive is it in Tokyo?

Maybe you're wondering what the actual figures are - well you can watch them (uSv/hr) change (FYI I looked at it a week ago and it was 0.14uSv/hr - it is now 0.24uSv/hr) live on this live feed of a Geiger counter (a RADEX RD1503) located in Tokyo:

Live TV : Ustream
For the latest on the reactors check out daily updates from Japan's Atomic Industrial Forum.

OSX environment variables

Where are those pesky things kept - as usual Apple like to keep us guessing....Whilst the folks at Stackoverflow provide answers:

• ~/.profile, ~/.bashrc, (~/.cshrc, ~/.tcshrc) - depending on what shell you're running
• ~/.MacOSX/environment.plist - More for GUI stuff
• /etc/launchd.conf - used globally by launchd (can be set per process using launchctl setenv)
• /etc/paths - just for setting the PATH

Windows networking: interfaces

So have you ever wondered where Windows configures the some more obscure networking things like the length of its outgoing interface queue? (It's ok if you haven't ;) Anyway if you have then here's the dirt:

• The actual maximum size of the queue (cf Linux's txqueuelen) is set in the registry:
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{...your  GUUID here....}\ForwardBufferMemory which defaults to 50 packets (ok for 100Mbit Ethernet but not so good for Gigabit speeds...)
• For the above config to work you need to enable router mode:
  HKLM\SYSTEM\CurrentControlSet\Services\Parameters\IPEnableRouter=1
• In principle you can monitor the length of the output queue interface using this API

There's a various places that offer advice on improving performance like, Microsoft, and speedguide (win7). Windows 7 even provides special networking/scheduling support for multimedia apps.

Handy command line based Windows network tools: ipconfig, netsh

Hard disc full again?

Yeah even if you've got GigaBytes of it you still seem to run out! Here's a few free tools that are good for visualising used space - using a nice visualisation technique known as treemaps:

Windows: WinDirStat, SequoiaView (a bit old)
Mac OSX: Disk Inventory X, GrandPerspective. (Baobab is available thru darwinpaorts)
Linux: Disk Usage Analyzer (aka Baobab)

There's also plenty of others out there but I've not tried 'em.

Updated: 1jul15

Using the Linux tbf qdisc for rate limiting on local or loopback interfaces

If you have ever played with the Linux tbf (Token Bucket Filter) on either some local interfaces, or on the loopback interface (lo) then you may have run into problems - like the attained rate is only a few hundred kilobits/s or less (zero)....?

tc qdisc add dev lo root tbf rate 10Mbit burst 10kb latency 5ms 

Basically if your interface has TSO/GSO enabled (check using ethtool -k ethX), or you're using the loopback interface - then you'll probably hit a problem. It turns out that the loopback interface has GSO/TSO enabled as default, plus since it is a software interface its default mtu is 16384 (as compared to 1500 for normal Ethernet interface). This matters as the tbf queue checks the size of the incoming 'packets' - which in the case of GSO/TSO are much larger than a normal on-the-wire packet - instead they're up to 9 x iface's mtu. So for normal interfaces it's about 12K, but for loopback it is about 100k!

In which case you'll need to add the 'mtu' argument to the tc command and then it might work( but check update below in case not):

tc q a dev eth0 root tbf rate 10Mbit burst 10kb latency 5ms mtu 100000

Update [29jan20]: It is also important that the burst parameter is greater than the MTU (you will see warnings in dmesg to this effect if your burst size if too small) if running on an interface that has a large MTU like the loopback interface which is now commonly set to 65535 :

tc q a dev eth0 root tbf rate 10Mbit burst 70kb latency 5ms mtu 100000

Python obfuscation

Well there's plenty of talk out there about Python obfuscation. But basically its frowned upon by most, and not that easy (though that's really the case for most languages). But if you'd like to make it a bit harder for people to rip-off your code, then these seem to be the ways to do it:

• Compile Python code into .pyc - using Python's in-built compileall module - in your code dir run (then delete all your .py files and you can run the .pyc files):

  python -mcompileall .

• Use [cx]Freeze (or py2exe) to compile your Python project into an executable
• Use a Python source code obfuscater like this one or that (both a bit old)
• Use cython instead of Python
• There are some commercial products out there too (e.g. this)