On Sat, Feb 15, 2014 at 2:34 PM, Daniel Campbell <li...@sporkbox.us> wrote: > On 02/15/2014 02:32 PM, Canek Peláez Valdés wrote: >> On Sat, Feb 15, 2014 at 2:23 PM, Mick <michaelkintz...@gmail.com> wrote: >>> On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: >>>> On Feb 15, 2014 11:02 AM, "Tanstaafl" <tansta...@libertytrek.org> wrote: >>>>> On 2014-02-15 10:16 AM, Tanstaafl <tansta...@libertytrek.org> wrote: >>>>>> Hi all, >>>>>> >>>>>> Not to revive a flame-fest against systemd, but... >>>>>> >>>>>> I'm sure some or most of you have already heard about this, but I found >>>>>> a really decent thread discussing this whole systemd thing. It is only >>>>>> really comparing systemd and upstart, as that was the debate going on in >>>>>> the debian TC, but it is a great read, and has actually made me rethink >>>>>> my blind objections to systemd a bit. >>>>> >>>>> One of which was logging: >>>>> >>>>> "20. Myth: systemd makes it impossible to run syslog. >>>>> >>>>> Not true, we carefully made sure when we introduced the journal that all >>>> >>>> data is also passed on to any syslog daemon running. In fact, if something >>>> changed, then only that syslog gets more complete data now than it got >>>> before, since we now cover early boot stuff as well as STDOUT/STDERR of any >>>> system service." >>>> >>>>> From: http://0pointer.de/blog/projects/the-biggest-myths.html >>>> >>>> Also, for those of you who don't follow Linux-related news, Ubuntu will >>>> also change to systemd in the future: >>>> >>>> http://www.markshuttleworth.com/archives/1316 >>>> >>>> And I *heard* that Slackware was also discussing the possibility, but since >>>> I don't follow Slackware at all, I don't know for sure. >>>> >>>> Anyway, distros not using systemd, and that they are not really small >>>> and/or niche, seem to be disappearing. The discussion that Tanstaafl posted >>>> is interesting since the arguments used by the four TC members are really >>>> focused on the technical merits of the proposed init systems. >>> >>> There was a thread sometime last year mentioning a slimmer/slicker and >>> obeying >>> to the *nix design principles initialisation system, but can't find it at >>> the >>> moment. Isn't that at all in the running? >> >> For Slackware, I have no idea. For Debian, no the only options were[1]: >> >> 1. sysvinit (status quo) >> 2. systemd >> 3. upstart >> 4. openrc (experimental) >> 5. One system on Linux, something else on non-linux >> 6. multiple >> >> It should also be noted that no one in the TC voted OpenRC above >> systemd AND upstart, and that while a couple voted systemd below >> everything else, it can be argued that it was a tactical vote. >> >> Regards. >> >> [1] https://wiki.debian.org/Debate/initsystem/ >> > > Why didn't they consider runit? It has parallel execution of daemons and > is backwards compatible with sysv. It has a few other mini-features as > well, iirc. I used for a little while before Arch pushed systemd on > their community and it was interesting.
Because nobody proposed it? And almost no one is using it? Which means; no high availability upstream, no momentum, and a small community, which translates in few real-live systems using it in production, and few testers and possible contributors... Besides, systemd and upstart are backwars compatible with sysv, and, well, nobody does parallel execution of daemons better than systemd, AFAICT. So, what advantages would runit bring to the table? Even OpenRC, now that it has (apparently) proper parallel execution support, would be a better choice. But you can read the discussion directly in [1], and see the different proposals in [2]. The discussion got nasty at some points, but I believe in general it was a very civil and intelligent debate. And the social/political "problems" you mentioned in your last mail were addressed as well. "Problems" in quotes because there are many of us who don't think they are problems at all, if they even exist. Regards. [1] https://lists.debian.org/debian-ctte/2014/02/threads.html [2] https://wiki.debian.org/Debate/initsystem/ -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
