A week or two ago, I emailed Ed at the Chronicle and asked a simple question: are you guys going to bring back the technology column? I’ve yet to receive a reply.

Edit/Update: I have heard through the grapevine that they do not have plans to bring the technology column back.

Atlanta is the most “wired” city in the world, according to Forbes Magazine (for the second year in a row). Money Magazine was quoted as saying that Atlanta has “a bustling community of Internet-related start-ups.” (thanks to Lance Weatherby for those 2 snippets). So why then does the Atlanta Business Chronicle forego technology coverage in order to continue to fill my driveway with piles of dead trees containing in-depth coverage of the real estate market (which we all know is tanking)? See Mike Blake’s recent presentation for some statistics on this …

Since TechLinks has evolved into a love fest for big company CIOs and sponsors, we have little-to-no traditional media coverage here (save for Tech Journal South, based out of RTP/Carolina, which tries to provide at least some coverage for us).

Come on guys … this is embarrassing. There is a whole new wave of technology players in Atlanta, and you are missing the boat. Then again, since most of us get our news online these days, maybe it doesn’t even really matter.

Cheers.

As pointed out by others, if this pace continues, it will easily be the best year for tech IPOs since 2000. Not bad.

I think another observation is warranted here. Most of the firms represented above are either in the network infrastructure or mobility sectors. These are both established markets that are resting firmly on solid ground. Contrast that to the IPO scene leading up to the shakeout in 2000, where you had a large number of companies going through an IPO that really should have never even been funded to begin with.

This is good.

Cheers.

For those who really still don’t get the movement, you owe it to yourself to watch this video. It is a bit long, but be patient – the payoff is worth it. This is done in the style of Lessig and Dick Hardt. Click the video clip below to play it.

Thanks to Michael Wesch, Assistant Professor of Cultural Anthropology at Kansas State University for putting this gem together.

Cheers.

Our informal discussions around scalability inspired me to jot down some of my thoughts on this issue, and how early-stage entrepreneurs can scale their technology platform from 5 users to millions.

Some Simple Rules

There rarely exists a set of rules that, if followed, will result in nirvana – scalability is no different. Every situation is different. However, these bullets summarize my general tenets, mantras, and beliefs for scaling a web-based application or system. The rest of this post will cover these in a bit more detail.

1. Abstract your logical architecture into at least 3 tiers (web, application, and data)
2. Even if you are only using one or two servers initially, think/design as if you have 50.
3. Designing with an SOA (services oriented architecture) in mind up front will aid you in scaling down the road.
4. Don’t overlook the scalability of your network infrastructure – your servers may be running at only 25% capacity, but if you don’t have the throughput and bandwidth to handle large amounts of traffic, those souped up servers won’t help you.
5. To help remove common/special cause variation – move system services such as DNS and e-mail off of production web/app servers and onto other, dedicated servers, and disable all non-essential services.
6. Scale vertically first, wherever possible, to control costs. But only do so if the benefits are greater than the cost. Early on, putting extra resources into an existing server is probably cheaper than procuring additional servers.
7. Scale horizontally when vertical scaling begins to produce diminishing returns
8. When upgrading/replacing existing servers, replace lesser horsepower ones first – and cannibalize components wherever possible (to control burn)
9. Performance tuning is not a one-time activity – it should be an iterative process
10. If you don’t have solid system administration capabilities in-house, outsource it immediately
11. Daily reporting is a must. You can’t know when/how to scale if you don’t know the landscape at any point in time.

What is scaling (or scalability)?
Simply put, scalability refers to an system’s ability to handle increasingly heavier loads from users (activity) without fundamentally breaking the way in which it operates. In other words, as you continue to add new users and expand your business, you want your application or service to be able to easily handle the increase without slowing down, or worse, breaking down completely.

An application (or platform) is considered scalable if it can continue to service additional users, through the deployment of supplemental hardware/software/resources, without seeing any significant performance hit from the user’s standpoint. Of course, very few systems in their early prototypical states will fit this definition. Your goal is to get the product to the point where it can be scaled in this manner, while reducing the number of potential bottlenecks.

Unfortunately, for business and IT managers, there is no single way to scale an application. Ah, if only there were actually a big red “easy” button. Each situation is different, given that there are so many factors that need to be taken into account. To make matters worse, sometimes, an application seems “infinitely scalable”, only to have a major bottleneck reveal itself down the road. This doesn’t mean the end of the world – it simply means that you have to adjust accordingly. The trick is, of course, to reduce the number of “midcourse corrections” that you will have to endure.

