[Technology] .htaccess and unsavoury IPs

http://www.htaccess-guide.com/deny-visitors-by-ip-address/

What happens when a small set of Asian IPs try to exploit possible (but absent) vulnerabilities in your website?  Deny their IPs access. :)

[Technology] eMusic and Linux

I like emusic.  It's my preferred source for music, in part due to their costs, but largely in part due to their philosophy.  They have occasionally had Linux clients, and was one of the first large music stores to eschew DRM on its tracks.



Recently, they've updated their site and their download client, and now its Windows-only.  When you go to purchase a track now, it asks you to accept an agreement (you can set it to not ask again) which is fine, and then it prompts you to download the eMusic download manager (for Windows).  If you're on Linux, even if you use Wine, eMusic won't let you go further.  It wants the installed download manager to send you to a web page to confirm that it was installed (and for some reason, even with Wine, that does not happen).



The solution for me is to

• continue using emusicj on Linux


• follow Matt Woodward's advice and let emusic believe I've installed their download manager by visiting www.emusic.com/dlm/install/


• then click to complete purchases as per normal. 

[Technology] Testing for memory leakage with Vala and GLib

For my thesis, I implemented my algorithm in Vala, in part because I want practise, as well as because the candy of a high level language can theoretically expedite implementation, while the nature of Vala being compiled down into C helps avoid the penalties of running code in a run time.



Vala manages memory for you mostly using reference counting.  This is mostly invisible.  Running my experiment the other week revealed a large amount of memory leaking.  I shuddered, and realised I'd have to analyse it and create tests for this.



I used the GTest framework and  malloc.h's struct mallinfo and mallinfo () to calculate memory usage before and after various blocks of logic.  (I mostly just encapsulated calls to functions + setup.)  I also occasionally used valgrind and gdb.  My methodology was to start at the highest level functions and measure memory leakage.  Then, if one was detected, I'd create new tests narrowing down the source.  This was sometimes arduous as I started learning how GType and GSlice worked.



First, the first time you use a type in GLib, there's often a bunch of memory allocated that will (as of late apparently) never be freed.  That's fine, because it's a one-time penalty and it's necessary.  To avoid having these allocations cause a test to unduly fail, I ended up with "priming" code before a lot of tests ran, that would simply invoke types for their first time, so nothing new on that account would have to be allocated during the time.



Second, after reading about how to use valgrind on GLib applications, I started to learn about GSlice.  GLib encourages the use of the GSlice memory allocator instead of g_malloc () or malloc ().  The idea seems to be that it will reserve a large contiguous block of memory for you to play with, that won't be released back to the system any time soon.  That way, if you would normally allocate and deallocate space many times quickly, you save on the cost of actually reallocating it, since you never really let it go.  That sounds great; but for the purpose of testing, I really want to measure only the memory the system is actually using, not how much I am prudently reserving.  To work around that, I set an environment variable G_SLICE=always-malloc.



Third, I encountered what may be a bug in Vala's code generation.  Bug 684182.  When using asynchronous methods, the generated C code that calls g_simple_async_result_new () passes a brand new GObject to it a a source without ever unref'ing it, so every time you run an async method, you lose 32 bytes.  Also, there is occasionally an additional 16 bytes lost in relation to running them, but I haven't narrowed down where that came from.  The 32 bytes are relatively negligible for my purposes, but it was still resulting in failed tests.  Consequently, I now define a margin that memory leakage can fall within for a test that will only result in a warning and no failure.  My margin is 32 bytes * # of async method calls + a possible 16 bytes.



Fourth, I discovered an actual issue with some of my code.  I ran into a reference cycle in my code.  Referring back to the ever-useful Vala referencing handling page helped me understand what I needed to do for that.  I made sure that the appropriate references had the "weak" modifier attached, and all was well there.  For a given use case, this reduced memory consumption from 681kB to 546kB. (Both with the TreeSet fix below.)



Fifth, the most significant issue I encountered wasn't a problem with my own code but a memory leak in libgee before version 0.8.5.  The current stable libgee in Fedora 18 is only 0.8.1.  It has a memory leak in TreeSet where the free method for the TreeSet's members is never called so all elements added to a TreeSet are leaked.  That is incredibly expensive as I use TreeSets a great deal.  Upgrading to 0.8.5 resolved this, and reduced memory consumption from 26,402kB to 546kB!  (Both have the "weak" fix above.)



So, now I have a nice set of reproducible test cases for memory usage to help prevent memory leaks in the future.  Vala does a really nice job of managing memory via references, so it's almost no problem at all.  While the biggest win comes from dealing with a memory leak in code that isn't even mine, the tests helped me locate it, and if the leak had not been fixed in the last couple of months, I would have been able to fix it myself, and now I'll know if any new leaks are created.  I'll probably trust the GSlice allocator in actually running my experiment, and be grateful for its purported benefits (rather than using always-malloc all the time), since there is no actual memory leaked.  Finally, it's nice to have a better understanding of memory usage in Vala and GLib.  I feel like it's generally important to be well-informed about how memory is being handled, and that's something I haven't had the time to educate myself on for Vala until now.

[Technology] Changing cursor size in GNOME 3

So, googling around, I was told there should be an option in GNOME Tweak Tool, but I don't see that right now, so poking around some more, I found a useful dconf key, and from the command line, I set it like this:



$ dconf write /org/gnome/desktop/interface/cursor-size 48



I'm doing this because I am using a double monitor but the one monitor is big enough that I keep losing my cursor!