Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 11869 invoked by uid 6000); 17 Mar 1999 03:05:45 -0000 Received: (qmail 11860 invoked from network); 17 Mar 1999 03:05:43 -0000 Received: from mail-out1.apple.com (17.254.0.52) by taz.hyperreal.org with SMTP; 17 Mar 1999 03:05:43 -0000 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id SAA43400 for ; Tue, 16 Mar 1999 18:55:48 -0800 Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (mailgate1.apple.com- SMTPRS 2.0.15) with ESMTP id for ; Tue, 16 Mar 1999 18:55:39 -0800 Received: from joliet-jake (joliet-jake.apple.com [17.202.40.140]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id SAA14144; Tue, 16 Mar 1999 18:55:38 -0800 Message-Id: <199903170255.SAA14144@scv2.apple.com> To: new-httpd@apache.org Subject: Re: Apple, "Darwin", Apache... Cc: new-httpd@apache.org Date: Tue, 16 Mar 1999 18:55:32 -0800 From: Wilfredo Sanchez X-Mailer: by Apple MailViewer (2.106) Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org | 1) MacOS X includes Apache 1.3. In fact it's billed as a major feature of | the product, with an installation and configuration wizard, etc. Those of | you following developments here will note that Fred Sanchez has been a | part of the development process here for quite a while; this is the fruit | of his work, as well as the work of others who helped integrate his | patches. I am, by the way, quite grateful that the Apache team has been so receptive to the Rhapsody/Mac OS X Server work I've been doing. It was a key part of why we were able to sell the open source idea to the executive team. | There may be some confusion in the press, as this open-sourced platform, | named "Darwin", was said to include Apache; and I haven't gone through the | steps of downloading it to see what's actually included, if the stock | Apache is in there, etc. Stock Apache is there; it's the same Apache code I built into Mac OS X Server. There are minor make tweaks from 1.3.4-dist which I made known before. | My guess is that there's some "glue" code in | there, for example whatever administrative scripts Apple wrote for its | web-based configuration tools. If Apache is included, it's probably not | the intent to fork the code from our code base here, as that would be | inconsistant with Apple's previous efforts. Anyways, I wanted to head off | concern about this ahead of time, and invite Fred to add any comments to | this if I've missed something. I tried to address this point on the darwin web page (www.publicsource.apple.com): In general, feature additions and bug fixes which are not specific to or needed by the Darwin platform should be sent to the upstream source; it is an explicit goal that the diffs between this code and the original code be kept at a minimum, as we don't intend to compete with other Open Source initiatives. For "Third Party Projects", such as Apache, we fully intend to have the primary caretakers of the code be the upstream provider of the code, and we aren't tacking our license onto such code. We do distribute a source tree which is known to build for the platform, etc. This is something I've been pushing here as a selling point for using all this open source code: don't do work someone else has covered. Help them out, sure. Duplicate effort, no. Same rules for Darwin. | 1) The appleshare and HFS code will be picked up and ported widely to the | other OS's. AppleShare isn't there. AppleTalk (the protocol) is. HFS+ support on xBSD and Linux would be swell. NetInfo client and server support on these OS's would also be cool. | 2) Someone will probably be able to stick GNOME or KDE on top of Darwin | pretty easily, thus opening up the potential for Darwin to be touched | by and enhanced by those with a religious aversion to paying for | software. I'm kinda hoping that Darwin + X11 gives GNUStep a kick. | 3) Someone else will probably be able to put the for-sale bits on top of a | Linux PPC base - it'll be interesting to see what that enables or | changes. I think that's kinda hard. They'll need to implement the Mach APIs, for starters. -Fred