IMO

Today marks the 3rd anniversary of my Dad's death. People say you'll never understand how it feels until you go through it, and they are correct. I never truly understood the emptiness that remains.

My most vivid memory of that time is standing there, at my Dad's side in the hospital, as he was breathing his last breaths.; watching the EKG go from a slow but steady beat, to a weak and chaotic wave and then, like a bad soap opera or medical show, to a simple flat line. And he was gone.

I looked at my Dad and all he really *was*, was gone. All that remained was the shell that carried the *real* Joe Jagielski. He was here, but he really wasn't. I looked at Dad and he was, but he wasn't, my Dad.

We all are aware of our mortality, but it never feels real to us. But when someone close to you dies, especially when you are right there when it happens, it brings it home like a bombshell. I can truly say that, for better or worse, my awareness of death and mortality is never that much below the surface. We all die, and before that happens, we should spend our lives with as much joy and fulfillment as possible.

This realization has somehow made me more, and yet also, less patient. I try not to let little things bother me, and try to see the good in people. I'm more sensitive to people, or, at least, I try to be. Yet, on the other hand, I find that I have little to no patience with two-faced or selfish people who are only there for you if it's "convenient"; Life is too short, and I don't have the time to waste. None of us do.

Dad, I miss you, and I always will. I love you.

Now that Christmas Day itself is over, but not the Season, I'm taking some time to reflect on the lessons detailed in Dickens' "A Christmas Carol." And upon reflection, I've decided that the most important character in the story is not Scrooge himself, but instead his deceased partner, Jacob Marley.

Dickens himself suggests so, by starting the novel ensuring his readers that Marley was most certainly dead. He realizes that the story itself has no depth, unless the scene between Scrooge and Marley actually, truly happened. Unless Marley was dead, and unless what he conveys to Scrooge is Truth, then Scrooge's change lacks the power that it deserves.

But even more so, to me, unless Marley is seen (and for the purposes of this blog post, portrayed) as this immensely tragic and woeful creature, the danger that Scrooge is exposing himself to and the dismal eternal future of those who waste their lives here on Earth, then "nothing wonderful" can come from the tale. And so, even more so (if possible) than the words of Marley, the pitiful nature of Marley provides the fuel for the entire story. Again, Dickens' emphasizes this, since Marley is constantly noted as raising a "frightful cry", or shaking his chains in woe. Marley is completely and totally miserable.

So when I watch the various incarnations of "A Christmas Carol," it's the portrayal of Marley which tells me just how well the director (and the entire crew) "gets" the story. So when I watched Disney's version, with Jim Carrey, I thought that it was an OK version until  the arrival of Marley. In this version, Marley is almost comic relief! And then they made the worst mistake ever. Scrooge tries to comfort Marley by explaining this his old partner was always a good man of business, and Marley summarizes the whole of the moral of the story in the most powerful sentences of literary history:

Business! Mankind was my business. The common welfare was my business; charity, mercy, forbearance, and benevolence, were, all, my business. The dealings of my trade were but a drop of water in the comprehensive ocean of my business!

And yet, in Disney's version, he does so with his lower jaw being "comically" manipulated up-and-down by Scrooge (if you've seen the movie, you know what I mean). Unforgivable.

For me, the best version is the 1984 version with George C. Scott. Frank Finlay is, imo, spot on, and I can't but help be moved when he says the above lines. The power, the emotion, the pure and deep misery Marley feels is there, and the audience, and Scrooge, cannot help but be moved by it, and act on it.

May we all remember the lessons of Marley, and for all of us, may mankind be our business. 

The reverse proxy feature of Apache httpd is an area which I like to particularly hack on. It's always been, imo, one of the killer features of httpd, but it is especially useful in the Cloud. Being able to dynamically allocate, enable/disable and load balance between back-ends is a MAJOR capability lacking in almost all other "generic" (and even "special-purpose") web servers. And the functionality of the reverse proxy in Apache 2.4 is pretty much state-of-the-art.

But there's a problem, which is not unique to Apache itself. In general, load balancers such as Apache do their load balancing determination based on values it calculates on the back-ends. Sure, Apache has a pretty nice set of load-balancing algorithms, but it still implies that the front-end (the reverse proxy) is responsible for predicting the load on the back-end. This is certainly not optimal.

Red Hat's mod_cluster works around this by creating a "unique" communication channel between Apache and JBoss, which allows JBoss to tell Apache some basic and useful loading parameters on the JBoss server itself. This is great, but limited (and hardly universal). What we really need, imo, is a general, universally agreed-upon method of the back-end sending server load data to the front-end. Something that all back-ends can easily generate (and enable/disable, of course) and something all reverse-proxies can easily parse and use. In other words, we need some sort of unofficial standard (which could eventually become a de-facto standard).

Using the assumption that starting simple is best, what I've been looking at is adding a simple HTTP Response header to Apache (via mod_header) which returns some subset of load parameters, the idea being that when the back-end sends the actual response, part of the meta-data it returns is some measure of its health and/or load. The front-end can then tuck that data away and use it in its load-balancing determination (while, of course, ensuring that the header is not forwarded to the client). Currently, in the trunk version of httpd (but hoping to backport it to 2.4), I have traditional Unix-type load-average and the percentage of how "idle" and "busy" the web-server is. But is that enough info? Or is that too much? How much data should the front-end want or need? Maybe a single agreed-upon value (ala "load average") is best... maybe not. These are the kinds of questions to answer.

Knowing that Apache httpd powers between 57% and 89% of the web (based on which surveys you use and/or trust), it seems logical to discuss this, and work out the particulars, on the Apache httpd development mailing list. I think the time for something like this "universal web-server load" value is long overdue. If interested, join the fun on dev@httpd.apache.org.

It's expected that pretty soon we all will hear about the next big "tech" IPO, which will create a mass of instant millionaires and billionaires. And these newly rich will have made their fortunes, at least partly, by leveraging Open Source and the efforts of unpaid volunteers.

I'm often asked, "Doesn't that bother you?" Ignoring the implication that somehow I "deserve" something due to my involvement when there are, of course, multitudes of people more deserving than I, I can honest answer, "No, not really." 

Continue reading "Why Open Source Needs Non Profits"

There are some topics which are just too expansive for a simple tweet. This is one of them.

Lately, there have been quite a few posts extolling the assumed decrease in the viability and "reason" for the Apache Software Foundation. It's always fashionable to lump all FOSS foundations, and related entities (such as Github), into one combined group and pick out the "winners" and "losers" and those whose stars are rising and those whose glory days are fading away. With the hubbub around DVCS and git/Github, people look at the ASF, and our measured approach to incorporating git into our workflow policies, and declare that since we have not drank the Kool-Aid, the ASF's days are done.

But all this misses the point about what the ASF is, and who we are, and why we are. I hope this blog post will clarify some things.

Continue reading "The silent drum-beat"