Well, firstly, you'll have to substantiate the importance of each part of your claim that the BSD's are a lot less popular, supported, and easy to learn, and that these are negative things.
Popularity is really not a good reason to choose something. Windows is a lot more popular than Linux. It has more users, more commercial programs, more programmers, certifications, and possibly books, training courses, and any number of other things. It doesn't make it any better, really, now does it? Yes, there are more Linux users than FreeBSD users. It doesn't really make that much of a difference.
As for support, is getting support for SuSE easy to get in a group that predominantly uses RedHat? Yes, some of the stuff is incredibly similar, but there are differences. The differences are on rough par with any differences you may find running FreeBSD, for example. As for commercial support, Wasabi Systems, BSDi, and a number of smaller consulting and support firms exist, reminiscent of Linux just two years ago. They'll grow, and BSDi is a good bet, and a reasonably well-known name amongst the older crowd of managers, so that's a bonus. I find the FreeBSD online support great, if that's a help. It's incredibly unusual for a help request to questions@FreeBSD.org not to be answered, and at least a few times correctly. (:
Easier to learn, again, is questionable. It's easy to learn something if you have, say, a friend next door that runs the same thing. At my university, FreeBSD became very popular (much more so than Linux) because the people who took the time to help out and organize things knew FreeBSD best, and suggested people try it. Those same people who used Linux before considered FreeBSD much easier to learn. The same may apply the other way around in your area. It isn't a matter of ease, but your surroundings. If you go it alone, like I pretty much did, it ends up being a personal matter (discussed below). As for documentation, I'd say it depends on the person. The FreeBSD Handbook helped me through most of my trials, but some find it too complicated, and some find it too abstract. Greg Lehey's book is good. There're FreeBSD courses offered by BSDi, amongst others. The NetBSD documentation is technically great and complete.
As for choosing between them, there are a few areas you have to discuss, really:
Firstly, why RedHat vs. SuSE? Why RedHat vs. Debian? Why foo and bar vs. fred and wilma? (obscure? me? never.) In this case, it's a matter of taste - some people just prefer something to another. It just fits their way of thinking and of doing things. And that requires trying everything until you can decide what fits your style. (Slackware's "do-it-yourself" vs. Debian's "we-have-a-package-for-everything!")
Secondly, we have to consider the actual product. The BSD product is integrated kernel and userland, with a full operating system as the product. Linux is a kernel, and RedHat, Debian, SuSE, and friends are the "full operating system" in the end, with subtle differences in between as to which programs are standard, where they live, how to configure them, versions, and so forth. "Linux 2.4.0ac1" is nowhere near sufficient to discuss a problem you may have - you need to know "RedHat 7.0" or "Debian 2.1" or something like that. You'll also need to know what modutils version, ppp version, and all sorts of other things. The BSDs have a slightly more integrated system, which may seem slightly inflexible to some, but which makes solving these things a lot easier - "FreeBSD 4.2", or "FreeBSD -CURRENT from 5 January" are pretty specific in what they contain.
Development models are slightly different. Linux has Linus being the only person with the ability to directly incorporate a change (which may be passed through a number of filters, such as Alan Cox, before Linus does the actual putting of the code in the source tarball), whereas with the BSD groups, there are a number of people who may make such changes in the kernel. Again, BSD is integrated userland and kernel, whereas the Linux distributions have different models for patches - Debian being the most community driven (roughly equivalent to the way the Open Source BSDs are run), and RedHat and SuSE having slightly more closed commercial processes.
Pure technical reasons are hard to find. Linux is ahead in some areas, the respective BSDs in their own. NetBSD's portability (not just kernel, but userland, and quality portable and correct coding models) is a god-send to many. While you can get "Linux" for Alpha, PPC, ARM, Intel, Dreamcast, and friends, it won't be the same Linux distribution, and will not be the same system, really (actually, Debian may come close). FreeBSD still has the occasional performance benefit, and still leads with some new features like kernel queues, accept filters, jail facility, and others. OpenBSD still has the most integrated crypto, followed only slightly further behind by FreeBSD and NetBSD, and also a well-auditted set of programs, and occasionally comes up with things like strlcpy and strlcat that are so obvious and yet missing.
You may consider the general community as a reason to choose something. You'll find your trolls in all of course. Some prefer the more "less talk, more code" and skill-driven attitude of NetBSD, or maybe the very weird culture that I enjoy in FreeBSD - a balanced "Let's try to do things right, and that means staying up to date, not falling behind but not living too close to the edge, copying ideas from other people's stuff, writing our own, and having fun while we're doing it" kind of attitude. I've had bad experiences with some online Linux communities, and with some online FreeBSD communities, and with some... - their choice in operating system doesn't seem to indicate they'll be nice or nasty people. In my experience, people just "are", and there're many more things that form the person than simple OS choice.
I'm rambling I suppose, but my final suggestion is that unless you have almost no time, no motivation, and no interest in exploring something else; just try it. Learn as much as you can about their differences and similarities, advantages, disadvantages, get kicked from lame IRC channels, enjoy socialising with the nicer IRC or mailing list people, and have fun, increase your knowledge, and try to be an ambassador for whatever your choices may end up being.
Feel free to reject the statement that any number of people are "allowed to modify a Free Software product, either Linux or a BSD". I didn't say anything about the restrictions regarding the modifications of copies of the source code that is distributed in the official projects.
There are two possible meanings of (for example) "FreeBSD source code", depending on stress:
The _FreeBSD_ source code is "The source code to the FreeBSD operating system, that is used to generate FreeBSD install CDs, is available in the FreeBSD cvs tree". In this case, no, you can't modify the _FreeBSD_ source code, because you don't have commit privilege - the 233 committers in FreeBSD can, though.
Or, the FreeBSD _source_code_ is "The source code to the FreeBSD operating system, freely available for anyone to use, whose modification need not occur in the active FreeBSD project, and can indeed be used in other projects". In this case, you're totally free to modify the source code. However, you are not modifying the source code to the actual FreeBSD operating system, just a local copy. You can feel free to submit patches back if you like.
The same applies to Linux - you can play all you like with the code with the usual restrictions, but you need to get Linus to accept it if you want it to become part of the Linux kernel. You can modify your own copies of it, but you need his permission and intercession for you to indirectly modify the actual Linux kernel source code, as distributed in tarballs.
I can't believe you're talking about the second meaning, since it's obvious I'm not talking about it in my comment - I specifically talk about direct modification of the FreeBSD source in CVS, and the modification of the Linux kernel in the tarballs.
In the first case, and as you later continue, the core team or Linus do indeed have no way to compel people to make changes to the "offical" distribution formats of FreeBSD (cvs) or Linux (tarball), nor do they have any power to compel people not to make their changes in other formats, such as local copies or other projects (subject to licensing).
The thing is - if everyone disagreed with Linus, would it still be Linux? Linux is a registered trademark of Linus, and as such, if people run off and do other work, it is not the "official" Linux tarball, and it would need to be renamed, unless Linus gave his approval.
I'm not sure if Mr. Jolitz trademarked 386BSD, but he certainly would not have allowed the upstart NetBSD and FreeBSD teams to continue calling themselves "386BSD" - that was his baby. Hence the renaming. FreeBSD is a registered trademark too, so if the FreeBSD core (who hold it with permission of the trademark owner) were deemed too slow or old or whatever to do real work, the disillusioned could form another system, but not "FreeBSD".
I'm pretty sure you know all this, I just wanted for the slashdot readers to know that you were talking about something unrelated to my comment; your comment mostly discusses the advantages of open source development (freely available, or free-for-source-available-derivatives source) and the realities of open source projects (the inability to force cats^H^H^H^Hhackers to follow a given path).
Obviously "gets hit by a bus" is a metaphor, and it is not to be taken seriously. It means "becomes unavailable", and I think you'd agree that if Linus did become unavailable, there'd be quite a bit of upheaval. Nothing fatal I imagine, but some upheaval - whoever takes over would also probably get quite a bit of "But Linus would have done this..." coming his or her way.
However, if one of the FreeBSD Core "became unavailable" because of other work, a change in direction, moving to another project, it wouldn't have nearly the effect. I imagine the most likely to cause the most upheaval is jkh. Whoever replaces the core member isn't likely to face "but foo would have done this..." arguments - core is about reaching concensus on issues that have escalated to that level - to settle disputes, add more committers, and very very occasionally decide policy. Everything else is based on rough concensus and working code in the project.
I don't believe you can say that the Linux kernel development is "at least as decentralized", in the sense that at least 233 people can directly modify the FreeBSD source code, including kernel. There is no need for them to get formal review and acceptance by a single person before it is possibly to go in - it is simply expected that review is sought, that the code is tested, and that you know what you're doing, and that you notify the maintainers or active worker on the subsystem you're working with. Architectural changes are monitored by various people (as I imagine it is with Linux too), and any questionable code is (optionally) backed out and discussed. People who repeatedly refuse to get review and discuss changes would theoretically get their bits removed, but there hasn't been a case in the time I've been following the project.
This is "decentralized", meaning ``withdrawn from a center or place of concentration; especially having power or function dispersed from a central to local authorities''. I'm not saying it's good or bad, but that's what it means - all changes are centralized through a point of concentration (Linus at the moment). The function of physically changing the code and generating the tarballs or whatever (since there's no versioning) falls with him.
One could theoretically extend that to FreeBSD in the fact that changes have to be made via cvs (or locally with cvs) on the FreeBSD cvs server, but that's a little technical. The function of changing the code is performed by the committers - the rest is automated and not concentrated through a single reviewer and changer.
Again, this is not a judgement, simply an observation. I don't think anyone in FreeBSD has the time and inclination to step up and manage every single change to the kernel, userland, documentation, or web site, so the functionally-decentralized distributed method probably suits FreeBSD.
Regular contributions are like more than three to five contributions ever. Or, rather, if it were defined that way, there would probably still be no regular female contributors.
Regular contributors become committers if they show they're able, and an existing committer asks if they're willing and they accept, and there is no veto by core (can't say I know of any recently).
Personally, I don't think there's any bias against women in the combined committer group, even if it's possible there is in one or a few individuals, and there certainly isn't any with me. It's all business - do the work, get the rewards, even if at first it's just recognition and praise. There is plenty of scope for new contributors, if you're having trouble looking for stuff to do, feel free to contact me. (nbm at FreeBSD.org)
It would be pretty impressive to come up with a female on a team out of a group of available nominees of all males.
The reason the nominees are all male is because there aren't any repeat female contributors. I see no reason for this to be due to any cost of contributing, nor to any adverse behaviour, unless it was entirely private and not on the regular mailing lists, and the female in question not making a public announcement about it, which I doubt is the case.
If that's not the case - if there is a cost to contributing, or there is negative behaviour that prevents you from contributing again, then kindly contact me directly (I'm nbm at FreeBSD.org), because I'd like to hear about it - bad reactions are not what anyone working on FreeBSD wants to happen to contributors.
If anyone (male or female) wishes to contribute to FreeBSD, it's very easy, and they can feel free to ask me via email if they have any questions, preferably after reading the relevant documentation.
I think it all boiled down to concerns that the core team weren't doing enough, that they were doing too much, that they were too closed off from the rest of the committers, that there were some people not doing any work just lurking there, and that some new blood would probably help revitalise things.
The idea for the new "democratically elected" core is that it will be re-elected on a regular basis (I can't remember exactly, but something like one or two years), and that it will allow people to get time off, take a break, return to real work without the overhead of core, and allow new, fresh, and revitalised blood back onto core.
I'm a FreeBSD committer, and my opinion is that is good - some core team members have been hanging on just because they were afraid no new blood would replace them - earlier this year a core member left core so he could concentrate on "real hacking" instead, and wasn't replaced. The new blood means people more motivated and eager, and often with more time and new perspectives.
The 225 or so committers that were around at the time of the nominations (there are 233 now, and yeah, I'm one of them) were allowed to vote for the core team.
Any of those 233 committers can commit changes, core is just there to perform some more complex functions, like settling disputes.
The leaving core members are still committers, they were just lucky to escape and get a bit of a holiday.
There can't be a woman on core, because core are a subset of committers, and there are no female committers.
That there is no female committers could imply two things - that there is a bias against women in FreeBSD core, or a lack of female contributors. It's most likely the second. There just aren't any returning female contributors, and committers are generally people who contribute over and again and show they know what they're doing by finding bugs and solutions in a few areas.
If any girls or women would like to get involved with FreeBSD, there are good entry spots in ports, documentation (in-depth kernel and user), filesystems, and for people who develop a good understanding of kernel internals (which, I admit I don't have, which is why I took the easy route and write documentation and ports).
The groups are occasionally a bit odd-ball, but avoid known trolls and get to know the more approachable people, and you're going to enjoy the community aspects (mailing lists, &c.) and the technical aspects (by getting someone you know to help review and commit your changes).
FreeBSD isn't particularly insular, there is increasingly younger (youngest committer is 16, I think) and newbie-er committers - the key is to contribute and not be aggressive and attacking if there is review and your solution is found wanting. We want your help, but we also want the correct solutions. If you think we're ignoring you, then send a reminder to your problem report every once in a while - chances are people are incredibly busy.
No, quite obviously it wasn't intended for use in proprietary products without fee. If you wanted to use it in your proprietary product, you could pay for it. Your product will work with or without softupdates, so it's a matter of whether you're willing to contact Mr. Mckusick and see what sort of arrangement you could get.
I'm quite sure, and hope, Kirk was able to make some money out of it, which allows him to continue developing and contributing. From the beginning, it was intended to be released under BSDL later, but still allowed the open source BSDs to use it, and help develop, test, and contribute towards it. I think this is great.
I'm happy the BSDL allows this to happen - Kirk has worked on BSD for years, distributing the results under the BSDL, and other licenses might not have given him the opportunity to fund his development simply by developing. Of course the 'service and support' side could work, and does, but that one can make a living with updates, speedups, new algorithms, and redesigns is mostly the point.
I think this is the BSD way. The other license is simply not the BSD license, but definitely fits in with the BSD way, in the grand scheme of things.
I think you may have read the final sentence out of context.
I said that neither GPL nor BSD will allow you to force a company to pay you if you want to later sell them your code, because at the end of the day, with the BSD license, they can just take it, and with the GPL, you probably won't own the end copyright.
Thus, you can't 'sell out' and give it to the company with a non-GPL license without first getting the permission of the other contributors.
I'm sorry if my final sentence was ambiguous in this regard. I know very well that you can sell GPL binary products, on the condition you make the source available, and allow anyone who receives a copy to pass on that product under the GPL license (roughly paraphrased). I recently convinced a local (South African) company to do this.
When I read your topic, I thought you were going to say something about NetBSD, OpenBSD, and FreeBSD. After all, they're not fragmented, they're specialized. I mean, there used to be four of them, and there'll soon be three, and the projects share code and collaborate in joint BSD-wide projects like KAME, so if anything, they're unifying.
I was disappointed to see you say "Linux can't truly fragment because of the nature of the GPL." with such authority. There's nothing in the GPL that prevents multiple GPL'd projects based on the Linux kernel code, after all.
However, I agree with you. Use what you enjoy and what works. Use different systems for different purposes. Use Linux if you want for your desktop, or your workstation, or your server, or your Palm. If you're inclined, go for a FreeBSD mega server like cdrom.com, and boast about your terabyte and a bit of traffic daily. OpenBSD'ify your router/firewall machine and show off your encrypted swap space, or NetBSD'ify that old Sparc and have people perve your UVM. Have fun, damnit!;)
What portal is this? cdrom.com? Walnut Creek doesn't own that. What financial situation is this? Where are you making this up from? Why is it that Walnut Creek have been making moves to spend more money on FreeBSD conventions, development, and publicity?
Walnut Creek believes in FreeBSD, and the bottom line is that FreeBSD is their most successful product. A merger which will make the product more popular can only help them. BSDI is quite happy to merge peacefully with Walnut Creek, as it doesn't want to alienate the FreeBSD community, especially Walnut Creek employees such as Jordan, Jim, Greg, Bill, and others, and they both genuinely gains a lot from the deal.
It is hard to believe a merger that places Jordan as the CTO, and places Mike Karels and David Greenment as co-architects, is a takeover.
(btw, I also bought my first Linux distribution from Walnut Creek, way back when, when there were only two or three distributions to chose from, and Slackware was the only real choice. This was also when FreeBSD was suffering under the lawsuit.)
The daemonnews article indicates that in the end, there'll be the joint code base, called FreeBSD, and any parts that are unable to be merged due to NDAs or other restrictions, will be available from the new company.
Therefore it seems quite likely you'll see FreeBSD commercial product, and not BSD/OS, which as a name (but not as a legacy) will not be used. To answer your question, it won't be a free vs. branded deal as Mozilla vs. Netscape, but will be a merger into FreeBSD, and some non-free commercial extensions to FreeBSD will be available from BSD, Inc.
While this is strictly off-topic, you're wrong when you say "if I were to release my code under the BSDL, a company can use it without even mentioning my name or giving me a penny". BSD-style licenses use the following:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Of course, if you're wanting to protect your code so that you can't not make money out of someone using it in a commercial product, neither GPL (after an extended period of time where people return patches to you) nor BSD are for you.
The patches you receive if you use the GPL are also under GPL, and copyright to the originator of the patch. The resulting work is GPL and shared by you and each contributor, and thus you'd need to get all the contributor's permissions before you can sell the end product.
Hopefully you'll read this, it would have been nicer to send you an email.
Some of your points above saying that 'qmail assumes' are simply what you assume that qmail assumes.
qmail does not assume that all users have entries in the passwd file, nor does it assumes all users have different UIDs, not in fact does it assume that each user has a home directory.
Just take a look at what vpopmail does to simply provide hints to qmail as to how to handle mail. All the stuff vpopmail does is easy to do manually, and all is easily understood from the available documentation. In fact, before I knew about vpopmail, I created a utility that did basically the exact same function in an hour or two.
Your other two points are true, although maybe not valid, and they're specific assumptions made by the code. You personally may think that a shared queue with multiple queue runners is the only way to work, but I would like to know whether you tried it qmail's way before deciding that was the way to do it. Admittedly, perhaps qmail isn't flexible in that area, but then again, perhaps qmail does it for a reason. djb is well-known for restricting people from shooting themselves in the foot, even if they might want to aim in the general direction of their foot, and are sure they won't hit it.
That said, I currently have no preference in MTAs between exim, postfix, and qmail, since they all seem to be very good products. I haven't had the time and inclination both at the same time to learn sendmail yet, but I'm sure I'll give it appropriate time before making any judgement.
From what I read in the Daemonnews article, in the end (which may take a while), there'll be only one source tree, still called FreeBSD. It will contain roughly the existing mish-mash of BSD licensed, GPL (gcc and numerous friends), and beerware licensed code.
The only code not scheduled for inclusion is that which was written by BSDI under NDA to another company, since they're under obligation by the NDA not to release that code.
For some people, providing good code to all takers is what makes them feel happy and fulfilled, knowing that their code is going to benefit end-users of some system, where that system does not creating their own, possibly inferior, implementation. In the end, there'll be a massive collection of good code that anyone can use. Due to various reasons, many companies make their changes, use them for a few months for some competitive advantage, and contribute them back (Netgraph and other items from Whistle are a good example).
Other licenses, by restricting their uses to open source projects, may lead a system to reimplement something poorly, and their end-users will suffer for it. However, it does end up with a massive collection of good code, and may help non-open systems become open source, which provides all the benefits of open source to that whole system, instead of just the original code.
I'm a committee member of a Linux User Group (even though I don't use Linux much), and after last night's meeting (on OpenBSD) we were all at the pub, drinking, as all South African open-source people seem to do, and we started getting philosophical.
An interesting, although oft-mentioned, reason why we shouldn't start slating projects that do roughly the same job is to foster competition, to have a 'biodiversity'. A case in point is qmail vs. postfix in the "secure fast mailer" section (vs. exim vs. sendmail in general too).
While it's perl's motto that "There is more than one way" to do something, I think it is almost necessary that there should be, so that there can be users of differing ways, who can have friendly competition to improve their programs against each other, leading to two or more very good products.
(But then we were drinking, so maybe this requires more thinking *grin*)
It is up to the author to decide whether he wants everyone to gain from his changes, or whether he wants only free-software/open-source users to gain from it.
I personally prefer to have everyone gain from my code, as small as it is. My theory is, that if someone gets to use my FOO code in their system, then that's great, because maybe their users will get a better FOO product than the original people could have provided.
On the other hand, some people like to assert in their licensing that since they provided the source code, they get to say that anyone who makes changes to it (and distributes that change) has to return their code free to the community. Unfortunately this occasionally prevents the use of that code in projects that are unable to provide the code that links with it for free for various reasons (Such as, the code was written under NDA to another company, and as such, the system provider cannot actually give that code away free, and as such, can't then use and change the "free" code that is available).
It could be (dangerously) generalized to depend on whether you're a "free everything" person, or a "improve everything" person, although I can see myself getting flamed for using such general terms. (:
Sorry for replying to myself, but my "line manager" (who is secretly an open source zealot) mentioned that it is quite likely that support contracts might be a hugely important spinoff.
Many geeks haven't considered support contracts as useful, but he (the manager) says he'd love to have that to back things up if I find myself unable to deal with something. (And he gets the CEO to support an open source project without making it look like a donation we don't get anything directly out of.)
Good question, and at most we can just speculate at this stage. One would hope that it would make FreeBSD easier to get. It might also provide more leverage to get hardware vendors to release driver specifications. There would also be more employed developers, which should be great, and lead to more drivers, better code, and so forth.
If you read the article, the merging of source of the two will end up with one, open-source, operating system, still called FreeBSD. In effect, BSD/OS will fall away, donating all the BSDI-owned code, with any code written by BSDI under an NDA (to a hardware vendor, for example)will still be available from BSD, Inc. as an addon (without source, since that is how NDAs generally work).
Slashdot Mirror
Well, firstly, you'll have to substantiate the importance of each part of your claim that the BSD's are a lot less popular, supported, and easy to learn, and that these are negative things.
... - their choice in operating system doesn't seem to indicate they'll be nice or nasty people. In my experience, people just "are", and there're many more things that form the person than simple OS choice.
Popularity is really not a good reason to choose something. Windows is a lot more popular than Linux. It has more users, more commercial programs, more programmers, certifications, and possibly books, training courses, and any number of other things. It doesn't make it any better, really, now does it? Yes, there are more Linux users than FreeBSD users. It doesn't really make that much of a difference.
As for support, is getting support for SuSE easy to get in a group that predominantly uses RedHat? Yes, some of the stuff is incredibly similar, but there are differences. The differences are on rough par with any differences you may find running FreeBSD, for example. As for commercial support, Wasabi Systems, BSDi, and a number of smaller consulting and support firms exist, reminiscent of Linux just two years ago. They'll grow, and BSDi is a good bet, and a reasonably well-known name amongst the older crowd of managers, so that's a bonus. I find the FreeBSD online support great, if that's a help. It's incredibly unusual for a help request to questions@FreeBSD.org not to be answered, and at least a few times correctly. (:
Easier to learn, again, is questionable. It's easy to learn something if you have, say, a friend next door that runs the same thing. At my university, FreeBSD became very popular (much more so than Linux) because the people who took the time to help out and organize things knew FreeBSD best, and suggested people try it. Those same people who used Linux before considered FreeBSD much easier to learn. The same may apply the other way around in your area. It isn't a matter of ease, but your surroundings. If you go it alone, like I pretty much did, it ends up being a personal matter (discussed below). As for documentation, I'd say it depends on the person. The FreeBSD Handbook helped me through most of my trials, but some find it too complicated, and some find it too abstract. Greg Lehey's book is good. There're FreeBSD courses offered by BSDi, amongst others. The NetBSD documentation is technically great and complete.
As for choosing between them, there are a few areas you have to discuss, really:
Firstly, why RedHat vs. SuSE? Why RedHat vs. Debian? Why foo and bar vs. fred and wilma? (obscure? me? never.) In this case, it's a matter of taste - some people just prefer something to another. It just fits their way of thinking and of doing things. And that requires trying everything until you can decide what fits your style. (Slackware's "do-it-yourself" vs. Debian's "we-have-a-package-for-everything!")
Secondly, we have to consider the actual product. The BSD product is integrated kernel and userland, with a full operating system as the product. Linux is a kernel, and RedHat, Debian, SuSE, and friends are the "full operating system" in the end, with subtle differences in between as to which programs are standard, where they live, how to configure them, versions, and so forth. "Linux 2.4.0ac1" is nowhere near sufficient to discuss a problem you may have - you need to know "RedHat 7.0" or "Debian 2.1" or something like that. You'll also need to know what modutils version, ppp version, and all sorts of other things. The BSDs have a slightly more integrated system, which may seem slightly inflexible to some, but which makes solving these things a lot easier - "FreeBSD 4.2", or "FreeBSD -CURRENT from 5 January" are pretty specific in what they contain.
Development models are slightly different. Linux has Linus being the only person with the ability to directly incorporate a change (which may be passed through a number of filters, such as Alan Cox, before Linus does the actual putting of the code in the source tarball), whereas with the BSD groups, there are a number of people who may make such changes in the kernel. Again, BSD is integrated userland and kernel, whereas the Linux distributions have different models for patches - Debian being the most community driven (roughly equivalent to the way the Open Source BSDs are run), and RedHat and SuSE having slightly more closed commercial processes.
Pure technical reasons are hard to find. Linux is ahead in some areas, the respective BSDs in their own. NetBSD's portability (not just kernel, but userland, and quality portable and correct coding models) is a god-send to many. While you can get "Linux" for Alpha, PPC, ARM, Intel, Dreamcast, and friends, it won't be the same Linux distribution, and will not be the same system, really (actually, Debian may come close). FreeBSD still has the occasional performance benefit, and still leads with some new features like kernel queues, accept filters, jail facility, and others. OpenBSD still has the most integrated crypto, followed only slightly further behind by FreeBSD and NetBSD, and also a well-auditted set of programs, and occasionally comes up with things like strlcpy and strlcat that are so obvious and yet missing.
You may consider the general community as a reason to choose something. You'll find your trolls in all of course. Some prefer the more "less talk, more code" and skill-driven attitude of NetBSD, or maybe the very weird culture that I enjoy in FreeBSD - a balanced "Let's try to do things right, and that means staying up to date, not falling behind but not living too close to the edge, copying ideas from other people's stuff, writing our own, and having fun while we're doing it" kind of attitude. I've had bad experiences with some online Linux communities, and with some online FreeBSD communities, and with some
I'm rambling I suppose, but my final suggestion is that unless you have almost no time, no motivation, and no interest in exploring something else; just try it. Learn as much as you can about their differences and similarities, advantages, disadvantages, get kicked from lame IRC channels, enjoy socialising with the nicer IRC or mailing list people, and have fun, increase your knowledge, and try to be an ambassador for whatever your choices may end up being.
Hi again Bruce,
Feel free to reject the statement that any number of people are "allowed to modify a Free Software product, either Linux or a BSD". I didn't say anything about the restrictions regarding the modifications of copies of the source code that is distributed in the official projects.
There are two possible meanings of (for example) "FreeBSD source code", depending on stress:
The _FreeBSD_ source code is "The source code to the FreeBSD operating system, that is used to generate FreeBSD install CDs, is available in the FreeBSD cvs tree". In this case, no, you can't modify the _FreeBSD_ source code, because you don't have commit privilege - the 233 committers in FreeBSD can, though.
Or, the FreeBSD _source_code_ is "The source code to the FreeBSD operating system, freely available for anyone to use, whose modification need not occur in the active FreeBSD project, and can indeed be used in other projects". In this case, you're totally free to modify the source code. However, you are not modifying the source code to the actual FreeBSD operating system, just a local copy. You can feel free to submit patches back if you like.
The same applies to Linux - you can play all you like with the code with the usual restrictions, but you need to get Linus to accept it if you want it to become part of the Linux kernel. You can modify your own copies of it, but you need his permission and intercession for you to indirectly modify the actual Linux kernel source code, as distributed in tarballs.
I can't believe you're talking about the second meaning, since it's obvious I'm not talking about it in my comment - I specifically talk about direct modification of the FreeBSD source in CVS, and the modification of the Linux kernel in the tarballs.
In the first case, and as you later continue, the core team or Linus do indeed have no way to compel people to make changes to the "offical" distribution formats of FreeBSD (cvs) or Linux (tarball), nor do they have any power to compel people not to make their changes in other formats, such as local copies or other projects (subject to licensing).
The thing is - if everyone disagreed with Linus, would it still be Linux? Linux is a registered trademark of Linus, and as such, if people run off and do other work, it is not the "official" Linux tarball, and it would need to be renamed, unless Linus gave his approval.
I'm not sure if Mr. Jolitz trademarked 386BSD, but he certainly would not have allowed the upstart NetBSD and FreeBSD teams to continue calling themselves "386BSD" - that was his baby. Hence the renaming. FreeBSD is a registered trademark too, so if the FreeBSD core (who hold it with permission of the trademark owner) were deemed too slow or old or whatever to do real work, the disillusioned could form another system, but not "FreeBSD".
I'm pretty sure you know all this, I just wanted for the slashdot readers to know that you were talking about something unrelated to my comment; your comment mostly discusses the advantages of open source development (freely available, or free-for-source-available-derivatives source) and the realities of open source projects (the inability to force cats^H^H^H^Hhackers to follow a given path).
Cheers,
Neil
Hi Bruce,
Obviously "gets hit by a bus" is a metaphor, and it is not to be taken seriously. It means "becomes unavailable", and I think you'd agree that if Linus did become unavailable, there'd be quite a bit of upheaval. Nothing fatal I imagine, but some upheaval - whoever takes over would also probably get quite a bit of "But Linus would have done this..." coming his or her way.
However, if one of the FreeBSD Core "became unavailable" because of other work, a change in direction, moving to another project, it wouldn't have nearly the effect. I imagine the most likely to cause the most upheaval is jkh. Whoever replaces the core member isn't likely to face "but foo would have done this..." arguments - core is about reaching concensus on issues that have escalated to that level - to settle disputes, add more committers, and very very occasionally decide policy. Everything else is based on rough concensus and working code in the project.
I don't believe you can say that the Linux kernel development is "at least as decentralized", in the sense that at least 233 people can directly modify the FreeBSD source code, including kernel. There is no need for them to get formal review and acceptance by a single person before it is possibly to go in - it is simply expected that review is sought, that the code is tested, and that you know what you're doing, and that you notify the maintainers or active worker on the subsystem you're working with. Architectural changes are monitored by various people (as I imagine it is with Linux too), and any questionable code is (optionally) backed out and discussed. People who repeatedly refuse to get review and discuss changes would theoretically get their bits removed, but there hasn't been a case in the time I've been following the project.
This is "decentralized", meaning ``withdrawn from a center or place of concentration; especially having power or function dispersed from a central to local authorities''. I'm not saying it's good or bad, but that's what it means - all changes are centralized through a point of concentration (Linus at the moment). The function of physically changing the code and generating the tarballs or whatever (since there's no versioning) falls with him.
One could theoretically extend that to FreeBSD in the fact that changes have to be made via cvs (or locally with cvs) on the FreeBSD cvs server, but that's a little technical. The function of changing the code is performed by the committers - the rest is automated and not concentrated through a single reviewer and changer.
Again, this is not a judgement, simply an observation. I don't think anyone in FreeBSD has the time and inclination to step up and manage every single change to the kernel, userland, documentation, or web site, so the functionally-decentralized distributed method probably suits FreeBSD.
Neil
Regular contributions are like more than three to five contributions ever. Or, rather, if it were defined that way, there would probably still be no regular female contributors.
Regular contributors become committers if they show they're able, and an existing committer asks if they're willing and they accept, and there is no veto by core (can't say I know of any recently).
Personally, I don't think there's any bias against women in the combined committer group, even if it's possible there is in one or a few individuals, and there certainly isn't any with me. It's all business - do the work, get the rewards, even if at first it's just recognition and praise. There is plenty of scope for new contributors, if you're having trouble looking for stuff to do, feel free to contact me. (nbm at FreeBSD.org)
It would be pretty impressive to come up with a female on a team out of a group of available nominees of all males.
The reason the nominees are all male is because there aren't any repeat female contributors. I see no reason for this to be due to any cost of contributing, nor to any adverse behaviour, unless it was entirely private and not on the regular mailing lists, and the female in question not making a public announcement about it, which I doubt is the case.
If that's not the case - if there is a cost to contributing, or there is negative behaviour that prevents you from contributing again, then kindly contact me directly (I'm nbm at FreeBSD.org), because I'd like to hear about it - bad reactions are not what anyone working on FreeBSD wants to happen to contributors.
If anyone (male or female) wishes to contribute to FreeBSD, it's very easy, and they can feel free to ask me via email if they have any questions, preferably after reading the relevant documentation.
Neil (nbm)
I think it all boiled down to concerns that the core team weren't doing enough, that they were doing too much, that they were too closed off from the rest of the committers, that there were some people not doing any work just lurking there, and that some new blood would probably help revitalise things.
The idea for the new "democratically elected" core is that it will be re-elected on a regular basis (I can't remember exactly, but something like one or two years), and that it will allow people to get time off, take a break, return to real work without the overhead of core, and allow new, fresh, and revitalised blood back onto core.
I'm a FreeBSD committer, and my opinion is that is good - some core team members have been hanging on just because they were afraid no new blood would replace them - earlier this year a core member left core so he could concentrate on "real hacking" instead, and wasn't replaced. The new blood means people more motivated and eager, and often with more time and new perspectives.
Nope, this is nothing like either.
The 225 or so committers that were around at the time of the nominations (there are 233 now, and yeah, I'm one of them) were allowed to vote for the core team.
Any of those 233 committers can commit changes, core is just there to perform some more complex functions, like settling disputes.
The leaving core members are still committers, they were just lucky to escape and get a bit of a holiday.
There can't be a woman on core, because core are a subset of committers, and there are no female committers.
That there is no female committers could imply two things - that there is a bias against women in FreeBSD core, or a lack of female contributors. It's most likely the second. There just aren't any returning female contributors, and committers are generally people who contribute over and again and show they know what they're doing by finding bugs and solutions in a few areas.
If any girls or women would like to get involved with FreeBSD, there are good entry spots in ports, documentation (in-depth kernel and user), filesystems, and for people who develop a good understanding of kernel internals (which, I admit I don't have, which is why I took the easy route and write documentation and ports).
The groups are occasionally a bit odd-ball, but avoid known trolls and get to know the more approachable people, and you're going to enjoy the community aspects (mailing lists, &c.) and the technical aspects (by getting someone you know to help review and commit your changes).
FreeBSD isn't particularly insular, there is increasingly younger (youngest committer is 16, I think) and newbie-er committers - the key is to contribute and not be aggressive and attacking if there is review and your solution is found wanting. We want your help, but we also want the correct solutions. If you think we're ignoring you, then send a reminder to your problem report every once in a while - chances are people are incredibly busy.
That applies only to redistribution, and in non-proprietary systems. This includes FreeBSD and most FreeBSD users.
If you wanted to use it for proprietary systems, you could approach Kirk for a relicense for yourself.
This is pretty standard. Did I miss your point?
No, quite obviously it wasn't intended for use in proprietary products without fee. If you wanted to use it in your proprietary product, you could pay for it. Your product will work with or without softupdates, so it's a matter of whether you're willing to contact Mr. Mckusick and see what sort of arrangement you could get.
I'm quite sure, and hope, Kirk was able to make some money out of it, which allows him to continue developing and contributing. From the beginning, it was intended to be released under BSDL later, but still allowed the open source BSDs to use it, and help develop, test, and contribute towards it. I think this is great.
I'm happy the BSDL allows this to happen - Kirk has worked on BSD for years, distributing the results under the BSDL, and other licenses might not have given him the opportunity to fund his development simply by developing. Of course the 'service and support' side could work, and does, but that one can make a living with updates, speedups, new algorithms, and redesigns is mostly the point.
I think this is the BSD way. The other license is simply not the BSD license, but definitely fits in with the BSD way, in the grand scheme of things.
I think you may have read the final sentence out of context.
I said that neither GPL nor BSD will allow you to force a company to pay you if you want to later sell them your code, because at the end of the day, with the BSD license, they can just take it, and with the GPL, you probably won't own the end copyright.
Thus, you can't 'sell out' and give it to the company with a non-GPL license without first getting the permission of the other contributors.
I'm sorry if my final sentence was ambiguous in this regard. I know very well that you can sell GPL binary products, on the condition you make the source available, and allow anyone who receives a copy to pass on that product under the GPL license (roughly paraphrased). I recently convinced a local (South African) company to do this.
They sold it a short while back to 'Digital River'. Yes, somebody probably should tell netsol, assuming netsol never lost the application ;)
When I read your topic, I thought you were going to say something about NetBSD, OpenBSD, and FreeBSD. After all, they're not fragmented, they're specialized. I mean, there used to be four of them, and there'll soon be three, and the projects share code and collaborate in joint BSD-wide projects like KAME, so if anything, they're unifying.
;)
I was disappointed to see you say "Linux can't truly fragment because of the nature of the GPL." with such authority. There's nothing in the GPL that prevents multiple GPL'd projects based on the Linux kernel code, after all.
However, I agree with you. Use what you enjoy and what works. Use different systems for different purposes. Use Linux if you want for your desktop, or your workstation, or your server, or your Palm. If you're inclined, go for a FreeBSD mega server like cdrom.com, and boast about your terabyte and a bit of traffic daily. OpenBSD'ify your router/firewall machine and show off your encrypted swap space, or NetBSD'ify that old Sparc and have people perve your UVM. Have fun, damnit!
What portal is this? cdrom.com? Walnut Creek doesn't own that. What financial situation is this? Where are you making this up from? Why is it that Walnut Creek have been making moves to spend more money on FreeBSD conventions, development, and publicity?
Walnut Creek believes in FreeBSD, and the bottom line is that FreeBSD is their most successful product. A merger which will make the product more popular can only help them. BSDI is quite happy to merge peacefully with Walnut Creek, as it doesn't want to alienate the FreeBSD community, especially Walnut Creek employees such as Jordan, Jim, Greg, Bill, and others, and they both genuinely gains a lot from the deal.
It is hard to believe a merger that places Jordan as the CTO, and places Mike Karels and David Greenment as co-architects, is a takeover.
(btw, I also bought my first Linux distribution from Walnut Creek, way back when, when there were only two or three distributions to chose from, and Slackware was the only real choice. This was also when FreeBSD was suffering under the lawsuit.)
The daemonnews article indicates that in the end, there'll be the joint code base, called FreeBSD, and any parts that are unable to be merged due to NDAs or other restrictions, will be available from the new company.
Therefore it seems quite likely you'll see FreeBSD commercial product, and not BSD/OS, which as a name (but not as a legacy) will not be used. To answer your question, it won't be a free vs. branded deal as Mozilla vs. Netscape, but will be a merger into FreeBSD, and some non-free commercial extensions to FreeBSD will be available from BSD, Inc.
While this is strictly off-topic, you're wrong when you say "if I were to release my code under the BSDL, a company can use it without even mentioning my name or giving me a penny". BSD-style licenses use the following:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Of course, if you're wanting to protect your code so that you can't not make money out of someone using it in a commercial product, neither GPL (after an extended period of time where people return patches to you) nor BSD are for you.
The patches you receive if you use the GPL are also under GPL, and copyright to the originator of the patch. The resulting work is GPL and shared by you and each contributor, and thus you'd need to get all the contributor's permissions before you can sell the end product.
Hopefully you'll read this, it would have been nicer to send you an email.
Some of your points above saying that 'qmail assumes' are simply what you assume that qmail assumes.
qmail does not assume that all users have entries in the passwd file, nor does it assumes all users have different UIDs, not in fact does it assume that each user has a home directory.
Just take a look at what vpopmail does to simply provide hints to qmail as to how to handle mail. All the stuff vpopmail does is easy to do manually, and all is easily understood from the available documentation. In fact, before I knew about vpopmail, I created a utility that did basically the exact same function in an hour or two.
Your other two points are true, although maybe not valid, and they're specific assumptions made by the code. You personally may think that a shared queue with multiple queue runners is the only way to work, but I would like to know whether you tried it qmail's way before deciding that was the way to do it. Admittedly, perhaps qmail isn't flexible in that area, but then again, perhaps qmail does it for a reason. djb is well-known for restricting people from shooting themselves in the foot, even if they might want to aim in the general direction of their foot, and are sure they won't hit it.
That said, I currently have no preference in MTAs between exim, postfix, and qmail, since they all seem to be very good products. I haven't had the time and inclination both at the same time to learn sendmail yet, but I'm sure I'll give it appropriate time before making any judgement.
From what I read in the Daemonnews article, in the end (which may take a while), there'll be only one source tree, still called FreeBSD. It will contain roughly the existing mish-mash of BSD licensed, GPL (gcc and numerous friends), and beerware licensed code.
The only code not scheduled for inclusion is that which was written by BSDI under NDA to another company, since they're under obligation by the NDA not to release that code.
This isn't necessarily a problem.
For some people, providing good code to all takers is what makes them feel happy and fulfilled, knowing that their code is going to benefit end-users of some system, where that system does not creating their own, possibly inferior, implementation. In the end, there'll be a massive collection of good code that anyone can use. Due to various reasons, many companies make their changes, use them for a few months for some competitive advantage, and contribute them back (Netgraph and other items from Whistle are a good example).
Other licenses, by restricting their uses to open source projects, may lead a system to reimplement something poorly, and their end-users will suffer for it. However, it does end up with a massive collection of good code, and may help non-open systems become open source, which provides all the benefits of open source to that whole system, instead of just the original code.
I'm a committee member of a Linux User Group (even though I don't use Linux much), and after last night's meeting (on OpenBSD) we were all at the pub, drinking, as all South African open-source people seem to do, and we started getting philosophical.
An interesting, although oft-mentioned, reason why we shouldn't start slating projects that do roughly the same job is to foster competition, to have a 'biodiversity'. A case in point is qmail vs. postfix in the "secure fast mailer" section (vs. exim vs. sendmail in general too).
While it's perl's motto that "There is more than one way" to do something, I think it is almost necessary that there should be, so that there can be users of differing ways, who can have friendly competition to improve their programs against each other, leading to two or more very good products.
(But then we were drinking, so maybe this requires more thinking *grin*)
There is only one thing to say about this:
It is up to the author to decide whether he wants everyone to gain from his changes, or whether he wants only free-software/open-source users to gain from it.
I personally prefer to have everyone gain from my code, as small as it is. My theory is, that if someone gets to use my FOO code in their system, then that's great, because maybe their users will get a better FOO product than the original people could have provided.
On the other hand, some people like to assert in their licensing that since they provided the source code, they get to say that anyone who makes changes to it (and distributes that change) has to return their code free to the community. Unfortunately this occasionally prevents the use of that code in projects that are unable to provide the code that links with it for free for various reasons (Such as, the code was written under NDA to another company, and as such, the system provider cannot actually give that code away free, and as such, can't then use and change the "free" code that is available).
It could be (dangerously) generalized to depend on whether you're a "free everything" person, or a "improve everything" person, although I can see myself getting flamed for using such general terms. (:
Sorry for replying to myself, but my "line manager" (who is secretly an open source zealot) mentioned that it is quite likely that support contracts might be a hugely important spinoff.
Many geeks haven't considered support contracts as useful, but he (the manager) says he'd love to have that to back things up if I find myself unable to deal with something. (And he gets the CEO to support an open source project without making it look like a donation we don't get anything directly out of.)
Good question, and at most we can just speculate at this stage. One would hope that it would make FreeBSD easier to get. It might also provide more leverage to get hardware vendors to release driver specifications. There would also be more employed developers, which should be great, and lead to more drivers, better code, and so forth.
If you read the article, the merging of source of the two will end up with one, open-source, operating system, still called FreeBSD. In effect, BSD/OS will fall away, donating all the BSDI-owned code, with any code written by BSDI under an NDA (to a hardware vendor, for example)will still be available from BSD, Inc. as an addon (without source, since that is how NDAs generally work).