Yet you don't seem to understand privacy extensions, which confound logging by generating lots of useless addresses rather than by trying to hide them all.
NAT breaks stuff. Its benefits are available other ways, so there's no need to put up with its downsides anymore. The world will be better off not having to deal with it everywhere.
Although ULA does exist... it's actually not very relevant for most people. Generally you want to be able to connect to anywhere on the internet, and to do that you use global addresses.
The thing the GP really wants is a firewall. If he doesn't want people on the internet connecting to his systems, all he has to do is say so. Firewalls have been around for a while and work just fine in IPv6; this is a solved problem.
Indeed, I was assuming privacy addressing was turned on. This is the default in Windows XP/Vista/7/8, so it's not an unreasonable assumption. It's still off by default in Linux, although that's nothing a sysctl or two won't solve.
Smart phones, tablets etc could be pretty much taken care of if Android, iOS and Windows Mobile enable privacy extensions by default. I'm not sure what they actually do at the moment; I think they default to off with a few isolated devices that have it turned on.
Why wouldn't they? ISPs get blocks in the/20 to/32 range, and end-users get/48s. That's plenty enough bits to do routing with, for both the ISP and for the end-user.
A/60 isn't generous, it's downright stingy. Not quite as bad as the ISPs that only give a single/64 (or the ones that fail to understand routing and don't give you anything at all), but there's plenty of space to give everyone/48s. Why go smaller? Especially all the way down to/96; you'd end up breaking SLAAC and subnetting for your users for no gain whatsoever.
Any argument revolving around what most people understand or need is silly in IPv6. Some people will need it or understand what to do with it, and the address space is large enough to allocate the same large block size to everyone, including the people who won't use it. What advantage is there in not doing that?
Every device gets an address, but that address is not a GUID. The address is different if you go to a different network. The address changes every day. It's not useful for tracking you, at least no more so than your v4 address was.
No. And that's not the point of mining anyway. The point of mining is to secure the network; any profit made from it is just the incentive. If your own electricity costs too much for there to be any incentive for you, then just buy the bitcoins outright, since doing that will be cheaper.
Do you also come out richer every time you buy something using Paypal?
In 3.6, I have three extensions installed to revert to old behaviour. In Nightly, I have fifteen, plus a ton of CSS in Stylish that I've written just to get the UI to match with the "Windows Classic" style I use in Windows.
Installing that many extensions is a chore. Worse, it wasn't just a matter of installing them and being happy: I had to write over half of them myself. I have to keep hunting down or writing new ones as stuff keeps changing in the browser (like the hiding of the forward button, the removing of the address bar favicon, the home tab...)
The hint is in its new name: "Add-on bar". I have icons for Stylesheet Chooser Plus, Textarea Cache, Adblock Plus, Greasemonkey, Screengrab, Stylish, Tabhunter, Yesscript, CipherFox, and Ghostery in there.
Now, yes, I could get rid of some of these. But others I actually use, and if I hid the status bar, where would I put them? So I don't.
The dumb bit comes in when the status bar isn't hidden: the mouseover link display continues to show in that tooltip, which is rendered above the big blank gap in the status bar where it used to be shown. This makes no sense to me. It takes up more space and it's irritating; why would I possibly want it? Yet someone at Mozilla has decided that it's being moved there and I'm going to like it.
I feel this is part of the reason we're losing so many users to Chrome; between the statusbar, tabs-on-top and in the titlebar, no menu bar, the removal of all color from the toolbars, putting the update checker in the About dialog, showing non-canonicalized URLs, and in-content UI, most of the things that annoy me about Chrome have come to Firefox. Since I'm going to dislike the UI anyway, why wouldn't I just move to Chrome, where I can dislike it faster?
And no: for those of us left, we can't just shut up and move on either. The UI is still sucking, and being quiet about it just paves the way for more suckage (see for instance the tabs-on-top in Thunderbird, which has no option to turn it off -- expect that to arrive in Firefox the next time they do a major change to the theme.)
In my eyes, this makes the GPL less free than similar licenses that allow for proprietary development (like MPL and MIT).
The GPL is designed to enforce the user's access to the "four essential freedoms": the ability to use the software, to examine and modify it, and to give it to other people.
If you're going to take the selfish view of only considering what you yourself can do with the code, then yeah: the GPL prevents you from preventing other people from getting those freedoms.
It doesn't have low rights mode like chrome and IE
True.
Its crazy release schedule means zero testing before deployment
Well, other than the six weeks it's in "Beta" (i.e. release candidate) where the intent is to make no changes, and the six weeks it's in "Aurora" (i.e. beta), where only bug fixes are made. And the extra twelve weeks it's in certify/deploy state in the ESR proposal. But other than that.
extensions were breaking everywhere
Extensions rarely break with the new "major releases are now minor releases" model. As of Fx10, it will even stop claiming they're broken too.
and the final straw was that XSS bug that allowed malware writers to spam yahoo mail accounts from FF... With low rights mode its damned near impossible to pull crap like that
OK, I'm not sure which bug you're referring to, but generally running the browser in a low-rights mode doesn't prevent XSS bugs, because XSS bugs happen inside the browser itself.
that requires admin rights to install
Wait, install? You said "update" earlier. But OK... I believe it installs fine as a non-admin user if you opt to install it to a directory the user has write permission to, which is what Chrome does by default. Firefox Portable certainly works fine as a non-admin user (updates included!), and that's just a wrapper around a vanilla Firefox.
and isn't easy at all to set up GPOs that can't be trivially bypassed by the user
True, as far as I know. Though if you're allowing the browser to be installed without admin rights, the user could presumably just overwrite it with a version that doesn't obey GPOs, so either this applies to Chrome too or you in fact don't actually want non-admin users to be able to install the browser.
I dislike the new release schedule as much as the next guy, but I'd prefer it if you disliked it for reasons that were true, or at least not getting fixed before 3.6's EoL.
Vista, and the very similar 7 are what's keeping me on XP: I dislike the UI changes they made for Vista, and didn't unmake for 7. Windows 8 is just going further down this road, and so is unlikely to make me change my mind either.
The remaining upgrade path is to Linux, but I tried that out for a couple of weeks. Turns out X.org can't do hardware acceleration on a multi-GPU multiple monitor setup unless you also want to sacrifice the ability to drag windows between monitors. Which I don't.
(I also had issues with menus rendering in the wrong place -- at least one UI toolkit would position menu popups aligned with the top of my smallest monitor, leaving a several-inch gap between the menubar and the popup depending on where the parent window was positioned. Windows gets this right...)
So in summary, if I want a desktop with 2D acceleration and a UI I don't hate... I only really have one choice.
This particular behaviour at least is configurable: set image.mem.discardable to false. (Or, if you decide you prefer a trade-off, lengthen image.mem.min_discard_timeout_ms.)
Unfortunately I don't believe it's possible to do that in a distributed system. The only way to fix the price against the dollar would be for someone to buy and sell bitcoins for a guaranteed fixed price, and to do that they'd need to be in a position to mint new coins (since they'd need an infinite supply); this is exactly the situation we're trying to avoid.
(It's not like this would completely eliminate the problem either: most of the rest of the world uses currencies that aren't fixed against the dollar. This "no guarantee that $50 will be worth the same tomorrow" thing is something the rest of us live with all the time.)
There are ways to mitigate the volatility. Rather than trying to store wealth in bitcoins for extended periods of time (which exposes you to changes in the exchange rate, be they good or bad), instead use it as a means of making payments. Buyers would buy coins only when they need to pay someone, and merchants would sell the coins after receiving them. If merchants perceive a risk of bitcoins dropping in value between setting the price and being able to sell the coins, then they can charge slightly extra to cover the perceived risk. (For symmetry, they should also charge slightly less if they believe the exchange rate will go up instead of down, but I bet most would quite happily take that as free profit.)
I do definitely agree this is a problem for Bitcoin. But it is possible to manage the risk, and that risk gets lower the more people use bitcoins. I don't think it's a show-stopper.
That's half of the problem, but how do you verify that the money held by the wallet service is valid? Anybody could set up a service, claim they have $50 and then spend it. You'd have to vet each wallet provider to make sure they could be trusted before you accept money from them. Imagine trying to handle your own wallet, and then getting Paypal to take you at face value on how much is in it: that's just not going to happen.
What they'd do is ask you to transfer funds from a wallet hosted by a credit card provider or a bank. With just an open API, you could pay people on other services (an improvement over the current situation), but the overall system would still be centrally controlled by the few players big enough to operate in it. To remove that central control, you need a distributed mechanism for making sure that people don't lie about how much money they have.
That's what Bitcoin is. It's a distributed, cryptographically-secure ledger for keeping track of who has how much money, and a way to transfer that money around.
Sorry, but nobody, apart from researchers, and those who want to check it out just for the novelty are going to use bitcoin as a currency.
On their own computers.
It's a bit like running an email server: they're big, complicated bits of software that require a ton of configuration, and you need to spend time keeping it up to date and keeping an eye out for any relevant security advisories. You also have to make sure to back up your mail daily -- preferably offsite too, in case your house burns down -- lest you lose all of it. This is beyond the ability of most people.
And yet plenty of people use e-mail! The beauty of e-mail is that it's possible for anybody to run a server, and yet still send messages to anybody using any other server. This is what Bitcoin is intended to do with payment systems.
Bitcoin makes it possible, if you wish, to make payments directly yourself, on your own systems and under your own control. (Of course, if you do this, you also take on the responsibility of doing it right.) Alternately, you can use wallet services provided by another entity of your choosing -- which can be anyone, since anyone has the ability to make and receive Bitcoin payments. There is no provider lockdown here.
Of course, I will admit we've now hit the real issue: it's hard to find someone you trust to host your wallet. This is similar to the situation with webmail, except with webmail you only give over access to most of your online accounts and the entire contents of every conversation you have with anybody over e-mail; with a Bitcoin wallet provider you'd be giving them access to the $50 you store in the wallet.
But this isn't a Bitcoin issue, it's a human/trust issue. People trust companies on the web all the time; I don't think this is insurmountable.
(Heck, it's not like you even have to leave the $50 in the wallet -- many people make use of Paypal without ever maintaining a balance in their account, often precisely because they don't trust Paypal with their money. The difference with Paypal is that you don't have the option to take your custom elsewhere, since the only way to pay Paypal users is via Paypal itself.)
I agree that, going by number of hosts, 64 bits for the interface ID is excessive. There are other reasons to want more than 32 bits though: a 32-bit subnet with 50,000 hosts using privacy addresses would have 400,000 addresses in use at any one time, and would get on average 5 address collisions every time the hosts generate themselves a new address -- even though 99.98% of the addresses on the network are unused. It's feasible to argue that a network that regularly sees collisions is one that's too small.
But more importantly, I'm just not convinced that allocation needs to be any better. I feel that reaching even the HD=80% point of 10/48s per person in 2000::/3 is going to be difficult, and as such even the current 48:16:64 split will leave us with plenty of space. Finally, if 2000::/3 does fill up, we can switch to 4000::/3 using 64:16:48 or your 64:32:32 without any hassle, so there's definitely no need to make any changes to the allocation policies in 2000::/3.
You're right, and I omitted that consideration from my post. (You're misunderstanding the allocations though -- APNIC have 2001:0400::/23, which is 2001:0400:0000:: through to 2001:05ff:ffff::. They also have 2400::/12, which is 2400:0000:0000:: though to 240f:ffff:ffff::. Also, if you look at the list of allocations, they've obviously been left the whole of 2400:0000:0000: up until 25ff:ffff:ffff:: to expand into. Even the smaller/23 block has room for more than 65,536 corporations, let alone the/7 reserved block.)
The allocations are being done sparsely like this in the interest of route aggregation. The idea is to issue an ISP a/32, for example, but then skip the next 7/32s. This means that the ISP can expand right up to a/29 while continuing to take up only a single routing table entry. If you want to put a negative spin on it, you could claim that this is only "12.5% efficient", or that it "wastes 87.5% of addresses", but this is not true: the gaps are being used to minimize routing table fragmentation.
How does this affect my assessment? RFC 3194 is required reading here. It defines the "H-density ratio", as a means of measuring how painful address allocation is becoming in a network with a hierarchical structure. Even if we take the low-end 80% used in that RFC, that would still be 70 billion/48s, or 10 per person on the planet. It's reasonable to expect some people to admin more than 10 networks and thus need more than 10/48s, but I feel that it's unreasonable to expect that to be true of every single person on the planet.
For comparison, it looks like IPv4 passed its HD ratio of 80% (51 M hosts) in about 2000 or so. Clearly a network can continue operating beyond 80% if necessary; it just means that you have to start sacrificing route aggregation for a higher allocation percentage.
(Once again, I did these calculations for the 45-bit space in 2000::/3. The "we can start over in one of the other five/3s" argument is just as valid here too.)
I think you might not have quite gotten your head around just how much bigger 2^128 is compared to 2^32.
There are 5000/48s per person on the planet -- out of 2000::/3 alone. (Remember that a single/48 has 80 bits of addresses in it. You could take the 2^32 addresses in IPv4, copy them 2^32 times and still only use 1/65536th of the space in a/48.)
If we do somehow manage to allocate the entire of 2000::/3, there are an additional five completely unused/3 blocks available, in which we can simply start over with tighter allocation policies.
# ip addr add 127.0.0.2/8 dev lo # ip addr show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN inet 127.0.0.1/8 scope host lo inet 127.0.0.2/8 scope host lo inet6::1/128 scope host valid_lft forever preferred_lft forever
ifconfig can't handle displaying them, but if you will insist on using an obsolete piece of software, don't complain when you bump into its limitations.
So then the answer is "yes". The "I refuse to adapt to change" crowd gets a new poster boy.
I feel that a lot of the changes are outright bad (like moving the link hover URL display from the status bar to a tooltip -- which displays just above the now-empty big blank space in the status bar. How does that make any sense?). These are the changes I refuse to adapt to.
Do you think you'll still be using Firefox 3.6 in 10 years? If not, then what's stopping you from upgrading now? Would it be easier to adapt going from XP to Vista to Win7 to Win8, or from XP straight to Win8?
The great thing about Firefox is that it's open-source and its interface is easily malleable; I'll upgrade off of 3.6 just as soon as I've finished fixing all the things that irritate me in "Firefox Vista". In a similar vein, I don't expect to move to Windows 8 at all. If things get bad enough on XP that I'm forced to upgrade, it will probably be to Linux, where I have control over my UI.
Slashdot Mirror
Yet you don't seem to understand privacy extensions, which confound logging by generating lots of useless addresses rather than by trying to hide them all.
NAT breaks stuff. Its benefits are available other ways, so there's no need to put up with its downsides anymore. The world will be better off not having to deal with it everywhere.
Although ULA does exist... it's actually not very relevant for most people. Generally you want to be able to connect to anywhere on the internet, and to do that you use global addresses.
The thing the GP really wants is a firewall. If he doesn't want people on the internet connecting to his systems, all he has to do is say so. Firewalls have been around for a while and work just fine in IPv6; this is a solved problem.
Indeed, I was assuming privacy addressing was turned on. This is the default in Windows XP/Vista/7/8, so it's not an unreasonable assumption. It's still off by default in Linux, although that's nothing a sysctl or two won't solve.
Smart phones, tablets etc could be pretty much taken care of if Android, iOS and Windows Mobile enable privacy extensions by default. I'm not sure what they actually do at the moment; I think they default to off with a few isolated devices that have it turned on.
Why wouldn't they? ISPs get blocks in the /20 to /32 range, and end-users get /48s. That's plenty enough bits to do routing with, for both the ISP and for the end-user.
A /60 isn't generous, it's downright stingy. Not quite as bad as the ISPs that only give a single /64 (or the ones that fail to understand routing and don't give you anything at all), but there's plenty of space to give everyone /48s. Why go smaller? Especially all the way down to /96; you'd end up breaking SLAAC and subnetting for your users for no gain whatsoever.
Any argument revolving around what most people understand or need is silly in IPv6. Some people will need it or understand what to do with it, and the address space is large enough to allocate the same large block size to everyone, including the people who won't use it. What advantage is there in not doing that?
Every device gets an address, but that address is not a GUID. The address is different if you go to a different network. The address changes every day. It's not useful for tracking you, at least no more so than your v4 address was.
Not much to discuss here.
No. And that's not the point of mining anyway. The point of mining is to secure the network; any profit made from it is just the incentive. If your own electricity costs too much for there to be any incentive for you, then just buy the bitcoins outright, since doing that will be cheaper.
Do you also come out richer every time you buy something using Paypal?
Thanks for completely misunderstanding Bitcoin.
In 3.6, I have three extensions installed to revert to old behaviour. In Nightly, I have fifteen, plus a ton of CSS in Stylish that I've written just to get the UI to match with the "Windows Classic" style I use in Windows.
Installing that many extensions is a chore. Worse, it wasn't just a matter of installing them and being happy: I had to write over half of them myself. I have to keep hunting down or writing new ones as stuff keeps changing in the browser (like the hiding of the forward button, the removing of the address bar favicon, the home tab...)
This is why it's a big deal to me.
The hint is in its new name: "Add-on bar". I have icons for Stylesheet Chooser Plus, Textarea Cache, Adblock Plus, Greasemonkey, Screengrab, Stylish, Tabhunter, Yesscript, CipherFox, and Ghostery in there.
Now, yes, I could get rid of some of these. But others I actually use, and if I hid the status bar, where would I put them? So I don't.
The dumb bit comes in when the status bar isn't hidden: the mouseover link display continues to show in that tooltip, which is rendered above the big blank gap in the status bar where it used to be shown. This makes no sense to me. It takes up more space and it's irritating; why would I possibly want it? Yet someone at Mozilla has decided that it's being moved there and I'm going to like it.
I feel this is part of the reason we're losing so many users to Chrome; between the statusbar, tabs-on-top and in the titlebar, no menu bar, the removal of all color from the toolbars, putting the update checker in the About dialog, showing non-canonicalized URLs, and in-content UI, most of the things that annoy me about Chrome have come to Firefox. Since I'm going to dislike the UI anyway, why wouldn't I just move to Chrome, where I can dislike it faster?
And no: for those of us left, we can't just shut up and move on either. The UI is still sucking, and being quiet about it just paves the way for more suckage (see for instance the tabs-on-top in Thunderbird, which has no option to turn it off -- expect that to arrive in Firefox the next time they do a major change to the theme.)
For example, with IPv6, there isn't really provider independent address space.
Uh.
Yes there is. See for example this and this/this.
In my eyes, this makes the GPL less free than similar licenses that allow for proprietary development (like MPL and MIT).
The GPL is designed to enforce the user's access to the "four essential freedoms": the ability to use the software, to examine and modify it, and to give it to other people.
If you're going to take the selfish view of only considering what you yourself can do with the code, then yeah: the GPL prevents you from preventing other people from getting those freedoms.
Some of us think that's a good thing.
Firefox has to run as admin to update
True for now.
It doesn't have low rights mode like chrome and IE
True.
Its crazy release schedule means zero testing before deployment
Well, other than the six weeks it's in "Beta" (i.e. release candidate) where the intent is to make no changes, and the six weeks it's in "Aurora" (i.e. beta), where only bug fixes are made. And the extra twelve weeks it's in certify/deploy state in the ESR proposal. But other than that.
extensions were breaking everywhere
Extensions rarely break with the new "major releases are now minor releases" model. As of Fx10, it will even stop claiming they're broken too.
and the final straw was that XSS bug that allowed malware writers to spam yahoo mail accounts from FF ... With low rights mode its damned near impossible to pull crap like that
OK, I'm not sure which bug you're referring to, but generally running the browser in a low-rights mode doesn't prevent XSS bugs, because XSS bugs happen inside the browser itself.
that requires admin rights to install
Wait, install? You said "update" earlier. But OK... I believe it installs fine as a non-admin user if you opt to install it to a directory the user has write permission to, which is what Chrome does by default. Firefox Portable certainly works fine as a non-admin user (updates included!), and that's just a wrapper around a vanilla Firefox.
and isn't easy at all to set up GPOs that can't be trivially bypassed by the user
True, as far as I know. Though if you're allowing the browser to be installed without admin rights, the user could presumably just overwrite it with a version that doesn't obey GPOs, so either this applies to Chrome too or you in fact don't actually want non-admin users to be able to install the browser.
I dislike the new release schedule as much as the next guy, but I'd prefer it if you disliked it for reasons that were true, or at least not getting fixed before 3.6's EoL.
Vista, and the very similar 7 are what's keeping me on XP: I dislike the UI changes they made for Vista, and didn't unmake for 7. Windows 8 is just going further down this road, and so is unlikely to make me change my mind either.
The remaining upgrade path is to Linux, but I tried that out for a couple of weeks. Turns out X.org can't do hardware acceleration on a multi-GPU multiple monitor setup unless you also want to sacrifice the ability to drag windows between monitors. Which I don't.
(I also had issues with menus rendering in the wrong place -- at least one UI toolkit would position menu popups aligned with the top of my smallest monitor, leaving a several-inch gap between the menubar and the popup depending on where the parent window was positioned. Windows gets this right...)
So in summary, if I want a desktop with 2D acceleration and a UI I don't hate... I only really have one choice.
This particular behaviour at least is configurable: set image.mem.discardable to false. (Or, if you decide you prefer a trade-off, lengthen image.mem.min_discard_timeout_ms.)
Unfortunately I don't believe it's possible to do that in a distributed system. The only way to fix the price against the dollar would be for someone to buy and sell bitcoins for a guaranteed fixed price, and to do that they'd need to be in a position to mint new coins (since they'd need an infinite supply); this is exactly the situation we're trying to avoid.
(It's not like this would completely eliminate the problem either: most of the rest of the world uses currencies that aren't fixed against the dollar. This "no guarantee that $50 will be worth the same tomorrow" thing is something the rest of us live with all the time.)
There are ways to mitigate the volatility. Rather than trying to store wealth in bitcoins for extended periods of time (which exposes you to changes in the exchange rate, be they good or bad), instead use it as a means of making payments. Buyers would buy coins only when they need to pay someone, and merchants would sell the coins after receiving them. If merchants perceive a risk of bitcoins dropping in value between setting the price and being able to sell the coins, then they can charge slightly extra to cover the perceived risk. (For symmetry, they should also charge slightly less if they believe the exchange rate will go up instead of down, but I bet most would quite happily take that as free profit.)
I do definitely agree this is a problem for Bitcoin. But it is possible to manage the risk, and that risk gets lower the more people use bitcoins. I don't think it's a show-stopper.
That's half of the problem, but how do you verify that the money held by the wallet service is valid? Anybody could set up a service, claim they have $50 and then spend it. You'd have to vet each wallet provider to make sure they could be trusted before you accept money from them. Imagine trying to handle your own wallet, and then getting Paypal to take you at face value on how much is in it: that's just not going to happen.
What they'd do is ask you to transfer funds from a wallet hosted by a credit card provider or a bank. With just an open API, you could pay people on other services (an improvement over the current situation), but the overall system would still be centrally controlled by the few players big enough to operate in it. To remove that central control, you need a distributed mechanism for making sure that people don't lie about how much money they have.
That's what Bitcoin is. It's a distributed, cryptographically-secure ledger for keeping track of who has how much money, and a way to transfer that money around.
Sorry, but nobody, apart from researchers, and those who want to check it out just for the novelty are going to use bitcoin as a currency.
On their own computers.
It's a bit like running an email server: they're big, complicated bits of software that require a ton of configuration, and you need to spend time keeping it up to date and keeping an eye out for any relevant security advisories. You also have to make sure to back up your mail daily -- preferably offsite too, in case your house burns down -- lest you lose all of it. This is beyond the ability of most people.
And yet plenty of people use e-mail! The beauty of e-mail is that it's possible for anybody to run a server, and yet still send messages to anybody using any other server. This is what Bitcoin is intended to do with payment systems.
Bitcoin makes it possible, if you wish, to make payments directly yourself, on your own systems and under your own control. (Of course, if you do this, you also take on the responsibility of doing it right.) Alternately, you can use wallet services provided by another entity of your choosing -- which can be anyone, since anyone has the ability to make and receive Bitcoin payments. There is no provider lockdown here.
Of course, I will admit we've now hit the real issue: it's hard to find someone you trust to host your wallet. This is similar to the situation with webmail, except with webmail you only give over access to most of your online accounts and the entire contents of every conversation you have with anybody over e-mail; with a Bitcoin wallet provider you'd be giving them access to the $50 you store in the wallet.
But this isn't a Bitcoin issue, it's a human/trust issue. People trust companies on the web all the time; I don't think this is insurmountable.
(Heck, it's not like you even have to leave the $50 in the wallet -- many people make use of Paypal without ever maintaining a balance in their account, often precisely because they don't trust Paypal with their money. The difference with Paypal is that you don't have the option to take your custom elsewhere, since the only way to pay Paypal users is via Paypal itself.)
I agree that, going by number of hosts, 64 bits for the interface ID is excessive. There are other reasons to want more than 32 bits though: a 32-bit subnet with 50,000 hosts using privacy addresses would have 400,000 addresses in use at any one time, and would get on average 5 address collisions every time the hosts generate themselves a new address -- even though 99.98% of the addresses on the network are unused. It's feasible to argue that a network that regularly sees collisions is one that's too small.
But more importantly, I'm just not convinced that allocation needs to be any better. I feel that reaching even the HD=80% point of 10 /48s per person in 2000::/3 is going to be difficult, and as such even the current 48:16:64 split will leave us with plenty of space. Finally, if 2000::/3 does fill up, we can switch to 4000::/3 using 64:16:48 or your 64:32:32 without any hassle, so there's definitely no need to make any changes to the allocation policies in 2000::/3.
You're right, and I omitted that consideration from my post. (You're misunderstanding the allocations though -- APNIC have 2001:0400::/23, which is 2001:0400:0000:: through to 2001:05ff:ffff::. They also have 2400::/12, which is 2400:0000:0000:: though to 240f:ffff:ffff::. Also, if you look at the list of allocations, they've obviously been left the whole of 2400:0000:0000: up until 25ff:ffff:ffff:: to expand into. Even the smaller /23 block has room for more than 65,536 corporations, let alone the /7 reserved block.)
The allocations are being done sparsely like this in the interest of route aggregation. The idea is to issue an ISP a /32, for example, but then skip the next 7 /32s. This means that the ISP can expand right up to a /29 while continuing to take up only a single routing table entry. If you want to put a negative spin on it, you could claim that this is only "12.5% efficient", or that it "wastes 87.5% of addresses", but this is not true: the gaps are being used to minimize routing table fragmentation.
How does this affect my assessment? RFC 3194 is required reading here. It defines the "H-density ratio", as a means of measuring how painful address allocation is becoming in a network with a hierarchical structure. Even if we take the low-end 80% used in that RFC, that would still be 70 billion /48s, or 10 per person on the planet. It's reasonable to expect some people to admin more than 10 networks and thus need more than 10 /48s, but I feel that it's unreasonable to expect that to be true of every single person on the planet.
For comparison, it looks like IPv4 passed its HD ratio of 80% (51 M hosts) in about 2000 or so. Clearly a network can continue operating beyond 80% if necessary; it just means that you have to start sacrificing route aggregation for a higher allocation percentage.
(Once again, I did these calculations for the 45-bit space in 2000::/3. The "we can start over in one of the other five /3s" argument is just as valid here too.)
I think you might not have quite gotten your head around just how much bigger 2^128 is compared to 2^32.
There are 5000 /48s per person on the planet -- out of 2000::/3 alone. (Remember that a single /48 has 80 bits of addresses in it. You could take the 2^32 addresses in IPv4, copy them 2^32 times and still only use 1/65536th of the space in a /48.)
If we do somehow manage to allocate the entire of 2000::/3, there are an additional five completely unused /3 blocks available, in which we can simply start over with tighter allocation policies.
It's going to be enough.
ifconfig can't handle displaying them, but if you will insist on using an obsolete piece of software, don't complain when you bump into its limitations.
So then the answer is "yes". The "I refuse to adapt to change" crowd gets a new poster boy.
I feel that a lot of the changes are outright bad (like moving the link hover URL display from the status bar to a tooltip -- which displays just above the now-empty big blank space in the status bar. How does that make any sense?). These are the changes I refuse to adapt to.
Do you think you'll still be using Firefox 3.6 in 10 years? If not, then what's stopping you from upgrading now? Would it be easier to adapt going from XP to Vista to Win7 to Win8, or from XP straight to Win8?
The great thing about Firefox is that it's open-source and its interface is easily malleable; I'll upgrade off of 3.6 just as soon as I've finished fixing all the things that irritate me in "Firefox Vista". In a similar vein, I don't expect to move to Windows 8 at all. If things get bad enough on XP that I'm forced to upgrade, it will probably be to Linux, where I have control over my UI.
It's the new XP -- that is, the last version before they started "improving" the UI.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
There's a problem with that -- smaller releases means smaller cakes.
Are you guys talking about this feature?