Sorry to be late with this reply, but the SCCS bug I mentioned was not an "output only bug". It totally refused to check in files, claiming that the so-called s-file was corrupt.
The other one I mentioned also was "fatal": it was (is, actually, because to my knowledge it has not yet been fixed) a project database that would say "internal database error" when one tried to enter a project with an end date in 2000.
I hate to rain on your show, but I have had some first hand experiences with software written in C that did contain The Bug. There is more badly written software out there than even many people in the IT industry can imagine.
Some of it was written not more than 1 year ago (yes: 1 year, I too needed to sit down when I ran into that baby). Some of it dates back to the AT&T UNIX days, is present in all major UNIX vendors' distributions, and yet still turned out to be buggy. Don't believe it? Ask (for instance) HP about the Y2K-1 bug in unpatched SCCS versions that hit on January 1, 1999 at 00:00:00 (while I was watching it, no less).
This is irrelevent, because 1) that's not what it's about; and 2) if the US government makes exceptions for big corporations, so could the Dutch. Not that I think they should...
The most blatent evidence of his bias was the quote, "Linux is as secure as you can make a computer."
It's sad, but I have to agree with that. I liked most of the article and don't mind the Alan Cox quote even though I can see why others would, but the above quote diminishes its value a lot as far as I'm concered.
What's bothering me is that the "insightful" label is being overused a lot. As if people have forgotten that, in order to be insightful, a comment should actually present an insight (e.g. a "new" or "unusually different" way to look at things, etc.). Before long being insightful won't mean anything anymore other than "this post was not deemed flamebait".:-(
This is not to say that I feel that posts are all the time being moderated up without a reason, but when meta-moderating. I quite often feel that using the "interesting" label would have been more appropriate.
Hmmm, my other activity got postponed, so I seem to have time to answer this more in-depth...
There are many elaborate and/or fancy ways to describe how open source works, but in the end they all come doen to this: survival of the fittest.
However, the important thing is to understand what it means to be fit or unfit. Being (un)fit is something one (or something) does for a certain purpose and within a certain context. Part of being fit for survival as an open source programmer is to recognise when a certain area of interest has already been occupied by projects that are fit and established enough so that fighting them is likely to be a loosing battle.
Note: While M$ Windows is very well established, it is in general not sufficiently fit. If not from technical point of view, then at least from the point of view of matching what people in certain "markets" want from a psychological point of view. That's why it makes sense for open source projects to enter the PC operating system arena. But this is an evaluation that must be made over and over again for each new (open source or other) project, and it is not always so that the new project will win, even if it is "better" at something (for some definition of better). Certainly not if the all established projects in the given arena already are open as well, as is the case with the example in my first post in this thread.
By the way: an other frequently misunderstood but crucial aspect of survival of the fittest is that it are not always the fittest who survive. The fittest survive on average.
Grrr. I wanted to also express that this IPO letter business as such isn't all that important to me, and so I added the "(un)" bit. Unfortunately, it escaped me until after I submitted the post that this makes the sentence ambiguous. So for clarity: I did recieve the letter (and it won't have been for advocacy).
PS: No need to go on flaming. I'm off to other activities now, and by the time I'll get back this whole thread will be history.
I'm sorry, but I don't think so. I've been at it longer than many others around here, and was recently deemed (un)worthy to get the VALinux IPO letter, so there seem to be others out there who know that.
I have no intention to flame any particular existing project, and thus will not get flamed back for doing so.
Notice that I was speaking in general terms, and did not at any point express an evaluation of the usefullness of the FreeMWare effort. Hence, feel free to moderate my origonal post down for being off-topic if you want, but at least read and understand what it says first. Now you can flame me.
Besides if these people want to code this software then let them
Far from me to disagree with that but, on the other hand, think how many really new things we could be doing if we wouldn't be reinventing every single commercial wheel out there.
Or even some non-commercial wheels: I've seen somebody from Debian suggest that they should make a free implementation of a 2000-line program I once wrote and put on the net for free (back when the net was still a small and cosy place and the GPL had just only been born). Why? Simply because, for reasons beyond my control, I had to disallow "commercial use". Fortunately I found out (by accident) and was able to convince them that they were being worried about nothing worthwhile and should spend their time doing more useful things. Especially since there already is an in part similar GPL-ed program out there as well (by none less that Jamie Zawinsky, himself even).
I clearly meant readers. In the context of the original discussion, it's not all that important how many people are posting to Slashdot, but what percentage of those who learn about something through Slashdot may be sending "angygrams", no matter whether they post or not.
And I know it's hard (or rather impossible) to do, but I also know that at least soms counting is being done, since there are lists of the most frequently accessed stories. Maybe if one has access to all the data that Rob has, it would be possible to make a (very) rough estimation of the number of readers. Accuracy is not all that important, anyway. What counts is to get a feeling for the order of magnitude.
Maybe Rob should somehow make it more clear to the world how many Slashdot readers there are for any given story. Approximately, that is, because of ACs and being harder to count "correctly" and all that, but still...
I have not yet had the time to read the stuff, but I got it while I live in Belgium. So either that list is not exclusive, or they did a bad job at filtering the e-mail addresses.
I must say I agree. Some people over here are seriously overreacting whenever Micro$oft is involved.
Most likely, It's just another bug. Buggy patches (a.k.a. service packs in the realm of the Big Bad Company) happen al the time. In fact, only last week or so, over here at teh place where I work, we learned that one of the big UNIX vendors had to recall a couple of libc patches. At least one of their past libc patches happened to break important ECAD tools such as Synopsys. Now, does this mean that this UNIX vendor is trying to kill Synopsys DC and BC? Could it be that this UNIX vendor is secretly preparing its own entry into the ECAD market? I don't think so...
By the way: before flaming me for teh above, read my signature. I'm far from a pro-M$ person, but that's no reason to label everything they do as being done with bad intentions.
Another thingie. With one central server, the companys work is much more vulnerable - if an evilminded cracker breaks system integrity. Don't think "backups!!".
Please do think "backups", but from a different perspective. Just think about what can go wrong if you have to backup several tens or hundreds of PCs every night! There simply are too many potential problems, and as an admin, if you rely on such a system, you simply cannot guarantee anything about your backups.
For years now, central data storage has been a standard in any shop that takes its IT support seriously, independent of the NC drive
Your description of the Ariane 5 problem isn't exactly accurate. For more information about what happened, check out the ARIANE 5 Flight 501 failure report, which is the official report about the accident. It is, however, correct that it was (amongst other things) a case of poor testing.
Home users with... one computer (and no interest to keep their private e-mail stored on an ISP's server).
Also, victims of sysadmins that switch off support for NFS-mounted mailboxes (hey, this really old technology already was multi-computer!) but that have no desire to switch to another MUA.
While I agree with the idea behind your statement, I'd like to point out that ESR did not attempt to show that lines of code are related to number of subscribers. He plotted lines of code versus time and number of subscribers versus time. The fact that these plots are presented in one and the same graph does not imply that the author is trying to show a relationship between the vertical axis.
A more suitable graph would indicate number of contributors rather than constituents of the mailing lists.
This is very true. I myself have been on the fetchmail mailing lists for a long time and while in the beginning I actually sent some stuff to the list (Note: I do not claim to have contributed, by the way. Not to fetchmail at least.), it's been a long time since I last had a need to do that.
So if ever I had been a developer, I would certainly at some point have stopped being one, even though I'm still on the list. For quite a while now, my fetchmail related needs would just as well be covered by merely being on the annoucement list. And even that is not really needed, given the availability of Freshmeat & Co.
So not only should one expect to see the number of contributors level off after a while, it can even be natural for it to shrink. This is so even for a successful project that is still very much alive.
Someone with a lot of time on his or her hands (or even better: who gets payed for doing it) should try making similar graphs for the Linux kernel and Mozilla. That would yield a few interesting comparisons.
The obvious problem is that it would be a bit hard to do (and even a bit harder to "prove correct"), but still... One thing one might consider is to look at all the Linux kernel or Mozilla releases and scan them for e-mail addresses and the like. Maybe only looking at the CREDITS files, maybe also scanning the source itself (e.g. to find driver co-authors that never made it into CREDITS and also those that are explicitly thanked by driver authors for contributing bug reports and fixes). Unfortunately, to make the results interesting, one would also be able to compare those numbers with those of the related "user" mailing lists and collecting that kind of data will be near impossible, I fear. In any case, one would have to be very careful in collecting and even more in interpreting, though.
It probably won't be done, but I would not at all be surprised to find developer curves very similar to the fetchmail one. The curves for the number of users may look very different, but my guess is that the developer one would not.
Very right. I use this kind of setup at work for developing E-CAD software for exactly those reasons. It works perfectly well, while costing a lot less in maintenance than a fat client setup.
Slashdot Mirror
The other one I mentioned also was "fatal": it was (is, actually, because to my knowledge it has not yet been fixed) a project database that would say "internal database error" when one tried to enter a project with an end date in 2000.
--
Some of it was written not more than 1 year ago (yes: 1 year, I too needed to sit down when I ran into that baby). Some of it dates back to the AT&T UNIX days, is present in all major UNIX vendors' distributions, and yet still turned out to be buggy. Don't believe it? Ask (for instance) HP about the Y2K-1 bug in unpatched SCCS versions that hit on January 1, 1999 at 00:00:00 (while I was watching it, no less).
--
--
This is irrelevent, because 1) that's not what it's about; and 2) if the US government makes exceptions for big corporations, so could the Dutch. Not that I think they should...
--
--
It's sad, but I have to agree with that. I liked most of the article and don't mind the Alan Cox quote even though I can see why others would, but the above quote diminishes its value a lot as far as I'm concered.
--
This is not to say that I feel that posts are all the time being moderated up without a reason, but when meta-moderating. I quite often feel that using the "interesting" label would have been more appropriate.
--
There are many elaborate and/or fancy ways to describe how open source works, but in the end they all come doen to this: survival of the fittest.
However, the important thing is to understand what it means to be fit or unfit. Being (un)fit is something one (or something) does for a certain purpose and within a certain context. Part of being fit for survival as an open source programmer is to recognise when a certain area of interest has already been occupied by projects that are fit and established enough so that fighting them is likely to be a loosing battle.
Note: While M$ Windows is very well established, it is in general not sufficiently fit. If not from technical point of view, then at least from the point of view of matching what people in certain "markets" want from a psychological point of view. That's why it makes sense for open source projects to enter the PC operating system arena. But this is an evaluation that must be made over and over again for each new (open source or other) project, and it is not always so that the new project will win, even if it is "better" at something (for some definition of better). Certainly not if the all established projects in the given arena already are open as well, as is the case with the example in my first post in this thread.
By the way: an other frequently misunderstood but crucial aspect of survival of the fittest is that it are not always the fittest who survive. The fittest survive on average.
--
PS: No need to go on flaming. I'm off to other activities now, and by the time I'll get back this whole thread will be history.
--
--
--
Notice that I was speaking in general terms, and did not at any point express an evaluation of the usefullness of the FreeMWare effort. Hence, feel free to moderate my origonal post down for being off-topic if you want, but at least read and understand what it says first. Now you can flame me.
--
Far from me to disagree with that but, on the other hand, think how many really new things we could be doing if we wouldn't be reinventing every single commercial wheel out there.
Or even some non-commercial wheels: I've seen somebody from Debian suggest that they should make a free implementation of a 2000-line program I once wrote and put on the net for free (back when the net was still a small and cosy place and the GPL had just only been born). Why? Simply because, for reasons beyond my control, I had to disallow "commercial use". Fortunately I found out (by accident) and was able to convince them that they were being worried about nothing worthwhile and should spend their time doing more useful things. Especially since there already is an in part similar GPL-ed program out there as well (by none less that Jamie Zawinsky, himself even).
--
I clearly meant readers. In the context of the original discussion, it's not all that important how many people are posting to Slashdot, but what percentage of those who learn about something through Slashdot may be sending "angygrams", no matter whether they post or not.
And I know it's hard (or rather impossible) to do, but I also know that at least soms counting is being done, since there are lists of the most frequently accessed stories. Maybe if one has access to all the data that Rob has, it would be possible to make a (very) rough estimation of the number of readers. Accuracy is not all that important, anyway. What counts is to get a feeling for the order of magnitude.
Anyway, it's just a thought.
--
Just a thought.
--
--
Most likely, It's just another bug. Buggy patches (a.k.a. service packs in the realm of the Big Bad Company) happen al the time. In fact, only last week or so, over here at teh place where I work, we learned that one of the big UNIX vendors had to recall a couple of libc patches. At least one of their past libc patches happened to break important ECAD tools such as Synopsys. Now, does this mean that this UNIX vendor is trying to kill Synopsys DC and BC? Could it be that this UNIX vendor is secretly preparing its own entry into the ECAD market? I don't think so...
By the way: before flaming me for teh above, read my signature. I'm far from a pro-M$ person, but that's no reason to label everything they do as being done with bad intentions.
--
Please do think "backups", but from a different perspective. Just think about what can go wrong if you have to backup several tens or hundreds of PCs every night! There simply are too many potential problems, and as an admin, if you rely on such a system, you simply cannot guarantee anything about your backups.
For years now, central data storage has been a standard in any shop that takes its IT support seriously, independent of the NC drive
--
--
Home users with... one computer (and no interest to keep their private e-mail stored on an ISP's server).
Also, victims of sysadmins that switch off support for NFS-mounted mailboxes (hey, this really old technology already was multi-computer!) but that have no desire to switch to another MUA.
--
--
This is very true. I myself have been on the fetchmail mailing lists for a long time and while in the beginning I actually sent some stuff to the list (Note: I do not claim to have contributed, by the way. Not to fetchmail at least.), it's been a long time since I last had a need to do that.
So if ever I had been a developer, I would certainly at some point have stopped being one, even though I'm still on the list. For quite a while now, my fetchmail related needs would just as well be covered by merely being on the annoucement list. And even that is not really needed, given the availability of Freshmeat & Co.
So not only should one expect to see the number of contributors level off after a while, it can even be natural for it to shrink. This is so even for a successful project that is still very much alive.
--
The obvious problem is that it would be a bit hard to do (and even a bit harder to "prove correct"), but still... One thing one might consider is to look at all the Linux kernel or Mozilla releases and scan them for e-mail addresses and the like. Maybe only looking at the CREDITS files, maybe also scanning the source itself (e.g. to find driver co-authors that never made it into CREDITS and also those that are explicitly thanked by driver authors for contributing bug reports and fixes). Unfortunately, to make the results interesting, one would also be able to compare those numbers with those of the related "user" mailing lists and collecting that kind of data will be near impossible, I fear. In any case, one would have to be very careful in collecting and even more in interpreting, though.
It probably won't be done, but I would not at all be surprised to find developer curves very similar to the fetchmail one. The curves for the number of users may look very different, but my guess is that the developer one would not.
--
--
Exactly. I couldn't have said it better. (I too have a Masters in computer science, by the way.)
I suspect that Linus Torvalds might have similar thoughts.
I would be surprised if he doesn't.
--