Putting nuclear bombs on the tips of rockets and programming them to hit other parts of the Earth is also mere tool use. Tools are not inherently safe, and never have been. Autonomous tools are even less inherently safe. The most likely outcome of a failed singularity isn't being ruled by robot overlords, it's being dead.

Especially since, how would you discriminate between discrimination and outright greed?

That's exactly the problem. Doubt. A team like that needs good morale. Doubt your boss, drop the ball. Err pardon the expression.

I don't think our opinions are that far apart. I don't think we should ever have heard that conversation. The problem was that was a circumstance that couldn't have been unheard.

Anyway, I think we're starting to go in circles here. But I did want to say thanks for the discussion and that I hope you have a good weekend coming up.

I'd find it troubling if my boss hated me for reasons he should not be and may be under-paying me and a select group of my coworkers as a result of it.

Every year that goes by this just gets fuzzier and fuzzier. Soon your private chat is going to be picked up by somebody at the next table wearing Google Glass. Then the line will shift. And so on.

"what is your position on the forced sale of the clippers?"

Recording and leaking that audio was wrong. Since it was made public, through no fault of the NBA, it had to be dealt with. It wasn't a "what the US believes" sort of thing, it was an "oop, this got complicated fast, and our players may quit" sort of thing.

I do not believe the forced sale of the clippers is correct. I believe transmission of these photos is fine. this is what they deserve for their blind faith.

These two statements contradict each other. Sterling knows phone conversations can be recorded. He also knew he had an agreement with the NBA to behave. His blind faith lost him the Clippers. Now if you disagree with that statement we're actually a little closer to seeing eye to eye. We probably have differing ideas about where the line of liability should be drawn. Perhaps "phone chats are private but data on the cloud isn't", or something like that. The problem I have with that line of thought is the line between 'phone chat' and 'on the internet' is getting blurrier every year. Worse, we are not all masters of every domain we cross. You may know how to be safe on the internet, that doesn't mean you're super smart and are also super safe at getting your car repaired or at knowing when to use interest-free credit cards.

In either case you've got somebody who did something wrong. It sounds like tough-love right up until you're bitten by it.

I'm not talking about the bank with the bad security, I'm talking about the people actively sharing my love letters they know they don't have permission to send and how that weakens their position on certain topics.

"You're advocating privacy through self-control."

No, I'm not, I'm suggesting that the behaviour in question is damaging the value of privacy. By behaving as though celebrities have no expectation of privacy one thing you're not doing is strengthening the privacy of everybody else.

One of the reasons privacy is important is that you don't want somebody, be it the government or some random stranger, having something they can use against you. I don't have any problem with conceding that the NSA's behaviour is a much bigger deal, but when you break things down to their basic components the philosophy is still very much the same whether it's about extorting money or punishment for having that political bumper sticker on your car.

It's also possible to advocate something like privacy and immediately start fapping over unethically acquired photos because a lot of blood has left your brain. Take a guess which category this particular behaviour falls into,

It would be a better idea to just not download them. Oh, who am I kidding, nobody cares about privacy while they're holding their dick in their hand.

You get a shot at seeing boobies and all the sudden all those complaints you have about the NSA peeking at your files goes flying out the window. When that's brought up all the sudden we've got something worthwhile to spend our mod-points on. Cute.

Let me make this simple in case there's a post-fap-clearer-head lurking around this area of the thread: No, you do not have a good reason to acquire those photos. Yes, you are a bad person for grabbing them and sharing them. No, modding my posts down does not make me wrong about it. You lot, and you know who you are, are despicable.

Why is this comment modded off-topic? Not only is it perfectly on-topic, but it also illustrates why you assholes that are seeking to aquire these photos really shouldn't be!

because we couldn't possibly have good service from an ISP.

Don't most ISPs sell good service at a premium? I think that was the entire point with having poor service in the first place. The only other reason I could imagine would be to drive customers to the competitors, and that doesn't seem to make sense from a business point of view.

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.

I can come up with a couple of additional usages for some /64s. One /64 could be used to harden your recursive DNS resolver against poisoning. The 16 bit transaction ID in DNS is way too small. The entropy you can get from randomizing port numbers help a lot. But you will still only get a total of 32 bits of entropy that way. Some have gone to great lengths to squeeze extra entropy into a DNS request, for example by mixing lower case and upper case in the domain. But that doesn't give a lot of bits. If you allocate a /64 to the recursive DNS resolver, you can put 64 bits of entropy into the client IP, which instantly gives you more than a doubling of entropy almost for free.