A Bit About n-Tier Architectures
Before we dive in too deep, I should probably throw out a note or two on n-Tier architectures. If you are an IT weenie, and understand this concept, skip to the next section. Otherwise, hang with me.

In the old days, applications were deployed onto servers, and when a bottleneck was encountered, the physical resources in the machines were expanded. This was the extent of scalability. Then, some bright engineer realized that if you split a system into two “tiers”, you could distribute the workload a bit. Voila – the birth of the client/server revolution. Eventually, though, systems began to grow so large that they needed something else in order to break through the inherent bottlenecks of a 2-tier system. An even brighter engineer realized that there was no reason to stop at “2″ tiers. You could have an arbitrary number of tiers in your system. Thus, the birth of the “n-Tier” architecture (“n” representing some arbitrary number of tiers).

An “n-tier” application architecture is characterized by the functional decomposition of applications, service components, and their distributed deployment. By breaking a system down in such a manner, it provides for improved scalability, availability, manageability, and good resource utilization. A “tier” itself is nothing more than a functionally separated hardware and software component that performs a specific function. Whew – what a mouthful.

Typical “tiers” include:

• Web server tier: provides HTTP protocol support (i.e. handles web requests)
• Application server tier: provides support for web services, business logic, etc. (e.g. web services/SOA)
• Database tier: provides data storage and retrieval support (e.g. Oracle, MySQL, mainframe/VSAM, etc.)

Note: don’t confuse these “tiers” with application “layers” (presentation layer, data layer, business logic layer, etc.) Tiers are architectural in nature, whereas “layers” are generally code/library specific.

The important thing to know here is that in an “n-tier” model, a system has been broken up into various levels of functionality, each capable of some degree of horizontal scaling. Which brings me to my next point …

Horizontal vs. Vertical Scaling
When you hear people talk about “scaling horizontally” they are essentially referring to the ability to add new servers to a tier to allow it continue to provide uninterrupted service in the face of continuously increasing usage. For example, your database is chugging hard and heavy, so you can add new servers to the database tier to distribute the workload. If your web server is bogged down, you can add new web servers to do the same. This also affords you with a nice layer of failover as well. If one server experiences an issue (even to the point where it crashes), you have other servers online in that particular tier that can still provide service. This concept is becoming increasingly important as more and more systems are being deployed using SOA models (service oriented architectures).

One great example of horizontal scaling can be seen in Amazon’s new “Elastic Computing Cloud” (my old friend Chris Brown is a patent co-inventor and senior engineer on that project).

Vertical scaling, on the other hand, is where you extend/expand the physical resources in a server itself. For instance, your database server is getting way overworked, hitting the swap space early and often. You can “vertically scale” that server by simply adding more RAM, faster hard disks, better CPUs, etc.

There are benefits/pros/cons to each type of scaling. Obviously there is a cost associated with both. Horizontal scaling is theoretically infinite, whereas vertical scaling has an obvious ceiling (there is only so much horsepower that you can derive from a single server).

Horizontal scaling only makes sense if the service you are attempting to scale was designed to be extended in this manner. For many third-party applications, such as a database server, this will be the case. Of course, if you are designing the software, you will want to take this into account as you build it.

Think of hardware as simply a vehicle (perhaps a bus) for your software, your real service. If the bus gets too crowded, you add another bus to the fleet. However, not all buses will go to the same destination, so those buses need to connect together in order to get information from point A to point B within your architecture. Voila, you have the meager beginnings of a service-oriented-architecture (SOA).

A Scalability Example
Let’s set the stage with a typical early-stage example, and we’ll try to scale this application theoretically as the business scales.

John is an aspiring technology entrepreneur who has developed a really great online service called WidgetFire. WidgetFire is brand new, so there aren’t many users yet. John has built this product in his spare time, and is bootstrapping the business via his day job as a software engineer for another company. To keep his costs down, he has a single web server (built from extra parts), and he has it co-located at a local data center with a basic level of service (1U single rack space, 1Mpbs throughput, unlimited bandwidth, for probably < $100/month). On this single server, he is running Apache and MySQL together, along with the normal services (bind/DNS, sendmail, etc.)

So far, scalability is not a concern to John. But that is about to change. In a big way.

