Here is a totally hacked-together and very poorly written JS implementation. It'll constantly take 1000-sample surveys of a 315m population. The actual distribution of the population is printed at the top, and the results of the surveys are printed underneath, color-coded to make it easier to spot the results.
It's kinda slow and may well need a 64-bit browser, so I also made versions with 100m population size, 31.5m and 3.15m. If you're going to argue that those are too small a population size, then suck it up and wait for the 315m version to finish. You can always just fiddle with the values yourself by saving the page; the population and sample size variables are at the top. I only tested on Firefox 24.0a1.
(To anybody who reads this post after the above links break: sorry. Slashdot wouldn't let be inline the data: URIs, so I had to use tinyurl.)
Interesting theory about sample size,let me make it clear for you. Take a digital picture with the same number of pixels as the adult population(we'll even narrow it down to adults) then, pick a thousand random pixels to represent the picture.... Whadda ya got? Crap.
Try it, then. This example is really easy to simulate with code.
Remember that the pixels in your picture can only have one of two values ("yes" and "no" -- map them to blue and red or whatever), and the question you're trying to answer is "are there more red pixels than blue pixels?", using 1000 randomly-selected pixels.
There's always been a separate stop button, you just have to customize the toolbar so that the stop button is ordered before the reload button
Just be aware that you won't be able to do this after the upcoming changes to make customization more user-friendly go in. The address bar (and buttons to the left of it, including back/forward) are outside of the customizable area, so you won't be able to split out the stop and reload buttons (or prevent the back/forward buttons from merging with the address bar by placing something between them).
The rows are huge because they also have to accommodate the status bar and status info on active downloads, and somebody decided that rows shouldn't change height based on whether a download is active or not. I fixed it by doing "#downloadsRichListBox > richlistitem.download { height: 0em !important; }" which makes the rows for inactive downloads take up the same amount of space as they did in the previous download UI.
Of course, the design is still poor for space usage. Most users will prefer to have the Library window sized fairly big, to accommodate the lists in the History/Bookmark views. That makes the Window far too big for the Downloads view, which has way too much whitespace if you do that. You can resize the window down, but then it's too small for the other views. You have to keep resizing it depending on what you want to look at. This would be pretty easy to fix by displaying Downloads in a separate window, to allow you to resize it separately, but they'll never do that because that's what we had before and they changed it, so they'll never change it back.
(My prediction is that the fix they'll actually end up doing will be to make the History and Bookmarks view similarly space-wasting, and then they'll probably stick the whole thing in a tab to prevent you from resizing it, along with picking up the terrible theme from about:addons.)
Did you also notice that the download arrow panel (which has no keyboard shortcut) doesn't display download speeds?
so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?
And the answer is in the most obvious of places. From the cal manpage:
The cal utility displays a simple calendar in traditional format and ncal offers an alternative layout, more options and the date of Easter. The new format is a little cramped but it makes a year fit on a 25x80 terminal.
and
HISTORY: A cal command appeared in Version 5 AT&T UNIX. The ncal command appeared in FreeBSD 2.2.6. The output of the cal command is supposed to be bit for bit compatible to the original Unix cal command, because its output is processed by other programs like CGI scripts, that should not be broken.
Naturally I went and found FreeBSD's archived copy of cal (which does indeed print in horizontal format, and was replaced with ncal in 1998) before I thought to look at my own system's manpage.
Debian will do this too if you manually create a "CAL" symlink and call that instead of `cal`, so I delved into the source for its Debian packge.
The code responsible is here. It prints in the horizontal format if you call the program as "cal" (case-sensitive), and in the vertical format otherwise. I have no idea why it does this (the git repository only goes back to 2009, and I bet this code has been around for a lot longer than that), but there it is. On my Debian system, the program is installed as `ncal`, with `cal` being a symlink to `ncal`, so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?
OS X systems are case-insensitive by default, so your attempt at using `CAL` ended up running ncal via the `cal` symlink, but the check for calling name is case-sensitive, so the horizontal mode isn't triggered.
It does on Windows, unless you set various options that aren't really supported and are likely to break when the big theme refresh lands.
The new UI is happening, too. See, for instance, this blog post about the changes to customization that will restrict what you can do with the UI. Or the UX branch, which has curvy tabs already.
Extensions can probably address many of the problems they're introducing, but -- particularly with the theme changes -- it's really getting to the point where an actual fork would be easier.
apt-get install miredo (or just make use of dependencies to install it automatically.)
With Teredo, you get NAT traversal... and you only have to set it up once, rather than once per application. As a bonus, anything that can use Teredo can also use native IPv6, sidestepping the need to do NAT traversal once you have v6.
Oh, and Windows comes with a client too, so you don't have to worry about that.
Not to mention that even a single NAT is a pain in the neck. The amount of time I've spent futzing with my NAT at home, even when I understand it... compared to some of the people I know who can spend ages poking at their router and then still fail to do a port forward. Adding an extra NAT in front isn't going to make anything easier.
The above paragraph doesn't really add much to this conversation, I just needed an excuse to post this:
It's impossible because of the pidgeon hole principle. A v4 node has no way to uniquely identify every v6 node, so it can't specify which one it's trying to send traffic to.
The only sort-of workarounds are tunnels or, as you say, NAT. But you already dismissed these gateway and tunnelling mechanisms as "clumsy" in your original post, so I'm not sure why you're now suggesting them as the solution.
NAT64 has been done. It's not used because, as you accurately point out, embedded devices are doing a spectacularly poor job of supporting IPv6, which makes it easier to use the dual stack+NAT44 deployment that you so quickly dismiss as being unworkable.
And note that doing that works just fine. You can have v6-capable devices on the same network as v4-only devices. When you roll out v6 on the network, v6-capable devices will get and use it straight away, and the v4-only devices will get it when you upgrade them.
I'm not sure how you can say that's not incremential adoption.
Fully agreed that CGN = more expenses (and therefore undesired), but "more IPv6 _you_ deploy" is not a sufficient condition by itself. You also depend on what _others_ do, and if there is a lot of content available only over IPv4 you still need a CGN in one form or another.
Luckily Google, Youtube and some other large content provideers have already made the right thing and switched IPv6 on.
Youtube is a massive fraction of the bandwidth on the net. Between them, Google and Facebook having v6, I'm told that v6-enabling an ISP sees about 40-50% of their traffic go over v6 immediately. (My stat is from a University network providing access to residential dorms, so the figure should be fairly similar at residential ISPs once all their customers are actually using v6).
Halving your required CGN capacity is a decent chunk of savings.
The practical reason is that it makes life easier. NAT's a pain. That space isn't wasted if it's being used to make your life easier (and thus cheaper, which is something businesses should be interested in.)
Subnets are/64, and there's 330 million of them available in IPv6... per person on the planet. If you want to use one or two for extra networks, go for it. (And if you're thinking of conserving individual addresses rather than subnets... you really don't need to do that. A/64 is never going to run out of addresses.)
Which you can do just fine without NAT; use a separate subnet for the little network and you're done. No need to make your life harder than it already is by translating addresses over the boundary too.
Of course, the **AAs love IPv6, since it gets rid of the "an IP address does not identify an individual" defense since an IPv6 can be traced to a specific PC, and it's possible to forensically analyze said PC to figure out which individuals are most likely to have done the crime. (Not so with NATv6 - because all traffic is routed through one IPv6 address).
There are other useful stats, depending on what decisions you're making. For instance, if you want to know how much CGNAT capacity you need to provide, then the relevant stat is "how much of our traffic will go over v6 (and thus avoid the CGNAT)?"
I've seen the figure from a large university network that provides internet access to its dorms: it was 50%.by volume.
(Though perhaps the better stat would be the fraction of packets rather than of bandwidth.)
Slashdot Mirror
Why predict when you can just do?
Here is a totally hacked-together and very poorly written JS implementation. It'll constantly take 1000-sample surveys of a 315m population. The actual distribution of the population is printed at the top, and the results of the surveys are printed underneath, color-coded to make it easier to spot the results.
It's kinda slow and may well need a 64-bit browser, so I also made versions with 100m population size, 31.5m and 3.15m. If you're going to argue that those are too small a population size, then suck it up and wait for the 315m version to finish. You can always just fiddle with the values yourself by saving the page; the population and sample size variables are at the top. I only tested on Firefox 24.0a1.
(To anybody who reads this post after the above links break: sorry. Slashdot wouldn't let be inline the data: URIs, so I had to use tinyurl.)
Interesting theory about sample size,let me make it clear for you. Take a digital picture with the same number of pixels as the adult population(we'll even narrow it down to adults) then, pick a thousand random pixels to represent the picture. ... Whadda ya got? Crap.
Try it, then. This example is really easy to simulate with code.
Remember that the pixels in your picture can only have one of two values ("yes" and "no" -- map them to blue and red or whatever), and the question you're trying to answer is "are there more red pixels than blue pixels?", using 1000 randomly-selected pixels.
It doesn't need to cover all walks of life. It only needs to cover a representative sample of them.
Exactly. If that's a drop in the oceans, then it's a 130 million cubic kilometer drop that weighs 130 trillion tons.
There's always been a separate stop button, you just have to customize the toolbar so that the stop button is ordered before the reload button
Just be aware that you won't be able to do this after the upcoming changes to make customization more user-friendly go in. The address bar (and buttons to the left of it, including back/forward) are outside of the customizable area, so you won't be able to split out the stop and reload buttons (or prevent the back/forward buttons from merging with the address bar by placing something between them).
The rows are huge because they also have to accommodate the status bar and status info on active downloads, and somebody decided that rows shouldn't change height based on whether a download is active or not. I fixed it by doing "#downloadsRichListBox > richlistitem.download { height: 0em !important; }" which makes the rows for inactive downloads take up the same amount of space as they did in the previous download UI.
Of course, the design is still poor for space usage. Most users will prefer to have the Library window sized fairly big, to accommodate the lists in the History/Bookmark views. That makes the Window far too big for the Downloads view, which has way too much whitespace if you do that. You can resize the window down, but then it's too small for the other views. You have to keep resizing it depending on what you want to look at. This would be pretty easy to fix by displaying Downloads in a separate window, to allow you to resize it separately, but they'll never do that because that's what we had before and they changed it, so they'll never change it back.
(My prediction is that the fix they'll actually end up doing will be to make the History and Bookmarks view similarly space-wasting, and then they'll probably stick the whole thing in a tab to prevent you from resizing it, along with picking up the terrible theme from about:addons.)
Did you also notice that the download arrow panel (which has no keyboard shortcut) doesn't display download speeds?
The ability to stop the animation of an irritating animated image by pressing Esc.
You can't do any of those things with Paypal either. This of course renders Paypal entirely useless, and nobody will ever use it.
so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?
And the answer is in the most obvious of places. From the cal manpage:
The cal utility displays a simple calendar in traditional format and ncal offers an alternative layout, more options and the date of Easter. The new format is a little cramped but it makes a year fit on a 25x80 terminal.
and
HISTORY: A cal command appeared in Version 5 AT&T UNIX. The ncal command appeared in FreeBSD 2.2.6. The output of the cal command is supposed to be bit for bit compatible to the original Unix cal command, because its output is processed by other programs like CGI scripts, that should not be broken.
Naturally I went and found FreeBSD's archived copy of cal (which does indeed print in horizontal format, and was replaced with ncal in 1998) before I thought to look at my own system's manpage.
Debian will do this too if you manually create a "CAL" symlink and call that instead of `cal`, so I delved into the source for its Debian packge.
The code responsible is here. It prints in the horizontal format if you call the program as "cal" (case-sensitive), and in the vertical format otherwise. I have no idea why it does this (the git repository only goes back to 2009, and I bet this code has been around for a lot longer than that), but there it is. On my Debian system, the program is installed as `ncal`, with `cal` being a symlink to `ncal`, so perhaps the vertical mode is the intended format and the horizontal mode is for backwards compatibility with a previous `cal` tool?
OS X systems are case-insensitive by default, so your attempt at using `CAL` ended up running ncal via the `cal` symlink, but the check for calling name is case-sensitive, so the horizontal mode isn't triggered.
It does on Windows, unless you set various options that aren't really supported and are likely to break when the big theme refresh lands.
The new UI is happening, too. See, for instance, this blog post about the changes to customization that will restrict what you can do with the UI. Or the UX branch, which has curvy tabs already.
Extensions can probably address many of the problems they're introducing, but -- particularly with the theme changes -- it's really getting to the point where an actual fork would be easier.
Thank you.
This also saves me the effort of working out what it means when it asks me for "US£31.00".
apt-get install miredo (or just make use of dependencies to install it automatically.)
With Teredo, you get NAT traversal... and you only have to set it up once, rather than once per application. As a bonus, anything that can use Teredo can also use native IPv6, sidestepping the need to do NAT traversal once you have v6.
Oh, and Windows comes with a client too, so you don't have to worry about that.
Not to mention that even a single NAT is a pain in the neck. The amount of time I've spent futzing with my NAT at home, even when I understand it... compared to some of the people I know who can spend ages poking at their router and then still fail to do a port forward. Adding an extra NAT in front isn't going to make anything easier.
The above paragraph doesn't really add much to this conversation, I just needed an excuse to post this:
Your router get's 1 private IP
Get's? Just no.
It's impossible because of the pidgeon hole principle. A v4 node has no way to uniquely identify every v6 node, so it can't specify which one it's trying to send traffic to.
The only sort-of workarounds are tunnels or, as you say, NAT. But you already dismissed these gateway and tunnelling mechanisms as "clumsy" in your original post, so I'm not sure why you're now suggesting them as the solution.
NAT64 has been done. It's not used because, as you accurately point out, embedded devices are doing a spectacularly poor job of supporting IPv6, which makes it easier to use the dual stack+NAT44 deployment that you so quickly dismiss as being unworkable.
And note that doing that works just fine. You can have v6-capable devices on the same network as v4-only devices. When you roll out v6 on the network, v6-capable devices will get and use it straight away, and the v4-only devices will get it when you upgrade them.
I'm not sure how you can say that's not incremential adoption.
Fully agreed that CGN = more expenses (and therefore undesired), but "more IPv6 _you_ deploy" is not a sufficient condition by itself. You also depend on what _others_ do, and if there is a lot of content available only over IPv4 you still need a CGN in one form or another. Luckily Google, Youtube and some other large content provideers have already made the right thing and switched IPv6 on.
Youtube is a massive fraction of the bandwidth on the net. Between them, Google and Facebook having v6, I'm told that v6-enabling an ISP sees about 40-50% of their traffic go over v6 immediately. (My stat is from a University network providing access to residential dorms, so the figure should be fairly similar at residential ISPs once all their customers are actually using v6).
Halving your required CGN capacity is a decent chunk of savings.
The practical reason is that it makes life easier. NAT's a pain. That space isn't wasted if it's being used to make your life easier (and thus cheaper, which is something businesses should be interested in.)
Subnets are /64, and there's 330 million of them available in IPv6... per person on the planet. If you want to use one or two for extra networks, go for it. (And if you're thinking of conserving individual addresses rather than subnets... you really don't need to do that. A /64 is never going to run out of addresses.)
Which you can do just fine without NAT; use a separate subnet for the little network and you're done. No need to make your life harder than it already is by translating addresses over the boundary too.
Perhaps, but it's impossible, which rather puts a damper on doing it.
This is what we already did with IPv6.
As I understand it, the reason is because he doesn't want to use an EEG-based input.
NAT won't help much either then, since it only hides the least significant bits.
Of course, the **AAs love IPv6, since it gets rid of the "an IP address does not identify an individual" defense since an IPv6 can be traced to a specific PC, and it's possible to forensically analyze said PC to figure out which individuals are most likely to have done the crime. (Not so with NATv6 - because all traffic is routed through one IPv6 address).
Do people seriously still not know about privacy extensions?
There are other useful stats, depending on what decisions you're making. For instance, if you want to know how much CGNAT capacity you need to provide, then the relevant stat is "how much of our traffic will go over v6 (and thus avoid the CGNAT)?"
I've seen the figure from a large university network that provides internet access to its dorms: it was 50%.by volume.
(Though perhaps the better stat would be the fraction of packets rather than of bandwidth.)
I'm an early adopter of IPv6. I don't believe your claim that it offers me nothing, because it's been making my life easier for years now.
No way to transition, other than the way everybody uses to transition to it (plus the other few methods in that section).