Some folks still think it was local jet traffic that made the noise that scared them all so much that they ran out of the tent, lost their lights and senses of direction, and died of exposure. It's just much more likely than a freak sound event.
As I posted before, this study had included non-enterprise drives which any thoughtful enterprise data preservation expert would not have ever used for enterprise data storage.
I visited part of Bletchley Park in the late 2000s and it was a ruin. The guard at the gate house said they are very much in need of money. The buildings were falling down.
Sure, it is a site of historical importance, but even the Enigma-cracking computers like the esteemed Alan Turing's bombe were dismantled and scrapped decades ago, and the hundreds of subsequent generations which won the war of the Atlantic are all over the world in both their original form, as replicas, and as computer emulations.
I just toileted three Seagate Barracuda drives of varying vintage, from three to five years old. I don't understand why my Western Digital, Samsung, Hitachi, and Toshiba drives don't crap out so soon.
In particular, Samsung F1 drives just flat out refuse to die, so why isn't any of that rubbing off on new owner Seagate?
Yes. The IBM "Pixie Dust" technology wasn't quite ready or understood well enough to be manufactured in a repeatable, reliable way.
Though sometimes quoted that this was the reason IBM exited the hard drive manufacturing business, it was a minor factor at best. IBM had been seeking a buyer for that business unit well before Pixie Dust spawned the annoying DeskStar "DeathStar" jokes.
This study is interesting, but consumer-grade hard drives are exactly not supposed to be used in this way. I worked on server-grade hard drives (also 3.5") that were going seven years old without spinning down and getting slammed hard all day, every day. The failure rate was less than 1% for all brands in seven years' time in an array that filled two server racks. The 2.5" drives are even better.
Vibrations causing failure? Brother label makers? Isn't this the online storage vendor that was bragging about shucking portable hard drives to get around a soft embargo imposed during the Indonesian flood crisis?
This is true, but most contemporary systems aren't SWM (which is a DirecTV term). DISH Network has a similar band-stacking technology but it's also rather rare and expensive and only found on relatively new installations. It's nice to see the major satellite TV providers have embraced band-stacking so we don't need so many cables and complicated switches anymore, even if it's at a premium price.
Yes, coaxial cable is absolutely required. Don't skimp. It has more bandwidth and it's 100% reliable.
When I renovated the basement, I bought a spool of quad-shield dual-line RG-6 cable with copper core and ran it to every wall in the basement and to every wall on the main floor. Then I ran a pair to every bedroom since I was able to use a riser to the attic. Then used a high-frequency splitter in the basement. This is how you get whole-house DVR working properly.
You *want* to have RG-6 copper-core cable to each point in addition to ethernet. You need it for all home television service. No matter cable, FiOS/fiber, U-verse, or IP-TV, they all use MoCa to communicate with the other TVs and you want to have that. Satellite also needs two cables to each point.
Plus your home DVR solution, whether cable, satellite, will use the RG-6 cable with MoCa to distribute the video to your TVs. The MoCa connection will be the only one that will allow you to reliably distribute non-buffered HDTV to all televisions in the house from a whole-house DVR. FiOS, for one, requires it.
RG-6 is not for analog--it's for modern televisions of all types.
Hard wiring to every room with RS-485, RS-422
on
New Home Automation?
·
· Score: 2
Since you have the grand opportunity to design your house before it's built, you want to use the best home automation protocol available. Hard wiring to every room with the RS-485, RS-422, TIA-485-A family is the best long-term bet. This will always work now and in the future. It won't be affected by obsolescence, RF interference, or electromagnetic interference.
You can extend your house later with the toy protocols later like Zwave, INSTEON, Zigbee, Bluetooth 4.0/Smart/WiBree, or whatever. For the core home automation where reliability is required, like lights, doors, alarms, sensors, you should use ANSI/TIA/EIA-485. The wires will be the same as your ethernet in case you ever change your mind, but if you design it right, you won't need to.
You rarely see any theaters, hotels, or shopping malls using anything else but ANSI/TIA/EIA-485.
Aside from the attack in the article, one might think that VSAT terminals are much more susceptible to DDoS attacks because of their limited bandwidth and the carrier's Fair Access Policy. One might assume that pretty much anyone who wanted to could just send data to the IP address of one and The FAP will restrict the throughput.
The thing is, the commercial VSAT providers have already thought of this. Each terminal is on a private network behind a NAT already, even if you're not using the software proxy accelerator. Incidentally, modern terminals already have the network accelerator built into the VSAT modem, but regardless of this most VSAT terminals are on private networks and can't be reached directly.
Back to the article, the uplink exploit is well-known and several decades old, as another poster reminds us of the 1980 Captain Midnight incident. Even in this case, the best you can do is deny service, and you'll eventually be caught doing it.
At the earth station you're not going to be stealing any data, as it's encrypted on the way down and you're not going to be breaking into the facility.
You're not likely to find them by scanning networks, either, as mentioned earlier most VSAT terminals are on private networks. Even if you were to reach the terminal directly the management port isn't reachable from the outside world, just the private network of the VSAT operator.
The article is an interesting bit of speculation, and has the obligatory mentions of Afhanistan, SCADA, and the SHODAN search engine.
Why are they not using thin clients like VMware, Citrix, with PCoIP? I recently visited a Bob's furniture store and all their POS terminals were thin clients using either RDP, Citrix, or bus virtualization protocols like PCoIP. Same with the terminals at all the centers at another firm.
With the current generation thin clients, particularly the nifty PCoIP ones, local performance is very attainable even though it isn't really needed for POS terminals. VMware has offered PCoIP since 2008 and Amazon has just released their implementation.
I think Target deserves what they got for having POS terminals that are allowed to be locally modified in any way.
The CDN just sends you to the edge servers that are closest peer to the DNS server. I thought there was a very elaborate geolocation scheme, but there is not. They merely use the location of the DNS server that resolves your query.
I was so disappointed. There is no magic. They do not know nor care about the end user's IP address. The CDN just sends you to the edge servers that are closest peer to the DNS server. Certain companies actually seem to own patents on this simple technique.
For public wireless networks, there is a popular solution to extract revenue, aptly named the Revenue eXtraction Gateway, or rXg, by http://www.rgnets.com/. It explicitly and effectively works by filtering content and inserting advertisements along with the usual wireless gateway tricks.
This is an honest revenue extraction service and, while it can be done at the ISP level, it does not pack affiliate cookies. It's probably one of the more legitimate ones available. It does require a significant back-end infrastructure to support its operations, though, which may or may not cover expenses.
Saw this in Reddit this morning but thanks for reposting it.
Seriously, the drawback to using public DNS like OpenDNS and Google DNS is that they present a serious performance problem.
Even though the physical DNS servers are "anycast" and geographically diverse, the IP addresses are still the same. Threrefore, the large content delivery networks (CDNs) like Akamai and LimeLight still use the IP address of the DNS server to judge your location.
Therefore, any service that uses a CDN (even Google's use them in spite of their own network) will really serve your content out of a data center that is not geographically or logically near your machine's location.
The article (if you read it) mentions that his ISP, like most that have similar revenue-extracting services, really does offer alternative DNS servers that do not pack affiliate cookies. You should use those if you want to enjoy high-performance, edge-serve content via Akamai (AKAM) and LimeLight (LLNW).
Otherwise, you'll all get your edge content served from some random data center in the central USA.
Having worked with pre-2000 versions of RSA BSAFE, the thing that the NSA paid RSA to do was to change the default selection of the random number generator with a weaker one. Nobody had to use the default version--it was just picked if you didn't specify one (or a callback to your own RNG). We had our own multi-threaded rendezvous noise generator thing since this was back before hardware entropy engines.
Oh, and before that, the NSA had unsuccessfully tried to get RSA to tell people that 512-bit keys were safe enough. It wasn't successful mostly because the old guard was still running the company then.
In our area, the phone company, before installing FiOS, installed these boxes on the telephone poles that had miniature DSLAMs on them about seven or eight years ago. A side-effect of this project was nearly perfect 56k connections (which cannot be reached due to FCC limitations, but whatever).
It's not the same kind of "digital" line that you're thinking of when talking about DSL, but it was much better than it was more than ten years ago when I dropped my faulty cable modem for 56k dialup for a few months time.
We all probably know that AOL has Turboweb, now called TopSpeed, which compresses graphics. On broadband you have to specifically turn it on by clicking "TopSpeed" and "Use AOL Proxies for broadband" and "Always compress graphics" and "Turn on maximum graphics compression" for extreme cases. It works very, very well on 768 kbps DSL.
If you don't use AOL, you can use a number of accelerator programs but they constantly come and go. One of them is known as Slipstream but there are many more. They work just like AOL by using proxies that compress the graphics.
More on the period: At this time I had been a die-hard TRS-80 Color Computer aficionado but I did appreciate the advances in which the Commodore camp had triumphed. I eventually embraced, for better or worse, the Commodore Amiga line, from 16- to 32-bit both in AmigaOS and Amiga Unix.
Slashdot Mirror
Not based on, but actually total fiction inspired by.
Some folks still think it was local jet traffic that made the noise that scared them all so much that they ran out of the tent, lost their lights and senses of direction, and died of exposure. It's just much more likely than a freak sound event.
As I posted before, this study had included non-enterprise drives which any thoughtful enterprise data preservation expert would not have ever used for enterprise data storage.
I visited part of Bletchley Park in the late 2000s and it was a ruin. The guard at the gate house said they are very much in need of money. The buildings were falling down.
Sure, it is a site of historical importance, but even the Enigma-cracking computers like the esteemed Alan Turing's bombe were dismantled and scrapped decades ago, and the hundreds of subsequent generations which won the war of the Atlantic are all over the world in both their original form, as replicas, and as computer emulations.
I just toileted three Seagate Barracuda drives of varying vintage, from three to five years old. I don't understand why my Western Digital, Samsung, Hitachi, and Toshiba drives don't crap out so soon.
In particular, Samsung F1 drives just flat out refuse to die, so why isn't any of that rubbing off on new owner Seagate?
Was this a Seagate scandal or actually a MiniScribe scandal (acquired by Maxtor, acquired by Seagate)?
Yes. The IBM "Pixie Dust" technology wasn't quite ready or understood well enough to be manufactured in a repeatable, reliable way.
Though sometimes quoted that this was the reason IBM exited the hard drive manufacturing business, it was a minor factor at best. IBM had been seeking a buyer for that business unit well before Pixie Dust spawned the annoying DeskStar "DeathStar" jokes.
Maxtor bought MiniScribe and their warehouse full of actual bricks in hard drive boxes.
This study is interesting, but consumer-grade hard drives are exactly not supposed to be used in this way. I worked on server-grade hard drives (also 3.5") that were going seven years old without spinning down and getting slammed hard all day, every day. The failure rate was less than 1% for all brands in seven years' time in an array that filled two server racks. The 2.5" drives are even better.
Vibrations causing failure? Brother label makers? Isn't this the online storage vendor that was bragging about shucking portable hard drives to get around a soft embargo imposed during the Indonesian flood crisis?
This is true, but most contemporary systems aren't SWM (which is a DirecTV term). DISH Network has a similar band-stacking technology but it's also rather rare and expensive and only found on relatively new installations. It's nice to see the major satellite TV providers have embraced band-stacking so we don't need so many cables and complicated switches anymore, even if it's at a premium price.
Yes, coaxial cable is absolutely required. Don't skimp. It has more bandwidth and it's 100% reliable.
When I renovated the basement, I bought a spool of quad-shield dual-line RG-6 cable with copper core and ran it to every wall in the basement and to every wall on the main floor. Then I ran a pair to every bedroom since I was able to use a riser to the attic. Then used a high-frequency splitter in the basement. This is how you get whole-house DVR working properly.
You *want* to have RG-6 copper-core cable to each point in addition to ethernet. You need it for all home television service. No matter cable, FiOS/fiber, U-verse, or IP-TV, they all use MoCa to communicate with the other TVs and you want to have that. Satellite also needs two cables to each point.
Plus your home DVR solution, whether cable, satellite, will use the RG-6 cable with MoCa to distribute the video to your TVs. The MoCa connection will be the only one that will allow you to reliably distribute non-buffered HDTV to all televisions in the house from a whole-house DVR. FiOS, for one, requires it.
RG-6 is not for analog--it's for modern televisions of all types.
Since you have the grand opportunity to design your house before it's built, you want to use the best home automation protocol available. Hard wiring to every room with the RS-485, RS-422, TIA-485-A family is the best long-term bet. This will always work now and in the future. It won't be affected by obsolescence, RF interference, or electromagnetic interference.
You can extend your house later with the toy protocols later like Zwave, INSTEON, Zigbee, Bluetooth 4.0/Smart/WiBree, or whatever. For the core home automation where reliability is required, like lights, doors, alarms, sensors, you should use ANSI/TIA/EIA-485. The wires will be the same as your ethernet in case you ever change your mind, but if you design it right, you won't need to.
You rarely see any theaters, hotels, or shopping malls using anything else but ANSI/TIA/EIA-485.
Naturally, but monitor how often that non-Google device interacts with Google services. You probably won't be feeling the same way.
Aside from the attack in the article, one might think that VSAT terminals are much more susceptible to DDoS attacks because of their limited bandwidth and the carrier's Fair Access Policy. One might assume that pretty much anyone who wanted to could just send data to the IP address of one and The FAP will restrict the throughput.
The thing is, the commercial VSAT providers have already thought of this. Each terminal is on a private network behind a NAT already, even if you're not using the software proxy accelerator. Incidentally, modern terminals already have the network accelerator built into the VSAT modem, but regardless of this most VSAT terminals are on private networks and can't be reached directly.
Back to the article, the uplink exploit is well-known and several decades old, as another poster reminds us of the 1980 Captain Midnight incident. Even in this case, the best you can do is deny service, and you'll eventually be caught doing it.
At the earth station you're not going to be stealing any data, as it's encrypted on the way down and you're not going to be breaking into the facility.
You're not likely to find them by scanning networks, either, as mentioned earlier most VSAT terminals are on private networks. Even if you were to reach the terminal directly the management port isn't reachable from the outside world, just the private network of the VSAT operator.
The article is an interesting bit of speculation, and has the obligatory mentions of Afhanistan, SCADA, and the SHODAN search engine.
It just goes to show you how much you think you know about security, which is quite a tiny bit.
Why are they not using thin clients like VMware, Citrix, with PCoIP? I recently visited a Bob's furniture store and all their POS terminals were thin clients using either RDP, Citrix, or bus virtualization protocols like PCoIP. Same with the terminals at all the centers at another firm.
With the current generation thin clients, particularly the nifty PCoIP ones, local performance is very attainable even though it isn't really needed for POS terminals. VMware has offered PCoIP since 2008 and Amazon has just released their implementation.
I think Target deserves what they got for having POS terminals that are allowed to be locally modified in any way.
The CDN just sends you to the edge servers that are closest peer to the DNS server. I thought there was a very elaborate geolocation scheme, but there is not. They merely use the location of the DNS server that resolves your query.
I was so disappointed. There is no magic. They do not know nor care about the end user's IP address. The CDN just sends you to the edge servers that are closest peer to the DNS server. Certain companies actually seem to own patents on this simple technique.
For public wireless networks, there is a popular solution to extract revenue, aptly named the Revenue eXtraction Gateway, or rXg, by http://www.rgnets.com/. It explicitly and effectively works by filtering content and inserting advertisements along with the usual wireless gateway tricks.
This is an honest revenue extraction service and, while it can be done at the ISP level, it does not pack affiliate cookies. It's probably one of the more legitimate ones available. It does require a significant back-end infrastructure to support its operations, though, which may or may not cover expenses.
Yes, that is, if the CDN has also implemented EDNS0 extensions, which some have not.
Thanks for the info!
Saw this in Reddit this morning but thanks for reposting it.
Seriously, the drawback to using public DNS like OpenDNS and Google DNS is that they present a serious performance problem.
Even though the physical DNS servers are "anycast" and geographically diverse, the IP addresses are still the same. Threrefore, the large content delivery networks (CDNs) like Akamai and LimeLight still use the IP address of the DNS server to judge your location.
Therefore, any service that uses a CDN (even Google's use them in spite of their own network) will really serve your content out of a data center that is not geographically or logically near your machine's location.
The article (if you read it) mentions that his ISP, like most that have similar revenue-extracting services, really does offer alternative DNS servers that do not pack affiliate cookies. You should use those if you want to enjoy high-performance, edge-serve content via Akamai (AKAM) and LimeLight (LLNW).
Otherwise, you'll all get your edge content served from some random data center in the central USA.
RSA SecurID tokens have absolutely nothing at all to do with this.
Having worked with pre-2000 versions of RSA BSAFE, the thing that the NSA paid RSA to do was to change the default selection of the random number generator with a weaker one. Nobody had to use the default version--it was just picked if you didn't specify one (or a callback to your own RNG). We had our own multi-threaded rendezvous noise generator thing since this was back before hardware entropy engines.
Oh, and before that, the NSA had unsuccessfully tried to get RSA to tell people that 512-bit keys were safe enough. It wasn't successful mostly because the old guard was still running the company then.
In our area, the phone company, before installing FiOS, installed these boxes on the telephone poles that had miniature DSLAMs on them about seven or eight years ago. A side-effect of this project was nearly perfect 56k connections (which cannot be reached due to FCC limitations, but whatever).
It's not the same kind of "digital" line that you're thinking of when talking about DSL, but it was much better than it was more than ten years ago when I dropped my faulty cable modem for 56k dialup for a few months time.
We all probably know that AOL has Turboweb, now called TopSpeed, which compresses graphics. On broadband you have to specifically turn it on by clicking "TopSpeed" and "Use AOL Proxies for broadband" and "Always compress graphics" and "Turn on maximum graphics compression" for extreme cases. It works very, very well on 768 kbps DSL.
If you don't use AOL, you can use a number of accelerator programs but they constantly come and go. One of them is known as Slipstream but there are many more. They work just like AOL by using proxies that compress the graphics.
More on the period: At this time I had been a die-hard TRS-80 Color Computer aficionado but I did appreciate the advances in which the Commodore camp had triumphed. I eventually embraced, for better or worse, the Commodore Amiga line, from 16- to 32-bit both in AmigaOS and Amiga Unix.