From owner-freebsd-current@FreeBSD.ORG Tue Feb 25 08:09:36 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A99EE785 for ; Tue, 25 Feb 2014 08:09:36 +0000 (UTC) Received: from smtp-sofia.digsys.bg (smtp-sofia.digsys.bg [193.68.21.123]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 31545192E for ; Tue, 25 Feb 2014 08:09:35 +0000 (UTC) Received: from dcave.digsys.bg (dcave.digsys.bg [193.68.6.1]) (authenticated bits=0) by smtp-sofia.digsys.bg (8.14.6/8.14.6) with ESMTP id s1P89WLs076205 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Feb 2014 10:09:32 +0200 (EET) (envelope-from daniel@digsys.bg) Message-ID: <530C4FBC.7000802@digsys.bg> Date: Tue, 25 Feb 2014 10:09:32 +0200 From: Daniel Kalchev User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Import of DragonFly Mail Agent References: <20140223211155.GS1699@ithaqua.etoilebsd.net> <942222.61849.bm@smtp118.sbc.mail.gq1.yahoo.com> <530B5DA7.1050902@digsys.bg> <1393264180.28812.87188993.20F1344F@webmail.messagingengine.com> In-Reply-To: <1393264180.28812.87188993.20F1344F@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:09:36 -0000 On 24.02.14 19:49, Mark Felder wrote: >> We can strip pieces of FreeBSD off and end up with an kernel. Or we >> could keep the system very much usable out of the box. >> > Imagine a world where everything in FreeBSD is a package and we have a > working "PROVIDES" framework. Upon installation you can choose the > software that "provides" the MTA role. Same for DNS, NTP, database, > webserver... That would be a great accomplishment along with a framework > to create a master install image utilizing the options/packages you > desire. I think this type of thing is definitely plausible if we keep > moving forward. My personal opinion remains that complex software is > better served/secured/maintained when it is handled in ports not in > base. > While I agree with all you say, it is worth noting that bind/sendmail/ntp have been very compatible with FreeBSD precisely because of their integration with the base system. What we risk with "everything is a port" concept is that we live in a world that there is a lot of software to chose from, but from time to time, the software happens to be incompatible with FreeBSD in one way, or another. Another risk is the confusion of too much choice. There is a fine balance to be found here. Daniel