I'd argue that this all comes down to patents. The OoO/speculative execution methods in the P6 architecture would be patented, and those P6 patents ought to be expiring about now. That means that using the fast Intel method of speculation would make sense if you are designing a brand new processor with OoO execution. The older ARM chips did little/no out-of-order or speculative execution, so the cost of adding any particular variant is probably similar.
Meanwhile, because AMD was competing with Intel directly on x86, they had to produce processors with OoO execution for years to keep up. The P6 patents meant AMD created their own implementation of OoO execution, and now the patents are no longer an issue, the cost of redesigning the chips meant that AMD stuck to their existing methods.
In fact, Chromium was dropped from Wheezy recently since the version it was based on lost upstream support and security updates. The advice then was to run Jessie instead. Presumably that advice is now "don't run Chromium derivatives on Debian", unless testing has a supported kernel version.
Most likely the GP has a modem that handles VDSL and ADSL and someone connected the wrong line in the cabinet. If the modem switched protocols to VDSL, you'd get 40 Mb/s on an "ADSL" line - just not using ADSL.
It's still possible in daemontools to run a shell script wrapper from/etc/service/foo/run around some real server in Java/Erlang/whatever. Stopping the service with "svc -d/etc/service/foo" will then entirely fail to kill the server process. I would imagine that the systemd's cgroup suport would avoid this happening.
There's a reasonable argument for moving to 64-bit on security grounds too. The increase in virtual address space makes ASLR far more effective since there are many more options for positioning compared to 32-bit code. On top of that, any attacks are more likely to hit a unallocated page as opposed to anything useful (with some limitations of course).
You can do that easily enough as it is. One way is to set up multiple SSIDs per radio with separate PSKs. Another way is to use WPA2 Enterprise with one username/password pair per device.
My post certainly wasn't meant to recommend that it should be attempted! It was intended to reply to the OP's comment that:
If mainstream media sites get (automatically) blocked then perhaps the backlash might force TPTB into either removing the requirement to block or require the ISPs to use a blocking mechanism with less potential for collateral damage.
Blocking "mainstream media sites" would upset journalists more and get far more publicity. TPTB probably care more about their own sites being available and not having to pay more staff to do the work by hand. Either way, this will probably be fixed within the week.
Answering your actual question: perhaps, but I seriously doubt the torrent site will care much either way since they can no doubt get away with blaming Sky or the content industry for the blocks anyway. The cynical view is that they'd get far more self-promotion that way too...
If they were aiming for truly evil exploitation of automated blocking, they wouldn't block any of those. They'd get the DVLA tax disc renewal site blocked instead and, given the automatic fines now, you'd easily upset a twelfth of Sky's userbase who'd need to switch back to manual methods. Alternatively, you'd aim to block HMRC in late January and block the rare people doing tax-returns at the last minute...
Wikipedia looks to be more misleading than wrong in this case. It seems to be using "member of Parliament" to mean members of either House, whereas the term "Member of Parliament" is pretty much reserved for members of the House of Commons. In short, you can be a "member of Parliament" without being a "Member of Parliament"...
Finding APIs copyrightable could get extremely interesting if parts of HTML5 or new network protocols count and were implemented in GPL-licenced code first... Would that essentially prevent Microsoft and Apple from legally implementing those standards?
Traditionally, you had "spear phishing" attacks which had attackers sending malware or phishing emails directly to their targets. This is relatively easy to spot and filter. The "watering hole" attacks work by compromising a trusted third-party site used by the targets. For example, if your attacker know you read Slashdot or use some specialised forum site, they could attempt to compromise those sites and use them to host exploits as part of the normal pages (infected banner ads or modified page content).
My ideas on this would work less well, but still be reasonably effective: simply check that any non-withheld numbers are actually valid! I have seen a lot of (admittedly UK and not US) calls apparently coming from numbers that cannot possibly exist. For example you would see calls where the local part is too short, or simply see invalid area codes. If you know all the valid number formats and area codes for domestic calls, you can drop all calls that do not fit. I'd also suggest wildcard-blocking for end users, too.
Another option would be to have the telcos automatically and freely lookup return routes for each call. If the openly announced number has no reverse route the inbound call should be null-routed. You would then have three cases: valid-but-possibly-forged domestic numbers, withheld numbers and international/not-available.
By default, XP allows inbound NTLMv2 authentication from remote clients but does not use it outbound to authenticate to remote servers. The same setting that makes XP refuse LM/NTLM also enables outbound NTLMv2.
It looks like Virgin Media at least still do run NNTP servers in the UK if this page is to be believed, although I have not used them in years: http://help.virginmedia.com/system/selfservice.controller?CMD=VIEW_ARTICLE&ARTICLE_ID=3525. Most ISPs were in the habit of dropping the binary groups even 10 years ago on storage and bandwidth grounds, which would also reduce the exposure to copyright issues.
Enough previous trolling to get a terrible karma rating (dropping initial scores to -1), plus a 50:50 moderation split between Troll and Insightful, apparently.
If I had any mod points, I'd have modded you Insightful for that. I was wondering myself why Apache itself should care about the header at all, since DNT should not affect the server's access or error logging. Unless the Apache developers intend to track every visitor by default, of course, in which case I can see nginx and the like becoming popular on scaling grounds...
Cisco's VPN client definitely has this in password form, where you have a group user/password plus additional username/password. It also has certificate authentication, but I don't know if it allows certificates to be used in place of passwords while retaining the group+user authentication though. The open-source vpnc client apparently does not support certificate authentication either.
I'd argue that this all comes down to patents. The OoO/speculative execution methods in the P6 architecture would be patented, and those P6 patents ought to be expiring about now. That means that using the fast Intel method of speculation would make sense if you are designing a brand new processor with OoO execution. The older ARM chips did little/no out-of-order or speculative execution, so the cost of adding any particular variant is probably similar.
Meanwhile, because AMD was competing with Intel directly on x86, they had to produce processors with OoO execution for years to keep up. The P6 patents meant AMD created their own implementation of OoO execution, and now the patents are no longer an issue, the cost of redesigning the chips meant that AMD stuck to their existing methods.
Using "apt-get install sysvinit-core" seems to work fine for reverting systemd.
It works for Google, Facebook and YouTube, and has done since mid-2012.
In fact, Chromium was dropped from Wheezy recently since the version it was based on lost upstream support and security updates. The advice then was to run Jessie instead. Presumably that advice is now "don't run Chromium derivatives on Debian", unless testing has a supported kernel version.
It's using HTML5 tags here - no Flash needed! Not even media.autoplay.enabled=false stops it. :(
Most likely the GP has a modem that handles VDSL and ADSL and someone connected the wrong line in the cabinet. If the modem switched protocols to VDSL, you'd get 40 Mb/s on an "ADSL" line - just not using ADSL.
Iceweasel is just the current Firefox ESR rebranded. Maybe the mozilla.debian.net repository would help if you want a current Firefox equivalent.
It's still possible in daemontools to run a shell script wrapper from /etc/service/foo/run around some real server in Java/Erlang/whatever. Stopping the service with "svc -d /etc/service/foo" will then entirely fail to kill the server process. I would imagine that the systemd's cgroup suport would avoid this happening.
There's a reasonable argument for moving to 64-bit on security grounds too. The increase in virtual address space makes ASLR far more effective since there are many more options for positioning compared to 32-bit code. On top of that, any attacks are more likely to hit a unallocated page as opposed to anything useful (with some limitations of course).
You can do that easily enough as it is. One way is to set up multiple SSIDs per radio with separate PSKs. Another way is to use WPA2 Enterprise with one username/password pair per device.
My post certainly wasn't meant to recommend that it should be attempted! It was intended to reply to the OP's comment that:
Blocking "mainstream media sites" would upset journalists more and get far more publicity. TPTB probably care more about their own sites being available and not having to pay more staff to do the work by hand. Either way, this will probably be fixed within the week.
Answering your actual question: perhaps, but I seriously doubt the torrent site will care much either way since they can no doubt get away with blaming Sky or the content industry for the blocks anyway. The cynical view is that they'd get far more self-promotion that way too...
If they were aiming for truly evil exploitation of automated blocking, they wouldn't block any of those. They'd get the DVLA tax disc renewal site blocked instead and, given the automatic fines now, you'd easily upset a twelfth of Sky's userbase who'd need to switch back to manual methods. Alternatively, you'd aim to block HMRC in late January and block the rare people doing tax-returns at the last minute...
Wikipedia looks to be more misleading than wrong in this case. It seems to be using "member of Parliament" to mean members of either House, whereas the term "Member of Parliament" is pretty much reserved for members of the House of Commons. In short, you can be a "member of Parliament" without being a "Member of Parliament"...
Finding APIs copyrightable could get extremely interesting if parts of HTML5 or new network protocols count and were implemented in GPL-licenced code first... Would that essentially prevent Microsoft and Apple from legally implementing those standards?
Traditionally, you had "spear phishing" attacks which had attackers sending malware or phishing emails directly to their targets. This is relatively easy to spot and filter. The "watering hole" attacks work by compromising a trusted third-party site used by the targets. For example, if your attacker know you read Slashdot or use some specialised forum site, they could attempt to compromise those sites and use them to host exploits as part of the normal pages (infected banner ads or modified page content).
My ideas on this would work less well, but still be reasonably effective: simply check that any non-withheld numbers are actually valid! I have seen a lot of (admittedly UK and not US) calls apparently coming from numbers that cannot possibly exist. For example you would see calls where the local part is too short, or simply see invalid area codes. If you know all the valid number formats and area codes for domestic calls, you can drop all calls that do not fit. I'd also suggest wildcard-blocking for end users, too.
Another option would be to have the telcos automatically and freely lookup return routes for each call. If the openly announced number has no reverse route the inbound call should be null-routed. You would then have three cases: valid-but-possibly-forged domestic numbers, withheld numbers and international/not-available.
By default, XP allows inbound NTLMv2 authentication from remote clients but does not use it outbound to authenticate to remote servers. The same setting that makes XP refuse LM/NTLM also enables outbound NTLMv2.
It looks like Virgin Media at least still do run NNTP servers in the UK if this page is to be believed, although I have not used them in years: http://help.virginmedia.com/system/selfservice.controller?CMD=VIEW_ARTICLE&ARTICLE_ID=3525. Most ISPs were in the habit of dropping the binary groups even 10 years ago on storage and bandwidth grounds, which would also reduce the exposure to copyright issues.
Enough previous trolling to get a terrible karma rating (dropping initial scores to -1), plus a 50:50 moderation split between Troll and Insightful, apparently.
Hmm ... looks like it got partially reverted. The configuration change is present but commented out: https://github.com/apache/httpd/commit/3dd6fb6882ae2b453c90d51e777e88bc420a0cb1.
If I had any mod points, I'd have modded you Insightful for that. I was wondering myself why Apache itself should care about the header at all, since DNT should not affect the server's access or error logging. Unless the Apache developers intend to track every visitor by default, of course, in which case I can see nginx and the like becoming popular on scaling grounds...
Isn't that what the flag is for?
Wouldn't link-local addresses be used for the transfer network?
Cisco's VPN client definitely has this in password form, where you have a group user/password plus additional username/password. It also has certificate authentication, but I don't know if it allows certificates to be used in place of passwords while retaining the group+user authentication though. The open-source vpnc client apparently does not support certificate authentication either.
What about using git-annexe to store large binaries?