After my corporation bought back some stock certificates, the method I used to calculate Item F, “Shareholder’s percentage of stock ownership for tax year,” became more complex. Neither Google nor WolframAlpha led me to an equation so I set about creating a spreadsheet to simplify the problem.

The IRS instructions for form 1120S Schedule K-1, Line F, describe the method to use thusly:

Each shareholder’s pro rata share items are figured separately for each period on a daily basis, based on the percentage of stock held by the shareholder on each day.

…..

If there was a change in shareholders or in the relative interest in stock the shareholders owned during the tax year, figure the percentage as follows.
• Each shareholder’s percentage of ownership is weighted for the number of days in the tax year that stock was owned. For example, A and B each held 50% for half the tax year and A, B, and C held 40%, 40%, and 20%, respectively, for the remaining half of the tax year. The percentage of ownership for the year for A, B, and C is figured as presented in the illustration and is then entered in item F.

I built myself a spreadsheet to calculate Item F correctly in the simple and complex cases. My spreadsheet implements the IRS described method without requiring the preparer to manually perform all the interim calculations. The only required inputs are the quantify of shares held by each shareholder and the number of days they were held.

Without any alteration, it supports up to 4 changes in shareholders and there’s no limit to the number of shareholders. I just plop in the raw numbers from the Stock Transfer Ledger and the spreadsheet does the rest.

I post it in Numbers and Excel formats, hoping that others will find it useful as well.

1120S_Schedule_K-1_Worksheet.xls

1120S_Schedule_K-1_Worksheet.numbers

After 50 hours of walking at my desk, a few shortcomings compelled me to action. Most of the treadmill surface was under the desk and not available for walking, forcing a shortened stride. It was also unsuitable for jogging or running. We left the treadmill on sliders, so it could be slid out for running. The most annoying problem was not being able to use the controls while standing on the treadmill.

On Saturday I did a little measuring and planning, and then cut out a 11″ x 32″ rectangle for the treadmills console to protrude through. I positioned the cutout 8″ from the front of the desk, leaving exactly enough space behind the console for my iMac to perch on. Then I slid the desk over the control unit and moved the desk surface up.

After everything was in position, I found two problems. The iMac fit but there wasn’t enough space between its chin and the back of the treadmill console to tilt. The solution was cutting a 1.5″ x 14″ notch at the rear (the part I stand in front of) of the desk cutout. That allowed the treadmill to move forward 1.5″ and now I can tilt the iMac.

The other problem was the shelf. With the initial cut, it didn’t fit. Anywhere. After adding the notch and moving the treadmill forward, it was mountable as can be seen. The ideal mounting distance from the front edge of the desk to the cutout is 12.5″. Everything fits perfectly.

I have used this new configuration for 10 hours now. I would like a little more desk available for my forearms to rest on, and I need to raise the desk surface. When I last raised it, I forgot to factor in the incline of the treadmill. Without intent, I created an adjustable height walking desk!

Background

In July of 2008, I was tasked with building a system to back up thousands of Linux based servers. Previous systems using Amanda and Bacula had failed, principally because they required a full time backup administrator to maintain. My job was to build a backup system that required very little maintenance, scaled well, and made restoring data straight forward and easy.

I initially deployed BackupPC which features data deduplication and would likely have reduced our storage needs by more than 60%. I deployed on two SuperMicro systems, each equipped with dual quad-core CPUs, 16GB RAM, and 24 one terabyte disks. I built out one system with OpenSolaris and the other with FreeBSD. After testing, we deployed both with FreeBSD.

BackupPC ended up being inadequate so I wrote my own backup system on top of rsnapshot. My backup system generates rsnapshot config files and then drives multiple concurrent rsnapshot processes on each of the backup servers, pumping data to the backup disks as fast as they’ll take it. I hacked up rsnapshot for better error handling and reporting. I log exactly how much data each remote system has, as well as how much is transferred during each backup.

About ZFS

The main reason we deployed on ZFS was file system compression. After testing several settings, I settled on compression=gzip. I noticed no difference in system performance between compression settings. The backup system has been in production since, with very little attention since deployment.

