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
Thursday, 24 February 2011
Sunday, 20 February 2011
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)....?
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 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
Friday, 11 February 2011
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)
Sunday, 6 February 2011
Airport Update 7.5.2 kills IPv6 Router Advertisements [NOT?]
[22sept11]: UPDATE: It appears that I may be wrong as I've now seen my machines automatically obtain an IPv6 address now (using an RS and receiving an RA). Possibly what was needed was a full power cycle of the Time Capsule to effect the IPv6 configuration.
After carefully managing to set up IPv6 on my Time Capsule using a manually configured tunnel I noticed that it had stopped working after updating to 7.5.2. I hadn't had the time to look into it before, but now I have it seems that 7.5.X has some kind of 'safety' feature that disables Router Advertisements (RAs) on your LAN when another box on your LAN is doing the DHCP (or RA) which seems DUMB. It should be configurable as alot of people don't use their TC as their main router box - since it only supports PPPoE. If someone's going to bother manually setting up a tunnel then they probably want to use it...
It seems that the Time Capsule reports this an "IPv6 Tunnel Error" - despite the fact that actual tunnel is up - so this error must be indicating it has had to stop the RA service.
I now have to manually add the IPv6 route to my hosts which make IPv6 a bit of joke on things like my iPhone or other devices I can't configure manually for IPv6.
Nice one Apple - just when we thought IPv6 was getting easier!
After carefully managing to set up IPv6 on my Time Capsule using a manually configured tunnel I noticed that it had stopped working after updating to 7.5.2. I hadn't had the time to look into it before, but now I have it seems that 7.5.X has some kind of 'safety' feature that disables Router Advertisements (RAs) on your LAN when another box on your LAN is doing the DHCP (or RA) which seems DUMB. It should be configurable as alot of people don't use their TC as their main router box - since it only supports PPPoE. If someone's going to bother manually setting up a tunnel then they probably want to use it...
It seems that the Time Capsule reports this an "IPv6 Tunnel Error" - despite the fact that actual tunnel is up - so this error must be indicating it has had to stop the RA service.
I now have to manually add the IPv6 route to my hosts which make IPv6 a bit of joke on things like my iPhone or other devices I can't configure manually for IPv6.
Nice one Apple - just when we thought IPv6 was getting easier!
Subscribe to:
Posts (Atom)