Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!news.maxwell.syr.edu!newsfeed.direct.ca!nntp.portal.ca!cynic.portal.ca!not-for-mail From: cjs@cynic.portal.ca (Curt Sampson) Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc,comp.unix.bsd.openbsd.misc,comp.unix.bsd.misc,comp.unix.bsd.386bsd.misc Subject: Re: *BSD Unification? Date: 6 Apr 1997 10:08:28 -0700 Organization: Internet Portal Services, Inc. Lines: 92 Message-ID: <5i8lac$9r2@cynic.portal.ca> References: <860029226.1885@dejanews.com> NNTP-Posting-Host: cynic.portal.ca Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38577 comp.unix.bsd.netbsd.misc:5760 comp.unix.bsd.openbsd.misc:54 comp.unix.bsd.misc:2946 comp.unix.bsd.386bsd.misc:1219 In article <860029226.1885@dejanews.com>, <prw@cyberwar.com> wrote: > I have heard people say that the presence of multiple BSD >systems is comparable to the fact that there are multiple Linux >distributions. I disagree wholeheartedly with this notion. The Linux >distributions share the same kernel, while with BSD there are now >three separate teams working on three separate kernels. Is this not a >waste of resources? You make it sound like the kernel is the hard part, and putting together the userland after that is easy. That's certainly not the case; just putting together all the programs for a distribution, much less testing and debugging them, is an enormous amount of work. Now isn't having nine (or however many it is) different organisations doing this a `waste of resources'? And even in the kernel, we see things like to completely separate and independently maintained drivers for the DEC Tulip Ethernet chip. Is this not just as much a `waste of resources'? Having all of these different distributions makes life difficult for commerical software developers as well. There have been three NetBSD kernel releases in the last couple of years (1.1, 1.2, 1.1.2). FreeBSD has had perhaps a couple more. How many different kernels have been released in the last couple of years in Linux distributions? And the same goes for userland software, of course. You can't ever really be sure which version of bash or awk you're going to get when your software is running on a `Linux' system. This leads to statements like the following one in the ReadMe file for Adobe Acrobat reader: : Adobe develops and tests this Reader on the Yggdrasil 1.2.13 Fall 95 release : configuration (1.2.13 Linux kernel, XFree86 3.1.2 and the following system : libraries: libc 5.0.9, libm 5.0, libdl 1.7.10). However, we believe and have : heard from users that it runs well on the following system configurations: : : Redhat Linux 3.0.3 and kernel 2.0 : Slackware and the 1.2.13 kernel : XFree86 3.1.2G X server : XFree86 3.1.2 server, using S3 Trio64 hardware : Linux 2.0.4 ELF system : Linux 2.0.21 : XFree86 3.1.2G (beta; X11R6.1) : libc 5.3.12 : ld.so 1.7.14 : Debian 1.1 with kernel upgraded to 2.0.21 : Slackware 3.1 : 2.0.18 and a hacked-up Slackware 3.0 install : Red Hat 3.0.3 Picasso system (Linux 1.2.13 kernel) Deciding which version of the dozens of versions of the kernel and the system libraries you want to run is hardly any more friendly than deciding which *BSD system you want to run! And how much work has been duplicated between the Slackware and Debian and Red Hat and Yggdrasil folks? How many times has a sophisticated package manager been written? How many times has an installation procedure been written? How many man-hours have been lost testing these duplicated installation procedures? I'm not taking the Gnu/Linux crowd to task for this, and I hope nobody takes this as a flame. But a close look reveals that the Gnu/Linux folks duplicate effort very frequently and at every level. That Gnu/Linux is much more popular than BSD is due to other factors. Now all that aside, I'd also like to point out, in I hope a non-inflamatory way, that asking the current developers to champion merge projects is probably not going to get anywhere. It's not as if the *BSD developers are all sitting around saying to themselves `What shall I do? I've nothing to work on.' If someone wanted to actually start doing the legwork to see what could be merged, ran around talking to the folks in the various camps, arranged for a common CVS repository, and actually started merging code, we'd see some progress. But I've seen very few people with a real interest in doing this. Most of the really pro-merge crowd seem content to post to the newsgroups every once in a while asking why we shouldn't merge. Please don't take that as a flame, but as a guide to what you can do to help merge things. Oh, and if you don't have the programming skills to do that part of the merge, there are plenty of other things you could work on. Expanding the FreeBSD handbook to apply to NetBSD as well would be an excellent start, and would probably bring a lot of the small incompatabilities to light, where many could be fixed. cjs -- Curt Sampson cjs@portal.ca Info at http://www.portal.ca/ Internet Portal Services, Inc. Through infinite myst, software reverberates Vancouver, BC (604) 257-9400 In code possess'd of invisible folly.