Living in the UK if that happened I'd unplug it immediately and investigate the fault
Indeed, in the UK we use very high rated (30A@240V is typical) socket circuits and lighting is generally* separate. So if a 1KW appliance causes a power dip for lights it's most likely (but not always) indicative of a problem.
Having said that filament lights are fairly sensitive to voltage changes and the human eye is very sensitive to even very slight light level changes if they happen suddenly. As a result of this it's perfectly possible to notice a change in the lighting even while the voltage remains within accepted limits. It's just that with typical UK wiring it takes something bigger than a SMT rework station to trigger it .
* Though you do sometimes see a little mixing. Posher houses in the UK often have 2A or 5A sockets on the lighting circuit for lamps controlled by lightswitches and sometimes you see fixed lighting connected via a fused connection unit on a socket circuit (especially if it was an addon).
The US also isn't your typical country. It's far more comparable to the EU as a whole than to any one EU country. We have
5 cities in europe (four of which are in the EU). 2 cities in north america 3 cities in east asia
Having said that i'm always very dubious of this sort of thing. I don't see anything in the article about how the critera were assessed and weighted. Nor any information on what citiees were assesed and didn't make the cut. I don't think this should be regarded as anything more than one reporter's opinion.
1: Initially all servers are up 2: user starts browsing your site. His DNS packets go to DNS1 since that is the closest DNS server to his recursive resolver. DNS1 returns the IP of WWW1 which is cached by the user's recursive resolver and possibly his OS. 3: site1 (including DNS1 and WWW1) goes down. 4: The user clicks a link within your site. The browser asks the OS to look up the name, the OS either looks in it's DNS cache and returns the IP of WWW1 or contacts it's local recursive resolver which looks in it's cache and returns the IP of WWW1. 5: The browser tries and fails to connect to WWW1, the user eventually gets a timeout message if they can be bothered to wait long enough. 6: The user hits the refresh button and the browser tries again but continues to get connection timeouts until the DNS cache expires the record, contacts DNS2 and gets the IP for WWW2.
(it can be used for other services, but, in practice, isn't).
And there is a reason for that. Using anycast for a stateful protocol (e.g. anything TCP based) means that routing changes that would normally be harmless (that is routing changes which mean the packets still get to you but enter your network on a different interface) can break open connections even when all your systems are up. In the worst case if routing is really unstable or if someone has done some dumb load balancing then they may not be able to complete a connection at all.
You need to deal with the possibility of both individual EC2 instances dying and a whole availability zone dying in your application architecture. Amazon provides tools to help with this like load balancing that can operate over multiple availability zones and database service that are replicated across multiple availability zones but you have to actually use those tools if you want to build a reliable application.
Short TTLs are good only for changes (i.e. TTL at 24 hours, then set it to 12 hours 24 hours before an IP migration, then 4 hours 12 hours before a migration, then 1 hour 4 hours before a migration, then 5 minutes 1 hour before a migration, then to 24 hours after the migration is done), obviously set in seconds
Which works fine for planned migrations, useless for unplanned ones.
The down one won't ever announce itselft
Sure once a DNS server goes down it will stop sending responses regardless of whether you used anycast or the traditional system of just listing multiple DNS server IPs but responses it has already sent will continue to be used by clients until their TTL expires.
To make anycast useful without low DNS TTLs you would need to anycast not just the DNS servers but the servers they point to as well. However anycasting TCP based services causes broken connections if routing changes.
Most clients either won't move on to a second IP at all or will only move on once the OS times out the first TCP connection. And OS TCP connection timeouts are long enough that most users won't put up with them for interactive services.
A better strategy is to put a DNS server in each datacenter, make the TTLs short and set things up to automatically remove records if a server goes offline. This works much better because DNS fallback timeouts are much shorter than TCP connection timeouts.
From reading the wikipedia article I get the impression that lightsquared got very close to getting away with it. I get the impression that the reason they didn't get away with it was because the service they were stepping on was GPS which is used by damn near everyone. So it gave them a LOT of opponents both military and civillian.
We were discussing the implications of all the cars at a stoplight moving off in unison (proposed by Daetrin several levels up the post tree) which would produce a tightly packet convoy. Great for road usage efficency, not so great if something unexpected happens.
An alternative would be to have the cars drive like human drivers are supposed to* leaving a sufficient gap that whatever the driver in front does they can stop. Of cours that would probably mean lower road capacities than we have today.
The problem is different cars will most likely have different characteristics.
So if you have a group of closely spaced cars and something (the computer is unlikely to be able to reliablly identify what) steps out in front of you. Do you brake as hard as you can to maximise the chance of saving the life of whatever stepped out in front of you but also risking causing a pileup if the cars behind you have weaker breaks then you do or do you break based on some estimate of the characteristics of the worst brakes in the convoy and hit whatever is in front of you harder?
I think there are a couple of things that contribute to that
1: example programs in textbooks/lecture slides are very often commented in the style you show. This is done because those programs have to be understandable to people who are just starting to learn the language but it also means students may come to think that comments like this should be in regular code. 2: teachers order their students to comment code but either they don't bother to teach their students about good commenting or their students don't "get it" when they are taught.
On indiegogo campaigns can be set up as "Flexible Funding" and the hosts get whatever is pledged (minus 9% for fees).
And even if a campaign is fixed funding (as this one was) it seems indiegogo charge immediately and refund if they have to.
I couldn't seem to find any specifics on how things are handled if a campaign fails. In particular does indigogo pay the payment processing fees or do those come out of your refund?
third world countries where they don't put communication lines in the ground?
I don't know where you live but it's not just third world countries that have overhead telecoms gear.
Here in the UK while city centers and newer suburbs don't tend to have poles older suburbs seem to use a hybrid system where the multipair cable runs in ducts and then up a pole then the final connection to the house (the "dropwire") runs overhead and rural areas often seem to be pure overhead.
In the USA I believe pure telephone poles are actually pretty rare. Normal US practice seems to be to use shared poles that are owned by the power company.
in Europe, most Internet Exchanges are public peering.
They offer public peering certainly but if you are going to max out a port communicating with one peer then there is little point pushing the traffic through a public peering lan
This is why Netflix/YouTube/etc will allow anyone to peer at any IX in the USA, if you can reach at least 100mb/s of 95th percentile. You still need to setup a private port.
If you look at netflix's peering policy you will see that they have both public and private peering available in both the US and europe. They state a minimum traffic level for private peering for obvious reasons. They don't seem to state a maximum for public peering.
Google seems to be pretty similar though they don't explictly state what the minimum is for private peering..
The BBC explicitly state that any peer pusing more than 10Mbps over a public exchange may be requested to move to private peering.
AIUI there are two types of 64-bit wine setup. A pure 64-bit wine and a WoW64 wine with the former only able to run 64-bit apps while the latter uses a 32-bit wine to run 32-bit apps within the context of the 64-bit wine. I don't see any techical reason why such a system couldn't run 16 bit apps but I couldn't findd any documentation either way. Indeed in general the ability of wine to run 16 bit apps seems to be almost totally undocumented.
It's a place where providers peer when they are not exchanging enough traffic to justify private peering. Exchange point connections are cheap compared to transit but expensive compared to private peering links. Traffic from major access providers to the likes of google is unlikely to go through an internet exchange because with that volume of traffic private peering is more economical.
Which is not to say the 40% figure is true, it's just to say that traffic on an internet exchange is not a reprepsenative sample of internet traffic
If this is true there's a vanishingly small but nonzero chance of recovering any private key
There is a vanishishingly small but nonzero chance of recovering a private key by simply guessing it's factors.
Crypto is a game of probabilities. The aim is to reduce the probability of compromise to a level you consider negligable. Usually you try to reduce what you belive to be the probability of compromise way beyond the level you consider negligable in case your assumptions in calculating the probability were wrong. Short of a one time pad (which has it's own issues) you can never reduce it to zero.
poorly-written RNGs simply increase that chance spectacularly.
According to the google blog post* the built in SSL stuff is fortunately not affected. So apps that simply act as clients over SSL should be fine. How many applications are there really that need crypto and/or secure random numbers other than SSL. I would think not that many and I would hope that most reputable designers of such applications would have heard about this and be working on an application side fix by now.
One big security problem with andriod is the distribution model. Google makes andriod and distributes it to their OEM partners (and to the general public though sometimes with a delay). The OEMs then customise it and pass it on to their users and in most cases (nexus excepted) all updates go through the OEM.
The result is you get the situation of there being lots of older smartphones out there that are still perfectly usable but are no longer able to receive security updates in the regular manner because the OEM can no longer be bothered updating them. Sometimes it's possible to unlock the bootloader and install an unofficial build but that is at best something that requires you to be fairly technical and at worst something where even a computer expert like me can find myself in a dead end*.
* For example htc officially offers a bootloader unlock process but when I tried it on my brother's old wildfire the software version on it was too new to apply the RUU needed for the bootloader unlock process.
"Applications that establish TLS/SSL connections using the HttpClient and java.net classes are not affected as those classes do seed the OpenSSL PRNG with values from/dev/urandom."
I would expect a two pronged attack on this with both a system side fix (for devices that are still getting updates) and application side fixes as app developers try to cover their users regardless of what version of andriod they are using.
Users using non-market apps or apps from vendors who don't get the memo on smartphones that are no longer getting updates will of course be SOL.
Average bandwidth (aka data transferred) and 95th percentile bandwidth are both imperfect measures of "how much of our capacity requirements is this user responsible for".
You don't need a perfect measure just one good enough to weed out users who are using far more capacity than they are paying for.
The most recent financial statment I could find for mozilla is the 2011 one. In it is this gem.
"Mozilla entered into a contract with a search engine provider for royalties which expires November 2014. The previous contract term expired in November 2011. Approximately 85% and 84% of royalty revenue for 2011 and 2010, respectively, was derived from this contract."
Now the default search engine provider in mozilla browsers is google (there was talk of changing it but this proved very unpopular). So this most likely means that most of mozilla revenue is coming from people using google through the browser search box. Google can pay mozilla for those searches because google gets advertising revenue from them.
So while mozilla may try a few things to reign in the most abusive advertiser practices I doubt they would do anything that seriously threatens the industry.
Server 2003 installs by default, as "Workstation/Pro" desktop class OS - you modularly ADD server modules to it, as is needed...
Maybe so but the fact that you can add those features and the fact you can allow more than a handful of clients for file and print serving makes it a "server edition".
* I think you're attempting to state, perhaps, that XP 64 had all the PATCHES that later caught it up to Server 2003... right?
Server 2003 is NT5.2. So is windows XP professional x64 edition. Both use the same hotfixes, service packs and drivers (though drivers can support more than one version). They are by all reasonable measures different editions of the same version just like 2K pro and 2K server were different editions of the same version. Presumablly it was marketed as XP so they didn't have to explain to customers why they had to use a 64-bit OS to get the new version.
The obvious answer is that the visible officer will prevent violations. If you see the cop and don't slow down, you deserve the ticket. Prevention is the primary purpose of the law, not punishment after the fact. It is because of that philosophy that we have the right to a fair trial and are presumed innocent until proven otherwise.
The correct answer is that noone really knows. The only way to find out for sure would be to do a controlled experiment where in two otherwise identical places you used visible and invisible officers. Then have a set of data collectors (SEPERATE from the officers) to monitor the rate of violations.
The visible officer will clearly reduce violations in his presence but may cause people to slow down for the cop and then speed up again as soon as he is out of sight*. The hidden officer will have less immediate affect but once people rack up a few fines and/or points on their license** they are likely to change their behaviour everywhere, not just where they can see an officer.
* Which could ironically increase the number of violations by splitting one long violation into two shorter ones. ** This is a UK concept, not sure if you have an equivilent over an america.
Slashdot Mirror
Living in the UK if that happened I'd unplug it immediately and investigate the fault
Indeed, in the UK we use very high rated (30A@240V is typical) socket circuits and lighting is generally* separate. So if a 1KW appliance causes a power dip for lights it's most likely (but not always) indicative of a problem.
Having said that filament lights are fairly sensitive to voltage changes and the human eye is very sensitive to even very slight light level changes if they happen suddenly. As a result of this it's perfectly possible to notice a change in the lighting even while the voltage remains within accepted limits. It's just that with typical UK wiring it takes something bigger than a SMT rework station to trigger it .
* Though you do sometimes see a little mixing. Posher houses in the UK often have 2A or 5A sockets on the lighting circuit for lamps controlled by lightswitches and sometimes you see fixed lighting connected via a fused connection unit on a socket circuit (especially if it was an addon).
The US also isn't your typical country. It's far more comparable to the EU as a whole than to any one EU country. We have
5 cities in europe (four of which are in the EU).
2 cities in north america
3 cities in east asia
Having said that i'm always very dubious of this sort of thing. I don't see anything in the article about how the critera were assessed and weighted. Nor any information on what citiees were assesed and didn't make the cut. I don't think this should be regarded as anything more than one reporter's opinion.
If DNS1 is down, then DNS2 will respond.
Sure it will
All load will go to WWW2.
Not immediately it won't
Consider this scenario.
1: Initially all servers are up
2: user starts browsing your site. His DNS packets go to DNS1 since that is the closest DNS server to his recursive resolver. DNS1 returns the IP of WWW1 which is cached by the user's recursive resolver and possibly his OS.
3: site1 (including DNS1 and WWW1) goes down.
4: The user clicks a link within your site. The browser asks the OS to look up the name, the OS either looks in it's DNS cache and returns the IP of WWW1 or contacts it's local recursive resolver which looks in it's cache and returns the IP of WWW1.
5: The browser tries and fails to connect to WWW1, the user eventually gets a timeout message if they can be bothered to wait long enough.
6: The user hits the refresh button and the browser tries again but continues to get connection timeouts until the DNS cache expires the record, contacts DNS2 and gets the IP for WWW2.
(it can be used for other services, but, in practice, isn't).
And there is a reason for that. Using anycast for a stateful protocol (e.g. anything TCP based) means that routing changes that would normally be harmless (that is routing changes which mean the packets still get to you but enter your network on a different interface) can break open connections even when all your systems are up. In the worst case if routing is really unstable or if someone has done some dumb load balancing then they may not be able to complete a connection at all.
Are the rest of us just not using it correctly?
More than likely.
You need to deal with the possibility of both individual EC2 instances dying and a whole availability zone dying in your application architecture. Amazon provides tools to help with this like load balancing that can operate over multiple availability zones and database service that are replicated across multiple availability zones but you have to actually use those tools if you want to build a reliable application.
Short TTLs are good only for changes (i.e. TTL at 24 hours, then set it to 12 hours 24 hours before an IP migration, then 4 hours 12 hours before a migration, then 1 hour 4 hours before a migration, then 5 minutes 1 hour before a migration, then to 24 hours after the migration is done), obviously set in seconds
Which works fine for planned migrations, useless for unplanned ones.
The down one won't ever announce itselft
Sure once a DNS server goes down it will stop sending responses regardless of whether you used anycast or the traditional system of just listing multiple DNS server IPs but responses it has already sent will continue to be used by clients until their TTL expires.
To make anycast useful without low DNS TTLs you would need to anycast not just the DNS servers but the servers they point to as well. However anycasting TCP based services causes broken connections if routing changes.
Most clients either won't move on to a second IP at all or will only move on once the OS times out the first TCP connection. And OS TCP connection timeouts are long enough that most users won't put up with them for interactive services.
A better strategy is to put a DNS server in each datacenter, make the TTLs short and set things up to automatically remove records if a server goes offline. This works much better because DNS fallback timeouts are much shorter than TCP connection timeouts.
From reading the wikipedia article I get the impression that lightsquared got very close to getting away with it. I get the impression that the reason they didn't get away with it was because the service they were stepping on was GPS which is used by damn near everyone. So it gave them a LOT of opponents both military and civillian.
We were discussing the implications of all the cars at a stoplight moving off in unison (proposed by Daetrin several levels up the post tree) which would produce a tightly packet convoy. Great for road usage efficency, not so great if something unexpected happens.
An alternative would be to have the cars drive like human drivers are supposed to* leaving a sufficient gap that whatever the driver in front does they can stop. Of cours that would probably mean lower road capacities than we have today.
*but don't.
The problem is different cars will most likely have different characteristics.
So if you have a group of closely spaced cars and something (the computer is unlikely to be able to reliablly identify what) steps out in front of you. Do you brake as hard as you can to maximise the chance of saving the life of whatever stepped out in front of you but also risking causing a pileup if the cars behind you have weaker breaks then you do or do you break based on some estimate of the characteristics of the worst brakes in the convoy and hit whatever is in front of you harder?
http://tinyurl.com/k72g6rq
I think there are a couple of things that contribute to that
1: example programs in textbooks/lecture slides are very often commented in the style you show. This is done because those programs have to be understandable to people who are just starting to learn the language but it also means students may come to think that comments like this should be in regular code.
2: teachers order their students to comment code but either they don't bother to teach their students about good commenting or their students don't "get it" when they are taught.
On indiegogo campaigns can be set up as "Flexible Funding" and the hosts get whatever is pledged (minus 9% for fees).
And even if a campaign is fixed funding (as this one was) it seems indiegogo charge immediately and refund if they have to.
I couldn't seem to find any specifics on how things are handled if a campaign fails. In particular does indigogo pay the payment processing fees or do those come out of your refund?
What's a telephone pole?
A pole used to hold up telephone wires.
third world countries where they don't put communication lines in the ground?
I don't know where you live but it's not just third world countries that have overhead telecoms gear.
Here in the UK while city centers and newer suburbs don't tend to have poles older suburbs seem to use a hybrid system where the multipair cable runs in ducts and then up a pole then the final connection to the house (the "dropwire") runs overhead and rural areas often seem to be pure overhead.
In the USA I believe pure telephone poles are actually pretty rare. Normal US practice seems to be to use shared poles that are owned by the power company.
in Europe, most Internet Exchanges are public peering.
They offer public peering certainly but if you are going to max out a port communicating with one peer then there is little point pushing the traffic through a public peering lan
This is why Netflix/YouTube/etc will allow anyone to peer at any IX in the USA, if you can reach at least 100mb/s of 95th percentile. You still need to setup a private port.
If you look at netflix's peering policy you will see that they have both public and private peering available in both the US and europe. They state a minimum traffic level for private peering for obvious reasons. They don't seem to state a maximum for public peering.
Google seems to be pretty similar though they don't explictly state what the minimum is for private peering..
The BBC explicitly state that any peer pusing more than 10Mbps over a public exchange may be requested to move to private peering.
AIUI there are two types of 64-bit wine setup. A pure 64-bit wine and a WoW64 wine with the former only able to run 64-bit apps while the latter uses a 32-bit wine to run 32-bit apps within the context of the 64-bit wine. I don't see any techical reason why such a system couldn't run 16 bit apps but I couldn't findd any documentation either way. Indeed in general the ability of wine to run 16 bit apps seems to be almost totally undocumented.
What is an internet exchange?
It's a place where providers peer when they are not exchanging enough traffic to justify private peering. Exchange point connections are cheap compared to transit but expensive compared to private peering links. Traffic from major access providers to the likes of google is unlikely to go through an internet exchange because with that volume of traffic private peering is more economical.
Which is not to say the 40% figure is true, it's just to say that traffic on an internet exchange is not a reprepsenative sample of internet traffic
If this is true there's a vanishingly small but nonzero chance of recovering any private key
There is a vanishishingly small but nonzero chance of recovering a private key by simply guessing it's factors.
Crypto is a game of probabilities. The aim is to reduce the probability of compromise to a level you consider negligable. Usually you try to reduce what you belive to be the probability of compromise way beyond the level you consider negligable in case your assumptions in calculating the probability were wrong. Short of a one time pad (which has it's own issues) you can never reduce it to zero.
poorly-written RNGs simply increase that chance spectacularly.
Taking it from negligable to likely.
According to the google blog post* the built in SSL stuff is fortunately not affected. So apps that simply act as clients over SSL should be fine. How many applications are there really that need crypto and/or secure random numbers other than SSL. I would think not that many and I would hope that most reputable designers of such applications would have heard about this and be working on an application side fix by now.
* http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html
One big security problem with andriod is the distribution model. Google makes andriod and distributes it to their OEM partners (and to the general public though sometimes with a delay). The OEMs then customise it and pass it on to their users and in most cases (nexus excepted) all updates go through the OEM.
The result is you get the situation of there being lots of older smartphones out there that are still perfectly usable but are no longer able to receive security updates in the regular manner because the OEM can no longer be bothered updating them. Sometimes it's possible to unlock the bootloader and install an unofficial build but that is at best something that requires you to be fairly technical and at worst something where even a computer expert like me can find myself in a dead end*.
* For example htc officially offers a bootloader unlock process but when I tried it on my brother's old wildfire the software version on it was too new to apply the RUU needed for the bootloader unlock process.
According to http://android-developers.blogspot.co.uk/2013/08/some-securerandom-thoughts.html
"Applications that establish TLS/SSL connections using the HttpClient and java.net classes are not affected as those classes do seed the OpenSSL PRNG with values from /dev/urandom."
I would expect a two pronged attack on this with both a system side fix (for devices that are still getting updates) and application side fixes as app developers try to cover their users regardless of what version of andriod they are using.
Users using non-market apps or apps from vendors who don't get the memo on smartphones that are no longer getting updates will of course be SOL.
Average bandwidth (aka data transferred) and 95th percentile bandwidth are both imperfect measures of "how much of our capacity requirements is this user responsible for".
You don't need a perfect measure just one good enough to weed out users who are using far more capacity than they are paying for.
The most recent financial statment I could find for mozilla is the 2011 one. In it is this gem.
"Mozilla entered into a contract with a search engine provider for royalties which expires
November 2014. The previous contract term expired in November 2011. Approximately
85% and 84% of royalty revenue for 2011 and 2010, respectively, was derived from this
contract."
Now the default search engine provider in mozilla browsers is google (there was talk of changing it but this proved very unpopular). So this most likely means that most of mozilla revenue is coming from people using google through the browser search box. Google can pay mozilla for those searches because google gets advertising revenue from them.
So while mozilla may try a few things to reign in the most abusive advertiser practices I doubt they would do anything that seriously threatens the industry.
Server 2003 installs by default, as "Workstation/Pro" desktop class OS - you modularly ADD server modules to it, as is needed...
Maybe so but the fact that you can add those features and the fact you can allow more than a handful of clients for file and print serving makes it a "server edition".
* I think you're attempting to state, perhaps, that XP 64 had all the PATCHES that later caught it up to Server 2003... right?
Server 2003 is NT5.2. So is windows XP professional x64 edition. Both use the same hotfixes, service packs and drivers (though drivers can support more than one version). They are by all reasonable measures different editions of the same version just like 2K pro and 2K server were different editions of the same version. Presumablly it was marketed as XP so they didn't have to explain to customers why they had to use a 64-bit OS to get the new version.
The obvious answer is that the visible officer will prevent violations. If you see the cop and don't slow down, you deserve the ticket. Prevention is the primary purpose of the law, not punishment after the fact. It is because of that philosophy that we have the right to a fair trial and are presumed innocent until proven otherwise.
The correct answer is that noone really knows. The only way to find out for sure would be to do a controlled experiment where in two otherwise identical places you used visible and invisible officers. Then have a set of data collectors (SEPERATE from the officers) to monitor the rate of violations.
The visible officer will clearly reduce violations in his presence but may cause people to slow down for the cop and then speed up again as soon as he is out of sight*. The hidden officer will have less immediate affect but once people rack up a few fines and/or points on their license** they are likely to change their behaviour everywhere, not just where they can see an officer.
* Which could ironically increase the number of violations by splitting one long violation into two shorter ones.
** This is a UK concept, not sure if you have an equivilent over an america.