Over a period of a few months, John leverages word-of-mouth marketing and manages to aggregate 25,000 registered users for his service. The server he is running (which he’s affectionately nicknamed “Seabiscuit”) is holding up fine, but is beginning to feel the strains of all of those new sessions and database queries. Additionally, his automated e-mail notification list is starting to add to the system load, as now the server is sending out thousands of emails a day.

John “vertically scales” his server by adding some additional RAM and performing some additional performance tuning to the database. This buys him time. But not much.

Then, WidgetFire gets a mention in a prominent tech blog, and the next thing John knows, he has 100,000 registered users for his service. His server is on its knees, and practically unresponsive. Sadly, the data center staff isn’t much help – after all, he is running under a pretty basic co-located hosting plan – and they have bigger problems to deal with than the occasionally unresponsive Seabiscuit.

So John then moves to a very rudimentary n-Tier architecture. He moves his MySQL database over to a separate server, which frees up resources on the old web server. Now, the system is humming along smoothly. But after a few months, WidgetFire is quite the rage on college campuses, and John must once again address how he is going to facilitate additional traffic.

He does some vertical scaling on the database server (adds new RAM, faster disks, etc.), but it isn’t enough. The new user signups are coming too fast and furious for his 2 server setup to handle.

This particular nexus is where many startups begin to experience some tough scalability issues. The “easy” scaling options have already been exhausted (vertical scaling on one server, splitting the database off into a separate server.)

Fortunately for John, his traction has caught the interest of a handful of investors, and he is able to secure a small round of outside capital.

To get to the next level, John implements a load balancing router, an extra web server, and an extra database server. He configures the load balancer to distribute incoming web requests evenly between his two web servers. Additionally, he configures the original database server to be a “master”, and the new database server to be a “slave” server. While all database write operations occur on the master server, John realizes that most web requests that require database access will be for “reads”, so the slave can offload some of that workload from the master. Voila – he has scaled even further!

A few more months go by, and John makes the cover of Wired Magazine. VCs are clamoring to pour their cash into WidgetFire. While John basks in this glory, he doesn’t realize that his little server farm is becoming overwhelmed by the sheer success of his venture. To make matters worse, while John is putting together a plan to scale even further, his slave database server crashes, leaving only the one original database server in operation. WidgetFire is basically dead in the water.

John brings the slave server back online, but he realizes that more must be done. He adds an extra web server to the web server tier, and adds an additional slave database server to the database tier. But he doesn’t stop there. John realizes that his actual application, which is comprised of a mish-mash of Java, PHP, and Perl, is utilizing the vast majority of CPU time on the web servers themselves. John decides to move from a 2-tier model to a 3-tier model by implementing an “application services” tier. He moves this code off of the web servers and onto several new servers.

John realizes pretty quickly that his original code design really wasn’t architected for this type of model. He has to spend a couple of months retrofitting his old code to fit into more of a “web services” model. He is now surrounded by burgeoning IT costs, hosting fees, and system complexity. All of a sudden, his “Google-ready” venture is giving him a headache, and isn’t much fun anymore.

Of course, had John anticipated the steepness of his growth curve ahead of time, he could have designed his system with it in mind, and avoided at least some of the headaches.

Can’t money be thrown at the problem?
Sure. To a point. All things cost money, of course, whether it be labor (people), hardware, or software. Most systems can initially be scaled to a sufficient level by simply adding more hardware, or expanding the resources within the server. But that only gets you so far in most cases – at some point the logical architecture of the system needs to have been designed with scalability in mind. If the architecture isn’t scalable, you are either going to hit a ceiling, or spend way too much money to scale it (and even then, there are no guarantees).

It isn’t a question of whether or not money can be thrown at the problem – it all costs money. The question is how much money are you going to have to spend to scale it? Obviously, there rarely exists an endless supply of capital that can be leveraged to solve a scalability problem – especially in the startup realm. Clearly, you want to be able to control your tech spend (which is a big part of your overall burn).

The bottom line is this: If you plan for scaling initially, instead of throwing a bunch of crap together and hoping it will get you to point “B”, the less money you are going to spend as you scale.

To properly address scalability, you have to take a holistic approach, and examine your architecture, your software components, and your hardware configurations. Then you have to deploy capital in an intelligent manner. Otherwise, you could end up like John in our fictitious example – sitting on a pile of code that really wasn’t designed to split up into services across an n-tier architecture. And that, my friends, represents a serious misuse of capital.

