Skip to content

Telaen 2.0 Status

As noted in a previous blog post, I've started working on the 2.0 version of Telaen: a simple but powerful PHP-based Webmail system. Quite a bit has been changed, fixed and added under-the-covers, including baselining PHP 5.4, a more robust installation checker, and some significant performance increases.

However, as I was working to make the backend stuff as up-to-date as possible, it became increasingly obvious that Telaen's UI was extremely dated. It was functional, yes, but made very limited use of CSS, HTML5, Javascript, etc, all of which combine to affect the user experience. Luckily, a very good friend of mine, Mike Hill, has started work on a new UI for Telaen, making it not only more streamlined and attractive, but also much more functional as well.

Now I know, of course, that there are a number of other PHP webmail offerings out there, so some may be questioning the need for yet another. I can think of a few reasons:

  • Telaen is designed to have as few dependencies as possible; the goal is that any typical PHP setup will be able to run Telaen.
  • No external database is required.
  • Extensive support for both IMAP and POP; to be honest, most webmail systems don't support POP at all, or are extremely limited in their support.
  • Consistent functionality, no matter which IMAP/POP server is used; most webmail systems are simple "front ends" for IMAP servers, meaning the capability of the webmail system depends on what IMAP server is being used. Telaen puts that capability within the webmail system for a consistent feature set.
  • Fast caching
  • Designed to serve as both someone's primary Email client, as well as their supplemental client.
  • Lots of what you need/want, and none of what you don't: Telaen is as simple as it can be, but no more so.
  • A fast and secure upgrade path for all those people still using UebiMaiu
  • Open to ALL contributions!

The last point is important: we really want as many people as possible to use, contribute, drive and develop Telaen. It's a great project for someone just starting out as well as for more experienced developers. Or if your passion is documentation, we could definitely use your help! In fact, however you want to be involved, we want to welcome you to the project.

Our goal is to have a beta available sometime within a month's timeframe. Stay tuned!

Open Source and Trademarks

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

  1. Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
  2. That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

Open Source and Trademarks

In any area of business and activity related to business, the idea behind, and protection of, trademarks is critical. But what some people don't understand is that in the Open Source/Free Software world, trademarks are, in many ways, the only real asset that a FOSS project has.

Think about this: in most normal areas of software development, the software itself (the code) is intellectual property. It is itself an asset, with value. But in an open source world, the code is free and open to all. "Having" the code isn't any sort of asset, since anyone can also have it as well; in fact, it is encouraged to share that code with as many people as possible. So whereas in other circumstances, the resulting work behind the effort of coding is an "asset", and, in many ways, the most valuable asset, with FOSS projects it is the least valuable.

So what is the main asset of a FOSS project?

The trademark. The brand and goodwill associated with that project. And for many projects, it's the only asset, and it's the main reason why people contributed to, and use, the code. For example, one significant reason why projects enter the Apache Software Foundation is that they want to leverage and benefit from the Apache brand. Being an Apache project automatically gives a project a sense of credibility, as well as a promise on how it will be governed and managed, and how code provenance will be done. It is a reputation obtained from years and years of doing things the right way; The Apache name means something. It has become a brand.

With this in mind, it should be somewhat obvious why FOSS projects walk that fine line between wanting (and needing) to protect their trademarks (and brand) yet, at the same time, allowing people to use those marks in as unrestricted ways as possible. On one hand, you want to use that brand to encourage even wider sharing and usage of the code, yet on the other hand, you must protect those marks from usage which would damage the brand, or confuse people. And so most FOSS projects or foundations create trademark policies that describe acceptable and unacceptable usage.

So I was shocked and extremely disappointed to hear that GNOME is having to battle Groupon over Groupon's unacceptable use of the GNOME mark. There are only 2 possible ways this could have come about:

  1. Those at Groupon tasked with this effort are so incompetent and clueless that they never heard of GNOME
  2. That Groupon is simply thumbing their noses at GNOME and, by extension, the entire FOSS community as well.

This is totally unacceptable, and is, IMO, an attack on all FOSS projects and foundations. When well-funded corporate entities, especially those who directly benefit from FOSS, go ahead and simply decide they can steam-roller over the FOSS community, it is time for all of us to take a stand. Help GNOME defend their mark!

Starting on Telaen 2.x

After a somewhat long sabbatical, I'm energized about rebooting the Telaen Project.

Partly, this is due to jaguNET migrating to using Dovecot for both POP3 and IMAP, and the realization that an upgraded webmail system would be the perfect compliment. Now for sure, Telaen is a great PHP-based webmail system, and, in fact, has served (from what I can tell) as inspiration and source for numerous other webmail systems as well (such as T-Dah Webmail, for example), but I had let it lay fallow for quite awhile and, well, it's showing its age. And to be honest, except for some of the larger, and more complex and dependency-ridden offerings out there, it seems that no real PHP webmail packages are being actively developed.

