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'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.

v6 makes things better, because it uses 128-bit addresses rather than 32-bit addresses. See RFCs 1715 and 3194 for the details.

Yes, there's a small linear factor of extra memory required for v6 routes vs v4 routes, but that's irrelevant compared to the route count reduction that comes from a lower HD ratio.

Which they are, as a direct result of v6 being so huge. See RFCs 1715 and 3194 for discussion on this.

Obviously in the long run we'll end up with a higher absolute count of routes in v6 (because supporting more people was the other reason for it) but the route count will scale far better than a network that has to be run at a ridiculously high HD-ratio because it's too small.

Yeah, it's technically possible in v4, but I need a /27 for my network and I guess most people need /28-/29. Your /19 is only 512 /28s, so I guess you aren't going to be giving those out. Realistically, your users are going to end up with 1 v4 IP each, and be stuck with NAT.

(Until you get more than a few thousand customers and have to start CGNATing, at which point they're screwed, especially without v6 as an alternative.)

Pretty much everybody does. My ISP gives a /48, and even Comcast give up to /60. (Then there's the depressingly large amount of ISPs that only do one /64, despite RFC 6177 basically saying that you should be getting at least /56...)