Return to BSD News archive
#! rnews 2536 sserve.cc.adfa.oz.au Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!newsfeed.internetmci.com!news.mathworks.com!news.kei.com!news.ssd.intel.com!ornews.intel.com!news.jf.intel.com!haertel From: haertel@ichips.intel.com (Mike Haertel) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: The Future of FreeBSD... Date: 20 Jul 1995 17:40:03 GMT Organization: Intel Corporation, Hillsboro, Oregon, USA Lines: 39 Message-ID: <3um4dj$6en@news.jf.intel.com> References: <3uktse$d9c@hal.nt.tuwien.ac.at> NNTP-Posting-Host: pdx404.intel.com In article <3uktse$d9c@hal.nt.tuwien.ac.at>, Martin Birgmeier <martin@hal.nt.tuwien.ac.at> wrote: >1) In order to separate FreeBSD from the rest of the free Unix efforts, > merge with Lites as developed by Johannes Helander *as soon as > possible* (though I admit I don't know how possible this is at all, > comparing with the state of affairs regarding the two BSD camps). > >This, in my opinion, would give FreeBSD the necessary edge over its >competitors to stay alive and healthy; it might also help Lites to >gain a wider user base. I think this is a bad idea. Mach is SLOW. As of right now, there is only one reason I can imagine to do this: to support multiprocessors. But, better (more efficient) to support them with a conventional kernel. So I think a better idea would be: rework the kernel to support multiprocessors, and maybe kernel multithreading. (When you've got one, it's pretty easy to do the other.) In a few years I'd like to be running FreeBSD on my 4-processor P6 box... :-) >2) Reorganize the sup tree such that it is not ordered by subdirectories, > but rather by functionality groups. With the current setup, you > basically can fetch either everything or nothing, except maybe for > the games and ports sections. Bad idea. IMHO one of the big problems with the Linux community is the chaos involved in getting the sources. It's partially caused by the "package" mentality associated with the major Linux distributions, where you pick and choose what to install. I really like the FreeBSD all-or-nothing approach in the binaries, and I think it is similarly appropriate to apply that to the sources. >3) Introduce the ELF binaries format. I don't know much about it, but it > seems to be the way of the future for various reasons. Your best suggestion so far. Especially if FreeBSD supports binary compatibility with Linux and/or SVR4, it should thrive even if it's not the most popular system.