Digital Wasabi

Update! I've been busy these last few months. I've Worked on porting Mono to the BB10 platform. worked on porting Google's Snappy compression to ZFS and a few other little side projects. Recently I came across an intriguing open source project, GamingAnywhere. GA basically a private cloud solution for Cloud Gaming services like Gaikai or OnLive. Cloud gaming has always interested me. What is interesting about private cloud gaming is that you can use your general purpose PC as a gaming hub for your house. You can have a fairly nice Mid to high end PC and, in theory, not have to care about how it fits in with your entertainment system etc. When you set up a GamingAnywhere server, it pipes your full desktop, or a specific named window'ed application to a GamingAnywhere client. It currently uses lag free x264 settings, at 24fps (Which if course brings up bandwidth and latency issues...the same issues that OnLive et al, have been working on). Currently both the cli...

Alright. I've finally got around to doing some Snappy testing. I've gotten some amazing results, but also noticed a bug. My current code seems to hang after a large amount of compression. It specifically hangs when i am doing an iozone benchmark. The 500MB pass (I set it to 4GB). But before I ran iozone, i did some paliminary testing vs lzjb, and I have to say, the compression performance is higher with Snappy. I was able to get a 23.14  compression ration instead of the 15.22 ratio from lzjb, with similar cpu usage. I suspect this has to do with the snappy_env_init method in the snappy-c library i found. It seems fishy having to initializing the environment for every compression event. I may look into it further but it does not seem very scaleable. and given that ZFS compression works at the block level, and not the file level, there are a lot of compression events happening for a single file (instead of one event, compressing a 400MB file...it would be 400 events with...

I've completed my first zfs + snappy build. Its up on github at  https://github.com/techsaint/zfs-snappy . I tried to test it on my Virtualbox instance, but it doesn't look like there is very good VDI support for zfs. It seems to freeze when i try to write to a file system. I tried with the non snappy version too, just in case I mucked up something, but the vanilla version also froze. Now that I have a compatible version, I will test it on actual hardware, instead of in a VM. This build actually has snappy baked into zfsonlinux using the snappy-c library I found. If this route works, I will look at using the snappy-c port in an illumos build. I have all the changes out on bitbucket, and I did spend a few months learning the opensolaris/illumos build files....

Just wanted to make a statement that the CLI tooling for building software in linux (and really any *nix) has changed dramatically. In my mind, configure and make were all black boxes and it was very very hard to actually effect them as an independent developer once they were baked. This is not the case anymore. I was able, with autoconf, automake, and m4 templates (and of course some C++ glue) to actually integrate two libraries (zfs and snappy-c) that know nothing about each other. This is a testament not just to the auto tooling, but the level of maturity of a lot of open source software out there. While make is still technically a black box (yes, make scripts are simple in concept, fine...but go look at Illumos makefiles and we'll talk...), it may be ok for make to stay in the shadows...like some x86 assembly that gets generated on the fly... I just might, after this zfsonlinux + snappy release, revisit illumos. But from what I recall of the original opensolaris d...