In most cases, the splitter will be hard-wired to the antenna. Installing the filter on the antenna side will require cutting into the existing coaxial cable, which most people will require engineers to do. The affected houses will probably get a small box that plugs in between the aerial and the TV or set-top box. Something similar was done when Channel 5 was first broadcast on analogue to prevent interference with video recorders. Pretty much anyone can handle plugging the filter box in, which means the installation costs are zero.

It would have helped if the summary had pointed at the actual Nature article or the ArXiv preprint.

This post sums up the concept well enough. Each OAM value (usually associated with the letter l) means that the phase of the light around the beam centre changes by 2pi. So, l=0 is no change in phase, l=1 is 2pi change in phase and so on. There's no upper limit to OAM values, and light waves with different OAM are orthogonal, so you can theoretically have infinitely many beams with no interference between them. There are no more theoretical problems with this than having say an infinite number of GigE cards and cables. There is no way you could build something that actually uses an infinite number of beams with individual vorticities, of course, but that's the same with the infinite gigabit links too.

RBS weren't fully taken over (Wiki says 84%); I suppose the government could claim the other 16% too but it's unlikely to happen.

Dynamic typing is common in functional programming languages but not essential; Haskell is statically typed and is one of the purer functional languages.

While that's true, a standard (and popular library) for SCTP-over-UDP could be created. At most, you'd need a single well-known UDP port for inbound SCTP-over-UDP (9989 is suggested by the Internet draft for this). SCTP ports would be used to distinguish between separate SCTP-using services on the server. I'm sure that the existing Linux and BSD SCTP stacks could support this with little effort. Firewalls that only permit HTTP/HTTPS would block this variant, but it would work well enough through NATs, especially if the multiple-endpoint parts of standard SCTP were left out.

The issue is that with unsalted hashes, you only need to use brute-force once to generate your rainbow table, at which point all the passwords are cracked simultaneously. (OK, in practice you would not wait for a full rainbow table to be produced; you'd download a list of pre-computed common passwords and start with those.) With salt and a strong password, you still have to do all of that brute-force work just to obtain a single password, even if you have several GPUs doing the calculations.

I'd forgotten about the Sprint 2600:: address. :(

I suspect that the real answer was that fc00::/7 was created just to keep all the anti-publicly-allocated-address people happy, and was never taken that seriously. All the real connectivity would use link-local or suitably firewalled global address space. VPNs between separate companies would be handled via IPSEC, and no new addresses would be needed. Of course, that works fine in theory, but will probably never happen in reality...

Actually, that shouldn't be too hard to do; just replace the initial "2001:" of your global prefix with "fc00:" and you should be done. (You could probably do something similar with 6to4, where the network prefix is defined by your external IPv4 address.)

Not living in the US, I wouldn't know. All I have to go on are the reports on /. and other such sites, which give the impression that those speeds are far from the norm. (If they are, this whole thread is rather pointless, apart from the issue of rural schools.) Not that 100mbit+ internet for end-users is that common yet outside the US either...

That'd be done either by whatever organisation runs the local school system or some group set up specifically as an ISP for the schools. (Assuming we're using JANET as an example...)

This excuse comes up way too often. I imagine it's perfectly easy to wire up New York and its surrounding areas for not much more than Sweden. Meanwhile, there seems to be nowhere that has 100Mb/s Internet in the US that isn't sat on a university WAN. There is nothing at all stopping an ultrafast ISP being set up specifically in San Francisco, New York or other cities and ignoring anywhere remotely rural.

I imagine he's using Virgin at home, in which case the speed doubling is their doing, not the poster's choice...

Blocking by IP address appears to be near-impossible now; I fail to see that IPv6 will make it worse.

On the subject of blocking IPv6 hosts, if a /64 (or whatever) is owned entirely by the organisation you want to block, blocking is easy. If it's shared with other users, though, a lot will depend on the host company's willingness to help. Some may somehow force a specific address per client (DHCPv6?) which makes blocking no harder than at present, or be willing to act on take-down requests. With unhelpful host companies, the offending site could try fast-flux DNS techniques to temporary addresses within the local /64. At that point I suspect the whole /64 would be blocked regardless of collateral damage. Alternatively, DNS blocks could be used, with the same effectiveness that we see today.

Ultimately though, the thing to remember is that at some point, people need to know what the present address is. I imagine that the address distribution methods will be somehow disrupted to prevent updates and then the IPs will be blocked. That applies regardless of the underlying protocol!

Apparently, the SDK has always had a basic compiler included.

As for alternatives, that's probably what will happen; people without MSDN access will just use GCC or Clang instead. However, given that the open source alternatives are far better supported under Linux or OS X, why write software for Windows? We're more likely to get new software projects targeting Linux, OS X or the mobile equivalents (Android/iOS) and ignoring Windows entirely. Alternatively, we get more web apps hosted on Linux servers that do not care about the type of client used. Either way, Microsoft and Windows users end up losing out on native software.

That's interesting. I knew you could get +5 Flamebait/Troll by combinations of Interesting+2*Troll+lots of Underrated mods (like these posts), but never a pure +5 with no mod type other than Underrated. I thought you needed at least one "normal" mod type for it to show up.