Um... not quite true, at least in the USA. Most ISPs charge on a modified 95/5 plan. In its pure form, that means they look at how many bits you push over each five minute period, then take the ninety-fifth percentile of those numbers and bill as if you'd used that for the entire billing period.
In the usual implementation, the downstream ISP commits to a certain minimum usage, and pays for that even if it doesn't use it. Using much more than that, however, gets you a ludicrously high "bursting rate".
The net effect of this is that while costs are tied to usage, it's only very loosely, with a padding of minimum costs and insurance against burst fees. On the other hand, you typically have lots of "free bandwidth" -- if you know that your 95th percentile is about 80 Mb/s, and you're only pushing 10 Mb/s at 3am, you might as well push about another 70 Mb/s, since you won't pay anything to do so.
This sort of plan is dramatically different from a per-bit rate. Such a scheme would cripple peer-to-peer systems (such as online games) and in fact everything *but* distribution of mass-media material.
This plan replaces the tyranny of ASCAP, RIAA, et al. with a new tyranny of ISPs. The author fails to deal with the problem of unwilling creators. Under this scheme, I pay as much to download a Debian CD set as I do to download a Metallica CD set. Not only that, but Lars has to pay just as much to download that Metallica CD as I do.
That opens up an even larger problem: I pay the surcharge even on bandwidth used to transfer my own data around. The obvious solution to this -- count already-owned bits differently from newly-purchased bits -- opens up the original can of worms. The next solution requires me to pay my ISP a bandwidth surcharge, then get some fraction of it back for being a content provider.
It seems that this isn't so much a bug in the Mac's StringToDate function, but in two-digit representations for dates. That is, *no* computer can deal with StringToDate("89") properly, save to interpret it as 1910 years ago.
I'd regard a computer which generated 89 from a DateToString call for a recent time as buggy, but I don't see any better way to handle this.
Slashdot Mirror
Um... not quite true, at least in the USA. Most ISPs charge on a modified 95/5 plan. In its pure form, that means they look at how many bits you push over each five minute period, then take the ninety-fifth percentile of those numbers and bill as if you'd used that for the entire billing period.
In the usual implementation, the downstream ISP commits to a certain minimum usage, and pays for that even if it doesn't use it. Using much more than that, however, gets you a ludicrously high "bursting rate".
The net effect of this is that while costs are tied to usage, it's only very loosely, with a padding of minimum costs and insurance against burst fees. On the other hand, you typically have lots of "free bandwidth" -- if you know that your 95th percentile is about 80 Mb/s, and you're only pushing 10 Mb/s at 3am, you might as well push about another 70 Mb/s, since you won't pay anything to do so.
This sort of plan is dramatically different from a per-bit rate. Such a scheme would cripple peer-to-peer systems (such as online games) and in fact everything *but* distribution of mass-media material.
This plan replaces the tyranny of ASCAP, RIAA, et al. with a new tyranny of ISPs. The author fails to deal with the problem of unwilling creators. Under this scheme, I pay as much to download a Debian CD set as I do to download a Metallica CD set. Not only that, but Lars has to pay just as much to download that Metallica CD as I do.
That opens up an even larger problem: I pay the surcharge even on bandwidth used to transfer my own data around. The obvious solution to this -- count already-owned bits differently from newly-purchased bits -- opens up the original can of worms. The next solution requires me to pay my ISP a bandwidth surcharge, then get some fraction of it back for being a content provider.
Better, I think, to leave bandwidth unmetered.
It seems that this isn't so much a bug in the
Mac's StringToDate function, but in two-digit
representations for dates. That is, *no* computer
can deal with StringToDate("89") properly, save
to interpret it as 1910 years ago.
I'd regard a computer which generated 89 from a
DateToString call for a recent time as buggy, but
I don't see any better way to handle this.