the latest (4.1) clearcase release has just started shipping for Linux with the filesystem (MVFS) component.
thank you thank you thank you thank you! Looks like I have something to do this weekend!
(And I'm sure I will have a great time trying to build a kernel that it likes, since I run Debian. Note to rational: you should create a system that allows a user to upload a kernel tarball and automatically compiles your modules against it. Unsupported, of course.)
I'm surprised there are so few supporters of Clearcase here. Yes, it has two primary disadvantages: it is big, expensive, slow, bulky, and administor-intensive (I'm only counting that as one:-) ); and the repository is binary and opaque, accessible only via Clearcase commands.
But it is so much more elegant than CVS if your use of version control is at all sophisticated! (Which, if your development effort is even medium size, I would argue it should be--this is stuff that pays off. But that is a separate discussion.)
For starters, there are some simple correctness issues. Clearcase tracks files across renames, which I gather CVS does not. Moreover, it versions directories, so if you look at an old view of the repository, you see the old names. This allows everything from corrections to badly chosen filenames, up to reorganization of the repository, without any fuss.
Clearcase also has a "findmerge" command with "common ancestor" support. This basically means, when it's time to merge, you always know exactly what you need to merge, with previous merges taken into account. I honestly don't know how you could live without this. (Note this is distinct the tool that actually performs merges, which is nothing special--I just use GNU diff3, myself.)
Second, clearcase has (to me) a killer feature, filesystem support. This means that that you get an ordinary-looking unix filesystem that automatically gives you the latest versions that you're interested in. Further, using an "extended" filename syntax, you can look at any version right from the filesystem. So if you want to see what's going on in the foo branch, you just vim code.c@@/main/foo/LATEST, or if you want to figure out which mainline versions use the fooble API, grep fooble code.c@@/main/*. This is addictive. NB: the filesystem support is not available in Linux:-(
Third, clearcase is very unix-friendly. While this is not a major difference with CVS, it is still worth pointing out (since many commercial products "don't get" unix). Most clearcase commands are close to their unix analogs (or in the same spirit, when there is no analog), and the documentation is in man pages. For me, this made learning clearcase easy, and adds a significant comfort factor.
To me, version control is not just about making sure I can work on my stuff without getting stepped on by anyone else. (CVS is fine for that.) It's also about expressing, understanding and managing the relationships between various versions and branches. This is a conceptually more difficult activity, and I frankly think many posters here don't see its value (it takes a while). But if you do, clearcase wins hands-down.
I admit that, while I have used CVS, I have only had day-to-day experience with clearcase (and Visual SourceSafe--bleh!), so I don't have a good sense of the "CVS routine". It perhaps includes some practices that mitigate the lacks I've cited. But, as long as someone else is taking care of the cost and administration and resources (under these circumstances, I have found clearcase reliable, if still a bit pokey), and I don't have to interoperate with outside developers who don't have clearcase, I would take clearcase in a second.
One last post for me: I do believe that a focus on freedom is best for GNOME, Evolution, and Helix. But that isn't the main point. The main point is that (IMO) we should respect Miguel's personal focus on freedom. If this focus inspires him, or keeps him sane, or just makes him happy, he should continue it. If this isn't compatible with your values, you can ignore him, or argue the point; but don't criticize him or propose to change the direction of his project.
I also think everyone should consider hard why Miguel--who could probably code more functionality in a week than many of us could in a year--values freedom over functionality.
However, I think that a focus on how GNU-compliant the software is doesn't help anyone: let's work to make this the best mail client available anywhere, period!
The most generous interpretation of the above is that freedom should be clearly secondary to functionality. A less generous interpretation is that freedom is not important at all.
"doesn't help anyone"--those are pretty strong words.
instead of trying to make the best free mail client... the goal should be the best mail client period
Your approach works great in an imaginary world with no trade-offs. Do you think Miguel ever says, "No, let's leave out that functionality. We don't need it, because we're Free!"? Of course not! But he does know that, to be successful in the long-run, GNOME and Evolution need to have the support of the hacker community. That means doing some things that you wouldn't do if you were a typical proprietary vendor aiming at Joe User:
convenient source distribution
smooth build process
portability
merging contributed patches
establishing, maintaining, and participating in community fora
building features that will attract developers, including features from the software that developers currently use
including "hackability" features like ultra-configurability and an extension framework
using (and enhancing) standard free libraries and components
modularizing your code, so that other developers can use parts of it
releasing early and often (with sufficient documentation for others to get started)
addressing licensing concerns
Not every effort does all of these things in the same way; but no matter how you do it, there is a lot of overhead that goes into a good free software project. It's all worth it, in the end. But you don't get the benefits if freedom is an afterthought.
Take the sixth item in particular. It ties into your "best free mail client" jibe. In fact, creating the "best free mail client" is a pragmatic strategy, even if it means ignoring Outlook-ish features, because most free software developers use free mail clients. If you make the best free client, you get lots of enthusiastic developers interested, which gives you lots of momentum. So creating the "best free mail client" is a valid goal.
In short, a person, and especially a company, are limited in the number of things they can focus on. If Helix were focused primarily on functionality and usability, they would be less focused on freedom, and would have less support from the community, and would have a lower chance of success.
Let's do a little thinking on the difference between the Windows and Linux markets before we post, eh?
What non-free software has taken off on Linux that had even one half-as-good--or even just promising--free competitor? This is a major hurdle to overcome.
You really didn't include enough information, but I imagine there are possible recourses.
First, who has the copyright? I assume it is your employer, in which case of course they have no legal obligation to credit anyone. However, a few companies assign it to the FSF, and there may be other policies as well.
Second, is there a significant user community around the software? If so, you should be able to point out to them that your name was on earlier versions of the software, and that the company is being dishonest by hiding your contribution.
Third, is the software "Free Software" free? If so, it should be easy for you to demonstrate evidence of your authorship. There is also more likely to be a sympathetic community if the software is free.
Why don't you start your own company, in which you focus on functionality and ignore freedom? Good luck making it work as the support of the free software community vanishes!
(Hmm... why aren't we all using StarOffice or ApplixWare?)
if [Linus] doesn't want to be held responsible for his predictions, then all he needs to do is stop making them.
Linus's "predictions" are not announcements or press releases or marketing messages. They are his personal opinions, usually expressed on the development mailing list to other programmers (and occasionally in interviews to reporters). It's your fault if you take them for anything else (just like it's your fault if you expect him to make coding decisions based on anything other than what he finds pleasing).
In my observation, it has been a truism that when a class of devices is relatively new or niche in the Linux world, the support for one such device is significantly better than support for any other, because the user and developer community "gangs up" on that device. Eg, the Wavelan in wireless LAN and bttv-based boards in TV tuner/video capture (though by now, many devices in both classes are well-supported). This can be frustrating if that device isn't the one you want, but it's probably for the best, since development and testing resources are scarce.
I tell you this because I think (but am not sure) that PDA's are still in this category. Though there is probably some support for just about any PDA, I'd bet that you'll have much better luck with a Palm-compatible than anything else. I'm not knocking the programmers working on other PDA's, but for now, they're shorthanded. Unless you want to help improve the support for other PDA's, buying one is risky.
Disclaimer: I am not terribly familiar with Linux PDA support. I am speaking on general terms but from considerable experience.
ESR has been variously predicting the collapse of Microsoft's stock and their "collapse into irrelevance" since about 1998 (example). And "Windows 2000 will be either cancelled or dead on arrival." He blindly fails to recognize the qualities in Microsoft that allowed it to lead the PC revolution, and will keep it a dominant company for many years.
it sure seems like it would cut out the majority of the dirtbags involved in domain reselling.
Whatever merits your plan may have, it is exactly the sort of thing that would increase the number of dirtbags involved, because it would inevitable drive many domain transactions "underground" (you know, with the dirt).
The microkernel design seems to me to be fundamentally more secure.
Currently, very few vulnerabilities of mainstream (monolithic kernel) systems involve compromise of the kernel proper. I can't think of any off hand. Some involve DOS'ing the kernel (ping of death). Some involve tricking the kernel into sending bad data to someone else (eg, modprobe). I've heard of potential buffer overruns being fixed in Linux, but I've never heard of any being exploited. Perhaps it's because there are too many bugs to exploit above the kernel, or because it's too hard to develop and tests the exploits, or because kernel developers are just a careful breed; but making the kernel harder to take over doesn't seem to buy you much in practice.
Even if you are worried about such attacks, it's not at all clear that a microkernel wins. A great benefit of a monolithic kernel is that the entire development project is more unified. Developers are more likely to be familiar with the whole codebase, aware of interrelationships and finding bugs throughout. This is why Linus insists on keeping megs of random drivers in the kernel distribution. If the parts of a microkernel are developed in more isolation, there are fewer eyes on the whole thing, and more chance of miscommunication. For example, the Linux/modprobe bug mentioned above could just as well have happened between two services in a microkernel-based system.
compared to anything else on the server-side, Java is faster to develop
You have the misconception that scripting is not acceptible on the enterprise server. This is not true. Robust and performant application can be written in Python (or Perl, Lisp, etc), if the problem is suitable. The advantages of scripting need not be forsaken!
Seriously, Java-heads, this is a fine, high-quality rant. You should be able to derive much wisdom from it. Remember, your critics are among your most valuable assets.
I've been toying with this idea, and I might as well try it out here.
The free software answer to this question is, distribute source (typically in C). This works pretty well for us; although it is easy to include assumptions about the target architecture into the code, a port or two usually shakes them out. The Java answer is, distribute Java bytecode. However, most acknowledge that this in not a panacea either, as dependencies on particular implementations frequently arise.
Fundamentally, what is the difference between bytecode and C source code? Very little, except that most companies resist distributing the latter. Usually, this is jutstified as protecting company secrets.
But bytecode can be decompiled, and source can be obfuscated, with some degrees of success. In fact, early Java compilers produced code that could be easily decompiled with great results. I imagine that compilers are better now (due to more complicated techniques), but Java bytecode still retains a lot of information. How well do decompilers work today? Is it plausible that you could get more information out of bytecode than obfuscated C?
Imagine a GCC backend that, after parsing and machine-independent optimization, output C. Since this process is not substantially different from what a Java compiler does, I would expect both processes to result in similarly comprehensible output.
If this were true, it would be possible to hide "secrets", while gaining the benefits of C code, eg wide availability of compilers, interoperability with most API's (like plug-in API's), and native code speed.
Are there technical reasons this couldn't work? I know that at least one company has been accused of distributing obfuscated hardware drivers and passing them off as free software. Political issues aside, people seemed to think this effectively reduced the usefulness of the source. I believe this case was "remedied" in short time; but has any company successfully used this strategy to achieve portability without exposing "secrets"?
I'd think that any system which allows voters to do a complete preference ranking of candidates would allow multiple winners to be selected by one vote
Yes, I just meant that IRV is likely the first such system that comes up, based on its relative familiarity. And many people probably don't think to look further, since the immediate problem is solved.
I used to think that IRV was the best you could do with ranked votes, even though it had occurred to me that it would be unfair to a "compromise" candidate (who gets lots of 2 votes). I was surprised that such a clearly superior alternative exists. I guess runoff voting has a large familiarity advantage.
Thanks, but just mod me up if you're running out of points:-)
However, "Condorcet" is not a descriptive name for a voting system. Call it "Instant Pairwise Runoff Voting". That way it sounds more palatable to IRV supporters.
That's an interesting point. I wrote to the people at fairvote.org, who favor IRV. Maybe I would have had better luck using that term (you might want to try; they did reply). Though, as for descriptiveness, the "Pairwise" is accurate, but there's no "Runoff" I can see. I'm going to try Instant Pairwise Voting, for now.
You add other good points--the logistical issue seemed rather academic to me, until this Florida business. I can't believe, in this day, that we can't even conduct a simple majority vote! There are still more reasons to favor IPV at electionmethods.com and elsewhere (eg, what happens if the first place votes are split, but one candidate gets lots of second place votes?).
My city uses IRV for city council elections, and my school uses IRV for student council. I used to assume because of this that IRV was the best alternative--surely, nobody would bother switching without researching the best choice. Now, I realize that IRV was chosen simply because it permits filling multiple seats with one vote. Overall fairness probably wasn't given much thought.
If you had continued your investigation further, you would see that instant runoff is also not much better than simple majority. Strategic voting in instant runoff is actually quite easy, given two major candidates A and B and an oncoming third-party candidate C (which is the most interesting situation if you're trying to break the two-party chokehold). If your preferences are C, A, B, and you really hate B, you are best off voting A, C, B, because if you vote C, A, B, there's a good probability that A will get knocked out first, and B will beat C. This is very wrong.
A system in which strategic voting is really hard is Condorcet voting. In Condorcet voting, strategy is only possible when the public prefers A to B, B to C, and C to A, and even then, it's tricky. Condorcet also satisfies many rigorous fairness criteria that instant runoff (and other methods) fail.
While it is important to realize the problems with simple majority voting, it is also important not to fall into another, less obvious, snare, like Borda or instant runoff. Instead, look at the results of hard logical and mathematical analysis. People who study this generally agree on Condorcet. (There are some variations, so to be precise, they agree on the basic idea.) See electionmethods.com or other sites
Software companies have always taken shortcuts. One of the important engineering lessons of free software is that fewer shortcuts are taken when developers are in charge and the development (and release) process is open. This is a key to the quality of much free software. Jamie Zawinski, even after leaving Mozilla, has acknowledged that "Netscape made better decisions as a result" of freeing the code.
But it's a tough pill for a traditional software organizaton to swallow. The Netscape PDT probably understands the pressure from marketing and management to get the product out, better than they understand the pressure from programmers to get the product right. They are comfortable letting another little bug slip through (it can be patched later, right?), but the deadline is a big bad monster that cannot be allowed any slack.
I think we need to make them uncomfortable. We need to make the PDT realize that technical issues--especially standards compliance--are not pawns. Mozilla and Netscape will be the better for it.
I know well that if I don't take lunch, my turns are going to get sloppy at the end of the day. But human physical limits are much easier to reckon than mental limits.
A study that says "programmers are less productive past 40 hours" is probably talking about a random assortment of programmers working on projects in which they have little personal interest, in an environment where they don't feel especially valued. Phil is talking about starting with people who have demonstrated strong mental capacity, and handing them a challenge and a sense of ownership. My direct experience tells me that many of them will want, and be able, to work 70 hours a week without ill effect. No pressure-cooking, whip-cracking management involved.
It's not for everyone, every project, every situation. If you (as a project leader) have mediocre or unenthusiastic programmers, or are not willing and able to inspire, empower, and accept some risk, forget it--go back to defensive projecting, long design cycles, and 40 hour weeks. These get the job done. But when you assemble the elements that make bright hackers want to throw themselves into the project, it's like a powder day versus New Hampshire ice.
Slashdot Mirror
thank you thank you thank you thank you! Looks like I have something to do this weekend!
(And I'm sure I will have a great time trying to build a kernel that it likes, since I run Debian. Note to rational: you should create a system that allows a user to upload a kernel tarball and automatically compiles your modules against it. Unsupported, of course.)
But it is so much more elegant than CVS if your use of version control is at all sophisticated! (Which, if your development effort is even medium size, I would argue it should be--this is stuff that pays off. But that is a separate discussion.)
For starters, there are some simple correctness issues. Clearcase tracks files across renames, which I gather CVS does not. Moreover, it versions directories, so if you look at an old view of the repository, you see the old names. This allows everything from corrections to badly chosen filenames, up to reorganization of the repository, without any fuss.
Clearcase also has a "findmerge" command with "common ancestor" support. This basically means, when it's time to merge, you always know exactly what you need to merge, with previous merges taken into account. I honestly don't know how you could live without this. (Note this is distinct the tool that actually performs merges, which is nothing special--I just use GNU diff3, myself.)
Second, clearcase has (to me) a killer feature, filesystem support. This means that that you get an ordinary-looking unix filesystem that automatically gives you the latest versions that you're interested in. Further, using an "extended" filename syntax, you can look at any version right from the filesystem. So if you want to see what's going on in the foo branch, you just vim code.c@@/main/foo/LATEST, or if you want to figure out which mainline versions use the fooble API, grep fooble code.c@@/main/*. This is addictive. NB: the filesystem support is not available in Linux :-(
Third, clearcase is very unix-friendly. While this is not a major difference with CVS, it is still worth pointing out (since many commercial products "don't get" unix). Most clearcase commands are close to their unix analogs (or in the same spirit, when there is no analog), and the documentation is in man pages. For me, this made learning clearcase easy, and adds a significant comfort factor.
To me, version control is not just about making sure I can work on my stuff without getting stepped on by anyone else. (CVS is fine for that.) It's also about expressing, understanding and managing the relationships between various versions and branches. This is a conceptually more difficult activity, and I frankly think many posters here don't see its value (it takes a while). But if you do, clearcase wins hands-down.
I admit that, while I have used CVS, I have only had day-to-day experience with clearcase (and Visual SourceSafe--bleh!), so I don't have a good sense of the "CVS routine". It perhaps includes some practices that mitigate the lacks I've cited. But, as long as someone else is taking care of the cost and administration and resources (under these circumstances, I have found clearcase reliable, if still a bit pokey), and I don't have to interoperate with outside developers who don't have clearcase, I would take clearcase in a second.
A lot of good it does you, because the server is never going to trust that data again. You lose. (This is not the only flaw in your proposal.)
I also think everyone should consider hard why Miguel--who could probably code more functionality in a week than many of us could in a year--values freedom over functionality.
He never said anything about ignoring freedom.
Not quite, but nearly:
The most generous interpretation of the above is that freedom should be clearly secondary to functionality. A less generous interpretation is that freedom is not important at all."doesn't help anyone"--those are pretty strong words.
Your approach works great in an imaginary world with no trade-offs. Do you think Miguel ever says, "No, let's leave out that functionality. We don't need it, because we're Free!"? Of course not! But he does know that, to be successful in the long-run, GNOME and Evolution need to have the support of the hacker community. That means doing some things that you wouldn't do if you were a typical proprietary vendor aiming at Joe User:
- convenient source distribution
- smooth build process
- portability
- merging contributed patches
- establishing, maintaining, and participating in community fora
- building features that will attract developers, including features from the software that developers currently use
- including "hackability" features like ultra-configurability and an extension framework
- using (and enhancing) standard free libraries and components
- modularizing your code, so that other developers can use parts of it
- releasing early and often (with sufficient documentation for others to get started)
- addressing licensing concerns
Not every effort does all of these things in the same way; but no matter how you do it, there is a lot of overhead that goes into a good free software project. It's all worth it, in the end. But you don't get the benefits if freedom is an afterthought.Take the sixth item in particular. It ties into your "best free mail client" jibe. In fact, creating the "best free mail client" is a pragmatic strategy, even if it means ignoring Outlook-ish features, because most free software developers use free mail clients. If you make the best free client, you get lots of enthusiastic developers interested, which gives you lots of momentum. So creating the "best free mail client" is a valid goal.
In short, a person, and especially a company, are limited in the number of things they can focus on. If Helix were focused primarily on functionality and usability, they would be less focused on freedom, and would have less support from the community, and would have a lower chance of success.
What non-free software has taken off on Linux that had even one half-as-good--or even just promising--free competitor? This is a major hurdle to overcome.
First, who has the copyright? I assume it is your employer, in which case of course they have no legal obligation to credit anyone. However, a few companies assign it to the FSF, and there may be other policies as well.
Second, is there a significant user community around the software? If so, you should be able to point out to them that your name was on earlier versions of the software, and that the company is being dishonest by hiding your contribution.
Third, is the software "Free Software" free? If so, it should be easy for you to demonstrate evidence of your authorship. There is also more likely to be a sympathetic community if the software is free.
(Hmm... why aren't we all using StarOffice or ApplixWare?)
Wine doesn't let you run xbill in Windows. It lets you run WinLinus in X.
Linus's "predictions" are not announcements or press releases or marketing messages. They are his personal opinions, usually expressed on the development mailing list to other programmers (and occasionally in interviews to reporters). It's your fault if you take them for anything else (just like it's your fault if you expect him to make coding decisions based on anything other than what he finds pleasing).
I tell you this because I think (but am not sure) that PDA's are still in this category. Though there is probably some support for just about any PDA, I'd bet that you'll have much better luck with a Palm-compatible than anything else. I'm not knocking the programmers working on other PDA's, but for now, they're shorthanded. Unless you want to help improve the support for other PDA's, buying one is risky.
Disclaimer: I am not terribly familiar with Linux PDA support. I am speaking on general terms but from considerable experience.
Widespread infrastructure failure? Riots? Depression? That's a bit more than a "disruption".
And remember what he said about Y2K?
I admire and like Eric--he's an uber-hacker--but I think in his zeal to sell "Open Source", he's become too confident in his theories.
Whatever merits your plan may have, it is exactly the sort of thing that would increase the number of dirtbags involved, because it would inevitable drive many domain transactions "underground" (you know, with the dirt).
The microkernel design seems to me to be fundamentally more secure.
Currently, very few vulnerabilities of mainstream (monolithic kernel) systems involve compromise of the kernel proper. I can't think of any off hand. Some involve DOS'ing the kernel (ping of death). Some involve tricking the kernel into sending bad data to someone else (eg, modprobe). I've heard of potential buffer overruns being fixed in Linux, but I've never heard of any being exploited. Perhaps it's because there are too many bugs to exploit above the kernel, or because it's too hard to develop and tests the exploits, or because kernel developers are just a careful breed; but making the kernel harder to take over doesn't seem to buy you much in practice.
Even if you are worried about such attacks, it's not at all clear that a microkernel wins. A great benefit of a monolithic kernel is that the entire development project is more unified. Developers are more likely to be familiar with the whole codebase, aware of interrelationships and finding bugs throughout. This is why Linus insists on keeping megs of random drivers in the kernel distribution. If the parts of a microkernel are developed in more isolation, there are fewer eyes on the whole thing, and more chance of miscommunication. For example, the Linux/modprobe bug mentioned above could just as well have happened between two services in a microkernel-based system.
You have the misconception that scripting is not acceptible on the enterprise server. This is not true. Robust and performant application can be written in Python (or Perl, Lisp, etc), if the problem is suitable. The advantages of scripting need not be forsaken!
Seriously, Java-heads, this is a fine, high-quality rant. You should be able to derive much wisdom from it. Remember, your critics are among your most valuable assets.
(JAPH, Pim)
I've been toying with this idea, and I might as well try it out here.
The free software answer to this question is, distribute source (typically in C). This works pretty well for us; although it is easy to include assumptions about the target architecture into the code, a port or two usually shakes them out. The Java answer is, distribute Java bytecode. However, most acknowledge that this in not a panacea either, as dependencies on particular implementations frequently arise.
Fundamentally, what is the difference between bytecode and C source code? Very little, except that most companies resist distributing the latter. Usually, this is jutstified as protecting company secrets.
But bytecode can be decompiled, and source can be obfuscated, with some degrees of success. In fact, early Java compilers produced code that could be easily decompiled with great results. I imagine that compilers are better now (due to more complicated techniques), but Java bytecode still retains a lot of information. How well do decompilers work today? Is it plausible that you could get more information out of bytecode than obfuscated C?
Imagine a GCC backend that, after parsing and machine-independent optimization, output C. Since this process is not substantially different from what a Java compiler does, I would expect both processes to result in similarly comprehensible output.
If this were true, it would be possible to hide "secrets", while gaining the benefits of C code, eg wide availability of compilers, interoperability with most API's (like plug-in API's), and native code speed.
Are there technical reasons this couldn't work? I know that at least one company has been accused of distributing obfuscated hardware drivers and passing them off as free software. Political issues aside, people seemed to think this effectively reduced the usefulness of the source. I believe this case was "remedied" in short time; but has any company successfully used this strategy to achieve portability without exposing "secrets"?
I'd think that any system which allows voters to do a complete preference ranking of candidates would allow multiple winners to be selected by one vote
Yes, I just meant that IRV is likely the first such system that comes up, based on its relative familiarity. And many people probably don't think to look further, since the immediate problem is solved.
Thanks :-)
I used to think that IRV was the best you could do with ranked votes, even though it had occurred to me that it would be unfair to a "compromise" candidate (who gets lots of 2 votes). I was surprised that such a clearly superior alternative exists. I guess runoff voting has a large familiarity advantage.
Thanks, but just mod me up if you're running out of points :-)
However, "Condorcet" is not a descriptive name for a voting system. Call it "Instant Pairwise Runoff Voting". That way it sounds more palatable to IRV supporters.
That's an interesting point. I wrote to the people at fairvote.org, who favor IRV. Maybe I would have had better luck using that term (you might want to try; they did reply). Though, as for descriptiveness, the "Pairwise" is accurate, but there's no "Runoff" I can see. I'm going to try Instant Pairwise Voting, for now.
You add other good points--the logistical issue seemed rather academic to me, until this Florida business. I can't believe, in this day, that we can't even conduct a simple majority vote! There are still more reasons to favor IPV at electionmethods.com and elsewhere (eg, what happens if the first place votes are split, but one candidate gets lots of second place votes?).
My city uses IRV for city council elections, and my school uses IRV for student council. I used to assume because of this that IRV was the best alternative--surely, nobody would bother switching without researching the best choice. Now, I realize that IRV was chosen simply because it permits filling multiple seats with one vote. Overall fairness probably wasn't given much thought.
A system in which strategic voting is really hard is Condorcet voting. In Condorcet voting, strategy is only possible when the public prefers A to B, B to C, and C to A, and even then, it's tricky. Condorcet also satisfies many rigorous fairness criteria that instant runoff (and other methods) fail.
While it is important to realize the problems with simple majority voting, it is also important not to fall into another, less obvious, snare, like Borda or instant runoff. Instead, look at the results of hard logical and mathematical analysis. People who study this generally agree on Condorcet. (There are some variations, so to be precise, they agree on the basic idea.) See electionmethods.com or other sites
But it's a tough pill for a traditional software organizaton to swallow. The Netscape PDT probably understands the pressure from marketing and management to get the product out, better than they understand the pressure from programmers to get the product right. They are comfortable letting another little bug slip through (it can be patched later, right?), but the deadline is a big bad monster that cannot be allowed any slack.
I think we need to make them uncomfortable. We need to make the PDT realize that technical issues--especially standards compliance--are not pawns. Mozilla and Netscape will be the better for it.
I know well that if I don't take lunch, my turns are going to get sloppy at the end of the day. But human physical limits are much easier to reckon than mental limits.
A study that says "programmers are less productive past 40 hours" is probably talking about a random assortment of programmers working on projects in which they have little personal interest, in an environment where they don't feel especially valued. Phil is talking about starting with people who have demonstrated strong mental capacity, and handing them a challenge and a sense of ownership. My direct experience tells me that many of them will want, and be able, to work 70 hours a week without ill effect. No pressure-cooking, whip-cracking management involved.
It's not for everyone, every project, every situation. If you (as a project leader) have mediocre or unenthusiastic programmers, or are not willing and able to inspire, empower, and accept some risk, forget it--go back to defensive projecting, long design cycles, and 40 hour weeks. These get the job done. But when you assemble the elements that make bright hackers want to throw themselves into the project, it's like a powder day versus New Hampshire ice.