From owner-freebsd-hackers Mon Dec 18 07:46:05 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA02430 for hackers-outgoing; Mon, 18 Dec 1995 07:46:05 -0800 (PST) Received: from etinc.com (et-gw.etinc.com [165.254.13.209]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA02425 for ; Mon, 18 Dec 1995 07:46:01 -0800 (PST) Received: from mail.etinc.com ([204.141.95.140]) by etinc.com (8.6.11/8.6.9) with SMTP id LAA21653 for ; Mon, 18 Dec 1995 11:05:54 -0500 Date: Mon, 18 Dec 1995 11:05:54 -0500 Message-Id: <199512181605.LAA21653@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (dennis) Subject: Re: FBSD support inc. Sender: owner-hackers@freebsd.org Precedence: bulk >> > > Basically it's one of those double-edged swords, like merging with >> > > NetBSD. A lot of really enticing benefits on the surface but a host >> > > of sticky problems to solve underneath. >> > >> > Like how do you deal with suddenly running on 12 more platforms for >> > nearly free. >> >> No, it's how do you deal with suddenly being forced to do release >> engineering for 12 platforms where one was formerly enough to drive >> the release engineer to early retirement? > >By making the administrative interfaces for all system identical, and >by data-driving those areas where it's not possible to resolve the >interface conflicts. > >CV: my more recent articles on logical device management in a devfs >framework. > >It's an engineering problem, not a management problem. note that this often leads to widespread mediocrity. db ---------------------------------------------------------------------------- Emerging Technologies, Inc. http://www.etinc.com Synchronous Communications Cards and Routers For Discriminating Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, and X.25