WinNT's POSIX compliance support in NTFS is intended for use by applications running in the POSIX subsystem - this is a mode in which apps can't make Win32 calls, and incredibly limited, so it's virtually useless for real applications.
The main purpose of the POSIX subsystem appears to have been to let NT meet government procurement specifications, rather than to enable real applications to be written. One result of this is that the various Unix emulation layers, such as Cygwin, are all implemented on the Win32 API, which does not have these limitations.
The MPLS-enabled switches (ATM, Optical, etc) will look like IPv4 and/or IPv6 routers - turning such a switch from IPv4 into dual-stack or IPv6 is just a matter of changing the control plane (routing) software on the switch, and doesn't have any impact on the data (forwarding) plane.
This is one reason why MPLS may be a good way of deploying IPv6 in large core networks - it removes the need to upgrade silicon to forward IPv6 packets, as long as the core switches/routers are MPLS capable. Only the edge MPLS routers (label switch routers in the jargon) need to actually forward IPv6 packets, all the core LSRS just do label-swapping or optical switching.
Somebody please mod this one up - clearly a lot of people think 'RFC = Standard', when the ECN RFC is clearly Experimental and explicitly not meant for production usage...
Currently there is *absolutely no practical benefit* in setting ECN bits in Internet packets today, because you need ECN capable routers throughout a network (or at least at bottleneck points) for ECN to be useful.
ECN is intended to work like this:
- ECN-capable host sends packets, setting the ECN-Capable bit in the IP Header's TOS byte to 1 so that routers know ECN is worth using
- packet experiences congestion in a router somewhere, i.e. router queue is filling up but not yet full
- router, rather than dropping the packet (which it could do, see WRED), chooses to forward the packet but mark it as 'congestion experienced' using a spare bit in the TOS byte of the IP header.
- host senses that congestion was experienced and does something about it - essentially the same as if the packet was dropped (e.g. TCP will halve its window size) but with the benefit of being able to process the packet rather than having to wait.
The end result should be quicker adaptation to congestion conditions, by avoiding some timeouts and retransmissions.
ECN is an interesting technique, but it will take a long time for it to be tested and debugged in realistic conditions, and for people to deploy it widely (perhaps in a modified version that is Standards Track within the IETF). Some routers, particularly routers in the core of the Internet, may never use ECN, since dropping packets is easier than modifying one bit.
Turning on ECN now will at least mean that some firewalls won't drop packets with ECN bits set, which is probably a good thing, but it's only going to help the ECN researchers in practical terms.
There's some interesting stuff around on faster recovery and convergence - see http://www.nanog.org/, recent presentations, and in particular http://www.packetdesign.com/Docs/isis.pdf which talks about millisecond-level convergence through better algorithms and faster updates on big links, etc.
You can also use layer 2/2.5 type technologies, such as SONET Automatic Protection Switching (APS) or MPLS Fast Recovery, which can recover much faster from certain types of failures. However, this won't address the whole issue.
ISPs that serve the business market are adding extra services such as IP VPNs, competing with Frame Relay and ATM, and are having to improve their availability figures - over time, this technology will filter down to the consumer market.
The Internet is already much more reliable and much faster than it was in 1995 - hopefully this will continue...
- you need routers at the edge of any optical network to talk to the copper world, and currently the bottleneck is building terabit/petabit routers that will go fast enough (as well as doing added value stuff on the edge such as QoS and VPN processing). Cisco, Juniper, Avici and co should carry on doing well.
- over time, optical switches are likely to become MPLS-enabled, meaning that they have an IP+MPLS (Multiprotocol Label Switching) control plane, and *appear* to be routers even though MPLS is laying down all-optical paths through all these switches. There is a lot of work going on in this area, but ultimately it means that ATM switches, Frame Relay switches, SONET cross-connect switches, and DWDM lambda switches will all look like IP routers. This is a Good Thing, since otherwise the edge IP routers would have to peer directly with all the other edge routers, generating too much routing traffic and consuming too much CPU in each router to be viable (the 'large, flat network' problem).
- Optical Burst Switching is a way of building all-optical switches (at least in the data path) that can at least switch packet trains (bursts). What happens is that an edge device signals ahead of the actual packet burst, on a separate control channel - the delay between the control packet and the data burst gives the electronic control-path part of the optical switch enough time to do the switching (5 ns is a long time at optical rates). This is an alternative to using MPLS or similar to lay down optical paths that are more or less fixed - of course, reliable and fast setup of switching is important to this working well.
This is really horrible - anything that discourages ingress filtering makes it a lot easier for script kiddies to DDoS the world. And routing all traffic via the waypoint server means you have now created a centralised network with sub-optimal routing.
This really does illustrate how successive kludges on top of IPv4 (NAT, AVES, etc) will make it essential to migrate to IPv6...
IPv6 may well happen first in mobile networks - this is due to the number of mobile phones (about 500 million currently), and the fact they are becoming IP enabled (about 70% of mobile phones use GSM, and most GSM networks are going GPRS, enabling IP to the phone).
GPRS is an easy upgrade for GSM networks and US TDMA (IS-36, i.e. digital cellular other than CDMA) networks. It includes a tunnelling protocol that allows the tunnelled address of the phone to be IPv4 or IPv6. And in the 3G world, IPv6 is part of the standards from the beginning.
I can't see any changes in the Bigfoot pricing model, at least since a few years ago when I signed up. They have a few premium services that are chargeable, but not all the premium services are for-pay in any case.
I would actually be happier to pay $20 to $40 per year for email forwarding - my main worry is that Bigfoot will go bust, since they have no visible means of support, and my email address will no longer be usable...
Useful mapping - there really needs to be a site that explains all this stuff.
BTW W-CDMA is the (main) air interface for UMTS, just as cdma2000 is the air interface for the 3GPP2's 3G standards. UMTS covers the whole network, including air interface, radio access and core network.
One interesting ray of hope in this standards mess is that AT&T recently decided to go for UMTS in the US, and Qualcomm is making dual-mode (cdma2000 and W-CDMA) chipsets, so it may be possible to have a single 3G phone that can roam anywhere in the world... Either UMTS will take off in the US (unlikely) or dual-mode phones will let you use any 3G network world wide. Currently, the US and Japan have mainlynon-GSM phone standards, so global roaming is not quite there.
The 2.4 Mbps figure only applies to static users of 3G wireless - typically within a building (called a picocell). Users who moving about get much less - 384 Kbps when walking or 128 Kbps when in a moving car.
Also, the number of users in a given cell, or that part of the network, will affect things - generally, though, once you have a session at X Kbps, you keep it even if other users try to connect - a bit like dialling into a modem pool, though in some circumstances a higher priority user could cause you to be kicked off.
3G will be way too expensive to use as a fixed wireless connection - there's a lot of complexity in managing mobile users, so why pay for that when you can just use broadband fixed wireless.
Have a look at LMDS, MMDS and VOFDM, not to mention wireless optics - these are all designed to connect a fixed site to a network, and can give broadband connections without the costs of 3G.
3G providers will probably charge by amount of data transferred, but hopefully will bundle a large amount of data transfer per month for a reasonable fee. Also, content providers such as e-commerce sites, banks, media sites, and so on, may be able to subsidise costs out of their transaction/subscription fees - e.g. if watching videos over 3G turns into a real market, i.e. pay per view, it would make sense to bundle the 3G communications cost into the video fee.
We all want 24/7 unlimited flat rate bandwidth, but someone has to pay for the roll-out of 3G or whatever wireless data system actually wins. If you mainly do interactive stuff rather than multimedia, the per-month flat fee would probably cover all your usage. For low cost multimedia you may need to wait for 4G...
For some reason, the US has incredibly fragmented cellular standards - AMPS, D-AMPS, TDMA, CDMA and even GSM. I think it's the last major country to still be using analogue phones at all.
This, along with the size of the US, is probably why there are still problems with coverage, because no one network operator can afford to cover the whole US, and the standards are too diverse to allow seamless roaming between networks.
The rest of the world (with a few exceptions) has standardised on GSM, and voice coverage and quality is generally excellent - the term 'cell phone quality' is meaningless in GSM countries because the voice quality is just as good as a fixed line. I use my phone in various European countries with no problems.
3G is going to take enormous investments, but the GSM world is going GPRS anyway, which gives you always-on packet mode at rates of 20 to 100 Kbps depending on user density in cells, and is a much simpler upgrade. So even if we are using GPRS for a few years before 3G, there will be packet mode services available to GSM phones. (GSM does exist in the US, e.g. Voicestream, but it's very patchy because it's in competition with so many other standards.)
Ricochet is not the only game in town, and is proprietary as far as I can tell. For people who travel a lot, it's more useful to have wide coverage from pretty much every cellular provider, around the world - 3G promises to provide this, and in the interim there's GPRS, a 2.5G technology based on the world-wide GSM standard, and already deployed in early stages in various countries.
As for per-minute billing - there's no technical or business reason why 3G will work like this for data. Providers will be able to bill flat rate, or a fixed fee for certain amount of data transfer, or whatever. 3G data and GPRS are packet based standards, not circuit based like current cell phones.
You are right, of course - 3GPP2 is a CDMA-oriented 3G standards development project, mainly focused on the US and some other CDMA markets. So this version of CDMA is a standard, although not exactly a global one.
3GPP, a similar effort that predates 3GPP2, is defining a version of 3G called UMTS that is more GSM-oriented (though using CDMA, upgrades from GSM networks will be easier) - this is what will be used in Europe, most of Asia, and by AT&T in the US. Depending on how the standards wars pan out, you may still be able to use a UMTS phone anywhere, but it will take a long time for either 3G standard to get very broad coverage - so multimode phones (e.g. current CDMA and cdma2000/3GPP2, or GSM and UMTS) will be important for a long time.
As for HSCSD - this is an upgrade to GSM that simply bundles 2 or more GSM calls together for increased bandwidth (up to 28.8 Kbps I think). It's somewhat of a dead end, and not implemented by many telcos - the packet-oriented standards, such as GPRS, EDGE, UMTS, and 3GPP2's work, are much more interesting, as they turn the phone into an always-on device that can dump IP packets into the network whenever it wants.
IPv6 will also help, though not mandatory for any of these standards yet, by giving your phone a static IP address - run a web server on your phone (if you can afford the air time...)
CDMA is the radio interface, and in this case stands for Code Division Multiple Access - nothing to do with Ethernet's CDMA.
The rest of the 3G radio access networks (i.e. the radio bits and everything that networks the base stations to the core) aren't based on Ethernet either - typically it's ATM, Frame Relay or IP.
The interesting part is that 3G infrastructure (at least the variant to be used almost everywhere but US/Canada) allows you to request a certain bandwidth, latency, jitter (latency variation), etc. Subject to your ability to pay, you then get the QoS you need, right the way through the radio access part and onto whatever IP network you want to get to.
There are many problems with 3G, including who's going to invest in the massive upgrades required (the entire network changes, radio and core), who's going to use it, what the killer application will be, and whether it will be too expensive for consumers (particularly in Europe, where the UK and other governments have managed to obtain ludicrously high license fees for 3G spectrum). But it's an interesting technology, and the bandwidth will only be oversold if that's the QoS level that people want. I suspect Sprint et al will sell a mixture of high QoS (for voice, video, and business users who need a VPN back to base) and medium/low QoS (for web surfing and general content/transactions).
3G has some other cool features - e.g. you can have connections to 2 or more base stations simultaneously, which makes your connection more resilient to obstacles and interference, as well as making it very easy to hand off from one cell to another. You should also be able to roam anywhere in the world with a 3G phone (particularly if US networks adopt UMTS, the global 3G standard, but multimode phones may help there even if not), and you can even switch to a different provider in the course of a single session.
Unfortunately there is not much digestible information on the Web, and the whole area is buried in acronyms...
"Windows offers a friendly environment that makes it easy to use software."
I've recently been getting my uncle, who is in his eighties, into using a Windows PC.
This is the first time he's used a computer, though he has used keyboards before, and it's made it clear to me that, for the average person, *using computers is still too hard*. It's easy to forget this when you've been using computers much of your life, and are surrounded by basically PC literate people at work.
Windows is certainly easier to use than DOS, but I've had to simplify the Windows setup so much that I could do this equally well under Linux. The only reason I didn't is that my uncle's friends provide local tech support, and they know Windows. Also, he can get local training in using computers.
One of the hardest things was the atrociously complex interface to dialup networking in Windows NT, and the way IE4's Offline/Online setting is shared with Outlook Express - I ended up buying a shareware dialer so that I could set up Netscape as the browser, not for ideological reasons but so that it wouldn't mess up the Outlook Express offline settings (which make it easy to compose email offline).
The lessons for Linux or any Windows alternative are:
- focus on real ease of use with non-PC literate users (Redmond Linux is getting quite close to this with task-based menus and so on - see http://www.redmondlinux.org/). Microsoft is pretty good at this, but maybe Eazel and Ximian type companies will run their own usability labs.
- incorporate natural language and voice input technologies - the keyboard and mouse are still barriers for some people
- settle on a single 'default' GUI, so that local training and support can be obtained without the 'I only know GNOME' syndrome
If my uncle lived round the corner, Linux would have worked well, but supporting someone 100 miles away solely through the phone and dialin is just too hard.
NAT breaks applications that are rash enough to embed IP addresses or port numbers (including FTP where you have to use the annoying passive FTP variant to get it to work) - this is common in slightly more advanced applications, and having to design around this is an unnecessary restriction (a bit like having to code within a 640K memory limit these days).
When IPv6 is deployed, a competitive market will grow up that delivers thousands of IPv6 addresses for a similar price to one IP address today. There is no extra cost to doing this, so any ISP that does not will be undercut by one who does. IPv4 address pricing is a direct result of the scarcity of address space. There are still hundreds to thousands of ISPs in most developed countries, so there is plenty of room for competition.
Your argument on IP mobility is similar to that for applications that don't code around NAT restrictions - there are always workarounds (e.g. reconnect all your TCP sessions) but they will cramp your style when moving between different Layer 2 technologies. If you don't want a wireless laptop, others will, and there are many other internet-connected devices such as PDAs and mobile phones that will also benefit.
The whole drive to P2P applications makes it much more desirable to have a static IP address. Again, not essential, but once you have enough IP addresses, application developers can concentrate on the important parts of their apps, rather than on beating NAT and the lack of static IP addresses.
There are some amazingly irony-impaired people around... My original post was actually criticising AOL by analogy to the more obviously broken *hypothetical* situation of non-interoperable phone standards. This situation never happened BTW - the worst that happened was that you needed a Ma Bell phone to plug into AT&T lines, but you could still call someone in the UK.
The second paragraph also stated how pointless AOL's restrictions were, but I guess you both replied before reading that.
Mainframes are surprisingly CPU-poor by Unix server and PC standards (or at least they were last time I looked) - but they generally make up for this with astonishingly good I/O capabilities.
Back when I was investigating Ingres on IBM mainframe Unix in the early 90s, I worked out that it could support perhaps 20 users, compared to hundreds with DB2 running on MVS (i.e. native mode not Unix). Ingres, like most Unix-based RDBMSs, assumed that CPU could be spent freely to save I/O (the best approach for mid-range Unix boxes), while DB2 assumed the opposite.
Anyway, the key point IMO is to choose a suitably I/O-focused application for Linux/390 - serving mostly static web pages would be fine, and CGI might be OK if you are using an efficient technique (e.g. Java with compilation to native code, or just very short CGI scripts in mod_perl), but generally any heavy computation should be avoided.
NAT breaks many applications (e.g. active FTP, NetMeeting, IPSec VPNs with IKE, many online games and so on). Where applications can get round NAT, they become more complex - e.g. Groove and other P2P apps must jump through hoops or rely on central servers. NAT does provide some security by default, but that's mainly by making it very hard for outside clients to talk to inside servers; a firewall can provide equivalent security quite easily.
If you ever want to be able to call in to a system at home (e.g. to tell your TiVo to record something), it will need a non-NATed configuration. IPv6 is the only way to do this without quickly running out of IP addresses - RSIP (Realm-Specific IP, a combination of tunnelling and IP address management) doesn't solve the 'call ing in' problem as far as I can see.
Before too long you'll want laptops to be able to roam between 3G networks when away from home, and then roam back to your Wi-Fi (802.11) wireless LAN at home. IPv6 enables much simpler IP mobility, i.e. your laptop keeps the same IP address (at least as far as TCP's concerned) no matter where you are. None of this is possible with NAT getting in the way - in fact, getting rid of NAT is one of the main reasons for IPv6.
"I don't know what the current figures are. But on the date that Windows 95 was released, the most common type of non-server computer hardware in businesses was... the 80286!"
The 286 was obsolete by the end of the 1980s - the most common hardware in 1995 was probably either the 486 or Pentium. I had a 486 laptop in 95, and the desktops around me were Pentia.
Yes, AOL are in their rights here - just like your local phone company would be completely justified in requiring you to buy its phones only, and to prevent anyone with an 'unauthorised' phone from calling you.
Instant messaging is currently hobbled by islands of proprietary protocols, and AOL's efforts to stop the tide of interoperability are as pointless as Canute's.
LTSP is very impressive, on reading the docs a bit further - despite the name, it can actually support *both* local apps (running on the diskless workstation) and remote apps (server-based in Windows parlance, i.e. running on the server). The latter is the only option with Windows Terminal Server (or Citrix MetaFrame), so LTSP is much more flexible.
If you have fairly old PCs (386, 486, Pentium), just buy a modern server and run the apps there. Even old Windows boxes or Macs will be fine - they just need to run an X server. More work to set up, but worth trying if the old hardware is still reliable and can run Linux without hassles.
If you need to run more compute-intensive apps and have the budget, you can buy new diskless workstation PCs. This is probably easier to set up, too, but the key thing is you have a choice of models - and whichever model you use, the system admin load is very low, because only the server needs administering.
See http://www.ltsp.org/documentation/lts_ig_v2.3/lts_ ig_v2.3-8.html for discussion of local vs. remote apps.
Slashdot Mirror
You could always just point to a TiVo - it has a pleasant, friendly user interface and is of course Linux based.
WinNT's POSIX compliance support in NTFS is intended for use by applications running in the POSIX subsystem - this is a mode in which apps can't make Win32 calls, and incredibly limited, so it's virtually useless for real applications.
The main purpose of the POSIX subsystem appears to have been to let NT meet government procurement specifications, rather than to enable real applications to be written. One result of this is that the various Unix emulation layers, such as Cygwin, are all implemented on the Win32 API, which does not have these limitations.
The MPLS-enabled switches (ATM, Optical, etc) will look like IPv4 and/or IPv6 routers - turning such a switch from IPv4 into dual-stack or IPv6 is just a matter of changing the control plane (routing) software on the switch, and doesn't have any impact on the data (forwarding) plane.
This is one reason why MPLS may be a good way of deploying IPv6 in large core networks - it removes the need to upgrade silicon to forward IPv6 packets, as long as the core switches/routers are MPLS capable. Only the edge MPLS routers (label switch routers in the jargon) need to actually forward IPv6 packets, all the core LSRS just do label-swapping or optical switching.
Somebody please mod this one up - clearly a lot of people think 'RFC = Standard', when the ECN RFC is clearly Experimental and explicitly not meant for production usage...
Currently there is *absolutely no practical benefit* in setting ECN bits in Internet packets today, because you need ECN capable routers throughout a network (or at least at bottleneck points) for ECN to be useful.
ECN is intended to work like this:
- ECN-capable host sends packets, setting the ECN-Capable bit in the IP Header's TOS byte to 1 so that routers know ECN is worth using
- packet experiences congestion in a router somewhere, i.e. router queue is filling up but not yet full
- router, rather than dropping the packet (which it could do, see WRED), chooses to forward the packet but mark it as 'congestion experienced' using a spare bit in the TOS byte of the IP header.
- host senses that congestion was experienced and does something about it - essentially the same as if the packet was dropped (e.g. TCP will halve its window size) but with the benefit of being able to process the packet rather than having to wait.
The end result should be quicker adaptation to congestion conditions, by avoiding some timeouts and retransmissions.
ECN is an interesting technique, but it will take a long time for it to be tested and debugged in realistic conditions, and for people to deploy it widely (perhaps in a modified version that is Standards Track within the IETF). Some routers, particularly routers in the core of the Internet, may never use ECN, since dropping packets is easier than modifying one bit.
Turning on ECN now will at least mean that some firewalls won't drop packets with ECN bits set, which is probably a good thing, but it's only going to help the ECN researchers in practical terms.
There's some interesting stuff around on faster recovery and convergence - see http://www.nanog.org/, recent presentations, and in particular http://www.packetdesign.com/Docs/isis.pdf which talks about millisecond-level convergence through better algorithms and faster updates on big links, etc.
You can also use layer 2/2.5 type technologies, such as SONET Automatic Protection Switching (APS) or MPLS Fast Recovery, which can recover much faster from certain types of failures. However, this won't address the whole issue.
ISPs that serve the business market are adding extra services such as IP VPNs, competing with Frame Relay and ATM, and are having to improve their availability figures - over time, this technology will filter down to the consumer market.
The Internet is already much more reliable and much faster than it was in 1995 - hopefully this will continue...
A few things to think about:
- you need routers at the edge of any optical network to talk to the copper world, and currently the bottleneck is building terabit/petabit routers that will go fast enough (as well as doing added value stuff on the edge such as QoS and VPN processing). Cisco, Juniper, Avici and co should carry on doing well.
- over time, optical switches are likely to become MPLS-enabled, meaning that they have an IP+MPLS (Multiprotocol Label Switching) control plane, and *appear* to be routers even though MPLS is laying down all-optical paths through all these switches. There is a lot of work going on in this area, but ultimately it means that ATM switches, Frame Relay switches, SONET cross-connect switches, and DWDM lambda switches will all look like IP routers. This is a Good Thing, since otherwise the edge IP routers would have to peer directly with all the other edge routers, generating too much routing traffic and consuming too much CPU in each router to be viable (the 'large, flat network' problem).
- Optical Burst Switching is a way of building all-optical switches (at least in the data path) that can at least switch packet trains (bursts). What happens is that an edge device signals ahead of the actual packet burst, on a separate control channel - the delay between the control packet and the data burst gives the electronic control-path part of the optical switch enough time to do the switching (5 ns is a long time at optical rates). This is an alternative to using MPLS or similar to lay down optical paths that are more or less fixed - of course, reliable and fast setup of switching is important to this working well.
This is really horrible - anything that discourages ingress filtering makes it a lot easier for script kiddies to DDoS the world. And routing all traffic via the waypoint server means you have now created a centralised network with sub-optimal routing.
This really does illustrate how successive kludges on top of IPv4 (NAT, AVES, etc) will make it essential to migrate to IPv6...
IPv6 may well happen first in mobile networks - this is due to the number of mobile phones (about 500 million currently), and the fact they are becoming IP enabled (about 70% of mobile phones use GSM, and most GSM networks are going GPRS, enabling IP to the phone).
GPRS is an easy upgrade for GSM networks and US TDMA (IS-36, i.e. digital cellular other than CDMA) networks. It includes a tunnelling protocol that allows the tunnelled address of the phone to be IPv4 or IPv6. And in the 3G world, IPv6 is part of the standards from the beginning.
I can't see any changes in the Bigfoot pricing model, at least since a few years ago when I signed up. They have a few premium services that are chargeable, but not all the premium services are for-pay in any case.
I would actually be happier to pay $20 to $40 per year for email forwarding - my main worry is that Bigfoot will go bust, since they have no visible means of support, and my email address will no longer be usable...
Useful mapping - there really needs to be a site that explains all this stuff.
BTW W-CDMA is the (main) air interface for UMTS, just as cdma2000 is the air interface for the 3GPP2's 3G standards. UMTS covers the whole network, including air interface, radio access and core network.
One interesting ray of hope in this standards mess is that AT&T recently decided to go for UMTS in the US, and Qualcomm is making dual-mode (cdma2000 and W-CDMA) chipsets, so it may be possible to have a single 3G phone that can roam anywhere in the world... Either UMTS will take off in the US (unlikely) or dual-mode phones will let you use any 3G network world wide. Currently, the US and Japan have mainlynon-GSM phone standards, so global roaming is not quite there.
The 2.4 Mbps figure only applies to static users of 3G wireless - typically within a building (called a picocell). Users who moving about get much less - 384 Kbps when walking or 128 Kbps when in a moving car.
Also, the number of users in a given cell, or that part of the network, will affect things - generally, though, once you have a session at X Kbps, you keep it even if other users try to connect - a bit like dialling into a modem pool, though in some circumstances a higher priority user could cause you to be kicked off.
3G will be way too expensive to use as a fixed wireless connection - there's a lot of complexity in managing mobile users, so why pay for that when you can just use broadband fixed wireless.
Have a look at LMDS, MMDS and VOFDM, not to mention wireless optics - these are all designed to connect a fixed site to a network, and can give broadband connections without the costs of 3G.
3G providers will probably charge by amount of data transferred, but hopefully will bundle a large amount of data transfer per month for a reasonable fee. Also, content providers such as e-commerce sites, banks, media sites, and so on, may be able to subsidise costs out of their transaction/subscription fees - e.g. if watching videos over 3G turns into a real market, i.e. pay per view, it would make sense to bundle the 3G communications cost into the video fee.
We all want 24/7 unlimited flat rate bandwidth, but someone has to pay for the roll-out of 3G or whatever wireless data system actually wins. If you mainly do interactive stuff rather than multimedia, the per-month flat fee would probably cover all your usage. For low cost multimedia you may need to wait for 4G...
For some reason, the US has incredibly fragmented cellular standards - AMPS, D-AMPS, TDMA, CDMA and even GSM. I think it's the last major country to still be using analogue phones at all. This, along with the size of the US, is probably why there are still problems with coverage, because no one network operator can afford to cover the whole US, and the standards are too diverse to allow seamless roaming between networks.
The rest of the world (with a few exceptions) has standardised on GSM, and voice coverage and quality is generally excellent - the term 'cell phone quality' is meaningless in GSM countries because the voice quality is just as good as a fixed line. I use my phone in various European countries with no problems.
3G is going to take enormous investments, but the GSM world is going GPRS anyway, which gives you always-on packet mode at rates of 20 to 100 Kbps depending on user density in cells, and is a much simpler upgrade. So even if we are using GPRS for a few years before 3G, there will be packet mode services available to GSM phones. (GSM does exist in the US, e.g. Voicestream, but it's very patchy because it's in competition with so many other standards.)
Ricochet is not the only game in town, and is proprietary as far as I can tell. For people who travel a lot, it's more useful to have wide coverage from pretty much every cellular provider, around the world - 3G promises to provide this, and in the interim there's GPRS, a 2.5G technology based on the world-wide GSM standard, and already deployed in early stages in various countries.
As for per-minute billing - there's no technical or business reason why 3G will work like this for data. Providers will be able to bill flat rate, or a fixed fee for certain amount of data transfer, or whatever. 3G data and GPRS are packet based standards, not circuit based like current cell phones.
You are right, of course - 3GPP2 is a CDMA-oriented 3G standards development project, mainly focused on the US and some other CDMA markets. So this version of CDMA is a standard, although not exactly a global one.
3GPP, a similar effort that predates 3GPP2, is defining a version of 3G called UMTS that is more GSM-oriented (though using CDMA, upgrades from GSM networks will be easier) - this is what will be used in Europe, most of Asia, and by AT&T in the US. Depending on how the standards wars pan out, you may still be able to use a UMTS phone anywhere, but it will take a long time for either 3G standard to get very broad coverage - so multimode phones (e.g. current CDMA and cdma2000/3GPP2, or GSM and UMTS) will be important for a long time.
As for HSCSD - this is an upgrade to GSM that simply bundles 2 or more GSM calls together for increased bandwidth (up to 28.8 Kbps I think). It's somewhat of a dead end, and not implemented by many telcos - the packet-oriented standards, such as GPRS, EDGE, UMTS, and 3GPP2's work, are much more interesting, as they turn the phone into an always-on device that can dump IP packets into the network whenever it wants.
IPv6 will also help, though not mandatory for any of these standards yet, by giving your phone a static IP address - run a web server on your phone (if you can afford the air time...)
CDMA is the radio interface, and in this case stands for Code Division Multiple Access - nothing to do with Ethernet's CDMA. The rest of the 3G radio access networks (i.e. the radio bits and everything that networks the base stations to the core) aren't based on Ethernet either - typically it's ATM, Frame Relay or IP.
The interesting part is that 3G infrastructure (at least the variant to be used almost everywhere but US/Canada) allows you to request a certain bandwidth, latency, jitter (latency variation), etc. Subject to your ability to pay, you then get the QoS you need, right the way through the radio access part and onto whatever IP network you want to get to.
There are many problems with 3G, including who's going to invest in the massive upgrades required (the entire network changes, radio and core), who's going to use it, what the killer application will be, and whether it will be too expensive for consumers (particularly in Europe, where the UK and other governments have managed to obtain ludicrously high license fees for 3G spectrum). But it's an interesting technology, and the bandwidth will only be oversold if that's the QoS level that people want. I suspect Sprint et al will sell a mixture of high QoS (for voice, video, and business users who need a VPN back to base) and medium/low QoS (for web surfing and general content/transactions).
3G has some other cool features - e.g. you can have connections to 2 or more base stations simultaneously, which makes your connection more resilient to obstacles and interference, as well as making it very easy to hand off from one cell to another. You should also be able to roam anywhere in the world with a 3G phone (particularly if US networks adopt UMTS, the global 3G standard, but multimode phones may help there even if not), and you can even switch to a different provider in the course of a single session.
Unfortunately there is not much digestible information on the Web, and the whole area is buried in acronyms...
"Windows offers a friendly environment that makes it easy to use software."
I've recently been getting my uncle, who is in his eighties, into using a Windows PC.
This is the first time he's used a computer, though he has used keyboards before, and it's made it clear to me that, for the average person, *using computers is still too hard*. It's easy to forget this when you've been using computers much of your life, and are surrounded by basically PC literate people at work.
Windows is certainly easier to use than DOS, but I've had to simplify the Windows setup so much that I could do this equally well under Linux. The only reason I didn't is that my uncle's friends provide local tech support, and they know Windows. Also, he can get local training in using computers.
One of the hardest things was the atrociously complex interface to dialup networking in Windows NT, and the way IE4's Offline/Online setting is shared with Outlook Express - I ended up buying a shareware dialer so that I could set up Netscape as the browser, not for ideological reasons but so that it wouldn't mess up the Outlook Express offline settings (which make it easy to compose email offline).
The lessons for Linux or any Windows alternative are:
- focus on real ease of use with non-PC literate users (Redmond Linux is getting quite close to this with task-based menus and so on - see http://www.redmondlinux.org/). Microsoft is pretty good at this, but maybe Eazel and Ximian type companies will run their own usability labs.
- incorporate natural language and voice input technologies - the keyboard and mouse are still barriers for some people
- settle on a single 'default' GUI, so that local training and support can be obtained without the 'I only know GNOME' syndrome
If my uncle lived round the corner, Linux would have worked well, but supporting someone 100 miles away solely through the phone and dialin is just too hard.
NAT breaks applications that are rash enough to embed IP addresses or port numbers (including FTP where you have to use the annoying passive FTP variant to get it to work) - this is common in slightly more advanced applications, and having to design around this is an unnecessary restriction (a bit like having to code within a 640K memory limit these days).
When IPv6 is deployed, a competitive market will grow up that delivers thousands of IPv6 addresses for a similar price to one IP address today. There is no extra cost to doing this, so any ISP that does not will be undercut by one who does. IPv4 address pricing is a direct result of the scarcity of address space. There are still hundreds to thousands of ISPs in most developed countries, so there is plenty of room for competition.
Your argument on IP mobility is similar to that for applications that don't code around NAT restrictions - there are always workarounds (e.g. reconnect all your TCP sessions) but they will cramp your style when moving between different Layer 2 technologies. If you don't want a wireless laptop, others will, and there are many other internet-connected devices such as PDAs and mobile phones that will also benefit.
The whole drive to P2P applications makes it much more desirable to have a static IP address. Again, not essential, but once you have enough IP addresses, application developers can concentrate on the important parts of their apps, rather than on beating NAT and the lack of static IP addresses.
There are some amazingly irony-impaired people around... My original post was actually criticising AOL by analogy to the more obviously broken *hypothetical* situation of non-interoperable phone standards. This situation never happened BTW - the worst that happened was that you needed a Ma Bell phone to plug into AT&T lines, but you could still call someone in the UK.
The second paragraph also stated how pointless AOL's restrictions were, but I guess you both replied before reading that.
Mainframes are surprisingly CPU-poor by Unix server and PC standards (or at least they were last time I looked) - but they generally make up for this with astonishingly good I/O capabilities.
Back when I was investigating Ingres on IBM mainframe Unix in the early 90s, I worked out that it could support perhaps 20 users, compared to hundreds with DB2 running on MVS (i.e. native mode not Unix). Ingres, like most Unix-based RDBMSs, assumed that CPU could be spent freely to save I/O (the best approach for mid-range Unix boxes), while DB2 assumed the opposite.
Anyway, the key point IMO is to choose a suitably I/O-focused application for Linux/390 - serving mostly static web pages would be fine, and CGI might be OK if you are using an efficient technique (e.g. Java with compilation to native code, or just very short CGI scripts in mod_perl), but generally any heavy computation should be avoided.
NAT breaks many applications (e.g. active FTP, NetMeeting, IPSec VPNs with IKE, many online games and so on). Where applications can get round NAT, they become more complex - e.g. Groove and other P2P apps must jump through hoops or rely on central servers. NAT does provide some security by default, but that's mainly by making it very hard for outside clients to talk to inside servers; a firewall can provide equivalent security quite easily.
If you ever want to be able to call in to a system at home (e.g. to tell your TiVo to record something), it will need a non-NATed configuration. IPv6 is the only way to do this without quickly running out of IP addresses - RSIP (Realm-Specific IP, a combination of tunnelling and IP address management) doesn't solve the 'call ing in' problem as far as I can see.
Before too long you'll want laptops to be able to roam between 3G networks when away from home, and then roam back to your Wi-Fi (802.11) wireless LAN at home. IPv6 enables much simpler IP mobility, i.e. your laptop keeps the same IP address (at least as far as TCP's concerned) no matter where you are. None of this is possible with NAT getting in the way - in fact, getting rid of NAT is one of the main reasons for IPv6.
For more information, see www.ipv6forum.com.
"I don't know what the current figures are. But on the date that Windows 95 was released, the most common type of non-server computer hardware in businesses was... the 80286!"
The 286 was obsolete by the end of the 1980s - the most common hardware in 1995 was probably either the 486 or Pentium. I had a 486 laptop in 95, and the desktops around me were Pentia.
Yes, AOL are in their rights here - just like your local phone company would be completely justified in requiring you to buy its phones only, and to prevent anyone with an 'unauthorised' phone from calling you.
Instant messaging is currently hobbled by islands of proprietary protocols, and AOL's efforts to stop the tide of interoperability are as pointless as Canute's.
LTSP is very impressive, on reading the docs a bit further - despite the name, it can actually support *both* local apps (running on the diskless workstation) and remote apps (server-based in Windows parlance, i.e. running on the server). The latter is the only option with Windows Terminal Server (or Citrix MetaFrame), so LTSP is much more flexible.
_ ig_v2.3-8.html for discussion of local vs. remote apps.
If you have fairly old PCs (386, 486, Pentium), just buy a modern server and run the apps there. Even old Windows boxes or Macs will be fine - they just need to run an X server. More work to set up, but worth trying if the old hardware is still reliable and can run Linux without hassles.
If you need to run more compute-intensive apps and have the budget, you can buy new diskless workstation PCs. This is probably easier to set up, too, but the key thing is you have a choice of models - and whichever model you use, the system admin load is very low, because only the server needs administering.
See http://www.ltsp.org/documentation/lts_ig_v2.3/lts