Absolutely. These big companies have managed a clever scheme to hijack the resolution of the problems with Software Patents. Instead, this gives the Patent Office some credibility, while at the same time offering a platform to make certain that no individual ever threatens these companies again with Software Patents.
Take Microsoft. They've spend a ton of money this year alone settling patent infringement claims against small people/organizations. Now they no longer have to. And Microsoft isn't the only one.
Back in the 70's, the rumors (I heard from guys at IBM no less) were that IBM had Patent Examiners on the take to make certain no patent popped up that might be a threat to them. Now they've created a monster that is much cheaper to operate.
In short, this approach gives the appearance that the big companies can collaborate to approve each others patents, while completely shutting out any little guy who might be a threat. Companies are obligated to do things in their own best interest. And they appear to be taking the Patent Office for a ride.
I'm sorry, but this is yet another incredible screw-up by the Patent Office, once more displaying that they just haven't a clue about what they are doing. This effort raises so many questions about conflict of interest that it just doesn't have any credibility whatsoever.
There really is no way out of the Software Patent mess other than to abolish them. Until then, innovation will continue to suffer.
I was all set to order two of these. Only I never got the confirmation email.
You have to wonder about how many other pledges they dropped. Perhaps not 95,000. But honestly, if they can't handle just simple web/email transactions there's a very high probability they wouldn't be able to handle shipping 100,000 OLPC systems.
This effort needs to examine where they failed and try to improve things if they want to succeed. I do hope they try. And I'd pay $500 for each of these, just to be able to play with them.
I agree completely; you are quite correct. Thank you for pointing that out.
It was clearly a failure of process here. Having built my own home-grown RAID
systems from scratch, I find them quite useful. Like any system, incorrect
usage will lead to problems. Such was the case here.
Indeed, one of the options was to build one simply for the storage here. Had I
been guaranteed reimbursement for this, one could've been put together
in a day or so.
dd wasn't an option as we didn't have enough free disk space for making such an image. We'd have had to have either set up another large RAID array, or have bought a new NAS server. Both would take time just to get the approval; and in the case of the NAS server, it would be a significant amount of time.
And time was of the essense, because having a bunch of engineers sitting around waiting for their files adds up to a significant amount of money.
IT departments in large companies are a little funny, in that they'd prefer to go with the NAS server. Mostly because of job security in case things go wrong. And it was the home-grown RAID array which triggered this mess in the first place.
That was a good article. However, there was one very key point which was missed. Specifically, the importance of using Open Source tools. Which this might be implied by the references, the author (like most people) have never faced a disaster situation where Open Source was the only way to do the backup and recovery.
Here's a real life case in point that I came across with a Fortune 500 company. This company had recently aquired a small startup, who's system administration skills were lacking. Before moving to the new facilities after being aquired, one of the V.P.'s told people not to bother copying their home directories from the server. They then proceeded to simply shut off the power to the server without doing a proper shutdown.
The server was using a Reiser FS, and this filesystem was spectacularly fried when it arrived that the big company. Tons of supposedly petabyte file sizes, and even more in the Terabyte range (clearly exceeding the size of the disk array). In the end, over 12,000 files and directories would end up under lost+found.
Anyway, it was decided to backup the filesystem before attempting to recover the files. Absolutely everything broke when trying to do this, as Linux doesn't handle petabyte (or even terabyte) files properly. There are subtle problems with all of the utilities (find, ls, cp, cpio, and tar, to name just a few). While this isn't surprising, when you're trying to make a backup, it presents a serious problem.
Were we dependent upon a closed-source solution, we would've been seriously stuck waiting for a fix.
In the end, I actually had to modify GNU tar to handle these problems. This was particularly amusing, as tar handn't been modified in years. But it was the only way out of the situation in a timely fashion.
The point here is that you have this option for really nasty disaster scenarios if you are familiar with Open Source tools.
Oh please. The reason why it's not a surprise is probably because lots of people knew about the situation beforehand. This has even been mentioned on some Linux mailing lists already, so it's really no surprise if you've been following this.
Here's a link to some of the media coverage from last month:
I'm sorry, but I have to strongly disagree. Decentralization is NOT good. Centralization is NOT good. Both are good at times, and bad at times. The trick is that you have to know when to use each, and when to avoid them.
Just saying one is always good is just plain silly. And, no disrespect intended, it indicates to me that you don't understand all of the variances which go one.
A case in point is your strawman argument. All this says is that your main application is naturally parallel, nor IO bound. I can guarantee you that I can create an application where your big-node cluster isn't faster. And that's not even with touching the IO issues.
And do some research on the channel architecture sometime. The common cluster solutions just don't come close. I won't even go into the maintenance and upkeep issues..
The point is, one should know one's problem and what tools are available. There is no single silver bullet for all problems. Claiming otherwise is just plain silly.
Mainframes are absolutely competitive. The main reason why people have stuck with mainframes is IO bandwidth. The PC solutions (even clustered) just can't touch the channel architecture, and never have been able to.
The second main reason why people go with mainframes is that it's more cost-effective to centralize your compute resources in one system, when it comes to maintenance, for many solutions. One single rack or so is a heck of a lot easier to maintain than a Beowulf cluster of boxes, particularly if the latter are scattered.
So yes, for certain niches, mainframes are the way to go.
Dice is simply the best. Well, THE best is a recruiter who supplies you with the royalty treatment, but you have to work a tad for that.
Seriously, though, you DO realize that what you are complaining about is the sign of a healthy, free market job board? Of course you get spammed. How exactly are you going to have a large job board and not get spammed? The best you can do is with a Social Network approach, but even that can be rigged.
I personally find the spam of use - it lets me know what agents to avoid. That is key. There are a LOT of sleezy agents/recruiters out there, and you really want to avoid the bad ones.
Honestly, your gripe sounds like someone who has just gone to a bazaar for the first time, and was expecting to find a supermarket.
I don't use anything else other than Dice, but then, I do contracting. None of the other boards are set up for effective use by contractors; they don't care, and it shows. Also, I've been seeing more direct contacts there, as some companies are slowly finding out that they can do what recruiters do, and save a bunch of money.
Alas, no. See my other comment above, on this thread.
The problem here is that none of these efforts offer a developer help in Patenting an idea. They are all after the fact. I.e. if you get a Patent, they'll gladly take it from you; but none of them offer you any help at all in getting the Patent in the first place.
My point is that developers can be a rather creative lot, and we should tap into that creativity. The only way to do this is by offering them legal support in actually getting the patent done.
The problem with the current implementation of the Commons is that it's passive, not aggressive. What I'm referring to is a handholding effort of helping developers through the Patent Filing process. I.e. a clear step up from the NoLo Press book on how to file a patent.
This is as opposed to the current Commons project, which is mostly just a collection effort of existing patents.
I've always wondered why the EFF doesn't promote a similar thing, but with an Open Source version. That is, helping individual Open Source developers patent new software patents, as long as the software is (say) released under version 3 of the GPL.
Or in otherwords, imagine a Beowulf Cluster (pardon the phrase) of Open Source patent filers. Intellectual Ventures wouldn't stand a chance.
Personally, I'm very opposed to Software Patents, as the EFF is. However, I can really see no other way of effectively changing the system in the near term other than this. Especially if, every so often, one files a suit against a closed-source company, and ends up with hundreds of millions of dollars to fund futher suits (E.g. What happened with RIM and their Blackberries).
I can well imagine that, if you make the big companies scream loudly enough, by hitting them where it hurts, they will end up running to Congress for protection. And, if done right, the only protection is eliminating Software Patents.
Aside from the distastefulness of dealing with Software Patents, I can so no reason why this type of strategy won't work. If anyone can spot what I'm missing from a strategic view, I'd appreciate knowing about it.
"if you can export PGP source code without violating U.S. export restrictions, I'm betting you can export data sheets too."
That's an interesting question. If people will recall, the PGP source code was put into a paper book and published. Explicitly to see if the U.S. Government would try to trump Freedom of the Press with Export Restrictions. The Feds didn't even bother to try.
Of course, this was after Kelly Goen released the source code, by putting PGP up on U.S. servers, and simply announcing where to find it. It was this latter method of release which got Kelly and Phil hauled up in front of the Grand Jury - not any book publications.
So, if Hifn is truly concerned about export restrictions on the data sheets, perhaps they should simply publish them in paperback form, with a binder and get an ISBN number.
I strongly doubt there will be any problems at all.
Oh no, not at all. There's a key potential difference here with this legislation. Most legislation sails right through Congress without so much as a whisper from the voters at home. On that, we seem to agree.
And this is what gives lobbiests (for both corporate and beaurecratic interests, like the DoJ) the ability to sway Congress.
The difference here is that this legislation will end up hitting people right in the pocketbook. Most people tend to get annoyed with that (they want their cheap internet!). Couple that with telling them that they have to pay the extra money so that the Government can spy on them. This is a potential PR disaster for the Feds, if the ISPs play their cards right.
And finally, couple this with appropriate lobbying. The ISP's do have the funds to do this.
In short, the ISPs have the ability to stir things up in a very unusual fashion. The only question is whether or not they have the willpower and gumption to do this.
I don't think the Feds have realized exactly who they are dealing with. Last I heard, 60+% of America was connected to the Internet.
All the ISP's have to do is to send an email to each of their subscribers pointing out that:
1. Congress is considering wiretapping their Internet surfing.
2. Each user is going to have to pay more in order to allow this wiretapping.
The latter is especially important, as people really don't like their rates to go up.
And of course, include the phone number and mail address that people can call or write to complain about this.
Somehow, I think Congress will (at the least) think twice about this proposal.
The ISP's have a VAST potential for lobbying Congress on this issue. No other industry can reach so directly to the general population in order to make their voice heard.
Probably. But not with the latest source code. There would be a turn-around time. The point (that you left out) is that its adoption would be limited significantly. Can you cite some instances where regulation of an industry did not reduce the number of participants (which was the original point)?
If you don't believe that less participants, plus having to follow Regulations in publishing code would be a strong disincentive for spurring independent developers, I won't try to convince you. But I think that the current marketplace is a superb example to the contrary. Which is something that Closed-source developers don't seem to ever understand.
The GP completely missed the point that the OP was making. And it made an ad-hominum attack as well.
How in the world was the GP modded +5 insightful?
By the GP's logic, regulation of the industry will either help, or won't hurt, Open Source at all. That is obviously absurd. Take, for example, a completely unregulated developer, outside the U.S., in Finland who decides to create an Operating System called Linux. It strikes me that any regulations here on Operating Systems would prevent many businesses from deploying it, and thus limiting its adoption (particularly on servers) significantly.
This is what the closed source companies would like. And was the original point before the GP took the subject off on a different tangent.
"Does it make anybody else nervous that there is a market for these products? "off the shelf" products that can scale to this degree?"
Of course there's a market for this. Where have you been? Universities and Companies have been rolling these things out to keep an eye on their networks for a while now. And this has been predicted for a long time before that.
You couple this, along with lots of cheap SATA storage on a Hypertransport Bus, and you're looking at storing network information for at least months, possibly years. At the rate technology is going, it will only get easier to store all of a student/employee's network connectivity for forever.
It looks like the tinfoil hat crowd was right all along. Clearly it's time to wake up and become aware of this stuff, as it's only going to become more ubiquitous.
I had a similar thought when I saw this. But I also had to wonder how long it will be until such information is kept from public view, on the basis of "National Security"?
Ummm, I take it you've never had to optimize FP code, have you? Nor have you even looked at code in this category.
For the time intensive calculations, people actually spend a lot of time optimizing the code. First they put it into assembly; and then they pour over every single assembly statement. You set, a tiny efficiency tweak, saving X number of cycles does indeed add up if you're running it for days or weeks at a time.
This is why I mentioned that mods to gcc might be a solution, but I doubt any changes there would happen. Perhaps I should've been more clear, but I thought that was self-explanatory.
Agreed; the GP doesn't understand the problem. At best, you might modify gcc; but I suspect that might be a pain, considering it's such a limited problem (according to the rumor mentioned in TFA).
There's no way the kernel can do anything about it, from the description of the problem.
And, contrary to AMD's attempts to downplay this issue, there are two immediate areas that I can think of which are affected. The first are certain scientific calculations (even worse, those involving Beowulf clusters). The second are CAD simulations.
Both areas can involve calculations which run for days at a time; far in excess of the hours mentioned in the fine article.
In general, people don't really seem to pay much attention to either the reliability of the CPU or the quality of the RAM though. Witness the number of really cheap systems that people buy for this type of work. Perhaps this will be a "heads up" that yes, even the most basic subsystem of your computer can go haywire, skewing your results, and wasting your time.
Slashdot Mirror
Take Microsoft. They've spend a ton of money this year alone settling patent infringement claims against small people/organizations. Now they no longer have to. And Microsoft isn't the only one.
Back in the 70's, the rumors (I heard from guys at IBM no less) were that IBM had Patent Examiners on the take to make certain no patent popped up that might be a threat to them. Now they've created a monster that is much cheaper to operate.
In short, this approach gives the appearance that the big companies can collaborate to approve each others patents, while completely shutting out any little guy who might be a threat. Companies are obligated to do things in their own best interest. And they appear to be taking the Patent Office for a ride.
I'm sorry, but this is yet another incredible screw-up by the Patent Office, once more displaying that they just haven't a clue about what they are doing. This effort raises so many questions about conflict of interest that it just doesn't have any credibility whatsoever.
There really is no way out of the Software Patent mess other than to abolish them. Until then, innovation will continue to suffer.
You have to wonder about how many other pledges they dropped. Perhaps not 95,000. But honestly, if they can't handle just simple web/email transactions there's a very high probability they wouldn't be able to handle shipping 100,000 OLPC systems.
This effort needs to examine where they failed and try to improve things if they want to succeed. I do hope they try. And I'd pay $500 for each of these, just to be able to play with them.
It was clearly a failure of process here. Having built my own home-grown RAID systems from scratch, I find them quite useful. Like any system, incorrect usage will lead to problems. Such was the case here.
Indeed, one of the options was to build one simply for the storage here. Had I been guaranteed reimbursement for this, one could've been put together in a day or so.
Unfortunately, the reimbusement was an issue.
And time was of the essense, because having a bunch of engineers sitting around waiting for their files adds up to a significant amount of money.
IT departments in large companies are a little funny, in that they'd prefer to go with the NAS server. Mostly because of job security in case things go wrong. And it was the home-grown RAID array which triggered this mess in the first place.
Here's a real life case in point that I came across with a Fortune 500 company. This company had recently aquired a small startup, who's system administration skills were lacking. Before moving to the new facilities after being aquired, one of the V.P.'s told people not to bother copying their home directories from the server. They then proceeded to simply shut off the power to the server without doing a proper shutdown.
The server was using a Reiser FS, and this filesystem was spectacularly fried when it arrived that the big company. Tons of supposedly petabyte file sizes, and even more in the Terabyte range (clearly exceeding the size of the disk array). In the end, over 12,000 files and directories would end up under lost+found.
Anyway, it was decided to backup the filesystem before attempting to recover the files. Absolutely everything broke when trying to do this, as Linux doesn't handle petabyte (or even terabyte) files properly. There are subtle problems with all of the utilities (find, ls, cp, cpio, and tar, to name just a few). While this isn't surprising, when you're trying to make a backup, it presents a serious problem.
Were we dependent upon a closed-source solution, we would've been seriously stuck waiting for a fix.
In the end, I actually had to modify GNU tar to handle these problems. This was particularly amusing, as tar handn't been modified in years. But it was the only way out of the situation in a timely fashion.
The point here is that you have this option for really nasty disaster scenarios if you are familiar with Open Source tools.
Here's a link to some of the media coverage from last month:
http://abclocal.go.com/kgo/story?section=local&id= 4558883
Just saying one is always good is just plain silly. And, no disrespect intended, it indicates to me that you don't understand all of the variances which go one.
A case in point is your strawman argument. All this says is that your main application is naturally parallel, nor IO bound. I can guarantee you that I can create an application where your big-node cluster isn't faster. And that's not even with touching the IO issues.
And do some research on the channel architecture sometime. The common cluster solutions just don't come close. I won't even go into the maintenance and upkeep issues..
The point is, one should know one's problem and what tools are available. There is no single silver bullet for all problems. Claiming otherwise is just plain silly.
Mainframes are absolutely competitive. The main reason why people have stuck with mainframes is IO bandwidth. The PC solutions (even clustered) just can't touch the channel architecture, and never have been able to.
The second main reason why people go with mainframes is that it's more cost-effective to centralize your compute resources in one system, when it comes to maintenance, for many solutions. One single rack or so is a heck of a lot easier to maintain than a Beowulf cluster of boxes, particularly if the latter are scattered.
So yes, for certain niches, mainframes are the way to go.
Seriously, though, you DO realize that what you are complaining about is the sign of a healthy, free market job board? Of course you get spammed. How exactly are you going to have a large job board and not get spammed? The best you can do is with a Social Network approach, but even that can be rigged.
I personally find the spam of use - it lets me know what agents to avoid. That is key. There are a LOT of sleezy agents/recruiters out there, and you really want to avoid the bad ones.
Honestly, your gripe sounds like someone who has just gone to a bazaar for the first time, and was expecting to find a supermarket.
I don't use anything else other than Dice, but then, I do contracting. None of the other boards are set up for effective use by contractors; they don't care, and it shows. Also, I've been seeing more direct contacts there, as some companies are slowly finding out that they can do what recruiters do, and save a bunch of money.
No, no, no. You're supposed to LIGHT your cigs using the CPU, not put them out!
The problem here is that none of these efforts offer a developer help in Patenting an idea. They are all after the fact. I.e. if you get a Patent, they'll gladly take it from you; but none of them offer you any help at all in getting the Patent in the first place.
My point is that developers can be a rather creative lot, and we should tap into that creativity. The only way to do this is by offering them legal support in actually getting the patent done.
The problem with the current implementation of the Commons is that it's passive, not aggressive. What I'm referring to is a handholding effort of helping developers through the Patent Filing process. I.e. a clear step up from the NoLo Press book on how to file a patent.
This is as opposed to the current Commons project, which is mostly just a collection effort of existing patents.
Or in otherwords, imagine a Beowulf Cluster (pardon the phrase) of Open Source patent filers. Intellectual Ventures wouldn't stand a chance.
Personally, I'm very opposed to Software Patents, as the EFF is. However, I can really see no other way of effectively changing the system in the near term other than this. Especially if, every so often, one files a suit against a closed-source company, and ends up with hundreds of millions of dollars to fund futher suits (E.g. What happened with RIM and their Blackberries).
I can well imagine that, if you make the big companies scream loudly enough, by hitting them where it hurts, they will end up running to Congress for protection. And, if done right, the only protection is eliminating Software Patents.
Aside from the distastefulness of dealing with Software Patents, I can so no reason why this type of strategy won't work. If anyone can spot what I'm missing from a strategic view, I'd appreciate knowing about it.
That's an interesting question. If people will recall, the PGP source code was put into a paper book and published. Explicitly to see if the U.S. Government would try to trump Freedom of the Press with Export Restrictions. The Feds didn't even bother to try.
Of course, this was after Kelly Goen released the source code, by putting PGP up on U.S. servers, and simply announcing where to find it. It was this latter method of release which got Kelly and Phil hauled up in front of the Grand Jury - not any book publications.
So, if Hifn is truly concerned about export restrictions on the data sheets, perhaps they should simply publish them in paperback form, with a binder and get an ISBN number.
I strongly doubt there will be any problems at all.
And this is what gives lobbiests (for both corporate and beaurecratic interests, like the DoJ) the ability to sway Congress.
The difference here is that this legislation will end up hitting people right in the pocketbook. Most people tend to get annoyed with that (they want their cheap internet!). Couple that with telling them that they have to pay the extra money so that the Government can spy on them. This is a potential PR disaster for the Feds, if the ISPs play their cards right.
And finally, couple this with appropriate lobbying. The ISP's do have the funds to do this.
In short, the ISPs have the ability to stir things up in a very unusual fashion. The only question is whether or not they have the willpower and gumption to do this.
All the ISP's have to do is to send an email to each of their subscribers pointing out that:
1. Congress is considering wiretapping their Internet surfing.
2. Each user is going to have to pay more in order to allow this wiretapping.
The latter is especially important, as people really don't like their rates to go up. And of course, include the phone number and mail address that people can call or write to complain about this.
Somehow, I think Congress will (at the least) think twice about this proposal.
The ISP's have a VAST potential for lobbying Congress on this issue. No other industry can reach so directly to the general population in order to make their voice heard.
I do hope they use it.
"We're legislating ourselves into becoming a third world nation."
Sadly, this applies far beyond this particular case, or even the original discussion on chemistry discussion at the other site.
My apologies for the confusion then. I wasn't suggesting that it would eliminate Open Source; rather, that it would limit its adoption.
If you don't believe that less participants, plus having to follow Regulations in publishing code would be a strong disincentive for spurring independent developers, I won't try to convince you. But I think that the current marketplace is a superb example to the contrary. Which is something that Closed-source developers don't seem to ever understand.
How in the world was the GP modded +5 insightful?
By the GP's logic, regulation of the industry will either help, or won't hurt, Open Source at all. That is obviously absurd. Take, for example, a completely unregulated developer, outside the U.S., in Finland who decides to create an Operating System called Linux. It strikes me that any regulations here on Operating Systems would prevent many businesses from deploying it, and thus limiting its adoption (particularly on servers) significantly.
This is what the closed source companies would like. And was the original point before the GP took the subject off on a different tangent.
Of course there's a market for this. Where have you been? Universities and Companies have been rolling these things out to keep an eye on their networks for a while now. And this has been predicted for a long time before that.
Here's another product which basically does the same thing
You couple this, along with lots of cheap SATA storage on a Hypertransport Bus, and you're looking at storing network information for at least months, possibly years. At the rate technology is going, it will only get easier to store all of a student/employee's network connectivity for forever.
It looks like the tinfoil hat crowd was right all along. Clearly it's time to wake up and become aware of this stuff, as it's only going to become more ubiquitous.
If you're looking for a defense, the only complete one is Tor .
Let the media giants DRM what they want. They'll only succeed in pushing people to other alternatives.
I had a similar thought when I saw this. But I also had to wonder how long it will be until such information is kept from public view, on the basis of "National Security"?
For the time intensive calculations, people actually spend a lot of time optimizing the code. First they put it into assembly; and then they pour over every single assembly statement. You set, a tiny efficiency tweak, saving X number of cycles does indeed add up if you're running it for days or weeks at a time.
This is why I mentioned that mods to gcc might be a solution, but I doubt any changes there would happen. Perhaps I should've been more clear, but I thought that was self-explanatory.
There's no way the kernel can do anything about it, from the description of the problem.
And, contrary to AMD's attempts to downplay this issue, there are two immediate areas that I can think of which are affected. The first are certain scientific calculations (even worse, those involving Beowulf clusters). The second are CAD simulations.
Both areas can involve calculations which run for days at a time; far in excess of the hours mentioned in the fine article.
In general, people don't really seem to pay much attention to either the reliability of the CPU or the quality of the RAM though. Witness the number of really cheap systems that people buy for this type of work. Perhaps this will be a "heads up" that yes, even the most basic subsystem of your computer can go haywire, skewing your results, and wasting your time.