Obscene Art

The California Gold Rush holds many parallels to our own current second Internet boom. More technology businesses are being started now than at any time in history, including during the first boom. Far fewer of them will go public, and far fewer of them will blow tens or hundreds of millions in VC (at least, I hope so). But, there are some similarities between this new boom and the previous boom and the Gold Rush of 1849.

A lot of people in all three instances struck it rich by tapping a rich vein…gold in the 1800′s, and huge user base and network effects in 2000 and today. But, and this is a big but, even more people barely broke even. If you don’t strike just the right balance of luck, hard work, and talent, you may end up holding an empty bag. Likewise, some walked a different path, and chose to serve those looking to find gold. Levi Strauss and Leland Stanford both began building their fortunes during the gold rush, but they did it not by searching for gold, but by selling tools, clothing, and supplies to the folks looking for gold. Yes, they had to work longer than the folks who actually found gold. But their odds of success were significantly higher. If you’re surrounded by people who need what you’re selling, and the alternative for your customers is to give up and go home or delay and miss out on a strike, it’s a safe bet you’re going to move a lot of product.

During the first boom, Sun and Oracle made more money than just about anyone by providing tools to the folks building businesses. They weren’t doing anything interesting on the Internet. They weren’t building websites that benefited from network effects, and it didn’t matter to them if millions of users chose their product or service every day. They only needed thousands of users…but they needed those thousands to pay a lot for their goods and services. Paul Graham talked about this in his An Alternative Theory of Unions, and it’s true that when time is of the essence, and staking a claim to your territory is a vital element of success, you’ll pay more to avoid delay.

Of course, Sun and Oracle weren’t the only businesses to make their fortunes providing tools for the first boom, and they aren’t going to be the ones making the money on this boom. The landscape is different, and the success stories are going to be in different areas. Hardware is cheaper and faster, entirely a commodity. Dell will make plenty on servers, but nothing like Sun’s astronomical profits. Databases, too, are a commodity. Every Web 2.0 service is using MySQL or PostgreSQL for their database needs.

We’re placing our bets on systems management. It’s boring, just like servers and databases. It’s necessary, just like servers and databases. And it’s not a commodity (except where we’ve made it a commodity with our own Open Source software). In fact, it’s surprising how weak server management is for web servers. We’re not the only folks placing our bets this way, of course, and it’s a rather big field. Analytics have been hot, because it’s easy to build technically and there’s been big upside for a few of the analytics providers (Urchin sold to Google, NetIQ bought WebPosition from FirstPlace, Instadia sold to Omniture, etc.), so it’s not surprising to see Mint, and dozens of others. Likewise for web service monitoring, with lots of new companies approaching the problem in new ways (we even have some plans in that direction, but only as an ancillary to our core product line). These are both products that tap into a desire that I believe is deeply ingrained into almost everyone, but managers tend to have almost no other desire: Measurement of success. I think of it as the “Ooh, look at the pretty graphs!” factor.

So, while our Open Source project Webmin is a wide-ranging general purpose web-based system administration tool (the most popular in the world with ~2 million downloads per year), our commercial products are tightly focused on web servers and the tools people building the next generation of web services need. So, we don’t get to enjoy the excitement of our first “million page view” day…we do get to live vicariously through our customers successes. It’s exciting to talk to Evan Williams about how he uses our software at Twitter. Nobody knows about it, since it’s on the back end. But it’s cool, nonetheless.

So, maybe if your consumer web business hasn’t taken off as well as you’d hoped, maybe you can refocus on making it a success as a tool for enabling others who are building businesses. Or, maybe not, and it’s time to get back to panning for gold. But it’s worth considering the alternatives to building a business whose only chance of success is convincing millions of people to use it every single day.

So, over at the Virtualmin forums I get a lot of questions about which operating system to use. Partly, they’re asking, “What does Virtualmin support?”, but they’re also looking for guidance on what will be most productive and least problematic for the tasks they want to perform with the system. Given that I’m building server management software, and the majority of the systems I deal with are web servers, the following advice pretty much applies exclusively to servers. Based on my past ten or so years of heavy Linux usage on servers, I’m comfortable calling myself an expert on OS selection and deployment, so disregard the advice at your own peril.

The good news is that I’m not going to tell you that any particular Linux distribution sucks for servers. Some of them do, but I won’t spend a lot of time naming names, except where there is a clear and objective measure that clearly makes some distros better than others. I’d much rather cover what I’ve found makes an OS great for server usage and what makes one painful.

