| 1 |
On 02/15/2014 02:32 PM, Canek Peláez Valdés wrote: |
| 2 |
> On Sat, Feb 15, 2014 at 2:23 PM, Mick <michaelkintzios@×××××.com> wrote: |
| 3 |
>> On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: |
| 4 |
>>> On Feb 15, 2014 11:02 AM, "Tanstaafl" <tanstaafl@×××××××××××.org> wrote: |
| 5 |
>>>> On 2014-02-15 10:16 AM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
| 6 |
>>>>> Hi all, |
| 7 |
>>>>> |
| 8 |
>>>>> Not to revive a flame-fest against systemd, but... |
| 9 |
>>>>> |
| 10 |
>>>>> I'm sure some or most of you have already heard about this, but I found |
| 11 |
>>>>> a really decent thread discussing this whole systemd thing. It is only |
| 12 |
>>>>> really comparing systemd and upstart, as that was the debate going on in |
| 13 |
>>>>> the debian TC, but it is a great read, and has actually made me rethink |
| 14 |
>>>>> my blind objections to systemd a bit. |
| 15 |
>>>> |
| 16 |
>>>> One of which was logging: |
| 17 |
>>>> |
| 18 |
>>>> "20. Myth: systemd makes it impossible to run syslog. |
| 19 |
>>>> |
| 20 |
>>>> Not true, we carefully made sure when we introduced the journal that all |
| 21 |
>>> |
| 22 |
>>> data is also passed on to any syslog daemon running. In fact, if something |
| 23 |
>>> changed, then only that syslog gets more complete data now than it got |
| 24 |
>>> before, since we now cover early boot stuff as well as STDOUT/STDERR of any |
| 25 |
>>> system service." |
| 26 |
>>> |
| 27 |
>>>> From: http://0pointer.de/blog/projects/the-biggest-myths.html |
| 28 |
>>> |
| 29 |
>>> Also, for those of you who don't follow Linux-related news, Ubuntu will |
| 30 |
>>> also change to systemd in the future: |
| 31 |
>>> |
| 32 |
>>> http://www.markshuttleworth.com/archives/1316 |
| 33 |
>>> |
| 34 |
>>> And I *heard* that Slackware was also discussing the possibility, but since |
| 35 |
>>> I don't follow Slackware at all, I don't know for sure. |
| 36 |
>>> |
| 37 |
>>> Anyway, distros not using systemd, and that they are not really small |
| 38 |
>>> and/or niche, seem to be disappearing. The discussion that Tanstaafl posted |
| 39 |
>>> is interesting since the arguments used by the four TC members are really |
| 40 |
>>> focused on the technical merits of the proposed init systems. |
| 41 |
>> |
| 42 |
>> There was a thread sometime last year mentioning a slimmer/slicker and obeying |
| 43 |
>> to the *nix design principles initialisation system, but can't find it at the |
| 44 |
>> moment. Isn't that at all in the running? |
| 45 |
> |
| 46 |
> For Slackware, I have no idea. For Debian, no the only options were[1]: |
| 47 |
> |
| 48 |
> 1. sysvinit (status quo) |
| 49 |
> 2. systemd |
| 50 |
> 3. upstart |
| 51 |
> 4. openrc (experimental) |
| 52 |
> 5. One system on Linux, something else on non-linux |
| 53 |
> 6. multiple |
| 54 |
> |
| 55 |
> It should also be noted that no one in the TC voted OpenRC above |
| 56 |
> systemd AND upstart, and that while a couple voted systemd below |
| 57 |
> everything else, it can be argued that it was a tactical vote. |
| 58 |
> |
| 59 |
> Regards. |
| 60 |
> |
| 61 |
> [1] https://wiki.debian.org/Debate/initsystem/ |
| 62 |
> |
| 63 |
|
| 64 |
Why didn't they consider runit? It has parallel execution of daemons and |
| 65 |
is backwards compatible with sysv. It has a few other mini-features as |
| 66 |
well, iirc. I used for a little while before Arch pushed systemd on |
| 67 |
their community and it was interesting. |
Archives