This is rubbish - while people might *prefer* a specific distro, simply ensuring that hardware has Linux support would be enough for most people to install the distro they prefer, without installation hassles.
Quite a lot of Windows users end up doing all sorts of tech fixes to solve problems, including registry hacks that are no easier than editing a text file. These are the moderately technical people who can download shareware, use regedit, read log files, etc, and could easily make the switch to a good Linux distro in which most things just work out of the box. This is why pre-installation matters - it lets someone who is fairly technical but short of time just get going with Linux, and spend a little time fixing anything that doesn't quite work, and then just use the box with very little maintenance due to Linux's inherent stability and the ease of doing updates via apt-get etc.
If there's no suitable application out there, I would do this with Perl, starting with a prototype that just reads in text files, processes them, and writes them back - then you can graduate to a more sophisticated version that uses a database if needed.
However, the relevant searching would take some time to do efficiently in a DB, and the stated number of subnets is quite small, so writing the algorithms in Perl would be easier - and as I expected there are some potentially useful CPAN modules:
Of course, on Windows Perl you can even use Perl as a macro language to manipulate Excel spreadsheets via OLE - or on *nix you can just read the Excel values directly from Perl without converting to CSV. See CPAN for details...
Why don't you want your addresses to go to the outside world? If you have a firewall, nobody can contact them anyway. This sort of thinking is left over from IPv4: "we must have NAT for security", rather than thinking about the real attack threats and defences. IPv6 NAT provides no real security over a firewall, just like IPv4 NAT.
And of course the *entire point of IPv6* is that the larger address space means you can dump NAT, and dump all the nasty workarounds so that more complex apps work end to end, host to host, as they should do.
Virtually every Cisco, Juniper or other router supports IPv6 - Cisco started its IPv6 transition in 2000 and finished it a long time ago, so a huge number of installed routers just need to be configured for IPv6 - still a big task, but not a capital investment and can be done gradually rather than as a 'fork lift upgrade'. As for firewalls, Check Point is the market leader and announced IPv6 support in 2002: http://www.checkpoint.com/press/2002/ipv6_081402.h tml - and for geeky home users, IPv6 is already suppported by DD-WRT and other Linux-based firmware for the Linksys WRT54G box, and of course by BSD/Linux on PCs.
Consumer routers are fairly disposable - when a real service comes along needing IPv6 they can be firmware-upgraded in many cases or just replaced. Many new services such as BT Total Broadband in the UK come with an integrated router/WiFi/VoIP box. Other services driving IPv6 might be 3G mobile, fixed-mobile convergence (3G femtocell access points for the home are coming, roam onto your home 3G cell for about $100 wholesale, less with subsidy), or IMS (IP Multimedia Subsystem, telcos' attempt to push high-QoS services across any access link).
IPv6 is taking off first in AsiaPac (China is doing a huge amount of IPv6, Japan has a lot of networks already), but it's also hitting Europe. I recently saw strong indications that IPv6 will be required for systems going in this year, from two well-known telcos, which is a first in my experience. And of course the DoD is procuring IPv6-based systems and networks.
Apps re the main area for IPv6 now, so Microsoft AD and Squid do need to support IPv6. But at least Windows Vista includes IPv6 enabled by default - v6 was included in XP but had to be enabled (just one command though).
Google Desktop says that it automatically updates itself, but that doesn't work, and there's no 'force an update' feature as with Firefox.
More infuriatingly, Google Desktop also doesn't understand that emails that it indexes in my Outlook Inbox won't stay there forever due to restrictions on server mailbox size, and doesn't re-index them when they move to an offline.PST file. So I frequently find an email, then try to open it in Outlook, then find I can't and have to find it manually by date/time. Same issue with files that are renamed or moved. Many people have complained about this, but the Google Desktop team ignored this, and instead spent their time producing the incredibly useless widgets, rather than *making the search features really work well*.
Google Desktop still doesn't support the use of '-' to join two words, i.e. "foo bar" can be written as foo-bar. And the Google Desktop results within Outlook are still not a proper Outlook result list (as with Outlook Find), so you can't just drag items into a new email as attachments - no, you have to open up the email (if it can find it...), use Outlook to copy it to a temp folder, then drag from that folder into the new email.
Google Desktop is simply too annoying to use any more, even though I've used it from version 1, and is actually a very un-Google-like product. Unlike the core Google.com search, which has been quietly optimised over the years to add stemming, proximity, spelling correction, etc, Google Desktop is actually a rather mediocre and barely usable desktop search tool whose primary benefit is that it integrates well with Google Toolbar.
At least in the UK, you can get CFL bulbs that look almost exactly like incandescent bulbs in shape and size. They are opaque, like most incandescent bulbs these days. The only issue I have with CFLs is finding bulbs that (a) light up quickly [mostly they do now], (b) go to max brightness in seconds (usually takes a minute or three), and (c) don't gradually get dimmer over a year or two.
The gradual dimming is a real pain although a known issue with flourescent lights - seems worse with CFLs somehow, and I've had to replace CFLs before they wore out because of this, which means their lifetime is a lot shorter than advertised. They're still a much better bet than incandescents though, and they make a big difference to CO2 emissions and electricity costs.
In the US, Sprint and Verizon run CDMA-based wireless networks, whereas T-Mobile and Cingular/AT&T run GSM, which is the standard used everywhere in Europe and by 80-90% of the world's mobile phones. So it's nothing to do with Sprint policies that you can't take a CDMA-based Treo 650 and use it on a GSM network.
The FCC is largely to blame for this situation btw - it decided that US carriers could buy spectrum without mandating technical standards on top of this as Europe did. So the US has five mobile phone standards (analog, TDMA, CDMA, GSM and iDEN), while the rest of the world basically has one (there are GSM operators in every country in the world that has mobile phones, although in some parts of Asia and Latin America there are also TDMA and CDMA operators). Despite GSM perhaps not being technically optimal initially, it works very well overall and the result is a mass market for GSM phones and network equipment, driving down costs and improving features/performance.
CDMA as a technology is great, and the basis for UMTS, the GSM world's version of 3G, it's just the market fragmentation that's been a problem.
My Treo currently crashes on some incoming calls - it actually reboots even before I can see the incoming caller's number. Good suggestion of yours, just stop getting incoming calls to avoid this!
I can probably fix this with a hard reset and re-installing all apps, but that really shouldn't be necessary on a mobile phone and I don't have the time. Apart from that it's very stable, but that type of crash is very annoying.
Generally the Treo makes a great organiser, good web browser, good app platform and a mediocre phone - it also has problems with severe echo heard by the people I call, but the organiser and Outlook syncing are so good that I've not shifted yet. Having said all that, my next phone will probably be a Treo 680, but I would really like a Linux-based Treo that could run PalmOS apps (not just in a PalmOS emulator) as well as handle WiFi and UMTS. Bizarrely, Palm has yet to do a UMTS 3G Treo that runs PalmOS and has WiFi, so I may be forced to leave PalmOS after 10 years or so...
It's best to not have any software firewalls on a PC used by someone elderly - from my experience, it's easy for the elderly person to click the wrong button after a Firefox/Thunderbird update and cut off their email. Instead, just use a broadband router with a reliable firewall, and disable all use of Internet Explorer or Outlook, and make sure Windows auto-updates are turned on. Or get them using Linux if you can - one relative, now 80, started using PCs a long time ago when Linux wasn't an option, so she took the DOS/Windows route, but if I was starting an elderly person on the Internet today I would use something like Kubuntu or MEPIS (now Ubuntu based).
Another key issue is setting up remote access unless you live a few minutes away - absolutely key to do this, yet the shortage of IPv4 addresses makes this annoyingly hard to do when both sides are behind a NAT router. It's almost worth getting IPv6 on both sites just to simplify this, though it would take some setting up.
For those stuck with NAT, try Fog Creek Copilot - https://www.copilot.com/ - not perfect, and requires access codes, but is relatively simple to get working. The downside of this is that you have to keep downloading new executables when buying a day-pass, which is the most error-prone part of the whole setup.
Linux desperately needs The One Universal Linux Setup Wiki that has refined and continually updated knowledge on common problems and how to fix them, as well as common setup tasks. Now that we have powerful Wikis like Wikipedia/MediaWiki and TWiki, and Linux users are becoming far more Wiki-literate, isn't it time for this single Wiki? Even one that covers a key distro like Ubuntu, but has the ability to expand to cover others, would be a good start.
I know there are many Linux tips and wiki sites out there, and innumerable forums, but the idea here is to consolidate information and tips gleaned from these various sources, and ultimately to have people ask questions on the wiki (or a closely linked forum perhaps) and then update the wiki with answers that really work.
I've seen Wiki technology work really well in smaller domains within specific companies, and I think it is just waiting for someone to get this started...
It's a lot cleaner and more reliable to have all the tab-session-saving functionality built into the browser - I used Tab Mix Plus and it was generally OK, but would frequently not restore all my tabs, and sometimes forget all of them. I now have a couple of very simple tab extensions in Firefox 2, one to let me duplicate a tab and the other to open new tabs immediately to the right of the current tab.
TWiki's generally great for intranet collaboration as it has good revision tracking, WYSIWYG editing (beta) and other nice features, as well as over 200 plugins including some that support action tracking, Extreme Programming support, etc.
I take your points about other areas that depend on IP addresses. The problem with multi-homing in IPv4 and IPv6 is that it makes it hard to scale the network - in fact, core routing tables started growing exponentially again in 2004 on the IPv4 Internet due to multi-homing (ref: http://en.wikipedia.org/wiki/Border_Gateway_Protoc ol). There is an IETF working group called Multi6 on IPv6 multi-homing for this reason, see http://www.ietf.org/html.charters/multi6-charter.h tml - not sure if their approach will simplify things for multi-homed sites but they are aiming to reduce core routing table growth.
People switch web hosting providers all the time on IPv4, it's just a matter of managing DNS TTLs as you get closer to switching, and so on. The barriers are exactly the same for people who have ISP-based address spaces (most of whom have the majority of devices behind NAT anyway). You may find some people will grant provider-independent IPv6 address space, but since it's so easy to switch provider-based address spaces, the extra cost will probably not be worth it for most people.
You can still do multi-homing, it's just that you then need to advertise two routes out via your ISP. Only the few companies that own ISP-independent address space can do this type of multi-homing, and it's horribly expensive for the core routing tables in IPv4. One more subtle benefit of IPv6 is that it can reduce the growth in core routing tables, which is a real scalability issue for core Internet routers.
I don't think so, but router and host autoconfiguration, and other features like address lifetimes, make it really much, much easier to switch over to a new ISP and address space, by simply configuring once at a central point. IPv6 is an enormous improvement in this area.
Re:You are completely retarded.
on
IPv6 Essentials
·
· Score: 1
Somebody should mod parent up, although it's somewhat flamey - the useful part of QoS (DiffServ codepoint support) is in IPv4 just as much as IPv6.
Security is also the same in IPv6 and IPv4, and autoconfiguration via RA really doesn't address all those extra parameters mentioned such as DNS servers.
However, transparent roaming through Mobile IP is genuinely useful, avoiding triangular routing. This and larger address space may be enough to make IPv6 happen.
Re:You are completely retarded.
on
IPv6 Essentials
·
· Score: 1
QoS is nothing to do with IPv6 - both IPv4 and IPv6 support DiffServ, which is the closest we have got so far to QoS standards that are actually deployed (mostly for MPLS IP VPNs and VoIP in closed IP networks run by telcos for business customers). The flow label is IPv6's only unique QoS feature and it is mostly for use by RSVP, which is undeployed and doesn't scale in current form.
Your other points are valid, though someone with NAT and IPv4 has basically the same restricted addressing as offered by IPv6, which doesn't add that much in terms of security.
QoS is nothing to do with IPv6
on
IPv6 Essentials
·
· Score: 1
IPv6 is not required to do QoS, and I really wish people would stop trying to associate the two - IPv4 has had QoS (via the 3-bit IP Precedence field and the 6-bit DiffServ codepoint that has superseded it) for decades, and virtually every router has QoS support. Both IPv4 and IPv6 have identical 6-bit DiffServ fields, termed the TOS byte in IPv4 and the Traffic Class in IPv6.
This is a bit like IPSec, which works fine on IPv4 even though it was designed alongside IPv6 (maybe that's why it was initially so NAT-hostile...)
The only unique IPv6 feature for QoS is the flow label, which is intended for easy classification of 'flows' such as a session on a specific source & destination port combination - however, this is really only useful with RSVP QoS, which doesn't scale well and requires application changes, and has therefore never taken off. (I worked on QoS technology and policy management for quite a while from the late 90s.)
The hard part of delivering QoS is the political/commercial agreement, and after that, agreeing on what the QoS levels should be. Telcos already run IP networks for use by business IP VPNs (MPLS not IPSec) this way, so they have a lot of experience.
IPv6 is a great technology but its main benefits are around router and host autoconfiguration, and never having to worry about IP address scarcity again.
Re:QoS (Quality of Service or crap for customers?)
on
IPv6 Essentials
·
· Score: 1
The TOS field is quite obsolete, and was never used anyway, although the adjacent 3 bit IP Precedence field was used somewhat. Both have been superseded by the 6 bit DiffServ codepoint field in IPv4 and IPv6 headers - it re-uses the TOS and IP Precedence fields.
There has never been much agreement on the meaning of these fields, though DiffServ does make some headway here by defining EF and AF schemes for the meaning of such codepoints.
There is some overhead to checking (classifying on) these fields, but the bigger issue is how do apps request QoS without zillions of fragile port-based classification rules on host or router. Microsoft's RSVP implementation in Windows XP made a valiant effort to provide a way for apps to set QoS, but was never used as far as I can tell. (I spent the last few years of the 90s doing QoS activation / policy management software for IP routers/hosts by the way).
The real issue with QoS is the inter-provider business and technical agreements - it's hard enough to get best-effort peering agreed, and getting QoS-based peering is a lot harder...
Slashdot Mirror
I'm curious - are there any other Linux phones that are actually available to buy in Europe (or can be shipped to Europe), and support:
1. Open architecture, ability to at least install apps and build your own apps on another host
2. UMTS 3G support - I don't want to buy yet another GPRS phone, my first one was over 5 years ago!
3. WiFi support
I know about OpenMoko and the Neo1973 - the software sounds fantastic but no UMTS, and WiFi would be nice too.
You could just read the FAQ, 2nd question is 'when can I buy one?' - http://wiki.openmoko.org/wiki/FAQ#Q:_When_can_I_bu y_a_Neo1973.3F - hardly 'buried in their Wiki'...
This is rubbish - while people might *prefer* a specific distro, simply ensuring that hardware has Linux support would be enough for most people to install the distro they prefer, without installation hassles.
Quite a lot of Windows users end up doing all sorts of tech fixes to solve problems, including registry hacks that are no easier than editing a text file. These are the moderately technical people who can download shareware, use regedit, read log files, etc, and could easily make the switch to a good Linux distro in which most things just work out of the box. This is why pre-installation matters - it lets someone who is fairly technical but short of time just get going with Linux, and spend a little time fixing anything that doesn't quite work, and then just use the box with very little maintenance due to Linux's inherent stability and the ease of doing updates via apt-get etc.
If there's no suitable application out there, I would do this with Perl, starting with a prototype that just reads in text files, processes them, and writes them back - then you can graduate to a more sophisticated version that uses a database if needed.
4 /IP.pm - NetAddr::IP, lets you manipulate IP addresses and subnets, including splitting and merginge tmask.pod - manipulate netblocks, closer to what's needed
However, the relevant searching would take some time to do efficiently in a DB, and the stated number of subnets is quite small, so writing the algorithms in Perl would be easier - and as I expected there are some potentially useful CPAN modules:
- http://search.cpan.org/~luismunoz/NetAddr-IP-4.00
- http://search.cpan.org/~muir/Net-Netmask-1.9015/N
Of course, on Windows Perl you can even use Perl as a macro language to manipulate Excel spreadsheets via OLE - or on *nix you can just read the Excel values directly from Perl without converting to CSV. See CPAN for details...
Why don't you want your addresses to go to the outside world? If you have a firewall, nobody can contact them anyway. This sort of thinking is left over from IPv4: "we must have NAT for security", rather than thinking about the real attack threats and defences. IPv6 NAT provides no real security over a firewall, just like IPv4 NAT.
And of course the *entire point of IPv6* is that the larger address space means you can dump NAT, and dump all the nasty workarounds so that more complex apps work end to end, host to host, as they should do.
Virtually every Cisco, Juniper or other router supports IPv6 - Cisco started its IPv6 transition in 2000 and finished it a long time ago, so a huge number of installed routers just need to be configured for IPv6 - still a big task, but not a capital investment and can be done gradually rather than as a 'fork lift upgrade'. As for firewalls, Check Point is the market leader and announced IPv6 support in 2002: http://www.checkpoint.com/press/2002/ipv6_081402.h tml - and for geeky home users, IPv6 is already suppported by DD-WRT and other Linux-based firmware for the Linksys WRT54G box, and of course by BSD/Linux on PCs.
Consumer routers are fairly disposable - when a real service comes along needing IPv6 they can be firmware-upgraded in many cases or just replaced. Many new services such as BT Total Broadband in the UK come with an integrated router/WiFi/VoIP box. Other services driving IPv6 might be 3G mobile, fixed-mobile convergence (3G femtocell access points for the home are coming, roam onto your home 3G cell for about $100 wholesale, less with subsidy), or IMS (IP Multimedia Subsystem, telcos' attempt to push high-QoS services across any access link).
IPv6 is taking off first in AsiaPac (China is doing a huge amount of IPv6, Japan has a lot of networks already), but it's also hitting Europe. I recently saw strong indications that IPv6 will be required for systems going in this year, from two well-known telcos, which is a first in my experience. And of course the DoD is procuring IPv6-based systems and networks.
Apps re the main area for IPv6 now, so Microsoft AD and Squid do need to support IPv6. But at least Windows Vista includes IPv6 enabled by default - v6 was included in XP but had to be enabled (just one command though).
Google Desktop says that it automatically updates itself, but that doesn't work, and there's no 'force an update' feature as with Firefox.
.PST file. So I frequently find an email, then try to open it in Outlook, then find I can't and have to find it manually by date/time. Same issue with files that are renamed or moved. Many people have complained about this, but the Google Desktop team ignored this, and instead spent their time producing the incredibly useless widgets, rather than *making the search features really work well*.
More infuriatingly, Google Desktop also doesn't understand that emails that it indexes in my Outlook Inbox won't stay there forever due to restrictions on server mailbox size, and doesn't re-index them when they move to an offline
Google Desktop still doesn't support the use of '-' to join two words, i.e. "foo bar" can be written as foo-bar. And the Google Desktop results within Outlook are still not a proper Outlook result list (as with Outlook Find), so you can't just drag items into a new email as attachments - no, you have to open up the email (if it can find it...), use Outlook to copy it to a temp folder, then drag from that folder into the new email.
Google Desktop is simply too annoying to use any more, even though I've used it from version 1, and is actually a very un-Google-like product. Unlike the core Google.com search, which has been quietly optimised over the years to add stemming, proximity, spelling correction, etc, Google Desktop is actually a rather mediocre and barely usable desktop search tool whose primary benefit is that it integrates well with Google Toolbar.
At least in the UK, you can get CFL bulbs that look almost exactly like incandescent bulbs in shape and size. They are opaque, like most incandescent bulbs these days. The only issue I have with CFLs is finding bulbs that (a) light up quickly [mostly they do now], (b) go to max brightness in seconds (usually takes a minute or three), and (c) don't gradually get dimmer over a year or two.
The gradual dimming is a real pain although a known issue with flourescent lights - seems worse with CFLs somehow, and I've had to replace CFLs before they wore out because of this, which means their lifetime is a lot shorter than advertised. They're still a much better bet than incandescents though, and they make a big difference to CO2 emissions and electricity costs.
In the US, Sprint and Verizon run CDMA-based wireless networks, whereas T-Mobile and Cingular/AT&T run GSM, which is the standard used everywhere in Europe and by 80-90% of the world's mobile phones. So it's nothing to do with Sprint policies that you can't take a CDMA-based Treo 650 and use it on a GSM network.
The FCC is largely to blame for this situation btw - it decided that US carriers could buy spectrum without mandating technical standards on top of this as Europe did. So the US has five mobile phone standards (analog, TDMA, CDMA, GSM and iDEN), while the rest of the world basically has one (there are GSM operators in every country in the world that has mobile phones, although in some parts of Asia and Latin America there are also TDMA and CDMA operators). Despite GSM perhaps not being technically optimal initially, it works very well overall and the result is a mass market for GSM phones and network equipment, driving down costs and improving features/performance.
CDMA as a technology is great, and the basis for UMTS, the GSM world's version of 3G, it's just the market fragmentation that's been a problem.
My Treo currently crashes on some incoming calls - it actually reboots even before I can see the incoming caller's number. Good suggestion of yours, just stop getting incoming calls to avoid this!
I can probably fix this with a hard reset and re-installing all apps, but that really shouldn't be necessary on a mobile phone and I don't have the time. Apart from that it's very stable, but that type of crash is very annoying.
Generally the Treo makes a great organiser, good web browser, good app platform and a mediocre phone - it also has problems with severe echo heard by the people I call, but the organiser and Outlook syncing are so good that I've not shifted yet. Having said all that, my next phone will probably be a Treo 680, but I would really like a Linux-based Treo that could run PalmOS apps (not just in a PalmOS emulator) as well as handle WiFi and UMTS. Bizarrely, Palm has yet to do a UMTS 3G Treo that runs PalmOS and has WiFi, so I may be forced to leave PalmOS after 10 years or so...
It's best to not have any software firewalls on a PC used by someone elderly - from my experience, it's easy for the elderly person to click the wrong button after a Firefox/Thunderbird update and cut off their email. Instead, just use a broadband router with a reliable firewall, and disable all use of Internet Explorer or Outlook, and make sure Windows auto-updates are turned on. Or get them using Linux if you can - one relative, now 80, started using PCs a long time ago when Linux wasn't an option, so she took the DOS/Windows route, but if I was starting an elderly person on the Internet today I would use something like Kubuntu or MEPIS (now Ubuntu based).
Another key issue is setting up remote access unless you live a few minutes away - absolutely key to do this, yet the shortage of IPv4 addresses makes this annoyingly hard to do when both sides are behind a NAT router. It's almost worth getting IPv6 on both sites just to simplify this, though it would take some setting up.
For those stuck with NAT, try Fog Creek Copilot - https://www.copilot.com/ - not perfect, and requires access codes, but is relatively simple to get working. The downside of this is that you have to keep downloading new executables when buying a day-pass, which is the most error-prone part of the whole setup.
Linux desperately needs The One Universal Linux Setup Wiki that has refined and continually updated knowledge on common problems and how to fix them, as well as common setup tasks. Now that we have powerful Wikis like Wikipedia/MediaWiki and TWiki, and Linux users are becoming far more Wiki-literate, isn't it time for this single Wiki? Even one that covers a key distro like Ubuntu, but has the ability to expand to cover others, would be a good start.
I know there are many Linux tips and wiki sites out there, and innumerable forums, but the idea here is to consolidate information and tips gleaned from these various sources, and ultimately to have people ask questions on the wiki (or a closely linked forum perhaps) and then update the wiki with answers that really work.
I've seen Wiki technology work really well in smaller domains within specific companies, and I think it is just waiting for someone to get this started...
It's a lot cleaner and more reliable to have all the tab-session-saving functionality built into the browser - I used Tab Mix Plus and it was generally OK, but would frequently not restore all my tabs, and sometimes forget all of them. I now have a couple of very simple tab extensions in Firefox 2, one to let me duplicate a tab and the other to open new tabs immediately to the right of the current tab.
TWiki (http://twiki.org/) has plugins that handle source code formatting (see http://twiki.org/cgi-bin/view/Plugins/SourceHighli ghtPlugin and http://twiki.org/cgi-bin/view/Plugins/SyntaxHighli ghtingPluginDev) and others provide blog features (http://twiki.org/cgi-bin/view/Plugins/BlogPlugin looks pretty good). (Some tweaking required for the syntax highlighting plugins to work with latest TWiki version).
TWiki's generally great for intranet collaboration as it has good revision tracking, WYSIWYG editing (beta) and other nice features, as well as over 200 plugins including some that support action tracking, Extreme Programming support, etc.
Not in terms of population, which is what matters in terms of crime newsworthiness - the UK has 60 million inhabitants.
I take your points about other areas that depend on IP addresses. The problem with multi-homing in IPv4 and IPv6 is that it makes it hard to scale the network - in fact, core routing tables started growing exponentially again in 2004 on the IPv4 Internet due to multi-homing (ref: http://en.wikipedia.org/wiki/Border_Gateway_Protoc ol). There is an IETF working group called Multi6 on IPv6 multi-homing for this reason, see http://www.ietf.org/html.charters/multi6-charter.h tml - not sure if their approach will simplify things for multi-homed sites but they are aiming to reduce core routing table growth.
People switch web hosting providers all the time on IPv4, it's just a matter of managing DNS TTLs as you get closer to switching, and so on. The barriers are exactly the same for people who have ISP-based address spaces (most of whom have the majority of devices behind NAT anyway). You may find some people will grant provider-independent IPv6 address space, but since it's so easy to switch provider-based address spaces, the extra cost will probably not be worth it for most people.
You can still do multi-homing, it's just that you then need to advertise two routes out via your ISP. Only the few companies that own ISP-independent address space can do this type of multi-homing, and it's horribly expensive for the core routing tables in IPv4. One more subtle benefit of IPv6 is that it can reduce the growth in core routing tables, which is a real scalability issue for core Internet routers.
I don't think so, but router and host autoconfiguration, and other features like address lifetimes, make it really much, much easier to switch over to a new ISP and address space, by simply configuring once at a central point. IPv6 is an enormous improvement in this area.
Somebody should mod parent up, although it's somewhat flamey - the useful part of QoS (DiffServ codepoint support) is in IPv4 just as much as IPv6.
Security is also the same in IPv6 and IPv4, and autoconfiguration via RA really doesn't address all those extra parameters mentioned such as DNS servers.
However, transparent roaming through Mobile IP is genuinely useful, avoiding triangular routing. This and larger address space may be enough to make IPv6 happen.
QoS is nothing to do with IPv6 - both IPv4 and IPv6 support DiffServ, which is the closest we have got so far to QoS standards that are actually deployed (mostly for MPLS IP VPNs and VoIP in closed IP networks run by telcos for business customers). The flow label is IPv6's only unique QoS feature and it is mostly for use by RSVP, which is undeployed and doesn't scale in current form.
c id=16289245 for more details.
See http://books.slashdot.org/comments.pl?sid=198651&
Your other points are valid, though someone with NAT and IPv4 has basically the same restricted addressing as offered by IPv6, which doesn't add that much in terms of security.
IPv6 is not required to do QoS, and I really wish people would stop trying to associate the two - IPv4 has had QoS (via the 3-bit IP Precedence field and the 6-bit DiffServ codepoint that has superseded it) for decades, and virtually every router has QoS support. Both IPv4 and IPv6 have identical 6-bit DiffServ fields, termed the TOS byte in IPv4 and the Traffic Class in IPv6.
This is a bit like IPSec, which works fine on IPv4 even though it was designed alongside IPv6 (maybe that's why it was initially so NAT-hostile...)
The only unique IPv6 feature for QoS is the flow label, which is intended for easy classification of 'flows' such as a session on a specific source & destination port combination - however, this is really only useful with RSVP QoS, which doesn't scale well and requires application changes, and has therefore never taken off. (I worked on QoS technology and policy management for quite a while from the late 90s.)
The hard part of delivering QoS is the political/commercial agreement, and after that, agreeing on what the QoS levels should be. Telcos already run IP networks for use by business IP VPNs (MPLS not IPSec) this way, so they have a lot of experience.
IPv6 is a great technology but its main benefits are around router and host autoconfiguration, and never having to worry about IP address scarcity again.
The TOS field is quite obsolete, and was never used anyway, although the adjacent 3 bit IP Precedence field was used somewhat. Both have been superseded by the 6 bit DiffServ codepoint field in IPv4 and IPv6 headers - it re-uses the TOS and IP Precedence fields.
There has never been much agreement on the meaning of these fields, though DiffServ does make some headway here by defining EF and AF schemes for the meaning of such codepoints.
There is some overhead to checking (classifying on) these fields, but the bigger issue is how do apps request QoS without zillions of fragile port-based classification rules on host or router. Microsoft's RSVP implementation in Windows XP made a valiant effort to provide a way for apps to set QoS, but was never used as far as I can tell. (I spent the last few years of the 90s doing QoS activation / policy management software for IP routers/hosts by the way).
The real issue with QoS is the inter-provider business and technical agreements - it's hard enough to get best-effort peering agreed, and getting QoS-based peering is a lot harder...
Jerry Pournelle's self-indulgent pieces were the only thing I didn't like about Byte - just about everything else was perfect.