Which brings us to the very first and single most important factor in your OS decision.

Support Life Cycle

Servers remain in service far longer than desktop machines. Migrating from one to another is painful and time-consuming (even with tools like Virtualmin providing a really clean migration path, you still have the DNS and temporary loss of service issues to contend with), so you want to do it as rarely as possible. But, you cannot safely run a server without regular security updates. You just can’t. Even if you carefully choose historically secure packages for your services (Postfix or qmail for MTA, OpenSSH for file transfer and shell access, Webmin for web-based administration, Dovecot for POP/IMAP, etc.) and carefully shut down every service you won’t be needing or firewall it down to just the hosts that need to talk to them, some security problem will pop up in the future. If you can’t easily upgrade that service within hours of the vulnerability being discovered, your system will be compromised, and you’ll be forced into a rapid migration to a new system, or trying to find a security consultant who can clean up the problem and paying the very high price that said consultants charge.

So, pick an OS with a long life cycle, and choose the most recent version of that OS. Debian has a very long life cycle. RHEL and CentOS have a very long life cycle. Mandriva and SUSE have a long life cycle (but I believe you have to get the paid versions to get the long-term support). Ubuntu LTS also has a long life cycle, but non-LTS releases do not, so you’d want to avoid any version other than LTS. Fedora, now that Fedora Legacy is gone, has a very short life cycle, and should be avoided for servers. I’m unable to find the life cycle of Gentoo.

I’m not kidding about life cycle. If you pay no attention to anything else in this article, pay attention to this advice. I’ve managed hundreds of servers in my life, and the single biggest pain point is updates and upgrade management and migration when updates and upgrades are no longer feasible. Avoid that pain as much as possible!

Package Management

Packages are great. They take away several major pain points in managing servers. So, choose an OS that offers good package management. The definition of “good” in this context is that it, roughly in order of importance: handles dependencies automatically, allows alternate software repositories so you can manage local packages or make use of third party repositories for specialized software, offers access to a wide array of “official” or at least nicely built third-party packaged software, allows you to make your own packages or customize existing ones, allows unattended operation and operation from scripts.

apt-get+dpkg and yum+RPM and urpmi+RPM are the best package managers available today, meeting all of those qualifications. After spending a couple of weeks porting our application and all of its dependencies to Debian 4.0 and CentOS/RHEL 5, I can say that Debian wins on the package management front, due to the sheer number of packages available in the universe repository. I like yum and RPM better from a technical perspective, and Fedora Extras makes it comparable to Debian on the package management front, but we’ve already disqualified Fedora due to stupidly short life cycle.

Ease of Management

Every Linux distribution has quirks that make it harder to use than it should be. In some cases, better ways are known and well understood, but historical behavior sticks around due to inertia and remaining compatible with existing users expectations. That said, there is value in predictability and good documentation. I find CentOS and RHEL to be the most capable out-of-the-box, and with quite sane management methods. Debian is also strong, but has a few historical stupidities, such as lingering reliance on START=yes crap in configuration files for some services. In a world where chkconfig has been around for years, this is foolishness. This is merely an example, and is a minor nuisance in any single instance, but by the time you’ve had to edit a dozen files just to get your services running (even if no configuration is required), it becomes painful.

SUSE has made a habit of changing major components of the system in every single revision. Package management on SUSE has changed in major ways three times in the past three revisions, and it’s still weaker than yum or apt-get. Configuration files move from one version to the next, and many can only be sanely managed with YaST. In fact, SUSE has a horrible habit of designing the underlying system for the convenience of the YaST developers. A specific example, so folks won’t think I’m just being bitchy because we build a management tool that overlaps with YaST in some areas: SUSE uses a firewall save format different from every other distro (which uses the standard iptables save file format). The SUSE format is less powerful, less flexible, more complicated to edit, and incompatible with all other firewall management tools. There’s no reason for this, except that it’s easier for YaST to modify a few variables in a shell script than to actually parse the iptables save file format and deal with it cleanly.

Webmin and Virtualmin nearly nullify the management problem, by abstracting it out to a nearly identical interface across all Operating Systems. But even with Webmin and Virtualmin, there are still differences that can increase the friction of going from zero to “in service”. I also like to know that when I hit the command line, the configuration files and mechanisms are sane and well-documented.

Documentation

