AIUI we have a situation where some miners are enforcing stricter rules than others.

If the strict miners significantly out mine the loose ones then not much will happen. The blocks that don't pass the strict rules will quickly be forked off and die and noone sensible accepts a one-block-confirmed transaction for anything important.

However if the loose miners out mine the strict miners you get a long lasting fork between the strict and loose miners. People whose clients only enforce the loose rules will see what is going on in the loose fork. People whose clients enforce the strict rules will see what is going on in the strict fork. The two forks will most likely contain most of the same transactions but there may be some cases where someone manages to engineer that the same bitcoins are transferred to different places in the two forks, newly mined coins will also go to different people in the two forks.

If the mining rate of strict and loose miners are approximately equal then you have a mess. The two forks could run in paralell for some time and then the strict fork could either hit a run of good luck or be boosted by miners switching to the strict rules and kill the loose fork. AIUI that is the present situation.

It is most likely this will end with the strict miners outnumbering the loose ones, any transactions that only happened on a loose branch will then be killed.

It does but it isn't always practical to use it.

If all your users do is create and edit files then sure you can use the --update flag and omit the --delete flag making the rsync operation a lot safer.

but if your users are more active that is not so practical. Assuming this storage is used as a work area by developers they are likely to be doing things like deleting files and sometimes even deleting files and replacing them with a copy of an older file (for example deleting a dirty copy of a source tree and replacing it with a clean one). So to copy all the changes you need to use rsync in a far more agressive mode without the --update flag and with the --delete flag.

It was probablly a mistake to put the agressive rsync in a cronjob, it would almost certainly have sufficed to use a less agressive rsync in the cronjob and only use the agressive one manually for the final sync but I can see how someone inexperianced would fail to think of that.

It was also of-course a mistake not to defuse the old server when decomissioning it. Ideally by BOTH disabling the cronjobs and disabling the credentials that allow the decomissioend server to talk to the active servers.

Normal NATs use one internet ip:port combination for each active (activity may be determined by timeouts and/or by watching for connection closures) internal ip:port combination. That means you can only have ~65K active outgoing connections per internet IP.

You could build a high ratio NAT which didn't do that. Technically for basic connectivity to work the source IP/port combination only needs to be unique for a given destination server (possiblly even a given port on a given destination server) but building such a thing would totally break most nat traversal techniques and hence break things like P2P and online gaming even worse than a normal NAT would.

NAT also really doesn't help much on the server side because people expect their services to be on well-known ports. For some services you can host multiple hostnames on the same ip either by serving them from the same server or using a reverse proxy but for others that is less practical. One specific case of interest is https. Right now for https services that matter people want a dedicated IP because of older clients that don't support SNI but as windows XP and android 2.x decline that will become less of an issue.

