Ugh... What part of the world are you people from???
These are European prices, so they include VAT. That would be something like 15 - 20 % (differs per country even though consumer prices are 99 cents in the euro countries AFAIK).
Don't know what that means for the Apple/label split, but Apple has to pay for bandwidth (cheap), servers (not quite as cheap) and credit card processing. Just the latter is probably more than what artists get from the labels.
apple seems to have picked a very good speed for the fans. I tested them with various processor and graphics loads, and the fans only spooled up when the laptop's temperature started to get up there. Right now it shows 132F, relatively idle
Unfortunately, it seems Intel's chipset doesn't allow the bus to slow down when the system is idle or battery-powered. That's not cool. The current implementation of the Core family is pretty energy efficient at full blast, but not so much when idle, compared to, for instance, a G4. Hopefully we'll have Santa Rosa soon and this will get better.
In my opinion, buying movies online makes little sense. The trouble is, when you buy online you need to provide the storage yourself. I don't have that many DVDs, but I'd still have to invest in some serious storage to put all that stuff on harddisks. And then back it up, move it to newer bigger disks every few years... This is a huge headache. With CDs, it's different, because one CD only needs about 1/20th of the disk space that the contents of a DVD does. And when you want to listen to a 4 minute song, spending 2 minutes to find the CD is problematic, so it makes sense to store your music on your computer. 2 minutes to find a DVD and then watch it for 2 hours isn't a problem at all so there isn't much of a case for doing the same here.
I think buying online will mostly be popular with people with small kids, who like to watch the same stuff over and over again and tend to wreak havoc on physical media, and for people who will treat the service mostly like a rental service and don't care about the price difference.
Downloading rentals rather than buying movies online makes much more sense: you get your stuff faster but you don't have worry about permanent storage. The DRM and slightly lower quality are much less of an issue.
Because of the RDF, mac lovers are convinced that 100 dpi really is the magic number and there's no greater proponent of that than you in your original post. I own a MBP and I use it despite its low resolution screen. Fixing that would make the MBP even better and allowing people with varying eyesight the ability to control scaling just makes sense.
I really don't get why you are arguing against me.:-)
I run my 17" CRT (= 15.5" viewable area) at 1172 pixels wide, and I'd love to have that as the native resolution for my Powerbook as well, making for 90 DPI.
We are pretty much saying the exact same thing, except that you want it in order to make stuff on the screen smaller, while I want it to make stuff on the screen bigger. We both don't like the hardcoded-for-100-DPI way that things work today.
I'm not quite as negative about Apple as you, though: it looks like they're getting their act together. It would have been better if they'd done that one or two releases ago, but I'm in the market for a new laptop between now and six months from now so it all works out.
For a notebook 150 dpi is perfectly reasonable and only mac people (who don't have the option) argue that it isn't.
Without any context, a DPI number is meaningless. My printer prints at 600 DPI which is great. If I set my CRT to its highest resolution (1600x1200) I get 130 DPI. Many things are just fine at this resolution, for instance the MacOS menu bar is easy to read. But for other stuff, it doesn't work so well. For instance, using Safari as my web browser without any zooming the letter o on/. is about 1 millimeter high on the screen. In a newspaper, it's about 2 mm, in a book a little less but closer to 2 than to 1.5. If you consider that newspapers in the past have had typefaces created for very purpose of cramming as much text on a page as possible, and they've been doing this for a few centuries, I'm pretty sure that around 2 mm is a much better size than 1 mm, and it's not Steve Job's reality distortion field that makes me feel that with this combination of web design and screen resolution, I have to strain to read text.
Curious that your computer usage specifically creates a problem that can't be solved without a user-controllable global scaling option which (a) doesn't exist and (b) there is no promise that it will exist in the future, then you use that problem of your own creation to argue against the value of display resolutions greater than 100 dpi.
I don't; go back and read my posts. I'm all in favor of high resolution screens in general. When I have to read a lot of stuff behind my CRT I'll increase the resolution to the aforementioned 1600x1200 and the letters look much better, this is great.
Apple had a page up talking about how 100 DPI is the ideal resolution (can't find the page right now, I think they took it down). I'm not buying that: it's a limitation of their software that everything running on a Mac thinks the whole universe is 72 DPI and you can't even change the system font size (even my first Amiga that I had half a lifetime ago could do this). But given that situation, I agree with their decision to stay away from really high resolutions.
Even Windows does better than that.
Sad but true, although changing the default in Windows XP isn't entirely problem free. Hopefully this type of discussion will be history after the introduction of Leopard and a slew of ultra-high resolution Apple laptops. In the mean time, I suggest that you consider the possibility that just like computers, people have widely different hard- and software attributes so what works for you doesn't necessarily work for everyone else.
The resolving power of the eye at 24" is about 150 dpi for good vision. That means your Powerbook could be 36" away and the MBP only 32". Chances are you use it closer than that so, unless you have poor vision, you don't really have a problem with the MBP at 110 dpi
It's not a question of being able to distinguish the individual pixels, but rather, what is a comfortable letter size for reading. Most people read the paper nearly at arm's length, I hold it much closer. It's not that I can't read it at arm's length, it's just much more comfortable a bit closer. When I'm using my laptop interactively, I sit relatively close because my hands are on the keyboard. But when I'm reading stuff on the web, I'd rather lean back against the couch. This makes the letter size used on/. too small to read for me. So either I have to lean in or I have to zoom the text.
In many applications, there are ways to increase the text size, but this depends on the application and can have undesired side effects. For instance, using text zoom in a browser zooms the text but breaks the intended layout because all the non-text stuff is nearly always defined in pixels. The MacOS UI as a whole doesn't have an option for setting the text size. All of this makes resolution independence something I really look forward to.
"Hell, a lot of Apple users complain already about the MacBook Pros for everything being too tiny."
I don't believe that for a second. MBP screens are only 100 dpi and everything is big. It is the single worst problem with the MBP IMO.
sqrt(1440^2+900^2) / 15.4 = 110
As I said, I have a Powerbook which does actually have 100 DPI, which makes certain things smaller than I'd like them to be. Maybe another 10% smaller would be workable for someone who has a 10% shorter eyes-to-lap distance than me, but I'll stick with my Powerbook until resolution independence is here.
Hell, a lot of Apple users complain already about the MacBook Pros for everything being too tiny.
I can do better than that: lots of stuff is uncomfortably small on my 1280x854 Powerbook screen. Especially the web seems to be made for people with hawk-like vision, I can't believe how tiny the letters on many pages are.
I'm not too worried about Apple not exposing zoom control to users: there will be utilities that allow users to adjust their zoom settings the same day that Leopard comes out in that case.
I am a bit worried about what someone said about there only being a small number of fixed zoom factors: 1.25, 1.5, 2 and 3. I can see how having a limited number of zoom factors can make some stuff a bit easier, but the short time gain is probably not worth it in the long run, and steps of at least 25% are just not good enough. I would love being able to zoom to the equivalent of 1172 pixels wide on my 15" screen, but that's only a factor 1.09. 1.25 would be 1024 pixels wide, which is way too much. So a granularity of at least 1/8th rather than 1/4th would be much better.
But I would take a 1920x1200 screen with a 1.5 rather than a 1.625 zoom factor without complaining too much, especially if such a MacBook Pro comes with the new Santa Rosa chipset that pushes real-world battery operation past the 4 hour mark. I wonder how many l33t h4x0rs will use a 0.75 zoom factor on such a rig, though...
For most applications you gain a lot of 64 bit support just by using the proper libraries. There are very few applications out there that would need both 32 bit and 64 bit versions of their code, so that probably wouldn't add to the size of the Mac version of Firefox 2
On PowerPC you'd only want applications that actually need to do 64-bit math or address more than 2 or 3 GB of memory to be 64-bit, but for x86 it's a different story because the extra registers that are available in 64-bit mode may make applications that have no use for 64-bitness in itself a lot faster.
So I'm curious as to what developers will do. Hopefully, they'll evaluate the performance of their code and compile for 32 or 64 bits depending on which is faster. But of course you want your app to work on older Macs too, so you may need to include:
A PowerPC/no Altivec version for G3 Macs
A PowerPC+Altivec version for G4 Macs
A PowerPC 64-bit version for G5 Macs
An x86/32 version for Core 1 Macs
An x86/64 version for Core 2 Macs
18 MB may not seem so bad at some point in the future.:-)
At 7200 RPM it only takes 8.33 milliseconds for the platters to make a revolution, while at 5400 RPM this takes 11.11 ms, so the average time you have to wait before the data is under the head (half a revolution) is 1.4 ms longer. But that's not the only aspect of the access time: the heads also need to move to the right track. The smaller the distance the heads have to travel, the faster your access time. By only using 63% of a 149 GB drive you cut down on the average distance the heads have to travel, increasing your average access time. This way, a 93 GB partition on a 149 GB 5400 RPM drive can have the same average access time as a 93 GB 7200 RPM drive and you have an additional 56 GB that you can use to dump data that isn't accessed often, and you'll save yourself some power.
"Resolution independent" means that the absolute size of stuff on the screen, such as text, GUI elelements and so on, is independent of the resolution of the screen. So if you have a CRT, and you change the screen mode from, say, 1280x960 to 1600x1200, everything looks the same except that (especially) text is now sharper. The same size letter is now drawn using a larger number of smaller pixels, just like printing at 600 DPI vs 300 DPI.
RI allows two very useful things: you can increase display resolution without automatically shrinking everything that's on the screen, and you can make everything look larger on screen without artificially lowering your screen resolution, so that text and other stuff stays sharp. It is of course also possible to zoom out so that everything gets smaller and you can fit more stuff on the same screen.
Apple has said they are going to support RI in the upcoming Leopard OS release, but it's unclear how they are going to expose this functionality to the user. Ideally, it will be possible to adjust the zoom factor on a per-application basis so that it's finally possible to compensate for the strange preference for ridiculously small text that is so prevalent among web designers without breaking the intended layour of websites, as the text zoom available in current browsers does.
Re:What ever happened to high res laptop displays?
on
MacBook Pro Reviewed
·
· Score: 1
Unfortunately, most stuff in MacOS is still fixed size. So if you go from 100 dpi to 150 dpi, everything becomes 33% smaller on screen. On my 100 dpi Powerbook (MBP is 110 dpi) a lot of stuff is already on the small side: when I lean back in my chair I really can't read it properly, I have sit up straight or lean in.
Apple has been laying the ground work for resolution independent graphics, but it doesn't work too well yet and it looks like it's not going to until application writers remove pixel-based assumptions from their code. Hopefully all of this will become a reality with MacOS 10.5 so Apple can start building those 150 dpi displays without losing all their customers above the age of 25.
The light makes perfect sense: it's color A when the charger supplies power to the laptop and color B when the battery is being charged. Yes, it takes a few moments before the power manager decides to start charging the battery. What's strange or bad about that?
The only thing you might complain about is the color choices, but I'm not sure if there are other choices that would be better.
Disappointed that they apparently didn't find it necessary to dial back the sleep light intensity, though. It's bright enough to be annoying if you're sleeping in the same room on my Powerbook. If the lid is closed, at least. When the Powerbook sleeps with the lid open the brightness is much more reasonable. (I do like the fact that it sometimes freaks out the security scanner operators, though.)
"And as working with addresses exclusively isn't unlike cruel and unusual punishment, an IPv6 hosts must either also run IPv4 and discover IPv4 DNS addresses through DHCP(v4), or the IPv6 DNS addresses must be configured manually."
(Didn't catch "an IPv6 hosts" before publication... Sigh.)
People tend to forget that you can still do much of the same outgoing load balancing with shim6 as today without it, barring ingress filtering by ISPs. Incoming load balancing is a big problem today, though. Shim6 should provide hooks for new ways to do both, so there will be a learning curve. But I don't see any fundamental problems. Personally, I'd really like to see support for "proxy multihoming" boxes that take care of shim (and thus traffic engineering) processing, but we'll have to see if that's doable.
Geographical aggregation only works if you connect to your ISPs in the same region, where the size of the region isn't necessarily specified. If you have ISPs in New Hampshire, Cape Town and Tokyo, that's going to be a problem, yes. But for someone in Europe or Australia New York and Los Angeles may indeed be aggregated together. But most people connect to ISPs that are much closer together. The issue of geographically dispersed organization is an interesting one. These days, it's not very cost effective to carry traffic to/from the internet over your internal network. This means that having one big address block for the entire organization isn't what most organizations want anyway. Or if they want it, they also want to break up that block in smaller pieces and use the various pieces mostly independent in different locations. That is of course not compatible with keeping the routing tables to a workable size. So if we remove that option, what's left is separate geo PI blocks for each office, or one big block for the entire organization. I'm confident that there aren't enough of these large organizations that act as ISPs for their own offices to make giving them a non-geo block problematic.
As for incentives: I don't think any of the improvements in IPv6 are big enough incentives to get a decent fraction of the internet populace on the new protocol. It will have to come down to IPv4 address depletion. We're burning address space fast the past couple of years: ~90 million in 2003, ~130M in 2004 and ~165M in 2005. With 1460M to go we may run out as soon as 2009 if the upward trend continues, 2012 if we stabilize around ~165M/yr or later if last year was an exception. (See http://www.bgpexpert.com/addrspace2005.php for more figures.)
I don't think I used the word "torture" in any IPv6 discussion. When I search for "torture" locally, all I find are references to some IETF SIP draft... So you probably got me confused with someone else.
It's indeed unfortunate that it has taken the IETF a very long time to address DNS resolver discovery. (Something is in the works now, though.) However, this doesn't mean that people are prompted to use DHCPv6, for the very simple reason that that didn't exist until not-too-long-ago either and isn't available in many IPv6-capable OSes today. But the fact that people tend to run IPv4 and IPv6 side by side hides a multitude of sins. In this case, they do DNS lookups over IPv4 using a DHCPv4-derived server. Only those who run IPv6-only have to make do with manual configuration of DNS addresses or mostly experimental DHCPv6 implementations.
The trouble with multihoming in IPv6 is that the way it's done currently in IPv4 doesn't scale to large numbers of multihomers. Some people say we'll never see such numbers but we'll be running IPv6 for a long time so that would be a very dangerous risk to take, as the results of having too many multihomers would be very bad. Using access to an AS number as the limiting factor isn't going to work now that AS numbers are going to be 32 bits long so this isn't a solution.
The IETF shim6 wg is working on mechanisms that allow hosts to switch running sessions from one address to another, thereby removing the multihoming burden from the routing system. However, this doesn't give you a portable address block, which is something people really want regardless of multihoming. So there is a lot of pressure to allow IPv4-style multihoming in IPv6 as well. My position on this is that to address this need (well, it's really not a need, you can always renumber) we should use geographically aggregatable provider independent address blocks for multihoming in IPv6 in places where shim6 is suboptimal. This allows us to remove a very large amount of information from the routing system when routing aligns with geography, which isn't universally the case but it's good enough to make everything scale one or two more orders of magnitude "for free". But the world apparently isn't ready for this.
As for the complexity in IPv6: that's all in the eye of the beholder. IPv4 is also quite complex if you look at the way it's used today rather than how it was specified 25 years ago. (PMTUD blackhole detection anyone?) The main difference between IPv4 and IPv6 that makes IPv6 more complex is neighbor discovery that replaces ARP. ND does everything that ARP does much better and does much more, so in this case the extra complexity is really worth it. And just wait until you can build an IPv6-only network. Those are so much cleaner than the convoluted IPv4 setups that are necessitated by address conservation and/or NAT.
Where exactly did I say that autoconfiguration is broken?
I'm not saying it's perfect but I use it every day and haven't had any trouble with it in a long time. (I did when I ran Zebra on my Mac a while ago - don't ask.)
The IETF is actually working on a new way to multihome in IPv6 that works for everyone (enterprises, end-users) rather than just those than have a portable address block and run BGP.
Two other things that were brought up earlier:
Last time I checked Cisco routers didn't do IPv6 NAT, but only NAT-PT. Sounds like the same thing, but it isn't: with NAT-PT IPv6 hosts can talk to IPv4 servers through an address translation device, it doesn't apply to IPv6-IPv6 interactions.
Even with NAT in full effect we used up 10/8s (~167 million IPv4 addresses) in 2005 with 62 free/8s held by IANA and another 25/8s worth of unused space available elsewhere.
Slashdot Mirror
Ugh... What part of the world are you people from???
These are European prices, so they include VAT. That would be something like 15 - 20 % (differs per country even though consumer prices are 99 cents in the euro countries AFAIK).
Don't know what that means for the Apple/label split, but Apple has to pay for bandwidth (cheap), servers (not quite as cheap) and credit card processing. Just the latter is probably more than what artists get from the labels.
In my opinion, buying movies online makes little sense. The trouble is, when you buy online you need to provide the storage yourself. I don't have that many DVDs, but I'd still have to invest in some serious storage to put all that stuff on harddisks. And then back it up, move it to newer bigger disks every few years... This is a huge headache. With CDs, it's different, because one CD only needs about 1/20th of the disk space that the contents of a DVD does. And when you want to listen to a 4 minute song, spending 2 minutes to find the CD is problematic, so it makes sense to store your music on your computer. 2 minutes to find a DVD and then watch it for 2 hours isn't a problem at all so there isn't much of a case for doing the same here.
I think buying online will mostly be popular with people with small kids, who like to watch the same stuff over and over again and tend to wreak havoc on physical media, and for people who will treat the service mostly like a rental service and don't care about the price difference.
Downloading rentals rather than buying movies online makes much more sense: you get your stuff faster but you don't have worry about permanent storage. The DRM and slightly lower quality are much less of an issue.
I run my 17" CRT (= 15.5" viewable area) at 1172 pixels wide, and I'd love to have that as the native resolution for my Powerbook as well, making for 90 DPI.
We are pretty much saying the exact same thing, except that you want it in order to make stuff on the screen smaller, while I want it to make stuff on the screen bigger. We both don't like the hardcoded-for-100-DPI way that things work today.
I'm not quite as negative about Apple as you, though: it looks like they're getting their act together. It would have been better if they'd done that one or two releases ago, but I'm in the market for a new laptop between now and six months from now so it all works out.
Apple had a page up talking about how 100 DPI is the ideal resolution (can't find the page right now, I think they took it down). I'm not buying that: it's a limitation of their software that everything running on a Mac thinks the whole universe is 72 DPI and you can't even change the system font size (even my first Amiga that I had half a lifetime ago could do this). But given that situation, I agree with their decision to stay away from really high resolutions.
Sad but true, although changing the default in Windows XP isn't entirely problem free. Hopefully this type of discussion will be history after the introduction of Leopard and a slew of ultra-high resolution Apple laptops. In the mean time, I suggest that you consider the possibility that just like computers, people have widely different hard- and software attributes so what works for you doesn't necessarily work for everyone else.In many applications, there are ways to increase the text size, but this depends on the application and can have undesired side effects. For instance, using text zoom in a browser zooms the text but breaks the intended layout because all the non-text stuff is nearly always defined in pixels. The MacOS UI as a whole doesn't have an option for setting the text size. All of this makes resolution independence something I really look forward to.
sqrt(1440^2+900^2) / 15.4 = 110
As I said, I have a Powerbook which does actually have 100 DPI, which makes certain things smaller than I'd like them to be. Maybe another 10% smaller would be workable for someone who has a 10% shorter eyes-to-lap distance than me, but I'll stick with my Powerbook until resolution independence is here.
I can do better than that: lots of stuff is uncomfortably small on my 1280x854 Powerbook screen. Especially the web seems to be made for people with hawk-like vision, I can't believe how tiny the letters on many pages are.
I'm not too worried about Apple not exposing zoom control to users: there will be utilities that allow users to adjust their zoom settings the same day that Leopard comes out in that case.
I am a bit worried about what someone said about there only being a small number of fixed zoom factors: 1.25, 1.5, 2 and 3. I can see how having a limited number of zoom factors can make some stuff a bit easier, but the short time gain is probably not worth it in the long run, and steps of at least 25% are just not good enough. I would love being able to zoom to the equivalent of 1172 pixels wide on my 15" screen, but that's only a factor 1.09. 1.25 would be 1024 pixels wide, which is way too much. So a granularity of at least 1/8th rather than 1/4th would be much better.
But I would take a 1920x1200 screen with a 1.5 rather than a 1.625 zoom factor without complaining too much, especially if such a MacBook Pro comes with the new Santa Rosa chipset that pushes real-world battery operation past the 4 hour mark. I wonder how many l33t h4x0rs will use a 0.75 zoom factor on such a rig, though...
On PowerPC you'd only want applications that actually need to do 64-bit math or address more than 2 or 3 GB of memory to be 64-bit, but for x86 it's a different story because the extra registers that are available in 64-bit mode may make applications that have no use for 64-bitness in itself a lot faster.
So I'm curious as to what developers will do. Hopefully, they'll evaluate the performance of their code and compile for 32 or 64 bits depending on which is faster. But of course you want your app to work on older Macs too, so you may need to include:
18 MB may not seem so bad at some point in the future. :-)
At 7200 RPM it only takes 8.33 milliseconds for the platters to make a revolution, while at 5400 RPM this takes 11.11 ms, so the average time you have to wait before the data is under the head (half a revolution) is 1.4 ms longer. But that's not the only aspect of the access time: the heads also need to move to the right track. The smaller the distance the heads have to travel, the faster your access time. By only using 63% of a 149 GB drive you cut down on the average distance the heads have to travel, increasing your average access time. This way, a 93 GB partition on a 149 GB 5400 RPM drive can have the same average access time as a 93 GB 7200 RPM drive and you have an additional 56 GB that you can use to dump data that isn't accessed often, and you'll save yourself some power.
"Resolution independent" means that the absolute size of stuff on the screen, such as text, GUI elelements and so on, is independent of the resolution of the screen. So if you have a CRT, and you change the screen mode from, say, 1280x960 to 1600x1200, everything looks the same except that (especially) text is now sharper. The same size letter is now drawn using a larger number of smaller pixels, just like printing at 600 DPI vs 300 DPI. RI allows two very useful things: you can increase display resolution without automatically shrinking everything that's on the screen, and you can make everything look larger on screen without artificially lowering your screen resolution, so that text and other stuff stays sharp. It is of course also possible to zoom out so that everything gets smaller and you can fit more stuff on the same screen. Apple has said they are going to support RI in the upcoming Leopard OS release, but it's unclear how they are going to expose this functionality to the user. Ideally, it will be possible to adjust the zoom factor on a per-application basis so that it's finally possible to compensate for the strange preference for ridiculously small text that is so prevalent among web designers without breaking the intended layour of websites, as the text zoom available in current browsers does.
Unfortunately, most stuff in MacOS is still fixed size. So if you go from 100 dpi to 150 dpi, everything becomes 33% smaller on screen. On my 100 dpi Powerbook (MBP is 110 dpi) a lot of stuff is already on the small side: when I lean back in my chair I really can't read it properly, I have sit up straight or lean in. Apple has been laying the ground work for resolution independent graphics, but it doesn't work too well yet and it looks like it's not going to until application writers remove pixel-based assumptions from their code. Hopefully all of this will become a reality with MacOS 10.5 so Apple can start building those 150 dpi displays without losing all their customers above the age of 25.
The light makes perfect sense: it's color A when the charger supplies power to the laptop and color B when the battery is being charged. Yes, it takes a few moments before the power manager decides to start charging the battery. What's strange or bad about that? The only thing you might complain about is the color choices, but I'm not sure if there are other choices that would be better. Disappointed that they apparently didn't find it necessary to dial back the sleep light intensity, though. It's bright enough to be annoying if you're sleeping in the same room on my Powerbook. If the lid is closed, at least. When the Powerbook sleeps with the lid open the brightness is much more reasonable. (I do like the fact that it sometimes freaks out the security scanner operators, though.)
(Didn't catch "an IPv6 hosts" before publication... Sigh.)
People tend to forget that you can still do much of the same outgoing load balancing with shim6 as today without it, barring ingress filtering by ISPs. Incoming load balancing is a big problem today, though. Shim6 should provide hooks for new ways to do both, so there will be a learning curve. But I don't see any fundamental problems. Personally, I'd really like to see support for "proxy multihoming" boxes that take care of shim (and thus traffic engineering) processing, but we'll have to see if that's doable.
Geographical aggregation only works if you connect to your ISPs in the same region, where the size of the region isn't necessarily specified. If you have ISPs in New Hampshire, Cape Town and Tokyo, that's going to be a problem, yes. But for someone in Europe or Australia New York and Los Angeles may indeed be aggregated together. But most people connect to ISPs that are much closer together. The issue of geographically dispersed organization is an interesting one. These days, it's not very cost effective to carry traffic to/from the internet over your internal network. This means that having one big address block for the entire organization isn't what most organizations want anyway. Or if they want it, they also want to break up that block in smaller pieces and use the various pieces mostly independent in different locations. That is of course not compatible with keeping the routing tables to a workable size. So if we remove that option, what's left is separate geo PI blocks for each office, or one big block for the entire organization. I'm confident that there aren't enough of these large organizations that act as ISPs for their own offices to make giving them a non-geo block problematic.
As for incentives: I don't think any of the improvements in IPv6 are big enough incentives to get a decent fraction of the internet populace on the new protocol. It will have to come down to IPv4 address depletion. We're burning address space fast the past couple of years: ~90 million in 2003, ~130M in 2004 and ~165M in 2005. With 1460M to go we may run out as soon as 2009 if the upward trend continues, 2012 if we stabilize around ~165M/yr or later if last year was an exception. (See http://www.bgpexpert.com/addrspace2005.php for more figures.)
It's indeed unfortunate that it has taken the IETF a very long time to address DNS resolver discovery. (Something is in the works now, though.) However, this doesn't mean that people are prompted to use DHCPv6, for the very simple reason that that didn't exist until not-too-long-ago either and isn't available in many IPv6-capable OSes today. But the fact that people tend to run IPv4 and IPv6 side by side hides a multitude of sins. In this case, they do DNS lookups over IPv4 using a DHCPv4-derived server. Only those who run IPv6-only have to make do with manual configuration of DNS addresses or mostly experimental DHCPv6 implementations.
The trouble with multihoming in IPv6 is that the way it's done currently in IPv4 doesn't scale to large numbers of multihomers. Some people say we'll never see such numbers but we'll be running IPv6 for a long time so that would be a very dangerous risk to take, as the results of having too many multihomers would be very bad. Using access to an AS number as the limiting factor isn't going to work now that AS numbers are going to be 32 bits long so this isn't a solution.
The IETF shim6 wg is working on mechanisms that allow hosts to switch running sessions from one address to another, thereby removing the multihoming burden from the routing system. However, this doesn't give you a portable address block, which is something people really want regardless of multihoming. So there is a lot of pressure to allow IPv4-style multihoming in IPv6 as well. My position on this is that to address this need (well, it's really not a need, you can always renumber) we should use geographically aggregatable provider independent address blocks for multihoming in IPv6 in places where shim6 is suboptimal. This allows us to remove a very large amount of information from the routing system when routing aligns with geography, which isn't universally the case but it's good enough to make everything scale one or two more orders of magnitude "for free". But the world apparently isn't ready for this.
As for the complexity in IPv6: that's all in the eye of the beholder. IPv4 is also quite complex if you look at the way it's used today rather than how it was specified 25 years ago. (PMTUD blackhole detection anyone?) The main difference between IPv4 and IPv6 that makes IPv6 more complex is neighbor discovery that replaces ARP. ND does everything that ARP does much better and does much more, so in this case the extra complexity is really worth it. And just wait until you can build an IPv6-only network. Those are so much cleaner than the convoluted IPv4 setups that are necessitated by address conservation and/or NAT.
Where exactly did I say that autoconfiguration is broken?
/8s (~167 million IPv4 addresses) in 2005 with 62 free /8s held by IANA and another 25 /8s worth of unused space available elsewhere.
I'm not saying it's perfect but I use it every day and haven't had any trouble with it in a long time. (I did when I ran Zebra on my Mac a while ago - don't ask.)
The IETF is actually working on a new way to multihome in IPv6 that works for everyone (enterprises, end-users) rather than just those than have a portable address block and run BGP.
Two other things that were brought up earlier:
Last time I checked Cisco routers didn't do IPv6 NAT, but only NAT-PT. Sounds like the same thing, but it isn't: with NAT-PT IPv6 hosts can talk to IPv4 servers through an address translation device, it doesn't apply to IPv6-IPv6 interactions.
Even with NAT in full effect we used up 10