Having good documentation is pretty darned important. And by documentation, I refer to every scrap of information that Google can dig up for you on a particular problem, not just the official documentation for the distribution. In this regard, the more popular an operating system for the tasks you’re performing, the more likely you are to find good documentation on the web.

The Debian official documentation is particularly verbose and particularly useless, and Ubuntu only marginally corrects that. The Debian documentation suffers from the same disease as man and info pages in the GNU system: No examples. Both are quite popular on servers, though, so one can often find good examples via Google.

The Red Hat, CentOS and Fedora documentation is much stronger, despite being less voluminous. The Red Hat based systems, are also the most popular, and so examples and discussions on the web abound. I’ve found them to be the easiest to find solutions for. If you’re new to Linux going with the most popular distro might be wise.

Gentoo has shockingly good official documentation with fantastic examples. The distro itself falls down in numerous other categories for server usage (pretty much all of the above, as far as I can tell), but the documentation is simply awesome. Whatever process they’ve used for their documentation ought to be replicated by the other distributions, because despite the youth of the Gentoo platform, it has far better official documentation than any other distribution. Hell, I need to spend some time studying how the Gentoo documentation project is run, so I can replicate it for Virtualmin and Webmin.

SUSE is far more popular on desktops than servers, and so server-related documentation is slimmer than we’d like. It is also less popular than Debian/Ubuntu and the Red Hat based systems, and so finding stuff on the web is less likely. The official documentation is of good quality, but again, there is simply less topic coverage.

Mandriva also has reasonably good official documentation, though it also is more popular on the desktop, and so much of the official and unofficial documentation is focused on things that we, as server administrators, don’t care about.

Your Use Case

This one is more difficult to give advice on, because it depends on what you’re doing with your system. If you’re a .net developer, you might look to SUSE, because Mono is a core part of that system. If you like Python, you might consider Red Hat or CentOS, because Python is an important part of their system and thus the packages are well-cared for in the official repository. Perl is well-supported by all of the distributions (though Mandriva and Debian have the most official packages for various CPAN modules), and Ruby is equally poorly supported by all of them (though Debian 4.0 seems to have improved remarkably on this front). Debian and Ubuntu are particularly strong on PHP, as they provide official packages for both PHP4 and PHP5, and they can co-exist on the same system (it took me weeks to replicate this capability on the Red Hat based systems).

So, what are you doing with your server? Search the web before making your OS decision to see if others are using one particular OS more often for tasks like the ones you’ll be tackling. This is a variation of the old “it’s the applications, stupid” rule. If all of your necessary applications are being used heavily on a particular OS, like maybe by the developers themselves, you’d be well-advised to pay attention to that.

In our case, we are heavily invested in Perl development, so our options are pretty wide open. We also use Joomla for our new in-development website, so we need reliable PHP support. Another, particularly difficult, piece of our puzzle is that we need a virtualized server to run our demo on, so native support for virtualization would be nice. We currently reside on a Red Hat Enterprise Linux 4 server, but if I were choosing today, I’d probably select Debian 4.0 on the strength of the universe repository. But, that’s just me.

Y’all pick your favorites, and let me know what criteria you use, but try to avoid “I like it because it’s easier to X”, because that intangible quality is almost always a function of what you’re familiar with…I’ve tried to steer clear of familiarity as a basis for selection, since there are far more folks who don’t have familiarity with any particular Linux distribution than there are that do.

I’ve noticed an interesting trend among our customers…the developers start really small, but buy more over time. Sometimes a lot more. This makes sense, of course, since freelance developers move from project to project and each new project has a new budget and a new server. Our product makes managing a server and the websites on it really, really, incredibly easy and fast, so folks who’ve used it end up using it on every web server they deploy. We’ve had dozens of web developers buy our cheapest offering one month and the next buy two or three of the more expensive versions.

Developers are also more demanding than most customers. They recognize when difficulties they are having are failings of the software rather than failure of their knowledge of the subject matter (generally), and so they file more bugs and ask harder questions. So far, you’re probably with me that developers are awesome users.

They also have some flaws, as users. They want things that are only useful to other developers. And I’m not just talking about APIs here. APIs are awesome, of course, and we’ve got APIs all over the place, and you should, too. But sometimes there are opportunities for making a product more useful to developers just by the features that you include.

