File sharing on Windows typically leverages the SMB protocol. While this is reliable, there are cases where SSHFS is preferable, most notably when interacting with *nix servers that have SSH access but don’t have SAMBA.
While there are options for running SSHFS natively on Windows, I’ve often found it unreliable; instead I’ll use a Linux VM as an intermediary to establish the SSHFS mount, and expose it to Windows as a SMB file share.
One of the things you begin to truly appreciate is the convenience of a networked printer. When our last one stopped working due to a drum failure, we were left with a single, USB-only Brother HL-2140 laser printer. And while it certainly worked, being able to print only from one computer was a real pain in the ass!
With a spare Raspberry Pi lying around yet again, it was time to fix that. The end result was a fast, AirPlay compatible, on-demand print server, with Windows clients connecting using LPR and *nix clients via IPP.
While working on FontForge to port it away from its hard X11 dependency, something that surprised me was the apparent lack of any decent cross - platform clipboard library. Searching for what was out there, the answer was either “use Qt”, “use Gtk”, or just “write your own”. Indeed, using a cross - platform toolkit is the way to go 90% of the time, but at times, you just want something simple and without the extra baggage.
What I wanted was a self - contained library that worked on all three (Windows, Linux, OS X) platforms, and more importantly, had a pure C API. Existing options ranged from only supporting two out of the three platforms (OS X and Windows, or Windows and Linux), to having half - baked solutions that called xclip as its Linux ‘implementation’.
So in answer to that, I developed libclipboard.
Mobile data is a strange thing in Australia. After taking advantage of an Optus ‘bonus data’ prepaid offer (5GB for $5, although I only got 3GB…), I was left with ‘unlimited’ calls that I was never going to make the best use of. However, I figured there was a better way to leverage more out of this offer - specifically by routing all my home phone calls through my mobile service.
After some thought, the above diagram is how the system works. As I was already routing home phone calls through an ATA to use VoIP, I only needed to add my own SIP server that somehow routed my calls through my mobile. Having a Windows Phone, writing an app to do this is impossible, given that the API is simply not there to perform remote calls. However, like many other smartphones, it does support making and receiving calls through a Bluetooth connection - and this is how, along with an Asterisk instance running the chan_mobile module, this setup is possible. The only reason I’m using the Raspberry Pi to do this was because I had one laying around that wasn’t doing much of anything, and this seemed like the perfect opportunity to use it.