A polite call or email to their lawyer stating "I believe that this modest quotation is well within the guidelines for 'Fair Use'", and citing the guidelines at http://www.copyright.gov/fls/fl102.html carefully, might be helpful, although those guidelines are about as sloppy as typical sexual harassment policies to prevent anyone from actually being able to provide a clear answer and possibly reducing the income of intellectual property attorneys.
I've certainly seen this in the hardware and software world, and the physical experimental world is rife with it. Subtle software distinctions, such as which Perl or MySQL or kernel you are using, have profound effects on system performance. And for compilers, simply switching optimization levels or the order of operations can trigger or avoid memory overflows in incredibly difficult ways to debug.
Peter Hagelstein has been on the cold fusion bandwagon for decades. He has a stunning ability to pick and choose evidence from different studies and assemble them into a glowing report, even though the distinct studies measure different effects, and only the least convincing of the studies actually link the effects together. The result has been years of mish-mosh from the man, appearing in enough places like Analog magazine that some educated people who don't know much about physics take him seriously.
It's sad, really. His enthusiasm and claims actually interfere with real research because other people expect so much more than the cold fusion research people can actually produce.
The knee-jerk is justified. The issues of botnetes used to send spam have been addressed here, repeatedly. And the issues of "legitimate" spam companies using forged SMTP information and co-located serves, worldwide, date back to the first commercial spam enterprises such as Canter&Siegel.
I'm afraid that what's been running short, in IPv4, is the evenly/8,/16, and/24 address spaces. And those divisions aren't necessary. Most/24 users only tie up a small fraction of their address space with machines that need external exposure. (The last 3/24 spaces I've seen, each had only a dozen addresses that actually needed exposure, and could have been funneled down to 4 with intellegent setups, proper use of NAT, and a proper DMZ.)
The gray market is a problem. ICANN has been awful about registration, unwilling to actually enforce their existing policies and unwilling to make new, saner policies. And t here are commercial reasons for th em to ignore the realities, such as the need for a more free market for DNS and domain management, rather than the truly awful current practices. But the existing hands-off policies, and the gray markets, will easily preserve the useful life of IPv4 out to 2020.
I have done so, but admittedly not for a few years. Too many of the employees try to use their coporate networks as ISP's. It's a security and a resource problem of major proportions, because we in the IT world have not been able to get the budget to fund the bandwidth, or the security requirements, for such services.
And no, VoIP does not require separate _external_ channels. It can use reliable internal VoIP services which many ISP's are happy to provide, or an end-to-end service with man-in-the-middle operations that make sense, such as Skype (which continues to work well behind doubled NAT's just as I've described them). The average random VoIP application written on a napkin during lunch, with a similar martini-fueled business plan, will not, especially when they're IPv6 based to escape the networking requirements for IPv4 and normal ISP resource allocations such as DNS services. I lived through the dotcom and the dotbomb, and it's fairly sad to see the same EXCITING! IDEAS! CHANGE YOUR INFRASTRUCTURE SO I'LL MAKE MONEY, AND YOU'LL GET NOTHING!!!! technologies and business plans still being sold.
The random Sourceforge VoIP project won't cut it, and isn't worth my time or an ISP's time to evaluate.
I'd support dropping DHS as a ludicrous "master agency" whose proposed components correctly ignored it. But who will handle cyber security, which is in fact a large and growing problem.
FBI? Not competent, and can't deal with international issues.
CIA? Also not competent, and can't legally deal with national issues.
NSA? They have the technical expertise, but no political sense. They're far, far, far too criminal, and primarily takes in information: they seem congenitally handicapped from giving out necessary or truthful information. (See their Clipper Chip and Skipjack fiascos, that "so complicated no one can be bothered with it" nightmare known as SELinux, their warrent-free tapping of the AT&T backbones with fiber-optic splitters and secret rooms, and numerous misadventures for the last 30 years.)
Secret Service? Less competent than the CIA, despite their existing role in handling wire fraud, which they do very badly.
DIA? Apparently competent, but _not_ legally equipped to deal with civilians.
The result is that there is no agency with the legal support and the technical capability to deal with this mess, especially since so much of it is the fault of the federal government for their history of insane policies on encryption and authentication technologies for public use. (Do you low-numbered Slashdot users remember Phil Zimmerman's PGP legal problemas, and having to sign multiple documents to get DES enabled versions of operating systems, and the craziness of 80-bit SSL keys?)
I find your statement confusing. A NAT provides a very _simple_ firewall effect: it interferes profoundly with amazingly stupid protocols like FTP, which typically uses one channel for data and another for commands, but for the sort of "reach out in a simple way, do your business, and disconnect" such as email and HTTP access, it's just fine.
It's when a designer tries to get clever and says "oh, I'll use this channel for this information, and reach back on another channel to establish some other connection" that it gets fairly insane. And because of that, it badly screws up a lot of P2P and online chat applications. And it should break those: in the NAT approach, such services should live on a local server that _can_ be managed and configured properly, rather than a highly distributed cloud of confusing and security hazardous protocols. Disabling everything but HTTP/HTTPS to the outside world seems a reasonable model for most ISP's. I've certainly encouraged that approach at work, simply to ease the security headaches.
Why? My provider can use a 10.* address space behind a NAT gateway of their own. I can use a 192.168.* address space behind my household cable modem, or even my FIOS. Unless they're selling externally exposed devices as a service, they have _every reason_ not to provide externally exposed IP addresses, because it helps reduce the ease of household fileservices and P2P services to the Internet without in any way running complex firewalls or deliberate bandwidth limiting. It just makes households serving as Bittorrent servers much more difficult, since people outside your household network can't reach into your household IPv4 addresses.
There are technical benefits to IPv6. But we don't need them yet, or for at least 10 years more. Effective NAT, and better handling of non/8,/16, and/24 network spaces has heavily reduced and nearly eliminated the need for them for the next decade. Yes, there is an issue for routers engaging in complex behavior, but you know what? Most of that complexity can _go away_ if they'd stop trying to do complex billing rules for bandwidth.
So for everyone who doesn't directly manage sophisticated routing tables, we're just not going to bother.
Make a bet? Decent lawyers can keep you out of jail for _years_, and even help you avoid extradition, or help keep you in a milder white collar prison where you are far less likely to discover what needing real virus protection is like.
You obviously know little about gcc. You're _supposed_ to be able to compile the latest gcc with much older versions of gcc and not-very-ANSI-compliant compilers. The bootstrap process it uses is fascinating. And yes, I've written patches for software with ancient versions of gcc to inter-operate with much more recent components, and vice versa.
Now, the policeman's behavior was one of making sure he didn't have to do any work and deal with the complaint, not one of actually dealing with the porn. That matches FBI behavior in the US, whose actual response to spam and fraud remains, basically, 'hit the D key', despite the millions invested in the completely useless and clueless 'Internet Crime Complaint Center', which is apparently a fancy website which gets you an autoresponse and then completely ignored no matter what you report.
I can talk them out of it. I have talked them out of it. A typical VMware setup purchased from a third-party vendor is _too much_ for many small uses. Even VMware ESX as opposed to VMware Workstation is also too much expense, too much support, too many unnecessary features.
The external USB storage was for local snapshot storage, FTP repositories, and media storage. It was for material that simply did not need the performance or live failover capabilities of fiber channel or iSCSI. Even for many more dynamic uses, the cheap external USB storage performs quie well due to so much of the commonly used data being in RAM. I actually expect this to improve with ext4, when small writes to disk may be pending for up to 60 seconds to bundle them and improve the optimization of such writes. But either way, it was a small fraction of the price of the originally planned storage arrays, especially because we could avoid puying fiber channel cards or expensive SCSI cables.
Unless you're willing to invest far, far, far more money in having multiple front end VMware servers, multiple backend iSCSI or fiber channel storage, and a lot of time working out the kinks of VMware's installer (such as their unreliable and dangerous Linux plugins) and tools (such as the fact that their guest 'clone' operations change the MAC addresses of the guest behind your back), it's a lot of effort for an erratic system. And they don't even give you the RedHat licenses with which you can keep the ESX server updated with security patches, or to install your own network's commonly used backup or management tools. (Ever tried to install Nagios or cfengine or rsync or even an updated OpenSSH on an ESX server? Or worst of all, update a network driver? It's often easier to plug in CentOS update tools and ignore RedHat's licensed software, not due to RedHat, but because getting VMware to give you the RedHat license you paid for is ridiculously hard.)
My time doing all that kind of work is not cheap, admittedly. For an environment with 20 or 30 live VMware servers swapping around and redistributing live images in a shared storage environment, VMware ESX can scale well. But short of that, the license and hardware is usually better spent on much, much lighter weight hardware and software that can be upgraded next year and take advantage of the Moore's law upgrades to hardware.
I'm unfortunately familiar with VMware, both Workstation and ESX. ESX has real limitations on what hardware it runs on, and is usually sold as part of a package with that hardware. So what is a modest virtualization environment in a pizza box with a built-in SATA drive and maybe a Terabyte of external USB device for cheap storage for half a dozen OS's on a single server with a dumb SCSI array is suddenly a much more expensive, dual-supply system, with fiber channel back end, and another server to run the managementn tools. So yes, it draws more like 100 or even 300 watts more.
You've a point that for such an expensive license, the power draws may be lost in the noise. But I've been forced to upgrade power supplies, cooling, and other facilities to deal with VMware installations when lighterweight servers, running Xen, were cheaper for licenses _and_ a lot cheaper for the physical facilities, especially where I've successfully talked facilities out of using very expensive dual-homed SCSI, fiber channel, or expensive dedicated iSCSI hardware and simply provided 500 Gig external USB drives for large scale storage, and moved the connectors when needed.
Unfortunately, they mislabeled and mispriced those notebooks to sell you the "contract" without your knowledge. And hey, a contract or warrantee you don't know about is pure profit: you'll never ask for the support they sold you, and the sales people get bonuses or job evaluations based on how many of those ripoff products they can sell.
Any interface or management tools for such virtualized pool systems, brought to you by the company that wrote and maintains IOSS, already has a serious hurdle to jump. That language is very, very clever and flexible. It is also absolutely awful for attempting to do simple, straightforward configuration tasks that _look_ like they should work from the documentation, but which extra steps to actually provide and can only be done directly from the text interface, not from _any_ of the GUI's. (I spent some time trying to configure proper failover behavior last year on a set of switches. It was painful.)
If their virtualization management tools are similarly powerful, flexible, and utterly useless to anyone not a highly trained Cisco technician, then these systems will be very expensive and under-utilized doorstops in most environments. If, however, they've fired the fools who wrote the IOS control language and replaced them with people being fired by Juniper and thus raised the IQ at both companies, then they have a chance to fill a serious niche in environments like Wal-Mart, where a centrally managed and flexible system could manage inventory, sales registers, their highly automated security and power management, and personnel records. Putting all those on different servers provided by different vendors is nightmarish to manage: having a consistent, virtualized hardware environment makes hardware repairs and upgrades far, far more efficient, in my experience.
And let's face it: when I've looked at the stock room at such a facility, I've often seen a server or desktop stashed under someone's desk, lying on top of a card table in a corner where it never got mounted but is still in use, or miscabled and unscrewed down with only one plug in on top of a rack with an overloaded UPS. Simplifying and modularizing that for such an environment would be a big headache that I wouldn't have to have for dealing with such partners and clients. (I highly recommend taking a cell phone and taking pictures of such setups to let their head office know there is a problem.)
Slashdot Mirror
A polite call or email to their lawyer stating "I believe that this modest quotation is well within the guidelines for 'Fair Use'", and citing the guidelines at http://www.copyright.gov/fls/fl102.html carefully, might be helpful, although those guidelines are about as sloppy as typical sexual harassment policies to prevent anyone from actually being able to provide a clear answer and possibly reducing the income of intellectual property attorneys.
Well, 4500 or so US troops probably included a lot of registered voters. Whether they're taxpayers or federal debits is another issue.
I've certainly seen this in the hardware and software world, and the physical experimental world is rife with it. Subtle software distinctions, such as which Perl or MySQL or kernel you are using, have profound effects on system performance. And for compilers, simply switching optimization levels or the order of operations can trigger or avoid memory overflows in incredibly difficult ways to debug.
Peter Hagelstein has been on the cold fusion bandwagon for decades. He has a stunning ability to pick and choose evidence from different studies and assemble them into a glowing report, even though the distinct studies measure different effects, and only the least convincing of the studies actually link the effects together. The result has been years of mish-mosh from the man, appearing in enough places like Analog magazine that some educated people who don't know much about physics take him seriously.
It's sad, really. His enthusiasm and claims actually interfere with real research because other people expect so much more than the cold fusion research people can actually produce.
The strap broke. That counts as hardware failure.
Well, the Wiimote has some problems. That strap is flimsy and folks have broken big-screen LCD displays because of it. But your point is still good.
The knee-jerk is justified. The issues of botnetes used to send spam have been addressed here, repeatedly. And the issues of "legitimate" spam companies using forged SMTP information and co-located serves, worldwide, date back to the first commercial spam enterprises such as Canter&Siegel.
I'm afraid that what's been running short, in IPv4, is the evenly /8, /16, and /24 address spaces. And those divisions aren't necessary. Most /24 users only tie up a small fraction of their address space with machines that need external exposure. (The last 3 /24 spaces I've seen, each had only a dozen addresses that actually needed exposure, and could have been funneled down to 4 with intellegent setups, proper use of NAT, and a proper DMZ.)
The gray market is a problem. ICANN has been awful about registration, unwilling to actually enforce their existing policies and unwilling to make new, saner policies. And t here are commercial reasons for th em to ignore the realities, such as the need for a more free market for DNS and domain management, rather than the truly awful current practices. But the existing hands-off policies, and the gray markets, will easily preserve the useful life of IPv4 out to 2020.
I have done so, but admittedly not for a few years. Too many of the employees try to use their coporate networks as ISP's. It's a security and a resource problem of major proportions, because we in the IT world have not been able to get the budget to fund the bandwidth, or the security requirements, for such services.
And no, VoIP does not require separate _external_ channels. It can use reliable internal VoIP services which many ISP's are happy to provide, or an end-to-end service with man-in-the-middle operations that make sense, such as Skype (which continues to work well behind doubled NAT's just as I've described them). The average random VoIP application written on a napkin during lunch, with a similar martini-fueled business plan, will not, especially when they're IPv6 based to escape the networking requirements for IPv4 and normal ISP resource allocations such as DNS services. I lived through the dotcom and the dotbomb, and it's fairly sad to see the same EXCITING! IDEAS! CHANGE YOUR INFRASTRUCTURE SO I'LL MAKE MONEY, AND YOU'LL GET NOTHING!!!! technologies and business plans still being sold.
The random Sourceforge VoIP project won't cut it, and isn't worth my time or an ISP's time to evaluate.
I'd support dropping DHS as a ludicrous "master agency" whose proposed components correctly ignored it. But who will handle cyber security, which is in fact a large and growing problem.
FBI? Not competent, and can't deal with international issues.
CIA? Also not competent, and can't legally deal with national issues.
NSA? They have the technical expertise, but no political sense. They're far, far, far too criminal, and primarily takes in information: they seem congenitally handicapped from giving out necessary or truthful information. (See their Clipper Chip and Skipjack fiascos, that "so complicated no one can be bothered with it" nightmare known as SELinux, their warrent-free tapping of the AT&T backbones with fiber-optic splitters and secret rooms, and numerous misadventures for the last 30 years.)
Secret Service? Less competent than the CIA, despite their existing role in handling wire fraud, which they do very badly.
DIA? Apparently competent, but _not_ legally equipped to deal with civilians.
The result is that there is no agency with the legal support and the technical capability to deal with this mess, especially since so much of it is the fault of the federal government for their history of insane policies on encryption and authentication technologies for public use. (Do you low-numbered Slashdot users remember Phil Zimmerman's PGP legal problemas, and having to sign multiple documents to get DES enabled versions of operating systems, and the craziness of 80-bit SSL keys?)
I find your statement confusing. A NAT provides a very _simple_ firewall effect: it interferes profoundly with amazingly stupid protocols like FTP, which typically uses one channel for data and another for commands, but for the sort of "reach out in a simple way, do your business, and disconnect" such as email and HTTP access, it's just fine.
It's when a designer tries to get clever and says "oh, I'll use this channel for this information, and reach back on another channel to establish some other connection" that it gets fairly insane. And because of that, it badly screws up a lot of P2P and online chat applications. And it should break those: in the NAT approach, such services should live on a local server that _can_ be managed and configured properly, rather than a highly distributed cloud of confusing and security hazardous protocols. Disabling everything but HTTP/HTTPS to the outside world seems a reasonable model for most ISP's. I've certainly encouraged that approach at work, simply to ease the security headaches.
Why? My provider can use a 10.* address space behind a NAT gateway of their own. I can use a 192.168.* address space behind my household cable modem, or even my FIOS. Unless they're selling externally exposed devices as a service, they have _every reason_ not to provide externally exposed IP addresses, because it helps reduce the ease of household fileservices and P2P services to the Internet without in any way running complex firewalls or deliberate bandwidth limiting. It just makes households serving as Bittorrent servers much more difficult, since people outside your household network can't reach into your household IPv4 addresses.
This is, in fact, desireable for most ISP's.
There are technical benefits to IPv6. But we don't need them yet, or for at least 10 years more. Effective NAT, and better handling of non /8, /16, and /24 network spaces has heavily reduced and nearly eliminated the need for them for the next decade. Yes, there is an issue for routers engaging in complex behavior, but you know what? Most of that complexity can _go away_ if they'd stop trying to do complex billing rules for bandwidth.
So for everyone who doesn't directly manage sophisticated routing tables, we're just not going to bother.
Make a bet? Decent lawyers can keep you out of jail for _years_, and even help you avoid extradition, or help keep you in a milder white collar prison where you are far less likely to discover what needing real virus protection is like.
And sadly, this is deliberate to keep the middle managers and the bureaucrats (who do not actually produce the desired good or service) employed.
Is that why so much botnet activity is hosted in Estonia and Russia now?
You sound like my physics teaching assistant.
The long-winded procedures in fact discourage honesty. They encourage systemic fraud.
And you believe them about safely handling your password and never storing or selling it for other uses, why?
You obviously know little about gcc. You're _supposed_ to be able to compile the latest gcc with much older versions of gcc and not-very-ANSI-compliant compilers. The bootstrap process it uses is fascinating. And yes, I've written patches for software with ancient versions of gcc to inter-operate with much more recent components, and vice versa.
Sir or madam, people spam for _everything_. Read http://www.sophos.com/pressoffice/news/articles/2006/03/offspam.html: while the article is a few years out of date, there's a commercial notification from a security company that it does occur.
Now, the policeman's behavior was one of making sure he didn't have to do any work and deal with the complaint, not one of actually dealing with the porn. That matches FBI behavior in the US, whose actual response to spam and fraud remains, basically, 'hit the D key', despite the millions invested in the completely useless and clueless 'Internet Crime Complaint Center', which is apparently a fancy website which gets you an autoresponse and then completely ignored no matter what you report.
I can talk them out of it. I have talked them out of it. A typical VMware setup purchased from a third-party vendor is _too much_ for many small uses. Even VMware ESX as opposed to VMware Workstation is also too much expense, too much support, too many unnecessary features.
The external USB storage was for local snapshot storage, FTP repositories, and media storage. It was for material that simply did not need the performance or live failover capabilities of fiber channel or iSCSI. Even for many more dynamic uses, the cheap external USB storage performs quie well due to so much of the commonly used data being in RAM. I actually expect this to improve with ext4, when small writes to disk may be pending for up to 60 seconds to bundle them and improve the optimization of such writes. But either way, it was a small fraction of the price of the originally planned storage arrays, especially because we could avoid puying fiber channel cards or expensive SCSI cables.
Unless you're willing to invest far, far, far more money in having multiple front end VMware servers, multiple backend iSCSI or fiber channel storage, and a lot of time working out the kinks of VMware's installer (such as their unreliable and dangerous Linux plugins) and tools (such as the fact that their guest 'clone' operations change the MAC addresses of the guest behind your back), it's a lot of effort for an erratic system. And they don't even give you the RedHat licenses with which you can keep the ESX server updated with security patches, or to install your own network's commonly used backup or management tools. (Ever tried to install Nagios or cfengine or rsync or even an updated OpenSSH on an ESX server? Or worst of all, update a network driver? It's often easier to plug in CentOS update tools and ignore RedHat's licensed software, not due to RedHat, but because getting VMware to give you the RedHat license you paid for is ridiculously hard.)
My time doing all that kind of work is not cheap, admittedly. For an environment with 20 or 30 live VMware servers swapping around and redistributing live images in a shared storage environment, VMware ESX can scale well. But short of that, the license and hardware is usually better spent on much, much lighter weight hardware and software that can be upgraded next year and take advantage of the Moore's law upgrades to hardware.
I'm unfortunately familiar with VMware, both Workstation and ESX. ESX has real limitations on what hardware it runs on, and is usually sold as part of a package with that hardware. So what is a modest virtualization environment in a pizza box with a built-in SATA drive and maybe a Terabyte of external USB device for cheap storage for half a dozen OS's on a single server with a dumb SCSI array is suddenly a much more expensive, dual-supply system, with fiber channel back end, and another server to run the managementn tools. So yes, it draws more like 100 or even 300 watts more. You've a point that for such an expensive license, the power draws may be lost in the noise. But I've been forced to upgrade power supplies, cooling, and other facilities to deal with VMware installations when lighterweight servers, running Xen, were cheaper for licenses _and_ a lot cheaper for the physical facilities, especially where I've successfully talked facilities out of using very expensive dual-homed SCSI, fiber channel, or expensive dedicated iSCSI hardware and simply provided 500 Gig external USB drives for large scale storage, and moved the connectors when needed.
Unfortunately, they mislabeled and mispriced those notebooks to sell you the "contract" without your knowledge. And hey, a contract or warrantee you don't know about is pure profit: you'll never ask for the support they sold you, and the sales people get bonuses or job evaluations based on how many of those ripoff products they can sell.
Any interface or management tools for such virtualized pool systems, brought to you by the company that wrote and maintains IOSS, already has a serious hurdle to jump. That language is very, very clever and flexible. It is also absolutely awful for attempting to do simple, straightforward configuration tasks that _look_ like they should work from the documentation, but which extra steps to actually provide and can only be done directly from the text interface, not from _any_ of the GUI's. (I spent some time trying to configure proper failover behavior last year on a set of switches. It was painful.)
If their virtualization management tools are similarly powerful, flexible, and utterly useless to anyone not a highly trained Cisco technician, then these systems will be very expensive and under-utilized doorstops in most environments. If, however, they've fired the fools who wrote the IOS control language and replaced them with people being fired by Juniper and thus raised the IQ at both companies, then they have a chance to fill a serious niche in environments like Wal-Mart, where a centrally managed and flexible system could manage inventory, sales registers, their highly automated security and power management, and personnel records. Putting all those on different servers provided by different vendors is nightmarish to manage: having a consistent, virtualized hardware environment makes hardware repairs and upgrades far, far more efficient, in my experience.
And let's face it: when I've looked at the stock room at such a facility, I've often seen a server or desktop stashed under someone's desk, lying on top of a card table in a corner where it never got mounted but is still in use, or miscabled and unscrewed down with only one plug in on top of a rack with an overloaded UPS. Simplifying and modularizing that for such an environment would be a big headache that I wouldn't have to have for dealing with such partners and clients. (I highly recommend taking a cell phone and taking pictures of such setups to let their head office know there is a problem.)