Date: Sat, 18 Mar 1995 00:22:45 -0800 From: "Justin T. Gibbs" <gibbs@estienne.CS.Berkeley.EDU> To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> Cc: gibbs@freefall.cdrom.com, hackers@freefall.cdrom.com Subject: Re: SVNET Meeting? Message-ID: <199503180822.AAA18883@estienne.cs.berkeley.edu> In-Reply-To: Your message of "Fri, 17 Mar 1995 20:34:31 PST." <10952.795501271@freefall.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>So, I imagine you'll be getting back from this sometime soon after the >time of this message (sorry I could not attend, but I am just about >to fall over right now! :-( ) > >How did it go? > > Jordan It was wednesday. It went okay although I got so turned getting down there that I was 30 minutes late :-(. Here are the highlights. J.T. was extremely fair in representing the weeknesses and strengths of both systems during the portion of his presentation I saw. His main points about NetBSD were: 1) Has passed standards tests (I forgot his list). 2) The strength of maintaining many ports is that it uncovers many bugs in the system. 3) Linux and IBCS2 compatibility. Supposedly they got the WP demo to work just that morning. 4) GPL clean kernel. 5) Sparc, Alpha, Mac, HP3/400, i386, etc ports. 6) VM86 system call and a full dos emulator coming RSN. During his Q&A section, the type of crowd there became aparent. Most of the audience had hardware other than Intel at their home or office (questions about HP400, Sparc, and Dec 3100 support). He only realized who I when the following questions came up: 1) I have a PC. What kind of SCSI controller/Video card should I buy to be NetBSD compatible. The first words from his mouth were anti Adaptec. Now I'm not the greatest Adaptec fan, but I don't like their policy blown into something it isn't. He basically said that they would not give enough information out to program the cards without an NDA. Actually, they won't give out the source code to their firmware or the exact interface to the firmware the BIOS loads by default, but they will give you all the information you want to help you write your own firmware (what the FreeBSD/Linux driver does). I made this clarification and pointed out that FreeBSD has support for the newer Adaptec cards. This led to a brief explanation of the NetBSD practice of not supplying any pieces of GPL code that can even optionaly be linked into the kernel. The sequencer code we use in the FreeBSD driver is GPLd. 2) What is the status of LFS and are there any plans to support it in the future. J.T's answer was a solid no, "If someone provides us with code that fixes it, we'll be happy to incorperate it." I added to this that I strongly believe in the merits of LFS and that it will have a presense in FreeBSD as soon as I get more time on my hands. I also pointed out that LFS places very different requirments on the VM system than FFS, and that at best, the current LFS implementation is a good example of the CS philosophy of "throw the first one away". If you've ever looked at the code, I think you might agree. ;-) Before LFS can become practical, some serious planning (some of which John and I have already done) will be needed to make it perform up to its theoretical max. 3) There has been some discussion in the NetBSD mailing lists about NetBSD's VM system, the fixed size buffer cache, and whether we're best utilizing availible memory. Is there any research being done in this area? J.T. was very honest in pointing to FreeBSDs totally revamped VM system as a new aproach to these problems. He said that NetBSD currently lacks the resources to address this problem, but also stated that not everyone agreed that the FreeBSD aproach was the the best one to take. This was when I started my presentation. The topics I covered were: the new VM system and other kernel performance improvments (John and David's work), better install tools, work on IBCS2 and Linux binary support, and our goal of stability for this release. I was more prepared to talk about most of the kernel work that we've done, but the questions I got were more basic: 1) Why are there two groups? What are the philosophical differences that keep the two groups apart? If one group has some cool feature working, will the other incorperate it? This led to a talk about the diverging kernel interfaces of the two groups and the fact that the reason there are two groups is mainly a control issue. My response to code exchange was that it is common, but that with different opinions on how to implement features, it didn't happen every time. My example was Linux binary compatibility and how FreeBSD isn't going to feel presured into adapting the same strategy as NetBSD just for expedience. 2) Why is FreeBSD i386 specific? "The hardware is cheap, readily availible, and there are enough bugs in 4.4 to be worked out even with concentrating on only one platform to keep us busy. This is not to say that ports to other platforms will not occur. In fact, work on a Sparc port is underway." 3) Why is the GPL so "evil"? "The requirement to distribute source code to 'anyone' who asks for it for up to 3 years just for starters. The goal of both groups is to provide an unencumbered system that even a comercial organization could sell binary distributions of. Even though the GPL is restrictive, FreeBSD differs from NetBSD in distributing GPLd portions of the kernel. The main reason is that features, like the 2x4x Adaptec driver, would not be availible otherwise, and in our opinion, so long as the GPLd portions are clearly marked and easily removed, it is foolish to keep these features out of the hands of our end users." After the meeting, I was aproached by a few FreeBSD users all of which are still running 1.1.5. The point they stressed again and again to me is that if 2.1 is not as stable as 1.1.5, they will have to look to other operating systems. I assured them, and I hope that the rest of core agrees, that stability, even if it means postponing the release, will be our primary goal. Anyway, that's "the way it was". Very interesting meeting on the whole. -- Justin T. Gibbs ============================================== TCS Instructional Group - Programmer/Analyst 1 Cory | Po | Danube | Volga | Parker | Torus ==============================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503180822.AAA18883>