So, I've gone ahead and create the telean_1.x branch and master on the git repo will be the source of Telaen 2.0 development. In no particular order, I plan the 2.0 version including the following:

  • Removal of PHP4 support and baselining PHP5.3 at a minimum.
  • Faster indexing by utilizing sqlite3 instead of PHP arrays
  • Better and more complete IMAP interaction
  • Better SPAM handling, especially related to auto-population of the Telaen internal SPAM folder (right now, if the user creates a real, IMAP SPAM folder, Telaen gets awfully confused)

In all cases, the design goals of keeping Telaen as simple and streamlined as possible, and avoiding as many dependencies as possible, will be kept and honored. In fact, the only dependency "added", that I can foresee at this time, is sqlite3 capability, which is default for PHP5.x anyway. However, I do plan on adding some hooks so that if people want to use MySQL or Postgres, they will be able to.

If interested, check out the Github page, and help develop the code, add features or wish lists, find and patch bugs, etc... 

Lack of civility

Over the last several weeks, much copy has been created over the lack of civility in various communities: Open Source, gaming, etc...

Now, I'm not a gamer, but I am a person seriously involved in the FOSS community, and I see some parallels between the issues involving all of these communities, and I have some thoughts and possible insights to share.

First of all, what I see is a significant lack of civility. Not only in what is being said, but also in how it is being said and, almost most unsettling of all, that if there is a way for someone's statements to be misconstrued in the most unattractive/unpopular/controversial fashion possible,  that's the way it will be seen (in other words: the other party doesn't receive the benefit of the doubt: you must prove that you are not an asshole; it's not assumed that you aren't).

Now certainly the anonymity of mailing lists, twitter, etc all help in that, but mostly, IMO at least, it's also due to people forgetting that there is a real live human being behind that Email address or twitter handle

The second issue I see is that there is no longer a desire to have a discussion or a conversation, per se, but rather it's a contest, a war, in which the sole desire is to win, and make the other side lose. In doing so, we don't listen, instead we are planning and plotting our response. And, because winning at all costs is important, the ends justifies the means. If we have to create strawmen, well, as long as we win (or, at least, they lose), that's OK. Of course, in matters that we have deep feelings and concerns for, it's hard to keep emotions out of it. After all, if someone calls my kids stupid, I will "fight" to ensure that no one walks away with the mistaken impression that somehow that position is correct, or right, or warranted. But very few things are really that personal, we just make them so.

Closely related to the strawmen method noted above, is that in most discussions other "baggage" (for lack of a better term) is brought in. This baggage is only remotely related to the discussion at hand, but it is a powerful, polarizing artifact, and serves to either focus the discussion on that issue or, most of the time, implies that being for one position implies being against another (which you would not agree to at all). For example, in a recent "discussion", I noted that "actions have consequences". Certainly this is something that we can all agree with, right? After all, our legal system is based on it, parents instill this concept to their children, religions are based on it, etc... But, that simple statement somehow implied that I was OK with "blaming the victim". So instead of simply seeing and understanding what I said, instead a position was forced upon me, a position that I would never take. And I had to prove that I was not a "victim blamer".

It is sad when activities which started off as, and are supposed to be, fun and enjoyable degrade into "contests" and battles in which people have to "expect" harassment, ridicule, threats, etc. All these technologies were supposed to bring us together, not provide ammunition and resources for dipwads  and psychopaths to destroy one's happiness and life. If you are involved in a community, it is your responsibility to make sure that poisonous people are not allowed. That's why I am so proud of the communities we've created at Apache, after all, our unofficial motto is Community Before Code. We aren't perfect, to be sure, but I think we have some insights that other communities could benefit from.

Shellshock: No, it IS a bash bug

Reading over http://paste.lisp.org/display/143864, I am surprised just how wrong the entire post is.

The gist of the post is that the Shellshock bug is not bash's fault, but rather, in this argument, the fault of Apache and other facing programs in not "sanitizing" the environment before it gets into bash's hands.

Sweet Sassy Molassy! What kind of horse-sh*t is that?

As "proof" of this argument, pjb uses the tired old excuse: "It's not a bug, it's a feature", noting that bash's execution of commands "hidden" in environment variables is documented; But then we get the best line of all:

The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature 

As far as outlandish statements, this one takes the cake. Somehow, Apache and other programs should sanitize magical, undocumented features and their failure to do so is the problem, not that this magic is undocumented as well as fraught with issues in and of itself.

Let's recall that if any other Bourne-type shell, or, in fact, any real POSIX-compliant shell (which bash claims to be), were being used in the exact situation that bash was being used, there would be no vulnerability. None. Nada. Zero. Replace with ksh, zsh, dash, ... and you'd be perfectly fine. No vulnerability and CGI would work just fine. And also let's recall, again focusing on Apache (and all web servers, in fact; It's not just Apache is affected by this vulnerability but any web server, such as nginx, etc...), the CGI specification specifically makes it clear that environment variables are exactly where the parameters of the client's request lives.