An example in our product is support for private IP addresses, dynamic DNS, and the ability to operate correctly behind a NAT firewall. This is actually quite a bit of code to support, and I was reluctant to add it. Our product already has too many features and too many options (flexibility can be a curse…but it’s also nice to always be able to answer “yes” to the question “does you product support X?”, so it’s a wash), so adding a bunch of stuff that’s only useful to web developers on their development servers in their home office seemed maybe a little crazy.

But, we did it anyway (OK, Jamie did it without really consulting with me on it, because his thought process on just about any new feature is, “yeah, I can do that” and then he does it that evening and launches it the next day). And, it turns out I was wrong. It’s worth the effort, the additional support expense, and the added options, because developers and IT are the key to customers for any technology product. If the nerd working on a project likes you and finds what you do valuable, they will recommend it at every opportunity within their company, or on every project they work on if they are contractors. If you save the IT department, or contractor, time and repetitive effort, you will have the whole company using your product in short order.

From here on out, when one of our developer customers has a request I’m going to think long and hard before dismissing it as too much of a niche feature. If I can visualize a large number of web developers across the world breathing a sigh of relief when we roll out such a feature, then we will roll it out. Our primary customer will always be web hosting providers, the bigger the better, and their usually non-technical end users. But, if we piss off the developers who actually build the websites, I’m certain we’d regret it.

So, what’s the punchline? What can you do about it? Well, if you’re building a web service that’s useful to a large segment of people, you may have built something that can save the IT departments in major companies time and repetitive effort. An obvious example of a fellow Y Combinator company is Wufoo. They make a really nice form builder service. Seems simple, until you realize how many forms could be used in day to day operations of most businesses…got a trip to plan and need to know who’s going? got a software audit coming up and need to know who’s using what products? got T shirts to distribute to customers and need to know where they are and what sizes to send out? Wufoo’s got it covered and you don’t need to bother your IT department about building another stupid form!

Online office productivity software is another obvious example. Saves IT departments tons of time and effort. Getting PowerPoint or Office or whatever for a system that doesn’t have it is a PITA in most companies. File a requisition, wait for an IT to get approval from your manager, wait for IT to license it and install it, find out that it needs more memory or disk space, requisition more memory and disk or new computer, etc. Three weeks later, the project has come and gone and now you’ve got PowerPoint or Office and don’t need it anymore. If you’ve got IT on your side, they will instead say to their user, “Try Zenter, it’ll let you do a nice presentation right away.” Or Google Apps. Or whatever…lots of possibilities there for making the life of IT guys better.

As I mentioned in a previous post, I believe the day is coming in which there will be an upset in the roles traditional media and polling play in elections, where they will be replaced by the Internet. I don’t know if we’ve reached that day yet, but there is a striking disparity between the two sources of data regarding Ron Paul.

Ron Paul’s website is trouncing the other Republican candidates in visitors, despite being a crappy website:

He’s also beating the leading Democratic offerings:

He’s also winning, or coming in second, on many online or SMS polls regarding the Republican debates.

MSNBC’s California post-debate poll

Fox’ Post-Debate Text Poll (following Rudy Giuliani’s 9/11 outburst)

Paul is the top search on Technorati’s blog search:

But, in traditional polls, Paul is consistently fourth or fifth, after Giuliani, Romney, McCain, and sometimes Thompson (I can’t keep up with which Thompson), with single digit percentages. So, where’s the disparity? How can there be such a big difference? Traditional polling uses land line telephone calls to likely voters. I don’t have a land line. I don’t know anyone, other than my parents and my older sister, with a land line. So, a good percentage of people under about 35 are under-represented in these polls. That’s probably OK for accuracy on the lower end of the age scale, since the people least likely to have a land line (those under about 24) don’t vote…so the skew might be good for overall accuracy. But, telephone polls have become less likely to predict outcomes in elections over the past few election cycles. Internet polls have never been accurate, but maybe they’ll become more accurate as more people begin to get all of their news online and identity becomes more solid on the Internet. Interesting that the mainstream sites are far less likely to know how accurate their voting is than sites like Reddit or Digg or Slashdot, simply because readers aren’t involved in the process and so are unknown anonymous readers rather than editors and participants.

