From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 20 16:57:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCF321065677 for ; Wed, 20 Jun 2012 16:57:19 +0000 (UTC) (envelope-from luke@foolishgames.com) Received: from stargazer.midnightbsd.org (cl-218.chi-02.us.sixxs.net [IPv6:2001:4978:f:d9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3688FC0A for ; Wed, 20 Jun 2012 16:57:19 +0000 (UTC) Received: from [10.39.1.67] (mobile-166-137-083-052.mycingular.net [166.137.83.52] (may be forged)) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.5/8.14.5) with ESMTP id q5KGvGQo022184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jun 2012 12:57:18 -0400 (EDT) (envelope-from luke@foolishgames.com) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.4 at stargazer.midnightbsd.org X-Authentication-Warning: stargazer.midnightbsd.org: Host mobile-166-137-083-052.mycingular.net [166.137.83.52] (may be forged) claimed to be [10.39.1.67] References: <4FDF6177.5050608@unsane.co.uk> <4FDF6586.9060501@gentoo.org> <4FDFB166.2040709@FreeBSD.org> <4FDFB44D.9090308@gentoo.org> <4FE0ADCD.9010109@FreeBSD.org> <4FE0C123.8030301@gentoo.org> <4FE0F773.1080403@gentoo.org> <4FE100F9.2050009@funtoo.org> <20120620073920.GA5300@lonesome.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Lucas Holt Date: Wed, 20 Jun 2012 12:57:11 -0400 To: Daniel Robbins Cc: Wojciech Puchar , "freebsd-hackers@freebsd.org" Subject: Re: Replacing rc(8) (Was: FreeBSD Boot Times) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 16:57:20 -0000 On Jun 20, 2012, at 11:43 AM, Daniel Robbins wrote: > On Wed, Jun 20, 2012 at 9:28 AM, Wojciech Puchar > wrote: >>=20 >> Whatever benefits are, and for sure they are think of this: >>=20 >> 1) can it be compatible with 20000 ports already made for FreeBSD, where >> many of them install rc.d scripts in CURRENT format. >=20 > OK. This will clearly be needed, and shouldn't take too much time to > investigate. >=20 >> 2) is the problem 1 worth of slight improvement over already good, but >> certainly not perfect rc.d subsystem. >=20 > Yes, clearly OpenRC will need to offer significant improvements to > make it worthwhile to justify migrating over to it. >=20 > So let me know if you have any ideas for anything that would be > considered more than just a slight improvement, that would make you go > "OK, now it's seriously worth considering OpenRC as this is more than > just a nominal improvement in functionality." >=20 >> If someone would like to make new ports subsystem from scratch then it wo= uld >> be great. Would you like to ? ;) >=20 > I know you are joking, but in all seriousness, this is another area of > potential collaboration, because at some point I will be looking to > significantly improve Portage. And Gentoo and Funtoo have the same > challenging of upgrading ports systems -- there's so much stuff that > already uses our *existing* ports system that needs to be moved over. > There are creative solutions to this problem that I have found. So > it's a good idea to stay in touch :) >=20 >> when i would have million dollars handy call me and find these 20 people ;= ) >=20 > I have some ideas that should make it possible to transition ports > systems with less effort than this. But this isn't related to the > current thread :) >=20 For one thing, it depends on how different the new ports system is. We migra= ted MidnightBSD's mports in about a year for roughly 2000 ports with four pe= ople, but that was a refactor of FreeBSD ports rather than a whole new syste= m. The biggest problems were related to installing into a fake root as many p= lists were terribly bad. There are classes of problems like perl ports or g= nu autotools which tend to have common solutions. In our case, we wanted so= me compatibility due to the limited resources we had. Looking at modern Fre= eBSD, most of the problems have been solved by automated testing and hard wo= rk by the ports people. I personally think the problem now is packages. They= must be updated and the tools must be better to upgrade. I know several fol= ks are working on it and both midnightbsd and pc-bsd have solutions to look a= t there as well.=20 As far as rc goes, I think it is slow for some setups and reasonable for oth= ers. Kernel boot time needs improvement as well as loading kernel modules. T= here isn't a one size fits all fix for the boot time problem. Maybe a bunch= of little improvements would help the most folks. rcorder caching or someth= ing ? Luke=