Mozilla has had nightly 64-bit builds for many months now, but nobody wants to use them to help test and get things working more quickly
You have this backwards. Mozilla tried to kill 64-bit Nightly builds two years ago, even though about 50% of Nightly users were using them at the time. Those users (somewhat predictably) weren't too happy and complained, and Mozilla eventually left 64-bit builds running, but disabled crash reports and automated testing, and refused to commit paid dev time to keeping it compiling or passing the tests. Plus they originally planned to automatically migrate those users to 32-bit, though that never actually happened. That's not exactly "nobody wants to use them to help test".
Then they replace their UI code so they do all of those things
Nope, different projects. Australis wasn't part of any of those.
and because you don't like it missing some features
More like, Mozilla deliberately killed some features because they thought we were too stupid to handle them, and when people asked them not to, they basically said "sod off, we don't care".
Would you rather have a browser you can still customize away from the defaults, or something like Firefox 2 or 3, where you have to sacrifice a lamb to change the UI substantially
Hm. I'm on Firefox 3.6 and it's a ton easier to customize than Australis. I prefer to have my stop and reload buttons between back/forward and the address bar. On 3.6 I just do it, on Australis I can't do it at all. Same deal with a bunch of other stuff. I guess I can't easily rearrange icons on the status bar, but then I can't do that with Australis either, can I?
presume that the only thing they need to do in order to get their way is spew more and more vitriol
It's more like: we've tried every other option and Mozilla just doesn't give a shit, so what's left to do but to bitch? If we shut up about it, they'll just assume we were complaining because stuff changed, rather than because we didn't like what it changed *to*.
All of that energy could have solved a real problem by now
"My browser pisses me off every time I use it" actually is a real problem for some of us. I groan every time I need to launch Australis to test some newly committed feature, there's no way in hell I could deal with that every single time I need to open a webpage -- and I'd have a hard time getting any other problems solved if I was that pissed off all the time.
SSH can be configured to lock down which commands the user can run; this is common in combination with e.g. gitolite for letting people push to a git repository without giving them full shell access. Anybody with access to such a server can now run arbitrary local commands
That's the general goal of the Free software movement. There's far, far more software out there than any one entity can produce, so 99% of the time you'll be benefiting from the work of other people.
My recommendations to that are a) use DNS anyway (you can limit which clients get access to which zones, so you can keep them internal if you really want), or at least a hosts file, b) pick your IPs carefully to avoid dealing with horrible addresses, c) copy/paste.
e.g.: # host he.net he.net has address 216.218.186.2 he.net has IPv6 address 2001:470:0:76::2
16 characters vs 13 characters isn't too bad, and it's the same effort to copy/paste either way... and if NAT is involved then the v4 side gets silly because you have to deal with two addresses for that machine, which is definitely more effort than those 3 extra characters.
If it was http://2001::48:8080/ then you'd be connecting on port 80. If it was http://[2001::48:8080]:8080/, then it'd be port 8080. It's not the most wonderful syntax, but it's not ambiguous either... and it's not like anybody deals with IPs on a regular basis anyway, because we have this "DNS" thing that saves you from doing it.
That decision was made almost 20 years ago, and I haven't had much luck finding any records of the discussion about it. I can, however, point out that there's a big difference between numbering networks and numbering hosts. A 48-bit space for numbering hosts is tight; a 64-bit space for numbering networks is not.
a) Being able to connect to someone else's (or your own) v6 machine is useful. b) Not needing NAT is very useful. It's much, much easier to manage a network that doesn't use NAT.
Even putting (a) aside, (b) makes it cheaper and nicer to admin your network. Unless you're a masochist, why wouldn't you want that?
NAT rewrites addresses; firewalls don't. The former breaks inbound connections and complicates everything for the network admin and for anything that needs to know your IP. There's no reason to do that to yourself unless you absolutely have to.
It's not a firewall. NAT doesn't block incoming connections, it breaks incoming connections (and more besides). We should not be basing the internet around something that does that.
Once you sit down and hash out all of the details of this "just add a few more octets" plan, you end up with roughly what we've already got. Except, of course, we decided to add 12 octets rather than 2, because 48 bits is hilariously too small for the current internet, let alone to handle future growth.
I and others have offered to maintain the features I listed above, and Mozilla have rejected our assistance. I'm an extension developer, and maintain a bunch of extensions which exist for the sole purpose of making recent Firefox versions sane, so this isn't a hollow offer: I (and/or other people) will be maintaining extensions to do these things anyway, but Mozilla is refusing to integrate that code into Firefox.
(Note that CTR is a pretty clear demonstration that you can't do all those things in Firefox, or there wouldn't be an extension for it.)
You can't stick stuff on a toolbar at the bottom of the screen, you can't uncombine or even move stop/reload, you can't move back/forward or put buttons between them and the address bar, you can't get rid of the conditional forward button, you can't put the tab toolbar under the navigation toolbar, you can't turn the broken toolbar button styling off with Small Icons mode any more, and you can't put stuff at the far right of the navigation toolbar because the Menu button is there and unmovable. Probably plus other stuff that I've forgotten or not discovered because I don't use Australis.
ZFS. It's by far and away the best choice for data storage like this. Even if you ignore its technical features (lz4 and gzip compression, checksumming (including of metadata, which you won't manage with a script), redundant metadata so you don't lose entire directories to a single badly-placed bad block, snapshots and the ability to incrementally send snapshots over a pipe to another pool, native block devices,...), it's just way nicer to administrate than btrfs, which is the only possible contender.
Just don't be tempted by its dedup. You'll regret turning that on.
By scanning the pattern and constructing a new brain with the same patterns. Implementation details are left as an exercise for the reader.
This seems like it'd be extremely hard but not necessarily impossible. The bigger issue is that you'd essentially be fork()ing your mind -- the original mind would still be stuck in the original body, so the whole procedure wouldn't help it any.
The odd thing is that they don't. Want a bigger allocation on Comcast? I guess you could buy Comcast Business, but that's inappropriate for residential use (it's a business account, after all)... and even that only gets you a/56. If you want more than that, I don't think you even have the option to pay for it. More v4 addresses? 95% of ISPs won't give you that, regardless of how much you're willing to spend. (Of course exhaustion is beginning to justify this, but these are the same ISPs that claim they "have enough v4 addresses to not need v6", so presumably they have enough.) Some ISPs will sell you a static IP, but not many. rDNS? Snort.
They're giving/56 to business customers... I can only assume they sat down and worked out what allocation sizes would be reasonable, then deliberately picked the next size down, because we couldn't possibly have good service from an ISP.
I can't yet imagine what I would use more than a/60 for.
I've got a router here that supports two guest wifi networks, so that's 3/64s already. Throw in one or two people using VMs with routed networks and maybe a son that went and plugged a second router in behind the first (which is generally dumb, but it ought to work) and suddenly you're looking at half of that/60 gone, and you've already had to throw away aggregation and nice rDNS sub-delegation to get it.
And that's just the stuff people are using today. I have no imagination, so I have no idea what we might get in the future if we actually had the infrastructure to support it.
Comcast's is native. AT&T's deployment is 6rd, where a/60 is justifiable, but all Comcast needed to do was write "56" in their config files rather than "60"...
A/60 is definitely better than nothing, yeah, and probably enough for 90% of people these days. But that's not what we should be targeting. We should be targeting "enough for pretty much everybody", and "for the foreseeable future" -- including for any new, fun things that become possible because of easily-available address space.
Of course it won't. The internet is growing and v6 is there to handle that growth, so of course it's going to end up with more prefixes. However, the number of prefixes scales much better with network size in v6, due to the much lower HD-ratio (which is a big part of why the address space is so huge in the first place). A v6 prefix tends to take 2x the TCAM space a v4 prefix does, but v6 can handle the same number of nodes with way fewer than half the prefixes that end up being needed in v4.
If you use SLAAC to automatically configure an address, it does it by putting the MAC (rather, EUI-64) address in the lower 64 bits. If your address comes from something other than SLAAC then it doesn't need to have the MAC address there.
Your solution is to a problem that doesn't exist. v6 already supports a gradual rollout and transition period: all you have to do is roll it out without disabling your existing v4.
/60 is actually pretty small; RFC 6177 basically says you should be getting/56 or bigger.
Though it's certainly better than the one/64 that far too many ISPs are doing (or the "no routed space whatsoever, on-link only" that way too many datacenters do...).
See RFCs 1715 and 3194. Lower HD-ratio means less fragmentation of allocations, which means fewer routes required to cover the same number of hosts. Each route takes twice the memory, but you have way fewer than half the number of routes because your allocations aren't fragmented to hell and back.
Slashdot Mirror
Mozilla has had nightly 64-bit builds for many months now, but nobody wants to use them to help test and get things working more quickly
You have this backwards. Mozilla tried to kill 64-bit Nightly builds two years ago, even though about 50% of Nightly users were using them at the time. Those users (somewhat predictably) weren't too happy and complained, and Mozilla eventually left 64-bit builds running, but disabled crash reports and automated testing, and refused to commit paid dev time to keeping it compiling or passing the tests. Plus they originally planned to automatically migrate those users to 32-bit, though that never actually happened. That's not exactly "nobody wants to use them to help test".
(References: [1] and [2].)
Of course, fast forward to a few months ago and Chrome's announcements of 64-bit, and suddenly it's "oh, we've been doing 64-bit builds for years".
Then they replace their UI code so they do all of those things
Nope, different projects. Australis wasn't part of any of those.
and because you don't like it missing some features
More like, Mozilla deliberately killed some features because they thought we were too stupid to handle them, and when people asked them not to, they basically said "sod off, we don't care".
Would you rather have a browser you can still customize away from the defaults, or something like Firefox 2 or 3, where you have to sacrifice a lamb to change the UI substantially
Hm. I'm on Firefox 3.6 and it's a ton easier to customize than Australis. I prefer to have my stop and reload buttons between back/forward and the address bar. On 3.6 I just do it, on Australis I can't do it at all. Same deal with a bunch of other stuff. I guess I can't easily rearrange icons on the status bar, but then I can't do that with Australis either, can I?
presume that the only thing they need to do in order to get their way is spew more and more vitriol
It's more like: we've tried every other option and Mozilla just doesn't give a shit, so what's left to do but to bitch? If we shut up about it, they'll just assume we were complaining because stuff changed, rather than because we didn't like what it changed *to*.
All of that energy could have solved a real problem by now
"My browser pisses me off every time I use it" actually is a real problem for some of us. I groan every time I need to launch Australis to test some newly committed feature, there's no way in hell I could deal with that every single time I need to open a webpage -- and I'd have a hard time getting any other problems solved if I was that pissed off all the time.
SSH can be configured to lock down which commands the user can run; this is common in combination with e.g. gitolite for letting people push to a git repository without giving them full shell access. Anybody with access to such a server can now run arbitrary local commands
That's the general goal of the Free software movement. There's far, far more software out there than any one entity can produce, so 99% of the time you'll be benefiting from the work of other people.
Whereas FF is far and away the MOST customizable
Mozilla are working hard to "fix" this though. It's not even as customizable as its own previous versions.
My recommendations to that are a) use DNS anyway (you can limit which clients get access to which zones, so you can keep them internal if you really want), or at least a hosts file, b) pick your IPs carefully to avoid dealing with horrible addresses, c) copy/paste.
e.g.:
# host he.net
he.net has address 216.218.186.2
he.net has IPv6 address 2001:470:0:76::2
16 characters vs 13 characters isn't too bad, and it's the same effort to copy/paste either way... and if NAT is involved then the v4 side gets silly because you have to deal with two addresses for that machine, which is definitely more effort than those 3 extra characters.
Neither. That's just an IP.
If it was http://2001::48:8080/ then you'd be connecting on port 80. If it was http://[2001::48:8080]:8080/, then it'd be port 8080. It's not the most wonderful syntax, but it's not ambiguous either... and it's not like anybody deals with IPs on a regular basis anyway, because we have this "DNS" thing that saves you from doing it.
That decision was made almost 20 years ago, and I haven't had much luck finding any records of the discussion about it. I can, however, point out that there's a big difference between numbering networks and numbering hosts. A 48-bit space for numbering hosts is tight; a 64-bit space for numbering networks is not.
And your ISP is supposed to be giving at least a /56, so take your allocation size up with them. If they won't give you more, it's not IPv6's fault, it's their fault.
Uh... yes there is.
a) Being able to connect to someone else's (or your own) v6 machine is useful.
b) Not needing NAT is very useful. It's much, much easier to manage a network that doesn't use NAT.
Even putting (a) aside, (b) makes it cheaper and nicer to admin your network. Unless you're a masochist, why wouldn't you want that?
NAT rewrites addresses; firewalls don't. The former breaks inbound connections and complicates everything for the network admin and for anything that needs to know your IP. There's no reason to do that to yourself unless you absolutely have to.
That's fairly unusual, but it's not quite as strange as Perl's $[, which you can assign to to select where arrays count from.
It's not a firewall. NAT doesn't block incoming connections, it breaks incoming connections (and more besides). We should not be basing the internet around something that does that.
This is pretty much what IPv6 did.
Once you sit down and hash out all of the details of this "just add a few more octets" plan, you end up with roughly what we've already got. Except, of course, we decided to add 12 octets rather than 2, because 48 bits is hilariously too small for the current internet, let alone to handle future growth.
I and others have offered to maintain the features I listed above, and Mozilla have rejected our assistance. I'm an extension developer, and maintain a bunch of extensions which exist for the sole purpose of making recent Firefox versions sane, so this isn't a hollow offer: I (and/or other people) will be maintaining extensions to do these things anyway, but Mozilla is refusing to integrate that code into Firefox.
(Note that CTR is a pretty clear demonstration that you can't do all those things in Firefox, or there wouldn't be an extension for it.)
You can't stick stuff on a toolbar at the bottom of the screen, you can't uncombine or even move stop/reload, you can't move back/forward or put buttons between them and the address bar, you can't get rid of the conditional forward button, you can't put the tab toolbar under the navigation toolbar, you can't turn the broken toolbar button styling off with Small Icons mode any more, and you can't put stuff at the far right of the navigation toolbar because the Menu button is there and unmovable. Probably plus other stuff that I've forgotten or not discovered because I don't use Australis.
ZFS. It's by far and away the best choice for data storage like this. Even if you ignore its technical features (lz4 and gzip compression, checksumming (including of metadata, which you won't manage with a script), redundant metadata so you don't lose entire directories to a single badly-placed bad block, snapshots and the ability to incrementally send snapshots over a pipe to another pool, native block devices, ...), it's just way nicer to administrate than btrfs, which is the only possible contender.
Just don't be tempted by its dedup. You'll regret turning that on.
By scanning the pattern and constructing a new brain with the same patterns. Implementation details are left as an exercise for the reader.
This seems like it'd be extremely hard but not necessarily impossible. The bigger issue is that you'd essentially be fork()ing your mind -- the original mind would still be stuck in the original body, so the whole procedure wouldn't help it any.
The odd thing is that they don't. Want a bigger allocation on Comcast? I guess you could buy Comcast Business, but that's inappropriate for residential use (it's a business account, after all)... and even that only gets you a /56. If you want more than that, I don't think you even have the option to pay for it. More v4 addresses? 95% of ISPs won't give you that, regardless of how much you're willing to spend. (Of course exhaustion is beginning to justify this, but these are the same ISPs that claim they "have enough v4 addresses to not need v6", so presumably they have enough.) Some ISPs will sell you a static IP, but not many. rDNS? Snort.
They're giving /56 to business customers... I can only assume they sat down and worked out what allocation sizes would be reasonable, then deliberately picked the next size down, because we couldn't possibly have good service from an ISP.
I can't yet imagine what I would use more than a /60 for.
I've got a router here that supports two guest wifi networks, so that's 3 /64s already. Throw in one or two people using VMs with routed networks and maybe a son that went and plugged a second router in behind the first (which is generally dumb, but it ought to work) and suddenly you're looking at half of that /60 gone, and you've already had to throw away aggregation and nice rDNS sub-delegation to get it.
And that's just the stuff people are using today. I have no imagination, so I have no idea what we might get in the future if we actually had the infrastructure to support it.
Comcast's is native. AT&T's deployment is 6rd, where a /60 is justifiable, but all Comcast needed to do was write "56" in their config files rather than "60"...
A /60 is definitely better than nothing, yeah, and probably enough for 90% of people these days. But that's not what we should be targeting. We should be targeting "enough for pretty much everybody", and "for the foreseeable future" -- including for any new, fun things that become possible because of easily-available address space.
Of course it won't. The internet is growing and v6 is there to handle that growth, so of course it's going to end up with more prefixes. However, the number of prefixes scales much better with network size in v6, due to the much lower HD-ratio (which is a big part of why the address space is so huge in the first place). A v6 prefix tends to take 2x the TCAM space a v4 prefix does, but v6 can handle the same number of nodes with way fewer than half the prefixes that end up being needed in v4.
If you use SLAAC to automatically configure an address, it does it by putting the MAC (rather, EUI-64) address in the lower 64 bits. If your address comes from something other than SLAAC then it doesn't need to have the MAC address there.
Your solution is to a problem that doesn't exist. v6 already supports a gradual rollout and transition period: all you have to do is roll it out without disabling your existing v4.
/60 is actually pretty small; RFC 6177 basically says you should be getting /56 or bigger.
Though it's certainly better than the one /64 that far too many ISPs are doing (or the "no routed space whatsoever, on-link only" that way too many datacenters do...).
See RFCs 1715 and 3194. Lower HD-ratio means less fragmentation of allocations, which means fewer routes required to cover the same number of hosts. Each route takes twice the memory, but you have way fewer than half the number of routes because your allocations aren't fragmented to hell and back.