People are still getting video feeds by HTTP. Multicast was supposed to save on bandwidth for things like IP TV. But it still isn't happening on any real scale. A lot of core infrastructure bandwidth could be reduced by making multicast fully functional and using it. And, of course, we need to do that in a way that precludes some intermediate business deciding what we can, or cannot, receive by multicast. Oh, and how many multicast groups are there? And how do I get one?
If there is current, there is electromagnetic radiation. And the EMP could create a current transient high enough to cause an arc across the switch contact, which could have temperatures far far in excess of 500 C and melt or fuse the tiny switch. There may be arcs already at the normal operating current wearing it out.
It can be interesting technology for certain peripheral devices, such as encoding sensor data in those 500 C places, as long as the data rates are not too fast.
Use IPv4 on your LAN. Use your own NAT on your own LAN to access the internet. Customer NAT is not as bad as ISP NAT. Then as more and more devices get IPv6, or you get off your lazy ass to upgrade their firmware, then you can use IPv6 even within you own LAN. BTW, there are 144,115,188,075,855,872 private IP addresses set aside in the IPv6 address space.
"Your Honor (or however they say it on that side of the pond), how can I possibly remember a 50 character long passphrase while under all this stress of unfounded charges?"
A script can be tweaked. One little mistake early on in a script, which you detect by testing it in a VM (with an OS tweaked to this point with the earlier scripts). If there is an error, you look at the logs of the output (not a memory of a vanishing GUI menu), and tweak the script. Roll back the VM, try again. Once you have it right, it is now crystalized knowledge, fully complementing documentation.
Try that with a GUI. Test out the steps in a VM. Once you figure out the steps that are right, how do you make sure they will be done correctly on each of the production machines?
If your IP is not on the list of infected customers, they won't affect you. But, if it is, they redirect your port 80 traffic to their proxy server that injects the HTML. Specifics, like how it does the overlay, I don't know. Maybe it wraps a frame or div. You'll have to fake being infected to see. Use HTTPS, or an SSH tunnel to a proxy of your own, to avoid it while being infected. If you can't be infected, then your own risk is if your ordinary traffic trips their infection detector.
There's some wiki thing I look at when I want to get info about a movie. But this movie wasn't listed there, either. So I guess maybe it's not a real movie.
A friend of mine had a terrible experience with Wells Fargo... and he didn't even bank with them. The problem was, they thought he did. And this was all because some bank clerk (because he was in there to cash a check drawn on that bank) was trying to get him to open a checking account, and he was stupid enough to give her his name and address so they could mail him some info. They mailed him nothing. This bank bitch went ahead and opened him a "free" account without his permission (my guess so she could meet her end of month new account quota). He also happened to move, so later when statements came, he didn't get them. How was he to know he needed to notify a bank he never opened an account with? The account wallowed in "$0.00 balance hell" for a few months until an annual service fee of $30 triggered a $35 overdraft fee followed by another $35 fee for being late on paying the $65 owe on the annual fee and overdraft fee. He found out about this when a debt collector called wanting $750 to cover $370 the bank originally thought he owed, all because Wells Fargo has no process whatsoever to be sure their "people" don't do things like this.
Stay away from EVERY big bank, but especially EVERY bank that got bailout money. Stay away from them forever.
If you think spending more than you have is the ONLY means to overdraft, then you clearly do not know how the system works. A great many overdrafts are the result of errors such as double-ringing at a cash register in a store, or an online service not updating their database properly (this has really happened to me).
If banks will now obey the new law that lets people opt out of their "protection racket", then people can at least put a stop to some of the problems of errors in processing. Too bad we can't get the system really fixed, yet (for example, by making it impossible to double ring).
This kind of thing can happen when records are being changed (say from A to CNAME) and the A record has not expired from your cache, yet. Did you do a "dig trace" around the cache to verify?
You seem informed. Maybe you can explain why it is that clients would not be picking up the corrected info and reducing their "attack" on the database servers (more so than everything being turned off and back on).
Let me have your email address and I can send you a MONTHLY reminder to download your transaction CSV data. To pay for this service, all the other days I'll send you some spam.
Better yet, just give me your bank web site, account number, and password, and I'll just download the CSV for you and email it to you. I'll still need your email address, and this extended service will require two spams each day.
Given that overdraft and other such fees are a substantial part of a bank's income, you'd think they would consider such accounts to be "high net worth"... for the bank's own net worth that is, and provide them good service for things like transaction reports.
Oh wait... if they provided transaction reports, many of these account holders would not be overdrawing. N/M
To make matters worse, every time a client got an error attempting to query one of the databases it interpreted it as an invalid value, and deleted the corresponding cache key. This meant that even after the original problem had been fixed, the stream of queries continued. As long as the databases failed to service some of the requests, they were causing even more requests to themselves. We had entered a feedback loop that didn't allow the databases to recover.
Even when the database has a valid value, if failures to get a value from the database can creating a growing cascade of errors, then this design is still poised for a future failure for simple things like a partial outage of databases or network access to them. Ideally, once the data was valid, the number of clients not getting a valid value should gradually decrease as more and more get valid values and don't have to requery. But if the scale was such that none could get anything when all were trying (and hence require a shutdown and slow start), it can all happen again with many other classes of failure. It can even happen with transient error, if the transient is long enough to trip a certain threshhold of clients.
So leaving that configuration correction system off for now makes sense. I would suggest a combination of a push system (originate at the database and push new values out... but watch for security) and a randomizing of delay times inserted for the data pulls.
Hey, someone has messed with our toys, so they must have broken in to our network.
Hey, someone has broken into the network, so they have the ability to mess with our toys.
Both capabilities are needed in a unit like this. Ideally, that should be from someone with experience in both. And I know a couple people like that (warrier and geek). The question is whether or not it is worthwhile to supplement such a team with some people that are top level warrior only, and some people that are top level geek only. When in an actual operational event, though, the ones with no military experience are not going to be trusted to perform (even if they really would). But having geeks without military training in a support role can still be valuable. For example, these geeks can train the warrior geeks to "pre-detect" intrusions well before they get to the warrior toys. You don't want the intruder to retarget and launch before you can detect it. You don't want to depend on being able to detect based on the intruder actually doing something or getting something.
But they still need warrior types to perform the front end functions, merging their experience and discpline into the mix.
Slashdot Mirror
People are still getting video feeds by HTTP. Multicast was supposed to save on bandwidth for things like IP TV. But it still isn't happening on any real scale. A lot of core infrastructure bandwidth could be reduced by making multicast fully functional and using it. And, of course, we need to do that in a way that precludes some intermediate business deciding what we can, or cannot, receive by multicast. Oh, and how many multicast groups are there? And how do I get one?
OK, so my webcam on Venus will have to be 320 x 240 at 6 frames per second. No big deal.
If there is current, there is electromagnetic radiation. And the EMP could create a current transient high enough to cause an arc across the switch contact, which could have temperatures far far in excess of 500 C and melt or fuse the tiny switch. There may be arcs already at the normal operating current wearing it out.
It can be interesting technology for certain peripheral devices, such as encoding sensor data in those 500 C places, as long as the data rates are not too fast.
... is easily explained. There is a flaw in the design. Someone apparently made the "wear out expiration" register signed instead of unsigned.
It's also great for pirates ... everyone sharing the same IP.
OTOH, with NAT, it's harder to identify who was using what IP address.
Use IPv4 on your LAN. Use your own NAT on your own LAN to access the internet. Customer NAT is not as bad as ISP NAT. Then as more and more devices get IPv6, or you get off your lazy ass to upgrade their firmware, then you can use IPv6 even within you own LAN. BTW, there are 144,115,188,075,855,872 private IP addresses set aside in the IPv6 address space.
"All your base are belong to us".
Then in 40 years, if anyone is there, we could get an answer. "We dare you to come and get all our base".
"Your Honor (or however they say it on that side of the pond), how can I possibly remember a 50 character long passphrase while under all this stress of unfounded charges?"
A script can be tweaked. One little mistake early on in a script, which you detect by testing it in a VM (with an OS tweaked to this point with the earlier scripts). If there is an error, you look at the logs of the output (not a memory of a vanishing GUI menu), and tweak the script. Roll back the VM, try again. Once you have it right, it is now crystalized knowledge, fully complementing documentation.
Try that with a GUI. Test out the steps in a VM. Once you figure out the steps that are right, how do you make sure they will be done correctly on each of the production machines?
If your IP is not on the list of infected customers, they won't affect you. But, if it is, they redirect your port 80 traffic to their proxy server that injects the HTML. Specifics, like how it does the overlay, I don't know. Maybe it wraps a frame or div. You'll have to fake being infected to see. Use HTTPS, or an SSH tunnel to a proxy of your own, to avoid it while being infected. If you can't be infected, then your own risk is if your ordinary traffic trips their infection detector.
There's some wiki thing I look at when I want to get info about a movie. But this movie wasn't listed there, either. So I guess maybe it's not a real movie.
Just one more reason to watch what you post, folks
Or use a fictitious online identity. You didn't really think that Skapare was my real name and 16644 was my real number, did you?
A friend of mine had a terrible experience with Wells Fargo ... and he didn't even bank with them. The problem was, they thought he did. And this was all because some bank clerk (because he was in there to cash a check drawn on that bank) was trying to get him to open a checking account, and he was stupid enough to give her his name and address so they could mail him some info. They mailed him nothing. This bank bitch went ahead and opened him a "free" account without his permission (my guess so she could meet her end of month new account quota). He also happened to move, so later when statements came, he didn't get them. How was he to know he needed to notify a bank he never opened an account with? The account wallowed in "$0.00 balance hell" for a few months until an annual service fee of $30 triggered a $35 overdraft fee followed by another $35 fee for being late on paying the $65 owe on the annual fee and overdraft fee. He found out about this when a debt collector called wanting $750 to cover $370 the bank originally thought he owed, all because Wells Fargo has no process whatsoever to be sure their "people" don't do things like this.
Stay away from EVERY big bank, but especially EVERY bank that got bailout money. Stay away from them forever.
There are plenty where that came from:
If I had time, I'd type in the full list.
If you think spending more than you have is the ONLY means to overdraft, then you clearly do not know how the system works. A great many overdrafts are the result of errors such as double-ringing at a cash register in a store, or an online service not updating their database properly (this has really happened to me).
If banks will now obey the new law that lets people opt out of their "protection racket", then people can at least put a stop to some of the problems of errors in processing. Too bad we can't get the system really fixed, yet (for example, by making it impossible to double ring).
This kind of thing can happen when records are being changed (say from A to CNAME) and the A record has not expired from your cache, yet. Did you do a "dig trace" around the cache to verify?
You seem informed. Maybe you can explain why it is that clients would not be picking up the corrected info and reducing their "attack" on the database servers (more so than everything being turned off and back on).
Let me have your email address and I can send you a MONTHLY reminder to download your transaction CSV data. To pay for this service, all the other days I'll send you some spam.
Better yet, just give me your bank web site, account number, and password, and I'll just download the CSV for you and email it to you. I'll still need your email address, and this extended service will require two spams each day.
Given that overdraft and other such fees are a substantial part of a bank's income, you'd think they would consider such accounts to be "high net worth" ... for the bank's own net worth that is, and provide them good service for things like transaction reports.
Oh wait ... if they provided transaction reports, many of these account holders would not be overdrawing. N/M
... and browsers will think their DNS is dead ... because, well, it is ... and is the first thing a browser needs to access.
To make matters worse, every time a client got an error attempting to query one of the databases it interpreted it as an invalid value, and deleted the corresponding cache key. This meant that even after the original problem had been fixed, the stream of queries continued. As long as the databases failed to service some of the requests, they were causing even more requests to themselves. We had entered a feedback loop that didn't allow the databases to recover.
Even when the database has a valid value, if failures to get a value from the database can creating a growing cascade of errors, then this design is still poised for a future failure for simple things like a partial outage of databases or network access to them. Ideally, once the data was valid, the number of clients not getting a valid value should gradually decrease as more and more get valid values and don't have to requery. But if the scale was such that none could get anything when all were trying (and hence require a shutdown and slow start), it can all happen again with many other classes of failure. It can even happen with transient error, if the transient is long enough to trip a certain threshhold of clients.
So leaving that configuration correction system off for now makes sense. I would suggest a combination of a push system (originate at the database and push new values out ... but watch for security) and a randomizing of delay times inserted for the data pulls.
There's a difference between:
Both capabilities are needed in a unit like this. Ideally, that should be from someone with experience in both. And I know a couple people like that (warrier and geek). The question is whether or not it is worthwhile to supplement such a team with some people that are top level warrior only, and some people that are top level geek only. When in an actual operational event, though, the ones with no military experience are not going to be trusted to perform (even if they really would). But having geeks without military training in a support role can still be valuable. For example, these geeks can train the warrior geeks to "pre-detect" intrusions well before they get to the warrior toys. You don't want the intruder to retarget and launch before you can detect it. You don't want to depend on being able to detect based on the intruder actually doing something or getting something.
But they still need warrior types to perform the front end functions, merging their experience and discpline into the mix.
His whole point is that when it finally comes down to following orders, even if they are totally fucked up, the soldier will follow the orders.
FYI, one can be both a geek and a soldier. They will follow orders when under the command.