Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!yarrina.connect.com.au!munnari.OZ.AU!news.hawaii.edu!ames!agate!howland.reston.ans.net!newsfeed.internetmci.com!news.kei.com!nntp.coast.net!news00.sunet.se!sunic!news99.sunet.se!news.uni-c.dk!kroete2!not-for-mail From: erik@kroete2.freinet.de (Erik Corry) Newsgroups: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc,comp.unix.advocacy,comp.unix.misc Subject: Re: Linux vs FreeBSD Followup-To: comp.os.linux.advocacy,comp.unix.bsd.freebsd.misc,comp.unix.advocacy,comp.unix.misc Date: Tue, 5 Dec 1995 02:30:07 GMT Organization: Home Lines: 61 Sender: news@kroete2.freinet.de (news) Message-ID: <DJ3DM7.n0L@kroete2.freinet.de> References: <489kuu$rbo@pelican.cs.ucla.edu> <49o2n2$t4e@daffy.anetsrvcs.uwrf.edu> <49osrd$ptg@times.tfs.com> <49rm0g$o8o@daffy.anetsrvcs.uwrf.edu> <DJ2IBL.71t@nntpa.cb.att.com> NNTP-Posting-Host: arhppp14.uni-c.dk X-Newsreader: TIN [UNIX 1.3 950515BETA PL0] Xref: euryale.cc.adfa.oz.au comp.os.linux.advocacy:29870 comp.unix.bsd.freebsd.misc:10137 comp.unix.advocacy:11991 comp.unix.misc:19976 John S. Dyson (dyson@inuxs.inh.att.com) wrote: : So then finally, someone who uses Linux is admitting that the Linux : kernel development at least is not open and free. Sounds like a monarchy : to me. (FreeBSD is somewhere between monarchy and anarchy :-)), and : the FreeBSD kernel is unencumbered with GPL. Monarchy? Benevolent dictatorship! :-) Linux development is based on patch files. Anyone who has a kernel enhancement that has not (yet) been accepted by Linus maintains a set of patches, which have to be kept up to date as new versions of the kernel are released. Inevitably, if Linus does not accept the patches, they will probably die out as the effort to keep them up to date becomes too large. Until now Linus seems to have shown very good judgement in this, so most people don't regard it as a problem. Of course the internal layers in the kernel are used to minimise the interaction between patches as far as possible. Again, there is nothing stopping someone bringing in the FreeBSD model if they prefer, but personally I find the multiplicity of BSD versions (FreeBSD, NetBSD, BSDI, and now OpenBSD) a sign that your way of doing things isn't without its problems, either. This must represent a similar duplication of effort to the effort that goes into maintaining Linux patch files. At least the patch files and new architectures are merged into Linux eventually: is there an effort to reunify NetBSD and FreeBSD? My impression is that the splits have mostly been caused by ego-clashes. In the Linux community, we have so much respect for Linus that such a clash has never been able to split the kernel. You say the FreeBSD kernel is 'unencumbered with the GPL'. The GPL may be an encumberance to you, but to Linux/GNU developers, the BSD license is also an encumberance: which means you can't use BSD code in the Linux kernel or in a GPL'ed application. The other major encumberance of the GPL is that noone can 'do a BSDI' with Linux, i.e. copy the code and create a private version. That's not perceived as a disadvantage by most Linux developers, in fact for many it is a prerequisite. For example, Alan Cox has stated that he does GPL development for free, but wants to be paid for development under other licenses. The original Linux license, before the GPL was even more restrictive. It was more like the Minix license, which clearly hindered the spread of Minix. If Minix had been under the GPL or the BSD license, perhaps the free Unix movement(s) would have happened much earlier. The encumberance of the GPL hasn't stopped Caldera from making a very nice-looking commercial package including Netware client support, native Wordperfect, Zmail, spreadsheet and a nice desktop app, and selling it as a complete Internet OS+program suite. And patches have flowed back from Caldera in a way that I don't imagine BSDI has done (corrections welcome). I don't want to be seen as bashing the BSDs: there's probably room for both. -- Erik Corry ehcorry@inet.uni-c.dk