No, that's not right. If I am developing some application and want to support some feature, I don't have time to sit down, figure out, and write a specification for that feature. Instead, if there isn't a spec around, I probably just won't implement that feature. The author had several viable points and the reply from the Xiph folks seemed to miss several of them. (Take how the reply completely missed the point about the comparison between OV and RA being that there is only one implementation not a matter of licensing issues.) The fact is that if Xiph wants their sound format to be more than a little toy, they need to do the not fun work of writing a specification, and the author was just trying to make that point. He could have just said "screw it", but instead he seems to want OV to succeed.
Code is not a specification. It is just an implementation.
This is mostly true but there are some inaccuracies.
For one thing, don't underestimate the influence of BSDi and WRS in paying people to work on FreeBSD full time. A lot of work (good or bad depending on who you talk to) came out of that. WRS didn't have any bad intentions when they bought BSDi as far as FreeBSD, I think it was more that they didn't know quite what they were getting (at least some people thought BSD/OS was an enhanced version of FreeBSD) and once they had it they didn't quite know what to do with it. FreeBSD kept going despite that, however, but corporate sponsorship is still quite important to FreeBSD. The main reason is that companies have money.:)
Secondly, while developers who used to work at Whistle do have a pretty good chunk of influence, it isn't necessairly Whistle driving that. KSE (the scheduler activations stuff) was originally threshed out by Jason Evans, Dan Eischen, and Julian Elischer. Julian is the only one of those who used to be a Whistle employee. He is currently working on the implementation, but he hasn't been employed by Whistle in quite some time. If you wanted to list the key architects in FreeBSD, you would find that they come from several different companies all over the place, and there really isn't a massive concetration of them in one company relative to another. The only exception to that might be the old WC/BSDi of which half the group now works at Apple.:)
Thirdly, the bandwidth isn't quite so bad as you make it. The actual development servers have not been at WC for quite some time (at least 1.5 years now IIRC) and never were at WRS. While ftp.freebsd.org did have its ups and downs for a bit, the actual devel servers have worked without a hitch. ftp.freesoftare.com was already somewhat on the way out before WRS stepped in, they two events just happened to coincide.
As for the Foundation, it isn't really a competitor to either DN or FreeBSDMall. The Foundation is a 501(c)3 non-profit designed to accept donations. It doesn't have any plans to sell CD's AFAIK. The Foundation was first setup well over a year ago and may have pre-dated the WC and BSDI merger/acquisition, but I'm not sure of that. I don't think having multiple CD distributors will be all that bad. However, I think FreeBSDMall has an edge over BSDMall, so it might be interesting to see how that pans out. One thing I would point out is that like WC did in the "good ole days", FreeBSDMall employs the chief release engineer for FreeBSD.:) However, the Project is also more open about not having an official sponsor anymore.
Anyways, you were mostly on, but there were a few subtle things you didn't quite have right.
Hopefully it will surpass Linux 2.4's SMP once it is done. However, I don't expect it to be done when FreeBSD 5.0 comes out. Instead of trying to push down code locks from the top, FreeBSD is approaching the preemptive kernel stragety a little different. We are using locks on data structures rather than on blocks of code. (Or attempting to at least.) This also involves other weird things like having interrupt handlers run in their own kernel thread context so that they have a context in which to block on a mutex. Unfortunately, it is still very much a WIP, and right now 99% of the kernel still lives under the Giant mutex. As more common structures get locked down, we will be able to start moving parts of the kernel out from under Giant. For example, I'm about halfway through sys/kern in my sweep of locking down struct proc right now. Once that is done, we will be able to remove Giant from several system calls as well as signal handling and ast handling during returns to usermode from traps, interrupts, syscalls and the like.
Slashdot Mirror
No, that's not right. If I am developing some application and want to support some feature, I don't have time to sit down, figure out, and write a specification for that feature. Instead, if there isn't a spec around, I probably just won't implement that feature. The author had several viable points and the reply from the Xiph folks seemed to miss several of them. (Take how the reply completely missed the point about the comparison between OV and RA being that there is only one implementation not a matter of licensing issues.) The fact is that if Xiph wants their sound format to be more than a little toy, they need to do the not fun work of writing a specification, and the author was just trying to make that point. He could have just said "screw it", but instead he seems to want OV to succeed.
Code is not a specification. It is just an implementation.
This is mostly true but there are some inaccuracies.
:)
:)
:) However, the Project is also more open about not having an official sponsor anymore.
For one thing, don't underestimate the influence of BSDi and WRS in paying people to work on FreeBSD full time. A lot of work (good or bad depending on who you talk to) came out of that. WRS didn't have any bad intentions when they bought BSDi as far as FreeBSD, I think it was more that they didn't know quite what they were getting (at least some people thought BSD/OS was an enhanced version of FreeBSD) and once they had it they didn't quite know what to do with it. FreeBSD kept going despite that, however, but corporate sponsorship is still quite important to FreeBSD. The main reason is that companies have money.
Secondly, while developers who used to work at Whistle do have a pretty good chunk of influence, it isn't necessairly Whistle driving that. KSE (the scheduler activations stuff) was originally threshed out by Jason Evans, Dan Eischen, and Julian Elischer. Julian is the only one of those who used to be a Whistle employee. He is currently working on the implementation, but he hasn't been employed by Whistle in quite some time. If you wanted to list the key architects in FreeBSD, you would find that they come from several different companies all over the place, and there really isn't a massive concetration of them in one company relative to another. The only exception to that might be the old WC/BSDi of which half the group now works at Apple.
Thirdly, the bandwidth isn't quite so bad as you make it. The actual development servers have not been at WC for quite some time (at least 1.5 years now IIRC) and never were at WRS. While ftp.freebsd.org did have its ups and downs for a bit, the actual devel servers have worked without a hitch. ftp.freesoftare.com was already somewhat on the way out before WRS stepped in, they two events just happened to coincide.
As for the Foundation, it isn't really a competitor to either DN or FreeBSDMall. The Foundation is a 501(c)3 non-profit designed to accept donations. It doesn't have any plans to sell CD's AFAIK. The Foundation was first setup well over a year ago and may have pre-dated the WC and BSDI merger/acquisition, but I'm not sure of that. I don't think having multiple CD distributors will be all that bad. However, I think FreeBSDMall has an edge over BSDMall, so it might be interesting to see how that pans out. One thing I would point out is that like WC did in the "good ole days", FreeBSDMall employs the chief release engineer for FreeBSD.
Anyways, you were mostly on, but there were a few subtle things you didn't quite have right.
- jhb
Hopefully it will surpass Linux 2.4's SMP once it is done. However, I don't expect it to be done when FreeBSD 5.0 comes out. Instead of trying to push down code locks from the top, FreeBSD is approaching the preemptive kernel stragety a little different. We are using locks on data structures rather than on blocks of code. (Or attempting to at least.) This also involves other weird things like having interrupt handlers run in their own kernel thread context so that they have a context in which to block on a mutex. Unfortunately, it is still very much a WIP, and right now 99% of the kernel still lives under the Giant mutex. As more common structures get locked down, we will be able to start moving parts of the kernel out from under Giant. For example, I'm about halfway through sys/kern in my sweep of locking down struct proc right now. Once that is done, we will be able to remove Giant from several system calls as well as signal handling and ast handling during returns to usermode from traps, interrupts, syscalls and the like.