A modern OS is a multi user system, imagine if each user could get their own IP address. You could allow users to use privileged port numbers on their own IP address, and all port numbers on their IP address would be protected from usage by other users. You could do this by responding to neighbor discovery for as many IPs in your link prefix as you have users on the node. But a more secure and more efficient approach would be to route a prefix to each node.

a prefix that just got compressed might get split quickly, and vice versa

There is no need to combine the routes, if there is still free entries in the CAM. Once the CAM is full and another entry need to be inserted, the pair which has been a candidate for combining for the longest time can then be updated. That algorithm would keep the number of updates down.

However as the number of routes approach the limit of what can be handled, even with combination of routes, the frequency of updates needing to combine and split entries will go up. It may be they are already doing this, some sources say the problem did cause reduced performance, which would be consistent with such behavior.

all Comcast needed to do was write "56" in their config files rather than "60"...

One has got to wonder if that's how it happened. Did some admin arbitrarily decide to write 60 in a configuration file, where he could/should have written 56, and then that was how it was going to be? Or did a lot of bean counters get together and decide on a policy (possibly not even based on real data), and then admins had to implement it like that without asking questions.

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.

Even in many areas where there is tough competition among ISPs, it is hard to find even one trying to capture those customers, who want IPv6. That's how bad it looks today. And that's why I would happily take a /60. Hopefully once IPv6 is the norm (which it likely will be before the end of the decade), the ISPs will start competing on prefix lengths as well.

I can't yet imagine what I would use more than a /60 for. But if I get a /60, I might soon come up with ideas on how to use a /56. All it takes to get that competition among ISPs started is two people independently of each other coming up with something really cool you can do to put your entire /60 to use.

Next, IPv6 addresses are of course 4 times larger than IPv4 addresses. Even if your IPv6 routing table has 5 times fewer entries, you're not getting a 5 times saving in memory. You're only getting a 5/4 times saving or tables that are 80% of the IPv4 - nowhere near as dramatic.

In IPv4 all 32 bits are used for routing, though on the backbone you tend to only accept /24s. In IPv6 the first 64 bits are used for routing, though on the backbone you tend to only accept /48s.

Either way, you only need twice as many bits in the CAM to handle an IPv6 route compared to IPv4. So what you call a 20% saving is more like a 60% saving. The picture is a bit more complicated, because two CAM entries at half the size is not the same as one of the full size. So you may have to decide at design time, how you are going to use that CAM.

Routing tables growing with the size of the network, in terms of # of entries - even if not at all fragmented.

I'd love to take part in solving that problem. Any realistic solution is going to start with a migration to IPv6. And I don't see how we could expect the solution to be deployed any faster, so if we start now, we could probably have it in production by 2040.

it is possible that IPv6 is actually too small to be able to solve routing scalability.

That algorithm has a major drawback. The address of a node depends on which links are up and which are not. You'd have to renumber your networks and update DNS, every time a link changing somewhere cause your address to change. If we assume that issue can be fixed, it doesn't really imply that addresses would have to be larger.

The algorithm in the paper assigns two identifications to each node. The first one could very well be the IPv6 address assigned to the node. The second address is computed based on the first address and structure of the network. However their routing looks awfully similar to source routing. So really the solution might just be to make source routing work.

I can think of a couple of other reasons to consider IPv6 addresses to be too short. That paper isn't one.

Teredo and 6to4 are two "automatic" tunnel protocols. Both embed IPv4 addresses inside IPv6 addresses. Due to the use of NAT, Teredo needs to embed two IPv4 addresses and a port number inside the IPv6 address. That doesn't leave room for a site-level-aggregator or host part. If you wanted one unified protocol which could replace both Teredo and 6to4, you'd need at least 192 bits in the IPv6 address.

After IPv6 showed up, people realized that it is sometimes convenient to embed cryptographic information inside the IP address. That was unthinkable with IPv4. With IPv6 it is doable, but you have to chose cryptographic primitives that are not exactly state of the art, due to 128 bits being a bit short for cryptographic values, and not all of them even being available for that purpose.