Anyway, despite all that we’d like to think about Democracy in America, the fact is that the candidate with the most money to spend generally wins. Paul isn’t bringing the big bucks, since he isn’t in any corporate pockets like the other candidates, so probably couldn’t win against a fat-pocketed corporate shill. His nomination could save the GOP from itself, however, and would certainly go a long way to convince me that it’s worth saving. Hell, I’d be proud to call myself a Republican if Ron Paul were the nominee. Otherwise, I guess I’ll have to vote Democrat…at least they haven’t been in power long enough to gerrymander, commit voter fraud on a wholesale basis, and otherwise use every despicable trick available to them to win elections at any cost.

I’ve been in the planning stages of a new product for Virtualmin users (and eventually for anyone who has a web server), which would predominantly run on on our servers. It would be our first application that allows us to choose the implementation language (our current codebase is over nine years old and includes hundreds of thousands of lines of Perl…we won’t be changing languages for our installable products, though we do look forward to Perl 6).

This got me to thinking about language popularity. PHP is, by far, the most popular language for the web. It’s also the worst among the popular choices. At least it’s the worst by every metric I consider important…except one: Availability.

PHP syntax is horrible. The vast majority of PHP code in the wild is horrible. The PHP standard library is inconsistent from top to bottom. It encourages bad practices, and dangerous behavior is the default for many PHP functions. Only in the past few years has PHP acquired the ability to safely and sanely use databases. The database problem is the cause of a huge percentage of the horrible PHP code in the wild…and folks are still writing code using the ugly way to access databases, despite better ways existing, because it’s all they’ve ever seen. PHP code, in general, is hard to maintain, hard to read, and often poorly documented (again, a lot of the documentation covers historic techniques that are simply dangerous). The object system is bolted on. It has no functional programming constructs to speak of.

So, why the heck is it so pervasive? Why on earth would smart people choose to use a language that is less effective for almost every non-trivial task in web development? And, I should be clear, smart people do choose to use it, and some fantastic applications have been written in it. This isn’t a situation where a bunch of idiots are using it because they don’t know better. Some of the coolest web applications are written in PHP, by some of the coolest developers working in the field.

The answer, and an answer that the Ruby On Rails folks, Pylons folks, Django folks, Perl Catalyst folks, etc. should all pay really close attention to (assuming they want their apps to be widely used), is that PHP is pervasive because it is pervasive. Tautology, I know, but what I’m trying to get at is that people code in PHP because they know it will work wherever they go or whoever they hand it off to. They know every web developer will be familiar with it, and will have access to a webserver that can run it. They know it will run on the cheapest DreamHost account, the midrange TextDrive account, or the most expensive RackSpace managed server, without modification and without jumping through too many hoops. They also know that if they have to hire someone to maintain it, or round up a community of users to help add features, there are no shortage of knowledgeable developers (it’s hard to find the good ones, as in any language, but some things don’t require good developers). Further, it’ll be reasonably fast, if they don’t do anything stupid or pathological with databases or files.

In short, if you want your installable application to be used, probably the single most useful thing you can do is write it in PHP. You also need to make it do something good, of course, and without huge glaring bugs. I’m guessing, but based on UI studies that show that for every field you add to a form, the completion rate drops by a huge amount (an order of magnitude in some extreme cases), I believe that an installable PHP application will initially get ten times the users of a Ruby On Rails application that does the same thing. I don’t have numbers to back up this bold assertion, of course, but I’m pretty sure that’s the way it will play out, unless and until Ruby On Rails is as pervasively available as PHP (which is unlikely to ever happen).

I don’t like this fact. I’m obviously not a fan of PHP as a language. I can’t think of a commonly used web development language that I would choose PHP over from a purely technical standpoint, except Java or C# (and even those have certain areas where they are particularly strong and well-suited for the task). But if I were building a small application (by small, I mean anything under 50,000 lines of code) that I wanted thousands of users to install, I would probably write it in PHP.

Of course, I’m not building an installable application this time…so I’ll be picking among the languages I like (Perl, Haskell, Python, Erlang). But my moments of blinding insight are few and far between, so I thought I’d share this one with the 12 people that visit my blog.

I’m feeling very independent-minded these days about the upcoming elections. What with the leading candidates from both parties serving a master that I can’t quite see and definitely don’t understand, it’d be impossible to feel anything but disenfranchised. But there’s something interesting happening on reddit, digg, and You Tube: Independent-minded candidates Ron Paul and Mike Gravel are getting a lot of attention. They resonate with a pretty big bunch of people. I’m not talking partisan politics here. I’m talking about a couple of guys who surprise us with their honesty, and their sincerity.

