Sun and NetApp have been arguing, for years, about patent issues both ways involving STK storage technologies purchased by Sun and used by NetApp, and in turn for these ZFS issues raised by NetAPP. From my experience with both, I'm inclined to believe that Sun is the one that wants actual open source competition, and that is innocent in patent violations. The Netapp appliances are painful to dig out the details of, and are exactly the sort of closed appliance that caused Richard Stallman to first become incensed and create the GPL. As such, they well deserve suspicion that they casually violate intellectual property rules.
In fact, I can think of one former Netapp kernel developer I met in another role where he couldn't understand why we published our Linux kernel patches, and thought we could reverse engineer any new Linux kernel back to his antique codebase for any new features we wanted, rather than releasing his modifications so that they would enter the Linux kernel development world and we could stop backporting and get some work done.
Sir, I suspect that you've never attended the meetings where these intellectual property issues are used to resist open source tools. The IBM patent portfolio may be used defensively, but the Microsoft patent portfolio has in fact been used aggressively to block Linux and BSD UNIX installations. Go read the details of the interview with Steve Ballmer at http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/index.htm.
Ahh, I see your point. SPF version one is even better that way, by dropping it at the "FROM" line for the bounce address before even getting to the "From:" line and bouncing back to a forged target. That's probably a bigger advantage during a big email worm attack, rather than during a spam attack. But I see your point.
Not much. Most of it, according to the last numbers I saw from the notes of the MIT Spam Conference, is rootkitted Windows boxes. There are just too many of them and it's just too easy to get more for any such operational feature of the servers themselves to make much of a dent.
I agree that sendmail was horrid to configure. The m4 wrappers have made it better, and Postfix provides an easy to configure tool that actually allows you to rebundle it with the configurations you want. Dan Bernstein's precious ideas of no documentation, his own peculiar and poorly explained licensing, no publication of forks of his code, and mixing the binaries in with the mail spool itself for various reasons are so nasty that many of us working with open source won't touch his utilities.
Which implant? There have been dozens, if not hundreds, of "revolutionary implants". They often fail in the human safety testing. Many are similar to each other: artifical hearing, artificial kidneys, artificial hips (which actually work!), artificial spinal nerves (which don't!), Norplant (for artificual pregnancy hormones, which does work), artificial blood (which apparently does not work well), the various artificial hearts which are just not able to provide normal circulation for prolonged periods, refinements in artificial limbs (which work better mechanically now due to the availability of Teflon and some nifty mechanical tricks), neurally controlled artificial limbs (which don't work well), etc.
I keep an eye on them partly out of curiousity, partly due to some older relatives I keep appraised of interesting technologies.
It's life. They're not discovering new "major diseases" to treat, and the remaining major ones have proven resistant to simple solutions. It's going to take a serious quantum leap in knowledge, such as understanding of the immune system, to provide a set of new medical solutions.
The "medical industry" is not a research industry. It's a service industry, and provides the service of health care to an aging population that refuses to take basic steps to assure its health, such as universal health care, better pre-natal care, eating a better diet, exercising, and visiting a dentist once a year. So don't be surprised that the industry continues quite well providing that health care.
It's not manufactured because it doesn't work long-term. The connections for artifical hearts and lungs are fragile and break down very rapidly, due to both mechanical issues and that tricky problem called the immune system. This isn't an engineering problem: making the connections out of better materials does not integrate them with the body better.
Some tools work: diabetics take insulin, some of them with insulin pumps. People wear glasses and hearing aids and cochlear implants. Others wear pacemakers. But mechanical cardio-vascular replacements? That's just not working yet, not by a long shot.
Intel also stole heavily from the DEC Alpha to create the Pentiums, as described in numerous articles from 10 years ago. Between Intel stealing Alpha development, and Windows stealing VMS features through hiring David Cutler and his gang of software pirates, it's amazing how the other people who both funded and developed the technologies got "innovated" into bankruptcy.
I guess this man wants his genetic research stocks to steal ideas and make money for him the same way that Intel did?
Please don't read in things I didn't say. I did not say "burn up". I referred to the thermal issues common with marginal cooling, especially when the installer fails to use the silver-based thermal paste. Re-install the CPU and heat sink, with better thermal paste, and they're restored.
And no, I'm not talking about gamer rigs. I've seen whole banks of commercial pizza box servers have members start dropping out as the thermal issues of too much CPU, poor airflow, poor cabling practices, too dense of packing, etc. combine to put them on the edge of their thermal tolerance, and start causing failures even while the motherboard thermal monitors read them within spec. And I've seen it with at least two different vendors in the last 5 years.
My experience has been that PSU's fail outright, especially at reboot. But I also do a serious burn-in for new hardware, which helps prevent many of these problems from happening later. And I find dual PSU's to be *extremely* expensive, in power consumption, rack space, UPS provisioning, cable management, support for monitoring, and basic cost of the servers themselves. For the cost of 10 racks of fully dual-supplied systems, I can typically install another 2 distinct sets of 10 racks of cheaper servers, often with more disk or RAM or CPU, in 2 entirely distinct locations.
Oh, you mean that run of bad caps from the stolen tantalum capacitor design? That was a sad problem for a lot of reputable vendors, which I managed to avoid but saw at some distance from the panicked motherboard replacements.
I'm really surprised you're seeing so many failures of PSU's, though. Don't you do at least a 2-day burn-in, or make sure your vendor does it? And avoiding brand-new designs is a good help for overall reliability.
I've seen the kind of "marginal bus errors" you describe on equipment near the end of its effective life, when it's more easily replaced with newer, often more capable or noticeably less power hungry components, say after 3 years. I've also seen similar results when upstream power was not as clean as expected, such as when actually plugging in to the whole rack to the slightly undersized UPS, rather than running it on the test bench. But after 3 years, it's due for replacement anyway by the standards I work with, and is reclaimed by the vendors or sold off to hobbyists. Are you seeing it earlier than that?
From the earlier poster's message, I assume that RedHat was quite firm in saying "it's the power supply". I don't expect them to make a wrong guess and be certain of it. It's possible that RedHat's support people said "the lm_sensor tests and errors are consistent with a power supply issue: contact your hardware vendor to address that", which I would consider just fine, even if it turned out to be something else hardware based. I may well be reading too much certainty into RedHat's support line from a third party report. I don't want to blame some poor tech who did his best, gave an educated opinion, and gets blamed for that best guess being off.
I will blame the tech if he professes hard and fast certainty and turns out to be dead wrong, which is what the poster seemed to describe.
Sadly for me, yes. My clients, with encouragement, do stay one grade above the cheapest 1U vendors, but it helps to actually test the hardware and recommend against vendors who cut the wrong corners.
Are you keeping in mind that there was enough of a system available to do dumps? The power supply failures I've seen have been more profound and immediate, and I kept that in mind. I've seen whole stacks of RAM failures, usually due to someone secretly skimping on the cost of RAM and buying weird third-party versions and not telling anyone. It shows up in testing, but you have to do the tests.
I've also seen quite a few CPU's that start failing after six months because the vendor provided barely enough cooling, but didn't use good quality thermal paste, and cooling degraded. When their techs came out to replace the CPU's, they installed the new ones themselves with good thermal paste, and voila! The issue went away, even when they turned out not to have the replacement in hand and temporarily put the old one back.
I believe you that you've seen different hardware failure patterns. Believe me that I've seen mine, over the course of years.
But for software commpanies reporting hardware problems, yes, I expect it because the failures we see are software failures. If I don't have network connections at home, I look at whether the computer's on, and yes, I call my ISP. If they turn around and say it's due to my computer, I don't expect them to just guess "it's because you run Linux". If my car fails, and I've paid for AAA service, I expect the person who tows my car to not say it's due to bad gasoline when it's actually a bad carburetor.
Yes, the difference between Fedora (which has a lot of bleeding edge software) and RHEL is too great to port things directly back to RHEL. But CentOS has been a very useful intermediate stage: some of us have even used RHEL with the Centosplus repository enabled, to get current versions of tools like MySQL. (That was a big deal in RHEL 4, which had the badly out of date MySQL 4 and serious perl module deficiencies.)
I couldn't have used RHEL 4 without the Centosplus repository, or building up compatible MySQL RPM's myself and maintaining them (which I lacked time to do).
In many if not most cases, the packaging itself is certainly under GPL. I've certainly submitted RPM's to various repositories, and patched them and given them back to RedHat as a good corporate citizen, all under GPL. It's also much easier and safer to be consistent about publishing all of it except those very few components that are not GPL (such as their latest clustering software).
Sadly, RedHat also leaves some available features out of their software, such as NTFS components in their default kernels. Fortunately, CentOS takes up that slack and provides them in the centosplus repository.
No, it's not. Really. There are a whole suite of memory and CPU testers in both the open source world and in the commercial market. Power supplies are one of the *least* likely components to fail: memory is the most vulnerable, CPU's are second especially with cooling issues. The failure to use silver thermal compound on an expensive and not well-ventilated CPU, for example, is a great source of transient CPU failures where the CPU's never show flaws on the test bench, and the flaws under load are intermittent.
Yes, I expect them to guess right, or to say "we don't know". I don't expect a wrong guess from "commercial support".
Or they funnel all their support calls for duplicate installations of RHEL into the one registered license, and use that to download updates. I recently spoke to an engineer trying to talk his employer out of doing that, and switch to CentOS in order to eliminate the licensing violation.
Spam and junk mail are different faces of the same coin. Junk mail is sent because it's a very cheap way to reach a lot of people, and get some business out of it. The margins are low, a lot of it is flat-out fraudulent, but the paper trail makes it traceable to some small extent, so it's somewhat limited.
Spam merely lowers the per-message cost by quite a lot, and lacks the paper trail. But in both cases, they are "unsolicited bulk communications". That's the only definition of spam I've seen that can be easily tested and verified, without getting into complicated issues of free speech or what is and what isn't fraud.
The intermediate is junk fax: notice that that was abused so badly, and was so expensive to the consumer, that it did in fact get outlawed and has witshstood all the constitutional challenges against the ban. I'd love to see that law extended to cover spam: in legal terms, it's a very clear way to extend the same law and the previous constitutional challenges should apply to a decent anti-spam law. But the DMA will never allow it, partly because they're not in this business for the "good of their members". They're in it for the next year's lobby funding.
This doesn't sound like a troll: this sounds like a domain squatter, either hitting you up for a chunk of money, or preserving the name to sell it to someone who *will* give him a chunk of money.
Can you afford a polite conversation with a laywer, and a bit of work tracking what this clown's real business is? His "whois" information for his domains should provide some contact details, and if those are invalid, you can get *his* domain cancelled for providing false contact information.
Given the prevalence of rootkitted Windows boxes and even servers on which spammers rent and lease time, the routing information doesn't do you that much good. And the routing information is often deliberately cluttered with forged and irrelevant headers, so it's not as useful as you might think.
Usenet had similar issues until the "NNTP-Posting-Host" header was added and became popular some years back, in the midst of a nasty war of forged cancellation messages on a Usenet newsgroup.
Unfortunately, it would interfere with the "Direct Marketing Association", a lobby that protects junk mail and junk email. They're thoroughly unwilling to allow any law that might interfere with their clients be passed, so the laws against spam are written only to address the most blatant forms of fraud and carefully avoid putting any responsibility on the network providers who provide them services.
So there remains no law against spam itself, anymore than there is a law against junk mail.
If I wanted a minute's play to wipe out months of work, I'd just run my programs from a root account all the time. No need to take that kind of risk for fun.
Actually, 220 Volt is plenty, and when the rebar gets cut, you're quite likely to notice it popping a fuse. And you don't have to risk the lives of your electricians running 230 kV through poorly electrically isolated rebar.
Slashdot Mirror
Sun and NetApp have been arguing, for years, about patent issues both ways involving STK storage technologies purchased by Sun and used by NetApp, and in turn for these ZFS issues raised by NetAPP. From my experience with both, I'm inclined to believe that Sun is the one that wants actual open source competition, and that is innocent in patent violations. The Netapp appliances are painful to dig out the details of, and are exactly the sort of closed appliance that caused Richard Stallman to first become incensed and create the GPL. As such, they well deserve suspicion that they casually violate intellectual property rules.
In fact, I can think of one former Netapp kernel developer I met in another role where he couldn't understand why we published our Linux kernel patches, and thought we could reverse engineer any new Linux kernel back to his antique codebase for any new features we wanted, rather than releasing his modifications so that they would enter the Linux kernel development world and we could stop backporting and get some work done.
Sir, I suspect that you've never attended the meetings where these intellectual property issues are used to resist open source tools. The IBM patent portfolio may be used defensively, but the Microsoft patent portfolio has in fact been used aggressively to block Linux and BSD UNIX installations. Go read the details of the interview with Steve Ballmer at http://money.cnn.com/magazines/fortune/fortune_archive/2007/05/28/100033867/index.htm.
Ahh, I see your point. SPF version one is even better that way, by dropping it at the "FROM" line for the bounce address before even getting to the "From:" line and bouncing back to a forged target. That's probably a bigger advantage during a big email worm attack, rather than during a spam attack. But I see your point.
Not much. Most of it, according to the last numbers I saw from the notes of the MIT Spam Conference, is rootkitted Windows boxes. There are just too many of them and it's just too easy to get more for any such operational feature of the servers themselves to make much of a dent.
I agree that sendmail was horrid to configure. The m4 wrappers have made it better, and Postfix provides an easy to configure tool that actually allows you to rebundle it with the configurations you want. Dan Bernstein's precious ideas of no documentation, his own peculiar and poorly explained licensing, no publication of forks of his code, and mixing the binaries in with the mail spool itself for various reasons are so nasty that many of us working with open source won't touch his utilities.
Which implant? There have been dozens, if not hundreds, of "revolutionary implants". They often fail in the human safety testing. Many are similar to each other: artifical hearing, artificial kidneys, artificial hips (which actually work!), artificial spinal nerves (which don't!), Norplant (for artificual pregnancy hormones, which does work), artificial blood (which apparently does not work well), the various artificial hearts which are just not able to provide normal circulation for prolonged periods, refinements in artificial limbs (which work better mechanically now due to the availability of Teflon and some nifty mechanical tricks), neurally controlled artificial limbs (which don't work well), etc.
I keep an eye on them partly out of curiousity, partly due to some older relatives I keep appraised of interesting technologies.
It's life. They're not discovering new "major diseases" to treat, and the remaining major ones have proven resistant to simple solutions. It's going to take a serious quantum leap in knowledge, such as understanding of the immune system, to provide a set of new medical solutions.
The "medical industry" is not a research industry. It's a service industry, and provides the service of health care to an aging population that refuses to take basic steps to assure its health, such as universal health care, better pre-natal care, eating a better diet, exercising, and visiting a dentist once a year. So don't be surprised that the industry continues quite well providing that health care.
It's not manufactured because it doesn't work long-term. The connections for artifical hearts and lungs are fragile and break down very rapidly, due to both mechanical issues and that tricky problem called the immune system. This isn't an engineering problem: making the connections out of better materials does not integrate them with the body better. Some tools work: diabetics take insulin, some of them with insulin pumps. People wear glasses and hearing aids and cochlear implants. Others wear pacemakers. But mechanical cardio-vascular replacements? That's just not working yet, not by a long shot.
Intel also stole heavily from the DEC Alpha to create the Pentiums, as described in numerous articles from 10 years ago. Between Intel stealing Alpha development, and Windows stealing VMS features through hiring David Cutler and his gang of software pirates, it's amazing how the other people who both funded and developed the technologies got "innovated" into bankruptcy.
I guess this man wants his genetic research stocks to steal ideas and make money for him the same way that Intel did?
Please don't read in things I didn't say. I did not say "burn up". I referred to the thermal issues common with marginal cooling, especially when the installer fails to use the silver-based thermal paste. Re-install the CPU and heat sink, with better thermal paste, and they're restored.
And no, I'm not talking about gamer rigs. I've seen whole banks of commercial pizza box servers have members start dropping out as the thermal issues of too much CPU, poor airflow, poor cabling practices, too dense of packing, etc. combine to put them on the edge of their thermal tolerance, and start causing failures even while the motherboard thermal monitors read them within spec. And I've seen it with at least two different vendors in the last 5 years.
My experience has been that PSU's fail outright, especially at reboot. But I also do a serious burn-in for new hardware, which helps prevent many of these problems from happening later. And I find dual PSU's to be *extremely* expensive, in power consumption, rack space, UPS provisioning, cable management, support for monitoring, and basic cost of the servers themselves. For the cost of 10 racks of fully dual-supplied systems, I can typically install another 2 distinct sets of 10 racks of cheaper servers, often with more disk or RAM or CPU, in 2 entirely distinct locations.
Oh, you mean that run of bad caps from the stolen tantalum capacitor design? That was a sad problem for a lot of reputable vendors, which I managed to avoid but saw at some distance from the panicked motherboard replacements.
I'm really surprised you're seeing so many failures of PSU's, though. Don't you do at least a 2-day burn-in, or make sure your vendor does it? And avoiding brand-new designs is a good help for overall reliability.
I've seen the kind of "marginal bus errors" you describe on equipment near the end of its effective life, when it's more easily replaced with newer, often more capable or noticeably less power hungry components, say after 3 years. I've also seen similar results when upstream power was not as clean as expected, such as when actually plugging in to the whole rack to the slightly undersized UPS, rather than running it on the test bench. But after 3 years, it's due for replacement anyway by the standards I work with, and is reclaimed by the vendors or sold off to hobbyists. Are you seeing it earlier than that?
From the earlier poster's message, I assume that RedHat was quite firm in saying "it's the power supply". I don't expect them to make a wrong guess and be certain of it. It's possible that RedHat's support people said "the lm_sensor tests and errors are consistent with a power supply issue: contact your hardware vendor to address that", which I would consider just fine, even if it turned out to be something else hardware based. I may well be reading too much certainty into RedHat's support line from a third party report. I don't want to blame some poor tech who did his best, gave an educated opinion, and gets blamed for that best guess being off.
I will blame the tech if he professes hard and fast certainty and turns out to be dead wrong, which is what the poster seemed to describe.
Sadly for me, yes. My clients, with encouragement, do stay one grade above the cheapest 1U vendors, but it helps to actually test the hardware and recommend against vendors who cut the wrong corners.
Are you keeping in mind that there was enough of a system available to do dumps? The power supply failures I've seen have been more profound and immediate, and I kept that in mind. I've seen whole stacks of RAM failures, usually due to someone secretly skimping on the cost of RAM and buying weird third-party versions and not telling anyone. It shows up in testing, but you have to do the tests.
I've also seen quite a few CPU's that start failing after six months because the vendor provided barely enough cooling, but didn't use good quality thermal paste, and cooling degraded. When their techs came out to replace the CPU's, they installed the new ones themselves with good thermal paste, and voila! The issue went away, even when they turned out not to have the replacement in hand and temporarily put the old one back.
I believe you that you've seen different hardware failure patterns. Believe me that I've seen mine, over the course of years.
But for software commpanies reporting hardware problems, yes, I expect it because the failures we see are software failures. If I don't have network connections at home, I look at whether the computer's on, and yes, I call my ISP. If they turn around and say it's due to my computer, I don't expect them to just guess "it's because you run Linux". If my car fails, and I've paid for AAA service, I expect the person who tows my car to not say it's due to bad gasoline when it's actually a bad carburetor.
Not everybody does that. But no, I've gone quite a bit further than that. Unfortunately, I'd get into NDA material pretty fast if I went into details.
Yes, the difference between Fedora (which has a lot of bleeding edge software) and RHEL is too great to port things directly back to RHEL. But CentOS has been a very useful intermediate stage: some of us have even used RHEL with the Centosplus repository enabled, to get current versions of tools like MySQL. (That was a big deal in RHEL 4, which had the badly out of date MySQL 4 and serious perl module deficiencies.)
I couldn't have used RHEL 4 without the Centosplus repository, or building up compatible MySQL RPM's myself and maintaining them (which I lacked time to do).
In many if not most cases, the packaging itself is certainly under GPL. I've certainly submitted RPM's to various repositories, and patched them and given them back to RedHat as a good corporate citizen, all under GPL. It's also much easier and safer to be consistent about publishing all of it except those very few components that are not GPL (such as their latest clustering software).
Sadly, RedHat also leaves some available features out of their software, such as NTFS components in their default kernels. Fortunately, CentOS takes up that slack and provides them in the centosplus repository.
No, it's not. Really. There are a whole suite of memory and CPU testers in both the open source world and in the commercial market. Power supplies are one of the *least* likely components to fail: memory is the most vulnerable, CPU's are second especially with cooling issues. The failure to use silver thermal compound on an expensive and not well-ventilated CPU, for example, is a great source of transient CPU failures where the CPU's never show flaws on the test bench, and the flaws under load are intermittent.
Yes, I expect them to guess right, or to say "we don't know". I don't expect a wrong guess from "commercial support".
Or they funnel all their support calls for duplicate installations of RHEL into the one registered license, and use that to download updates. I recently spoke to an engineer trying to talk his employer out of doing that, and switch to CentOS in order to eliminate the licensing violation.
Spam and junk mail are different faces of the same coin. Junk mail is sent because it's a very cheap way to reach a lot of people, and get some business out of it. The margins are low, a lot of it is flat-out fraudulent, but the paper trail makes it traceable to some small extent, so it's somewhat limited.
Spam merely lowers the per-message cost by quite a lot, and lacks the paper trail. But in both cases, they are "unsolicited bulk communications". That's the only definition of spam I've seen that can be easily tested and verified, without getting into complicated issues of free speech or what is and what isn't fraud.
The intermediate is junk fax: notice that that was abused so badly, and was so expensive to the consumer, that it did in fact get outlawed and has witshstood all the constitutional challenges against the ban. I'd love to see that law extended to cover spam: in legal terms, it's a very clear way to extend the same law and the previous constitutional challenges should apply to a decent anti-spam law. But the DMA will never allow it, partly because they're not in this business for the "good of their members". They're in it for the next year's lobby funding.
This doesn't sound like a troll: this sounds like a domain squatter, either hitting you up for a chunk of money, or preserving the name to sell it to someone who *will* give him a chunk of money.
Can you afford a polite conversation with a laywer, and a bit of work tracking what this clown's real business is? His "whois" information for his domains should provide some contact details, and if those are invalid, you can get *his* domain cancelled for providing false contact information.
Given the prevalence of rootkitted Windows boxes and even servers on which spammers rent and lease time, the routing information doesn't do you that much good. And the routing information is often deliberately cluttered with forged and irrelevant headers, so it's not as useful as you might think.
Usenet had similar issues until the "NNTP-Posting-Host" header was added and became popular some years back, in the midst of a nasty war of forged cancellation messages on a Usenet newsgroup.
Unfortunately, it would interfere with the "Direct Marketing Association", a lobby that protects junk mail and junk email. They're thoroughly unwilling to allow any law that might interfere with their clients be passed, so the laws against spam are written only to address the most blatant forms of fraud and carefully avoid putting any responsibility on the network providers who provide them services.
So there remains no law against spam itself, anymore than there is a law against junk mail.
If I wanted a minute's play to wipe out months of work, I'd just run my programs from a root account all the time. No need to take that kind of risk for fun.
The chemistry notation is apparently confusing you: try this for more normal looking math.
2(H*2) + (O*2) = 2(H*2 + O)
Does that make more sense now?
Actually, 220 Volt is plenty, and when the rebar gets cut, you're quite likely to notice it popping a fuse. And you don't have to risk the lives of your electricians running 230 kV through poorly electrically isolated rebar.