Slashdot Mirror
Halloween Document Revisited
GroundBounce writes: "The front page of LWN has an interesting three-year-after analysis of the predictions in the Halloween document, which was "leaked" from Microsoft around Halloween of 1998. It's interesting to see how their predictions have/have not panned out."
Moderators: this is more Usenet plagiarism from spootnik.
There are BSD copyright notices in various userland utilities because Windows has an implementation of the BSD sockets API, which makes the BSD utilities relatively easy to port. The kernel is a different matter--while I haven't seen the source code to Windows, I have seen the DDK and the documentation for writing Windows device drivers. Windows device drivers are quite different from BSD device drivers; it would be a major undertaking to take BSD's TCP/IP stack and interface it with the rest of the Windows kernel. I don't think it'd be worth the effort... even with Unix-like OSes like *BSD and Linux, it's generally not worth the effort to actually take code; the other OS' code is just good as documentation. I think it's much more likely that MS reimplemented the sockets API to give programmers an interface they were familiar with.
Even if you want to go all out with the benefit of the doubt, and decide that they rewrote their own implementation of the API, it's still safe to say that MS' IP stack is based on BSD.
I don't see that that follows... the IP stack is the low level protocol implementation, not the API.
It is true that closed-source projects can make one sort of deadline and stick to it. That's the "we'll ship by" sort of deadline. That's not the kind of deadline that knowledgeable users generally need.
The sort of deadline that open-source projects can generally meet is the "we'll get a nightly build up every night" and the "we won't call it version 1.0 until we're ready" sorts. These will do just fine for knowledgeable users. No closed-source company can meet this kind of commitment.
Indeed, but there are very serious problems with development processes that set these kinds of deadlines.
Clearly, the "we'll ship by" deadline can lead to shipping products that were not ready to ship. But if project managers and developers are intelligent about it, it can also lead to debugging and other project finalizations being done when they need to be done.
"We'll get a nightly build up every night" can become a completely worthless type of deadline very quickly. Nightly builds are worthless and should not count as any kind of achievement most of the time. No user needs a new release every night, especially at the cost of uncertainty of quality. Post builds when it's useful to users to do so. Developers shouldn't need a build posted every night to continue the development process.
The "we won't call it 1.0 until it's ready" anti-deadline is obviously a rule that everyone should follow. It's tautological. Unfortunately, I think a lot of the time, especially in open source projects, this rule gets turned into "we won't call it 1.0 until we get bored of adding new features to it; and we won't debug it after that because that isn't as interesting to do." Worse yet, it turns in to "we won't bother releasing a version we'll call 1.0 any time soon because stableizing the project to an acceptable level isn't something anyone on the team is interested in."
Even microsoft has figured out a solution to the problem of making users wait for an official release. It's called releasing betas to the public. It's still up to the users if they feel the betas are good enough to use on a daily basis. Still, for most users, it is unacceptable to have to try out more than one release of a product to find out if it's up to their standards. A whole lot of users want that 1.0 release so they can try it will the expectation "if this release isn't good enough, the product isn't good enough, and I should go try something else."
I'm not a smorgasbord.