No idea what you're trying to achieve with your IPv4 plus sign there. 2 separate addresses? You remember them as 2 separate addresses, depending on which side of the NAT you're on.
One on either side of the NAT, yes. And v6 is basically the same: it's the prefix (2001:db8:a0b:) plus the subnet and host (12f0::1).
Try memorising a SLAAC address or any other autoconf.
Yeah, obviously you don't do that. This is what DNS is for.
Try building out an infrastructure provider PD hierarchy [...]
Ultimately, it doesn't matter what you want here. v4 is too small for the internet, v6 is the replacement. As an ISP it's your job to deal with it. And it won't be as bad as you think it is.
An individual IP should be used by one machine. It'd be more useful to track the number of networks/subnets (where each subnet gets a/64). But houses can have more than one network, so they should be getting more like a/56 (with companies getting/48 or so for their bigger networks).
The numbers are still crazy though. 10 million houses per person? We should be able to keep under that.
You're right that hierarchy in address allocation increases the address space requirements (you could say "wastes" addresses, but they're not wasted, they're being used to reduce routing table fragmentation). But it doesn't follow that v6 exhaustion is actually plausible as a result. v6 is really damn big (for precisely this reason!) and we're only allocating from one/3; over 60% of the total space is outright reserved at the moment.
Your example allocations are all shifted to the right a bit. ISPs are generally getting/32s, companies should be getting/48s, their internal departments could be getting/56s (so they'd need 256 departments before having a problem). But even/32s to ISPs isn't problematically big -- 4 billion ISPs would be a lot, given that there's only 7 billion humans.
You can mostly run a NAT64+DNS64 network with no native v4 right now -- the only problem with it is v4-only client software (not v4-only servers). And even that could be fixed by client OS support for 464XLAT or some sort of automatic mapping of v4 sockets into a v6 prefix (which is something that everything should've supported years ago but unfortunately doesn't look like it's ever going to happen).
Check `ipconfig/all`. Or I can tell you it's 2001:db8:420::53 because you deliberately picked a short address for it, because why would you pick something long and unrememberable like 2001:db8:420:f4ca:c6fb:d174:620e:37f9 for the one specific machine that you have to remember the IP for?
Have you actually used v6? It's not really that hard. For starters, that address is 2001:db8:a0b:12f0::1. (Why did you write it with all the extra zeros?) Secondly, let's compare the v6 case with the inevitably-NATed v4 case:
2001:db8:a0b:12f0::1 vs 192.0.2.215+192.168.189.1
So, v6 is shorter. If you have trouble memorizing v6, then you should be having even more trouble with v4.
I'd also like to introduce to this wonderful thing called DNS that eliminates the need to remember most addresses. It's a pretty mature tech by now, is supported by most programs and I strongly suggest you start using it. It'll make your life easier.
v6 has a lot of addresses. There's no point counting the IP addresses somebody has, because the answer is always "too many". And surely that's a good thing? Would you rather people had too few addresses instead?
Sprint's block is not overly generous -- in terms of overall consumption of the v6 space it's like allocating them 8 IPs in v4 space, to cover 60 million customers. We'll be fine, and even if we aren't and we somehow manage to run out of space in 2000::/3, we can break into the 5 other reserved/3 blocks using tighter allocation policies, so we do have a backup plan.
If you still disagree with me, show us the math. Try and make a reasonable argument for us running out, that doesn't boil down to "well we ran out in v4 so clearly the same must happen in v6".
That's because those businesses are paying extra money to continue to support v4 -- which is of course being passed straight on to their customers.
Would you rather have waited until companies were being bankrupted by the need for v4 support until we did anything about it? (Because it sure seems like a lot of people would...)
The actual screenshot functionality is already there: just do shift+F2 > "screenshot [--fullpage] filename", or "screenshot --clipboard".
In fact I just checked the syntax for it and "--imgur" is also an available argument (which is great if you're okay with all your screenshots ending up on imgur).
I know it because I've been paying attention and can extrapolate. Mozilla have rejected, on the grounds of being too hard to maintain, lots of options that would be simple to implement. They're not going to maintain APIs instead of options for the same thing, since APIs require even more maintenance than options do.
In any case, there's always going to be something the APIs don't cover, and for that you need some way of going around the friendly API sandbox to access the internals. No amount of API requests or proposals are going to fix that. Unfortunately, since removing access to browser internals is one of the explicit goals of WE I'm somewhat skeptical that we're going to do anything to fix this problem.
You're playing with abstractions, but there's no way around the abstractions to get at the underlying implementation, which is necessary whenever you want to write an extension that affects the implementation side of things, or that does something that Mozilla don't want to maintain an abstraction for. That's why I'm calling it a sandbox: because it is.
WebExtension APIs are going to allow for modification of browser chrome.
Only extremely limited modification of the few parts of it that Mozilla think you should be able to touch, and which they're willing to maintain an API for. That's not good enough; I mainly use extensions to do things to the UI that Mozilla don't think I should be able to do (things like "look and act like any other Windows program"...) and obviously they're not going to maintain an API for those.
If you have useful ideas for new extension APIs, I encourage you to offer suggestions instead of FUD.
I really wish this was FUD. I know I'm describing a really shit situation, but the shit situation is the stated plan, and there doesn't seem to be any intention of changing it.
Firefox doesn't support sandboxing yet, therefore sandboxing is the security feature that every browser needs to have (for anybody who wants to complain about Firefox).
I took a brief glance at that extension's source. From https://addons.mozilla.org/en-...: exports.main = function (options) {
if (options.loadReason === 'install' || options.loadReason === 'startup') {
var version = sp.prefs.version;
if (self.version !== version) {
if (sp.prefs.welcome) {
timers.setTimeout(function () {
tabs.open(
'http://firefox.add0n.com/privacy-settings.html?v=' + self.version +
(version ? '&p=' + version + '&type=upgrade' : '&type=install')
);
}, 3000);
}
sp.prefs.version = self.version;
}
}
};
Because phoning home on every update is good for your privacy, right?
Not in those explicit words, no. You have to apply your brain a bit.
"WebExtensions" are just glorified Greasemonkey scripts -- with a much larger API than GM scripts have available, but you're still playing around in a sandbox. These are mostly interesting for extending how a given website works, hence my comparison to GM.
"Extensions" have access to the browser chrome, and can thus add or change any functionality in the browser. This is the bit that is euphemistically (and wrongly) described as "deprecation of XUL and XPCOM" (even though XUL and XPCOM aren't actually a requirement for this type of extension...).
The plan is actually to drop extensions completely. They're also adding support for what are roughly Greasemonkey scripts, but those aren't going to be anywhere near as capable as extensions are.
If your extension can be ported to a content script easily, then great, but otherwise you're screwed and won't even be allowed to keep your extension working.
It doesn't fix the form data loss problem, and it also removes the only non-shifted way of going back from a regular keyboard, which really isn't worth the loss.
Just fix the damn data loss issue, don't try to paper over it by making the browser harder to use.
It can be done just fine without being horrifically insecure, for instance by putting a list of acceptable extension fingerprints in/etc/. Why Mozilla won't do that I'm not sure -- I've not been able to get a straight answer out of them that isn't obviously wrong.
There are no options for dealing with this in Firefox. There are a few options (like Nightly, unbranded builds, other browsers) where you side-step the problem with Firefox by not using Firefox, but none of those options fix the problem for people using Firefox. The issue isn't that there aren't browsers that let you disable extension signing, the issue is that there are browsers that don't.
They're working hard on this. Their announced plan is to drop support for extensions soon (to replace them with, approximately, Greasemonkey scripts, which can't do anything like the range of things extensions can).
And this version of Firefox takes away your ability to decide what code runs on your own computer when you use it, which just isn't acceptable. It's not good enough that Mozilla will probably give you permission to run one exact, unmodified version of an extension; you need to be able to make the decision on your own for your own computer.
No, the UI failure was losing form data when going back. The right fix isn't to remove one of the ways of going back, but rather to stop losing form data when going back.
We're already paying those people them money via welfare, so we've already figured out where that part of the money will come from.
The last category of people are those who aren't working (aren't paying tax) and who aren't currently claiming benefits. The money for these people will come from the money saved by reducing administration overhead on the welfare system.
If that's still not enough money to cover it... then yes, you're going to have to start working out where it comes from. But the bulk of the money is in fact already available or easy to find a source for, and any shortfall will be nothing like the $10,000 * 300 million that the article thinks you'll need to find.
Slashdot Mirror
No, I just figured that GP probably did, since any Linux sysadmin should already know how to look up which resolvers their system is using.
DHCP seems somewhat orthogonal here.
No idea what you're trying to achieve with your IPv4 plus sign there. 2 separate addresses? You remember them as 2 separate addresses, depending on which side of the NAT you're on.
One on either side of the NAT, yes. And v6 is basically the same: it's the prefix (2001:db8:a0b:) plus the subnet and host (12f0::1).
Try memorising a SLAAC address or any other autoconf.
Yeah, obviously you don't do that. This is what DNS is for.
Try building out an infrastructure provider PD hierarchy [...]
Ultimately, it doesn't matter what you want here. v4 is too small for the internet, v6 is the replacement. As an ISP it's your job to deal with it. And it won't be as bad as you think it is.
The correct calculation is 2^(2*2^4) vs 2^(2*2^6))
An individual IP should be used by one machine. It'd be more useful to track the number of networks/subnets (where each subnet gets a /64). But houses can have more than one network, so they should be getting more like a /56 (with companies getting /48 or so for their bigger networks).
The numbers are still crazy though. 10 million houses per person? We should be able to keep under that.
You're right that hierarchy in address allocation increases the address space requirements (you could say "wastes" addresses, but they're not wasted, they're being used to reduce routing table fragmentation). But it doesn't follow that v6 exhaustion is actually plausible as a result. v6 is really damn big (for precisely this reason!) and we're only allocating from one /3; over 60% of the total space is outright reserved at the moment.
Your example allocations are all shifted to the right a bit. ISPs are generally getting /32s, companies should be getting /48s, their internal departments could be getting /56s (so they'd need 256 departments before having a problem). But even /32s to ISPs isn't problematically big -- 4 billion ISPs would be a lot, given that there's only 7 billion humans.
You can mostly run a NAT64+DNS64 network with no native v4 right now -- the only problem with it is v4-only client software (not v4-only servers). And even that could be fixed by client OS support for 464XLAT or some sort of automatic mapping of v4 sockets into a v6 prefix (which is something that everything should've supported years ago but unfortunately doesn't look like it's ever going to happen).
Check `ipconfig /all`. Or I can tell you it's 2001:db8:420::53 because you deliberately picked a short address for it, because why would you pick something long and unrememberable like 2001:db8:420:f4ca:c6fb:d174:620e:37f9 for the one specific machine that you have to remember the IP for?
Have you actually used v6? It's not really that hard. For starters, that address is 2001:db8:a0b:12f0::1. (Why did you write it with all the extra zeros?) Secondly, let's compare the v6 case with the inevitably-NATed v4 case:
2001:db8:a0b:12f0::1
vs
192.0.2.215+192.168.189.1
So, v6 is shorter. If you have trouble memorizing v6, then you should be having even more trouble with v4.
I'd also like to introduce to this wonderful thing called DNS that eliminates the need to remember most addresses. It's a pretty mature tech by now, is supported by most programs and I strongly suggest you start using it. It'll make your life easier.
v6 has a lot of addresses. There's no point counting the IP addresses somebody has, because the answer is always "too many". And surely that's a good thing? Would you rather people had too few addresses instead?
Sprint's block is not overly generous -- in terms of overall consumption of the v6 space it's like allocating them 8 IPs in v4 space, to cover 60 million customers. We'll be fine, and even if we aren't and we somehow manage to run out of space in 2000::/3, we can break into the 5 other reserved /3 blocks using tighter allocation policies, so we do have a backup plan.
If you still disagree with me, show us the math. Try and make a reasonable argument for us running out, that doesn't boil down to "well we ran out in v4 so clearly the same must happen in v6".
That's because those businesses are paying extra money to continue to support v4 -- which is of course being passed straight on to their customers.
Would you rather have waited until companies were being bankrupted by the need for v4 support until we did anything about it? (Because it sure seems like a lot of people would...)
But why hate backspace-as-back rather than hating the fact that going back destroys your form data?
Surely that's the real issue we should be fixing here, not trying to paper over it by making it harder to go back.
The actual screenshot functionality is already there: just do shift+F2 > "screenshot [--fullpage] filename", or "screenshot --clipboard".
In fact I just checked the syntax for it and "--imgur" is also an available argument (which is great if you're okay with all your screenshots ending up on imgur).
The lack of automation means you end up paying in admin overhead though.
I know it because I've been paying attention and can extrapolate. Mozilla have rejected, on the grounds of being too hard to maintain, lots of options that would be simple to implement. They're not going to maintain APIs instead of options for the same thing, since APIs require even more maintenance than options do.
In any case, there's always going to be something the APIs don't cover, and for that you need some way of going around the friendly API sandbox to access the internals. No amount of API requests or proposals are going to fix that. Unfortunately, since removing access to browser internals is one of the explicit goals of WE I'm somewhat skeptical that we're going to do anything to fix this problem.
You're playing with abstractions, but there's no way around the abstractions to get at the underlying implementation, which is necessary whenever you want to write an extension that affects the implementation side of things, or that does something that Mozilla don't want to maintain an abstraction for. That's why I'm calling it a sandbox: because it is.
WebExtension APIs are going to allow for modification of browser chrome.
Only extremely limited modification of the few parts of it that Mozilla think you should be able to touch, and which they're willing to maintain an API for. That's not good enough; I mainly use extensions to do things to the UI that Mozilla don't think I should be able to do (things like "look and act like any other Windows program"...) and obviously they're not going to maintain an API for those.
If you have useful ideas for new extension APIs, I encourage you to offer suggestions instead of FUD.
I really wish this was FUD. I know I'm describing a really shit situation, but the shit situation is the stated plan, and there doesn't seem to be any intention of changing it.
Sandboxing.
Firefox doesn't support sandboxing yet, therefore sandboxing is the security feature that every browser needs to have (for anybody who wants to complain about Firefox).
I took a brief glance at that extension's source. From https://addons.mozilla.org/en-...:
exports.main = function (options) {
if (options.loadReason === 'install' || options.loadReason === 'startup') {
var version = sp.prefs.version;
if (self.version !== version) {
if (sp.prefs.welcome) {
timers.setTimeout(function () {
tabs.open(
'http://firefox.add0n.com/privacy-settings.html?v=' + self.version +
(version ? '&p=' + version + '&type=upgrade' : '&type=install')
);
}, 3000);
}
sp.prefs.version = self.version;
}
}
};
Because phoning home on every update is good for your privacy, right?
Not in those explicit words, no. You have to apply your brain a bit.
"WebExtensions" are just glorified Greasemonkey scripts -- with a much larger API than GM scripts have available, but you're still playing around in a sandbox. These are mostly interesting for extending how a given website works, hence my comparison to GM.
"Extensions" have access to the browser chrome, and can thus add or change any functionality in the browser. This is the bit that is euphemistically (and wrongly) described as "deprecation of XUL and XPCOM" (even though XUL and XPCOM aren't actually a requirement for this type of extension...).
Did you miss this announcement?
The plan is actually to drop extensions completely. They're also adding support for what are roughly Greasemonkey scripts, but those aren't going to be anywhere near as capable as extensions are.
If your extension can be ported to a content script easily, then great, but otherwise you're screwed and won't even be allowed to keep your extension working.
It doesn't fix the form data loss problem, and it also removes the only non-shifted way of going back from a regular keyboard, which really isn't worth the loss.
Just fix the damn data loss issue, don't try to paper over it by making the browser harder to use.
It can be done just fine without being horrifically insecure, for instance by putting a list of acceptable extension fingerprints in /etc/. Why Mozilla won't do that I'm not sure -- I've not been able to get a straight answer out of them that isn't obviously wrong.
There are no options for dealing with this in Firefox. There are a few options (like Nightly, unbranded builds, other browsers) where you side-step the problem with Firefox by not using Firefox, but none of those options fix the problem for people using Firefox. The issue isn't that there aren't browsers that let you disable extension signing, the issue is that there are browsers that don't.
They're working hard on this. Their announced plan is to drop support for extensions soon (to replace them with, approximately, Greasemonkey scripts, which can't do anything like the range of things extensions can).
And this version of Firefox takes away your ability to decide what code runs on your own computer when you use it, which just isn't acceptable. It's not good enough that Mozilla will probably give you permission to run one exact, unmodified version of an extension; you need to be able to make the decision on your own for your own computer.
No, the UI failure was losing form data when going back. The right fix isn't to remove one of the ways of going back, but rather to stop losing form data when going back.
We're already paying those people them money via welfare, so we've already figured out where that part of the money will come from.
The last category of people are those who aren't working (aren't paying tax) and who aren't currently claiming benefits. The money for these people will come from the money saved by reducing administration overhead on the welfare system.
If that's still not enough money to cover it... then yes, you're going to have to start working out where it comes from. But the bulk of the money is in fact already available or easy to find a source for, and any shortfall will be nothing like the $10,000 * 300 million that the article thinks you'll need to find.