From owner-freebsd-hackers Sun Apr 20 05:32:12 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA18434 for hackers-outgoing; Sun, 20 Apr 1997 05:32:12 -0700 (PDT) Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id FAA18413 for ; Sun, 20 Apr 1997 05:32:07 -0700 (PDT) Received: from wgold.demon.co.uk by wgold.demon.co.uk (NTMail 3.02.10) with ESMTP id xa001349 for ; Sun, 20 Apr 1997 12:41:35 +0100 Message-ID: <335A00EF.E5A@wgold.demon.co.uk> Date: Sun, 20 Apr 1997 12:41:35 +0100 From: James Mansion Organization: Westongold Ltd X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: "John S. Dyson" CC: freebsd-hackers@freebsd.org Subject: Re: Price of FreeBSD (was On Holy Wars...) References: <199704182341.SAA02032@dyson.iquest.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk John S. Dyson wrote: > Well -- I don't want an OS like NT. Microsoft has already done that, > and it shows *interesting* performance charactistics. Of course, I > admit that it would be very nice if we could maintain more consistant > interfaces, but frankly, I have used the latest version of Unixware MP > code also, and I don't like that either... It just doesn't work nicely. > > John I don't see why one would equate NT's performance characteristics with an improved level of modularity. For a start, you wouldn't need to have the same LRPC/'microkernel' (ha!) approach. It does seem that the kernel is suffering in the way that many successful software products suffer - they get rusty and hard to upgrade or maintain, because the coupling between 'modules' has grown. I would have though that some very minor performance hit would be worthwhile if you could make it much easier to: - add new file systems, preferably layered too - add support for native interpreted systems, such as Java - add new system calls - add new 'objects' that can be integrated into select() or poll() [in particular, threads and synchronisation primitives] (Oh yeah, and I absolutely refuse to write anything in C when I have C++ to hand, and I'd kinda appreciate an ability to reuse my Good Stuff) It would seem that we are in danger of 'proving' that a tightly coupled monolithic system can have much better performance characteristics than a modular one with 'traffic cops' (such as the HAL) in the middle. But then that's hardly news, nor would it be news that the upgrade and release process got steadily more painful as the complexity/entropy increased. Your choice, guys, and the product is at least successful at the moment, but it seems like (the top of?) a slippery slope to me. James