If you are scaling by adding new hardware – that is generally a good problem to have – that hopefully means your business is expanding. However, if you are having to rewrite large amounts of code in order to scale – you’ve likely made some very serious mistakes. Too many of those mistakes, and you’ll be dead in the water. You see the latter quite often in the startup world, again, as there is so much pressure to slap something together and get it out the door.

Architectural Concerns
It all starts with the blueprint of your architecture. Note, I am not referring to your functionality matrix/map, your application requirements definition, etc. I am talking about your physical and logical architectures.

When I say physical architecture, I am referring to the physical hardware components that make up your network, application, etc. Things to consider:

• What are your network capabilities? Throughput, bandwidth, etc. Are these scalable from a cost and availability standpoint?
• What are the capabilities and specifications of your web servers, application servers, database servers, etc.?
• How many of these servers do you have at your disposal? Are they dedicated or shared?
• What are your capabilities for handling increased DNS requests, e-mail volume (in and out), etc.?

When I refer to your logical architecture, I am referring to the way in which your various software components connect with and layer into one another. Things to consider:

• Are you properly segregating functional aspects of your application into easily managed and scalable services (e.g. SOA)?
• Are you isolating those services in unique hardware or operating environments?
• Are you building for the short-term, but planning for the long-term (i.e. how extensible will this thing be down the road?)

If you are in startup mode it is very easy to fall into the trap of “getting started” – pushing code and charging up the hill. “Get-to-market” pressure from investors rarely helps. However, many such efforts are met with stiff resistance once the entrepreneur realizes that the “hill” he or she just conquered is actually but a small plateau on a mountain comprised of increasingly steeper slopes. It all starts with a good plan in place!

Having the right architecture in place doesn’t guarantee that you won’t have to eventually add more hardware or write more code. Actually, in the early stages, you may actually spend more money (especially if you are deploying web services on their own servers, etc.) However, the proper architecture allows you to get the most out of out that new hardware and software, as you will be plugging it into a framework that was built with it in mind.

A Note on System Services
Before you start diving off into creating a true services oriented architecture, do yourself a favor and split your system services off accordingly. Things like DNS services and e-mail should be move off of and away from your application’s production environment. I bring this up because more often than not, you find system services being co-located on production web servers.

It is hard to get a sense of an application’s true load on a physical machine when you have a million other things running on it. This becomes even more important if you are planning on using tools like Six Sigma to measure scaling and availability metrics, as you will need to do everything possible to remove potential causes of common/special cause variation.

The Importance of Performance Tuning
Another very important aspect of scaling is performance tuning. Performance tuning is essentially the art of tweaking and fine-tuning your various applications and services in order to maximize their operational efficiency. There are more ways to performance tune a system than you can possibly imagine. Some obvious examples would include:

• Tuning your database server to use more or less RAM (for buffering, sorts, key lookups, etc.), adding indexes on data tables to decrease query times, etc.
• Optimizing your web server’s socket configuration to improve connection times

Some not-so-obvious examples might include:

• Enabling DMA (direct memory access) for a server’s IDE drives to improve seek times (you should be using 15K RPM SCSI drives, but if you aren’t … )
• Making sure your OS kernel (for UNIX/Linux) was compiled with only the services and features you require (i.e. remove kernel bloat)
• Mounting filesystems with the “+noatime” flag, which will prevent the OS from updating the (mostly) meaningless “last access timestamp” of every file you read or write
• Partitioning your OS so that system files, logs, etc. are on their own partition (or even a separate IDE channel or SCSI bus)
• Using the “strip” command to remove debugging/profiling data from common executables to lower their memory footprint (On UNIX systems)

I have known people who have spent thousands on new hardware, only to realize later that their applications or server/OS were simply not optimized. if you don’t have the requisite skills in house to do performance tuning, then outsource this function immediately – it is that important.

Finally, I should mention that performance tuning should not be viewed as a one-time activity. You should routinely profile and tune your systems (both hardware and software).

Network Scalability
Another thing to stay on top of is your service level agreements with your data center or hosting provider. There are fundamentally three or four things to keep in mind:

First, if you are bootstrapping a startup, and you are using a low-cost, shared server, you need to move to a dedicated server solution as soon as possible. Trust me.

Next, make sure that you have the ability to quickly secure additional rackspace and bandwidth as you need it. Having your data center tell you that you are going to have to suffer major downtime because they have to move your servers to a “bigger rack” is probably not a good thing.

