The Free Software Foundation can only file suit when someone directly violates the copyrights of FSF software. There is a lot of GPL licensed software which the FSF does not hold copyrights for. FSF can't sue just because a program is licenses by GPL.
To sue, you either have to be the copyright holder, or maybe (not sure on this one), a downstream 'recipient' of the software. E.g. if you bought a Cisco device with GPL'ed softare, and you couldn't get the source from Cisco, you might have grounds to sue them for breaching your rights wrt to the GPL as a recipient of a binary.
I suppose that might leave some wiggle room for FSF to simply arrange to receive a copy from the violator (e.g. by a non-compliant linksys device at Best Buy), then file the lawsuit.
Someone please correct me if I'm wrong, but I think that when you compile C-code with gcc, particularly if you use.so files instead of a monolithic binary, doesn't the program have some dependencies on a libgcc.so or something like that? I suspect that you're right that the devices don't have a fully functioning GCC build environment, but I think they may distribute some components of GCC which are required to execute programs compiled with gcc. Same for binutils - I think you pretty much *need* the ld programs which are part of binutils to have a functioning Linux environment (unless you statically compile *everything*), because they implement and manage so loading on behalf of the kernel, no?
I've always been under the impression that, from a provider standpoint, density is good, because the cost per-customer is cheaper, even if you have to provision more overall bandwidth? In low-population areas, I think companies often run into under-utilization problems (or at least, potentially can), where they have to pay costs to maintain infrastructure, which is a fairly fixed cost, but might have fewer customers to a) recover the fixed infrastructure costs, and b) make an additional profit?
"Saving the internal deltas of almost anything a typical user does with a PC are not unreasonable."
What about, moving beyond mere text, word processor, and spreadsheet files, larger types of files where a single change can modify megabytes of data? For example, making a change to a graphics file, or audio file (like, for example, making an image brighter, darker, adjusting contrast, etc, which might change every pixel in the image; now, someone might propose that you don't save the change to every byte in the image, but instead just save that the user adjusted the contrast or brightness (which could probably be represented in a few bytes of data), etc, and when you re-load the file in the future, the app just 'plays back' the journal of changes.
The only problem with that, is that is an application-domain specific change; how would a general purpose, versioning file system be able to handle application specific changes? That would require a further extension of the filesystem where instead of just tracking changes to the actual file data, you have some sort of meta-data system where applications can store application-specific logs of stuff like that. That could be possible, but that then requires applications to be modified to take advantage of that. When you consider that there are thousands of legacy apps on any given platform, that means that you will likely be stuck, for a long time, with apps that still don't take advantage of the new functionality.
Still, I suppose it would be cool if someone developed the necessary filesystem to implement these kinds of things, and the corresponding system calls necessary to provide the interface between apps and the filesystem.
That seems to be a rather rude reply. First off, I never said the idea was without merit. I asked what you would do instead. That seems a reasonable question if someone is proposing a change.
I then went on to attempt to think through the problem a little bit, and offer what alternatives occured to me at the time, and any new problems I could think of that might arise from the alternatives I thought of. That does, of course, leave room for alternatives that I just wasn't creative enough to think of.
I didn't respond to most of these responses right away, as I wanted to think some more on the issue based on everyone's replies. Not sure if anyone will ever see this at this point, but here goes. . .
"what's the issue with simply saving the undo data, along with each revision".
If you can do that in a 'metadata' block in the filesystem, seperately from the actual file data, fine. But a text file does not have any concept of a journal of changes. If you create a new file format with that info, fine, but that is no longer a text file. So, you do have the issue of making sure that files remain the basic data that they are. Notepad, as our example, is designed to work with text files. Most other data file formats do not have the ability to save undo data in them (perhaps doc or odf do?).
Also, what if I am using a USB flash drive formatted with FAT32 or NTFS? Those don't support that, so I would still need the 'old style' save capability.
In fact, I would argue that for the most part, any type of functionality like this would have to be implemented at the O/S filesystem level, not the application level, although the applications *also* need to be changed so that if they detect a filesystem that supports this, they start auto-saving or continuous saving, but revert back to 'traditional' behavior when using a 'legacy' filesystem.
The biggest roadblock to this is that it requires every (well, most, anyhow) application to be updated to be compatible, before you start to see the advantages. That is, you need first the filesystem to be changed (to support the seperate-from-the-file-data change journal), then additionally the apps. Any 'legacy' application could still potentially interrupt your system reboot even with this new capability.
Do I think auto-versioning filesystems are a good idea? Heck yeah. But I'm not sure that applications having a 'save' button is really that big a deal, to worry about updating thousands of applications to get rid of it. Also, you still need to decide what directory/volume to save the file to, somewhere. Maybe when you first create a new document, before you type anything into it (or, as the case may be, record audio, record video, create graphics, create models, create level maps, etc).
I've thought before that it would be useful, if I'm using my laptop on a public WiFi network, to be able to use a pre-designated, trusted DNS Server (so that the public network's DNS Server can't send me to bogus servers).
It would be a nice feature if I could have my computer cache the public key of my ISP's DNS Server (or maybe OpenDNS; the point is, some DNS Server *I* trust, instead of a random DNS server), then, no matter what network I connect to, always use that DNS Server, with the DNS packets being signed by the trusted server, so I know they are really from that server. (I realize I can use OpenDNS pretty much anywhere, but I don't know if there is anything preventing the local network from doing a MITM attack?)
It might also be useful, for this type of system, if my computer can authenticate to the ISP DNS Server (because they might not normally allow DNS requests from outside their own network, but if there were a specified authentication mechanism as part of the standard, they might allow me to roam if I authenticate)?
Maybe the best answer is to just use the VPN capability on my home router to always VPN to that router, which will then use my ISP's DNS. Until DNSSec is implemented widely, that's the best solution for now, anyhow, I think.
No matter what medium you are using for propulsion (Air, C02, or combusting fuel), it still requires the same amount of energy to make the stability corrections (in one case the energy comes from fuel combustion, in the other case, it comes from some sort of air pumps at the ground). The point is, that it still requires a potentially unknown amount of energy to stabilize the thing. Since the *point* of the space elevator idea is to conserve energy, the question becomes, will we actually conserve any energy with a space elevator? Plus, with an 'active' stabilization system like that, there's the posibility of something going wrong (like the air pumps at the ground going out of operation due to power loss or something), causing the whole thing to be destroyed.
The driving desire behind a space elevator is to reduce the amount of energy required to lift an object up to a point where the Earth's gravity is sufficiently weak to use 'lower power' rockets for establishing orbit, or leaving the Earth entirely. When considering the energy requirement, you can break the energy into two components - the energy of motion of the mass (kinetic energy), and the gravitational potential energy. The gravitational potential energy, if you haven't taken physics or don't remember, is the fact that in order to lift any object to a given distance above the Earth's surface requires an investment in energy. I don't know what the formula is for lifting an object that far above the Earth's surface, but we don't have to know it for this discussion. Whatever that formula is, that is the 'minimum' energy needed to get an object to a certain elevation.
A rocket or a space cannon would both essentially do the same thing - accellerate you to escape velocity (or sufficiently near it to reach the desired elevation), 11.2km/s. But, the formula for the kinetic energy of an object at 'low' speeds (and escape velocity is low compared to the speed of light) is k =.5mv^2. Where m is in kilograms, v is velocity in meters/sec, and k is energy in Joules. Because 11200^2 is a very large number ( 125440000 ), even when you halve it, it's still a large number (62720000). Which means it takes a whole lot of energy to lift anything into orbit by accellerating to, or near, escape velocity. Consider an object which, at the Earth's surface, weighs 1000 lbs (so it has a mass of 453.6 kg). To accellerate to escape velocity, that's about 28.45 GigaJoules of energy required.
The only advantage the space cannon would have is that instead of having to use a lot of fuel to propel it, you could use an array of fission or fusion reactors to supply the energy required. But it's still a lot of energy. It would be better to reduce the amount of energy needed.
Just because the Mozilla foundation will no longer be providing any updates doesn't mean there isn't the possibility of updates. Remember, FF is open source. If a security exploit is found, someone else could, at least, theoretically, provide a patch.
Funny thing, though, about old software. . . as it gets less popular (because people gradually upgrade), it simultaneously becomes a less interesting attack vector. There's maybe still enough FF2 users that it might be a worthwhile target, but as time goes on, and the installed user base shrinks, I think it becomes less likely that anyone bothers to try to find attacks for it.
T-Mobile has implemented on their network, a technology called UMA, which T-Mo markets under the name "Unlimited Hotspot Calling". Basically, for $10/mo extra on your phone plan, you can make unlimited calls via WiFi. Would be sweet if Google or someone can get UMA working on the Dev phone.
Your argument is, to some extent, self-contradictory:
"When piracy no longer gives you better content than buying it, and when people have loads of cash to spare and can afford to pay for their current content intake, THEN you can expect people to stop downloading things for free."
People who pay for stuff which they *could* pirate, largely do it because they realize the necessity of it. I *could* go to a restaraunt, and not give my waiter/waitress any tip, but that'd make me a dick. They need that income, and they *did* provide me with something of value, namely, service. Same thing with artistic works. I don't pay because I'm rich (I'm not), I pay because the investors and creators of that artistic work deserve to be paid.
Nobody has 'infinite' income, so the idea that people will stop pirating when they have more money isn't really true. Because there is *always* something else they could use the money for if they didn't spend it on music/movies/software/whatever. Someone who justifies pirating stuff when they make $20k/yr, will probably still justify it when they make $80k/yr.
As for Free Software - that is a different story; the copyright holders have chosen to give it away for free, and that's their business. I salute anyone who gives their software away, and I've even begun making donations to free software projects, on the basis that they do still need money, even if they don't demand it from everyone. Sort of a 'tip' for the software developers.
As for the DRM issue - yes, that is somewhat valid. If someone buys the DRM version, then downloads the DRM-free 'hacked' version, personally I have no problem with that. I'm sure RIAA/MPAA/software publishers do, but in that case the person did pay for it, so I don't really see the harm. Also, I would like to point out that Amazon.com, Walmart.com, and iTMS are all selling DRM-free versions of music (ok, in the iTMS case, the DRM-free catalog is somewhat limited), but that hasn't put an end to piracy of those tracks.
Art and entertainment will still be made, because there are people like me who think it's worth paying for stuff we enjoy. Other's will mooch. The one thing RIAA et. al. need to learn is that they'll never really be able to stop piracy, and trying to convince people to pay by 'scaring them straight' just isn't going to work. They need to instead convince people to pay because it enables the creators to keep creating art full time, and keeps investors putting down money to enable stuff to be made. Sometimes people justify their piracy by saying that the money isn't going to artists, it's going to publishers. I'm not saying that publishers don't ever exploit artists, but, particularly for movies and software, it takes a lot of 'up front' money to get a project completed, and those projects often couldn't *ever* be done without investors fronting the money. Movies often cost $50-$100 Million to create. So, we need to make sure investors get a return on their investment, if we want to see them continue investing in those things.
1) "If the legacy device has an app which doesn't do DNS, how can it reach the endpoint?"
This question, I think, has to be broken down into two cases, in order to answer it:
Case A: The static IPv4 address endpoint it is trying to reach is a server which is still in operation, on the same IPv4 address, but the user has an ISP or backbone provider which is IPv6-only (so that, at some point, the traffic must go across one or more IPv6 only links), but there is still a coherent IPv4 "backbone" which, once reached, the data should be able to get to any IPv4 public IP address. In this case, the 'gateway' device does something which is the logical inverse of the current 6to4 tunnel system - more of a 4to6 - the IPv4 traffic gets automatically tunnelled through the IPv6 links to the nearest IPv4 'endpoint', then gets routed as IPv4 to the server. There might be 'traditional' IPv4 NAT involved in this, or not, depending on whether the end-user network has public addresses available for devices, or only private networks, much like today.
Of course, the eventual goal is that the server migrates to IPv6 only as well. Hopefully the device maker has put out a firmware update by this time, but, knowing the reality of the industry, and that most devices, once sold, never get firmware upgrades. . .
Case B: When the operator of the server migrates over to IPv6, they get to take their IPv4 address with them. The old IPv4 address becomes part of a new IPv6 address, with a standardized way of converting old IPv4 addresses to IPv6 addresses (standardized prefix, perhaps, similar to how 6to4 uses a standardized prefix?). So, when the old IPv4 device tries to contact the old IPv4 address, the translation gateway knows how to create an IPv6 address from the IPv4 address automatically, then forwards the traffic on.
I think those two solutions could work to solve this problem, couldn't they?
Now, in both of these cases, I'm essentially assuming that traffic is being initiated by the end-user device making an 'outbound' connection. This still leaves a question about how such devices could receive incoming traffic. This two needs two cases
Case C: IPv6 host wants to contact the end-users IPv4 device. I think, in my journal, I might have touched on this, but basically, I think the 'translation gateway' could generate an IPv6 address from the local network's IPv6:prefix::IPv4:addr, which would allow an IPv6 endpoint to contact an IPv4 endpoint.
Case D: IPv4 host contacting the end-user's IPv4 host through IPv6 links, where the end-user's IPv4 host doesn't have a 'public' IPv4 address. Much like the current Internet, you need at least 1 public IP address, and you use NAT and port forwarding, almost exactly the same as today, only with the IPv4 packet being tunneled over the IPv6 Internet (this stage would be quite a ways in the future, when significant chunks of the Internet are IPv6 only, so that your ISP maybe has no direct connection to IPv4 backbones). Somehow, there is going to have to be a table somewhere, like there are today, of how to route to a given public IPv4 address over the IPv6 Internet, so that the NAT gateway can receive the packet. Once the NAT gateway receives the tunneled packet, it does the normal IPv4 NAT/port forward to the private address.
Maybe. I'm not so sure. I don't claim to have all the answers. Someone out there might have a better answer than me on this. It just seems like it should be *possible* to address most of these issues, if people are willing to work on it.
I dunno, honestly, what is slowing adoption of IPv6. It seems more that no one is getting started. Here in the US, I don't know of any consumer ISPs that use IPv6. I'm not sure if any of the backbone providers use IPv6. Without the backbones and the ISPs switching, the switch can never really happen. Sure, people get use 6to4 or a tunnel today. But, if the ISPs, backbones, etc aren't changing, what's really the point?
IPv6 allows for address abbreviation. It is common for IPv6 addresses to have a relatively short network prefix, a bunch of zeros, then a non-zero host address. IPv6 specifies that addresses may be provided in a full form, or abbreviated form, where all the internal zeros are replaced by::
This still only helps so much but, you can think of IPv6 addresses more as
pre:fix::host:addr
Now, that said, IPv6 addresses do still tend to be pretty long, because the 'host' portion is often the 48-bit MAC address of the host computer. The upside is that allows for automatic configuration without needing DHCP. The downside is, common IPv6 addresses are still about 80 bits of information (32-bit prefix, 48-bit host).
The real answer is, of course, host names/DNS. Don't bother remembering numeric addresses, except for the DNS servers, routers, etc and give them an address like:
pre:fix::1
(I believe you can statically assign an arbitrary host IP to something like a DNS server or router, so you can use::1,::2,::3, etc. for the servers/devices that absolutely must be accessed by static addresses).
There's an infinite difference between 0 and. . . almost 0. If IPv6 adoption was 0.001 percent of total Internet hosts last year, and it's 0.003 this year, that is, technically, 300% growth. Not necessarily very meaningful, but still 300 percent growth.
I was thinking about this recently. I don't have the know-how to actually code up a proof of concept of my idea, but I did some 'high-level' thinking about the transition problem and posted an entry in my slashdot journal. I just Googled the NAT64 you mentioned, and that looks (from a cursory glance; I didn't have time to read the full draft RFC) like it's describing something like what I have in mind. I think once something like that is widely available, the 4-to-6 transition can begin.
It would also help if device makers started supporting IPv6 in firmware. For example, you can find plenty of network and WiFi printers right now. Good luck finding one that supports IPv6 though. This is they type of thing where the government could step in and show some initiative. I'm generally a free-market guy, but with something like the IPv6 transition, sometimes some leadership is necessary to start things off. Seems like a government regulation mandating network device makers to start including IPv6 support in any device which claims TCP/IP compatibility [after some reasonable threshold date, say June 1, 2009, or Dec 31 2009], would be a good starting point.
Sort of. Ok, what I describe below might not really fit the definition of NAT, so read on for what I mean.
Allow me to explain. One of the 'hardest' problems I hear mentioned when people discuss transitioning to IPv6 is the problem of legacy devices - printers, video game systems (think XBox Live), Tivos, etc.
It occurs to me that, at the ISP level, or possibly at the home/company router level (depending on your needs, it could be either place), a device could 'translate' packets between IPv4 and IPv6, so that legacy devices talk using IPv4 to the router, and the router does something similar in concept to NAT, where it creates IPv6 packets to forward on to IPv6 hosts and devices.
In such a situation, every ISP or home user can have their own entire IPv4 "virtual Internet" worth of IPv4 addresses.
I posted a longer article, a few weeks ago, in my user Journal, describing in a little more detail what I have in mind. Is there any reason something like this couldn't be made to work, to assist in transitioning to IPv6?
"Nothing anywhere is completely safe. Everything you own is up for grabs at any point in time by anyone who wants it bad enough. Best course of action I can think of is to buy a gun."
What if what they want really badly is your gun? By your own admission, "Everything you own is up for grabs at any point in time by anyone who wants it bad enough." That would include the gun, seems like.
It seems to me that part of the problem is that too many websites that service too many customers are all using a *single* payment service. Hijack that one payment service, and you can potentially hit 10's of millions of customers.
I don't see why giant national banks, and even mid-size regional banks, can create their *own* online payment services. Heck, they might even be able to generate new streams of revenue for themselves, instead of giving all that revenue to Checkfree. If nothing else, it helps to limit the scope of damage from one provider getting compromised.
For small banks and CUs, I could see that they might not have the resources to create their own online payment service, but if the larger banks were creating more online payment services, maybe there'd at least be a little more diversity in the systems being used by the small banks.
What would you do instead of file save? Continuous save, where the file data is saved as you type? What if you decide the changes you made were a mistake? I think one of the basic premises, going a very long way back in the design of software, is that you don't immediately save changes, so that the user can make a choice whether to 'commit' the changes, or throw them away and revert back to the original state of the file. As far as I know, Notepad will only temporarily stop the shutdown of the computer, to ask you do you want to save the file - yes/no? I don't see how that is such a bad thing?
Now, you might say that the solution for this is automatic file versioning. The problem is that if you have continuous save, you would either get a version for every single character typed, deleted, etc, or else you would get 'periodic' versions (like, a version from 30 seconds ago, a version from 30 seconds before that, etc) and pretty soon you'd have a ridiculous number of 'intermediate' versions. File versioning should, ideally, only be saving essentially 'completed' versions of the file (or at least, only such intermediate versions as the user chooses to save [because, if you are creating a large document, like a Master's Thesis, or book, you will probably not create it all in a single session, so in that case, you might have versions which don't correspond to completed 'final products', but you probably also don't want 1000 different versions either], instead of a large number of automatically created versions).
"So someone may trick you into running the installer for that rootkit, but the installer can't then put the rootkit into the system areas. The OS simply won't allow it to write to those areas. So it'll either fail, or it'll have to have the OS prompt you to allow it to mess with the system areas."
There's one problem with this. . . the potential for un-patched vulnerabilities in user-accessible programs which allow privilege escalation. The original poster mentioned how, for a worm on the network to attack a Mac (or Unix, for that matter) system, there were only a few network services for it to exploit vulnerabilities in: ssh, postfix, apache, etc. I agree that is a pretty small 'footprint'. But, now if I run a program locally on my computer as my user account, the possibility exists that their is an unpatched vulnerability in some program somewhere which would allow for privilege escalation (anything which would be 'suid' root, like su/sudo [does OSX have an equivalent to su/sudo], the passwd/password command, etc), or by modification of a startup script or configuration file which does not have proper permissions set, so by running something locally, the 'footprint' of potentially vulnerable programs and files has just grown much larger.
There's also a second problem with this. . .
"Or it'll have to limit itself to installing only into user-accessible areas, in which case it won't be able to hide from utilities running from the administrative side of the system which don't access anything in your user-local areas. That makes it much easier to detect and clean up the infestation."
Ok, the program might not be able to completely own your system and hide itself forever. But: If something runs as you, it can still search your user home directory, browser cache, etc looking for email addresses, credit card numbers, social security numbers, tax id numbers, addresses, bank account numbers, etc. Just because something doesn't run as root doesn't mean it can't do some serious harm to you.
I remember hearing about a couple trojans a few years ago which were collectively dubbed something like 'ransomware', where the trojan would encrypt all your files, delete the originals, then give you a message about having to pay someone off to get the key to decrypt those files. I'm not sure how effective such a scheme would be, long-term, because any time you try to extort payment from someone, there is the possibility for law-enforcement agencies to 'follow the money' back to you and nail your butt. Also, if your 'victim' has a recent un-infected backup, they might just format the hard drive and do a clean restore. Still, anyone who got hit with a ransomware trojan would no doubt experience some serious inconvenience, or worse, from the experience.
I'm just saying, it seems a little cocky of Apple to say that Mac's are 'safe' from viruses and trojans. On the other hand, plenty of PC owners who *did* own anti-virus software have gotten infected by programs that were not detected by the A/V software, so arguably nobody is really safe from viruses, even if they have A/V soft.
"You ever build a network that stretches from one city to the next? With access points all along the highway?
I bet it cost you a hell of a lot more than $60 a month."
Wait. Did you just compare the cost for a single user to use a network to the cost to build an entire network for only 1 user?
If you want to make a comparison, you have to compare the costs of building a Co-ax or copper twisted-pair network (with fiber backbones) to every house and apartment in the city. If you can get Cable or DSL for $40/mo or less, and they have to run individual cables to every building in the city, versus setting up 4 or 6 or 10 Cell Towers, I bet it costs far *less* than $40/mo to build and operate the cellular-based network than it does to build and operate the co-ax or copper network.
Oh, by the way, the cellular companies aren't setting up Wi-Fi hotspots every 500 yards along the highways. They build 1 Cellular tower every what, 5 or 10 miles. So, with cellular technologies, to cover 100 square miles, you might need 5 towers (1 at each corner of the 10x10 mile square, and maybe 1 in the middle), whereas if you tried to use WiFi, you'd probably need hundreds or thousands of hotspots.
Again, going back to one of the points in my original post, the actual costs to run a wireless network are basically fixed, whether you have 10 users or 10k users. If the cell companies introduce 42MBit connections, but then try to charge people 200 bucks a month, very few users are going to pay 200/mo for Internet access. You might get some very rich people doing it as a form of conspicuous consumption, and you might get some business users who desperately need the capability and who can pass the costs along to their customers, but overall, you will have a fairly small user base.
I'd also like to point out that I never said $60/mo is too expensive for wireless internet (just that I'm surprised that wireless internet isn't *cheaper* than wired internet connections, because there is no line-installation and line-maintenance related costs). What I was saying about their pricing structure is that it's crazy how much the bandwidth cap jumps between the $40/mo and $60/mo tiers, which indicates to me that the cell networks must have some bandwidth issues, because a lot of people don't have $60/mo to pay for Internet access, no matter how convenient it is, and the extreme restrictions on the lower tiers seems to serve no other purpose than to discourage people from using their service. For some reason, they've chosen to keep the 'population' of their wireless networks low via their pricing scheme, so they must have pretty limited bandwidth.
Mobile Co. pricing on data connects makes no sense to me, at least here in the USA. I was checking prices at ATT, Verizon, Sprint, and T-mobile the other day.
AT&T Data plans are fairly typical (the other providers are basically the same, with the exception that none of the others offers a $20/mo 'tier'; Sprint only offers a $60/5GB tier, T-mobile offers unlimited bandwidth for $50/mo [which is the best value for data plans of all the carriers, but they have a ToS which prohibits you from doing a lot of things like P2P, hosting servers, etc on it], while Verizon offers $60/5GB and $40/50MB tiers).
From that page, you can see the following absolutely insane pricing structure:
$20/mo for a total of 10MB transfer for the whole month $40/mo for a total of 50MB transfer for the whole month $60/mo for a total of 5GB transfer for the whole month
Now, some interesting things to note is that somehow that phone company can afford to give you 100 TIMES more bandwidth when you go from $40/mo to $60/mo. What. the. hell? That'd be like a butcher offering you 1 lb. of steak for $10, or 100 lbs. of steak for $15. I understand the idea of 'the more you buy the more you save', but that is just freaking ridiculous. They are obviously price gouging any customer who wants to pay less than $60/mo, on a cost-per-MB basis.
It has always been my understanding that wireless networks are cheaper to build and operate than cable or telephone networks, so *why* are they charging so much? The simplest answer would be 'because they can'. In a free market, any provider of goods or services will charge as much as they can. *But*, one of the principles that they teach in High School economics classes is that price and profit form a curve. If you charge to little, you make less money, but if you charge too much, you also make less money. There is a 'sweet spot' where the price maximizes revenue.
Now, since I don't really know *anybody*, personally, who their mobile phone company to connect their laptop or desktop to the Internet, it tells me that, possibly, the mobile phone companies are seriously limiting their own growth in the ISP business. The only thing I can conclude is that the mobile phone companies, even though they have these high speed wireless data networks, can't actually handle the amount of bandwidth that they would need to compete with cable and landline telco companies.
Because, I imagine that if they offered 1 GB/mo for $20, 3GB/mo for $40, and 6GB/mo for $60, they'd have MANY more customers than they currently do, so I can only conclude that they don't want a lot of customers; they want a relatively small amount of customers, all paying $60/mo, or if paying less, getting *dramatically* less bandwidth, which keeps the majority of potential customers off of their network. I'd probably sign up for 1GB/mo for $20, but there's no way I'd ever pay $20 for 10MB.
Slashdot Mirror
The Free Software Foundation can only file suit when someone directly violates the copyrights of FSF software. There is a lot of GPL licensed software which the FSF does not hold copyrights for. FSF can't sue just because a program is licenses by GPL.
To sue, you either have to be the copyright holder, or maybe (not sure on this one), a downstream 'recipient' of the software. E.g. if you bought a Cisco device with GPL'ed softare, and you couldn't get the source from Cisco, you might have grounds to sue them for breaching your rights wrt to the GPL as a recipient of a binary.
I suppose that might leave some wiggle room for FSF to simply arrange to receive a copy from the violator (e.g. by a non-compliant linksys device at Best Buy), then file the lawsuit.
Someone please correct me if I'm wrong, but I think that when you compile C-code with gcc, particularly if you use .so files instead of a monolithic binary, doesn't the program have some dependencies on a libgcc.so or something like that? I suspect that you're right that the devices don't have a fully functioning GCC build environment, but I think they may distribute some components of GCC which are required to execute programs compiled with gcc. Same for binutils - I think you pretty much *need* the ld programs which are part of binutils to have a functioning Linux environment (unless you statically compile *everything*), because they implement and manage so loading on behalf of the kernel, no?
I've always been under the impression that, from a provider standpoint, density is good, because the cost per-customer is cheaper, even if you have to provision more overall bandwidth? In low-population areas, I think companies often run into under-utilization problems (or at least, potentially can), where they have to pay costs to maintain infrastructure, which is a fairly fixed cost, but might have fewer customers to a) recover the fixed infrastructure costs, and b) make an additional profit?
"Saving the internal deltas of almost anything a typical user does with a PC are not unreasonable."
What about, moving beyond mere text, word processor, and spreadsheet files, larger types of files where a single change can modify megabytes of data? For example, making a change to a graphics file, or audio file (like, for example, making an image brighter, darker, adjusting contrast, etc, which might change every pixel in the image; now, someone might propose that you don't save the change to every byte in the image, but instead just save that the user adjusted the contrast or brightness (which could probably be represented in a few bytes of data), etc, and when you re-load the file in the future, the app just 'plays back' the journal of changes.
The only problem with that, is that is an application-domain specific change; how would a general purpose, versioning file system be able to handle application specific changes? That would require a further extension of the filesystem where instead of just tracking changes to the actual file data, you have some sort of meta-data system where applications can store application-specific logs of stuff like that. That could be possible, but that then requires applications to be modified to take advantage of that. When you consider that there are thousands of legacy apps on any given platform, that means that you will likely be stuck, for a long time, with apps that still don't take advantage of the new functionality.
Still, I suppose it would be cool if someone developed the necessary filesystem to implement these kinds of things, and the corresponding system calls necessary to provide the interface between apps and the filesystem.
That seems to be a rather rude reply. First off, I never said the idea was without merit. I asked what you would do instead. That seems a reasonable question if someone is proposing a change.
I then went on to attempt to think through the problem a little bit, and offer what alternatives occured to me at the time, and any new problems I could think of that might arise from the alternatives I thought of. That does, of course, leave room for alternatives that I just wasn't creative enough to think of.
I didn't respond to most of these responses right away, as I wanted to think some more on the issue based on everyone's replies. Not sure if anyone will ever see this at this point, but here goes. . .
"what's the issue with simply saving the undo data, along with each revision".
If you can do that in a 'metadata' block in the filesystem, seperately from the actual file data, fine. But a text file does not have any concept of a journal of changes. If you create a new file format with that info, fine, but that is no longer a text file. So, you do have the issue of making sure that files remain the basic data that they are. Notepad, as our example, is designed to work with text files. Most other data file formats do not have the ability to save undo data in them (perhaps doc or odf do?).
Also, what if I am using a USB flash drive formatted with FAT32 or NTFS? Those don't support that, so I would still need the 'old style' save capability.
In fact, I would argue that for the most part, any type of functionality like this would have to be implemented at the O/S filesystem level, not the application level, although the applications *also* need to be changed so that if they detect a filesystem that supports this, they start auto-saving or continuous saving, but revert back to 'traditional' behavior when using a 'legacy' filesystem.
The biggest roadblock to this is that it requires every (well, most, anyhow) application to be updated to be compatible, before you start to see the advantages. That is, you need first the filesystem to be changed (to support the seperate-from-the-file-data change journal), then additionally the apps. Any 'legacy' application could still potentially interrupt your system reboot even with this new capability.
Do I think auto-versioning filesystems are a good idea? Heck yeah. But I'm not sure that applications having a 'save' button is really that big a deal, to worry about updating thousands of applications to get rid of it. Also, you still need to decide what directory/volume to save the file to, somewhere. Maybe when you first create a new document, before you type anything into it (or, as the case may be, record audio, record video, create graphics, create models, create level maps, etc).
Well, if you're not worried about energy, why bother with an elevator at all? What other benefit does it actually provide?
I've thought before that it would be useful, if I'm using my laptop on a public WiFi network, to be able to use a pre-designated, trusted DNS Server (so that the public network's DNS Server can't send me to bogus servers).
It would be a nice feature if I could have my computer cache the public key of my ISP's DNS Server (or maybe OpenDNS; the point is, some DNS Server *I* trust, instead of a random DNS server), then, no matter what network I connect to, always use that DNS Server, with the DNS packets being signed by the trusted server, so I know they are really from that server. (I realize I can use OpenDNS pretty much anywhere, but I don't know if there is anything preventing the local network from doing a MITM attack?)
It might also be useful, for this type of system, if my computer can authenticate to the ISP DNS Server (because they might not normally allow DNS requests from outside their own network, but if there were a specified authentication mechanism as part of the standard, they might allow me to roam if I authenticate)?
Maybe the best answer is to just use the VPN capability on my home router to always VPN to that router, which will then use my ISP's DNS. Until DNSSec is implemented widely, that's the best solution for now, anyhow, I think.
No matter what medium you are using for propulsion (Air, C02, or combusting fuel), it still requires the same amount of energy to make the stability corrections (in one case the energy comes from fuel combustion, in the other case, it comes from some sort of air pumps at the ground). The point is, that it still requires a potentially unknown amount of energy to stabilize the thing. Since the *point* of the space elevator idea is to conserve energy, the question becomes, will we actually conserve any energy with a space elevator? Plus, with an 'active' stabilization system like that, there's the posibility of something going wrong (like the air pumps at the ground going out of operation due to power loss or something), causing the whole thing to be destroyed.
The driving desire behind a space elevator is to reduce the amount of energy required to lift an object up to a point where the Earth's gravity is sufficiently weak to use 'lower power' rockets for establishing orbit, or leaving the Earth entirely. When considering the energy requirement, you can break the energy into two components - the energy of motion of the mass (kinetic energy), and the gravitational potential energy. The gravitational potential energy, if you haven't taken physics or don't remember, is the fact that in order to lift any object to a given distance above the Earth's surface requires an investment in energy. I don't know what the formula is for lifting an object that far above the Earth's surface, but we don't have to know it for this discussion. Whatever that formula is, that is the 'minimum' energy needed to get an object to a certain elevation.
A rocket or a space cannon would both essentially do the same thing - accellerate you to escape velocity (or sufficiently near it to reach the desired elevation), 11.2km/s. But, the formula for the kinetic energy of an object at 'low' speeds (and escape velocity is low compared to the speed of light) is k = .5mv^2. Where m is in kilograms, v is velocity in meters/sec, and k is energy in Joules. Because 11200^2 is a very large number ( 125440000 ), even when you halve it, it's still a large number (62720000). Which means it takes a whole lot of energy to lift anything into orbit by accellerating to, or near, escape velocity. Consider an object which, at the Earth's surface, weighs 1000 lbs (so it has a mass of 453.6 kg). To accellerate to escape velocity, that's about 28.45 GigaJoules of energy required.
The only advantage the space cannon would have is that instead of having to use a lot of fuel to propel it, you could use an array of fission or fusion reactors to supply the energy required. But it's still a lot of energy. It would be better to reduce the amount of energy needed.
Just because the Mozilla foundation will no longer be providing any updates doesn't mean there isn't the possibility of updates. Remember, FF is open source. If a security exploit is found, someone else could, at least, theoretically, provide a patch.
Funny thing, though, about old software. . . as it gets less popular (because people gradually upgrade), it simultaneously becomes a less interesting attack vector. There's maybe still enough FF2 users that it might be a worthwhile target, but as time goes on, and the installed user base shrinks, I think it becomes less likely that anyone bothers to try to find attacks for it.
T-Mobile has implemented on their network, a technology called UMA, which T-Mo markets under the name "Unlimited Hotspot Calling". Basically, for $10/mo extra on your phone plan, you can make unlimited calls via WiFi. Would be sweet if Google or someone can get UMA working on the Dev phone.
Your argument is, to some extent, self-contradictory:
"When piracy no longer gives you better content than buying it, and when people have loads of cash to spare and can afford to pay for their current content intake, THEN you can expect people to stop downloading things for free."
People who pay for stuff which they *could* pirate, largely do it because they realize the necessity of it. I *could* go to a restaraunt, and not give my waiter/waitress any tip, but that'd make me a dick. They need that income, and they *did* provide me with something of value, namely, service. Same thing with artistic works. I don't pay because I'm rich (I'm not), I pay because the investors and creators of that artistic work deserve to be paid.
Nobody has 'infinite' income, so the idea that people will stop pirating when they have more money isn't really true. Because there is *always* something else they could use the money for if they didn't spend it on music/movies/software/whatever. Someone who justifies pirating stuff when they make $20k/yr, will probably still justify it when they make $80k/yr.
As for Free Software - that is a different story; the copyright holders have chosen to give it away for free, and that's their business. I salute anyone who gives their software away, and I've even begun making donations to free software projects, on the basis that they do still need money, even if they don't demand it from everyone. Sort of a 'tip' for the software developers.
As for the DRM issue - yes, that is somewhat valid. If someone buys the DRM version, then downloads the DRM-free 'hacked' version, personally I have no problem with that. I'm sure RIAA/MPAA/software publishers do, but in that case the person did pay for it, so I don't really see the harm. Also, I would like to point out that Amazon.com, Walmart.com, and iTMS are all selling DRM-free versions of music (ok, in the iTMS case, the DRM-free catalog is somewhat limited), but that hasn't put an end to piracy of those tracks.
Art and entertainment will still be made, because there are people like me who think it's worth paying for stuff we enjoy. Other's will mooch. The one thing RIAA et. al. need to learn is that they'll never really be able to stop piracy, and trying to convince people to pay by 'scaring them straight' just isn't going to work. They need to instead convince people to pay because it enables the creators to keep creating art full time, and keeps investors putting down money to enable stuff to be made. Sometimes people justify their piracy by saying that the money isn't going to artists, it's going to publishers. I'm not saying that publishers don't ever exploit artists, but, particularly for movies and software, it takes a lot of 'up front' money to get a project completed, and those projects often couldn't *ever* be done without investors fronting the money. Movies often cost $50-$100 Million to create. So, we need to make sure investors get a return on their investment, if we want to see them continue investing in those things.
In answer to your problems:
1) "If the legacy device has an app which doesn't do DNS, how can it reach the endpoint?"
This question, I think, has to be broken down into two cases, in order to answer it:
Case A: The static IPv4 address endpoint it is trying to reach is a server which is still in operation, on the same IPv4 address, but the user has an ISP or backbone provider which is IPv6-only (so that, at some point, the traffic must go across one or more IPv6 only links), but there is still a coherent IPv4 "backbone" which, once reached, the data should be able to get to any IPv4 public IP address. In this case, the 'gateway' device does something which is the logical inverse of the current 6to4 tunnel system - more of a 4to6 - the IPv4 traffic gets automatically tunnelled through the IPv6 links to the nearest IPv4 'endpoint', then gets routed as IPv4 to the server. There might be 'traditional' IPv4 NAT involved in this, or not, depending on whether the end-user network has public addresses available for devices, or only private networks, much like today.
Of course, the eventual goal is that the server migrates to IPv6 only as well. Hopefully the device maker has put out a firmware update by this time, but, knowing the reality of the industry, and that most devices, once sold, never get firmware upgrades. . .
Case B: When the operator of the server migrates over to IPv6, they get to take their IPv4 address with them. The old IPv4 address becomes part of a new IPv6 address, with a standardized way of converting old IPv4 addresses to IPv6 addresses (standardized prefix, perhaps, similar to how 6to4 uses a standardized prefix?). So, when the old IPv4 device tries to contact the old IPv4 address, the translation gateway knows how to create an IPv6 address from the IPv4 address automatically, then forwards the traffic on.
I think those two solutions could work to solve this problem, couldn't they?
Now, in both of these cases, I'm essentially assuming that traffic is being initiated by the end-user device making an 'outbound' connection. This still leaves a question about how such devices could receive incoming traffic. This two needs two cases
Case C: IPv6 host wants to contact the end-users IPv4 device. I think, in my journal, I might have touched on this, but basically, I think the 'translation gateway' could generate an IPv6 address from the local network's IPv6:prefix::IPv4:addr, which would allow an IPv6 endpoint to contact an IPv4 endpoint.
Case D: IPv4 host contacting the end-user's IPv4 host through IPv6 links, where the end-user's IPv4 host doesn't have a 'public' IPv4 address. Much like the current Internet, you need at least 1 public IP address, and you use NAT and port forwarding, almost exactly the same as today, only with the IPv4 packet being tunneled over the IPv6 Internet (this stage would be quite a ways in the future, when significant chunks of the Internet are IPv6 only, so that your ISP maybe has no direct connection to IPv4 backbones). Somehow, there is going to have to be a table somewhere, like there are today, of how to route to a given public IPv4 address over the IPv6 Internet, so that the NAT gateway can receive the packet. Once the NAT gateway receives the tunneled packet, it does the normal IPv4 NAT/port forward to the private address.
Maybe. I'm not so sure. I don't claim to have all the answers. Someone out there might have a better answer than me on this. It just seems like it should be *possible* to address most of these issues, if people are willing to work on it.
I dunno, honestly, what is slowing adoption of IPv6. It seems more that no one is getting started. Here in the US, I don't know of any consumer ISPs that use IPv6. I'm not sure if any of the backbone providers use IPv6. Without the backbones and the ISPs switching, the switch can never really happen. Sure, people get use 6to4 or a tunnel today. But, if the ISPs, backbones, etc aren't changing, what's really the point?
IPv6 allows for address abbreviation. It is common for IPv6 addresses to have a relatively short network prefix, a bunch of zeros, then a non-zero host address. IPv6 specifies that addresses may be provided in a full form, or abbreviated form, where all the internal zeros are replaced by ::
This still only helps so much but, you can think of IPv6 addresses more as
pre:fix::host:addr
Now, that said, IPv6 addresses do still tend to be pretty long, because the 'host' portion is often the 48-bit MAC address of the host computer. The upside is that allows for automatic configuration without needing DHCP. The downside is, common IPv6 addresses are still about 80 bits of information (32-bit prefix, 48-bit host).
The real answer is, of course, host names/DNS. Don't bother remembering numeric addresses, except for the DNS servers, routers, etc and give them an address like:
pre:fix::1
(I believe you can statically assign an arbitrary host IP to something like a DNS server or router, so you can use ::1, ::2, ::3, etc. for the servers/devices that absolutely must be accessed by static addresses).
It's not so bad remembering 2579:2a3d::1
There's an infinite difference between 0 and. . . almost 0. If IPv6 adoption was 0.001 percent of total Internet hosts last year, and it's 0.003 this year, that is, technically, 300% growth. Not necessarily very meaningful, but still 300 percent growth.
I was thinking about this recently. I don't have the know-how to actually code up a proof of concept of my idea, but I did some 'high-level' thinking about the transition problem and posted an entry in my slashdot journal. I just Googled the NAT64 you mentioned, and that looks (from a cursory glance; I didn't have time to read the full draft RFC) like it's describing something like what I have in mind. I think once something like that is widely available, the 4-to-6 transition can begin.
It would also help if device makers started supporting IPv6 in firmware. For example, you can find plenty of network and WiFi printers right now. Good luck finding one that supports IPv6 though. This is they type of thing where the government could step in and show some initiative. I'm generally a free-market guy, but with something like the IPv6 transition, sometimes some leadership is necessary to start things off. Seems like a government regulation mandating network device makers to start including IPv6 support in any device which claims TCP/IP compatibility [after some reasonable threshold date, say June 1, 2009, or Dec 31 2009], would be a good starting point.
Sort of. Ok, what I describe below might not really fit the definition of NAT, so read on for what I mean.
Allow me to explain. One of the 'hardest' problems I hear mentioned when people discuss transitioning to IPv6 is the problem of legacy devices - printers, video game systems (think XBox Live), Tivos, etc.
It occurs to me that, at the ISP level, or possibly at the home/company router level (depending on your needs, it could be either place), a device could 'translate' packets between IPv4 and IPv6, so that legacy devices talk using IPv4 to the router, and the router does something similar in concept to NAT, where it creates IPv6 packets to forward on to IPv6 hosts and devices.
In such a situation, every ISP or home user can have their own entire IPv4 "virtual Internet" worth of IPv4 addresses.
I posted a longer article, a few weeks ago, in my user Journal, describing in a little more detail what I have in mind. Is there any reason something like this couldn't be made to work, to assist in transitioning to IPv6?
"Nothing anywhere is completely safe. Everything you own is up for grabs at any point in time by anyone who wants it bad enough. Best course of action I can think of is to buy a gun."
What if what they want really badly is your gun? By your own admission, "Everything you own is up for grabs at any point in time by anyone who wants it bad enough." That would include the gun, seems like.
It seems to me that part of the problem is that too many websites that service too many customers are all using a *single* payment service. Hijack that one payment service, and you can potentially hit 10's of millions of customers.
I don't see why giant national banks, and even mid-size regional banks, can create their *own* online payment services. Heck, they might even be able to generate new streams of revenue for themselves, instead of giving all that revenue to Checkfree. If nothing else, it helps to limit the scope of damage from one provider getting compromised.
For small banks and CUs, I could see that they might not have the resources to create their own online payment service, but if the larger banks were creating more online payment services, maybe there'd at least be a little more diversity in the systems being used by the small banks.
What would you do instead of file save? Continuous save, where the file data is saved as you type? What if you decide the changes you made were a mistake? I think one of the basic premises, going a very long way back in the design of software, is that you don't immediately save changes, so that the user can make a choice whether to 'commit' the changes, or throw them away and revert back to the original state of the file. As far as I know, Notepad will only temporarily stop the shutdown of the computer, to ask you do you want to save the file - yes/no? I don't see how that is such a bad thing?
Now, you might say that the solution for this is automatic file versioning. The problem is that if you have continuous save, you would either get a version for every single character typed, deleted, etc, or else you would get 'periodic' versions (like, a version from 30 seconds ago, a version from 30 seconds before that, etc) and pretty soon you'd have a ridiculous number of 'intermediate' versions. File versioning should, ideally, only be saving essentially 'completed' versions of the file (or at least, only such intermediate versions as the user chooses to save [because, if you are creating a large document, like a Master's Thesis, or book, you will probably not create it all in a single session, so in that case, you might have versions which don't correspond to completed 'final products', but you probably also don't want 1000 different versions either], instead of a large number of automatically created versions).
"So someone may trick you into running the installer for that rootkit, but the installer can't then put the rootkit into the system areas. The OS simply won't allow it to write to those areas. So it'll either fail, or it'll have to have the OS prompt you to allow it to mess with the system areas."
There's one problem with this. . . the potential for un-patched vulnerabilities in user-accessible programs which allow privilege escalation. The original poster mentioned how, for a worm on the network to attack a Mac (or Unix, for that matter) system, there were only a few network services for it to exploit vulnerabilities in: ssh, postfix, apache, etc. I agree that is a pretty small 'footprint'. But, now if I run a program locally on my computer as my user account, the possibility exists that their is an unpatched vulnerability in some program somewhere which would allow for privilege escalation (anything which would be 'suid' root, like su/sudo [does OSX have an equivalent to su/sudo], the passwd/password command, etc), or by modification of a startup script or configuration file which does not have proper permissions set, so by running something locally, the 'footprint' of potentially vulnerable programs and files has just grown much larger.
There's also a second problem with this. . .
"Or it'll have to limit itself to installing only into user-accessible areas, in which case it won't be able to hide from utilities running from the administrative side of the system which don't access anything in your user-local areas. That makes it much easier to detect and clean up the infestation."
Ok, the program might not be able to completely own your system and hide itself forever. But: If something runs as you, it can still search your user home directory, browser cache, etc looking for email addresses, credit card numbers, social security numbers, tax id numbers, addresses, bank account numbers, etc. Just because something doesn't run as root doesn't mean it can't do some serious harm to you.
I remember hearing about a couple trojans a few years ago which were collectively dubbed something like 'ransomware', where the trojan would encrypt all your files, delete the originals, then give you a message about having to pay someone off to get the key to decrypt those files. I'm not sure how effective such a scheme would be, long-term, because any time you try to extort payment from someone, there is the possibility for law-enforcement agencies to 'follow the money' back to you and nail your butt. Also, if your 'victim' has a recent un-infected backup, they might just format the hard drive and do a clean restore. Still, anyone who got hit with a ransomware trojan would no doubt experience some serious inconvenience, or worse, from the experience.
I'm just saying, it seems a little cocky of Apple to say that Mac's are 'safe' from viruses and trojans. On the other hand, plenty of PC owners who *did* own anti-virus software have gotten infected by programs that were not detected by the A/V software, so arguably nobody is really safe from viruses, even if they have A/V soft.
"You ever build a network that stretches from one city to the next? With access points all along the highway?
I bet it cost you a hell of a lot more than $60 a month."
Wait. Did you just compare the cost for a single user to use a network to the cost to build an entire network for only 1 user?
If you want to make a comparison, you have to compare the costs of building a Co-ax or copper twisted-pair network (with fiber backbones) to every house and apartment in the city. If you can get Cable or DSL for $40/mo or less, and they have to run individual cables to every building in the city, versus setting up 4 or 6 or 10 Cell Towers, I bet it costs far *less* than $40/mo to build and operate the cellular-based network than it does to build and operate the co-ax or copper network.
Oh, by the way, the cellular companies aren't setting up Wi-Fi hotspots every 500 yards along the highways. They build 1 Cellular tower every what, 5 or 10 miles. So, with cellular technologies, to cover 100 square miles, you might need 5 towers (1 at each corner of the 10x10 mile square, and maybe 1 in the middle), whereas if you tried to use WiFi, you'd probably need hundreds or thousands of hotspots.
Again, going back to one of the points in my original post, the actual costs to run a wireless network are basically fixed, whether you have 10 users or 10k users. If the cell companies introduce 42MBit connections, but then try to charge people 200 bucks a month, very few users are going to pay 200/mo for Internet access. You might get some very rich people doing it as a form of conspicuous consumption, and you might get some business users who desperately need the capability and who can pass the costs along to their customers, but overall, you will have a fairly small user base.
I'd also like to point out that I never said $60/mo is too expensive for wireless internet (just that I'm surprised that wireless internet isn't *cheaper* than wired internet connections, because there is no line-installation and line-maintenance related costs). What I was saying about their pricing structure is that it's crazy how much the bandwidth cap jumps between the $40/mo and $60/mo tiers, which indicates to me that the cell networks must have some bandwidth issues, because a lot of people don't have $60/mo to pay for Internet access, no matter how convenient it is, and the extreme restrictions on the lower tiers seems to serve no other purpose than to discourage people from using their service. For some reason, they've chosen to keep the 'population' of their wireless networks low via their pricing scheme, so they must have pretty limited bandwidth.
Mobile Co. pricing on data connects makes no sense to me, at least here in the USA. I was checking prices at ATT, Verizon, Sprint, and T-mobile the other day.
AT&T Data plans are fairly typical (the other providers are basically the same, with the exception that none of the others offers a $20/mo 'tier'; Sprint only offers a $60/5GB tier, T-mobile offers unlimited bandwidth for $50/mo [which is the best value for data plans of all the carriers, but they have a ToS which prohibits you from doing a lot of things like P2P, hosting servers, etc on it], while Verizon offers $60/5GB and $40/50MB tiers).
From that page, you can see the following absolutely insane pricing structure:
$20/mo for a total of 10MB transfer for the whole month
$40/mo for a total of 50MB transfer for the whole month
$60/mo for a total of 5GB transfer for the whole month
Now, some interesting things to note is that somehow that phone company can afford to give you 100 TIMES more bandwidth when you go from $40/mo to $60/mo. What. the. hell? That'd be like a butcher offering you 1 lb. of steak for $10, or 100 lbs. of steak for $15. I understand the idea of 'the more you buy the more you save', but that is just freaking ridiculous. They are obviously price gouging any customer who wants to pay less than $60/mo, on a cost-per-MB basis.
It has always been my understanding that wireless networks are cheaper to build and operate than cable or telephone networks, so *why* are they charging so much? The simplest answer would be 'because they can'. In a free market, any provider of goods or services will charge as much as they can. *But*, one of the principles that they teach in High School economics classes is that price and profit form a curve. If you charge to little, you make less money, but if you charge too much, you also make less money. There is a 'sweet spot' where the price maximizes revenue.
Now, since I don't really know *anybody*, personally, who their mobile phone company to connect their laptop or desktop to the Internet, it tells me that, possibly, the mobile phone companies are seriously limiting their own growth in the ISP business. The only thing I can conclude is that the mobile phone companies, even though they have these high speed wireless data networks, can't actually handle the amount of bandwidth that they would need to compete with cable and landline telco companies.
Because, I imagine that if they offered 1 GB/mo for $20, 3GB/mo for $40, and 6GB/mo for $60, they'd have MANY more customers than they currently do, so I can only conclude that they don't want a lot of customers; they want a relatively small amount of customers, all paying $60/mo, or if paying less, getting *dramatically* less bandwidth, which keeps the majority of potential customers off of their network. I'd probably sign up for 1GB/mo for $20, but there's no way I'd ever pay $20 for 10MB.