It's true - H2 is nothing but an energy storage system. I'd completely forgotten about hydrogen as a fuel. There's no need for it any more. Energy storage has moved on since then. The only rational reason to store energy as hydrogen was that it can be burned in an internal combustion engine, and now the progress of electric motors shows that's no longer an issue.

Ruckus and others have had good luck with beam-forming technologies, so having some directionality on the physical layer doesn't necessarily render it incompatible with Wi-Fi (or its various add-ons, AirMax and their ilk). What would render it incompatible with Wi-Fi in my opinion is: it isn't Wi-Fi, your existing Wi-Fi equipment won't work with it (you need a receiver device). It's another physical protocol, they could layer ethernet or anything else over it since they are going to have to implement drivers/integration anyway!

I missed "trouble tickets" - we ended up going with RT from Best Practical and linking into it. No need to reinvent the wheel.

I recently helped a small wireless ISP get started, and one of the first things we did was put together a management application. It's grown to be moderately large, but a lot of the functionality required can be constructed from various free sources. My client is chugging away nicely with a Java-based (server-side) system, although it could have been written in any one of a large number of languages - Java was convenient for the available skill-set in the company [never overlook the value of using an environment with which the customer is already skilled!]. The Seam+Hibernate stack provides a very quick development path for most of the CRUD [Create/Read/Update/Delete] functionality that forms the backbone of any data-driven app - but it could just as easily be Access, or (insert favorite ORM here). We found a few commercial systems that could do all of this, but they typically cost more than putting this together ourselves - however, that's partly a function of who you have available.

The key to getting the project off the ground, in use, and genuinely useful was to identify the various areas that are essential - and automate them as building blocks within a framework. You're already used to Access+Excel+manual legwork, so you don't need to start with an amazing UI (although it is a good idea to come up with one that doesn't make the eyes bleed) - identify areas to automate (starting with the biggest pain points) and gradually reduce the pain as you can afford to do so. Also, don't be afraid to use various Free/Open Source packages to help out with sections!

The important chunks for my client (and probably for other ISPs) were:
* Customer database. This acts as the core for a lot of the rest of the system; database (and UI) for customers, their addresses and billing information, account history, etc. Includes tables linking to inventory to indicate what devices they have activated and the details (including billing plan, etc.)
* Inventory system. Lists CPEs, with status, location, ownership info and history. Linked back to the customer database, to make it easy to say "Johnny has this CPE, on that plan". This ended up growing lots of historical options for reporting, but those aren't really essential.
* Activation. This was the biggie for us. When a customer (optionally a new customer) is "activated" with a CPE/plan/etc. (a wizard helps you pick), it adds the appropriate history items and invokes scripts that setup the account in RADIUS and LDAP servers. This is the obvious place to include every step you need - but you can start as simple as "email tells you what to do" while you automate the steps.
* Deactivation. Suspending customers (typically for non-payment), handling CPE returns, etc. You can probably live without this immediately, but it is really nice to have.
* Billing. The first few iterations made CSV files for Quickbooks - that should be fine to get started. The most recent handles credit card payments, etc.

There's also a lot of management niceties, and these were integrated back into the main portal for convenience:
* Cacti for graphing various bits of the network, notably throughput and latency across the network. Very useful for planning.
* Nagios for monitoring the network and paging us when something isn't responding.

As it grows, you'll doubtless end up with a bunch of esoteric scripts also. We even have one that periodically uses an SSH session to log into various access points and records who is online in each sector, what their signal strength is like, and any de-registration events that have occurred. That highlights the biggest pitfall: it is really easy to get excited and try to program in the kitchen sink. If you don't focus on small/modular at the core, you'll end up with a mess - fast. We try to keep the core small, and then have the core UI link into various other tools as we create them.

I currently have a small (3 towers; 3 more going up in the next few months) WiMAX ISP as my primary client. They already had some appropriate frequencies available; if you don't, you either need to find some (schools are a good bet - many have some old licenses lying around that they don't use) - or go with unlicensed frequency bands. That will severely reduce your range/throughput, but has the advantage of being free.