Third, make sure that the connections from your servers to the net are burstable. When you have those huge traffic spikes because someone put a mention of your site on digg.com, Slashdot, etc., you’ll want to be able to handle the temporary increase in traffic (without necessarily incurring a large bandwidth bill).

Finally, make sure that your throughput is not capped, or if it is capped, make sure it is capped higher than you think you’ll need. Don’t confuse bandwidth with throughput. Bandwidth refers to how much data your connection can transfer over a period of time (e.g. 100 gigabytes per month, etc.) Throughput, on the other hand, refers to how much data can be flowing through your connection at any given time (e.g. 10Mbps). Think of throughput as being the thickness of your server’s pipe – obviously, a lot more can flow through a garden hose than a soda straw. Same analogy.

To illustrate the point on throughput; a few years back we had a system that began to be wickedly unresponsive. The CPU loads on the server were only about 35-50%, so it didn’t make a lot of sense. It turns out that the connection had been capped at 10Mbps. Anything over 10Mpbs at any point in time had to basically wait in the queue. This caused perceived “slowdowns” by users. Raising the throughput cap remedied the problem, of course.

On a final note, I want to voice my support for co-locating servers rather than using a full-service hosting provider. If you have the skillset in house to maintain the boxes, using co-location can save you some money, and give you more flexibility. Again, in startup mode, every penny counts. If you are in or near Atlanta, I highly recommend my friends down at Capital Internet. I’ve co-located and hosted servers with them for 6 years now, and it has been a very enjoyable, hassle-free partnership.

Advanced Topics
There are a lot of advanced topics that come up in discussions about scaling applications. Things like caching, high availability clustering, network storage (via SANs), and distributed networks. Obviously, those are very specific areas that are beyond the scope of this already ridiculously long blog post. Suffice it to say that there are some very advanced (and expensive) toys out there that can make scaling a lot easier. However, the vast majority of applications/services can be scaled to rather massive proportions if you simply follow the bullet points at the top of this post.

I came across an old proposal that I received from a vendor years ago (in the 1.0 days), and got a good laugh out of it.

We all know that things are cheaper to build these days, but I thought it might be interesting to put together a post illustrating the actual dollar differences in hardware, software, services, and labor costs. And yes, this is my last official post for 2006 – so happy new year in advance (4 hours from now!).

Preface

Note: I am using the phrases “Web 1.0″ and “Web 2.0″ to simply represent the passing of time.

The numbers that I am using to represent the Web 1.0 days are taken from a series of documents from a startup I was working with at the time. I am going to show those vendor dollars (and time components, where possible), and compare them to what my estimate would be if I were building that same system today. The focus, of course, will be on dollars, time, and trends.

The exact specifications of the proposed system are not important. For the purposes of this post, consider the proposed system to be a “typical” B2B/ASP procurement system. The only important criteria here at this point is that there should be a suitable “stage” environment, which would run parallel to the production environment.

These numbers only reflect hardware, software, and outsourced labor costs – they do not reflect internal IT spend (laptops, mobile fees, etc.), and do not reflect salaries of FTEs or other business-related expenses. I think it is safe to say that there were more than a few companies back then spending money on frivilous non-essential items.

Enterprise Software Costs
The original system was built on a stack comprised of ATG’s Dynamo web application server (with the personalization license add-on), and Netscape’s Enterprise Web Server. The backend was facilitated by an high-end Oracle database.

On the application side of things, we were building upon Oracle Exchange, which was Oracle’s attempt at fighting Commerce One and Ariba. It was *supposed* to provide a big pile of transactional and catalog management capabilities – it turned out to be a vaporous pile of ****, but that’s probably a post best left for another day.

Interwoven was the content management system (CMS) of choice, and Verity was selected to provide “search” capabilities.

We implemented a very high-end CRM solution built around Silknet’s product and Aspect’s ACD (call center) solution.

Component	Qty	Unit Price	Total
Oracle Database	1	120K	120K
ATG Dynamo	4	10K	40K
ATG Personalization License	4	20K	80K
ATG Development Seats	5	10K	50K
ATG Staging Licenses	4	5K	20K
Netscape Enterprise Server	2	1K	2K
Silknet	1	170K	170K
Silknet Maintenance (1st year)	1	34K	34K
Aspect ACD	1	250K	250K
Aspect Maintenance (1st year)	1	41K	41K
Oracle Exchange	1	825K	825K
Interwoven Bundle	1	90K	90K
Verity Bundle	1	120K	120K
			$1,842,000

