I'm guessing that AOL will go for something like grand theft. The list was re-sold for $52,000. No telling how much the guy he originally gave it to paid him. I'm sure the value of the list to AOL's business is much higher but this sets a lower bound that easily puts the theft into the range where grand theft would stick. From this perspective, what he did was no different than carting out a server or some other piece of equipment and fencing it for $52,000.
Personally, I think the dweeb should be staked out on an ant-hill or drawn and quartered but I've been accused of being a little extreme when it comes to spam, spammers and people who disclose e-mail addresses without the owners's permission.
Interesting question. There is a word for conveying a paid, commercial message: advertising.
I wonder what would happen if complaints against these supposed "think tanks" were filed with the IRS (advertising is *not* something for a not-for-profit organization to engage in; its a business activity) and the FTC (deceptive advertising). It may not be possible to nail them for their current activities but the tobacco industry disclosures are apparently a matter of public record and indicate a direct linkage between "contributions" and "study results".
I've worked for quite a few different people over the last 20+ years. Based on how their career went, some were good at management; some were not. One reason I got out of a management career track was I realized that the perception of how well these folks were doing was more important than to their career than their actual results. I found that I could get along with most people as long as they perceived me as contributing to their success.
The one thing I absolutely could not and still cannot stand in a manager is if they try to tell me how to do my job. I expect my manager to give me tasks to do and its up to me to figure out how to perform them. I don't expect them to set up my daily calendar. Unfortunately, some people want to manage at too low a level. This has applied as much to some of the managers I otherwise got along with as to some that I thought were absolute jerks. Be wary of any candidate you talk to who is too much into the details of how you do what you caurrentyly do. You don't want someone critiquing you on your mouse click technique.
I'm glad I'm not the only one who thought that. Mr. Willis needs to also experience working in a large programming environment (e.g., 100+ developers working on something over several years). Many of the lessons from "The Mythical Man-Month" only become apparent when the size of the project is such that no one person can understand the whole in complete detail. An architech or cheif engineer may understand the overall concept but will not understand every gory detail at the lower-most levels.
Likewise, his lack of any understanding of how the cost of correcting an error grows exponentially with how late in the development cycle the error is discovered speaks volumes about his lack of experience in commercial software (e.g., what if the bug requires the documentation to be re-printed? how about if it requires a product recall and/or advertising campaign to mitigate the harm to the reputation of the company doing the development?). That Microsoft follows the model of charging people for a new version of their bloatware that fixes the bugs in the previous version (while introducing more bugs at the same time) may be a good business model but it is hardly a contribution to the science of developing software.
Too bad no editor at O'Reilley had enough sense to tell him to try again. On the plus side, maybe this will get a few more people to read TMMM before they transform into PHBs. Maybe Ed should apply for a position as a writer at the Alexis de Tocqueville Institute. I understand that they don't require that the people who write for them have any knowledge about what they're writing about.
The example is literally working with up to ~100GB "archives" of "event data" to be restored from a remote file server. The system doing the work is either an 4 CPU Dell 6650 with 8GB of RAM or a 2 CPU Dell 1750 with 2GB of RAM. Files in the archives consist of metadata identifying the file contents and the application data. Restoring an archive means the metadata gets stuffed into a postgres database with the application data remaining accessible through the file system. An "archive" such as this can consist of up to 1.7 million event files. The implementation language is Java as Java Server Pages (JSP) on a Red Hat Enterprise Linux 3 platform. The 6650 has a RAID 5 array to help provide better I/O throughput.
The developers tend to test with (and think in terms of) small archives of several hundred event files and an archive size on the order of tens of megabytes. Multi-threading a few of these *appears* to work well and even doing a bunch doesn't seem to do much harm due to their size. Even at a point in between these extremes (e.g., 10 GB archive of a few hundred thousand event files), all it takes is firing off a couple of actions concurrently and the system is as good as dead. Running top on the system will reveal almost no user CPU cycles but everything solidly in I/O wait. At least the developers didn't try to mmap the archive.
The real problem is the massive, monolithic archive which really isn't required since the end users access the event data through the metadata in the database. It would be fairly easy to also do a little more "book-keeping" and spread the events through several smaller archives. Unfortunately, the same developers seem to have trouble grasping this and want to cling to the single archive file design. The trick *isn't* to find a way of doing what we're currently trying to do but, instead, find an easier way to provide the user with the data they're interested in (e.g., try the door handle before you attempt to break down the door).
Your example struck a nerve because I just went through having to show a developer how his design failed because he launched a separate thread for each action the user requested. His solution worked great when the number of requested actions was less than the number of CPUs (4 in this case: 2 physical and 2 HT). It wasn't even too horrible when the number of actions was greater but what was being acted on was small. Unfortunately, it sucked major, big-time when the objects were large (aggragate size greater than available RAM) and got worse when each thread finally tried to start updating the database. At that point, the system became completely unusable until it sort of caught up but, even then, any queries to the database still gave a bogus result because updates to the database were still I/O bound and going on in the background.
We ended up serializing multiple user action requests of the type that caused the problem. Turns out that the serial solution actually was *faster* in all but a few trivial situations (e.g., multiple threads were only faster when there were only a few, small requested actions) since we also didn't start swapping, there were fewer context switches, etc. and the actual bottleneck was I/O. Yet another case of throwing multiple threads at a problem without anayzing what the system actually has to do. Since this just went on over the past couple of weeks at work, it was the type of example I was thinking of in my original post.
(Note: I try not to over qualify my postings to the point where all my qualifications only serve to confuse the point I'm trying to make. That usually means there are some excpetions to what I have to say. See somebody else's comeback later in the responses with what they construe as another exception.)
I have to agree. I run into quite a few people looking for programming jobs who don't understand what the CPU has to do to execute their code. They do dumb things like multithread something that is CPU bound becuase they have no understanding of how what they write actually gets executed. Same thing with regard to data representation mistakes.
I'm not saying that everyone has to become a proficient assembly level programmer but I think a lot of people would be a lot better HOL programmers if they understood something about assembly language. I wonder how many Windows buffer overflow exploits are simply the result of someone not understanding that just because you can't express it in a HOL doesn't mean you can't exploit it from assembly code.
The problem Grokline sets out to address is that Eric Levenez's original Unix timeline didn't quantify or qualify exactly what sort of "contribution" an existing product made to a newer product. As an example, it might show that Linux was somehow descended from Minix in spite of Andy Tanenbaum's recent disclaimer. Another way of looking at the problem is that the original timeline didn't really differentiate between an actual inclusion of code vs. inspiration and a platform to work on.
Hopefully, Grokline will help sort this out for at least the open source world and the people like Ken Brown at AdTI will have to find a different dumpster to go diving in to find dirt on FOSS and FOSS contributors. Alternatively, he could seek employment at the National Enquirer since his idea of research seems to be more at home in a supermarket tabloid.
PJ & Co. at Groklaw are faced with an easier problem and the best solution thay have is to OCR what they can and then have individual volunteers fix the stuff that the OCR process misses. I say they have an easier problem because they are getting "published" court documents that have been scanned in as graphics. For that matter, you could also technically do what the court is doing and simply scan the notes as graphics and publish them that way as PDFs. That is, don't even try to convert them to text.
In this day and age, almost any source of information (including/.) is out to make a buck. This means that the source will provide the "news" that will generate the most revenue. Everyone has an axe to grind so the trick is to either read opposing points of view (if you have the time) or at least be cognisant of the biases of the source you're reading.
Who inherits the title of litiguous bastards once IBM, Novell, Red Hat, Autozone, Daimler-Chryslers, et al finish flushing the current holder of the title down the crapper.
Since Novell bought SuSe they are now a Linux distributor and bound by the terms of the GPL. If Novell owns the Unix copyrights (looks like they do from what I read on Groklaw), we're all VERY safe from them attempting to pull an SCO.
Personally, I'd worry more about "submarine" software patents that someone will suddenly complain are being infringed ala PanIP, RAMBUS, et al. You will note how easily IBM was able to find four patents for their counter-suit against SCO.
He keeps referring to Linux as free as in beer and has no concept, according to the article, of the other aspects of Open Source.
Because MS can only compete against the "free as in beer" aspect of Linux. That's why you see all of the MS sposored studies that purport to show that Windows is cheaper than Linux. It keeps the argument focussed on the one aspect of the debate where MS can use they marekting war-chest to create the illusion that they are competitive.
The last thing MS wants to acknowledge is that the free as in speech aspect of open source is even an issue. They have no way to compete there because their business model is all about locking people into a closed source solution and then continuing to extort money from them for upgrades. Thus, they try to keep the debate focussed strictly on visible costs and only visible costs.
As IBM has countered the various claims made by SCO, the case has become more dependent on the outcome of SCO v. Novell (e.g., Novell overriding SCO's attempt to pull IBM's license to distrbute AIX). The next thing that happens is IBM asks for a stay pending the outcome of Novell v. SCO and Novell shows that SCO doesn't actually own the base Unix copyrights. This leaves the only IP that SCO actually owns as the copyright to their pitifully small contributions that they made to "Unixware". They also are copyright holder to their contributions to Linux but, oh my, those were released under the GPL and so can't be "monetized."
You will note that this outcome does nothing to prevent IBM or Red Hat from continuing to pursue their claims against SCO. Novell ends up with clear title to the "Unix IP" and IBM and Red Hat get to carve up the carcass of SCO for the damages inflicted by Darl and Co. I'm guessing that Novell will ask for SCO to pay their legal fees before IBM and Red Hat chew up what's left.
It's time for a new section. It's time for an SCO section, ala Games or YRO. A section devoted entirely to SCO stories, because I (and I imagine a lot of other people) simply
do not care about them anymore.
So why do you bother reading them and posting comments?
BTW, if you go to the user preferences section and click on the "Homepage" tab you will note a rather large table that lets you exclude stories based on topic as well as other criteria. Check the box next to Caldera. That's the "old" name for the bunch of litiguous bastards known as The SCO Group. You can then stick your head back in the sand and stories about SCO will no longer interupt your reading of slashdot. Unless that is, due to a preponderence of apathy and ignorance, SCO happens to win in which case slashdot and a lot of the net as we know it will cease to exist. But don't worry. Some of us who do care will try to stay informed and keep that from happening.
Oh, and quit whining and try to figure stuff out for yourself sometime.
Most of us who read Groklaw filter postings from Anonymous Cowards so we don't get as many "noise" postings. Its amazing how much better the quality of the posted comments are once you filter this drivel.
Oh, sorry.
BTW, the setting is under the preferences link on the left side of the page once you log in. Its right under their award for "Best News Site" from OSDir so its easy to find. But of course, if you don't log in, you would never see it.
I get it. The people like Bernie Ebbers (MCI), Ken Lay (Enron) and Dennis Kozlowski (Tyco) didn't really hurt anyone when they enriched themselves while bankrupting their companies since these were strictly "white collar" crimes.
There are thousands of people who lost a significant portion of their life savings to these swindles. As a guess they were the, "...just the average tax-payers - you know - the ones the Law Enforcement Officers swore to serve, protect, and defend" but since none of the perps used a gun it doesn't matter.
I also think the author of the article doesn't understand how open source projects get started and evolve. My impression is that most start from the individual "scratch an itch" program and then grow and evolve from there. This is, I need a program to do X so I write a command-line program to do X. I know where (newsgroup, whatever) other people are who might be interested in X hang out so I post about my program there. If enough people are interested, it becomes a real open source project and someone says, "Gee, it would be nice if it had a GUI."
The prevalence of command line programs is not some deep dark conspiracy to retain the command line but, if you just need something for yourself, who is going to engineer a complete GUI? That only comes after you figure out how to do X (unless you also want to learn about crafting a GUI). The main difference is that in the commercial world someone says, "We need a *product* that does X," so the ease of use and human engineering are part of the *product* development because they know they have to make it easy to use in order to *sell* the program. You will note that this misunderstanding of motivation also comes through in the original article's problems 3 and 4.
2) Documentation
Most general purpose software documentation sucks regardless of whether its from a FOSS project or a commercial vendor. The last hardcopy documentation I saw for Microsoft Office was simply the on-line help printed and bound. You don't see anything like the quality documentation that used to come with some of the old DOS programs (e.g., WordPerfect, Lotus 1-2-3, dBase, etc.). Part of this was that the people writing that documentaion had to assume that the user didn't have the faintest idea of what a computer was or what their program did.
3) Feature-centric development
I don't see this as being restricted to FOSS projects. About the only difference is that with commercial software, the feature-centric development just means the features come from marketing instead of the developers/users. I actually see *less* of this in FOSS than I do in commercially developed software. Commercial software producers have a huge monetary incentive to keep their customers on the upgrade treadmill to maintain their cash-flow. I see more of a recognition in FOSS that a program can be relatively complete.
4) Programming for the self
This one I have to agree with although I see hope in companies like IBM and Novell getting involved in FOSS. I see them as having the resources and incentive to do real human interface engineering.
5) Religious blindness
I don't see this as a problem either. I think this is one place where the author needed to provide some specific examples instead of just making general accusations. I do see a very valid position taken by the FOSS development community to respect open standards and rejection of proprietary protocols and formats. If this is the "religious blindness" she's talking about then so be it.
Just to point out that Hot Hot Hot is a fine puveyor of some of the best (read as really, really hot) hot sauces known to mankind. Other than it would be a waste of good hot sauce, the principals at PanIP should have a liberal dose of something like Rior Mortis applied to a variety of sensetive body parts so that they remember that there was prior art.
I have argued the same point but offer some more specific reasons.
1) If you assume that, without Microsoft, there would be multiple competing OSes (e.g., the multitude of Unix variants in the 1980s) then just having FOSS to provide a choice wouldn't be needed. For all intents and purposes, the only alternative to Microsoft on i386 hardware is FOSS. This leads to:
2) The FOSS movement is getting support from various companies (e.g., IBM, Novell) since FOSS is the only way they can compete against Microsoft's lock-in with hardware vendors through marketing agreements. If you dig into the record of the Microsoft anti-trust case you'll find that Microsoft even had enough leverage to pressure IBM into not offering alternatives to Microsoft products (e.g., OS/2) on IBM made PCs by threatening to no longer provide IBM a price break since they weren't giving Microsoft an exclusive.
3) Kind of fall-out from item 1, above, but if you had competition in OS and applications, you wouldn't have Microsoft's monopolist pricing on buggy bloatware. Choice means the freedom to choose between different products basd on their merits. Generally, in a competitive market this means that price goes down while quality goes up.
I'm not saying that FOSS wouldn't exist without Microsoft but it would be one player among many instead of being the only alternative.
See my original comment. In partuicular, where I said, "Some of this may be security through obscurity". All I can say is that the people we talk to are convinced that Netware is more secure than Windows.
I work for a comapny that makes a network monitoring product so my sample may be skewed. Regardless, a lot of people would probably be surprised how many networks still use Novell to handle their network logins, file sharing, etc. becuase its more secure than Windows. Some of this may be security through obscurity but the answer we consistently get when we ask people why they still run Netware is that its more secure.
How about: "Open Source development methods create higher quality software."
My contention is that it isn't just the peer review process but also the notion that its not right until its right. This is my rant from a couple days ago regarding why so much software stinks. Open source projects don't have some marketing weenies demanding that the next version be released by some arbitrary date so there's time for both peer review and adequate testing.
Slashdot Mirror
I'm guessing that AOL will go for something like grand theft. The list was re-sold for $52,000. No telling how much the guy he originally gave it to paid him. I'm sure the value of the list to AOL's business is much higher but this sets a lower bound that easily puts the theft into the range where grand theft would stick. From this perspective, what he did was no different than carting out a server or some other piece of equipment and fencing it for $52,000.
Personally, I think the dweeb should be staked out on an ant-hill or drawn and quartered but I've been accused of being a little extreme when it comes to spam, spammers and people who disclose e-mail addresses without the owners's permission.
Interesting question. There is a word for conveying a paid, commercial message: advertising.
I wonder what would happen if complaints against these supposed "think tanks" were filed with the IRS (advertising is *not* something for a not-for-profit organization to engage in; its a business activity) and the FTC (deceptive advertising). It may not be possible to nail them for their current activities but the tobacco industry disclosures are apparently a matter of public record and indicate a direct linkage between "contributions" and "study results".
I've worked for quite a few different people over the last 20+ years. Based on how their career went, some were good at management; some were not. One reason I got out of a management career track was I realized that the perception of how well these folks were doing was more important than to their career than their actual results. I found that I could get along with most people as long as they perceived me as contributing to their success.
The one thing I absolutely could not and still cannot stand in a manager is if they try to tell me how to do my job. I expect my manager to give me tasks to do and its up to me to figure out how to perform them. I don't expect them to set up my daily calendar. Unfortunately, some people want to manage at too low a level. This has applied as much to some of the managers I otherwise got along with as to some that I thought were absolute jerks. Be wary of any candidate you talk to who is too much into the details of how you do what you caurrentyly do. You don't want someone critiquing you on your mouse click technique.
I'm glad I'm not the only one who thought that. Mr. Willis needs to also experience working in a large programming environment (e.g., 100+ developers working on something over several years). Many of the lessons from "The Mythical Man-Month" only become apparent when the size of the project is such that no one person can understand the whole in complete detail. An architech or cheif engineer may understand the overall concept but will not understand every gory detail at the lower-most levels.
Likewise, his lack of any understanding of how the cost of correcting an error grows exponentially with how late in the development cycle the error is discovered speaks volumes about his lack of experience in commercial software (e.g., what if the bug requires the documentation to be re-printed? how about if it requires a product recall and/or advertising campaign to mitigate the harm to the reputation of the company doing the development?). That Microsoft follows the model of charging people for a new version of their bloatware that fixes the bugs in the previous version (while introducing more bugs at the same time) may be a good business model but it is hardly a contribution to the science of developing software.
Too bad no editor at O'Reilley had enough sense to tell him to try again. On the plus side, maybe this will get a few more people to read TMMM before they transform into PHBs. Maybe Ed should apply for a position as a writer at the Alexis de Tocqueville Institute. I understand that they don't require that the people who write for them have any knowledge about what they're writing about.
The example is literally working with up to ~100GB "archives" of "event data" to be restored from a remote file server. The system doing the work is either an 4 CPU Dell 6650 with 8GB of RAM or a 2 CPU Dell 1750 with 2GB of RAM. Files in the archives consist of metadata identifying the file contents and the application data. Restoring an archive means the metadata gets stuffed into a postgres database with the application data remaining accessible through the file system. An "archive" such as this can consist of up to 1.7 million event files. The implementation language is Java as Java Server Pages (JSP) on a Red Hat Enterprise Linux 3 platform. The 6650 has a RAID 5 array to help provide better I/O throughput.
The developers tend to test with (and think in terms of) small archives of several hundred event files and an archive size on the order of tens of megabytes. Multi-threading a few of these *appears* to work well and even doing a bunch doesn't seem to do much harm due to their size. Even at a point in between these extremes (e.g., 10 GB archive of a few hundred thousand event files), all it takes is firing off a couple of actions concurrently and the system is as good as dead. Running top on the system will reveal almost no user CPU cycles but everything solidly in I/O wait. At least the developers didn't try to mmap the archive.
The real problem is the massive, monolithic archive which really isn't required since the end users access the event data through the metadata in the database. It would be fairly easy to also do a little more "book-keeping" and spread the events through several smaller archives. Unfortunately, the same developers seem to have trouble grasping this and want to cling to the single archive file design. The trick *isn't* to find a way of doing what we're currently trying to do but, instead, find an easier way to provide the user with the data they're interested in (e.g., try the door handle before you attempt to break down the door).
S I G H
Your example struck a nerve because I just went through having to show a developer how his design failed because he launched a separate thread for each action the user requested. His solution worked great when the number of requested actions was less than the number of CPUs (4 in this case: 2 physical and 2 HT). It wasn't even too horrible when the number of actions was greater but what was being acted on was small. Unfortunately, it sucked major, big-time when the objects were large (aggragate size greater than available RAM) and got worse when each thread finally tried to start updating the database. At that point, the system became completely unusable until it sort of caught up but, even then, any queries to the database still gave a bogus result because updates to the database were still I/O bound and going on in the background.
We ended up serializing multiple user action requests of the type that caused the problem. Turns out that the serial solution actually was *faster* in all but a few trivial situations (e.g., multiple threads were only faster when there were only a few, small requested actions) since we also didn't start swapping, there were fewer context switches, etc. and the actual bottleneck was I/O. Yet another case of throwing multiple threads at a problem without anayzing what the system actually has to do. Since this just went on over the past couple of weeks at work, it was the type of example I was thinking of in my original post.
(Note: I try not to over qualify my postings to the point where all my qualifications only serve to confuse the point I'm trying to make. That usually means there are some excpetions to what I have to say. See somebody else's comeback later in the responses with what they construe as another exception.)
I have to agree. I run into quite a few people looking for programming jobs who don't understand what the CPU has to do to execute their code. They do dumb things like multithread something that is CPU bound becuase they have no understanding of how what they write actually gets executed. Same thing with regard to data representation mistakes.
I'm not saying that everyone has to become a proficient assembly level programmer but I think a lot of people would be a lot better HOL programmers if they understood something about assembly language. I wonder how many Windows buffer overflow exploits are simply the result of someone not understanding that just because you can't express it in a HOL doesn't mean you can't exploit it from assembly code.
The problem Grokline sets out to address is that Eric Levenez's original Unix timeline didn't quantify or qualify exactly what sort of "contribution" an existing product made to a newer product. As an example, it might show that Linux was somehow descended from Minix in spite of Andy Tanenbaum's recent disclaimer. Another way of looking at the problem is that the original timeline didn't really differentiate between an actual inclusion of code vs. inspiration and a platform to work on.
Hopefully, Grokline will help sort this out for at least the open source world and the people like Ken Brown at AdTI will have to find a different dumpster to go diving in to find dirt on FOSS and FOSS contributors. Alternatively, he could seek employment at the National Enquirer since his idea of research seems to be more at home in a supermarket tabloid.
PJ & Co. at Groklaw are faced with an easier problem and the best solution thay have is to OCR what they can and then have individual volunteers fix the stuff that the OCR process misses. I say they have an easier problem because they are getting "published" court documents that have been scanned in as graphics. For that matter, you could also technically do what the court is doing and simply scan the notes as graphics and publish them that way as PDFs. That is, don't even try to convert them to text.
In this day and age, almost any source of information (including /.) is out to make a buck. This means that the source will provide the "news" that will generate the most revenue. Everyone has an axe to grind so the trick is to either read opposing points of view (if you have the time) or at least be cognisant of the biases of the source you're reading.
Who inherits the title of litiguous bastards once IBM, Novell, Red Hat, Autozone, Daimler-Chryslers, et al finish flushing the current holder of the title down the crapper.
Since Novell bought SuSe they are now a Linux distributor and bound by the terms of the GPL. If Novell owns the Unix copyrights (looks like they do from what I read on Groklaw), we're all VERY safe from them attempting to pull an SCO.
Personally, I'd worry more about "submarine" software patents that someone will suddenly complain are being infringed ala PanIP, RAMBUS, et al. You will note how easily IBM was able to find four patents for their counter-suit against SCO.
(You can go back to worrying now)
The last thing MS wants to acknowledge is that the free as in speech aspect of open source is even an issue. They have no way to compete there because their business model is all about locking people into a closed source solution and then continuing to extort money from them for upgrades. Thus, they try to keep the debate focussed strictly on visible costs and only visible costs.
As IBM has countered the various claims made by SCO, the case has become more dependent on the outcome of SCO v. Novell (e.g., Novell overriding SCO's attempt to pull IBM's license to distrbute AIX). The next thing that happens is IBM asks for a stay pending the outcome of Novell v. SCO and Novell shows that SCO doesn't actually own the base Unix copyrights. This leaves the only IP that SCO actually owns as the copyright to their pitifully small contributions that they made to "Unixware". They also are copyright holder to their contributions to Linux but, oh my, those were released under the GPL and so can't be "monetized."
You will note that this outcome does nothing to prevent IBM or Red Hat from continuing to pursue their claims against SCO. Novell ends up with clear title to the "Unix IP" and IBM and Red Hat get to carve up the carcass of SCO for the damages inflicted by Darl and Co. I'm guessing that Novell will ask for SCO to pay their legal fees before IBM and Red Hat chew up what's left.
BTW, if you go to the user preferences section and click on the "Homepage" tab you will note a rather large table that lets you exclude stories based on topic as well as other criteria. Check the box next to Caldera. That's the "old" name for the bunch of litiguous bastards known as The SCO Group. You can then stick your head back in the sand and stories about SCO will no longer interupt your reading of slashdot. Unless that is, due to a preponderence of apathy and ignorance, SCO happens to win in which case slashdot and a lot of the net as we know it will cease to exist. But don't worry. Some of us who do care will try to stay informed and keep that from happening.
Oh, and quit whining and try to figure stuff out for yourself sometime.
Most of us who read Groklaw filter postings from Anonymous Cowards so we don't get as many "noise" postings. Its amazing how much better the quality of the posted comments are once you filter this drivel.
Oh, sorry.
BTW, the setting is under the preferences link on the left side of the page once you log in. Its right under their award for "Best News Site" from OSDir so its easy to find. But of course, if you don't log in, you would never see it.
I get it. The people like Bernie Ebbers (MCI), Ken Lay (Enron) and Dennis Kozlowski (Tyco) didn't really hurt anyone when they enriched themselves while bankrupting their companies since these were strictly "white collar" crimes.
There are thousands of people who lost a significant portion of their life savings to these swindles. As a guess they were the, "...just the average tax-payers - you know - the ones the Law Enforcement Officers swore to serve, protect, and defend" but since none of the perps used a gun it doesn't matter.
1) User interface design
I also think the author of the article doesn't understand how open source projects get started and evolve. My impression is that most start from the individual "scratch an itch" program and then grow and evolve from there. This is, I need a program to do X so I write a command-line program to do X. I know where (newsgroup, whatever) other people are who might be interested in X hang out so I post about my program there. If enough people are interested, it becomes a real open source project and someone says, "Gee, it would be nice if it had a GUI."
The prevalence of command line programs is not some deep dark conspiracy to retain the command line but, if you just need something for yourself, who is going to engineer a complete GUI? That only comes after you figure out how to do X (unless you also want to learn about crafting a GUI). The main difference is that in the commercial world someone says, "We need a *product* that does X," so the ease of use and human engineering are part of the *product* development because they know they have to make it easy to use in order to *sell* the program. You will note that this misunderstanding of motivation also comes through in the original article's problems 3 and 4.
2) Documentation
Most general purpose software documentation sucks regardless of whether its from a FOSS project or a commercial vendor. The last hardcopy documentation I saw for Microsoft Office was simply the on-line help printed and bound. You don't see anything like the quality documentation that used to come with some of the old DOS programs (e.g., WordPerfect, Lotus 1-2-3, dBase, etc.). Part of this was that the people writing that documentaion had to assume that the user didn't have the faintest idea of what a computer was or what their program did.
3) Feature-centric development
I don't see this as being restricted to FOSS projects. About the only difference is that with commercial software, the feature-centric development just means the features come from marketing instead of the developers/users. I actually see *less* of this in FOSS than I do in commercially developed software. Commercial software producers have a huge monetary incentive to keep their customers on the upgrade treadmill to maintain their cash-flow. I see more of a recognition in FOSS that a program can be relatively complete.
4) Programming for the self
This one I have to agree with although I see hope in companies like IBM and Novell getting involved in FOSS. I see them as having the resources and incentive to do real human interface engineering.
5) Religious blindness
I don't see this as a problem either. I think this is one place where the author needed to provide some specific examples instead of just making general accusations. I do see a very valid position taken by the FOSS development community to respect open standards and rejection of proprietary protocols and formats. If this is the "religious blindness" she's talking about then so be it.
Hmmm. Heavy breathing using morse code. Tricky but *so* kinky.
Just to point out that Hot Hot Hot is a fine puveyor of some of the best (read as really, really hot ) hot sauces known to mankind. Other than it would be a waste of good hot sauce, the principals at PanIP should have a liberal dose of something like Rior Mortis applied to a variety of sensetive body parts so that they remember that there was prior art.
1) Buy some land near Chernobyl (should be cheap).
...
2) Start a Giant Mutant Boneless Chickens Ranch.
3) Breed them to be self cooking.
Profit!
I have argued the same point but offer some more specific reasons.
1) If you assume that, without Microsoft, there would be multiple competing OSes (e.g., the multitude of Unix variants in the 1980s) then just having FOSS to provide a choice wouldn't be needed. For all intents and purposes, the only alternative to Microsoft on i386 hardware is FOSS. This leads to:
2) The FOSS movement is getting support from various companies (e.g., IBM, Novell) since FOSS is the only way they can compete against Microsoft's lock-in with hardware vendors through marketing agreements. If you dig into the record of the Microsoft anti-trust case you'll find that Microsoft even had enough leverage to pressure IBM into not offering alternatives to Microsoft products (e.g., OS/2) on IBM made PCs by threatening to no longer provide IBM a price break since they weren't giving Microsoft an exclusive.
3) Kind of fall-out from item 1, above, but if you had competition in OS and applications, you wouldn't have Microsoft's monopolist pricing on buggy bloatware. Choice means the freedom to choose between different products basd on their merits. Generally, in a competitive market this means that price goes down while quality goes up.
I'm not saying that FOSS wouldn't exist without Microsoft but it would be one player among many instead of being the only alternative.
See my original comment. In partuicular, where I said, "Some of this may be security through obscurity". All I can say is that the people we talk to are convinced that Netware is more secure than Windows.
... The ones who care about security.
I work for a comapny that makes a network monitoring product so my sample may be skewed. Regardless, a lot of people would probably be surprised how many networks still use Novell to handle their network logins, file sharing, etc. becuase its more secure than Windows. Some of this may be security through obscurity but the answer we consistently get when we ask people why they still run Netware is that its more secure.
My contention is that it isn't just the peer review process but also the notion that its not right until its right. This is my rant from a couple days ago regarding why so much software stinks. Open source projects don't have some marketing weenies demanding that the next version be released by some arbitrary date so there's time for both peer review and adequate testing.