The unusual thing about comcast is they are an insanely large triple play provider with a heavy reliance on IP. Their triple play services ended up using about 8-9 IP addresses per household* . Of these only one (the customer's internet device) needed to be a public IP but comcast's system was so damn large and IP hungry that they ran out of space in net10 and had to start using public IPv4 addresses for internal management.

So while most non-botique access providers were probablly thinking "meh, when the IPv4 crises hits we can keep going almost indefinitely with CGN, lets let someone else be the early adopter of IPv6" comcast didn't have that buffer. They faced a stark choice between stopping expansion of services, federating their network**, or adopting IPv6. They chose IPv6.

That is why comcast is so ahead of the game on IPv6.

* http://meetings.ripe.net/ripe-...
** That is splitting it into multiple sections to allow IP reuse and redesigning their management systems to cope with it.

The big legacy assignments predate those agreements. It is much less clear legally whether ICANN and/or the RIRs have the right to reclaim legacy space than with more recent assignments.

There is also the question of how much legal power ICANN has over IP addresses in the first place. Is there actually any law that you should route traffic for an IP address to the organsation that ICANN says owns it? Is there any law preventing the teir 1 providers from collectively telling ICANN to go fuck themselves and setting up their own body to decide who has the right to advertise IPv4 addresses on their networks and hence the internet? I'm not aware of any.

And there isn't much point, reclaiming those blocks would have just slightly delayed the end of cheap and easy IPv4. Since the widespread adoption of IPv6 is highly dependent on the end of cheap and easy IPv4 I doubt reclaiming those blocks would have made much difference in the end.

If the price to buy or lease IPv4 addresses rises people will reevaluate what applications really need a public IPv4 address and what applications can manage with IPv6 and/or private/shared IPv4.

Windows vista and android 3.x introduced support for server name indication which allows mulitiple https sites to be hosted behind the same IP address. With windows XP and android 2.x in decline more people will find it acceptable to host their https sites on shared IPs. Already some hosting providers are offering SNI based shared https hosting. If IPv4 addresses become too expensive I would expect hosting providers to introduce SNI reverse load balancers to allow v6 only customer servers/vms to serve v4 only clients.

The big access providers who long dragged their heels on IPv6 are looking at it seriously. Usually in conjunction with a mechanism to provide access to servers on the IPv4 internet without giving every end user a public IPv4 address such as DS-LITE, NAT64/464XLAT or traditional CGN. This will mean an increase in the proportion of users who can access IPv6 only resources and possiblly also a freeing up of IPv4 IPs.

So IPv4 addresses are likely to be a pretty volatile asset. They will probablly peak higher than their current price (lets be honest the current price of about $10/IP* is peanuts) but they may also drop off a cliff as the IPv6 transition progresses.

Also there is provision in the RIR rules for permanently transferring address blocks to another organision (a sale) subject to restrictions at some RIRs that address use must be justified (which can make selling the bigger blocks problematic, few if any organisations would be able to swing a believable justification for a /8). I'm not sure there are any similar provisions for temporary transfers (a lease) of IPs only. Of course IPs can be tempoerrally allocated to customers but that really only works if your organsiation wants to be in the ISP or hosting buisness.

* http://ipv4marketgroup.com/bro...

And as a general rule given a correctly exposed scene (no sensor saturation) darker things are harder than lighter things. To judge 3D shapes from a 2D image we (both humans and computers) rely on the fact that surfaces at different angles to the light source have different apparent shades but the darker the object is the less light will be reflected and therefore the smaller your "signal" (difference in the light reflected by points on the object at different angles) is.

Was it really only "a few years" or are you forgetting how long it has been (easy to do)? was this machine a fully functional workstation (including stuff like web browsers and if so which web browser)? or was it just a toy/special purpose box?

A few years ago gcc itself switched from C to C++ https://lwn.net/Articles/54245... . Both of the two main web rendering engines (geko and webkit) are C++. One of the two main desktop widget sets is C++.

I agree C++ has it's problems, templates look good in microbenchmarks but can easilly blow up code size. Memory requirements for linking large C++ projects can be horrific but the fact remains C++ is far more widely used and supported than any other object-orientated native-compiled language. It's position may not be quite as important as C but it's not far off.

I can see a few ways informatoin could leak in a dual stack situation involving a VPN that would not happen if everything was IPv4 only

1: The users local connectivity is dual stack (or v6 only) but the VPN is IPv4 only. The result is IPv4 goes via the VPN but IPv6 doesn't. The user thinks the VPN is hiding the origin of their traffic but it isn't hiding the origin of all of it. With a bit of extra work it may also be possible for a website or an attacker in the network to tie the direct v6 address(es) to the VPN v4 address.
2: IPv6 traffic does go via the VPN but addresses are generated in such a way that the users MAC address is revealed (for example the user has a network behind the VPN and that network uses MAC based IP autoconfiguration). This MAC address can later be tied
3: The machine has an IPv6 address from the local ISP. Even if routing tables or firewall configurations are such that this address won't be used for making connections an application could still mistakenly send it as part of a payload. The same could in principle happen with IPv4 but it's much less likely due to pervasive use of NAT.

That's the problem. That isn't an easy question to answer.

What does "associated with commerical activities" mean? does running adverts or having a donate button to help pay for hosting count? does posting links to your activities on commercial sites that runs adverts like youtube, facebook and twitter count even if none of the money from those adverts comes to me? does saying you are looking for work on a blog count?

If something like this goes through expect broad interpretations of "commerical" to be used as a stick if someone doesn't like you and/or wants to take over your domain.

It seems far moe likely to me it was rockstar/take 2's own doing. The release plan they went for means the hardcore fans will have ended up buying the game THREE TIMES.

No, java is something that people want/need which is supplied with bundled crapware that you have to remember to opt out of.

What TFA doesn't make clear is whether this new yahoo thing will be instead of the ask toolbar bundling or in addition to it.

What if your source for this claim? Searching for "opt out illegal" doesn't seem to turn up anything relavent.

It's perfectly possible technically.

Your carrier can easilly find out what sites you are connecting to and what IPs/ports you are using to do it (and if they are using CGN how those IP/port combinations may through their nat). They can easilly pass that information on to the site operator. For unencrypted protocols they can trivilly inject additional headers. For encrypted protocols they can't inject headers as easilly but they could easilly arrange with the site owner to pass the information over another channel.

Your only real defense is to use a VPN to hide the details of the mobile carrier from the target site and vice-versa. Yes this does mean additional cost and likely performance degredation.

Accelerated aging tests are far from perfect. So in a fast changing buisness there will always be the risk of a flaw that slips past testing but becomes apparent once the product has been out in the wild for a while.