We launched HiddenMarket into public beta yesterday! At several points yesterday, I was asked how I felt (by various people). Here are some of the words that I used to describe that unmistakable range of feelings:

Tired/drained/spent, hungry (literally and figuratively), excited/thrilled, pumped/stoked, blessed/fortunate, pissed off/chaffed, curious/anxious.

You don’t really know whether to love it or hate the experience. It simply is what it is. I suppose it is a bit of both.

The way to get started is to quit talking and begin doing. — Walt Disney

The requisite goofy post-launch self-portrait of Jerry and I.

HiddenMarket Launches First Social Business Intelligence Network

HiddenMarket Group, Inc., an Atlanta-based technology start-up, launched the open beta of HiddenMarket.com today. The free, first-of-its-kind social business intelligence network helps members tap into the vast “hidden market” of business news, information, resources, and opportunities.

HiddenMarket Founder and CEO Scott Burkett explained, “70-80% of job openings aren’t posted in the public domain and word of mouth is a key driver of informal sales leads, business intelligence and business opportunities. Even the most dedicated networkers can’t be everywhere. So in spite of someone’s best networking efforts they could be missing out on the perfect job, or the sales lead that could turn into their biggest customer.”

“Everyone knows that networking is the surest catalyst for career and business success,” said Jerry Recht, HiddenMarket Vice President of Business Development. “The key to successful networking is the groups with whom people affiliate, from professional trade associations to church groups to alumni associations. These groups provide an environment where individuals connect based on shared values, interests and objectives. Those connections lead to mutually beneficial relationships where exchanges of valuable information take place.”

The key to HiddenMarket’s success, the founders believe, is a unique model that simulates a real world networking environment. Individuals join the HiddenMarket community according to the groups with whom they are affiliated. They also have the option of joining as individuals or creating their own groups. Members decide with whom they want to share information, whether it’s just one individual, people on one or more of their friends lists, one of their groups, several groups or the whole community. Conversely, members can receive information based on criteria they define to ensure they only receive information that is relevant to their interests and objectives.

The way Burkett sees it, “Most business networks are essentially databases. HiddenMarket is a community. By leveraging the power of the Internet to facilitate relationships we think HiddenMarket.com has the potential to transform the way people do business.”.

Cheers.

Each year, the Technology Association of Georgia (TAG) (through a partership with the Business & Technology Alliance) uses its Excalibur Awards program to recognize those tech-enabled companies that are leveraging technology to create competitive advantages. This year’s award winners:

Macon E. Gooch III Building Consultants (small organization category)
Intercontinental Exchange (medium organization category)
Southern Company (large organization category)
Georgia Innocence Project (creativity award)

You can read the official TAG press release here.

Additionally, the audience was treated to a fantastic keynote address by Matthew Szulik, CEO of RedHat. To the enjoyment of everyone, Matthew articulated very clearly the cultural aspects of the open source movement. After the ceremony concluded, the crowd continued networking, with some folks staying until nearly lunchtime! By the way, if you haven’t seen RedHat’s “Truth Happens” video clip – check it out here.

HiddenMarket sponsored a table at the event, and we had a great group of our friends, colleagues, and associates hanging out with us. That is the really fun thing about networking events – bringing really interesting people together so everyone can expand their business horizons.

From left to right: Mike Blake (Adams Capital), Alan Urech (Stoney River Capital), Mitch Free (CEO, MFG.com), Scott Burkett (CEO, HiddenMarket), Anne Simons (brandsizzle), and Nelson Chu (Kinetic Ventures). Not pictured: Andy Monin (CEO, Vendormate), Stephen Fleming (ATDC/GA Tech/VentureLab), Jim Williams (The Certus Group), Jerry Recht (HiddenMarket).

The TAG Excalibur Awards are quickly becoming a staple part of the Georgia technology scene, and they are a phenomenal way to recognize the people who really matter in this business — the end users! I was proud to be a part of the Excalibur Awards steering committee this year, and I am excited about our prospects for continuing to build this program. I definitely encourage technology leaders in other cities to consider running a similar program.

If you are a technology company, forget about trying to win those “me first” awards. Who cares if you are the “best technology provider in your class?” Instead, I encourage you to do your part in getting your customers to win awards such as the Excalibur Awards. If they are using your technology to improve their bottom line, and are getting accolades because of it, that speaks volumes!

