You're only paying for 1M between you and the DSLAM. Beyond the DSLAM, I'm certain you're not going to always get your full rate. Case in point, I know of at least one DSL ISP that sells >1M connections to DLSAMs feed via 768K frame T1's... it is impossible to see greater than 768k to any single connection; and then, only if you are the only one moving any traffic. Even the ones feed by DS3 are oversold by a factor of 12. (which is actually a little better than the industry average.)
The claims of "not shared" are 100% marketing bullshit. ALL BANDWIDTH IS SHARED. Unless you physically run a wire from point A to point B to move your bits, your bits are mixing with everyone else's. Even the p-t-p T1's and DS3's sold today aren't 100% p-t-p... those idle timeslots are wasted bandwidth telco's want to sell to someone else (and DO.)
The instant they start doing this, they lose the protection of 'Common Carrier' and instantly become legally liable for anything any of their customers do. Either their lawyers are idiots -- for not realizing this, or thinking they have a loophole -- or the PHB's aren't listening.
That's different... cell phones are a shared medium that everyone knows is oversold several orders of magnitude. There's no way even half of all cell phone users could use their phones at the same time. They charge for airtime because you're consuming a very limited resource -- and because the various PUC's allow them to do so.
The same is true for POTS as well, just not as severe. While every pots line is required to get dialtone, there's no requirement for there to be sufficent capacity for every phone to make a call beyond the serving switch. (If you pick up the handset and don't get dialtone, that's an "outage" as defined by the PUC.)
When you pin your company's profits on over estimating contracts and "finishing early", all you're doing is lying to your clients and screwing them out of their money.
Prove this.
Buy a dictionary... if you tell a client a job will take 100 hours (and bill them), KNOWING your guys are going to do it in less time, that's lying. That has nothing to do with telling someone spending $50k today will save them $100k tomorrow. Obviously your clients have money to burn or they'd realize over time that your estimates are always high. The naive will conclude your "guys are good"; the savy will see though the BS, but might not care in light of quality work.
If I tell someone a job will take 10 hours and I'm done after only 2 hours, they get billed for 2 hours. If it takes more than 10 hours, they only get billed for 10 hours -- unless there are agreed upon reasons otherwise (changing specs, etc.)
Only if his clients are aware of it. Even then, some larger companies may not care if the bills are "small enough". I've had a few contracts where the client didn't care about how much work it was (or wasn't); they had an amount they wanted to pay -- much more than the work could justify -- so that's what they were billed.
Let's say 20 of those hours are his supervision... He pockets the $145 an hour x 20...
So, the person who does almost zero actual work gets a huge salary, and the peon doing all the hard work gets shit. This, as you describe it, is bordering very closely on accounting and tax fraud. The employee's benefits and other employment factors are set by the base pay/hourly (minimum) wage. That "bonus" isn't taxed the same as his/her base pay. And absent any specifics in a contract, there's no certainty of the existance of any bonus much less what cut goes in which pockets.
There's a reason technology workers don't work on commision... the work is almost always non-deterministic. They aren't installing an electrical outlet or paving a driveway -- things that can be accurately estimated quickly and easily with one walk-through (how big is the drive? how far am I from the breaker box? etc.) Most IT jobs aren't as immediately simple... how long does it take to install/setup Exchange for a company? The answer involves hundreds of questions that won't necessarily lead you to an accurate timetable.
When you pin your company's profits on over estimating contracts and "finishing early", all you're doing is lying to your clients and screwing them out of their money.
No. You just don't get it. Every packet arriving at "B" comes from a valid, routable IP address. This is REQUIRED as it has to acknowledge the data it's receiving. This is how TCP works. There's basically no way around it. (local network spoofing and multicast aside) If you're trying to send files across the internet using UDP, then it's critically important to be able to talk to the thing sending the traffic because packets ARE going to be lost.
It doesn't mater who originates the data; B got it from C. B knows it came from C. Anyone watching can see B received a packet from C. Encrypting the payload will not protect you -- certainly not for ever. (Don't assume B is the only one that can decrypt it... weak encryption, compromised machine/keys, or complicit "spy"/"mole"/etc.) The mere fact that packets are splintered throughout the network makes a case against every node in the network... all it takes is one illegal distribution into the mesh to potentially hang everyone. And don't think the RIAA/MPAA won't file a suit against thousands of Doe's.
There's no network equivalent of floppy disks materializing out of thin air on your desk when no one is looking. Every packet is coming from somewhere; and that somewhere is tracable. You don't have to know an item is stolen to be arrested for possesing/selling it... encrypting the traffic being shuffled around will not protect you. (if common carrier provisions applied (and they don't), there'd be no need for crypto... you'd be "hidden" by the bouncing through various intermediate nodes.)
Granted, the larger the network, the harder it will be to drag everyone into court and sort out who sent what to whom. But we already know few of such cases ever make it to court anyway, most are settled long before going before a judge -- it's all about extorting you out of your money.
It still doesn't matter. If A sends to B via C, then B will simply be unaware of A; watching the traffic at B will not incriminate A... It will incriminate C. To the letter of the law, both A and C are violating copyright law (unauthorized distribution), but only C will be immediately evident. Given the nature of such networks (everyone is an intermediary), by definition, every node in the network is violating copyright law.
Bram is correct on one point... there's no such thing as anonymous. When packets arrive at a computer, there's very little wiggle room in hiding where they came from. It's extremely easy to trace them all the way back to their source. (and various laws are forcing this to be easier every day.)
You're getting a "Blue Screen of Death" on a hard drive? Impressive. I wasn't aware any hard drives had video interfaces. *rolls eyes* Your COMPUTER is crashing; this is not Seagate's problem. If the drive has bad sectors (and it's still under warantee, not OEM'd to some machine factory like Sun, Dell, etc.) Seagate WILL replace it without any hassle -- I've been doing this for over a decade so I think I know w.t.f. I'm talking about.
In most cases, simply writing anything at all to the bad sector(s) will trigger a remap. Very few drives remap on read errors. (BTW, RAID systems typically disable automatic remapping to avoid read/write delays. The system can then remap the sector when it's prepared for it. Plus, there's very little to be gained from the drive's lengthy recovery proceedures when the RAID can recover a sector in very short order.)
Yeap. Obviously, this poor college kid didn't need a printer as he already had access to one. However, printing barcodes in a university computer lab will eventually be noticed by someone.
Oh, he's still charged with theft. By printing those barcodes, he's stepped into the realm of fraud. (and he ain't a big enough fish (CEO) to get away with it.)
And it would appear he's probablly lying, too... seeing as he pulled the same scam to steal the printer he used to print his barcodes. The whole "poor student" crap isn't going to get him very far either. He wasn't swaping barcodes on produce at the local mega-mart; he's stealing expensive electronics by defrauding the store. If it were simply walking out without paying for it, the store might've let it go without pressing charges -- poor college kid and all, but knowing he's defrauded the store, they aren't about to let him walk.
The UPC barcodes are placed there by the manufacturer. If you put a different one for a lower priced item, records will not show selling 6 XBox's for $40; the inventory will be short 6 xbox's and long on some other item(s). And if the cashier doesn't notice the XBox ring up as a tube of toothpaste, no one will ever notice. (unless some dude asks to see the receipt on the way out the door.) Catching this from receipts and video is very, VERY difficult.
Nope. That's no dream. For most of a decade, the entire thing was run from Linus' INBOX. Various other kernel developers used CVS (etc.), but Linus HATES CVS. (And I don't blame him one bit.)
...what do we do when we merge with another company...
This comes up everytime IPv6 is mentioned. And it's wrong. NAT is not the center of the difficulty in merge/connecting two large networks. The size of the network(s) and the breadth of interconnectedness are the real problems. And there's a lot more to merging networks than making sure there aren't address overlaps. Building a NAT-NAT map to address overlaps can be headache generating, but it's certainly not "excessively complex". [I've done it dozens of times.]
Granted, not having to build any NAT maps at all is a lot simpler. *grin*
Not really... they just came late to the party and now there's no bean dip.
It's easier for emerging markets to be IPv6 since they're starting out, day-one, with IPv6 capable hardware. When you go to buy a computer today, do you get a 486 running win95 or a P4 running XP? The 486 will certainly be cheaper, but the P4 has longer usable lifetime.
Y2K was a real problem with a real deadline. IPv4 isn't either of these. We still have quite a bit of IPv4 space available and aren't going to "run out" for decades. (people have been screaming "10-20 years" for decades now.) When the last block(s) have been sent to RIRs for assignment, then it will be a problem.
Honestly, it's not very difficult to switch to IPv6 on devices that currently support it. When it comes to it, IPv6 could be pushed across the internet over a few years with most transitioning in the first few months. The only real problem is the devices that don't currently support IPv6 because either there's no (official) software updates to bring them IPv6, or there's no one left to bring them IPv6 support -- how many IPv4 devices do companies use today that no longer have support from the manufacturer or no longer have a manufacturer? (IPv6 is not a sufficient reason to throw away millions in hardware.)
Yes, you can load unsupported/hacked firmware on some Linksys gear if you know where to find it. The point is, it didn't come from linksys. And the hardware isn't coming IPv6 capable from factory.
Incorrect. NAT is a security measure. It is not the security measure. NAT will help protect a network, but it offers no protection for exported service(s) or outbound traffic. ("Packets show up; I rewrite the headers and send them on." -- NAT)
if you could just have a million public IP addresses that worked, why wouldn't you use them?
This is the exact mentality that has several dozen/8's hoarded away. In the early days of the internet, address space was abundant and thus large swaths were given away, rapidly consuming the landscape. Now we're poised to create a new landscape and we're doing the same damned stupid thing.
And you are missing an important point: Every human in existance doesn't need an IP address.
I'm one person with dozens of machines, yet I get along just fine with one IPv4 address. My office, with 2 dozen people and many more machines, gets along just fine with ONE IPv4 address.
So, STOP with the BS that every grain of sand in the universe needs an address! Eventually, yes, we will exhaust available IPv4 addresses, but that's not going to happen tomorrow -- more like decades from now. People are not going to throw away a perfectly workable, deployed, solution until there's a real need -- i.e. until there are real problems, not theoretical problems decades away.
Read the notice from Cisco. Yeah, it's a lot of words, but there are instructions for non-contract holders near the bottom... ask TAC for an update. (This is Cisco's standard practice, btw.) Note the word "update" not "upgrade", they will give you the nearest release fix with the same feature set. If you're running 12.2, you'll get a 12.2 image. If you aren't running a crypto image, you aren't entitled to anything because you aren't affected. For example, I'm running 12.4(3), so they'd send me 12.4(3b) not 12.4(5).
Of course, there are "places" where you can "buy" IOS updates. *cough*ebay*cough* But it's not 100% legal.
There are a number of reasons skype is "bad", but there are just as many reasons why it's "good". The reasons these idiots are spouting are rubbish... "it's closed source"; well, guess what, so's Windows, and almost everything Cisco makes, and all the "corp" AV software, and most commercial IDS/IPS's... the list is never ending.
They claim it's succeptable to man-in-the-middle, yet show no research to prove it. (those that have done the research say otherwise.) A working example would be nice.
(For the record, about the only real problem with Skype is it's proprietary protocol. If it were standards compliant, it'd be a breeze to use existing VoIP technologies to bring many, many millions more nodes online. I'd love to link PBX voice interfaces to Skype, but that ain't gonna happen until they all talk the same language.)
You do realize just how fast light travels, right? At 1Gbit/sec, it takes just over 500ns to transmit a 64byte packet (the smallest allowed per spec.) Given, the speed of light is almost precisely one foot per nanosecond, even a 64byte packet would see greater than 50 "collision". I think I've said this already: the tx/rx elements are not reflective. If they were (even slightly), it would never work.
I wouldn't go that far. (for either sentence.) I've seen a fair number of cables damaged from being strung like they were copper -- don't hang them from cable management loops. Personally, I have fibre on *my* desk (at home), but it's for FC, not networking.
Have you tried this with optical SPDIF? Those are large filament, "cheap" plastic cables. (they need a connector, but I'm sure a wad of duct tape 'll work.)
Except FDDI has been around longer. With an aging existing infrastructure, it's not uncommon to find FDDI. It was the only way to avoid some issues -- mostly cable length restrictions. Moving to gig (optical) is (usually) as simple as changing the equipment on both ends.
Tell that to telco techs. I've seen OC-3 - OC-48 fibre bundles bent in arcs that truly alarmed me. Bits were flowing through them, 'tho. I also have pictures of one telco's practice of coiling up single-mode OC3 cables and stuffing them between equipment or pilling them on the cable ladders where they don't belong. (fibre has it's own conduit.)
Trust me, it's common practice for people to "string it anywhere." Plastic MM cable might be able to take the abuse, but certainly not for long.
Slashdot Mirror
You're only paying for 1M between you and the DSLAM. Beyond the DSLAM, I'm certain you're not going to always get your full rate. Case in point, I know of at least one DSL ISP that sells >1M connections to DLSAMs feed via 768K frame T1's... it is impossible to see greater than 768k to any single connection; and then, only if you are the only one moving any traffic. Even the ones feed by DS3 are oversold by a factor of 12. (which is actually a little better than the industry average.)
The claims of "not shared" are 100% marketing bullshit. ALL BANDWIDTH IS SHARED. Unless you physically run a wire from point A to point B to move your bits, your bits are mixing with everyone else's. Even the p-t-p T1's and DS3's sold today aren't 100% p-t-p... those idle timeslots are wasted bandwidth telco's want to sell to someone else (and DO.)
The instant they start doing this, they lose the protection of 'Common Carrier' and instantly become legally liable for anything any of their customers do. Either their lawyers are idiots -- for not realizing this, or thinking they have a loophole -- or the PHB's aren't listening.
That's different... cell phones are a shared medium that everyone knows is oversold several orders of magnitude. There's no way even half of all cell phone users could use their phones at the same time. They charge for airtime because you're consuming a very limited resource -- and because the various PUC's allow them to do so.
The same is true for POTS as well, just not as severe. While every pots line is required to get dialtone, there's no requirement for there to be sufficent capacity for every phone to make a call beyond the serving switch. (If you pick up the handset and don't get dialtone, that's an "outage" as defined by the PUC.)
When you pin your company's profits on over estimating contracts and "finishing early", all you're doing is lying to your clients and screwing them out of their money.
Prove this.
Buy a dictionary... if you tell a client a job will take 100 hours (and bill them), KNOWING your guys are going to do it in less time, that's lying. That has nothing to do with telling someone spending $50k today will save them $100k tomorrow. Obviously your clients have money to burn or they'd realize over time that your estimates are always high. The naive will conclude your "guys are good"; the savy will see though the BS, but might not care in light of quality work.
If I tell someone a job will take 10 hours and I'm done after only 2 hours, they get billed for 2 hours. If it takes more than 10 hours, they only get billed for 10 hours -- unless there are agreed upon reasons otherwise (changing specs, etc.)
Only if his clients are aware of it. Even then, some larger companies may not care if the bills are "small enough". I've had a few contracts where the client didn't care about how much work it was (or wasn't); they had an amount they wanted to pay -- much more than the work could justify -- so that's what they were billed.
Let's say 20 of those hours are his supervision ... He pockets the $145 an hour x 20 ...
So, the person who does almost zero actual work gets a huge salary, and the peon doing all the hard work gets shit. This, as you describe it, is bordering very closely on accounting and tax fraud. The employee's benefits and other employment factors are set by the base pay/hourly (minimum) wage. That "bonus" isn't taxed the same as his/her base pay. And absent any specifics in a contract, there's no certainty of the existance of any bonus much less what cut goes in which pockets.
There's a reason technology workers don't work on commision... the work is almost always non-deterministic. They aren't installing an electrical outlet or paving a driveway -- things that can be accurately estimated quickly and easily with one walk-through (how big is the drive? how far am I from the breaker box? etc.) Most IT jobs aren't as immediately simple... how long does it take to install/setup Exchange for a company? The answer involves hundreds of questions that won't necessarily lead you to an accurate timetable.
When you pin your company's profits on over estimating contracts and "finishing early", all you're doing is lying to your clients and screwing them out of their money.
No. You just don't get it. Every packet arriving at "B" comes from a valid, routable IP address. This is REQUIRED as it has to acknowledge the data it's receiving. This is how TCP works. There's basically no way around it. (local network spoofing and multicast aside) If you're trying to send files across the internet using UDP, then it's critically important to be able to talk to the thing sending the traffic because packets ARE going to be lost.
It doesn't mater who originates the data; B got it from C. B knows it came from C. Anyone watching can see B received a packet from C. Encrypting the payload will not protect you -- certainly not for ever. (Don't assume B is the only one that can decrypt it... weak encryption, compromised machine/keys, or complicit "spy"/"mole"/etc.) The mere fact that packets are splintered throughout the network makes a case against every node in the network... all it takes is one illegal distribution into the mesh to potentially hang everyone. And don't think the RIAA/MPAA won't file a suit against thousands of Doe's.
There's no network equivalent of floppy disks materializing out of thin air on your desk when no one is looking. Every packet is coming from somewhere; and that somewhere is tracable. You don't have to know an item is stolen to be arrested for possesing/selling it... encrypting the traffic being shuffled around will not protect you. (if common carrier provisions applied (and they don't), there'd be no need for crypto... you'd be "hidden" by the bouncing through various intermediate nodes.)
Granted, the larger the network, the harder it will be to drag everyone into court and sort out who sent what to whom. But we already know few of such cases ever make it to court anyway, most are settled long before going before a judge -- it's all about extorting you out of your money.
It still doesn't matter. If A sends to B via C, then B will simply be unaware of A; watching the traffic at B will not incriminate A... It will incriminate C. To the letter of the law, both A and C are violating copyright law (unauthorized distribution), but only C will be immediately evident. Given the nature of such networks (everyone is an intermediary), by definition, every node in the network is violating copyright law.
Bram is correct on one point... there's no such thing as anonymous. When packets arrive at a computer, there's very little wiggle room in hiding where they came from. It's extremely easy to trace them all the way back to their source. (and various laws are forcing this to be easier every day.)
You're getting a "Blue Screen of Death" on a hard drive? Impressive. I wasn't aware any hard drives had video interfaces. *rolls eyes* Your COMPUTER is crashing; this is not Seagate's problem. If the drive has bad sectors (and it's still under warantee, not OEM'd to some machine factory like Sun, Dell, etc.) Seagate WILL replace it without any hassle -- I've been doing this for over a decade so I think I know w.t.f. I'm talking about.
In most cases, simply writing anything at all to the bad sector(s) will trigger a remap. Very few drives remap on read errors. (BTW, RAID systems typically disable automatic remapping to avoid read/write delays. The system can then remap the sector when it's prepared for it. Plus, there's very little to be gained from the drive's lengthy recovery proceedures when the RAID can recover a sector in very short order.)
Yeap. Obviously, this poor college kid didn't need a printer as he already had access to one. However, printing barcodes in a university computer lab will eventually be noticed by someone.
Oh, he's still charged with theft. By printing those barcodes, he's stepped into the realm of fraud. (and he ain't a big enough fish (CEO) to get away with it.)
And it would appear he's probablly lying, too... seeing as he pulled the same scam to steal the printer he used to print his barcodes. The whole "poor student" crap isn't going to get him very far either. He wasn't swaping barcodes on produce at the local mega-mart; he's stealing expensive electronics by defrauding the store. If it were simply walking out without paying for it, the store might've let it go without pressing charges -- poor college kid and all, but knowing he's defrauded the store, they aren't about to let him walk.
The UPC barcodes are placed there by the manufacturer. If you put a different one for a lower priced item, records will not show selling 6 XBox's for $40; the inventory will be short 6 xbox's and long on some other item(s). And if the cashier doesn't notice the XBox ring up as a tube of toothpaste, no one will ever notice. (unless some dude asks to see the receipt on the way out the door.) Catching this from receipts and video is very, VERY difficult.
Nope. That's no dream. For most of a decade, the entire thing was run from Linus' INBOX. Various other kernel developers used CVS (etc.), but Linus HATES CVS. (And I don't blame him one bit.)
...what do we do when we merge with another company...
This comes up everytime IPv6 is mentioned. And it's wrong. NAT is not the center of the difficulty in merge/connecting two large networks. The size of the network(s) and the breadth of interconnectedness are the real problems. And there's a lot more to merging networks than making sure there aren't address overlaps. Building a NAT-NAT map to address overlaps can be headache generating, but it's certainly not "excessively complex". [I've done it dozens of times.]
Granted, not having to build any NAT maps at all is a lot simpler. *grin*
Not really... they just came late to the party and now there's no bean dip.
It's easier for emerging markets to be IPv6 since they're starting out, day-one, with IPv6 capable hardware. When you go to buy a computer today, do you get a 486 running win95 or a P4 running XP? The 486 will certainly be cheaper, but the P4 has longer usable lifetime.
Y2K was a real problem with a real deadline. IPv4 isn't either of these. We still have quite a bit of IPv4 space available and aren't going to "run out" for decades. (people have been screaming "10-20 years" for decades now.) When the last block(s) have been sent to RIRs for assignment, then it will be a problem.
Honestly, it's not very difficult to switch to IPv6 on devices that currently support it. When it comes to it, IPv6 could be pushed across the internet over a few years with most transitioning in the first few months. The only real problem is the devices that don't currently support IPv6 because either there's no (official) software updates to bring them IPv6, or there's no one left to bring them IPv6 support -- how many IPv4 devices do companies use today that no longer have support from the manufacturer or no longer have a manufacturer? (IPv6 is not a sufficient reason to throw away millions in hardware.)
Yes, you can load unsupported/hacked firmware on some Linksys gear if you know where to find it. The point is, it didn't come from linksys. And the hardware isn't coming IPv6 capable from factory.
...NAT is not a security measure...
/8's hoarded away. In the early days of the internet, address space was abundant and thus large swaths were given away, rapidly consuming the landscape. Now we're poised to create a new landscape and we're doing the same damned stupid thing.
Incorrect. NAT is a security measure. It is not the security measure. NAT will help protect a network, but it offers no protection for exported service(s) or outbound traffic. ("Packets show up; I rewrite the headers and send them on." -- NAT)
if you could just have a million public IP addresses that worked, why wouldn't you use them?
This is the exact mentality that has several dozen
And you are missing an important point: Every human in existance doesn't need an IP address.
I'm one person with dozens of machines, yet I get along just fine with one IPv4 address. My office, with 2 dozen people and many more machines, gets along just fine with ONE IPv4 address.
So, STOP with the BS that every grain of sand in the universe needs an address! Eventually, yes, we will exhaust available IPv4 addresses, but that's not going to happen tomorrow -- more like decades from now. People are not going to throw away a perfectly workable, deployed, solution until there's a real need -- i.e. until there are real problems, not theoretical problems decades away.
Read the notice from Cisco. Yeah, it's a lot of words, but there are instructions for non-contract holders near the bottom... ask TAC for an update. (This is Cisco's standard practice, btw.) Note the word "update" not "upgrade", they will give you the nearest release fix with the same feature set. If you're running 12.2, you'll get a 12.2 image. If you aren't running a crypto image, you aren't entitled to anything because you aren't affected. For example, I'm running 12.4(3), so they'd send me 12.4(3b) not 12.4(5).
Of course, there are "places" where you can "buy" IOS updates. *cough*ebay*cough* But it's not 100% legal.
There are a number of reasons skype is "bad", but there are just as many reasons why it's "good". The reasons these idiots are spouting are rubbish... "it's closed source"; well, guess what, so's Windows, and almost everything Cisco makes, and all the "corp" AV software, and most commercial IDS/IPS's... the list is never ending.
They claim it's succeptable to man-in-the-middle, yet show no research to prove it. (those that have done the research say otherwise.) A working example would be nice.
(For the record, about the only real problem with Skype is it's proprietary protocol. If it were standards compliant, it'd be a breeze to use existing VoIP technologies to bring many, many millions more nodes online. I'd love to link PBX voice interfaces to Skype, but that ain't gonna happen until they all talk the same language.)
You do realize just how fast light travels, right? At 1Gbit/sec, it takes just over 500ns to transmit a 64byte packet (the smallest allowed per spec.) Given, the speed of light is almost precisely one foot per nanosecond, even a 64byte packet would see greater than 50 "collision". I think I've said this already: the tx/rx elements are not reflective. If they were (even slightly), it would never work.
I wouldn't go that far. (for either sentence.) I've seen a fair number of cables damaged from being strung like they were copper -- don't hang them from cable management loops. Personally, I have fibre on *my* desk (at home), but it's for FC, not networking.
Have you tried this with optical SPDIF? Those are large filament, "cheap" plastic cables. (they need a connector, but I'm sure a wad of duct tape 'll work.)
Except FDDI has been around longer. With an aging existing infrastructure, it's not uncommon to find FDDI. It was the only way to avoid some issues -- mostly cable length restrictions. Moving to gig (optical) is (usually) as simple as changing the equipment on both ends.
Tell that to telco techs. I've seen OC-3 - OC-48 fibre bundles bent in arcs that truly alarmed me. Bits were flowing through them, 'tho. I also have pictures of one telco's practice of coiling up single-mode OC3 cables and stuffing them between equipment or pilling them on the cable ladders where they don't belong. (fibre has it's own conduit.)
Trust me, it's common practice for people to "string it anywhere." Plastic MM cable might be able to take the abuse, but certainly not for long.