Yaourt and NixNote

See Time For a Change for the first in this series, or check out the index to see all the posts dealing with Arch Linux. Today I will set up yaourt, which makes working with the Arch User Repository (AUR) much easier, and then use it to get NixNote installed.

Yaourt stands for "Yet AnOther User Repository Tool", which is a terrible name, but it is very effective at its job. It makes the AUR significantly easier to work with, by giving a pacman-like interface that does everything pacman does, but adds the AUR as a source. This makes installing packages from the AUR as simple as installing packages from the core repository... usually.

Having fought with and failed to get NixNote installed by hand, I turned in frustration to yaourt, and was pleasantly surprised at how easy it was to use. I still don't trust it entirely, because I can't find much in the way of documentation about it, and there seems to be some contradictory information about whether it is safe to use it for non-AUR packages or not. But I suspect like any labor-saving tool, my comfort with it will come long before my understanding.

I installed yaourt in a very similar manner to my installation of libgcal and akonadi-googledata before. It relies on the package-query package in AUR, which therefore needs to be installed first. The following steps can also be found at yaourt's website:

$ cd ~/abs
$ wget http://aur.archlinux.org/packages/package-query/package-query.tar.gz
$ wget http://aur.archlinux.org/packages/yaourt/yaourt.tar.gz
$ tar xf package-query.tar.gz
$ tar xf yaourt.tar.gz
$ cd package-query
$ makepkg -si
$ cd ../yaourt
$ makepkg -si

Next is to install NixNote. In theory, all I should need to do is:

$ yaourt nixnote

And in theory, there is no difference between theory and practice. But in practice, there is (Yogi, or Al, or Jan). And so it is in this case. After a bunch of package downloading, configuring, and compiling -- all done by yaourt -- I finally get this error:

/usr/bin/ld: /caviar/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libm.a(k_standard.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC

/caviar/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libm.a: could not read symbols: Bad value

collect2: ld returned 1 exit status
make[1]: *** [libpng12.la] Error 1
make[1]: Leaving directory `/tmp/yaourt-tmp-mark/aur-libpng12/src/libpng-1.2.46'
make: *** [all] Error 2

Let's break this down, shall we?

• /usr/bin/ld - this is the linker reporting the error, which means that all the code has compiled just fine, and now the build system is trying to assemble it into an executable binary file.
• .../lib/libm.a(k_standard.o) - the failure occurred while linking the static library "libm.a" into the executable, specifically some reference inside the program module k_standard.c, it doesn't really matter what.
• relocation R_X86_64_32s against `.rodata' can't be used when making a shared object - I'm not really sure what is going on here, but I suspect it has something to do with some of the weirdnesses of working with 64-bit addressing within libraries that were written assuming a 32-bit world. This sort of thing happens far more often than it should.
• recompile with -fPIC - advice from the linker on how to solve this issue, I love it.
• .../lib/libm.a: could not read symbols: Bad value - probably caused by the previous error. Once something goes wrong in a build process, its effect usually cascades forward a ways before the build system stops.
• make...libpng12.la - we weren't even working on building NixNote, here, but libpng12, one of its dependencies. libpng is a library for manipulating PNG graphics, and the repository version of this library is at 1.4. NixNote is woefully out of date, though, and won't work with anything newer than the old 1.2 version of libpng, and this is that outdated library.

The -fPIC flag to the linker is a new one to me. Here's a man page reference, taken from man ld:

-f name  :  When creating an ELF shared object, set the internal DT_AUXILIARY field to the specified name.  This tells the dynamic linker that the symbol table of the shared object should be used as an auxiliary filter on the symbol table of the shared object name.

This doesn't really clear it up much. Some more searching led me to some related content that implied that the "recompile with -fPIC" advice was actually suggesting that I recompile the math library libm, which is an integral part of the operating system (pun intended). This is probably not a great idea, so instead I'll try to disable the use of shared libraries and PIC (Position Independent Code). By the way, if you want more information about all these issues, read this and then explain it to me. ;-) Anyway, I want to adjust the build process of libpng12, which all starts with the same command:

$ yaourt nixnote

Except this time, I'll answer "yes" when it comes to the libpng12 PKGBUILD question. Within this file, I see a section called "build" contains the line:

./configure --prefix=/usr

This is a very standard way to get a Linux source package ready for building and installation, and the best place to make my change. Specifically, I'll change it to:

./configure --prefix=/usr --disable-shared --without-pic

And this time, it sailed right through, building and installing libpng12, and then building and installing NixNote successfully, even adding it to my KDE menu for me and everything. But when I try to run it:

$ nixnote

...

java.lang.UnsatisfiedLinkError: /tmp/QtJambi_mark_amd64_4.5.2_01_gcc-20090628-2055/lib/libQtGui.so.4: libpng12.so.0: cannot open shared object file: No such file or directory

This isn't a big surprise, since I did disable the building of the shared library libpng with that first additional flag. For some reason, it occurred to me to do a file search on my hard drive for libpng12, and lo and behold, there was a libpng12.so.0 sitting in the Dropbox application directory! Yoink...