I do want to take a quick second to plug the efforts of Tino Mantella, the current President of TAG. Through his leadership, TAG is once again establishing itself as the centerpiece of the technology industry in the state of Georgia. TAG has certainly been plagued with its share of issues over the years, but I think we are seeing some positive momentum under Tino’s stewardship.

And of course, no mention of TAG would be complete without also recognizing Laura Heinlein, (TAG’s Membership Development Director) who is arguably one of the most organized people I’ve ever known. Susan Stottlemyer, the CEO of Association Planners of Georgia was on hand as well, and once again delivered a great event to her customer (TAG). Marc Fleury, former CEO of JBoss and now RedHat VP, did a great job in chairing the event this year.

See you next year!

Cheers.

These were all taken from my own experiences. I’m sure that other folks have some good ones, too. Feel free to pile on by adding a comment down below. ;)

1) If you’ve ever had to do this:

or this:

Bonus points if you still remember what those old Hayes-compatible modem registers actually did. Deduct points if you have never actually used a modem, because the only thing you remember is broadband. Deduct additional points if the slowest modem you’ve ever used personally was a 9,600 baud modem.

2) You not only know what a FOSSIL driver does, but you also know that it stands for Fido Opus SEAdog Standard Interface Layer. You get bonus points if you actually know who Tom Jennings, Ray Gwinn, and David Nugent are. If you thought BNU was a better FOSSIL driver than X00, give yourself 5 extra points.

3) You remember how utterly earth-shatteringly cool it was to toggle back and forth between two tasks using DESQview.

4) You remember fighting tooth and nail to convince your boss that Visicalc would be a worthwhile tool to have laying around at the office. Bonus points if you know who Dan Bricklin is. Additional bonus points awarded if you were able to convince your boss successfully.

5) You remember how ticked off you were when your only CP/M boot disk went bad. Bonus points if you ever booted CP/M (or anything for that matter) from an 8-inch floppy disk. Deduct points if the only diskette size you’ve ever seen is a 3.5 inch floppy. For those of you that have never seen an 8 inch diskette (or god forbid, a 5 1/4 inch diskette), see the image below comparing them all. Nice, huh? :)

6) You remember how much of a quantum leap it was when you upgraded from XModem to YModem, then to ZModem. You get bonus points if you remember using Kermit or uucp from the command line. Additional points awarded if you know who Ward Christensen and Chuck Forsberg are.

7) If you considered performing Fidonet FREQs (File Requests) as an early version of P2P networking. Bonus points if you remember how long it took to download the latest version of Binkleyterm, Maximus, or Frontdoor via FREQ over a 2400 baud modem. Additional bonus points if hearing the names of Scott Dudley, Joaquim Homrighausen, Vince Perriello, Bob Hartman, and Andrew Milner make you smile.

8) If you remember how much devastatingly faster the “new” 1200 baud modems were (as compared to your old 300 baud unit). You get serious bonus points if you’ve ever used an acoustic coupler.

9) If you remember going through hell and high-water to get the COHERENT operating system running on an Intel 8088-based computer, only to be utterly frustrated when you realized that it didn’t have a native C compiler or a TCP/IP stack (that didn’t cost you extra, I mean). You get bonus points if you remember upgrading from COHERENT (or Xenix) to Minix. Additional bonus points if you’ve ever corresponded via e-mail with Andy Tannenbaum.

10) If you remember the old MFM, Winchester, and RLL format hard drives. You get bonus points if you remember that they weighed 25 pounds each, took 60 seconds to spin up, and only held 10MBs of data. Additional bonus points awarded if you’ve ever freed up stuck mechanical heads in a Winchester drive by repeatedly smacking it on the side with a thick-handled screwdriver (a nod there to my old pal, Kruges).

11) If you know the difference between a blue box, a beige box, and a red box. Bonus points awarded if you’ve ever used any of these (deduct 5 points if you were ever caught.) You get additional bonus points if you remember John “Captain Crunch” Draper.

12) You remember having to upgrade the UART chip in your serial ports from an 8250 to a 16450 or 16550A in order to prevent dropoffs.

13) You not only know what a “Duff’s Device” is, but you’ve used it in production code. Bonus points awarded if you’ve ever submitted code to the International Obufscated C Code Contest (IOCCC). Additional bonus points awarded if you enjoy sitting around in your spare time unravelling other people’s obfuscated C entries.

14) You have not only been to the GUE (Great Underground Empire), but you went back several times. You get bonus points if you actually know the meanings of the words “Zork” and “Frobozz”.

