Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!zombie.ncsc.mil!news.mathworks.com!gatech!howland.reston.ans.net!agate!violet.berkeley.edu!jkh From: jkh@violet.berkeley.edu (Jordan K. Hubbard) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: The Future of FreeBSD... Date: 20 Jul 1995 15:31:04 GMT Organization: University of California, Berkeley Lines: 95 Message-ID: <3ulsro$ssl@agate.berkeley.edu> References: <3uktse$d9c@hal.nt.tuwien.ac.at> NNTP-Posting-Host: violet.berkeley.edu In article <3uktse$d9c@hal.nt.tuwien.ac.at>, Martin Birgmeier <martin@hal.nt.tuwien.ac.at> wrote: >being one of them (i.e. FreeBSD aficionado), during the past year or >so I got the very strong impression that the FreeBSD effort is most >likely going to die, for at least two reasons: I don't see either of these arguments as being very on-target.. Sure, Linux has a large developer/user base, but then so does SCO and you don't see people crying that SCO is going to destroy FreeBSD any day now. There is plenty of room for BOTH systems, in reality, and if anything I think Linux has *helped* FreeBSD by drawing more attention to the viability of free software. There was a time not too long ago when commercial interests wouldn't touch free software with a stick, but the FSF and Linux have gone a fair way towards changing that and this can't be anything but a good thing. >2) FreeBSD developers are more or less reinventing the wheel, and even > that wheel is basically from the stone-age of OSs as well... I > understand that there is going a large amount of effort into making > FreeBSD an advanced Unix system (unified buffer cache comes to mind), > but basically it's still the same old story. VM/CMS is from the stone age. RSTS is from the stone age. 4.4 Lite is hardly from the stone age, my friend! Progress on the BSD code base still continues at a very healthy pace and sometimes you WANT code that's had a chance to mature. The fact that our networking code has had almost 10 years to stabilise and work in MANY different strange and stressful networking scenarios has in fact helped us considerably. I don't buy this point. >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). We talk to Johannes fairly frequently and support his project, but do you really think that all of our ISP "customers" would suddently jump up and down over something that wasn't even of obvious utility to them? I think not. You're clearly of an academic mindset where "newer and cooler" is equivalent to "better", and that's just not the case in the commercial world. In fact, many members of the project would LEAVE were we to suddenly jump on the Mach bandwagon since universal agreement on microkernel technology is hardly here, and there are in fact a number of detractors alive and well in the UNIX camp. >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. HOW would it give it an edge? You're long on rhetoric and short on details here.. I see no substantive argument as to WHY Lites will save our collective butts and bring happiness to our user base, and I won't accept "because it's new and it's the way forward" as an argument. We need more concrete examples of what a new technology will buy us before we sign on and take the significant hit in testing and re-certifying our OS for stability, and I think our users wouldn't have it any other way. Like I said, I do support Johannes and his project as it makes a good *alternative* for those with more experimental mindsets and alternatives are good in general, but a mainstream technology? You'll need to be significantly more convincing.. >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. I don't see this at all. Have you *looked* at the interdependencies within the source tree? What good would it do to get gcc without any of its include files? Or all the file munging tools without the libraries they depend on? >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. We're going to do that someday, yes, but we're waiting for the compiler tools to mature a little where ELF is concerned. >4) Try to reach an agreement with the NetBSD developers on as common a > source tree as possible, such that mutual fertilization can be > achieved more easily. In my opinion it would be best to really have > a physically common tree, with mirrors to the development groups. We do this as best we can now and any further commonality will simply have to wait until more people are working in common with both groups. You can lead a horse to water, but shoving his head under isn't a good way of making him drink. All things in good time.. I don't mean to quash what was probably a well-intended set of points, but if you're going to preface a set of suggestions with "this is what I think FreeBSD needs to do or it's dead" then you'd better put a LOT more thought into those suggestions and perhaps try to be a little less naive about the realities of this market. Jordan