$ sudo ln -s ~mark/.dropbox-dist/libpng12.so.0 /lib/libpng12.so.0

$ nixnote

Finally, I can enter my Evernote account details, synchronize my notes from their server, and I'm off to the races. It's kind of sad that I had to jump through so many hoops to get this installed when the right answer would be to update NixNote to use the latest (and fully supported) version of libpng. Maybe someday I'll look at how feasible doing that would be, but today I just want my software to work.

Almost there!

PasswordSafe for secure password management

Moneydance for personal finance DONE!

ThinkOrSwim for option trading DONE!

Minecraft DONE!

Dropbox for cloud storage DONE!

Kontact for e-mail, contacts, and calendar DONE!

Choqok for micro-blogging (following and posting to Twitter) DONE!

NixNote for notes/personal organization DONE!

Okteta hex editor DONE!

Bacula for automated backups

Hard Drive Exhumations

I have a lot of hard drives lying around, because no matter what happens to the other parts from a decommissioned computer, the hard drive always gets stored.  There's too much sensitive data on there for me to let anyone else get their hands on it, and for many years I have been stashing hard drives in the basement with the intention of "one day" zeroing out all the sectors and disposing of them... somehow.

Today I decided to take an inventory, and it was an interesting-but-dusty trip through the last 13 years of building and destroying the computers that live in this house.  I have no fewer than 19 decommissioned hard drives that I know of.  Here are a few of the more dramatic highlights:

• There are two 250GB Western Digitals that I pulled out of the LaCie BigDisk external USB drive enclosure after it died.  I bought those back in the halcyon days of Mad Dog Software as a backup solution, because I could fit the contents of all the computers in my house on just one of them.  The intention was to get two of those enclosures and keep one off-site.  That fizzled, but it did give me an excuse to write a trickle-transfer utility to run on Linux and send backup files to Dan's house for storage.  That was my first serious Linux project.
• There are three 60GB Maxtors of which I have no guess the purpose... but one of them has a post-it note that reads "noisy" in Diane's handwriting.  I can only imagine how all this came about.
• There are four 60GB IBM Deskstars dating back from the dead-drive catastrophe of 2001 (or was it 2000? not sure now).  I decided to build the Mother of All Machines, so I bought four of these hot-running high-failure-rate data bombs and put them in RAID 0+1.  Maximum PC rated them Kick-Ass at the time, so they seemed like the best choice.  Little did I know I had just purchased drives that would be the subject of a class-action lawsuit a few years later.  The thing about RAID 0+1 is that, in theory, it has the speed of RAID 0 (striping) with the data safety of RAID 1 (mirroring).  But in practice, it isn't that fast and it isn't that safe.  Especially when you have two drives fail simultaneously, like I did.  The four I have now include two warranty replacement drives, so I think they all work.
• Last spring I built my grandmother a new PC from leftover parts I had lying around, replacing one that was refusing to boot.  I took the dead hardware with the plan of figuring out what the problem was, but didn't even crack the case until today.  Inside I found three hard drives.  They proved to be resistant to my charms and I was in a hurry because I was expecting a phone call.  Can't wait to get back to them and see what sort of complicated storage scheme was dreamed up on those.
• Buried deeply in the random-hardware boxes and covered in dust, I found a 6GB (yes, six gigabytes) Western Digital from 1998, and a circa-1997 Fujitsu that gave no size nor cylinder information whatsoever.  Wow.

Sitting here next to my desk is a fully functional Windows PC of fairly recent vintage that has no keyboard, monitor, or mouse - just power and network.  I know I had a reason for not moving this thing down to the basement, but I couldn't say what that reason was.  In any case, I'll use that machine to clean these hard drives one at a time over the next million years or so, all so that I can safely dispose of them.  I may dual-boot it to Linux first, just for fun, I don't know.

Diane suggested I look at FreeCycle as a way to give away stuff to people who want it... I can't wait to see who wants a 10GB IBM OEM hard drive from 1998.

December Iron Condor

In another of my paperMoney trades, I experiment with iron condors.  Today I opened a position on my next month's iron condor, expiring in December, on RUT.  RUT is the Russell 2000 index, and options on it are European-style and cash-settled.  This means they cannot be exercised early (very important for spreading), and in-the-money options at expiry won't cause securities to change hands - just money.  Settlement at expiry is weird, though, so it's best not to take them to expiry in any case.

WTF is an Iron Condor?
An iron condor is a market-neutral option strategy that is short volatility but with limited profit/loss ranges.  It consists of two vertical spreads: a put spread below the current index price, and a call spread above the current index price.  The long options in the spreads are both farther OTM than the short options, so opening an iron condor position generates a credit.  The farther apart the short option strikes are from each other, the lower the risk that the iron condor will lose money, but the less credit it generates on opening.

A picture is worth a thousand words.  Luckily for you, I have both.  Check out this page from Option Trading Tips:  Iron Condor Description.  I'm working on getting permission from ThinkOrSwim to include screen shots from their software.  In the meantime, this is the best I can do, sorry.

