Actually, virtually anything can be done using just Perl - the whole point of creating it was to have a single tool that could do what people did with awk, shell, sed, and many C programs, without the impedance mismatch problem. Shell scripting is great for whipping up a very quick solution, but you usually reach a point at which Perl/Python would be better. I once wrote a simple 4GL compiler entirely in shell and sed, so I think I went well beyond that point - my only defence is that Perl wasn't available then...
See http://death2spam.net - this is a commercial mailbox service that appears to have really good bayesian-style spam filtering (referenced by Paul Graham in a recent article) - they even fetch URLs in some messages to filter based on website content. They don't require individuals to train on their own messages, which may be controversial but also makes it feasible to deploy this at large scale in ISPs.
Without major ISP deployments, the response rates to spam will not go down, since the clued-up individuals who deploy filtering themselves would never have responded to spam anyway.
Your RF analogy is interesting but it breaks down for people with wireless mobile phone links, dialup when travelling, and so on. The best thing is to make spam unprofitable so it goes away.
I use SpamAssassin (which includes Bayesian filtering, though I don't use it) and it works fine - no need to switch away since it's very flexible and lets me write my own rules for new types of spam, or just tinker with the scores.
For those in the UK, try Andrews and Arnold - not a free service, but you get IPv6 as a tick box option when you get normal IPv4 service. Provided through a tunnel endpoint within A&A's network, so the latency should be pretty good. They are very Linux friendly, and tracking ADSL installation through their web pages was very easy. See http://aa.nu/ for more information.
This is a re-post of a posting in an earlier story - see my home page link for rebuttals including mine, it's the one about DoD IPv6. Almost everything in this post is wrong but I'm not going to re-post...
This is a real FAQ, but IPv4 is easily capable of doing QoS (many of my telco customers do it today) and IPSec as well. That article has some huge mistakes in it and is clearly written by someone who doesn't know IPv6 well - IPSec is NOT mandatory in IPv6, and I shudder to think of the scalability issues if it was, given that most routers struggle with a large number of host to host SAs or tunnels. The author also seems to think that IPv6 gives you flow-level QoS - while it does have a flow ID, that's really not important for most people since flow-based RSVP is not going anywhere even in IPv6 land.
The main reason to go for IPv6 is address space, and this will happen first in AsiaPac as well as for mobile phones and the DoD (from Oct 2003 IPv6 is mandatory for procurements).
Re:Enough with the flames already
on
State of the Onion 7
·
· Score: 2, Informative
Popularity for open source tools has something to do with usefulness, quality, availability (on various platforms) and so on. Unlike both Windows and VB, Perl has never had a significant marketing campaign - it got lucky in the Unix/shell environment, then in hitting the CGI niche in the mid-90s, and then again in hitting the bioinformatics niche in the late 90s (getting lucky this many times begins to look like something other than luck, though).
I use Perl a lot, and despite the near-vertical learning curve at times (when you try to go from trivial to medium size programs, the error messages can be fairly horrible), it is just incredibly useful. The existence of pre-tested modules on CPAN for major chunks of functionality helps enormously - modules I've used recently include Mail::IMAPClient (enabling a specialised biff in just 20 or so lines), Parse::RecDescent (enabling parsing of router configs with very little code, i.e. it's a well tested Yacc for Perl), and various email manipulation modules.
Perl probably isn't the world's easiest language to learn, but neither is English - both have a large number of peculiarities, but once you know them well they are very pleasant to use. Although I am looking at OCaml now (because it is high level but performs as well as C/C++ for most things), it is not as easy to code in as Perl, so I doubt I'll stop using Perl.
I also know Python, and it's very nice, but it doesn't have CPAN. In fact, Parrot could be the killer platform for Python if the Python community get behind it, just by allowing Python to call the enormous CPAN module library (2,000 plus modules). Perl 6 may be more significant for bringing us Parrot than for the sometimes scary language features.
Point 1 re 'Cisco sucks at IPv6' - do you have any data to back this up? Cisco seem to be doing fine with IPv6 deployments so I don't believe this is a real issue. More recent Cisco routers (7600, 10000, 12000 series) are hardware-based and will do IPv6 in hardware. Those that are software-based will forward IPv6 exactly like the other non-IPv4 protocols they have supported for years (DECnet, SNA, etc) - Cisco started out with multiprotocol routing not just IP. I'd be surprised if there is a big difference in performance - certainly there'll be more memory references with IPv6 addresses, but the IPv6 header (less the addresses) is shorter and simpler than the IPv4 header, so software-based routers may actually go faster on IPv6. Hardware-based routers should go at wire speed, basically.
Point 2 - there are already 1 billion cell phones in the world, and perhaps 30% of those are already IP-enabled. If you add in VoIP phones at home, and the myriad of new devices such as TiVOs, you can easily see how a mere 4 billion addresses is not enough - remember that India and China alone have 2 billion people. NAT is a hack that prevents simple deployment of more complex applications that aren't merely client to server - P2P apps work much more easily without NAT.
Point 3 - routing tables too large. Routing tables won't grow in size as you imply - if anything they are smaller for the true core routers, since IPv6 was designed to scale better using CIDR-like techniques for route aggregation, i.e. only a short prefix is stored and fewer prefixes should be needed. Your proposal for using the Ethernet-style MAC address doesn't work for ADSL, leased lines, and many other non-Ethernet media.
Point 4 - this is true for MTU-sized packets, but of course the host can send larger packets (frequently 1500 bytes or so), reducing this overhead. A 1 to 3 % overhead doesn't sound like much given IPv6's other advantages.
The fact that IPv6 allows stupid hacks like this is irrelevant. IPv6 is going to happen, it's just a question of time - my ADSL ISP already offers IPv6 as a checkbox option at no extra cost.
You can in fact do this with plain old Perl 5 regexes, as follows - to quote from Jeffrey Friedl's excellent Mastering Regular Expressions, 2nd Edition, p. 328-331:
This dynamic regex matches text within an arbitrarily-nested set of nested parentheses, by recursively 'calling' the compiled regex $LevelN from within itself - the left hand condition of the alternation is the exit condition. It works in Perl 5.6 or higher, maybe even earlier - just tested it.
Of course, Perl 6 makes this sort of thing much easier and has a built-in Parse::RecDescent feature within regexes, but the overall complexity of the language is quite scary. I'm looking at OCaml, which is higher level than Perl (though with some features in modules and less syntactic sugar) and almost as fast as C/C++. It's also functional and OO, more details on my OCaml page
"Internally, every carrier in Europe with 2.5G/3G services is running IPv6 for everything (except for a few dinosaurs about to be extinct)"
This might be true for a few carriers you know, but it is absolutely not true for the wireless networks I've been working with (and they aren't dinosaurs, they include the market leaders) - they are all IPv4 and are running routers with IOS/JUNOS versions that don't even support IPv6. Since Cisco IOS 12.3 is the first non-T train IOS to support IPv6 and it came out in May 2003, this is not that surprising.
The new GSM smartphones (e.g. SonyEricsson P800) do have built-in IPv6, and GPRS/UMTS support IPv6, but this is something that will be turned on in the next few years. UMTS (3G) Release 3 is the version that most operators are deploying, and not until UMTS R5's IP Multimedia Subsystem is IPv6 mandated, so this isn't too surprising.
It's nothing to do with security - IPSec works just as well (or not) on IPv4 as on IPv6. In any case, the military has its own specific ways of securing networks, including specialised encryption and keeping classified networks entirely separate to other networks.
Also, QoS (both DiffServ and the less common RSVP) works fine on IPv4 and IPv6.
IPv6 makes sense to the military for the same reasons as everyone else, I'd guess. Addressability and avoidance of NATs is the most obvious benefit.
Cisco has finally released IOS 12.3 which has full support for IPv6 in a production IOS train (see http://www.cisco.com/warp/public/732/Tech/ipv6/ ) - IPv6 has been in the 'T' train IOSes for some time. Their support now makes full use of hardware acceleration and looks very complete.
Juniper have had IPv6 in production JUNOS releases on the M-series/T-series for quite a while.
Most other vendors already have production IPv6, so in reality the router vendors aren't a roadblock. The same is now true for host OSs - Linux, Windows XP and modern Unixes have had IPv6 for a while as well. The real issue is getting applications ported (not that hard) and networks deployed.
Yes, free local calls (which are really not free in US or UK, just pre-paid monthly for unlimited minutes) are quite recent - they do cover voice as well as dialup Internet, but are mostly for the latter. One recent deal is US$20 per month for free local and UK national calls, unlimited time - this is over a fairly large area (about 800 miles from south to north).
Elitism was also an issue here - back in the late Eighties and up to mid Nineties, only yuppies had mobile phones, or so it seemed, and there were obnoxious people using them in restaurants. The latter are still with us but to a lesser extent, but now 80% of population has a mobile even if some don't use theirs very much.
SMS and email are both useful, for different reasons - the more email becomes like SMS (i.e. always on and delivered to handset) the better it will be. There are various input systems for SMS, google for Tegic T9 for a very popular one, particular amongst non-teenagers who don't want to lrn txt spk. However, one reason SMS has succeeded is that it IS hard to get into, but is also viral since a non-user may get a text message from someone else and want to reply - the investment in time to learn how to use SMS input creates a sort of 'spent so much time learning I might as well use it' effect, a bit like the way Palm users like Graffiti despite it not being much like normal writing. A key plus point of SMS is that you can use it single handed when walking - you can also get qwerty keyboards, some of them built into the phone, but they aren't very popular at the moment.
I agree about PDA/phones aka smartphones - without a large touch screen like the P800, I think most data usage will be limited to SMS, with a tiny bit of MMS and the occasional web/WAP usage.
And I also agree that going GSM instead of 3G would be a mistake for the US - however, I think that GSM, GPRS and EDGE (like GPRS only faster) will be a very common solution. Most GSM base stations in the US have been installed in last couple of years and should already be EDGE-capable - since EDGE is just 3G (similar bandwidth to CDMA2000) that may be the route that they go. AT&T have to install UMTS in a number of cities due to an investment agreement with NTT DoCoMo but everyone else may end up on EDGE.
There aren't any US CDMA providers going to GSM - the only ones going GSM are AT&T Wireless and Cingular, who were both TDMA-based. VoiceStream aka T-Mobile was GSM from the start. There are lots of misconceptions about your argument on Europe's allegedly poorer land lines (why do I always get 20-25Kbps in US on dialup, vs 40+ Kbps in UK, if they are really inferior?) but I can't be bothered to rebut them all. See my other recent postings for details if you're interested.
UMTS in the US is hard pressed because of lack of spectrum, so GSM and EDGE are very sensible decisions for operators who want to be able to capture international roaming fees (from tourists in US and from US customers abroad), which are significant revenue streams.
SMS is something you have to use before you realise it's useful - not for everyone, but if someone is in a noisy environment or on a train or in a meeting, it's much more friendly to just send them a short text message. Also avoids mis-transcription of messages, and beeps someone as soon as they get a message (unlike email where almost everyone has to check for new messages, and of course find a PC to do so).
Email on phones is a killer app too - my SonyEricsson P800 makes it easy to check for email (IMAP or POP3), and it also runs Opera (with SSL, JavaScript, frames, etc, and good small screen rendering). Not to mention Doom:)
According to http://www.gsmworld.com/roaming/gsminfo/index.shtm l there are 4 GSM telcos in Colombia and 2 in South Korea, so perhaps it is probably just a matter of coverage where you were - other parts of those countries might have had poor CDMA coverage. There's no GSM in Japan, which is one of the few countries without GSM.
There are lots of great wireless developments coming out of Europe, in both handsets and infrastructure - GSM is somewhat like the Intel architecture PC, it constrains you in some areas but enables huge innovation in others because it's a volume market with high levels of competition. The laissez-faire approach in the US has enabled CDMA to flourish but has also led to smaller isolated handset and infrastructure markets.
Building a US-wide network is even more expensive than it should be, because there are 4 equipment markets for the cell towers and supporting kit - CDMA, GSM, TDMA and Analogue. Scandinavian telcos can benefit from economies of scale in the world-wide GSM market, which is about 80% of all subscribers. And not everything is government subsidised in Scandinavia, though certainly that's more true than the US - one reason they had just about the world's first cellular networks is that they have very inhospitable terrain and climate that makes it difficult to run land lines in some parts of the country.
> (1) conflicting standards
Good to see you proving the US-centric point there - rest of world != Bulgaria, and in fact good GSM coverage makes it easier to use a cell phone almost any country in the world, as well as parts of the US where your telco doesn't have coverage but another GSM telco does. Are you really saying that 95% of Americans don't travel more than 20 miles from their homes? Many of them drive much further than that just to visit friends, and people seem much more willing to hop on a plane than in Europe.
> (2) separate area code
Strangely enough, Europeans have good land lines as well - perhaps not as cheap as the US but not far off. There are bundled and unlimited minutes plans, at least in the UK, but those are mainly for Internet users who aren't on broadband yet.
I really don't get the argument that good land lines mean cell phones aren't needed - they are fundamentally different products, and once people get used to the convenience of a cell phone they are usually reluctant to go back. People tend to travel and commute more than they used to a few decades before, and expect to be able to contact whoever they want to - land lines just don't fulfil this need.
Cell phones are increasing their penetration of the US population - this is partly due to implementation of cross-network SMS (text messaging), which took off a few years ago in Europe and Asia. For example, US reality TV shows using SMS for voting are seeing huge month by month increases in usage.
There's no conceptual problem with providing IP-addressable Bluetooth nodes. The main issues are implementation related, as you point out - however, these will also apply to WiFi if it's used between highly mobile routing nodes (not just end points talking to static access points).
Google for mobile ad hoc routing and the IETF's manet group for some work going on in this area - the problem is how do you route between nodes that can disappear (go out of range) at any time, and there are other interesting problems as well.
Many Bluetooth devices, e.g. phones, have IP stacks anyway. However, I'd like to see zeroconf with high security before we go to IP addresses on every BT device - otherwise it could be interesting trying to stop hack attacks, e.g. one on your BT headset that blasts thrash metal at your ear (substitute whatever sort of music you hate)...
This argument comes up again and again - check the population densities of Scandinavia, which has amazingly good mobile coverage even north of the Arctic circle. They aren't very different from the US.
Almost nobody in Europe switches from land line to mobile for cost reasons - most countries have had competition in land lines for at least five years, and land lines are still much cheaper per minute than mobiles, and with lower monthly charges. However, many people prefer to just get calls on their mobile so they don't miss them. Comparing the US to Thailand is hardly fair, as the latter is still a developing economy - more sensible to compare to European countries.
The main reason mobiles haven't taken off so much in the US is regulation: (1) there are three conflicting digital standards vs the single global standard elsewhere (GSM), due to laissez-faire regulation by the FCC, and (2) no separate area code was allocated for mobiles (unlike Europe) meaning that callers can't tell they are calling a mobile, which means that they can't be charged extra for the call. The result of (2) is that mobile phone users must pay for all incoming calls, and don't give out their mobile number (or just turn off the mobile phone).
Nokia don't get Bluetooth, nor do Samsung, Sharp Panasonic, etc (based on the various phones in the UK market). However, SonyEricsson do support Bluetooth well, and increasingly other manufacturers do as well - Motorola, Siemens, etc. Also Sony has several Clie's with built-in Bluetooth, and the same's true of HP iPAQs.
One annoying issue with Palm Bluetooth when using it with mobile phones to get onto GPRS - when the Palm device goes to sleep, it disconnects the PPP link to the mobile phone, causing the GPRS connection to drop. This converts the nice always-on GPRS link into a 'must always reconnect' link, causing 10-30 sec delay. Nice one, Palm - does anyone know if PalmOS 5 fixes this?
The idea is to print from a PDA, tablet PC, laptop or whatever without having to buy *yet another* cable, or to tie into an overloaded PC that runs out of USB slots.
GSM has something like 80% market share world-wide, and is heavily used in the Middle East as well as Africa, Europe, Asia and has some market share in North and South America. So the real reason it's desirable is that it's the standard, just like VHS, not that it has the best possible technology. CDMA2000 should be compared with W-CDMA, where it looks like the former is much more mature and currently deployable.
I'm afraid your memory is not right - the PDP-11 had post-increment and post-decrement only, see http://www.wikipedia.org/wiki/PDP-11 to confirm this. C's post-increment/decrement operators, used for something like *p++ = *q++, were designed to be easily mapped onto the PDP-11 (i.e. one instruction in this case).
For everyone else: PDP-11's are still used for industrial control, were a key Unix platform, and gave rise to the instruction sets of the VAX, 6809 (ish) and 68000.
Slashdot Mirror
Actually, virtually anything can be done using just Perl - the whole point of creating it was to have a single tool that could do what people did with awk, shell, sed, and many C programs, without the impedance mismatch problem. Shell scripting is great for whipping up a very quick solution, but you usually reach a point at which Perl/Python would be better. I once wrote a simple 4GL compiler entirely in shell and sed, so I think I went well beyond that point - my only defence is that Perl wasn't available then ...
See http://death2spam.net - this is a commercial mailbox service that appears to have really good bayesian-style spam filtering (referenced by Paul Graham in a recent article) - they even fetch URLs in some messages to filter based on website content. They don't require individuals to train on their own messages, which may be controversial but also makes it feasible to deploy this at large scale in ISPs.
Without major ISP deployments, the response rates to spam will not go down, since the clued-up individuals who deploy filtering themselves would never have responded to spam anyway.
Your RF analogy is interesting but it breaks down for people with wireless mobile phone links, dialup when travelling, and so on. The best thing is to make spam unprofitable so it goes away.
I use SpamAssassin (which includes Bayesian filtering, though I don't use it) and it works fine - no need to switch away since it's very flexible and lets me write my own rules for new types of spam, or just tinker with the scores.
http://spamassassin.org/
For those in the UK, try Andrews and Arnold - not a free service, but you get IPv6 as a tick box option when you get normal IPv4 service. Provided through a tunnel endpoint within A&A's network, so the latency should be pretty good. They are very Linux friendly, and tracking ADSL installation through their web pages was very easy. See http://aa.nu/ for more information.
This is a re-post of a posting in an earlier story - see my home page link for rebuttals including mine, it's the one about DoD IPv6. Almost everything in this post is wrong but I'm not going to re-post...
This is a real FAQ, but IPv4 is easily capable of doing QoS (many of my telco customers do it today) and IPSec as well. That article has some huge mistakes in it and is clearly written by someone who doesn't know IPv6 well - IPSec is NOT mandatory in IPv6, and I shudder to think of the scalability issues if it was, given that most routers struggle with a large number of host to host SAs or tunnels. The author also seems to think that IPv6 gives you flow-level QoS - while it does have a flow ID, that's really not important for most people since flow-based RSVP is not going anywhere even in IPv6 land.
The main reason to go for IPv6 is address space, and this will happen first in AsiaPac as well as for mobile phones and the DoD (from Oct 2003 IPv6 is mandatory for procurements).
Popularity for open source tools has something to do with usefulness, quality, availability (on various platforms) and so on. Unlike both Windows and VB, Perl has never had a significant marketing campaign - it got lucky in the Unix/shell environment, then in hitting the CGI niche in the mid-90s, and then again in hitting the bioinformatics niche in the late 90s (getting lucky this many times begins to look like something other than luck, though).
I use Perl a lot, and despite the near-vertical learning curve at times (when you try to go from trivial to medium size programs, the error messages can be fairly horrible), it is just incredibly useful. The existence of pre-tested modules on CPAN for major chunks of functionality helps enormously - modules I've used recently include Mail::IMAPClient (enabling a specialised biff in just 20 or so lines), Parse::RecDescent (enabling parsing of router configs with very little code, i.e. it's a well tested Yacc for Perl), and various email manipulation modules.
Perl probably isn't the world's easiest language to learn, but neither is English - both have a large number of peculiarities, but once you know them well they are very pleasant to use. Although I am looking at OCaml now (because it is high level but performs as well as C/C++ for most things), it is not as easy to code in as Perl, so I doubt I'll stop using Perl.
I also know Python, and it's very nice, but it doesn't have CPAN. In fact, Parrot could be the killer platform for Python if the Python community get behind it, just by allowing Python to call the enormous CPAN module library (2,000 plus modules). Perl 6 may be more significant for bringing us Parrot than for the sometimes scary language features.
So many half-truths, so little time...
Point 1 re 'Cisco sucks at IPv6' - do you have any data to back this up? Cisco seem to be doing fine with IPv6 deployments so I don't believe this is a real issue. More recent Cisco routers (7600, 10000, 12000 series) are hardware-based and will do IPv6 in hardware. Those that are software-based will forward IPv6 exactly like the other non-IPv4 protocols they have supported for years (DECnet, SNA, etc) - Cisco started out with multiprotocol routing not just IP. I'd be surprised if there is a big difference in performance - certainly there'll be more memory references with IPv6 addresses, but the IPv6 header (less the addresses) is shorter and simpler than the IPv4 header, so software-based routers may actually go faster on IPv6. Hardware-based routers should go at wire speed, basically.
Point 2 - there are already 1 billion cell phones in the world, and perhaps 30% of those are already IP-enabled. If you add in VoIP phones at home, and the myriad of new devices such as TiVOs, you can easily see how a mere 4 billion addresses is not enough - remember that India and China alone have 2 billion people. NAT is a hack that prevents simple deployment of more complex applications that aren't merely client to server - P2P apps work much more easily without NAT.
Point 3 - routing tables too large. Routing tables won't grow in size as you imply - if anything they are smaller for the true core routers, since IPv6 was designed to scale better using CIDR-like techniques for route aggregation, i.e. only a short prefix is stored and fewer prefixes should be needed. Your proposal for using the Ethernet-style MAC address doesn't work for ADSL, leased lines, and many other non-Ethernet media.
Point 4 - this is true for MTU-sized packets, but of course the host can send larger packets (frequently 1500 bytes or so), reducing this overhead. A 1 to 3 % overhead doesn't sound like much given IPv6's other advantages.
The fact that IPv6 allows stupid hacks like this is irrelevant. IPv6 is going to happen, it's just a question of time - my ADSL ISP already offers IPv6 as a checkbox option at no extra cost.
You can in fact do this with plain old Perl 5 regexes, as follows - to quote from Jeffrey Friedl's excellent Mastering Regular Expressions, 2nd Edition, p. 328-331:
This dynamic regex matches text within an arbitrarily-nested set of nested parentheses, by recursively 'calling' the compiled regex $LevelN from within itself - the left hand condition of the alternation is the exit condition. It works in Perl 5.6 or higher, maybe even earlier - just tested it.
Of course, Perl 6 makes this sort of thing much easier and has a built-in Parse::RecDescent feature within regexes, but the overall complexity of the language is quite scary. I'm looking at OCaml, which is higher level than Perl (though with some features in modules and less syntactic sugar) and almost as fast as C/C++. It's also functional and OO, more details on my OCaml page
Good to see someone exactly copying my comment from an earlier story... By the way this isn't 'Cisco's take', please keep up at the back.
"Internally, every carrier in Europe with 2.5G/3G services is running IPv6 for everything (except for a few dinosaurs about to be extinct)"
This might be true for a few carriers you know, but it is absolutely not true for the wireless networks I've been working with (and they aren't dinosaurs, they include the market leaders) - they are all IPv4 and are running routers with IOS/JUNOS versions that don't even support IPv6. Since Cisco IOS 12.3 is the first non-T train IOS to support IPv6 and it came out in May 2003, this is not that surprising.
The new GSM smartphones (e.g. SonyEricsson P800) do have built-in IPv6, and GPRS/UMTS support IPv6, but this is something that will be turned on in the next few years. UMTS (3G) Release 3 is the version that most operators are deploying, and not until UMTS R5's IP Multimedia Subsystem is IPv6 mandated, so this isn't too surprising.
It's nothing to do with security - IPSec works just as well (or not) on IPv4 as on IPv6. In any case, the military has its own specific ways of securing networks, including specialised encryption and keeping classified networks entirely separate to other networks.
Also, QoS (both DiffServ and the less common RSVP) works fine on IPv4 and IPv6.
IPv6 makes sense to the military for the same reasons as everyone else, I'd guess. Addressability and avoidance of NATs is the most obvious benefit.
Cisco has finally released IOS 12.3 which has full support for IPv6 in a production IOS train (see http://www.cisco.com/warp/public/732/Tech/ipv6/ ) - IPv6 has been in the 'T' train IOSes for some time. Their support now makes full use of hardware acceleration and looks very complete.
Juniper have had IPv6 in production JUNOS releases on the M-series/T-series for quite a while.
Most other vendors already have production IPv6, so in reality the router vendors aren't a roadblock. The same is now true for host OSs - Linux, Windows XP and modern Unixes have had IPv6 for a while as well. The real issue is getting applications ported (not that hard) and networks deployed.
Yes, free local calls (which are really not free in US or UK, just pre-paid monthly for unlimited minutes) are quite recent - they do cover voice as well as dialup Internet, but are mostly for the latter. One recent deal is US$20 per month for free local and UK national calls, unlimited time - this is over a fairly large area (about 800 miles from south to north).
Elitism was also an issue here - back in the late Eighties and up to mid Nineties, only yuppies had mobile phones, or so it seemed, and there were obnoxious people using them in restaurants. The latter are still with us but to a lesser extent, but now 80% of population has a mobile even if some don't use theirs very much.
SMS and email are both useful, for different reasons - the more email becomes like SMS (i.e. always on and delivered to handset) the better it will be. There are various input systems for SMS, google for Tegic T9 for a very popular one, particular amongst non-teenagers who don't want to lrn txt spk. However, one reason SMS has succeeded is that it IS hard to get into, but is also viral since a non-user may get a text message from someone else and want to reply - the investment in time to learn how to use SMS input creates a sort of 'spent so much time learning I might as well use it' effect, a bit like the way Palm users like Graffiti despite it not being much like normal writing. A key plus point of SMS is that you can use it single handed when walking - you can also get qwerty keyboards, some of them built into the phone, but they aren't very popular at the moment.
I agree about PDA/phones aka smartphones - without a large touch screen like the P800, I think most data usage will be limited to SMS, with a tiny bit of MMS and the occasional web/WAP usage.
And I also agree that going GSM instead of 3G would be a mistake for the US - however, I think that GSM, GPRS and EDGE (like GPRS only faster) will be a very common solution. Most GSM base stations in the US have been installed in last couple of years and should already be EDGE-capable - since EDGE is just 3G (similar bandwidth to CDMA2000) that may be the route that they go. AT&T have to install UMTS in a number of cities due to an investment agreement with NTT DoCoMo but everyone else may end up on EDGE.
There aren't any US CDMA providers going to GSM - the only ones going GSM are AT&T Wireless and Cingular, who were both TDMA-based. VoiceStream aka T-Mobile was GSM from the start. There are lots of misconceptions about your argument on Europe's allegedly poorer land lines (why do I always get 20-25Kbps in US on dialup, vs 40+ Kbps in UK, if they are really inferior?) but I can't be bothered to rebut them all. See my other recent postings for details if you're interested.
:)
UMTS in the US is hard pressed because of lack of spectrum, so GSM and EDGE are very sensible decisions for operators who want to be able to capture international roaming fees (from tourists in US and from US customers abroad), which are significant revenue streams.
SMS is something you have to use before you realise it's useful - not for everyone, but if someone is in a noisy environment or on a train or in a meeting, it's much more friendly to just send them a short text message. Also avoids mis-transcription of messages, and beeps someone as soon as they get a message (unlike email where almost everyone has to check for new messages, and of course find a PC to do so).
Email on phones is a killer app too - my SonyEricsson P800 makes it easy to check for email (IMAP or POP3), and it also runs Opera (with SSL, JavaScript, frames, etc, and good small screen rendering). Not to mention Doom
According to http://www.gsmworld.com/roaming/gsminfo/index.shtm l there are 4 GSM telcos in Colombia and 2 in South Korea, so perhaps it is probably just a matter of coverage where you were - other parts of those countries might have had poor CDMA coverage. There's no GSM in Japan, which is one of the few countries without GSM.
There are lots of great wireless developments coming out of Europe, in both handsets and infrastructure - GSM is somewhat like the Intel architecture PC, it constrains you in some areas but enables huge innovation in others because it's a volume market with high levels of competition. The laissez-faire approach in the US has enabled CDMA to flourish but has also led to smaller isolated handset and infrastructure markets.
Building a US-wide network is even more expensive than it should be, because there are 4 equipment markets for the cell towers and supporting kit - CDMA, GSM, TDMA and Analogue. Scandinavian telcos can benefit from economies of scale in the world-wide GSM market, which is about 80% of all subscribers. And not everything is government subsidised in Scandinavia, though certainly that's more true than the US - one reason they had just about the world's first cellular networks is that they have very inhospitable terrain and climate that makes it difficult to run land lines in some parts of the country.
> (1) conflicting standards
Good to see you proving the US-centric point there - rest of world != Bulgaria, and in fact good GSM coverage makes it easier to use a cell phone almost any country in the world, as well as parts of the US where your telco doesn't have coverage but another GSM telco does. Are you really saying that 95% of Americans don't travel more than 20 miles from their homes? Many of them drive much further than that just to visit friends, and people seem much more willing to hop on a plane than in Europe.
> (2) separate area code
Strangely enough, Europeans have good land lines as well - perhaps not as cheap as the US but not far off. There are bundled and unlimited minutes plans, at least in the UK, but those are mainly for Internet users who aren't on broadband yet.
I really don't get the argument that good land lines mean cell phones aren't needed - they are fundamentally different products, and once people get used to the convenience of a cell phone they are usually reluctant to go back. People tend to travel and commute more than they used to a few decades before, and expect to be able to contact whoever they want to - land lines just don't fulfil this need.
Cell phones are increasing their penetration of the US population - this is partly due to implementation of cross-network SMS (text messaging), which took off a few years ago in Europe and Asia. For example, US reality TV shows using SMS for voting are seeing huge month by month increases in usage.
There's no conceptual problem with providing IP-addressable Bluetooth nodes. The main issues are implementation related, as you point out - however, these will also apply to WiFi if it's used between highly mobile routing nodes (not just end points talking to static access points).
Google for mobile ad hoc routing and the IETF's manet group for some work going on in this area - the problem is how do you route between nodes that can disappear (go out of range) at any time, and there are other interesting problems as well.
Many Bluetooth devices, e.g. phones, have IP stacks anyway. However, I'd like to see zeroconf with high security before we go to IP addresses on every BT device - otherwise it could be interesting trying to stop hack attacks, e.g. one on your BT headset that blasts thrash metal at your ear (substitute whatever sort of music you hate)...
This argument comes up again and again - check the population densities of Scandinavia, which has amazingly good mobile coverage even north of the Arctic circle. They aren't very different from the US.
Almost nobody in Europe switches from land line to mobile for cost reasons - most countries have had competition in land lines for at least five years, and land lines are still much cheaper per minute than mobiles, and with lower monthly charges. However, many people prefer to just get calls on their mobile so they don't miss them. Comparing the US to Thailand is hardly fair, as the latter is still a developing economy - more sensible to compare to European countries.
The main reason mobiles haven't taken off so much in the US is regulation: (1) there are three conflicting digital standards vs the single global standard elsewhere (GSM), due to laissez-faire regulation by the FCC, and (2) no separate area code was allocated for mobiles (unlike Europe) meaning that callers can't tell they are calling a mobile, which means that they can't be charged extra for the call. The result of (2) is that mobile phone users must pay for all incoming calls, and don't give out their mobile number (or just turn off the mobile phone).
Nokia don't get Bluetooth, nor do Samsung, Sharp Panasonic, etc (based on the various phones in the UK market). However, SonyEricsson do support Bluetooth well, and increasingly other manufacturers do as well - Motorola, Siemens, etc. Also Sony has several Clie's with built-in Bluetooth, and the same's true of HP iPAQs.
One annoying issue with Palm Bluetooth when using it with mobile phones to get onto GPRS - when the Palm device goes to sleep, it disconnects the PPP link to the mobile phone, causing the GPRS connection to drop. This converts the nice always-on GPRS link into a 'must always reconnect' link, causing 10-30 sec delay. Nice one, Palm - does anyone know if PalmOS 5 fixes this?
The idea is to print from a PDA, tablet PC, laptop or whatever without having to buy *yet another* cable, or to tie into an overloaded PC that runs out of USB slots.
GSM has something like 80% market share world-wide, and is heavily used in the Middle East as well as Africa, Europe, Asia and has some market share in North and South America. So the real reason it's desirable is that it's the standard, just like VHS, not that it has the best possible technology. CDMA2000 should be compared with W-CDMA, where it looks like the former is much more mature and currently deployable.
EDGE isn't CDMA based, it's still TDMA but with better radio technology allowing more capacity in existing GSM/GPRS cells, and higher speeds.
W-CDMA is the 'true 3G' step after GPRS/EDGE, which is CDMA based.
I'm afraid your memory is not right - the PDP-11 had post-increment and post-decrement only, see http://www.wikipedia.org/wiki/PDP-11 to confirm this. C's post-increment/decrement operators, used for something like *p++ = *q++, were designed to be easily mapped onto the PDP-11 (i.e. one instruction in this case).
For everyone else: PDP-11's are still used for industrial control, were a key Unix platform, and gave rise to the instruction sets of the VAX, 6809 (ish) and 68000.
I was so stunned that Knoppix autodetected my sound card and played a startup sound that I had to reboot it with the sound turned up...