So, when I stumbled upon this story at the Daily Kos (not something I read very often…I saw it on Reddit) it really hit me that this could be the best and most important election year in my lifetime. Now, I’m not imagining that the big party politicos are going to accept either of these guys. And, they’ve raised so little money that it’s almost laughable to think they might make it to the primaries, much less take the nomination. But, the day is coming when the Internet is going to decide a national election (some say it’s already happened, in the form of voting shifts large enough to hand the office to another party…perhaps the Greens diversion of votes away from Gore cost the Democrats the election, perhaps not). Maybe this is the year.

My daily web browsing doesn’t include any overtly political websites, but Reddit does have its share of politics coverage. It’s probably biased. I’m probably completely out of the loop on who can be a contender. I get the impression that the mainstream media don’t want to cover Ron Paul or Mike Gravel. But maybe the mainstream media have reached the level of irrelevance needed to allow some independent candidates to rise to the top. I don’t know.

Anyway, the idea of an election pitting Mike Gravel vs. Ron Paul has me feeling a little light-headed. Y’all start talking about it. Get a bumper sticker or something. Really, tell your friends. (These guys are both solid on the issues that you, dear reader, and I almost certainly agree on: privacy, Internet rights, ending the war. Interesting how the two parties leading candidates are aligned against us on those issues, and yet I feel confident assuming you agree with me. Something’s wrong with that sort of system.)

I made a silly button:

OK, so I’ve read the existing articles about building bar graphs with CSS. All are great work. But they didn’t exist before I needed such a creature…and now that they all exist, I still need functionality that doesn’t exist in them. What, you might ask, could I possibly need from a bar chart that these examples do not provide? They look good, they’re generally clean, and they work in all (or most) browsers. Ah, well, we’re developing web-based system administration tools, and one of the things we do a lot of (and will be doing a lot more of in the future) is presenting data about the system to the user in a clear graphical form.

System data does not generally come in the form of multiple numbers to be presented in single part bars. No, more interesting is “how much is available and how much is used”, and even more interesting is, “what is it used for”. For example, we have disk usage graphs that use a different color for each type of usage: mail, web, databases, unused. Ah, so there’s the problem. We need a single bar with multiple elements, and so far, none of the examples provides that. Now, if you happen to be looking for a multi-segment bar CSS bar graph, today is your lucky day, because I’m going to show you two examples.

Example 1 (Apples to Oranges derived)

Note: I finally tested this on IE7 (I run Linux, so I’m using Wine and the ies4linux script to setup IE…IE7 didn’t work on my box until recently), and, of course, it looks atrocious. If anyone knows a fix, I’d appreciate hearing it.

The first is the most recently developed, based on the nice Apples to Oranges definition list example. It works well in all of the browsers I’ve tested except the bastard IE, in which it repeats a piece of the image vertically no matter how I try to stop it from doing so. Otherwise, these graphs rock.

Click here for the live example (which you can view the source of to see how it’s done). Now, in addition to the IE nastiness, there’s two other nasty things about it…you have to do math, and the order in which you insert the colors matters. Math is required because it’s the only way I could get the inner sections to display correctly. Otherwise they either drop below the bar, or they completely cover the bar, depending on how they’re styled. I would more than welcome fixes for any of those issues…but especially the IE thing.

I only used four colors in the example, but it scales out as far as you need just by copying the div.yellow or div.green section and changing the color.

Example 2 (I think I came up with this one all by my lonesome)

This one is a bit less CSS and more HTML, but it is also cross-browser and doesn’t even really require CSS (though, it too can end up going astray on IE–it’s unbelievable how little time I spend on web design work, and yet I still manage to hit IE bugs several times a day…I always thought web designers were just bitching). It does require tables, despite it not seeming to on first glimpse. In fact, I thought I would rip out the tables we use in our actual UI to simplify the example, but found that the images picked up some extraneous space underneath, because they are block elements and the browser is leaving room for tails on g and p and q!

So, here’s what it looks like:

Click here for the live example. This one is probably going the way of the buffalo in our UI because wrapping everything in tables is a thing of the past, so it’ll begin to look funny soon. Scaling this one out to more colors is too obvious for me to bother talking about, and you don’t have to do any math (beyond figuring out percentages).

As mentioned, this one also has an IE issue. Because IE is retarded, it’s easy to end up with oddly sized graphs…it doesn’t handle percentage sized tables, so if you use percentages in the wrapping table widths, you’ll get broken graphs.