You make some good points about Qt's adoption - definitely helps to get a major open source project to adopt a GUI toolkit. However, Qt is not viable for non-open-source developers or sysadmins who want to write cross-platform GUI-based scripts in Perl/Python. Its per-seat development cost is aimed at commercial C++ applications, so wxPerl/WxPython are ideal.
GNOME/Gtk are nice but getting them working on a Windows box is painful - wxWindows provides a simpler approach. To use wxPerl, you just install the Wx module from CPAN, read the tutorials, and off you go - no license fees.
Also, there's a GUI design tool for Wx, called wxDesigner - it's commercial but the cost is very reasonable, under $300 for 10 licenses, and it supports C++, Perl and Python.
By the way, am I the only person who sees Perl and Python as more similar than different? Of course, each one has advantages, but perhaps it is the similarity that drives the language wars...
Would be nice if wxPython was ported to PalmOS, and if Pippy was a bit more complete...
wxPerl is good, and similar to wxPython as it should be. There are some good tutorials for wxPerl but the docs aren't as good as for wxPython - fortunately you can read the wxPython or C++ docs and just transliterate them into Perl.
My T68 is being repaired for the second time in a month - it goes into a state where it refuses to make or receive calls, mainly on GSM-1800 networks. Along with the frequent crashes and spontaneous switching-off in my pocket (even though keypad lock is on), this is making me less than impressed with SonyEricsson...
If the Nokia 7650 wasn't so chunky I'd buy one like a shot, and I may still do just to get phone software that is faster and more stable.
That's a bit like saying, back in 1995, that 'Linux is doomed - Windows has more users, more desktops, high economies of scale,...' Of course, back then Linux was not really ready for prime time the way it is now, with nicer GUIs, installers, more apps, etc.
W-CDMA is not really finished yet, as other posts have pointed out - NTT DoCoMo launched too early with a sort-of W-CDMA, but its phones didn't have any roaming onto the local 2G networks, so you had to buy a large expensive phone to get tiny coverage in a couple of big cities. Not surprisingly, it failed.
The real test will come when W-CDMA phones have integrated roaming onto 2G networks (mainly GSM) - only then is there any chance of serious uptake. These phones will have a much bigger potential market than CDMA2000, so as long as the phones and networks work well, and have good services at reasonable prices, it's possible that W-CDMA will gradually come to dominate. But only time will tell...
Re:hrm, somethings amiss, me thinks
on
Itanium Problems
·
· Score: 2
That's assuming IA-64 lasts that long - Digital/Compaq's Alpha was announced in 1992 with a planned life of 25 years and is (more or less) dead now. See http://www.funet.fi/pub/unix/DEC/Alpha/press_relea se.txt for the original announcement.
Of course, Alpha failed to take over more for commercial reasons, but if successive waves of competition beat IA-64 commercially or technically, the effect may be the same.
If your office VPN setup *has* to use IPSec AH, you are probably out of luck. AH means Authentication Header, which means it cryptographically authenticates every IP packet, including the IP address. NAT changes this address, and AH on the server rejects the packet as it should do.
The only way round this is to use ESP, and most likely ESP over UDP. CheckPoint VPN-1 supports this in recent versions, as do most other vendors I think. See my other post in this thread for links.
You are correct that IPSec has protocol issues with NAT, but they are being addressed. Until the solution is standardised, the IPSec implementation matters a lot - some implement ESP over UDP, i.e. pre-standard versions of http://www.ietf.org/internet-drafts/draft-ietf-ips ec-udp-encaps-03.txt and http://www.ietf.org/internet-drafts/draft-ietf-ips ec-nat-t-ike-03.txt
There's an overview of IPSec over NAT at http://www.networkcomputing.com/1123/1123ws2.html - I'm not fully up to date with all this, but it does work and I use it every day to get past my Linux NAT/firewall at home from a CheckPoint SecureClient IPSec implementation on Windows.
I agree about the performance - it's painful to have to wait a second or two for a screen to appear, and in some cases minutes (after changing a season pass). I can't work out why it is this slow - I suspect poor algorithms and data structures. After all, it is presumably dealing with an in-memory database that (with proper indexing and data structures) should be blindingly fast for retrievals and updates.
Tivo's performance is the one really annoying part of the product, and enough to stop me recommending it to other people.
PostgreSQL is an open source project, not a product. The developers can port it to Windows in any way they want - it does run on Cygwin, which I use a lot for other tools. Why is it such a problem to use Cygwin? It's just a DLL, you wouldn't need the whole Cygwin environment on a production server, only on development machines.
You have no right to be angry at an open source project that is done by volunteers, usually in their spare time - if you really want a native Windows port, you can either help port it yourself or pay someone to do it.
This is a somewhat 1980s perspective - back when there were multiple layer 3 and 4 network technologies and IP was just one of them, it was common to invent transport-independent APIs. However, this still leaves the issue of transport level gateways to allow the end hosts to communicate. It's much easier to just use IP everywhere so that IF you want your mobile phone to talk to a Sun server there is no technical barrier to doing so.
The drive for end to end no-NAT networks is exactly why IPv6 should take off - unfortunately NAT is such a popular quick fix that this may take a long time. Ironically enough, transport-independent APIs will enjoy a resurgence as part of the conversion to IPv6.
All GPRS rollouts today use NAT, because the predicted number of active always-on users was so high - at one point the GSM Association asked for something like 2% of the IPv4 address space and was told to go away...
UMTS requires that IPv6 is enabled in some areas, and use of IPv6 is mandated by the UMTS Release 5 IP Multimedia System. This is a big driver for IPv6 and is one reason why Cisco, Juniper, Sun and co are shipping production IPv6 code.
So VoIP needs QoS - this is a well established technology in IP. There are wireline VoIP providers today who use private IP networks (some using QoS based on queuing) and some who actually use the Internet and get good QoS - the latter have to closely monitor achieved QoS and be ready to switch their traffic to another provider, but they claim good QoS and their costs are very low.
For dependable service, network switching is not enough and QoS is probably essential. This is particularly true with 3G where you might be able to choose from the following VoIP-related services, all with different bandwidth/latency requirements:
- simple voice call
- stereo call (listen in to a live concert perhaps?)
- conference call (high QoS)
- multimedia conference (voice, data sharing)
- videoconference
These more flexible IP services are where circuit switching falls down.
IP QoS will have to develop hugely to work for wireless, though. In wireline environments, you can set up a QoS session using RSVP and have it stay up for minutes or hours, so setup latency is not a big issue. In wireless, the caller could be moving between cells in a car or train, and might spend only a matter of seconds in each cell - every time they move to a new cell, their QoS session must be partially recreated (from the core network to the new cell), in a matter of tens of milliseconds.
For quite some time, it may be more cost-effective to overbuild networks and introduce simplifying constraints, but eventually wireless IP QoS should take off as an invisible support for wireless VoIP and multimedia over IP.
UMTS, a key 3G standard mostly used outside North America, will be All-IP in Release 5, which is nearing completion and should be rolled out in a few years. This mandates the use of VoIP for all use of the IP Multimedia Subsystem (which enables the advanced services listed above). Current UMTS rollouts are using Release 99 or Release 4 (formerly Release 2000), which are much less IP-based.
3GSM is usually known as UMTS, and is associated with W-CDMA (the commonest radio interface for UMTS). (Only the GSM Association calls it 3GSM). UMTS should be the most widespread 3G standard a there is an upgrade path for GSM operators - even though the UMTS technology is very different from GSM, handover between GSM and UMTS cells will be possible.
As for CDMA - it has been deployed at 800 MHz in Australia to replace the analogue AMPS network, primarily to provide rural coverage. An interesting comparison table for GSM and CDMA in Australia is at http://www.austarmobile.com.au/tools_netinf02.asp - looks relatively unbiased as it's from a company with a foot in both camps.
The kicker is that current 3G deployments using the CDMA upgrade for 3G (CDMA2000) are going very well in Japan and Korea, while NTT DoCoMo's flavour of 3G (W-CDMA based, similar to UMTS) is having real trouble (due to poor coverage, single-mode handsets, applications, pricing, etc). So there is a chance that UMTS won't really succeed and CDMA2000 will take over. However, given the sheer amount of investment in UMTS by Ericsson, Nokia and many wireless operators, I'd be surprised to see this happen.
Yes, we GSM freaks are just plain wrong - except that the statistics show that GSM has 71% of the world digital mobile phone market and 68% of the whole market (analogue and digital). GSM is available in 157 countries from 438 operators (hint: there aren't 157 countries in Europe...) See http://www.gsmworld.com/news/statistics/index.shtm l for the details.
CDMA has some benefits and it is gaining market share against GSM in some markets, but GSM is in no way a European standard, although it originated in Europe. And 3G of all the various flavours will be CDMA based, even for current GSM operators.
As for moving to Europe - you're right, you might as well buy a different phone since you will need a new mobile phone service anyway. If and only if GSM is a good option for where you live and travel in the US (analogue or CDMA may be better for you), it may make sense to get a tri-band GSM phone that works on any GSM network in the world. Tri-band GSM is also good for Americans who travel a lot outside the US, particularly in Europe, Asia and Australasia.
Interesting that shops can raise prices just before the sale - there is a law in the UK that says an item must have been on sale for some period of time at the pre-sale price before the shop can claim it is in the sale. It's a bit more complicated since chains could probably do this in just one obscure location, but it helps to stop this sort of thing. Of course, there are probably other scams that are just as bad...
It's just a matter of rolling out more Wi-Fi access points - this is exactly what happens with mobile phone networks. The great thing about such 'cellular' (in the technical sense) networks is that you can just subdivide cells and get more capacity quite easily. Eventually cells reach a minimum size but you can go quite a way with this approach.
MVS (which later became OS/390 and z/OS) does not have the ability to run other OSs. VM is the hypervisor that lets you run 'real' OSs such as MVS, CMS, Unix and Linux, using IBM mainframes, like VMware on x86. VM/VMware are something like UML but work at the hardware level and can run virtually any OS for the given hardware, whereas UML obviously is a version of Linux and can only run Linux apps, not OSs.
VM is very unlike OS/400 - one is a hypervisor, the other is an OS.
Putting all P2P traffic into a 'low priority' queue on all routers, and HTTP traffic and everything else into a 'normal priority' queue, would help this. Actually some sort of bandwidth allocation (WFQ, CBQ, etc) could be used rather than priority queuing. P2P apps would get the whole pipe if no higher priority traffic is around, but just X% if there is other traffic.
Of course, this is wildly impractical given the complete lack of uptake of QoS in the Internet - but since bandwidth hogs such as Pointcast and P2P drove earlier adoption of single-point QoS boxes such as Packeteer, it is not beyond the bounds of possibility. ISPs could deploy this without cooperation from other ISPs, just as a way of giving better service to non-P2P traffic within their network.
Of course, some would say that P2P should not be segregated - in which case, perhaps they could buy a premium service that puts P2P into 'normal priority'...
There is a lot of support in the HTTP caching headers for controlling the timeliness of cached copies - you can say 'keep this for just 5 minutes then check for a new version'. The trouble is that web developers don't know much about caching.
Of course, your browser caches already, and can easily be more aggressive than proxy caches, so eliminating proxy caches is not going to solve anything. If someone using a web-based application is so clueless they don't know about the Refresh button, AND the application developer managed to do a cacheable dynamic page, that is just lack of training, or using the wrong tools.
Defeating caching is very easy - most CGI-based sites are not cacheable, and many commercial sites turn caching off in order to see all hits.
Eventually, software-defined radio will come to mobile phones and PDAs, and you'll be able to just download new software to switch from CDMA to GSM and so on. At least, that's the vision - your RF hardware must still be able to handle the right frequencies.
I had forgotten about EDT - actually it was a huge step up just having a screen editor on RSX-11M, before that we had some horrible line editor. Shortly after that I got into Unix System III and learnt vi, and have never stopped using it...
Back in the days when computing revolved around IBM mainframes, Amdahl was a plug-compatible mainframe manufacturer. There was a saying that just having an Amdahl mug on your desk was worth a significant discount when the IBM salesman came calling.
I see the x86 version of MacOS X as just a bargaining chip - given the huge hassle of converting to x86, and the danger of commoditising Mac hardware, I think this is really a way of getting a better deal out of Motorola and IBM.
I did talk to someone in Japan in the late Eighties who was planning on selling consumer software via vending machines, but I don't know if this ever materialised.
What sort of keyboard would you suggest rather than Qwerty? Nobody is going to learn a Dvorak or Maltron layout just to use a mobile device... The Qwerty layout was originally designed to slow down typing (back when typewriters were wholly mechanical and jammed easily), but that's not really relevant when you are using your thumbs to bash out a short message.
Slashdot Mirror
You make some good points about Qt's adoption - definitely helps to get a major open source project to adopt a GUI toolkit. However, Qt is not viable for non-open-source developers or sysadmins who want to write cross-platform GUI-based scripts in Perl/Python. Its per-seat development cost is aimed at commercial C++ applications, so wxPerl/WxPython are ideal.
GNOME/Gtk are nice but getting them working on a Windows box is painful - wxWindows provides a simpler approach. To use wxPerl, you just install the Wx module from CPAN, read the tutorials, and off you go - no license fees.
Also, there's a GUI design tool for Wx, called wxDesigner - it's commercial but the cost is very reasonable, under $300 for 10 licenses, and it supports C++, Perl and Python.
By the way, am I the only person who sees Perl and Python as more similar than different? Of course, each one has advantages, but perhaps it is the similarity that drives the language wars...
Would be nice if wxPython was ported to PalmOS, and if Pippy was a bit more complete...
wxPerl is good, and similar to wxPython as it should be. There are some good tutorials for wxPerl but the docs aren't as good as for wxPython - fortunately you can read the wxPython or C++ docs and just transliterate them into Perl.
My T68 is being repaired for the second time in a month - it goes into a state where it refuses to make or receive calls, mainly on GSM-1800 networks. Along with the frequent crashes and spontaneous switching-off in my pocket (even though keypad lock is on), this is making me less than impressed with SonyEricsson...
If the Nokia 7650 wasn't so chunky I'd buy one like a shot, and I may still do just to get phone software that is faster and more stable.
That's a bit like saying, back in 1995, that 'Linux is doomed - Windows has more users, more desktops, high economies of scale, ...' Of course, back then Linux was not really ready for prime time the way it is now, with nicer GUIs, installers, more apps, etc.
W-CDMA is not really finished yet, as other posts have pointed out - NTT DoCoMo launched too early with a sort-of W-CDMA, but its phones didn't have any roaming onto the local 2G networks, so you had to buy a large expensive phone to get tiny coverage in a couple of big cities. Not surprisingly, it failed.
The real test will come when W-CDMA phones have integrated roaming onto 2G networks (mainly GSM) - only then is there any chance of serious uptake. These phones will have a much bigger potential market than CDMA2000, so as long as the phones and networks work well, and have good services at reasonable prices, it's possible that W-CDMA will gradually come to dominate. But only time will tell...
That's assuming IA-64 lasts that long - Digital/Compaq's Alpha was announced in 1992 with a planned life of 25 years and is (more or less) dead now. See http://www.funet.fi/pub/unix/DEC/Alpha/press_relea se.txt for the original announcement.
Of course, Alpha failed to take over more for commercial reasons, but if successive waves of competition beat IA-64 commercially or technically, the effect may be the same.
If your office VPN setup *has* to use IPSec AH, you are probably out of luck. AH means Authentication Header, which means it cryptographically authenticates every IP packet, including the IP address. NAT changes this address, and AH on the server rejects the packet as it should do.
The only way round this is to use ESP, and most likely ESP over UDP. CheckPoint VPN-1 supports this in recent versions, as do most other vendors I think. See my other post in this thread for links.
You are correct that IPSec has protocol issues with NAT, but they are being addressed. Until the solution is standardised, the IPSec implementation matters a lot - some implement ESP over UDP, i.e. pre-standard versions of http://www.ietf.org/internet-drafts/draft-ietf-ips ec-udp-encaps-03.txt and http://www.ietf.org/internet-drafts/draft-ietf-ips ec-nat-t-ike-03.txt
There's an overview of IPSec over NAT at http://www.networkcomputing.com/1123/1123ws2.html - I'm not fully up to date with all this, but it does work and I use it every day to get past my Linux NAT/firewall at home from a CheckPoint SecureClient IPSec implementation on Windows.
I agree about the performance - it's painful to have to wait a second or two for a screen to appear, and in some cases minutes (after changing a season pass). I can't work out why it is this slow - I suspect poor algorithms and data structures. After all, it is presumably dealing with an in-memory database that (with proper indexing and data structures) should be blindingly fast for retrievals and updates.
Tivo's performance is the one really annoying part of the product, and enough to stop me recommending it to other people.
PostgreSQL is an open source project, not a product. The developers can port it to Windows in any way they want - it does run on Cygwin, which I use a lot for other tools. Why is it such a problem to use Cygwin? It's just a DLL, you wouldn't need the whole Cygwin environment on a production server, only on development machines.
You have no right to be angry at an open source project that is done by volunteers, usually in their spare time - if you really want a native Windows port, you can either help port it yourself or pay someone to do it.
Not sure about any such laws in Europe, but CDMA and GSM coexist in Asia, and GSM is still the market leader there. GSM is in over 150 countries...
This is a somewhat 1980s perspective - back when there were multiple layer 3 and 4 network technologies and IP was just one of them, it was common to invent transport-independent APIs. However, this still leaves the issue of transport level gateways to allow the end hosts to communicate. It's much easier to just use IP everywhere so that IF you want your mobile phone to talk to a Sun server there is no technical barrier to doing so.
The drive for end to end no-NAT networks is exactly why IPv6 should take off - unfortunately NAT is such a popular quick fix that this may take a long time. Ironically enough, transport-independent APIs will enjoy a resurgence as part of the conversion to IPv6.
All GPRS rollouts today use NAT, because the predicted number of active always-on users was so high - at one point the GSM Association asked for something like 2% of the IPv4 address space and was told to go away...
UMTS requires that IPv6 is enabled in some areas, and use of IPv6 is mandated by the UMTS Release 5 IP Multimedia System. This is a big driver for IPv6 and is one reason why Cisco, Juniper, Sun and co are shipping production IPv6 code.
So VoIP needs QoS - this is a well established technology in IP. There are wireline VoIP providers today who use private IP networks (some using QoS based on queuing) and some who actually use the Internet and get good QoS - the latter have to closely monitor achieved QoS and be ready to switch their traffic to another provider, but they claim good QoS and their costs are very low.
For dependable service, network switching is not enough and QoS is probably essential. This is particularly true with 3G where you might be able to choose from the following VoIP-related services, all with different bandwidth/latency requirements:
- simple voice call
- stereo call (listen in to a live concert perhaps?)
- conference call (high QoS)
- multimedia conference (voice, data sharing)
- videoconference
These more flexible IP services are where circuit switching falls down.
IP QoS will have to develop hugely to work for wireless, though. In wireline environments, you can set up a QoS session using RSVP and have it stay up for minutes or hours, so setup latency is not a big issue. In wireless, the caller could be moving between cells in a car or train, and might spend only a matter of seconds in each cell - every time they move to a new cell, their QoS session must be partially recreated (from the core network to the new cell), in a matter of tens of milliseconds.
For quite some time, it may be more cost-effective to overbuild networks and introduce simplifying constraints, but eventually wireless IP QoS should take off as an invisible support for wireless VoIP and multimedia over IP.
UMTS, a key 3G standard mostly used outside North America, will be All-IP in Release 5, which is nearing completion and should be rolled out in a few years. This mandates the use of VoIP for all use of the IP Multimedia Subsystem (which enables the advanced services listed above). Current UMTS rollouts are using Release 99 or Release 4 (formerly Release 2000), which are much less IP-based.
3GSM is usually known as UMTS, and is associated with W-CDMA (the commonest radio interface for UMTS). (Only the GSM Association calls it 3GSM). UMTS should be the most widespread 3G standard a there is an upgrade path for GSM operators - even though the UMTS technology is very different from GSM, handover between GSM and UMTS cells will be possible.
As for CDMA - it has been deployed at 800 MHz in Australia to replace the analogue AMPS network, primarily to provide rural coverage. An interesting comparison table for GSM and CDMA in Australia is at http://www.austarmobile.com.au/tools_netinf02.asp - looks relatively unbiased as it's from a company with a foot in both camps.
The kicker is that current 3G deployments using the CDMA upgrade for 3G (CDMA2000) are going very well in Japan and Korea, while NTT DoCoMo's flavour of 3G (W-CDMA based, similar to UMTS) is having real trouble (due to poor coverage, single-mode handsets, applications, pricing, etc). So there is a chance that UMTS won't really succeed and CDMA2000 will take over. However, given the sheer amount of investment in UMTS by Ericsson, Nokia and many wireless operators, I'd be surprised to see this happen.
Yes, we GSM freaks are just plain wrong - except that the statistics show that GSM has 71% of the world digital mobile phone market and 68% of the whole market (analogue and digital). GSM is available in 157 countries from 438 operators (hint: there aren't 157 countries in Europe...) See http://www.gsmworld.com/news/statistics/index.shtm l for the details.
CDMA has some benefits and it is gaining market share against GSM in some markets, but GSM is in no way a European standard, although it originated in Europe. And 3G of all the various flavours will be CDMA based, even for current GSM operators.
As for moving to Europe - you're right, you might as well buy a different phone since you will need a new mobile phone service anyway. If and only if GSM is a good option for where you live and travel in the US (analogue or CDMA may be better for you), it may make sense to get a tri-band GSM phone that works on any GSM network in the world. Tri-band GSM is also good for Americans who travel a lot outside the US, particularly in Europe, Asia and Australasia.
Interesting that shops can raise prices just before the sale - there is a law in the UK that says an item must have been on sale for some period of time at the pre-sale price before the shop can claim it is in the sale. It's a bit more complicated since chains could probably do this in just one obscure location, but it helps to stop this sort of thing. Of course, there are probably other scams that are just as bad...
It's just a matter of rolling out more Wi-Fi access points - this is exactly what happens with mobile phone networks. The great thing about such 'cellular' (in the technical sense) networks is that you can just subdivide cells and get more capacity quite easily. Eventually cells reach a minimum size but you can go quite a way with this approach.
MVS (which later became OS/390 and z/OS) does not have the ability to run other OSs. VM is the hypervisor that lets you run 'real' OSs such as MVS, CMS, Unix and Linux, using IBM mainframes, like VMware on x86. VM/VMware are something like UML but work at the hardware level and can run virtually any OS for the given hardware, whereas UML obviously is a version of Linux and can only run Linux apps, not OSs.
VM is very unlike OS/400 - one is a hypervisor, the other is an OS.
Putting all P2P traffic into a 'low priority' queue on all routers, and HTTP traffic and everything else into a 'normal priority' queue, would help this. Actually some sort of bandwidth allocation (WFQ, CBQ, etc) could be used rather than priority queuing. P2P apps would get the whole pipe if no higher priority traffic is around, but just X% if there is other traffic.
Of course, this is wildly impractical given the complete lack of uptake of QoS in the Internet - but since bandwidth hogs such as Pointcast and P2P drove earlier adoption of single-point QoS boxes such as Packeteer, it is not beyond the bounds of possibility. ISPs could deploy this without cooperation from other ISPs, just as a way of giving better service to non-P2P traffic within their network.
Of course, some would say that P2P should not be segregated - in which case, perhaps they could buy a premium service that puts P2P into 'normal priority'...
There is a lot of support in the HTTP caching headers for controlling the timeliness of cached copies - you can say 'keep this for just 5 minutes then check for a new version'. The trouble is that web developers don't know much about caching.
Of course, your browser caches already, and can easily be more aggressive than proxy caches, so eliminating proxy caches is not going to solve anything. If someone using a web-based application is so clueless they don't know about the Refresh button, AND the application developer managed to do a cacheable dynamic page, that is just lack of training, or using the wrong tools.
Defeating caching is very easy - most CGI-based sites are not cacheable, and many commercial sites turn caching off in order to see all hits.
Eventually, software-defined radio will come to mobile phones and PDAs, and you'll be able to just download new software to switch from CDMA to GSM and so on. At least, that's the vision - your RF hardware must still be able to handle the right frequencies.
I had forgotten about EDT - actually it was a huge step up just having a screen editor on RSX-11M, before that we had some horrible line editor. Shortly after that I got into Unix System III and learnt vi, and have never stopped using it...
Back in the days when computing revolved around IBM mainframes, Amdahl was a plug-compatible mainframe manufacturer. There was a saying that just having an Amdahl mug on your desk was worth a significant discount when the IBM salesman came calling.
I see the x86 version of MacOS X as just a bargaining chip - given the huge hassle of converting to x86, and the danger of commoditising Mac hardware, I think this is really a way of getting a better deal out of Motorola and IBM.
I did talk to someone in Japan in the late Eighties who was planning on selling consumer software via vending machines, but I don't know if this ever materialised.
What sort of keyboard would you suggest rather than Qwerty? Nobody is going to learn a Dvorak or Maltron layout just to use a mobile device... The Qwerty layout was originally designed to slow down typing (back when typewriters were wholly mechanical and jammed easily), but that's not really relevant when you are using your thumbs to bash out a short message.