Terminology does not agree on how to refer to iron condors that generate a credit when opened.  They consist of two short vertical spreads, but many (including the website above) call that combination a Long Condor.  To me, selling means that I get money; buying means that I give up money.  So throughout this blog I will rightly or wrongly refer to iron condors like they're short: I sell them to open them and I buy them to get out.  So today I sold an iron condor, opening a short position, and I generated cash.  Questions? No? Excellent.

Where To Begin...
Here I have to give Mark Wolfinger props again, because about a year ago I looked at iron condors briefly when a co-worker (not a professional trader, in this case) told me about how he was making a guaranteed 10%/month on them.  This seemed too good to be true, and after analyzing them a little I decided that it was: the probability-weighted return on his capital was far too low for the risk of ruin he was taking.  I dismissed iron condors as hardly better than naked option selling, and was ready to leave it at that.  In the process, however, I ran into Mark Wolfinger's blog Options for Rookies, and I started reading it regularly.  Over the next few months I realized that there was more to iron condor trading than I first assumed.  Guaranteeing 10%/month was indeed too good to be true, as I suspected.  But there was nevertheless a viable trade there for someone willing to put in the time and effort to build experience.  A firm believer that nothing worth doing is easy, I set out to learn.  I'm just getting started on that journey, and though it will never end, I hope that soon I will have made enough progress to begin profiting from it.  I don't know when that will be, but I know it isn't now yet.

I've followed MW's lead in a lot of respects, because I am more of a learn-by-doer than a learn-by-reader.  As I try different approaches and find my own comfort zones and style, I start to diverge from him; this is natural.  But some aspects of his trade are relatively arbitrary from my perspective:  he trades RUT because he feels that its volatility is not-too-high but not-too-small; he trades options with 60+ days to expiry because he feels that is the right mix of risk (gamma) and reward (theta).  Never having traded iron condors on any index, and never gotten burned in either direction in time-to-expiry, I figured 60+ days on RUT was as good a place to start as any.

My Own Trading Style
My current behavior pattern is to start looking for a new iron condor position around the first of the month two months before expiry.  This gives me 60-80 days or so before expiry.  Also like Mark, I look to get out of the condor early if the market is willing to let me buy back pieces of it at good prices.  I don't try to choose a low-risk / low-reward condor that I never have to adjust, but I try to give it enough room to move that I can make adjustment decisions after work for trading on the open the next day.  Taking some of his lessons to heart, I try not to increase my position in the course of adjustments; however, I will do so if I have previously reduced the position via cheap buy-backs.  I try very hard to evaluate what the position is now, instead of whether I'm up or down from my entry point.  This is a lot harder than it sounds, but Mark harps on it so much that it is starting to sink in.

In Theory, There Is No Difference Between Theory and Practice
A perfect situation in my trading style is to find a new iron condor on, say, October 1 for December expiry that I can put on generating 3.50 or so in premium while keeping the two short options a good 15-20 strikes apart.  For this situation to remain perfect, the market needs to move up and down some so I can cheaply (like 20c or so) get out of the two spread legs, but not so much that I feel I need to adjust to protect my position.  The perfect scenario ends about 30 days before expiry when I exit the last position without ever having to adjust.  Net profit when perfect: nearly $3.00 per contract, or about 30% on margin risked.

But In Practice, There Is
In reality, that scenario never happens.  I always have to adjust, I always agonize over how much insurance to buy and when, I seldom pay as little as 20c to buy back my spreads, I frequently enter the position for less than 3.50 credit, and I often find myself still trying to dump some position off with only 2 weeks to go.

I often have two condors on at any given time: one that I'm adjusting and working my way out of, and one that I'm watching eat up theta prior to its first adjustment.  If I end up with over 1.00 per original contract profit, I'm thrilled. Note that because of adjustments, 1.00 per original contract is a lot less than 10% margin profit, because the margin gets bigger and the profits get smaller with insurance.  If my net cash flows are positive at the end of a condor run, I'm satisfied.  If I learn something along the way, it's all worth it.

I'm slowly starting to get a feel for what values of delta make me nervous, and I'm better at choosing adjustments that don't give me a negative theta, since that would negate the whole purpose.  I'm always massively short vega, since that's the nature of an iron condor; and gamma doesn't really affect me too much 60 days out.  It is nevertheless always the shadow in the corner, and I keep an eye on it more and more the closer to expiry I find myself.  Experience has come very slowly, but it is starting to click.  That's a cool feeling.

Current Situation
Right now I have a heavily-adjusted November position on.  It's too complicated to explain without charts, so I won't try.  But despite the drop in volatility the past couple of days as the market rallied, I was able to put on my December iron condor position for my target price of 3.50.  It's a little tighter (short strikes are closer together) than some previous months, but I'm also getting a little more comfortable with adjustments; this lets me generate more premium credit at the start without so much fear.  My new RUT December condor is a 610/620/770/780, meaning that I am long the 610 puts and the 780 calls, and short the 620 puts and 770 calls.  Max profit: the 3.50 credit it generated.  Max loss: 6.50.