dis·am·big·u·ous·i·ty

It’s funny how volatile my relationship with “new technology” can be. It’s not uncommon for an alpha geek like me to pick something up, kick the tires for ten minutes, then declare it unfit  for use. It’s always nice (albeit rare) to pick up the same tech down the road and come to find my previous judgement was premature.

I’ve just recently had this experience with Wine (as in the Windows Emulator) on my Fedora 12 x86_64 laptop. For months now I’ve been using my wife’s Mac in order to run Google SketchUp because I just assumed Wine was still unusable, especially for a program requiring OpenGL. But I gave it a spin on a whim last night and was pleased to find that it runs very well. Maybe the rumors I’ve read that Google has been contributing a lot to the project are true.

There were a few tweaks necessary to get it working properly though. Here they are for you:

1. Since I’m running an x86_64 distribution, the standard install from the Fedora Updates repo was naturally the x86_64 Wine build. A blog I read said 64-bit Wine just doesn’t really work, and my experience was the same.  So I had to change to the 32-bit version:
   yum remove wine
yum install wine.i686
2. After installing and upon my first attempt to run, SELinux alerted me to some mischief. Something about mmap_zero, but I was happy to see that an SELinux boolean was available to switch off enforcement of that, so I did:
   System > Administration > SELinux Management > Boolean > Module:Wine & Description:"Ignore wine mmap_zero errors"
3. That was getting closer, but the next problem would have been too much for me to solve if not for a forum posting that described some necessary registry hacking (yikes, now I’m remembering why I left Windows behind).

That was it. I’m running SketchUp and editing some of my old models.  Extra bonus points to Wine for putting a shortcut in my Applications menu (see the screenshot).

Screenshot: Google SketchUp on Fedora 12 x86_64

I had some more time to think about what I am looking for in a directory synchronization tool. I had decided that the main requirements were:

• Peer-to-Peer model: mostly for private synchronization (i.e. only for the same user) from multiple nodes, but also opening up opportunities for group sharing
• Branch-per-node: each node will be a branch, but will have to have some sort of intelligent merging in order to deal with the potential problem of binary files growing out of control
• HTTP support for firewall issues

Given those new requirements, I googled “BitTorrent Sync” and was surprised to find a project by the name of PowerFolder | Easy Secure File Transfer, Share, Sync and Online Storage Software I’m doubly thrilled to find that it is Open Source, although it appears to have a dual-licensing scheme which automatically makes me skeptical.

I’ll have to give the produce a peak and report back whether or not it meets my needs. Stay tuned.

So, I agree that the iPhone is awesome, but is it really worth all these articles flowing through to my RSS reader? I was on the fence, until I read the following comment left under this flickr photo:

“This is an incredible phone . . . imagine how fast apps will be created! This is MacOS X in a phone!!”

LIGHT BULB! I suddenly remembered how much I’ve been moaining about the difficulty to put useful apps on your cellphone, even to the point of touting the Qtopia Greenphone. Could this be the first mobile platform to gain traction in “the community”? If it does gain traction in that sense, will we be able to load our own non-Apple DRMed media software?

I’m excited – and skeptical. Maybe the best solution is to throw a linux distro on there!

By the way, that size comparison app in the photo looks pretty cool.

Okay everyone – you ready for this?  Honestly, you are probably bored already.  Hopefully this blog doesn’t go to waste (yeah, I tried this before).