Actually, there's an enormous difference. Disc is designed for high capacity, and thus has insanely high bit densities. They rely on significant technology to work at all. With the bits so small and packed so close together, modern hard disks tend to self-destruct if not constantly maintained. (read: powered on and left to run recalibrations) Tape is designed for long term storage, so bigger bits, less densely packed. Tape will maintain the pattern written to it for a very long time.
If your tape drive doesn't work, it can be replaced (usually -- older tech can be a problem), and the tape(s) read perfectly from it. When your hard drive fails -- bearings, circuits, or (99.999999% of the time) the firmware the cheap bastards stored on the media becomes unreadable -- You. Are. Screwed. (options: 1) throw it away, 2) pay a data recovery company $$$$ to get your data back.)
Flash drives aren't magnetic storage.
Enterprises use disc backups for two simple reasons: cost and speed. In most cases, the data backed up will be obsolete in a few weeks or months. Anything that has to outlast the quarter finds it's way to more stable storage -- tape, cd/dvd/bluray (unwise, but still used), flash drives, and/or SSDs.
The CO (switch) never cared. Despite having the ability to check/reject CLID values, no one ever has. Today, with SIP and soft switches, it's even easier, and they still don't do it. (I bet your voip.ms personal account could send out whatever it wants -- not a cutomer, so I don't know.)
There is, and always has been. With a simple POTS line, there's no means for the caller to manipulate anything -- it's all set by the serving switch. With ISDN (PRI and to some extent BRI), the caller was allowed to set CLID fields to indicate which "extension" is calling, ANI would be set by the switch to indicate the billing number for the line, however, your phone doesn't show ANI (even if it's a ISDN phone.) ISDN was expensive, so only a business would have them, and businesses could be trusted to not abuse the feature. That has worked out so well.:-)
Every phone switch I'm aware of supports limiting what's allowed for CLID. It's obvious most (all?) telcos cannot be bothered to use this feature.
Actually, the MPAA/RIAA do have a court order in these cases... but just one for many IPs. When they have to file one case per address, it becomes a huge burden (and expensive) and they tend to walk away.
IF you take the call directly from a scammer, and the SIP call is completed...
And just who in their right mind allows random SIP traffic from the internet to reach their PBX? ABSOLUTELY FUCKING NO ONE! Page one, step one of toll-fraud: allow access only from authorized sources. So, if a SIP call is "completed", it came from your phone service provider.
If they're spoofing the caller-id, then you have NO WAY to know where it came from. Only a "trap and trace" can follow it back, hop by hop, to the origin -- one switch at a time, one provider at a time, all the way back to China (or where ever.) That's the basis for the hollywood phone trace, but in reality, it takes people combing through records to see what's going on. (unless it's crossing metered lines, in the US, it's almost a certainty no CDRs are being generated and/or recorded, and even then, only for the segment that's metered -- eg. your cellphone.)
"Secret" is the most basic of our (US) government clearances. It's an entirely clerical check. It's not like you're being authorized for nuclear launch codes, but something closer to knowing phone numbers and extensions for people's desks.
(I've had a "secret clearance"; it was the.gov's equiv of an NDA.)
Unless you've been keeping detailed records long BEFORE the event(s) that triggered your blacklisting, odds are you'll have no record of what actually caused it. With Yahoo, you may not even know who was sent what, so you don't know who might have clicked the "spam" button. (and it used to be far to easy for complete idiots to click spam instead of delete, and not have any idea the difference between them.)
NET-23-30-0-0-1 was assigned to Comcast Business two and a half years ago. Your (apparent) netblock [NET-23-31-69-152-1] was assigned to you about a year ago. If anti-spam outfits were, as you claim, blocking all Comcast addresses, you'd've been blocked from day-one. The fact that you weren't, and have now mysteriously been blocked very strongly suggests something occurred from within your netblock to cause it. That means ANY device within your network could be the "bad apple".
It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.
The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.
Right. Manned by a pair of people inside a bunker that would take days to breach from the outside -- by design. One of the goes nuts and kills the other, he's got plenty of time to rig shit. Someone on the surface would have to notice this, and then get maintenance crews to the site(s) and into the silo(s) to physically disable the launchers. Every step in that chain is measured in multiple HOURS -- assuming anyone outside even notices before a missile comes flyin' out.
And if the stories are true, for a very long time, the silo launch codes were (still???) set to zero in protest to having those installed in the first place.
All this assumes a mad man in a silo couldn't figure out how to bypass the proven lax security measures and light one off on his/her own.
So I should be able to demand Verizon install ("host") my server(s) for free as well? Not going to happen.
Netflix is a FOR PROFIT BUSINESS. They can pay for services just like everybody else. (speaking as Verizon) Why should I bear the cost of hosting their business? It isn't costing me customers. And I'm sure as hell not going to give those asshats at Cogent anything; they're being paid boatloads by Netflix but won't buy the interconnects to support 'em.
Yes, there are small(ish) ISPs hopping on the Open Connect bandwagon. For them, it's a cost effective solution vs. the alternatives -- lost customers, or additional expensive bandwidth. Verizon (et. al) simply aren't going to play those games: Cogent can buy the bandwidth necessary to support their customers, or Netflix can find a different (preferably direct) path.
They have (had?) more than one provider. They have their own ASN - AS2906. It's readily apparent they suck at traffic engineering. (or they let it happen to try to push Open Connect.)
Netflix has other ISPs, and significant traffic engineering power at their disposal to get traffic to flow how they like. The simple fact that people could "VPN around" the congestion is proof Netflix could have used a different path to that user. However, it's easier to whine to the media in lame attempts to get Open Connect in the door. (i.e. host our business for free.)
Plus, they bought bandwidth from some of the cheapest providers around, who everyone knows isn't going to care when they fail to deliver. (Cogent is infamous for "peering disputes".)
Not "for free". Settlement Free Peering is based on a mostly balanced flow of traffic. The instant that ratio moves from 1:1 to 100:1 (as happened when Netflix switched to their in-house CDN), "free" isn't in the room anymore.
The reason for turning the crank was not to "charge them", but to generate the ring voltage -- to make a light bulb illuminate at the switch board where the operator is sitting.
They have, but those mechanical watches are very expensive, and are by definition a "chronometer". (designed to meet a certain precision) The crap you find in the checkout lane at Wal-mart will be cheap (sometime less than $3) and incredibly inaccurate.
(Even the $7 digital crappers are super inaccurate. The one we strapped into the race car is over 30mins off now, after just a few months. It's sufficient to measure 2hrs, but then so's the gas tank.)
It was more a factor of cheaper, and easier to mass produce, than "better". Granted, it's a lot easier to make a quartz watch accurate than a mechanical one.
Linus has nothing to do with that shit. And for the record, Red Hat has been renaming interfaces based on the ifcfg-XXX contents for years. (eth0 is MAC X, if X isn't present in the system, you won't have an eth0) udev adds a second layer to that "stupid" by adding "persistence" everywhere -- turning that crap off is pretty simple, once you know to do it.
Not "repacked", but "re-placed". And it happens so rarely because no one will assume the liability of anything ever going wrong with the replacement. Should you have a crash and the airbag doesn't deploy, guess who's going to be sued? (answer: who ever replaced that airbag.)
Where "from the manufacturer" is far too often "type VIN into a box on a web page." VW has actually made that process much harder over the years. It used to be a 4-5 digit code on the VIN tag that came with the car. Today, the immobilizer code can only be accessed from the diagnostic computer connected to the car. (supposedly through a secure channel (SSL?) to the mothership. and may require some human interaction to allow it in the first place.) Of course, the code is fairly obvious once the ECU is disassembled.:-) But that can take a while, depending on model.
Slashdot Mirror
Actually, there's an enormous difference. Disc is designed for high capacity, and thus has insanely high bit densities. They rely on significant technology to work at all. With the bits so small and packed so close together, modern hard disks tend to self-destruct if not constantly maintained. (read: powered on and left to run recalibrations) Tape is designed for long term storage, so bigger bits, less densely packed. Tape will maintain the pattern written to it for a very long time.
If your tape drive doesn't work, it can be replaced (usually -- older tech can be a problem), and the tape(s) read perfectly from it. When your hard drive fails -- bearings, circuits, or (99.999999% of the time) the firmware the cheap bastards stored on the media becomes unreadable -- You. Are. Screwed. (options: 1) throw it away, 2) pay a data recovery company $$$$ to get your data back.)
Flash drives aren't magnetic storage.
Enterprises use disc backups for two simple reasons: cost and speed. In most cases, the data backed up will be obsolete in a few weeks or months. Anything that has to outlast the quarter finds it's way to more stable storage -- tape, cd/dvd/bluray (unwise, but still used), flash drives, and/or SSDs.
The CO (switch) never cared. Despite having the ability to check/reject CLID values, no one ever has. Today, with SIP and soft switches, it's even easier, and they still don't do it. (I bet your voip.ms personal account could send out whatever it wants -- not a cutomer, so I don't know.)
There is, and always has been. With a simple POTS line, there's no means for the caller to manipulate anything -- it's all set by the serving switch. With ISDN (PRI and to some extent BRI), the caller was allowed to set CLID fields to indicate which "extension" is calling, ANI would be set by the switch to indicate the billing number for the line, however, your phone doesn't show ANI (even if it's a ISDN phone.) ISDN was expensive, so only a business would have them, and businesses could be trusted to not abuse the feature. That has worked out so well. :-)
Every phone switch I'm aware of supports limiting what's allowed for CLID. It's obvious most (all?) telcos cannot be bothered to use this feature.
Actually, the MPAA/RIAA do have a court order in these cases... but just one for many IPs. When they have to file one case per address, it becomes a huge burden (and expensive) and they tend to walk away.
And just who in their right mind allows random SIP traffic from the internet to reach their PBX? ABSOLUTELY FUCKING NO ONE! Page one, step one of toll-fraud: allow access only from authorized sources. So, if a SIP call is "completed", it came from your phone service provider.
If they're spoofing the caller-id, then you have NO WAY to know where it came from. Only a "trap and trace" can follow it back, hop by hop, to the origin -- one switch at a time, one provider at a time, all the way back to China (or where ever.) That's the basis for the hollywood phone trace, but in reality, it takes people combing through records to see what's going on. (unless it's crossing metered lines, in the US, it's almost a certainty no CDRs are being generated and/or recorded, and even then, only for the segment that's metered -- eg. your cellphone.)
"Secret" is the most basic of our (US) government clearances. It's an entirely clerical check. It's not like you're being authorized for nuclear launch codes, but something closer to knowing phone numbers and extensions for people's desks.
(I've had a "secret clearance"; it was the .gov's equiv of an NDA.)
They can be in full f'ing uniform and lie right to your face. What the cop (detective, etc.) says is "hearsay"; what you say is "evidence".
/ip-log/karma.log.11:virus 23.31.69.157 fimble.com NOTQUIT [S=5 - FakeMX NoQuit] X=tarbaby H=mail.fimble.com [23.31.69.157] HELO=[fimble.fimble.com] F=[lollypop@fimble.com] T=[terrydw@mkl.com] S=[Feeling adventurous tonight? Multiple mega hot lasses, free access!]
Hostkarma still had it in the logs.
You sent junk mail; you got blacklisted. Nothing more to see here.
Unless you've been keeping detailed records long BEFORE the event(s) that triggered your blacklisting, odds are you'll have no record of what actually caused it. With Yahoo, you may not even know who was sent what, so you don't know who might have clicked the "spam" button. (and it used to be far to easy for complete idiots to click spam instead of delete, and not have any idea the difference between them.)
NET-23-30-0-0-1 was assigned to Comcast Business two and a half years ago. Your (apparent) netblock [NET-23-31-69-152-1] was assigned to you about a year ago. If anti-spam outfits were, as you claim, blocking all Comcast addresses, you'd've been blocked from day-one. The fact that you weren't, and have now mysteriously been blocked very strongly suggests something occurred from within your netblock to cause it. That means ANY device within your network could be the "bad apple".
It's spelled mommy and daddy. If ever there were a better example of an excess of privilege and status, I'm not aware of it.
It's not a flag, it's a command. Support for the feature is signaled after the client hello (EHLO). It's not just hiding the indicator in the hello, but actively blocking the command.
The issue Goldenfrog whined about was a simple oversight from Cricket Wireless(?). That's the default behavior (even today) for Cisco firewalls -- which is why everyone with a clue disables (or at least tweaks) that idiotic inspection rule.
Wrong. Most MTAs (for a long time now) will attempt TLS if available.
Sure they do, it has a Cisco logo on it. :-)
(I have two college degrees. They aren't hanging on any wall, 'tho -- they're in a file cabinet.)
Right. Manned by a pair of people inside a bunker that would take days to breach from the outside -- by design. One of the goes nuts and kills the other, he's got plenty of time to rig shit. Someone on the surface would have to notice this, and then get maintenance crews to the site(s) and into the silo(s) to physically disable the launchers. Every step in that chain is measured in multiple HOURS -- assuming anyone outside even notices before a missile comes flyin' out.
And if the stories are true, for a very long time, the silo launch codes were (still???) set to zero in protest to having those installed in the first place.
All this assumes a mad man in a silo couldn't figure out how to bypass the proven lax security measures and light one off on his/her own.
So I should be able to demand Verizon install ("host") my server(s) for free as well? Not going to happen.
Netflix is a FOR PROFIT BUSINESS. They can pay for services just like everybody else. (speaking as Verizon) Why should I bear the cost of hosting their business? It isn't costing me customers. And I'm sure as hell not going to give those asshats at Cogent anything; they're being paid boatloads by Netflix but won't buy the interconnects to support 'em.
Yes, there are small(ish) ISPs hopping on the Open Connect bandwagon. For them, it's a cost effective solution vs. the alternatives -- lost customers, or additional expensive bandwidth. Verizon (et. al) simply aren't going to play those games: Cogent can buy the bandwidth necessary to support their customers, or Netflix can find a different (preferably direct) path.
They have (had?) more than one provider. They have their own ASN - AS2906. It's readily apparent they suck at traffic engineering. (or they let it happen to try to push Open Connect.)
Netflix has other ISPs, and significant traffic engineering power at their disposal to get traffic to flow how they like. The simple fact that people could "VPN around" the congestion is proof Netflix could have used a different path to that user. However, it's easier to whine to the media in lame attempts to get Open Connect in the door. (i.e. host our business for free.)
Plus, they bought bandwidth from some of the cheapest providers around, who everyone knows isn't going to care when they fail to deliver. (Cogent is infamous for "peering disputes".)
Not "for free". Settlement Free Peering is based on a mostly balanced flow of traffic. The instant that ratio moves from 1:1 to 100:1 (as happened when Netflix switched to their in-house CDN), "free" isn't in the room anymore.
The reason for turning the crank was not to "charge them", but to generate the ring voltage -- to make a light bulb illuminate at the switch board where the operator is sitting.
They have, but those mechanical watches are very expensive, and are by definition a "chronometer". (designed to meet a certain precision) The crap you find in the checkout lane at Wal-mart will be cheap (sometime less than $3) and incredibly inaccurate.
(Even the $7 digital crappers are super inaccurate. The one we strapped into the race car is over 30mins off now, after just a few months. It's sufficient to measure 2hrs, but then so's the gas tank.)
It was more a factor of cheaper, and easier to mass produce, than "better". Granted, it's a lot easier to make a quartz watch accurate than a mechanical one.
Linus has nothing to do with that shit. And for the record, Red Hat has been renaming interfaces based on the ifcfg-XXX contents for years. (eth0 is MAC X, if X isn't present in the system, you won't have an eth0) udev adds a second layer to that "stupid" by adding "persistence" everywhere -- turning that crap off is pretty simple, once you know to do it.
Not "repacked", but "re-placed". And it happens so rarely because no one will assume the liability of anything ever going wrong with the replacement. Should you have a crash and the airbag doesn't deploy, guess who's going to be sued? (answer: who ever replaced that airbag.)
Where "from the manufacturer" is far too often "type VIN into a box on a web page." VW has actually made that process much harder over the years. It used to be a 4-5 digit code on the VIN tag that came with the car. Today, the immobilizer code can only be accessed from the diagnostic computer connected to the car. (supposedly through a secure channel (SSL?) to the mothership. and may require some human interaction to allow it in the first place.) Of course, the code is fairly obvious once the ECU is disassembled. :-) But that can take a while, depending on model.