It seems as though bugs may have developed an attraction to me of late. I've discovered that 'pcmanfm' doesn't handle unmounting of drives completely cleanly and that you need to manually kill processes regularly sometimes. I've also discovered that Windows Media Player (with my configuration at least) only seems to work when the TV tuner is inserted on the original USB port that it was configured on (else it will indicate that there are no tuners currently available. Obviously, you can attempt to re-configure the tuner on another USB port but that's beside the point. This is strange behaviour.). MultibootUSB needs 32-bit of 7-Zip to be installed to be run (even if you have installed the 64-bit version on a 64-bit Windows system). Otherwise, you end up with a never ending series of errors. Tip, you need to kill MultibootUSB first before killing 7-Zip else it will keep on trying to re-spawn that process.
While the following is not a bug I find it 'annoying'. The versions of Acronis TrueImage distributed by Seagate/Western Digital are incompatible (retail and other version are fine). I've obviously tried various Open Source options in the past but none come near the performance/compression balance that currently exists in this product and several other proprietary options.
While searching for a new external hard drive I came across the following...
I was recently playing around with the idea (and the practice) of turning Android phones into servers. It was not without its difficulties though. On most mobile computing devices there are forms of so called speed stepping technologies to help increase battery life. It's obviously re-appeared on Android as well but not without some of the problems that plagued other platforms. I once recall using a power control utility application on my old Android phone which underclocked it to such an extent (1/3 of it's full capacity) that I couldn't answer phone calls because there weren't enough CPU cycles for user space applications (such as unlocking the phone itself so that I could take a call) while playing music. Admittedly, the hardware specifications were minimal (it was an extremely early and inexpensive Android phone) but I would have thought a bit more thought would have gone into it prior to deployment (I 'accepted' the 'default settings' believing that that would have been adequate).
I obviously tried SSHDroid but like others I came across what were seemingly stability problems. Upon further examination though I found a lot about wireless and power control technologies. I think a lot of the problems that I was experiencing were as a consequence of power saving software (the above will likely make more sense to you now) which may have led to SSHDroid shutting down randomly and regularly. However, in my research I also came across a file transfer application called SwiFTP. In it, was option to shutdown most power saving behaviour. By enabling this, I've seen been able to achieve relatively stable connections (hours at a time).
You can lock up (somewhat) your Android phone by using firewall such as DroidWall.
Strongly suggest you have reliable equipment if you do ANY wireless experimentation. Obviously firmware changes can have significant impacts upon devices. One thing I underestimated though was how much of an impact 'raw power' played on connection stability. In the past (and recently) I was playing around with the idea of deliberately changing architecture to maintain wireless security (as opposed to relying on pure 'Faraday Cages' and other anti-TEMPEST techniques). By using the concepts of absorption, superposition, and reflection we can manipulate wireless signal pathways (very similar to some of the techniques that are used to develop low visibility/stealth aircraft). The results of these experiments indicate that putting this theory into practice will be less trivial than I had originally anticipated though (the intensity of a signal is conversely proportional to the inverse square of the distance between the source and destination if I recall my physics correctly).