WiMAX is a good fit for the rural model, but there's a fairly hefty setup cost. Most vendors require that you have an ASN-GW at the core of your network, which is a very large initial cost (both in setup time and actual purchase price). The large ones can easily run to a quarter of a million, with smaller models costing a lot less. My client is on NewNet gear (formerly Nokia-Siemens, formerly Motorola - corporate pass-the-parcel), and the setup was pricey - but it performs very well (they have plenty of customers getting 18-20 mbit/s down; upstream on WiMAX isn't so good, expect 3/4 mbit/s on a good day).
You can shave a LOT off the cost by using an open source core to the network (you can't avoid needing RADIUS, DNS, NTP, plus servers for actually running the business), and you could shave more off by going with someone like Alvarion who use a distributed ASN rather than an expensive core (in my experience, performance on Alvarion is decent but not on a par with the NewNet gear). You also need base-stations and antennas per site, but the cost there is quite reasonable in comparison (although "tower monkeys" are expensive to put the stuff up!).

By far the highest long-term cost is backhaul; you need a good connection to each tower (100 mbit/s for full capacity for a 3-sector, max 768 concurrent users). In many areas, dedicated fiber is really expensive - and you end up paying the telco you are trying to supplant. Microwave is a better option - you pay $10-15k up-front (plus FCC license if you need it), but there are no recurring costs. With fiber prices around here, it pays for itself in well under a year. There will also be the cost of your upstream Internet connection; that's incredibly variable by location.
The next cost is CPEs. Our experience has been that the fixed devices sell far better than the mobile devices (mobility isn't so useful when its only within your small network), and the outdoor CPEs need good installation to perform well. Expect to pay $150+ per unit, which can make for a high setup fee.

Finally on the money-side, there's the human cost. You'll want support, enough engineering muscle to monitor/fix your network, and any sales/business side you need. That can be hard to juggle while you get started: mouths to feed while you get enough customers to hit the magical "break even" point. It's a tough phase, and you have to be very careful to keep your spending within reach of this goal. That means you can expect to be working hard for very little for a while - but that's true of most start-up ventures.

It's also worth considering LTE. It's currently an expensive proposition to get into LTE, but you can cover your butt against the eventual inevitable transition. All the major WiMAX players are moving towards a dual-stack mode, allowing you to concurrently run LTE and WiMAX (on different frequencies) on the same gear. Most CPEs scheduled for next year are also dual-stack, so you can deploy WiMAX now and LTE later when you can afford the exorbitant cost of a packet-core (or packet cores come down in price). To do WiMAX well, you want 3-4 10mhz channels; if you can get adjacent frequencies, when you light-up LTE you can start by using one of the 10mhz channels - and gradually phase-out WiMAX adding bands to the LTE side. It isn't free future-proofing, but it's a lot better than knowing you will have to tear out all your gear in a few years.

Call off your patent-trolling dogs and maybe I'll code to your closed, putrescent platform.

"What we really need is for the legal department to slap a $2 billion fine on Apple over anti-competitive behaviors

Apple, Inc. could pay that out of their petty cash.

and forcing developers to use the App Store,

The only Mac App Store purchase (so far) was Angry Birds for the MacBook. Everything else on the Macs here is third party or non App Store Apple/Mac apps (Aperture, iWorks, for example).

  not to mention not making music purchased on iTunes work on other music players."

iTunes tracks have been DRM free for years. Oh, you have DRMed iTunes tracks? Burn a CD, rerip as MP3. No DRM. iTunes DRM was REQUIRED by the RIAA, not Apple.

FUD failure, there, Slappy.

SoundJam MP.

SoundJam MP was, perhaps, the first genuinely useful MP3 application for the Macintosh. One could easily rip CDs to MP3, mix songs as one wished in playlists, and then burn them to CD.

Rip. Mix. Burn. Where have we heard that before?

It even had support built in for the few MP3 players of the time.

Review of an early incarnation of SoundJam.

Review of the final revision.

And, the ObWiki entry .

MacLife history of iTunes .

Without SoundJam MP. there would likely have been no iTunes, as Apple bought SoundJam MP, filed off the serial numbers, slapped a coat of paint on it and called it iTunes V1.0.

Well, yeah, there still would have been AN iTunes. Apple would have just bought Audion .

So, while the iPod was indeed a seachange for the portable music player (cassette/CD/digital) of the era, without the software to support it as easily and as elegantly as SoundJam, er, "iTunes", it was the software that made the iPod the success it was and remains to this day.

This right here!

Oh, look! It's the South Park turd fan, back again.

Just like the last time, spreading his BS about "freedom".

Dude, take. your. meds. Or your Cheetos. Which ever salms you down and allows you to actually think rationally.

Kthnxbai!

Are Apple ninjas forcing you to buy Apple hardware?

If yes, you're a loony.

If no, WTF are you complaining about?

If you don't want an iPod, buy a Zune.

Oh, wait...

Right.

Haters gonna hate.

They hate that Apple doesn't suck up to their particular hardware/software/user interface fetish.

They hate Apple because Apple doesn't care a fat rat's ass what they think or say about Apple.

They hate Apple because when they got to the opening day of their local Apple Store, the Store had run out of free T-shirts, which meant that they HAD to do laundry and not put it off another few days.

Yes, and keep your filthy govt. hands off my Medicare and Social Security and someone fetch me a fresh battery for my electric scooter chair that Medicare gave me!

I'm sure you meant to write,

"Legally and ethically obtained the non-exclusive rights to the intellectual property of the GUI and Mouse from Xerox PARC."

Oh, wait, then you wouldn't be repeating a lie that is dead. Dead and buried. With a one meter layer of concrete over the gravesite, and an Apple Store built on it.

Haters gonna hate, and do a remarkably pisspoor job of it, too.