When initially deployed, each backup server required manual tweaks so that they would only crash once a day. The multiple concurrent rsync processes created a workload that stressed the ZFS memory pools. Working with the lead FreeBSD ZFS developer helped the situation and my systems only crashed once a week. When ZFS v13 was merged into FreeBSD 8-current, memory management improved and my systems only crashed once a month.

Even during the months of using ZFS with frequent crashes, I never lost any data. And there’s no need to fsck the disks after crashes. My confidence in ZFS grew enough that when I upsized the disks in my home file server, I switched from gmirror (tried and true) to ZFS mirrors. I back up my public server to my home file server and saw the same occasional rsync induced crashes. About the time FreeBSD released 8.0 beta releases, I updated and the crashes ceased. So I updated these backup servers and they too have been stable ever since.

I have added another server to the pool and currently store 58 terabytes of data and over a billion files. My compression ratio averages 2.25, more than doubling the effective capacity of the disks we purchased. After FreeBSD 8 was released, I upgraded all the backup servers and could scarcely be more pleased.

And then I learned that deduplication is coming to ZFS. I can’t wait to test it.

SSH scans and bruteforce attacks that have have been common since my first SSH enabled server was attacked in 1996. Back then, attacks were so rare that monitoring logins and manually adding attackers IPs to /etc/hosts.allow (TCP Wrapper) was sufficient to keep systems secure.

In the mid 2000′s, the rise of botnets resulted in distributed bruteforce attacks, in which dozens of IPs (bots) would attempt to bruteforce my SSH daemons. I wrote a shell script that collected the IPs and added them to the TCP Wrappers deny list. A while later, denyhosts, was released and I started using it instead of my shell script.

Since installing denyhosts, I only monitor logins and scan the nightly security reports. In the past few years, the frequency of attacks has slowly risen but occasionally there are significant changes in attack frequency and duration. The last significant escalation I can recall was in the months leading up to McColo being shut down. Immediately after their shutdown, I noticed a dramatic reduction in bruteforce SSH attacks.

It was during that time of increased activity that I wrote Sentry. Like my original shell script and denyhosts, it adds attacking IPs to the TCP Wrappers deny list. Sentry also adds their IPs to my PF firewall. Sentry worked much the same as denyhosts, except that when someone attacks one of my IPs, they got blacklisted on all of them. The number of attacks that made it into my security logs dropped accordingly.

Months later, after McColo was shut down, the distributed attacks all but ceased. Since then, attacks have remained sporadic, perhaps 10 a week. In the last couple weeks, the number of attacks spiked. I’m seeing dozens of new IPs getting blacklisted each day. Unlike previous attacks, the usernames the attackers are using are not being duplicated, which means the command & control network behind this latest round of attacks is more intelligent than most.

While I’m ranting about business practices stuck in the 20th century, there is a simple reason I frequently decline online delivery of statements. What assurance do I have that after I terminate my account, I will still have access to my account records?

If you want me to sign up for e-delivery, give me some assurance that my records will remain online and accessible for a reasonable period of time. Regardless of the status of my account with you. In other words, match the functionality of paper statements.

If I cancel my account with you, my paper records don’t self-destruct. If you want me sign up for e-delivery, implement and publish your document retention policy that is client friendly and aligns with IRS guidelines. If I have an account with you and cancel it, my account history must remain accessible to me for at least 3 years. 

Considering the cost of printing and mailing statements versus the incredibly cheap cost of storing electronic records, this seems like a no-brainer.

Here are a few more suggestions for a good implementation:

 • Provide a simple method for downloading multiple statements. Quite often I don’t care at all about my statements until the end of the year when I want to download all of them. Selecting a period, clicking download, renaming the statement, and repeating a dozen times is tedious.
 • Give the downloaded files a name useful to humans. Filenames like 82383423546602382_08-08.pdf are not  human friendly.
 • Prefix filenames with a date nomenclature like: YYYY_MM or YYYY_q1. That way, when I’m looking at a folder with several years worth of statements, they are sorted properly.
 • If I cancelled my account with you N years ago and you’re about to expunge my records, make a good faith attempt to inform me prior to that event.