From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 27FF11381F3 for ; Sun, 26 May 2013 10:24:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 97137E0B22; Sun, 26 May 2013 10:23:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A0A6FE0B11 for ; Sun, 26 May 2013 10:23:55 +0000 (UTC) Received: from Nyx.local (dynamic-adsl-84-220-77-8.clienti.tiscali.it [84.220.77.8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 1EA1333DE0C for ; Sun, 26 May 2013 10:23:53 +0000 (UTC) Message-ID: <51A1E2B7.5020803@gentoo.org> Date: Sun, 26 May 2013 12:23:51 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:22.0) Gecko/20100101 Thunderbird/22.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Reusing systemd unit file format / forking systemd References: <20130526093755.42b62259@gentoo.org> In-Reply-To: <20130526093755.42b62259@gentoo.org> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 0da651ea-da3d-48d9-b703-172c3f815fc8 X-Archives-Hash: 925f9525361bf53a9e86223aad7e15c3 On 5/26/13 9:37 AM, Michał Górny wrote: > By the way, we should really keep the separation between systemd itself > and the unit files. I agree that systemd is not the best thing we could > have. But the unit file format is, er, good enough -- and has > the advantage of eventually taking a lot of work from our shoulders. Unit files had been considered when I started exploring the idea, sadly Joost shown me their limitation wouldn't make people life exactly happy. > Although some of the ideas (esp. wrt targets) are near to crazy > and awfully hard to understand, that's what we have and trying to do > something else is eventually going to make people's lives harder. Making better mousetraps usually works fine: as long you have generators that are good enough to get something working nobody would complain. > We should *really* work on supporting the unit files within OpenRC > (aside to init.d files). That's a way to at least: > > a) reuse the work that has been done upstream already (when it was > done), > > b) have common service names and startup behavior in all relevant > distros (which is really beneficial to the users). Can be done notwithstanding the rest. > Considering the design of OpenRC itself, it wouldn't be *that hard*. It is sort of simple. > Actually, a method similar to one used in oldnet would simply work. > That is, symlinking init.d files to a common 'systemd-wrapper' > executable which would parse the unit files. A compiler is an option as well, as said unit -> runscript should map fine. > On the completely different topic, I agree that systemd design is far > from the best and the way it's maintained is just bad. I was interested > in the past in creating an improved alternative using compatible file > format and libraries, while choosing a better design, improving > portability and keeping stuff less integrated. > > But the fact is -- I doubt it will make sense, much like the eudev > project. And it will take much more work, and give much less > appreciation. Having stand alone component would probably win you many friends and if the whole thing could work on something non-linux-latest-with-latest-glibc you'd have one less technical concern. > First of all, working on it will require a lot of work. Seeing how > large systemd become and how rapidly it is developing, establishing > a good alternative (even dropping such useless parts as the Journal) > will take at least twice that work. You make clean blueprints, get enough people agreeing with them and implement simple workalike for what you care about. For example logind seems to be the current fad. > The systemd haters will refuse the project because of its resemblance > to systemd. The systemd lovers will refuse it because of its > resemblance to systemd. And the OpenRC lovers will want to design it > to resemble OpenRC which is just pointless. Then the few remaining > people will find systemd 'good enough'. systemd haters, as you name them, could be split in few groups: - those that consider systemd a bad idea because it is a single item with many parts that would break horribly, if your idea is to make it less tightly coupled and with less parts many would consider helping. - those that consider systemd a bad idea because of the force feeding theme started with udev incorporation and continued with logind and such, again if you are creating alternatives the people would help gladly. - those that consider key part of systemd just wrong the limitation in the unit format or path activation as panacea, in that case you have to make clear the scope of your project, you might win few or lose some. > And even if there are a few people who will want to work on it, > and design a 'good systemd', they wouldn't get much appreciation. > Fedora definitely won't care for it. It would have to be really > definitely awesome for most Linux distros to even notice it. > And I doubt *BSD people would be interested in something external. Make it bsd and they would consider helping. > It is possible that systemd upstream will steal a few patches or ideas > from it. Yet they will never apply any of the really important changes, > so the project will have to be maintained indefinitely. The only hope > for it would be to win over systemd users which I doubt will happen. Or just make something useful, winning or losing is for the people using it. If it works and works fine people will use it. > So there's a lot of work, no fame or money in it, and most likely more > work being the only future. Anyone volunteering? Probably would be better sit down, figure out exactly what you want and see who has interest: E.g. Init-project - portable -> must work on non-linux and non-glibc more or less decently - modular -> loose coupling of functionality - robust -> the core functionality must not crash or remain inconsistent because of libdbus or such often occurring problems unrelated to - compatible -> should grok at least a good subset of systemd unit files. On a side note I really want to know in detail why you loathe openrc with this strength but we can discuss on irc. lu