Satellite Internet Service for Macs?

Untimely Ripp'd asks: "Satellite broadband has been available to PC users for half a decade, and still is not trivially available to Mac users. It can be done, but it's always an unsupported hack, or it requires buying expensive extra hardware and software. I cannot understand why Hughes and the other providers would refuse to spend the relatively few dollars necessary to develop a couple of device drivers and glue libraries. Time after time, the vendors have said, 'it's coming,' but it never does, and the promise eventually goes away. (Earthlink's FAQ page no longer says that Mac software is being developed, for example). I'm not gung-ho on conspiracy theories, but the only explanation I can figure is that they're either being paid or bullied. Does anyone know of any serious tech hurdle that would make it cost more than $100K or so to develop the necessary software?" this article mentions one-way Mac service coming online from OWC in a future expansion, along with nationwide service. A comment from that story does mention a simple solution, but why is it that Satellite service, even one way satellite service, depends on Windows-only software? What other solutions have Mac users resorted to when they wanted their Macs connected?

Comments

Again?

[Clue4All]

I'm not gung-ho on conspiracy theories, but the only explanation I can figure is that they're either being paid or bullied.

How many times can we go over this same point? It's the same for Linux and Mac, it's just not economically viable to develop software for something used by less than 5% of the computing masses. It doesn't pay, plain and simple, and companies aren't going to waste money developing with little to no returns. I await next week's Ask Slashdot with the same question.

Re:Again?

[Otter]

Also, while Mac users may be ~5% of the total, they're a vanishingly small percentage of the construction supervisors, petrologists and logging bosses who need a satellite link. This troll is essentially correct, even if he can't spell Shih-Tzu.

Re:Again?

[GlassHeart]

It's the same for Linux and Mac, it's just not economically viable to develop software for something used by less than 5%

One way to make money is to build a product that 95% of the people use. Another way to make money is to build a product that 5% of the people use. Microsoft certainly made a boatload of money, but Apple is not exactly bankrupt. In fact, I'd expect that Mac sales of Adobe Photoshop account for significantly more than 5%.

In practice, a lot of times you'll find that the reason a minority OS is not supported is not because somebody determined that it was not viable, but that nobody ever bothered to see if it was viable or not. Only the former is a good business decision.

Re:Again?

[swdunlop]

Having done a stint or two of technical support, a tour in quality assurance, I can point out several costs of supporting less-used OS's and hardware platforms.

First, it's not quite so easy to provide technical support for more than one environment. Like it or not, it isn't just a case of hitting Command-C instead of Control-C; Windows users expect one set of UI conventions, Mac users expect another, and Unix users want it three different ways, and it should also work from the command line. Each OS requires different tactics to work around existing issues. For technical support departments supporting diverse platforms is a nightmare, since it means they have to either spend most of their time in training, or provide multiple specialized departments, which can easily eat up manpower.

Setting rigid support boundaries is a partial solution, but I have yet to have a customer who knew of the support boundaries and had a problem outside those nicely defined lines who didn't try to cajole and/or threaten me into helping him "just this once." It wastes my time, and his.

For developers, this is similarly a nightmare. I know of one decent cross-platform GUI toolkit that works on X11, Win32 and Mac OS, and on the Mac, it doesn't conform strictly to the Apple User Interface guidelines. Compound that with the highly specialized skillset required to write drivers for a particular operating system, with some exceptions, and to go with your bloated support department, you'll have an increased software development budget, and QA budget.

The only recourse we fringe users have is open standards; encourage your vendors to use published protocols, open standards and to document their API's. Take those documents and write a solution for your environment of choice.

It's not about the cost to *develop* the software

[mbessey]

The main barrier to providing a service like this for the Mac, or for Linux, Solaris, BeOS, or whatever, isn't the cost to develop the software, it's the cost of supporting users on another platform.

Every time someone calls with a question, it costs the company money. The quicker you can answer their question and get them off the phone, the better. This means minimizing the number of different systems your support folks have to be trained for.

-Mark

Technical issues

[rochlin]

I think it's worth mentioning a couple technical points that have been overlooked by people considering using a PC as a bridge between the satellite receiver and the Mac.

I set up a PC system (with win2k) purely as a bridge. The satellite reciever uses USB (this is from Pegasus-DirecPC-Hughes - now acquired by Earthlink). Pegasus and DirecPC provide proprietary Windows only drivers to deal with the USB network-satellite connection. That's issue #1. That means using Linux or (as suggested in the "comment" link in the oringal post) a simple router won't fly.

Issue 2: Optimizing the Window size for the ethernet connections --
The fact is, the TCP/IP conneciton to the satellite (high bandwidth - extremely high latency) needs different rwin settings to optimize the connection than the simple pc->mac LAN connection. So far as I can figure, Windows lets you choose one setting for all NICs (in this case the USB satellite connection is a NIC).

Issue 3 - you need some kind of 3rd party NAT/Bridge software like Sygate to share the connection with the Mac. The built in (to Win2k, 98) Internet connection software won't work because it can't bridge different subnets. The USB conneciton is on a different subnet vs. a regular NIC. I don't think it can be configured otherwise. WinXP might fix that.

Bottom line: You need a PC with Windows to share the satellite with the Mac and even then the Mac will have inferior service vs. the directly connected PC. So a satellite service supporting Macs would be nice :)

But it IS economically viable to ...

[Ungrounded Lightning]

How many times can we go over this same point? It's the same for Linux and Mac, it's just not economically viable to develop software for something used by less than 5% of the computing masses.

Let's phrase this another way:

How much would a company pay for ADVERTISING to get a 5% increase in sales? (And thus a MUCH greater than 5% improvement in profits, since the development is already amortized.)

Now if that same amount bought you the development of an incremental feature (i.e. a Linux or Mac driver) that enables another 5% of the market to use your product, it's the same case. (Actually, if you're currently addressing 90% of the potential market and the new segment is an incremental 5% you're adding 5%/90% or about 5.6%).

But wait, it's better ...

Suppose that you're currently splitting the market evenly with one other competitor. If YOU do it and HE doesn't, that 5.55% about doubles to 11.1%. With an even split among three competitors the first mover gets about a 16.7% bump in potential sales (and more in profit), and so on.

With something like networking you have a small number of competitors but MAJOR lock-in. First mover gets the prize and KEEPS it. With something (like a device) with more competitors and less lock-in you may not keep it, but you get a BIG boost until your competition wises up.

But WAIT! You don't HAVE to develop it yourself! Publish enough of the interoperability specs and - at least for Linux - SOMEONE ELSE will do it FOR you! You get the benefits and do only a tiny fraction of the work.

Your work consists mostly editing your internal documents into an externally-releasable one that will enable a developer without giving away your trade-secret farm. But don't get too paranoid: Your competitors are ALREADY reverse-engineering you. You should have your critrical IP already locked up in patent-pending, which will keep your competition at bay if you publish more than you intended. Meanwhile, better specs mean better and sooner community software to enable your sales.

Network operators might have some issues with security - but that's already been addressed elsewhere. (Bottom line is that the black hats will get you anyhow if you're already BADLY broken, regardless of whether you publish, while if you're reasonably secure (i.e. only a little flakey) the exposure will get the white hats on your side and you'll probably increase your lead in the arms race.)