On Saturday 20 March 2010 11:40:09 pm Seebs wrote:
> On 2010-03-21, David Masover <ninja / slaphack.com> wrote:
> > In this case, that's an assumption based on the device, and it's the
> > reason we have all this stupidity about tethering. If the bandwidth is an
> > issue, charge per bit or raise the monthly fee. (There's also the issue
> > that not all smartphone users want or need Internet on their phone.)
> >
> > Instead, we get potentially a lower monthly fee, plus some arbitrary and
> > asinine restrictions on how we use it, in the _hope_ that we use less
> > bandwidth. Why not simply have a lower-bandwidth plan?
> 
> Probably because you can't cap bandwidth -- the phone is effectively broken
> if you do

Well, its Internet functionality is. It can still make phone calls, unless 
you're counting phone calls towards bandwidth -- in which case, I hope you 
aren't charging for minutes. (If you are, you're charging them twice for the 
same call, which is a bit sleazy.)

> and people freak out if you charge them huge amounts of money
> for bandwidth.

They also freak out if you charge them huge amounts for text messaging, or 
regular calls, or minutes of regular calls.

The same simple rules apply -- offer a per-usage rate (per-minute, per-bit), 
offer various tiered rates, offer an "unlimited" flat-rate if your network can 
handle it.

In fact, that's exactly what they do anyway -- they just charge an additional, 
arbitrary "smartphone" fee on top of it if you happen to be using a 
smartphone. And you're saying it's because of bandwidth? With what they're 
charging for bandwidth, you'd think that's already built into the bandwidth 
plan -- and it has to be, to some extent, given that my "non-smartphone" can 
already download apps, music, and video, and can message/email said 
music/video to others.

> > Think about it -- Ruby without readline support (so IRB sucks), or raw C?
> > For the cases where I'd be considering Ruby at all, the lack of readline
> > wouldn't stop me.
> 
> The point is, it's an example of a case where I can use a program already
> existing, written in C, but I can't use one already existing, written in
> Ruby.

Well, again, it comes down to compiling Ruby vs compiling your C program. If 
they can compile Ruby, there's no compiling needed for your Ruby script, it 
just runs -- so it's still exactly one compile step.

I could even argue that if your build process is more complicated than "type 
make" or "gcc foo.c", it might be that much easier to install something like 
Ruby, with a large community of maintainers and a number of people who may be 
able to help if you have problems compiling on a weird platform, rather than 
installing whatever make/autoconf/whatever you come up with.

> > Also, I'm not sure I see efficiency as a
> > burden here, for the most part -- it looks like the intended use here is
> > compiling, which is already slow anyway,
> 
> Yeah, that's the thing.  Right now, a build of the whole shebang this is
> being used with takes over an hour on an 8-core machine with 48GB of
> memory and fast disks.  Running stuff inside my current library adds
> about 16% to everything, give or take -- more with lots of small files.
> Running inside a larger/slower language would be crippling.

Huh. I concede the point, then. I'd have to look much closer for opportunities 
to script, and you're probably right.