Also, let's consider this: A shell is where the unwashed public interfaces with the OS. If there is ANY place where you don't want undocumented magic, especially in executing random code in an undocumented fashion, it AIN'T the shell. And finally, the default shell is also run by the start-up scripts themselves, again meaning that you want that shell to have as few undocumented bugs... *cough* *cough*, sorry "features" as possible, and certainly not one's that could possible run things behind your back.

Yes, this bug, this vulnerability is certainly bash's, no doubt at all. But it also goes without saying that if bash was not the default shell (/bin/sh) on Linux and OSX, that this would have been a weaker vulnerability. Maybe that was, and is, the main takeaway here. Maybe it is time for the default shell on Linux to "return" to the old Bourne shell or, at least, dash.

Shellshock

UPDATED: Sept 29, 2014 with current OSX Bash patch

First of all, when this was first found, we were looking for a cool name... It was found.

Anyway, as noted here [https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/]  the shellshock vulnerability is pretty nasty. What's interesting is that, in general, the *BSD variants aren't as vulnerable as *NIX platforms, simply because the default shell on BSD is still the Bourne shell (the "real" sh) and not Bash itself (On Linux and OSX, for example, /bin/sh is either a copy or link to /bin/bash).

Even so, BSD systems are not immune by any stretch of the imagination, since one attack vector is via web-servers and CGI, and it's likely that there are numerous CGI scripts that require/use Bash. So no matter what, patch your systems.

Continue reading "Shellshock"

iOS 8

With all the buzz around iOS 8, I decided to take the plunge. I went ahead and upgraded an iPad2, iPad Mini and iPad Retina. I didn't upgrade any iPhones.

Why?

I'm not crazy! I need my iPhone to work! 

Anyway, so after several days of using iOS 8 on these devices, I can come up with a singular conclusion: It Is Dog Slow.

I mean really, frustratingly slow. Like I could use a stop-watch to time how long it takes apps to open (even those specifically upgraded for "iOS 8 compatibility" or to get back to the home screen when the Home button is pressed. Once in the apps, things are better, but no app at all feels peppier under iOS 8, except for maybe Safari.

Plus, a lot of apps, like Scribd, don't even open up and just die. 

Continue reading "iOS 8"

Dad

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.

Marley

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 Case for a Universal Web Server Load Value

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.

Categories: ASF

Why Open Source Needs Non Profits

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"

The silent drum-beat

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"
Categories: ASF

I join OSI

Yesterday I learned that, along with Karl Fogel and Mike Godwin, I was elected to serve on the Board of Directors (BoD) of the Open Source Initiative (OSI). I consider this a great honor, joining the ranks of the great FOSS luminaries of this esteemed organization. I am also very excited by the changes and the challenges that the coming year holds for OSI, as they... we move to a member, representational model. This is, of course, the logical outcome from OSI moving from being the stewards of the Open Source Definition, to being, for lack of a better term, stewards of Open Source itself. There are, after all, quite a number of open source foundations out there, including the ASF (which I'm also on the BoD of, as well as President), the FSF and Outercurve (which I am on the BoD as well). But just as all these FOSS entities share a common license type, there are also other shared concepts which are core and central to the whole milieu of Open Source, a sort of common ground. And OSI is ideally suited to serve as the focal point for that common ground, a "United Nations" kind of entity. As successful as Open Source has been, it is clear that there is still much to be done... much FUD to be cleared away, much more "evangelism" to be done, and fostering the continued use of FOSS methodologies outside of the traditional "software development" space. And I'm proud to be part of an organization which is wholeheartedly behind all those efforts, and more. Exciting times ahead indeed.

Apache httpd 2.4 - one step closer!

Today we released the first public beta of the next-gen version of Apache httpd, version 2.4. This release is officially called Apache httpd-2.3.11-beta, since we use odd/even numbering (for the minor version number) to signify alpha/beta vs. stable releases. Most work has been done in improving performance and stability, but as well as adding lots of useful features, especially as we see the demands placed on web servers by cloud environments. This means that the (reverse) proxy module had gotten a lot of special care and attention. But there are also modules to help with more fine-grained control over timeouts and even a basic bandwidth limiting module bundled in. With this release and the coming of Apache httpd 2.4 GA, you'll see the popularity and usage of Apache increase even more, as it becomes the web server for the cloud, bar none. Cheers!
Categories: ASF