15) You’ve ever daisy chained several 1541 floppy drives together and ran a BBS. Bonus points if you ran a BBS from your Apple II and kept the cover off of it half the time.

16) You learned 6502 assembler programming from the master, Jim Butterfield.

17) Much to the dismay of your wife, you don’t have to heart to throw away your old Timex Sinclair, Commodore (PET, C116, C64, C128, or VIC-20), Kaypro, Texas Instruments (TI-99/4A), Heathkit, or Osborne. Bonus points for even knowing what these are anyway! Additional bonus points if you thought the 5 inch monitor built into the Osborne was “more than enough.”

18) If you ever hooked up an 8-port (serial) DigiBoard, and ran Wyse terminals all over your house so you could monitor your (UNIX, COHERENT, Xenix, SCO, Linux et al) system from most any room. Bonus points if you did this in an apartment and had to pay to repair the sheetrock from the damage caused by running those thick serial cables (especially those Digiboard “octopuss cables”) through the walls.

19) You vividly remember the day they took your favorite pinball machine away from the [bowling alley | arcade | pizza parlor ] and replaced it with Space Invaders, Pong, or Asteroids. Bonus points if you ever played the coin-op Space Invaders so much that you heard the ominous background sound of “dum dum dum dum” in your sleep. Deduct points if you paid money for the Buckner & Garcia album featuring “Pac Man Fever.”

20) You remember how huge the Sperry / Burroughs merger was (forming Unisys). Bonus points if you ever actually used a Sperry or a Burroughs system.

21) BONUS: You ever developed something comprised of at least 100,000 lines of Fortran, Assembler, COBOL, or C (not C++ or C#). Bonus points if your code was put into production somewhere and is still running. DEDUCT points if you ever programmed in LOGO, and thought it was the next big thing, or if you used Pascal and got all worked up about it.

22) BONUS: You ever mounted a magnetic tape reel in a mainframe data center while smoking a cigarette in your mouth, and juggling a hot cup of coffee.

Some fun links for you:

• Erik Klein’s Vintage Computer Site
• Heathkit Virtual Museum
• Obsolete Technology Website

Cheers.

From their web site:

The Uptime-Project is a Fun-Project. Using our service you can collect all your uptime-data (your computer’s uptime) and compete against other users.

I decided to sign up for fun with one of our custom-built (dual Xeon) Linux development servers. We debuted within the top 50 (out of nearly 12,000 registered servers). Here is a screen shot (via SSH) of our current uptime on that box:

495 days, or, 1 year and 130 days. Not bad! At least, I thought so, until I saw the guy sitting at number one. His SunOS box has been running non-stop for over six (6) years! Madness!

The downside to all that uptime, though, are the obvious security issues … surely at some point, you’d need to upgrade the kernel and do a reboot. The top guy is basically running a six year old operating system. That is the equivalent of running Windows ’98 on your desktop here in 2006.

Check ‘em out at: www.uptime-project.net

BTW, that hostname is “rampage” – a nod to my old Army unit (3d Battalion, 64th Armored Regiment … the Rampage battalion!) If you are curious, the specs on Rampage are:

• Custom built 2U rackmounted server
• Dual Intel Xeon 3GhZ processors (with hyperthreading – 4 virtual CPUs)
• 4GB RAM
• 15K rpm SCSI RAID array
• Running Linux 2.6.xx SMP

Cheers.

See the “Mosquito” bit below. If nothing else, this is a great illustration of innovation and entrepreneurship – in both directions. Repurposing is a great thing. Now, if only I could figure out a dual-use for my old pet rocks. ;)

Students find ring tone adults can’t hear

NEW YORK – Students are using a new ring tone to receive messages in class — and many teachers can’t even hear the ring.

Some students are downloading a ring tone off the Internet that is too high-pitched to be heard by most adults. With it, high schoolers can receive text message alerts on their cell phones without the teacher knowing.

As people age, many develop what’s known as aging ear — a loss of the ability to hear higher-frequency sounds.

The ring tone is a spin-off of technology that was originally meant to repel teenagers — not help them. A Welsh security company developed the tone to help shopkeepers disperse young people loitering in front of their stores while leaving adults unaffected. The company called their product the “Mosquito.”

Donna Lewis, a teacher in Manhattan, says her colleague played the ring for a classroom of first-graders — and all of them could hear it, while the adults couldn’t hear anything.

—

Cheers.